风险预警

明·如归 · 宿舍管理白皮书 ｜ 第四篇 智能化篇

第十九章讲了系统怎么提前摆出节奏。当"摆出来"的东西里有一个不该有的形状——系统要主动喊人。这就是预警。宿舍管理里的预警不是"多一条消息"、是"有一条必须被处理的信号"——它的算法、阈值、送达、处置四个环节都要有硬约束。

20.1 三张归寝异常检测器：预警的核心算法

系统里"预警"最集中的落点是三张归寝异常检测器。每张检测器都是"输入 → 判定 → 输出 → 送达"四段式：

20.1.1 检测器一：连续未归

输入信号：一个学生在最近 N 个考勤日的考勤结果。N 的默认值是 3、可以由学校调整。

判定规则：这 N 天里每一天都是"未归"、且每一天都不是"请假已批准"或"暂不考勤覆盖"——三个条件同时满足才命中。

为什么这么严：一个学生如果昨天请假今天返校、后天又请假——中间那天不算未归；一个学生连续 3 天没打卡但被"暂不考勤"覆盖了——不算未归；只有"应考勤日 + 未归状态 + 没有例外"三条同时成立才算。误报比漏报对预警体系的伤害更大——学校一旦被误报打扰几次，真出事的时候就不会再信预警了。

输出：一条"连续未归"预警记录，绑定学生、绑定最近一次未归的房间、绑定业务日期。

送达：走五层通知链——宿管、宿舍长、学院负责人、辅导员、家长（按学校政策配置哪一层接收）。

20.1.2 检测器二：作息突变

输入信号：一个学生最近 14 天的回寝时刻中位数（不是平均数，中位数抗离群值）。

判定规则：当日实际回寝时刻与个人中位数偏差 > 90 分钟，且过去 14 天里至少有 5 个有效样本。

为什么用中位数：一个学生上周有两天晚归到 1 点、其他 12 天都是 10 点——他的中位数还是 10 点。均值会被离群值污染、中位数不会。这一条对预警体系至关重要——一个学生偶然两次晚归不该触发"作息突变"。

为什么要 5 个样本：一个学生刚开学只回寝了 3 天——没有稳定的作息基线、不该被判定为"突变"。样本不足时直接跳过、不输出预警。这一条保护了转学生、交换生、临时入住的学生。

输出：一条"作息突变"预警，附上"过去 14 天中位数 22:15 / 今天 00:45 / 偏差 150 分钟"这样的原始依据。预警必须能展开看到数据、不然宿管只能凭空口判断。

20.1.3 检测器三：同寝连带

输入信号：一个宿舍当日所有成员的考勤状态。

判定规则：同一宿舍当日未归人数 ≥ K（默认 2）。

为什么要这一张：前三十天都没事、今天突然一屋子人全没回来——这可能是一个宿舍集体外出、也可能是一个宿舍集体出事（打架、集体生病、集体被骗）。同寝连带关心的是"群体的异常"、不是"个体的异常"。

输出：一条"同寝连带"预警，绑定宿舍、绑定当日所有未归人名单。

这张检测器的一个隐藏用途：它倒逼宿管把"暂不考勤"用对。如果一个宿舍有两个人这周都被"暂不考勤"覆盖了、当日晚归不会被算作未归——那这张检测器就不会误报；但如果暂不考勤没设对，一屋子人外出比赛没打卡、系统就会集体报警。这张检测器是"例外机制是否用得干净"的照妖镜。

20.2 四元组去重：让预警不至于刷屏

三张检测器每天扫一次；如果没有去重机制，一个学生连续 3 天未归会被"连续未归"命中、被"作息突变"命中、可能同寝的另外两个人也会一起触发"同寝连带"——一个真实问题产生 5-10 条预警，收件人开始屏蔽消息，真出事就漏了。

系统的解决方案是四元组唯一：(规则, 学生, 房间, 业务日)。

• 规则：三张检测器的名字，防止"连续未归"和"作息突变"当日均命中同一人时算作两条；
• 学生：谁触发；
• 房间：在哪里；
• 业务日：哪一天的事。

四元组相同的预警只发一次。同一天、同一学生、同一房间、同一规则——不管扫描器被触发多少次（比如手动 + 定时都跑了），预警只有一条。这一条硬约束是"预警可信"的基础。

20.3 送达：五层通知链，一层不落地

一条预警生成之后要送出去。系统里通知链路是分层的：

• 宿管：手机推送 + 工作台红点，第一时间知道；
• 宿舍长：小程序消息，让同龄人先内部处理；
• 学院负责人：企业微信消息 + 邮件（视学校政策）；
• 辅导员：小程序 + 企业微信；
• 家长：企业微信 + 短信（视学校政策与预警级别）。

每一层的送达都独立记录："何时发、通过哪个通道、对方是否已读、失败重试了几次"。这些字段都进入预警详情的"发送链"标签页——宿管可以点击查看"这条预警几点几分送到家长手机、家长有没有点过"。

"发送链"是宿舍管理里的一个重要设计：一条预警在系统里"发出"了、不代表"送到"了。只有把每一层的送达状态都摊开、学校才能在家长追问时给出准确回答。这一层"能不能追溯到送达状态"是很多系统没有做、但真正出事的时候最需要的东西。

20.4 处置：预警状态三态与操作留痕

一条预警发出后，接收人可以点它进入工作台。系统里预警只有三种状态：

• 未处置：刚生成、没人动过；
• 已处置：接收人点了"确认处理"、可以写一句处置说明（比如"电话已接通、学生在图书馆通宵自习"）；
• 已忽略：接收人点了"忽略这条"、必须写忽略理由。

没有"删除"这个操作——预警只能被处置或被忽略、不能被抹掉。每一天的所有预警、每一条的处置人和时刻、处置说明都要能追溯。这是学校面对家长追问、面对上级检查、面对突发事件复盘时的最后一道防线。

批量处置：管理员可以对"同一宿舍当日 4 条未处置"一键"标记为已处置"（用于"整栋楼突然停电"这类根因单一的场景），但批量处置要求填一条统一说明——防止有人用批量把该看的都划过去。

20.5 与其他系统的联动

预警不是孤立能力，它至少和四件事联动：

• 考勤日历：暂不考勤覆盖的日子不参与连续未归判定；
• 请假审批：已批准的请假覆盖目标时间段的考勤、不触发预警；
• 学生 360 画像：一个学生被多次预警会体现在画像的"异常密度"维度；
• 操作日志：所有预警的处置动作要留痕，与调宿、审批类操作日志合并归档。

这种联动让"预警"不是孤立能力、而是整个系统在"异常时刻的显性化"。学校层面看到的"这个学生本学期预警 7 次"——背后是考勤数据、请假数据、预警算法、送达链路四套系统一起工作。

20.6 一张表：预警能力清单

能力	当前状态	说明
连续未归检测	已投产	近 N 日均未归，N 默认 3
作息突变检测	已投产	中位数偏差 > 90 分钟，最少 5 样本
同寝连带检测	已投产	同宿舍当日 ≥ K 人未归，K 默认 2
四元组去重	已投产	规则 + 学生 + 房间 + 业务日
五层通知链送达	已投产	宿管 / 宿舍长 / 学院 / 辅导员 / 家长
三态处置工作台	已投产	未处置 / 已处置 / 已忽略
预测性预警（"这个学生下周可能要出事"）	未投产	当前是回溯性算法
心理危机预警	不做	涉及专业评估、不由系统承担

20.7 给学校的一件事

开学第一周，做一次预警演练：手动创建一条假的"连续未归"预警、看它在系统里走完四个环节：

• 生成：四元组有没有正确去重？
• 送达：五层通知链每一层都到不到位？有没有一条被漏？
• 处置：宿管点"已处置"和"已忽略"分别是什么体验？
• 追溯：一周之后你能不能通过预警号找到当时的完整处置链？

演练通过再上线，比上线后靠运气靠谱得多。

预警发出之后，接收人做的判断才是这套系统的最终价值——决策与沉淀。