多校区与老校区

明·如归 · 宿舍管理白皮书 ｜ 第六篇 高校篇

某大学三个校区：本部在市中心、老校区是一栋 1985 年的六层家属楼改造的宿舍、新校区在三十公里外的郊区。同一个学生处要管三个校区的宿舍，处长办公室的墙上挂着三张平面图，比例尺不一样——本部的楼密集、老校区的楼零散、新校区的楼规整。三套物业、三套门禁设备品牌、三套历史遗留数据。

多校区与老校区不是一类学校，是任何一类学校可能碰上的复杂度增量。系统的承接分七个层面展开。

36.1 多校区的三个真问题

• 数据范围：谁能看哪个校区？处长看全部、副部长看分管的两个、校区宿管主任只看本校区。这件事在系统里落得很实：组织六级树（学校 → 校区 → 学院 → 专业 → 班级）+ 宿舍四级树（校区 → 楼 → 层 → 房间）——"校区"这个层级在系统里是一等公民，不是靠字段区分。
• 跨校区调宿：某学院从老校区整体搬新校区，涉及四百人、两个学期。这件事在系统里走"批量调宿 + 批次时间窗 + 审批链"——不是靠"退住 + 重新分配"两步手工拼。
• 口径统一：三个校区的考勤时间窗可能不一样（老校区 22:30、新校区 23:30），三套门禁设备品牌不一样（老校区是十多年的闸机、新校区是海康、本部是通用接口）。这件事在系统里落两处：考勤时间窗按校区批次分开配置；门禁设备连接器按类型分别配置（三种连接器可以并存，只有地图服务受"同时只允许一个启用"约束）。

36.2 跨校区调度：一次搬迁的四步

某学院从老校区整体搬迁到新校区——四百人、两百张四人间、一次搬完。这四步是这类搬迁在系统里的完整链路：

• 第一步，建新账：新校区那栋楼的楼、层、房间、床位在系统里先建齐（导入模板批量建、一次导完）；床位初始状态全部为"空闲"。
• 第二步，跑预排：把这四百人 + 两百张新床作为一次独立的分配批次跑一次预排——三条硬不变量、软约束按"同班级同楼层"配。预览结果人工调整（个别学生要调室友）后确认。
• 第三步，批量调宿：一次性生成四百条调宿申请（原房间 → 新房间），走一次审批。这一步不需要学生个人操作——由校区管理员与宿管主任在管理端批量处理；每条调宿记录都保留原床位、新床位、审批人、时刻。
• 第四步，处理旧账：老校区那两百张床位状态改"封闭"或直接删除；住宿记录保留历史归属，用于将来审计。

整个链路系统都有对应功能，学校只需要一次批下来一个专项窗口。关键是"批量"两个字——如果是四百条一条条点，谁也受不了。

36.3 老校区：三个特殊难点

老校区跟新校区的差别不是"楼旧一点"，是三个具体的难点：

• 房型不规则：1985 年的家属楼改造，同层房间大小不一、床位数量不一（有的三人间、有的四人间、有的把两间打通做六人间）。这件事系统的解法是"房间表允许每间独立配置容量"——不是强制按楼栋统一房型。字段元数据加"房型备注"、"实际面积"、"是否有独立卫浴"，把这些不规则特征显式记下来。
• 设施台账缺失：水电气管网图找不到了、门锁品牌换过三次、每层配电箱编号跟实际不对应。这件事系统的解法是"从上线之日起记新账 + 逐步回补旧账"——报修工单每一次处理都留下设备与位置；学期末导出一次"曾经报修过的设备清单"作为最低可用台账。不要求学校上线前把老账全部理齐，那是逼学校放弃上线。
• 门禁设备老：十多年前的闸机可能没有网络接口、只有串行总线或韦根信号。这件事系统的解法是"允许某些楼栋没有门禁数据"——考勤默认来源不依赖门禁、五路来源里门禁只是其中一路；老校区可以先用移动打卡 + 宿舍长上报运转，等新设备接入再合并。

36.4 一套系统 vs 多套系统：为什么不建议拆

多校区学校常见的一个冲动是"给每个校区各装一套、互不影响"。这个想法可以理解，但代价很大：

• 口径不一致：三个校区各自配置考勤时间窗，跨校区转学的学生一进门就懵——"我在 A 校区算晚归、在 B 校区算正常"。
• 数据不能合并：处长要看全校床位使用率，得分别打开三个后台，人工加总。
• 政策落不下去：学校层决定"明年全校推行同一种卫生检查评分"，三套系统要改三次。

一校一实例不等于一区一实例。系统对多校区的正确用法是"一个实例、多个校区、按校区配批次与规则"——共享政策与数据模型、独立配置与数据范围。这件事在系统架构里是天然支持的：组织六级树的第一层就是校区。

36.5 地图与定位：多校区的另一个复杂源

多校区意味着"校区之间的物理距离"是真实存在的问题——学生从老校区下课回新校区宿舍要坐班车四十分钟。系统的地图服务在这种场景里的用法跟单校区不同：

• 五类地图源都要能配：本部可能在市中心用高德最准、老校区在市区边缘用天地图覆盖更全、新校区在郊区可能需要卫星图叠加。系统对这三类的支持是"同时只允许一个启用，可切换"——不是同时叠加，是一条硬约束。
• ** campuses 图层独立**：不同校区各自维护自己的建筑图层。这件事在系统里不是"地图"管的、是"资源台账"管的——楼栋与房间的物理坐标通过字段元数据挂到楼栋实体上。
• 移动端定位：多校区学生打卡时"到寝判定"要按各自校区的坐标算。这件事系统已经支持——移动端的定位打卡是按"当前分配房间所在楼栋的坐标"判定，不按全校统一中心。

36.6 老校区的智能层：什么能做什么不能做

• 智能预排：老校区房型不规则，求解器要能承接"同层不同房型"的分配——这件事能做，但预览界面要清晰标注"该房间容量与常规不同"，避免使用者误以为是数据错误。
• 归寝异常预警：老校区的连续未归检测在门禁覆盖不全时价值有限；作息突变检测靠打卡数据能跑，但基线建立慢（老校区学生作息本来就不规整、14 天中位数容易偏）。建议老校区第一学期只做"宿舍长上报"、不做自动预警；跑一学期后再看。
• 360 画像：老校区学生画像的"活动轨迹"维度可能缺失（没有门禁数据）、"作息规律"维度可能噪声大——这是画像在老校区最容易失真的两处。用画像决策时要把这两点显式降级或标注置信度。

36.7 给多校区与老校区的一句话

你的复杂度不在功能、在结构。同一套系统跑三个校区、三种设备、三套历史遗留——关键是"校区"这个层级在系统里是一等公民，不是靠字段区分；是**"房型不规则、设备覆盖不全、数据不完整"这三种现实能被系统承接**，不是要求学校先"把老账理干净"再上线。

第一年先建组织树与宿舍树、把三套设备的连接器分别配起来、跑一次跨校区搬迁演练；第二年看数据是否统一、政策是否能一次落到三个校区；第三年才谈跨校区智能调度。这条时序在老校区尤其重要，因为老校区的每一次"想快"最后都变成"更慢"——政策与设备不齐就跑智能，跑出来的东西没人信。