第一晚

明·如归 · 宿舍管理白皮书 ｜ 第五篇 旅程篇

李洋晚上八点拖着行李箱进 3 栋大厅。宿管王师傅坐在窗口看了一眼他的手机——不是"你有没有分配记录"，是"这个学生长这样、系统里那张照片长那样"。王师傅在系统里的住在校验接口上按学号查到了他的床位、看到"未住"状态，把钥匙从挂钩上取下来递出去。

李洋上五楼、推开 512 的门。房间里已经有一个先到的人——宿舍长陈昊，正在铺床单。这是他们的第一晚：还叫不出对方全名、不知道对方是不是好相处、不知道空调怎么用、不知道水卡去哪里充值。这一晚的每一个"不知道"，系统能不能提前替他答一句？

24.1 入住登记的那一刻：从"未住"到"在住"

李洋拿到钥匙不算入住。入住登记才是。这一步在很多学校是一张纸质登记表——这套系统里它是学生端一次点击 + 一次身份核验：

• 学生端"我的宿舍"页有一个"办理入住"按钮；点下去，系统读定位、读时间、读操作者；
• 后端校验：这个床位当前的分配记录是否属于该学生（防止拿错钥匙）、房间容量是否已满（防止重复登记）、当前时间是否在批次允许入住窗口内；
• 校验通过，住宿记录状态从"未住"切"在住"；写操作日志（谁、什么时刻、什么状态变更）；房间与床位容量占用同步刷新；
• 学生端首页显示"已入住 3 栋 512"；家长端的绑定关系同步刷新（若学校启用了家长通知）。

这一步看起来小，实际决定了后续所有链路的起点——考勤从今天开始算、检查从今天开始查、退住从今天开始有历史。没有入住登记，考勤系统就"不知道这个人是不是应该在这里"；有入住登记，所有后续问题都能问一句"他登记了吗"。

24.2 空调、水卡、洗衣机：第一晚的四件具体小事

第一晚学生真正会做的事只有四件：开空调、洗澡、洗衣服、给手机充电。四件事在系统里的落点是三个：

一、设施台账。每台空调、每一个水龙头、每一台洗衣机在系统里都是一个设备实体——设备编号、品牌、安装位置、启用日期、上次维修日期。这些台账不需要李洋看，但需要王师傅和维修员能查。李洋第一晚按了空调遥控没反应，走报修工单——维修员到场打开平板，能看到这台空调是 2019 年装的、去年换过一次电容、这次是遥控接收器问题；不用从头检查、不用叫厂家。

二、报修工单。李洋在移动端提交"宿舍空调不制冷"——工单落"待处理"状态、绑定 512 房间、绑定他本人；系统按学校策略派单（自动分给该楼水电商、或由楼长手工派）；处理完成后状态切"已完成"，李洋手机端弹出确认。这条工单永久留在系统里，学期末可以按"某楼某年某月空调类工单数"统计——下一批采购换空调时，这份数据是依据。

三、水卡与洗衣机的充值。这两件事多数学校走独立系统（一卡通、校园 App），宿舍系统不承诺承接。但李洋在移动端"我的宿舍"页能看到一个"外部服务"入口——学校配置的链接、二维码、说明文字——一键跳到该去的地方。这个入口是"字段元数据 + 链接配置"，学校自己维护。

24.3 22:30 之前：第一次打卡

李洋的第一晚，真正的系统时刻是当晚的归寝打卡。这套系统的考勤有五路来源：

• 移动自助打卡（学生自己在手机上定位打卡）；
• 宿舍长上报（每间房指定一人代报"我宿舍今晚都在"）；
• 宿管查寝（王师傅拿着平板逐间确认）；
• 门禁通行（如果设备已经接入）；
• 自动考勤（定时任务在时间窗结束时按已有数据合成结果）。

李洋第一晚不知道有这回事——系统会在他入住当天通过移动端消息通道推一条"今晚 22:30 前请完成归寝打卡"的提醒。这个提醒挂在考勤批次配置上：批次表里有"提醒提前分钟数"字段（默认 30 分钟），系统按此定时推送。

他 21:47 在房间用手机打了卡，状态记"在寝"。这是他在这个系统里的第一条个人操作记录——不是"某某号某某房间"、是"某某时刻、某某 IP、某某定位坐标"。以后所有关于他的轨迹都从这条开始。

"第一晚的打卡体验"是决定学生对系统第一印象的关键动作：打得通、状态对、消息不炸、不需要注册第五个账号——这条通了，学生后续一学期都愿意配合；卡了一次，第二天就会去家长群说"学校非让我们下 App"。

24.4 熄灯之后：那一晚王师傅在做什么

王师傅晚上 22:35 从系统首页上看了一眼"5 层今日未打卡 3 人"——不是他主动去敲的门，是系统自动考勤时间窗结束后给他的一条待处理清单。

他拿着手电上楼，逐间轻敲门：512 里陈昊指了指靠窗那张床说"他肚子疼去校医院了"。王师傅回到值班室，在系统里给李洋的当晚记录补一条备注"因病去校医院"、把状态从"未打卡"改为"已请假（校医院）"——这条记录不是替代请假审批链，是给考勤当日做兜底说明。李洋第二天回来在移动端补提一份"就诊请假"申请，走完整审批链；系统对这两条记录都保留、按 (人员, 业务日) 唯一约束自动合并显示为"当日不在宿舍：因病因由 + 已发起请假"。

第一晚对王师傅来说也是一样的——他以前查寝靠腿、记本子、第二天问同事；现在他先看屏幕再决定去不去。这套系统对王师傅的第一晚价值：让他少爬两次楼、让他能证明"那晚我去过 512"、让他知道那个 4 号床的孩子后来有没有销假。

24.5 系统对第一晚能承接什么、不能承接什么

能承接：

• 入住登记、状态切换、留痕；
• 五路来源的考勤打卡与自动合并；
• 报修、请假、调宿、消息通知；
• 与同学的联系方式（同房间友按权限可见）；
• 学校配的入住须知与外部服务链接。

不能承接（这些是学校自己的政策与人的温度）：

• 李洋想家的那通电话——系统不接管；
• 室友因为空调温度第一次小摩擦——系统不接管；
• 宿舍里该不该买共用垃圾桶这种约定——学校自己定；
• "第一晚给爸妈报平安"的通知文案怎么写——学校自己拟，系统只负责送达。

这套系统的边界感是它最诚实的地方。它把所有能自动化的动作做完，然后退开一步——第一晚真正让李洋觉得"这学校还行"的，多半不是系统，是那个递钥匙时说了句"热水壶在走廊左头"的王师傅。

24.6 给学校的一件事

新生入住那天，你派一个人在 3 栋大厅跟王师傅并肩坐两小时。记录学生问王师傅最多的三个问题：

• 如果这三个问题里有两条以上系统能提前答（消息、公告、字段、地图）——说明你的第一晚前段做得还行；
• 如果三个问题全都是"我空调怎么用"、"水卡去哪充值"、"洗澡要不要抢"这类具体生活问题——说明你在系统里配的是"分配与考勤"，不是"一个学生的第一晚"。

系统的第一晚指标不是"分配准确率 100%"，是"学生问王师傅的次数从五个降到两个"。这件事不需要供应商做什么，需要学校自己在上线之前把每个宿舍里可能遇到的 20 个小问题的答案先写进公告栏与图文指引里。