- 学生360画像由基础、住宿、考勤、服务、异常、社交六维聚合而成
- 决策仪表盘覆盖床位、异常、服务与时延三类可下钻指标
- 周报草稿系统给40%、人写60%,尚未接入真实语言模型
- 政策实验通过对照组与实验组为政策调整提供数据依据
- 数据复利依赖结构化、保留期长、可追溯三条同时成立
明·如归 · 宿舍管理白皮书 | 第四篇 智能化篇
第二十章讲了系统怎么把异常喊出来。当喊过足够多次之后,学校真正需要的不是"再多一条预警",是"这学期的整体决策依据"。宿舍管理里最有价值的不是"某一天谁没回来"、是"一学期之后我们能不能说清楚这一年宿舍发生了什么、明年应该改什么"。这就是决策与沉淀。
21.1 学生 360 画像:六维聚合
系统里每个学生都有一张 360 画像。六维是这张画像的基本结构:
- 基础信息:学号、姓名、性别、学院、专业、班级、入学年份、政治面貌、族别、国籍、籍贯、证件号(掩码);
- 住宿轨迹:历次房间分配、每次调宿的起止时刻与操作人、当前床位号;
- 考勤轨迹:本学期的在寝 / 晚归 / 未归 / 请假 / 暂不考勤五日统计与逐日时间线;
- 服务轨迹:报修发起数、投诉建议发起数、经手处理的服务单数;
- 异常轨迹:经手的归寝异常预警数、按检测器分类的分布、处置状态分布;
- 社交轨迹:历任同室同学名单(用于"和室友处不来"、"同寝连带预警"的分析)。
六维不是六张表拼起来——是在同一个页面里、通过一次点击能看到全部。这个"一次点击"的价值不是效率、是决策完整性。宿管判断"要不要给这个学生调一次宿舍"时,如果只看考勤会漏、只看住宿轨迹会漏、只看服务工单会漏——只有六维同时在场,判断才不会偏。
画像的权限设计:宿管只能看自己管辖范围的学生画像、辅导员只能看本院的、管理员能看全校的——每一层的画像可见字段也不同(例如手机号、证件号在非管理员视角是掩码)。这一层设计让"数据可用"与"数据不泄露"能同时成立。
21.2 决策仪表盘:三类核心指标
系统给管理员一张决策仪表盘,展示三类指标:
21.2.1 床位类指标
- 总床位数 / 已使用 / 空置 / 维修中;
- 分学院的床位使用率;
- 本学期调宿人次与调宿原因分布;
- 预排命中率(自动分配后不需要人工调整的比例);
- 一学年内的床位周转天数(一间房从上一个学生退住到下一个学生入住的中位间隔)。
这一类指标回答的问题:"我们的房子够用吗、用得好吗?"
21.2.2 异常类指标
- 每日在寝率、晚归率、未归率;
- 分学院、分楼栋的异常分布;
- 三张检测器分别命中了多少条预警;
- 预警的处置时长中位数(从生成到被处置要多久);
- 连续预警学生名单(一学期被预警 3 次以上的学生)。
这一类指标回答的问题:"我们的学生在宿舍里安全吗、有事的时候响应得快吗?"
21.2.3 服务与时延类指标
- 报修工单总量、按状态分布、按处理时长分布;
- 投诉建议总量、按类型分布;
- 审批链路的时延中位数(例如请假审批从提交到通过要多久);
- 各角色操作频度(宿管、宿舍长、辅导员各自的活跃度)。
这一类指标回答的问题:"我们为学生提供的服务到位吗?"
三类指标的共同点:每一类都能下钻——比如"未归率高"能一路点到"哪个学院、哪栋楼、哪几个学生、哪一天的数据"。不能下钻的指标是虚的、只有能一路追到具体学生的指标才是可问责的。
21.3 周报草稿:把六维聚合翻译成人话
决策仪表盘是图、是数、是下钻——但学校真正对外沟通用的是文档。系统里有一类 大模型出口叫周报草稿:把过去 7 天的六维数据聚合成一段自然语言的周报。
示例输入(伪数据):
- 本周在寝率 96.2%(上周 95.8%);
- 本周预警 41 条(连续未归 18、作息突变 19、同寝连带 4);
- 本周报修 87 单、完工 61 单、超期 4 单;
- 本周调宿 23 人次,主要原因:宿舍矛盾 9、身体原因 6、其他 8。
示例输出(周报草稿的一段):
本周整体态势:在寝率环比小幅上升 0.4 个百分点,保持在近 5 周的高位。预警方面:连续未归与作息突变两条线合计 37 条,同比略降;同寝连带预警 4 条集中在周三晚上,与学校运动会调休有关,无风险。服务方面:报修 87 单、完工率 70%、4 单超期已升级至后勤主管。调宿方面:宿舍矛盾类占 39%,建议下周由学工部门针对 3 号、7 号宿舍楼的高频矛盾宿舍做一次专题座谈。
这份草稿在系统里的定位:人写 60%、系统给 40%。系统给的是数据、结构、初步判断——最终发出去之前管理员要重写、要补充、要修正。它节省的是"从翻数据到起草"的时间、不是替代人。
当前实现:这一类出口在系统里跑的是确定性测试桩(给定输入产生结构正确、内容固定的输出,供上线前验证链路),尚未接入真实语言模型。接入计划在学校使用满一学年、积累了真实周报样本之后启动——没有真实样本训练出来的自动周报会写得不像这个学校,宁可不做。
21.4 政策实验:给"要不要改"提供依据
宿舍管理里最有价值的决策不是"某天的的具体处理"、是"政策要不要改"。例如:
- "男生楼 6 栋的晚归率高、要不要把晚上 11 点的门禁延后到 11 点半?"
- "调宿矛盾集中在大二年级、要不要专门为大二年级配一名副宿管?"
- "预分配比例班级 30% 是不是太低?调到 50% 会不会更好?"
这类问题不能拍脑袋答。系统的机制是政策实验:把学生分成对照组和实验组、跑一学期、看数据。
- 对照组:现有政策(门禁 11 点、班级比例 30%);
- 实验组:新政策(门禁 11 点半、班级比例 50%);
- 观测周期:一学期;
- 核心指标:晚归率、调宿率、预警处置量、学生满意度(走学期问卷)。
系统支持政策实验的三层能力:
- 分组:通过批次参数或组织范围划出实验组与对照组;
- 观测:六维聚合能按组分别看;
- 对比:导出对比表、外部工具做统计显著性检验。
这一层不是"系统能自动跑实验"、是"系统能给实验提供完整数据"。实验设计、执行、判断还是学校的育人团队来做——系统的价值是让判断有依据、不是让判断自动化。
21.5 一学年的数据复利
第一年用系统,看到的是"每天的考勤"。第三年用系统,看到的是"这个学生从入学到现在的完整住宿档案、这类政策在过去三学年的效果曲线、这个楼栋在同类学校中的相对位置"。
这就是数据复利。它不来自"数据多"、来自"数据结构化 + 保留期长 + 可追溯"。三件事同时成立才有复利:
- 结构化:所有数据都在同一套模型下、能一起聚合;
- 保留期长:一学年的数据在系统里、上学年的还在、上上学年的也还在;
- 可追溯:任何一条聚合数据能一路点到源记录。
没有这三条的"数据多"就只是"文件多"。
21.6 目前做不到什么
诚实地列出决策与沉淀维度的边界:
- 因果推断:系统能给"门禁延后 + 晚归率下降"的相关性数据,不能证明"晚归率下降是因为门禁延后"——那是实验设计和人工判断的责任;
- 跨系统数据整合:教务成绩、图书借阅、消费流水不在本系统内、跨系统的画像需要学校级数据中台;
- 长期预测:系统能报本学期和过去 3 年的数据、不能预测 5 年后的招生与床位——那是学校战略层的事;
- 自动生成正式报告:草稿可以自动、正式发文必须人写、这条边界不给系统留后门。
21.7 给学校的一件事
学期中段做一次"画像抽查":随机挑 5 个学生、5 个宿舍、5 个楼栋,把每个对象的 360 画像和决策仪表盘对应指标打开看:
- 能不能一屏看到这个学生过去一学期的完整住宿故事?
- 这个宿舍的"同寝连带预警"历史上是不是集中在某个时间段?
- 这栋楼的服务工单完工时长中位数是不是显著劣于均值?
任何一屏让你觉得"这个数据我看不出来什么"——那就是这个数据没沉淀好。让信息化专员记下这些"看不出来什么"的点,作为下一批治理的选题。决策与沉淀不是一次做对的、是每学期挑一两个薄弱点补上。
画像、仪表盘、周报草稿、政策实验四层都在讲"系统能替人做多少判断"——下一份要谈"系统不能替人做什么":智能化的边界与落地形态。