预测与调度

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

第十八章讲了系统怎么把已经发生的卡点指出来。往前一步：不等事情发生、提前把节奏摆出来。宿舍管理里能被预测的东西比想象中多：床位需求、假期周转、考勤时间窗、处理器执行时机——每一项都在系统里有对应的机制、也都有明确的边界。

19.1 床位需求预测：一条简单但不易的算术

床位预测听起来高深，实际是最基础的算术：

下一学年新生床位需求 = 下一学年招生计划 × 预期报到率 - 可回收床位

其中：

• 招生计划：来自学校层（不在宿舍系统管辖范围内），系统里通过字段配置由管理员录入；
• 预期报到率：过去三年该批次报到率的加权平均——系统里有历史住宿记录，能直接算；
• 可回收床位：本学年毕业生退住的床位总数 - 维修中或封闭的床位数——系统里能实时算。

这三个数拼起来给的判断是："明年净增 400 张床位需求、当前床位池只有 120 张空闲、缺口 280 张"。这个判断在第一年跑的时候可能不准（因为历史报到率数据不足），但每年滚动一次，第三年就能收敛到 ±3% 的误差区间。

注意：预测的是"需求量"、不是"实际结果"——学校可能扩招、可能缩减、可能把研究生外租。系统只算床位池、不接管招生计划。这一条边界要在报告里写清楚。

19.2 假期床位调度：三种典型场景

宿舍床位不是"一年定一次就完事"，寒暑假与小长假都有短期周转需求。三种典型场景：

一、考研集训营：暑假把 6 栋男生宿舍改成考研自习用房，住宿的男生临时并入 3-5 栋。这件事在系统里走临时批次 + 时间窗：新建一个"暑期集训"批次、时间窗 7 月 1 日到 8 月 31 日、目标学生名单从"自愿报名 + 辅导员审核"里生成、床位重分配走一次预排；到期自动回滚到原批次。

二、新生提前入住：某些专业（艺术类、体育类）要求 8 月 20 号提前报到，比其他专业早一周。系统里给这一批人单独一个"提前批次"、独立时间窗、独立房源池——不干扰其他新生的正常批次。

三、临时外宾与培训：学校承接短期培训班、外宾团组，需要 30-50 张临时床位。这一类在系统里走"临时住宿登记"通道——由管理员直接分配、不进入学生批次的常规预排，考勤不纳入正常范围（因为不是学籍内学生）、退住走手工操作。

这三种场景的共同点是"床位随时间弹性变化"——系统对这件事的承接是把床位状态、住宿记录、批次时间窗、考勤日历四张表联动，不是靠一张纸质"临时腾挪表"来管。

19.3 定时任务处理器：预测能自动运行的载体

上面这些"到期回滚"、"提前预警"、"定期扫描"的能力都挂在定时任务处理器上。系统里三个内置处理器 + 学校可以自配的处理器：

三个内置处理器：

• 自动考勤处理器：每天 23:00 触发；按考勤日历判定当日是否算考勤、按 (人员, 业务日) 唯一约束合成考勤结果；
• 消息发布处理器：按批次扫描待发送消息，走企业微信 / 小程序 / 邮件等通道；每条消息落发送记录、失败重试；
• 消息已读轮询处理器：定期查已送达但未读的消息、走一次二次提醒；对已读消息停轮。

学校可以自配的处理器示例：

• "未来 7 天签证到期 + 在住"扫描（研究生与国际学生场景）；
• "调宿后 30 天内二次调宿率"周报（宿舍主任）；
• "报修超 72 小时未处理"升级提醒（民办与应用型对物业的考核）。

每个处理器都有四条硬纪律：

• 幂等：同一天同一批人不重复生成数据；靠数据层的唯一约束兜底；
• 可追踪：每次执行落一条历史记录（开始时刻、结束时刻、结果、影响行数、异常）；
• 可手动执行：管理员随时能点"立即执行一次"，不用等定时；这一条给运维留出兜底路径；
• 防重启与并发：多实例同时运行时用行级锁抢占，不会重复处理。

这四条纪律不是"技术细节"、是"你敢不敢让这个自动化跑"的心理前提——一个不能幂等、不能追溯、不能手动、不能防并发的处理器，运维员永远要在旁边盯着；这四条到位了才能真的忘掉它。

19.4 调度：从"时间到就跑"到"事件到就跑"

系统里"调度"有两层：

第一层：定时调度。23:00 自动考勤、每月 1 号扫描证件校验位——按固定节奏跑。这一层由处理器承担。

第二层：事件调度。学生提交调宿申请 → 触发一次目标房间筛选、触发一次设备权限变更待办；请假审批通过 → 触发考勤日历的覆盖更新；退住执行 → 触发六张表联动。这一层由后端业务代码的事件挂钩完成。

两层的边界：定时是"到点看"、事件是"发生即响应"。宿舍管理里两样都需要——比如"连续 3 天未归"是定时扫出来的，"李洋刚刚提交了调宿申请"是事件触发的。混起来会让系统看起来很忙但没实际响应（每 5 分钟扫一次"谁刚刚申请了调宿"这种）。

19.5 预测与调度的三条常见误解

误解一：预测是 AI。本篇讲的预测是"历史数据 + 简单算术"、不是机器学习。这套系统的当前版本不包含自训练的预测模型——所有预测口径都是明规则、可解释、可回溯。这听起来"不智能"、但对学校来说可解释比准确率更重要：你能说清"为什么说明年缺 280 张床"、学校才敢拿这个数去申请预算。

误解二：调度能完全自动化。系统能自动跑处理器、能自动合成考勤、能自动派发工单——但"要不要把 6 栋改成考研集训用房"这件事永远不能自动化。那是学校层决定，需要一次专项会议、一份正式政策。系统能做的是"政策定完之后自动执行"、不是"政策自动定出来"。

误解三：处理器越多越好。有些学校喜欢配一堆处理器，"每 5 分钟扫一次这个、每天跑三次那个"。结果服务器很忙、消息很多、人已经麻木了。健康的处理器数量是"每周至少有一次真被人处理的动作"——没有这个动作的处理器就是噪音源，应该关掉。

19.6 一张表：预测与调度能力清单

能力	当前状态	说明
床位需求算术预测	已投产	招生计划 × 报到率 - 可回收床位
假期床位调度	已投产	临时批次 + 时间窗 + 自动回滚
定时任务处理器	已投产	三个内置 + 学校自配
事件驱动的业务联动	已投产	调宿 / 请假 / 退住触发链路
机器学习预测模型	未投产	当前是明规则算术，不宣称此项
自动政策调整	不做	政策由学校定，系统只执行

19.7 给学校的一件事

学期中段，问你的信息化专员或运维员三个问题：

• "我们现在跑了几个定时处理器？"——如果不到 3 个，说明系统没被真正用起来；
• "最近一个月，哪个处理器跑出的结果被人处理过？"——如果一个都没有，那些处理器就是白跑的噪音源；
• "有没有一次你希望系统能提前告诉你、但它没有？"——这一条最有价值，它是"下一个处理器"的选题。

预测与调度这件事，80% 靠学校提出"要预测什么"、20% 靠系统给机制。系统提供了配置化处理器的完整框架、提供了幂等与追溯、提供了手动兜底——但学校得自己决定要预测什么、多久跑一次、结果给谁看。

预测到位之后，下一层是"预测到异常之后怎么发出去"——风险预警。