大屏后面的那双眼

明·如归 · 宿舍管理白皮书 ｜ 第五篇 旅程篇

学生处长的办公室在行政楼四层，窗户正对着 3 栋。她办公桌上没有大屏、但走廊尽头有一块 65 寸的显示屏——每天早上上班路过时她会瞟一眼：今天分配率、昨天打卡率、本周异常数、报修处理时长。这块屏是旅程篇的最后一个场景：当系统从"个人使用的工具"变成"管理层看的窗口"，它到底在替谁看什么。

三件事要说清楚：大屏给谁看、大屏上有什么、大屏后面那双眼该问什么。

30.1 大屏不是给参观团看的、是给三个使用者看的

很多学校的第一块大屏是给参观团看的——"你看我们数字化做得多好"。这套系统的大屏不是这样设计的。它的三个真实使用者是：

• 每天上班路过瞟一眼的处长：看趋势与异常。她不需要点击、不需要查询，只需要"这块屏显示的数是不是跟昨天不一样"；
• 每周例会前 15 分钟对着开会的主任：看排行与对比。她把大屏投到会议室墙上、拿一份周报对着讲；
• 每月被上级检查时给检查组看的信息化专员：看完整覆盖。他要证明"这个系统真的在跑、不是摆设"。

三类使用者、同一块屏、不同的关注点。系统的接口在这三个层面各自有对应的聚合：趋势曲线、排行 Top20、状态占比——大屏不是把所有数字堆上去、是把这三类人各自最关心的东西分区显示。

30.2 大屏上的六组数字来自哪里

一块典型的宿舍大屏上会有六组数字——每一组都能追溯到具体接口：

• 在住总人数与床位使用率：来自住宿记录与床位状态；按校区、按楼栋可下钻；
• 今日考勤进度：来自考勤日历与五路来源的实时合成；每分钟刷新一次；
• 本周异常检出数：来自归寝异常检测器的输出、按"连续未归 / 作息突变 / 同寝连带"三档分开；
• 报修待处理数与平均处理时延：来自报修工单的状态与时间戳；
• 检查评比排行：来自宿舍评级模块的三级评分（个人 / 宿舍 / 楼栋）；
• 当日进出趋势：来自门禁通行数据（如果设备已接入）；每小时一个柱。

这六组数字背后是同一批数据——大屏、首页、周报、月报、导出报表用的是同一套接口。不存在"大屏上显示的是另一份数"这种事。这一条对管理者的重要性在于：你在屏幕上看到的数字、和你下属从后台导出的数字、和你给上级报的数字，必须完全一致——否则一周之内就会有人来问"这两个数为什么不一样"。

30.3 那块屏上不该有什么

诚实说明：

• 不放具体学生姓名。除非某学生已经被检测器判为"连续未归"这种需要立即处理的异常，且这个异常卡片是给特定值班人（不是给过路人）看的；
• 不放实时摄像头画面。这套系统不接管视频监控，也不承诺对接；
• 不放具体手机号或身份证。所有可能识别到个人的字段在大屏上永远脱敏；
• 不放"当前秒"的实时数据。考勤刷新到分钟级即可；秒级数字只会让人误以为"这系统是活的、可以立刻反映现实"——其实现实不是这样运作的。

30.4 大屏的克制：为什么"看起来不够炫"

校长第一次看大屏时常常问一句："能不能加上地图、加上动画、加上实时进出人像？"——这套系统对这些需求会拒绝一部分。理由是：

• 炫的可视化会分散注意力。大屏的价值在"看一眼就知道今天要开几个会"，不在"看起来像科幻片"；
• 过度实时会误导决策。考勤数字如果做到"每 5 秒刷新"，那"昨晚 23:00 未归数 = 8"和"今早 6:15 未归数 = 5"看起来是同一件事，实际是两个完全不同的口径——保留"每日定版"这种粗颗粒度反而诚实；
• 地图与动画对使用没价值。地图上闪一个点在管理者看来毫无意义——她想知道的是"3 栋今天未归 8 人、和昨天比是多了还是少了"。

这套系统对大屏的设计哲学是"该动的地方动、不该动的地方别动"。数据每 5-10 分钟刷新一次；动画只有轻微的过渡效果；颜色只有语义色（红 = 需要处理、黄 = 关注、绿 = 正常）。它不炫、但看得清；它不花哨、但每天有效。

30.5 大屏背后的三问：处长在上班路上会问什么

问题一：这个数在往好里走还是坏里走？——需要趋势。系统里有过去 30 天的曲线，可以直接对比。

问题二：这个数为什么变高了？——需要下钻。系统从大屏可以点到某楼栋、某学院、某年级；每一层再往下钻到具体学生。下钻不是"给处长看具体学生"、是"让处长知道问题出在哪个组织节点上"——具体名单是下属要处理的、组织定位是处长要问的。

问题三：我下一步该做什么？——需要动作建议。这一条系统目前给得弱：它能给"哪几栋楼的异常数在恶化"、但不能给"因此你要开一次针对这些楼的协调会"。这类"从数字到动作"的建议是智能层的自然语言出口未来要做的；现在还在测试桩阶段。

30.6 大屏与周报、月报的关系

大屏是"实时快照"、周报是"周期总结"、月报是"深度回顾"。三者是同一份数据的三种表达、不冲突：

• 大屏看趋势与异常，粒度是"今天/本周"；
• 周报看排行与时延，粒度是"上周对比再上周"；
• 月报看模式与政策效果，粒度是"本月对比上月与去年同期"。

这三份报表在系统里都由同一批接口生成——大屏每 5-10 分钟拉一次、周报每周固定时刻算一次、月报每月固定时刻算一次。使用者看到的数字对得上，是因为它们来自同一份数据。

这套系统对"三份报表口径不一致"这件事是零容忍的——因为一旦不一致，就有人开始怀疑所有数字。"你告诉我这个月的异常数是 12，可是大屏上显示的是 15"这种对话不能发生。

30.7 旅程篇的收束：五个人、四条线、一份数据

旅程篇 8 章讲了五个人：李洋（学生）、陈昊（宿舍长）、王师傅（宿管）、李洋的辅导员、学生处长。五个人的日常在同一份数据上运转，但看到的完全是不同的六个界面：

• 李洋看学生端首页（房间、考勤、报修、请假、调宿、公告）；
• 陈昊看宿舍长端（代报考勤、上报问题）；
• 王师傅看教师移动端工作台（考勤汇总、检查、审批、报修处理）；
• 辅导员看管理端学生列表（他所带班级的所有记录）；
• 处长看大屏与首页（趋势、异常、时延）。

这五个视角共用同一批接口、同一份数据模型、同一套权限过滤。系统的架构不是"给五种人做五套系统"、是"给一套系统做五种视图"。这一条纪律保证了：李洋在手机上打的卡、王师傅的平板上看到的"已打卡 484 人"、处长大屏上的"今日打卡率 92.3%"，是同一个事实。

30.8 给学校的一件事

学期末，你带着处长、主任、王师傅、李洋坐下来，每人面前一张纸——"请你画一张你心目中宿舍系统的样子：你打开时看到什么？"

四张纸摊在桌上比对。如果四张纸互相没有一处对得上——那说明你们学校的宿舍系统虽然装了，但没形成统一的心智模型。每个人在自己那一格里各看各的。

"大屏后面的那双眼"真正要问的是：不是"你的大屏做得好不好看"——是你的这双眼睛看到的数字，跟楼下王师傅看到的、跟 512 李洋看到的，是不是同一件事。

如果是，那这套系统就在你们学校跑起来了；如果不是，那它只是一块挂在走廊尽头的屏，每天亮 24 小时，跟谁都没关系。

旅程篇到此结束。五个人的一天、四年、一次搬迁、一场告别——系统在这些时刻里都在场，但都是安静的。下一篇回到全典——把这套系统的全部能力、全部字段、全部环节一次性摊开——供你按类查阅。