病了丢了坏了

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

凌晨两点，512 里李洋烧到 38.9 度。陈昊摸到他额头的时候手都在抖——四个大一新生里没人经历过这种事。宿舍长拨了 120、另一个室友去敲门叫王师傅、第三个在手机上翻辅导员的电话——这时他们才想起，辅导员的联系方式在系统里、不在通讯录里。

宿舍生活里那些"突发时刻"：病了、丢了东西、水管爆了——系统能不能在这些时刻真的帮上一点忙。展开讲三件事。

25.1 凌晨两点这一刻，系统的三样东西派上用场

第一样：紧急联系人字段。李洋自己填过、也在校方数据里存在。系统里"人员信息"表的"紧急联系人 + 电话"字段是必填项，学生在自助核对时看到过——陈昊后来是在系统里查到的。这一条救不了命，但让那个凌晨三点打给家长的电话终于打通了。

第二样：宿管值班表与联系方式。宿舍楼每一层都有值班表——但王师傅的手机号在系统里挂在"楼栋 → 值班人 → 角色 = 宿管"的关系上。学生端"我的宿舍"页能看到本栋宿管的电话；深夜找不到人这件事在系统里被消灭了一次。

第三样：请假与暂不在寝的入口。李洋被送校医院那一晚，陈昊在系统里代他提了一条"因病不在寝"的临时说明——这条说明不是请假审批链的替代品，是给当晚考勤兜底。第二天李洋从校医院回来，正式请假单从移动端提交、审批链走完；系统对这两条记录都保留、按 (人员, 业务日) 唯一约束合并显示。王师傅第二天早上看到"512 4 号床昨夜因病因由 + 已发起请假"，不用打三个电话问。

25.2 病假与校医院转诊：系统与校医院系统各管一段

宿舍系统不管医疗、不替代校医院、不承诺挂号。它能做的是让"学生因病不在宿舍"这个事实被完整记录、被正确传递到该知道的人那里：

• 请假单：学生在移动端提交、选类型（病假 / 事假 / 公假）、填起止时间、可上传附件（校医院的诊断书）。
• 审批链：学校自己配——一天内辅导员批、三天内院系副书记批、更久走学工部。审批链的每一级都有留痕，事后审计能追到人。
• 考勤联动：请假审批通过之后，考勤日历在覆盖时段内自动跳过该生——不需要"宿舍长再单独报一次"。这是这套系统的一条重要纪律：已审批通过且覆盖目标时间的请假自动不参与考勤，不需要重复加入"暂不考勤"。
• 返校确认：请假到期前一天系统推一次"到期销假"提醒；学生返校后在移动端"销假"按钮点一下——没点，第二天早上辅导员会收到"未销假"待办。

这四步在系统里都是配置项与流程动作、不涉及医疗判断。"学生生什么病、要不要送医院"这件事，系统不接管——它接管的是"学生因为生病不在宿舍"这条管理事实。

25.3 东西丢了：一条完整链路能做什么

李洋的耳机不见了。他翻遍了 512 没有、怀疑是别的宿舍的人拿的。他要做的是报案或找辅导员——但报告之前，他其实可以先看系统里的三样东西：

一、门禁通行记录。如果 3 栋的门禁数据接进来了（通用接口或海康协议），系统能查"当日 20:00-24:00 之间，哪些卡号进出过 3 栋、经过哪个读头"。这不是"破案证据"，是"缩小怀疑范围"——如果那天除了本楼学生没有外人进过，那李洋大概知道要在自己年级里找。

二、访客登记（如果学校启用了）。校外人员来访在系统里有登记表——"谁、几点到、找的谁、几点走"都有记录。丢东西之后调这段记录能排除或确认"是否曾有外人到过本层"。

三、报修与巡检记录。有些"丢了"其实是"被搬走了"——卫生检查时挪动过、维修工进场时挪动过。这些动作在系统里都有留痕：谁在什么时刻因为什么原因进过 512 房间。

这三条不构成"破案系统"、构不成"证据链"——真要报案还是要报警。它们的价值是"让李洋在深夜十二点不慌"——他能自己先看一遍数据、能确定"没有外人来过"，然后安心睡觉、第二天再找辅导员。

这套系统的诚实边界：它不承诺帮你找东西、它承诺"当你要说清楚发生过什么时，你不用凭记忆"。

25.4 水管爆了：从"水漫宿舍"到"修完擦地"三小时的链路

周六中午，5 楼水房水管接头爆了。水从 512 门口漫过走廊。这一小时里系统按学校配置做了五件事：

• 一、报修提交。陈昊在移动端拍了一段视频上传，选类别"水管 / 严重"、勾"紧急"。报修工单落"待处理"，绑定 5 楼水房、绑定提交人、带视频附件。
• 二、自动派单。系统按学校策略把工单派给对应维修组（水电工种 + 5 楼所属楼栋的外协）；派单动作本身走一次审批或免审——学校定。
• 三、紧急响应。工单标"紧急"，处理时限按学校政策（一般 2 小时）；超时会自动升到"已超时"状态，触发一条提醒给楼栋责任人。这个提醒不是催维修工，是让楼长知道"要不要自己先跑去关水阀"。
• 四、维修过程留痕。维修员到场、更换接头、清理走廊——每一步在移动端打卡。每一次操作都写日志：谁、什么时候、做了什么、用了什么材料。如果学生反映"修完地还没擦干净"，处理人能看到自己有没有留这一步。
• 五、完成与验收。维修员提交"完成"、状态切"待验收"；宿舍长或陈昊在系统里点"确认"，工单归档。如果不同意"完成"，可以点"不通过"、工单回到"处理中"、留一条备注。

整条链路从"学生拍视频"到"维修员完成擦地"三小时——没有一步是靠记忆、没有一条要事后补录。学期末统计"某楼某月水管类工单数、平均处理时延、超时占比"，就是这一条链路的自然产物。

25.5 突发时刻之后系统留给学校的三样东西

• 完整时间线：几点提交、几点派单、几点到场、几点完成、几点验收——每一件事都有时间戳。事后有家长打电话质问"孩子病了没人管"，学校能拉出一份带分钟级的时间线。
• 可追溯的责任链：谁批的请假、谁派的工单、谁去修的、谁验收的——每一条都有人。事后不必靠"我记得是某某做的"来复盘。
• 可复用的模式数据：一学期跑完，"5 楼水房水管"这个位置已经报修过四次——下一次翻新计划里，这个位置就该被优先处理。系统给学校的不只是当次事件，是一年后能拿来看的"重复出现的位置"。

25.6 系统在这些时刻做不到什么

诚实说明：

• 不代替人的响应。学生病了还是要陈昊去敲门、水漫了还是要王师傅先关总阀——系统只能保证"该知道的人及时知道"，不能替代那个伸手的人。
• 不做医学判断。它不知道 38.9 度要不要送医院——那是学生、家长、校医院的事。
• 不做侦破工具。门禁数据能缩小范围，不能替警察办案。
• 不能保证维修速度。它保证的是"超时可见、可追"；至于维修工能不能两小时到场，那是物业合同的事。

这套系统的边界感是它可信的原因。它不承诺救火、不承诺破案、不承诺治病——它承诺的是"火警响了之后，你知道是哪儿响的、谁去的、什么时候灭的"。

25.7 给学校的一件事

学期中间抽一个晚上，去问三个宿舍长同一个问题："如果今晚你们宿舍出了事，你能在 60 秒之内找到哪三个人？"

如果他们的答案是"我打给同学问"、"我下楼敲王师傅门"、"我明天问辅导员"——说明系统里的紧急联系人、宿管电话、审批链还没被他们当回事。这三个入口都在移动端首页上；他们看不见是因为学校从来没在开学那周带他们点开过。

突发时刻系统的价值不是"多智能"、是"该出现的人 60 秒之内出现"。这件事 90% 靠学校平时的引导、10% 靠系统把该露的信息露出来——这 10% 我们做到了，那 90% 是学校自己的功课。