第九章　任务引擎与配置化交付

交付成本能压下来，靠的不是压缩人力，而是一件更底层的事：一套引擎跑完所有迎新形态（35 类型 × 4 种类），新学校的需求不靠改程序。

9.1 两级任务模型：4 种任务种类 × 35 个任务类型

迎新的所有工作，最终都能落到"某个人要在某个时间前完成某件事"。系统把这层意思做成两级模型。

上面一级是任务种类，共 4 种：入学任务、报到任务、新生活动、新生学习。它对应的是学生所处阶段的分类。

下面一级是任务类型，共 35 个具体的事：信息采集、在线缴费、绿色通道、宿舍意向、选床、体检预约、军训服装、床上用品、党团转接、档案接收、保险、问卷、证件核验……它是学校真正会去勾选的那些事项。

为什么要分两级？因为学校说的"任务"和系统里的"任务"不是一个粒度。有的学校把缴费算一件事，有的要拆成"学费""住宿费""代管费"三件；有的学校体检在报到前，有的在报到后两周。两级模型让这两种学校用同一套引擎跑，不需要为其中一所改程序。

9.2 种类与类型是多对多的：同一件事可以出现在不同阶段

这一点是这套模型真正灵活的地方。

一个任务种类可以挂多种任务类型，同一个任务类型也能出现在不同阶段：入学任务下可挂 25 类，报到任务 10 类，新生活动 3 类，新生学习 5 类。

举个真实的例子。"证件照采集"这件事，在有的学校属于入学任务（在家就要上传），在有的学校属于报到任务（现场拍）；"体检"在有的学校挂在入学任务里做预约、在报到任务里做核验，同一个类型出现在两个阶段，各自有各自的时间节点和完成判定。

如果用一张固定的流程表来设计，这类需求就变成"要不要加个字段"的争论。多对多映射之后，它是配置里的一次勾选。选型时不妨把这个问题原样抛出去："同一件事能不能在入学阶段和报到阶段各出现一次？"答"能，配一下就行"和答"要变通处理"的，是两种系统。

9.3 自定义任务：一个批次可以挂多个实例

35 个类型不可能穷尽所有学校的需求。所以有自定义任务：学校自己定名称、自己定要采集哪些字段，而且一个批次可以挂多个实例。

"多个实例"这四个字很要紧。一所学校有三个校区、每个校区的领物安排不同，如果自定义任务只能挂一份，那三个校区只能共用一套要求，或者要人为拆成三个批次。支持多实例之后，它是同一批次下的三条配置。

再加上任务分组、时间节点、完成判定、任务日志这套配套，配置化的底座其实早就在了。

学校最特殊的那件事，恰好就是配置化的边界所在。一个只有本校才有的任务——比如"预交住宿费明细确认"，带两个自定义字段、只对本批次某个学院开放——能不能不改程序就配出来，直接决定明年加需求时要不要花开发费。

9.4 「迎新一件事」首页与线上办结率

任务引擎解决"能配"，接下来要解决"学生看得见、学校算得出"。

规划中的形态是把学生的待办做成一张卡片式的「迎新一件事」首页：这个学生此刻该办的几件事，一屏列清，办完一件少一件。对应的管理侧指标是线上办结率——所有必办事项里，有多少比例是在家就办完的，不是到窗口再办的。

这个指标的价值在于它把"错峰"这件事变成可量度的：办结率 70%，意味着到校现场要处理的事项少了七成；第二年做到 85%，报到日的人流压力就是可预期的下降。它比"我们支持线上办理"这种说法有用得多，因为前者可核对，后者只是表态。

对标来看，西安交通大学的"迎新一件事"已经做到除体检与领军训服外全部线上完成，服务 7407 名新生。这一形态我们按批次建设，落地之后学校拿到的就是上面那个可核对的指标。

9.5 个性化入学准备清单：这台引擎存在的理由

清单不是把 35 个任务全列给学生。

规划中的形态是按学生类型、学院、省份、是否住宿、走读与否，生成只有他相关的那几件事和一条时间轴：本地生源不该看到接站须知，走读生不该看到床品预订，参加了专项计划的学生该在靠前位置看到资助材料。

实现路径上有一条界线：这件事靠的是任务引擎的配置粒度与规则，不依赖模型。任务找谁、什么条件触发提醒、哪个人该看到哪一条，全是规则驱动的主动服务。第二章说"六条反转跟 AI 会不会聊天无关"，说的就是这样一件事——能不能做到"只给他那一条"，取决于配置能细到什么程度，不取决于模型有多大。

9.6 配置化底座早已存在

常被误解的一点：很多人以为配置化是要新做的能力。其实底座早就在了，而且不止一处。

• 自定义任务机制（名称、字段自定，一批次多实例）；
• 任务种类与任务类型的多对多映射；
• 字典分组机制：信息采集、服装尺寸、兴趣爱好、报到登记、走读申请各自独立成组，学校自行维护选项，改完即生效；
• 系统配置表支持分类与配置项管理，敏感项带标记；
• 连人脸比对的判定阈值、预检次数这类看起来最"技术"的参数，都是可配项，不是写死的常量。

这些机制本身不是新的。而机制在了一处没用、图快走了捷径，是一件不太好听但更要紧的事。

9.7 一次工程纪律的教训：定制必须与主干隔离

有一处教训必须摆在这里。

在服务客户的过程中，一共有 6 所学校和 1 家运营商的 8 处定制需求被直接写进了主干：其中 5 处是"按学校名走不同分支"，另外 3 处是把定制任务单独做成了独立入口或独立功能块。

后果不在当天，在之后每一次升级：主干里存着按学校名判断的分支，意味着每加一所新客户都要先确认历史分支会不会被误触发；意味着同一功能在不同学校行为不一致，排查问题时无法假设"大家跑的是同一套程序"；意味着我们前面讲的配置化，被这几处捷径架空了。

这件事的教训不是"不该做定制"——学校的真实差异必须被满足。教训是：机制已经在了，没被贯彻使用，图快就会欠债。

所以定制与主干隔离被列进交付批次，与跨校字段标准库、开箱即用的配置向导同组，目标是把每一处历史定制都收进单独分支，主干只留配置入口。新定制一律走扩展，不改主干。 这一条现在被当成工程纪律执行，而不是承诺。

反过来，一家供应商敢不敢把"按学校名判断的分支现在还有几处"这个数字摆出来，基本就能判断它是否把隔离当成纪律在管——答得出具体数字的，是在管；含糊过去的，是还没当成回事。

9.8 字段标准与复利：多所学校攒下来的东西存在哪里

服务过十几所学校之后，会攒下一样单校自研永远拿不到的东西：同一件事在不同学校叫什么、怎么写、取值范围是什么。

这份资产现在存在两个地方。一处在字典里——动态字段字典带着跨系统映射位，记着这个字段对应源表的哪一列、哪一张表，换一所学校接一个数据源，改的是配置不是程序；另一处在归一工具里——民族、行政区划、生源地这类值被收敛到同一个口径，"汉"与"汉族"不再算两类。

但还没攒成一套能自动比对的对照库。 到了第八所学校，列名与值域仍要人工确认一遍。这一段时间省不掉，不是多学校的积累没价值，是那本对照库还没建起来。把它建起来——已确认过的列名、值域、映射关系沉淀成跨校标准，新学校导入时先给出候选匹配，人只确认没命中的少数——是随批次要补的一项，也是交付曲线压到 25 人日之后下一个能压下去的地方。

已经压下来的那一截，靠的是配置化本身：首校 60 人日、第五校 40 人日、第十校 25 人日。省的不是写程序的时间，是每一所新学校都要重新弄清"这个字段到底是什么意思"的那部分沟通成本。

字段标准与值域收敛，是这套系统在服务更多学校之后本应自然增值的部分，也是第六章那句"功能列表可以复制，做到能被验收的程度才是差别"的具体含义。多接一所学校就更懂教育行业一分，前提是这些经验被沉淀成标准，而不是留在做过那所学校的人身上。

第二章那条"从一份通知给全校，到只给他那一条"，能不能成立，全看这台引擎的配置粒度够不够细。配置粒度决定了学校能不能把"接住每一个学生"从一句口号变成一条规则。 粗到只能按批次发，所有学生收到的还是同一份东西；细到能按人判断，第一章那四条塌陷才有真正的替代方案。这台引擎因此既是前面数据与身份的承接者，也是后面所有个性化主张能否兑现的前提。