第六章　我们的不一样

前五章说完了学生变了、思路要换、谁来换、方向在哪、底线是什么。剩下的问题只有一个：具体到这套系统，哪些地方和常见做法真的不一样。

九条里前六条是软件功夫，第七八条是形态与态度，最后一条才是智能化主张——顺序本身就是立场：先比功夫，再比花样。 每条差别都配一个当场能核对的动作，因为说得出"演示时点哪里、交付时查什么"的才叫差别，说不出来的只能算宣传。

6.1 唯一事实源：一个人只有一条记录

常见做法是按部门建表。招办一份录取表、学工一份报到表、宿管一份分床表、财务一份缴费表，靠人工定期合并。合并那天就是不一致开始的那天。

我们的做法是所有业务挂在同一个学生主记录上：53 类业务数据、35 个任务类型 × 4 种任务形态，最终都指向同一个人。他在系统里只有一个身份、一份进度。学院、批次、组织通过授权范围切视图，不复制数据。

这一条学校最容易验：现场指定一名新生，请对方在三分钟内答出他此刻差哪两件事没办、这几件事分别由哪张表说了算。答不出来，或者要回办公室查，就说明没有唯一事实源。

6.2 源头拦错：不靠当天格外细心

常见做法是把校验放在人工环节：导入后打印名单、让学院自己核对、报到现场再核一遍。

我们的做法是把拦错前移进系统。16 个导入入口里，最容易出错的宿舍与楼栋两类已支持"先校验、不写入"——上传一份表，系统返回一份与真实导入完全一致的结果：哪些行会成功、哪些行会被拦下、拦下的原因是什么。新生基础信息这类主入口的错误回执给的是行号和原因（哪个字段、第几行、为什么不行），其余入口的回执格式还在统一。值域收敛做了一半：性别的"男"与"1"、"女"与"0"归到同一标准值，民族由归一工具统一，写成"male"的值今天会被置空而不是报错——这一格缺口在第七章有完整说明。唯一性冲突当场拦下并给出冲突明细，不留"先导进去再手工清理"的余地。身份核验是另一道硬关口：证件读取、号码比对、人像比对三样串成一条完整链路，阈值默认 80 分、连错 10 次锁定转现场人工，全程留痕，已生产验证，并含 4 所学校的定制变体。这一项的边界也要说清：识别与比对算法由第三方服务提供，系统负责的是流程、阈值、留痕与降级到人工的那一段。

带一份故意做坏的表格去演示就能见分晓——手机号少一位、同一学号重复两行、性别列挪到最后一列。看系统是把错误行拦下来并说清原因，还是默默导进去，然后留给你自己找。

6.3 配置化是生死线

这一条不是加分项，是决定这套系统能用几年的东西。理由很直接：迎新需求每年都在变，改一次就要厂商排期开发，第二年就没人敢改了。

我们的做法是把任务、字段、流程、提醒规则都做成配置：动态字段字典带着跨系统映射位、一个批次可挂多个自定义任务实例、种类与类型多对多组合。效果体现在交付曲线上——首校 60 人日、第五校 40 人日、第十校 25 人日。

现场提一个真实变更就能试出配置化的深浅，比如"把绿色通道的时间从三天改成五天，并给未提交的学生多加一次提醒"。看这是后台点几下就能改完，还是要回去提需求单。

6.4 扛得住集中洪峰

第一章说过，全部准备要在四十八小时兑现。洪峰不是比喻，是几千人同时抢同一批床位。

我们的做法是在选宿这类高并发场景做并发保护，开学季数千人同时选床已生产验证，不超卖；体检预约的集中时段同样经过生产验证。业务上这意味着床位这类稀缺资源不会出现"两个人抢到同一张床"，报到日不需要有人去处理这种纠纷。

直接问一句"你们承载过的最大一所学校，报到当天同时在线多少人，有没有出过重复分配"。答得出数字、也答得出处理方式的，才谈得上验证过。

6.5 数据只属于学校

"数据二十条"把数据资源持有权、加工使用权、产品经营权分置，落到迎新这一段的判断很清楚：学校是持有方，厂商是受托处理方。

我们把它写成三条硬约束：这批数据只属于学校；学校随时可以完整导出；每一次导出的发起都有记录可查。 一校一实例，本校数据不与别校混存。定制功能单独成支，不污染主干，所以学校要带走的是自己的全部配置与数据，不是被版本绑住。导出前的审批流与文件水印随批次补齐（见第十三章），这一段先说清楚，免得学校拿着一句"出得有名有姓"去对现成的功能。

要求演示"导出这一届全部新生的完整数据"，并当场打开看格式。只能给专有格式、或者要走厂商流程才能导出的，等于数据不在学校手里。

6.6 把能挪出那两天的事都挪走

削峰不靠通知，靠把环节前置。

预报到阶段在家填完、在家确认、在家选床；手机选号付费的变体已生产验证；宿舍意向、问卷、物品预订、走读申请（含家长签名）、党团转接、档案接收、医保参保、户口迁移，这些"入学必办但常被漏掉"的事都放到到校之前。到校那两天只留必须现场做的动作——核验身份、核对材料、领取物品。

拿自己学校去年的报到现场流程清单，逐条问一句"这一项能不能提前两周在手机上完成"。能提前而没提前的每一项，都是报到日的排队人数。

6.7 用他们的形态给信息

第二、三章说过学生怎么获取信息，对应的做法也要说清楚。

三个前端合计 207 个页面（管理端 108、移动端 73、学院端 26），学生端以卡片与一屏待办为主，不是一堆附件。管理侧是一个统一数据大屏，分 8 个视角：迎新总览、报到指挥、宿舍全景、缴费看板、体检监控、出行调度、趋势分析、竞赛榜单。它的价值不在好看，在"哪个环节卡住了多少人"这句话第一次有据可说。

消息这一层的范围要说明白：落地的是站内消息记录与发送管理，以及"体检预约成功即刻生成个人通知"这条自动链路；短信与微信两类外部通道、与任务引擎联动的自动触达、频控、静默时段与一键退订，属于按批次建设的内容，具体机制在第十一章展开。主动推送一旦没有频次约束就等于自废，所以这几条是随通道一并设计，不是先上线再补。家长端做轻量，隐私边界先定清楚，不把所有信息都摊给家长看。

最直观的检验还是那个：把自己学校的入学通知材料用手机打开一遍，算一下看完要多久、有多少内容跟自己无关。这个体感就是评分。

6.8 让数据替学校说话

前七条是"办事"，这一条是"判断"，也是第四篇的全部内容。

我们主张的智能化不是对话能力，是四类人工做不到、数据做得到的判断：识别卡点（不是报到率 78%，而是"卡在绿色通道的 213 人里 134 人卡在材料上传"）、预测与调度（按到站时刻算逐小时到校曲线，反推该派几路车、开几个窗口）、风险预警（未报到线索、应助未助线索、资格复查异常聚集，只提示有权责的人）、决策沉淀（把今年的曲线和基线回写成明年配置）。

同时把边界写死：智能层整体可关，底座不依赖模型；写操作要过权限、留审计、进事务；不可逆的事一律不交给机器——不发资助、不做处分、不改学籍、不代替本人核验与签字。

演示时请对方当场回答一句："如果现在关掉 AI 功能，你们的报到还能不能正常跑完。"这个问题能干脆回答的，才说明智能层是加层，不是危楼。

6.9 这些不一样最终指向一件事

九条摆在一起，看起来是工程清单。但它们指向的是同一个问题，而且不是技术问题。

第一章说过，学生判断一所学校，不会去读培养方案，他只看这几个月和这两天被怎样对待。所以这九条对学校真正的意义是：这套系统上线之后，学校能不能在新生面前当场证明自己跟得上时代。

每一条都在回答同一个疑问：这所学校是把我当成一个需要被登记的人，还是一个需要被接住的人。

功能列表可以复制，把一件事做到能被当场验收的程度，才是差别。