第四十一章　配置化交付与实施陪跑

先说清一件事："几万块、零驻场、学校自己就能用"这三个特点放在一起，不是便宜，是一种约束。

它意味着这套系统不能依赖有人长年守在甲方办公室里，意味着配置必须让学校的行政人员做得动，意味着每一次改动都不能要求厂商发版本。这套产品里很多看起来"不够炫"的设计，都是这个约束逼出来的结果。 而它的反面也要说清：同样的约束，决定了交付方式必须提前把学校该做的事说破——因为学校不会有人天天盯着这套系统，除了那两周。

交付的终点不是上线，是有人每天看数据。

41.1 交付即可用

一套系统上线时要现场开发的功能越少，第二年的存活率越高。这套产品交付时装箱带走的东西是明确的： 名册与组织架构、批次与任务装配、字段采集与自定义、分组定向与时间窗、缴费账单与绿色通道、宿舍与选宿、体检排期与预约、行程与接站、志愿者与代办、公告与图文单页、统计看板与八个视角的大屏、三端共二百多个界面、五十多张业务表与三十多项权限。

学校侧要做的不是开发，是三件事：定标准、给名单、排现场。第三十九章那张九十天倒排表讲的就是这三件事。

配置化不是"什么都不用做"。把"零开发上线"说成"零工作量"，是所有失败交付的共同起点。

41.2 一校一实例

这套系统的上线形态只有一种：一所学校一套独立环境，数据不与他人混存，不存在跨校汇总的那一张表。

三件事跟着这个形态来：

数据边界天然成立。 不需要在每一张表上加租户标识、不需要在每条查询里拼租户条件——这些机制一旦存在，就有写漏的那一处。 独立实例的隔离强度比"共享实例加行级过滤"高一个量级，这是选择它的首要理由。

并发保护可以做得很朴素。 选宿抢床位、体检抢号源这类"不能让两个人拿到同一个资源"的场景，用的是三层：进程内按床位和按人分别加锁、按固定顺序取锁防死锁、存储层的唯一性约束兜底，并把"是否已选"的判定放进同一把锁里。这层强一致之所以成立，前提就是一校一实例——不需要引入跨节点的协调机制。反过来也提醒一句：这套系统不按"多节点水平扩展"设计，规模再大的学校应该走"加配置、减现场峰值"的路子，而不是把一个实例拆成三台。

升级节奏是一所学校自己的事。 一套学校一套环境意味着升级要一所一所做，因此升级必须是可回退的、且不能要求学校停机太久。这也是新加功能很克制的原因之一。

41.3 定制不进主干

"能不能给我们学校单独改一下？"——每一家都会问。回答分两半：改什么，和改完谁负责。

三种承接方式，成本从低到高：

配置项承接。 主题色与标志、时间窗、任务开关、分组定向、采集字段、权限分配。这一层覆盖了绝大多数"我们学校不一样"的诉求，改完即生效，不占用任何人的排期。

字段与流程扩展承接。 动态字段引擎、任务的类型与先后关系、导入导出的列结构。这类改动仍然不需要动程序，但要走一轮变更确认，因为它会影响历史数据口径。

程序分支承接。 确实存在无法配置化的学校规则——比如某个学校的照片库主键和别人不一样、某个学校的号码要单独走一条业务线。目前这类分支是按学校名判定走向的，数量被严格控制。要说实话：这类改动会进主干，每多一处，系统的可维护性就降一分。 因此这条路上有一条明确的工程纪律——能收敛成配置项的，尽快收敛掉；把按名字判断走向的分支当成技术债，不当成功能卖点。

判断责任跟着这个逻辑走：一个供应商愿意主动告诉你"这个不该定制，应该改流程"，比答应所有定制要求更可信。

41.4 零驻场，是把责任交回学校

驻场人员的成本会一直挂在项目上，最后往往变成"学校自己不会用"的理由。这套系统的选择是零驻场，代价由产品设计承担：

• 所有日常操作都必须能在管理端网页里完成，不需要有人进后台改数据；
• 出问题必须能自助排查——作业列表写明失败原因、审计日志记录每一次写操作、存活探针与运行日志按天滚动保留；
• 权限必须细到"给一个学院的人开一个入口"，否则学工处会成为唯一的操作者。

零驻场不是"不管了"，是"不需要你管"。 学校侧需要有一到两个能日常维护的人，要做的具体事情就是现场保障那一节里列的三件。

41.5 人日曲线：为什么第十所最便宜

第三十九章给过这三个数：首校约六十人日，第五校约四十，第十校约二十五。 这里解释它是怎么降下来的——降的部分很具体：

首校花时间最多的是摸索学校流程：任务怎么排、字段采哪些、未报到原因归几类、哪个学院先试点。到第五所，这些问题都有了参考答案，实施人从"和用户一起想"变成"给用户看模板"；到第十所，标准件已经成型，实施人只做适配。

这条曲线对学校侧的意义是：交付报价里"定制开发"这一项应该很小。 如果一所新学校要的人日和第一所差不多，说明供应商还没把它做成产品，那这笔钱是在替别人交学费。

41.6 两条数据接入路

数据进来的路只有两条，各有各的适用条件。

第一条：文件导入。 名册、住宿分配、志愿名单、绿色通道、缴费项、任务分组名单……一共十六处入口，都是表格文件进、异步作业出，错误行带行号和原因。适合：一次性初始化、每年一次的批量替换、没有接口条件的第三方。

第二条：外部数据源直连。 支持四类常见数据源，只允许查询语句且禁多句拼接，字段映射与值映射在配置里定义，可定时增量。适合：学校已有学工或人事系统、要求权威数据不落地两份的情况。去重键是学校的唯一编号，不是身份证号——这是从旧系统沿用下来的做法，好处是和学校自己的编号体系一致。

还有一条补充路：接口回写。 需要把报到结果回给学工或教务平台时，按字段配置逐校适配。这条路的周期从来不由我们决定，由对方接口排期决定。

41.7 迎新季现场保障

每年最紧的那两周，现场要靠得住的东西是有限的、可数的：

系统不能崩。 分区限流按认证用户与匿名访问分别给额度，排队缓冲，超限明确拒绝——关键是限流判定在认证之后，整个宿舍楼共用一个出口地址的学生不会互相挤掉。存活与就绪探针按固定周期探测，异常明确返回。

数据不能丢。 每日全量备份、保留三十天，每周另有一份基础快照支撑时点恢复；并且有一份周期跑的恢复演练——自动把最近的备份还原到临时环境，比对表数量、关键表的行数和列数，用完即删。备份脚本不等于备份可用，这一步是真正区分"做了备份"和"能恢复"的地方。

长任务不能卡死。 大批量导入导出与同步走同一条作业队列，超时强制终止，服务重启时自动把上一轮没跑完的作业标记为失败并注明原因——不会出现"页面永远转圈"的状态。

出问题要能查到。 每一次写操作与敏感数据读取都有审计日志，系统日志按级别、类别、时间可查，导出名单留痕。

学校侧要做的对应三件： 报到日前一周做一次全量演练、当日安排一个能拍板的值守人、次日核对异常与未报到名单。

41.8 按角色培训：四套话，不是四份手册

不同角色只需要掌握各自的三件事，把所有人拉到一起培训是浪费时间。

给领导：一屏。 八个视角的大屏加一个总数，怎么切换、分母是什么、被追问时怎么答。二十分钟。

给干部（处长、院系副书记）：三件事。 批次与任务的装配、权限怎么发、统计怎么按学院专业班级拆。半天，含一次自己动手配。

给一线（辅导员、班主任、报到点工作人员）：一个流程。 从找人名、代办理、到核验收、到查日志。这是最重要的一场，也是第二年最容易忘的一场。

给志愿者：一个动作。 扫码，看结果。十分钟，报到日集合前讲。

需要说清楚一条边界：这套系统目前不附带面向学校的成册使用手册。 培训与现场陪跑是实施动作，上线后学校自己的操作说明、常见问题、流程指引，建议由学工处自己整理发布——系统里的图文单页与公告位就是放这些东西的地方，内容得学校自己写，因为写的人才是真正懂业务的人。

41.9 交接给学校的那三样东西

上线结束那天，真正要留在学校的不是账号，是三样东西。

口径。 那份指标字典：报到率叫什么、分母是谁、哪一项暂时算不出来。没有它，第二年新来的人会把同一件事算成两个数。

权限。 一份"哪个岗位开哪些入口"的分配表，附带两条原则：最小必要、导出必须二次确认。权限表是学工处的管理文件，不是厂商的配置项。

判断责任。 系统给出的所有预警、比对、分组与推荐都只是线索，签字的人永远是人。这一条要写成纸面约定，因为它决定了出事之后的责任边界——第二十二章划的那条界线，最终要落在这里。

41.10 选型时最常碰到的几个问题

"多久能上线？" —— 技术上很快，慢的通常是学校的三件事：名单什么时候到、收费标准什么时候批、字段口径谁定。把这三件事的日期定下来，上线时间自然就定下来了。

"要不要接我们现有的系统？" —— 不要求替换任何现有系统。能接，但接入范围越小越好：先接名册，跑一年再考虑别的。很多项目死在第一步就接了五个系统。

"我们没人懂技术，能维护吗？" —— 需要一个人会做这几件事：看作业状态、看日志、执行恢复演练、按学期调整配置。不需要专职的系统管理员，但如果学校连这一个人都出不了，建议先解决组织问题再谈采购。

"数据是我们的吗？" —— 实例独立、备份在学校手里、所有列表都能导出成表格文件。跨校比对这件事系统做不了，也不该做。

"你们有 AI 吗？" —— 有判断能力（卡点定位、比对打分、分组定向），算法和语言层依赖外部服务，不承诺自研模型——理由在第二十二章，此处只重复一句：把对话框当迎新门面，是把预算花在最好演示、最少人用的地方。

"能不能先在一个学院试点？" —— 可以，批次与组织授权天然支持收窄到一个学院。试点选数据最全的那一个，不要选领导最关心的那一个。

"三年后不用了怎么办？" —— 数据可以全量带走，迁移成本主要在字段口径的重新解释——这也是为什么前面说的交接三样，比软件本身更值钱。