底座三件事

明·如归 · 宿舍管理白皮书 ｜ 第一篇 开篇

在进入具体能力之前，必须先处理一章不太光彩的内容。名单进得来、床号对得齐、台账理得清——这三件事任何一家做宿舍系统的厂商都写在首页上，很多学校自己上一轮信息化就解决过。把它们当卖点，是使用方经验的侮辱；把它们当空气，又是对学校预算的不负责任。 这里把三件事一次讲完、定性好性质，后面四十一章不再回去讲它们。

5.1 为什么只给底座一章

先立规矩：做不好这三件事，任何智能都是给学校添乱；做好了这三件事，也不值得反复宣讲。

添乱的意思很具体：名单都没导齐的系统推"归寝异常预警"，预警本身就是新的舆情源；床位对不齐的系统做"分布测算"，测算是拿着错的底数做正确的算术。底座不是智能化的铺垫，是它的准入条件——这一条放在招标里，比任何参数都管用。

不值得宣讲的意思也一样具体：这三件事的技术方案在上一轮智慧校园与一网通办时代就是成熟品，把它们重新包装成"亮点"，暴露的是厂商这些年没往前走。

5.2 进得来：对账，不是导入

"数据接入"这个词被用坏了——几乎所有系统都宣称支持导入导出，差别在一条脏数据进来的那一刻发生了什么。

这套系统的做法是分层的。最基础的一层是模板化导入：字段对照表提前给到，证件类型、学号格式这类能在入口拦的当场拦下。往上一层是源系统对账：与教务学籍之间不靠人工搬表，按学号为锚点做全量比对，每一行的去向归进四类——新增、更新、冲突、跳过；冲突单独成册，等人裁决，系统不自作主张。来源可信等级不同的字段有保护名单，对账不许静默覆盖。

增量同步依赖真实源系统提供时间戳或游标，不在当前版本范围内；眼下按批次全量比对，重复执行结果一致——这话说的不是效率，是敢让你跑第二遍的底气。第七、十五章会回到这条链路，谈的是治理，不再谈能不能导进来。

5.3 对得齐：两套树，一张床

宿舍数据难管，难在它天生挂了两套组织架构：一套是学校的人——校、区、学院、专业、班级；一套是学校的楼——校区、栋、层、房间、床位。一个人必须同时落在两棵树的末端，且两端指的是同一张床，数据才算对得齐。

对不齐的代价平时看不见，出事时全都现形：学院要名单，楼栋给不出；楼栋清了楼，学院不知道谁该在却没在。所以系统的底层不是"一张住宿表"，是两棵树的交叉挂接——人的组织归属实时从学籍源同步，床的空间归属由楼栋模型维护，分配记录是钉住两端的那颗钉。钉子要有硬约束：性别隔离、一人一床、组织预分范围，这三条写死在程序里，不进入任何可配置项（第九章谈为什么这三条不配做配置）。

配套的工程纪律还有一条：结构变更走幂等脚本，重复执行不产生第二份数据。"对得齐"不是上线那天对一次，是每一次变更之后仍然对得齐。

5.4 理得清：台账是拿来查的

设施台账是宿管最日常的负担，也是最容易做死的模块——多数系统的"台账"是一张只能追加的导入表，一年以后没人敢看。

活的台账至少满足三件事。有状态： 一件设备的报修、停用、报废是状态迁移，不是新记一行；有历史： 修过几次、哪天换的、谁验的收，逐条可翻，历史导入不覆盖既有记录；有出口： 任何一张表能按当前口径导出，字段随学校自定义字段配置走，不锁在厂商的报表模板里。

留痕同理。操作日志不是给审计人员准备的刑罚预案，是让"当时谁做了什么"成为可以不依赖任何人记忆的事实——这一性质在第三十八章展开，底座层面只需要记住一句：记录写给未来的陌生同事看。

5.5 底座的自检：五规则与问题工作台

三件事各归其位之后，底座还需要一样东西：自我检查的能力。没有自检的系统，数据质量靠出事后来考古。

系统内置五条固定规则周期扫描全库：一人多占（一个学生占两张床）、性别不符（男生挂进女生楼）、离校在住（学籍状态已离校仍有在住分配）、证件校验位错误、通行无主（设备记录里出现系统无法归属的人）。每条命中生成一个问题，进问题工作台；去重规则保证同一实体同一问题不会重复刷屏，处理有状态、有回执。

这五条没有一条是人工智能，全部是朴素的比对逻辑。它们值钱的地方在于：错的数据不再被默认正确——治理的姿态从"回头清理"变成"当场摆出来"。 底座做到这个程度，才有资格往上面搭判断。

5.6 底座三件事的小结

进得来、对得齐、理得清——三件事任何一家厂商都能写在首页上。真正把它们当空气的、也是同一家厂商。下一章谈“我们的不一样”：当底座不成为话题时、这套系统把精力花在了哪里。

5.7 一张表：底座三件事的能力清单

能力	当前状态	要点
模板化导入	已投产	字段对照表 + 入口拦截
学号锚点全量对账	已投产	新增 / 更新 / 冲突 / 跳过
冲突册不自动裁决	已投产	四要素摆齐等人签
受保护字段不静默覆盖	已投产	床位与分配不反向写回
两棵树交叉挂接	已投产	组织树 + 宿舍树
三条硬约束写死	已投产	性别隔离 / 一人一床 / 组织预分
幂等迁移	已投产	18 个脚本可重跑
台账三件	已投产	有状态 / 有历史 / 有出口
五条质量规则	已投产	多占 / 性别 / 离校 / 校验 / 无主
问题工作台	已投产	去重不刷屏、处理有回执
增量同步	未投产	需要源系统提供时间戳
自动修复	不做	修复永远由人执行

5.8 三条关于底座的常见误解

误解一：底座很简单、一周上完。底座自身的技术不新、但在具体一所学校里把底座立住至少需要一个学期——因为你要清账（历史数据里的病）、要定口径（与教务的受保护字段边界）、要养习惯（冲突册里真的有人处理）。“底座一周上完”的下一句通常是“一学期后里面一堆错没人发现”。

误解二：底座做好了就可以不管了。底座不是一次工程、是一个持续运行的前提。学生入学、毕业、转专业、休学、返校——每一天底座的对账与扫描都要重新跑一遍。底座的价值不只在“一开始对”、在“错了能当天发现”。

误解三：底座不直接影响体验。完全相反——底座直接决定预警不刷屏、报表不丢人、导出不出事。一所底座没建好的学校，上面一开智能预警就是几百条假报、一个报表导出就是两百个重名不确定的列。底座不直接看见、但它直接控制上面一切可信度。

5.9 到此为止

底座到此讲完。最好的证明是：点头“确实该这样”之后，记不住任何新东西——记不住，恰好说明它配得上“底座”二字。

能力篇从这里接棒，谈的不再是“数据怎么进来、怎么理齐、怎么记”、而是这堆理齐了的记录能为一栋楼、一个人做什么。先谈床位——宿舍里第一个不允许出错的东西。