AI 协作工程化终篇：高可靠工作流的代价，串行、台账与可演进性
把 AI 协作做成状态机、台账、质量门和证据链之后，流程会比“一个 Agent 从头做到尾”慢一些。这个结论不需要回避。工程化从来不是免费获得控制力，而是在速度、一致性、可解释性和维护成本之间选择合适的平衡。
本系列的核心观点不是“所有 AI 任务都应该走完整流程”，而是：当任务开始影响代码、需求范围、用户行为或团队协作时，必须把关键不确定性从对话记忆迁移到可验证的系统边界中。
这套设计真正买到了什么
| 机制 | 直接收益 | 解决的原始问题 |
|---|---|---|
| 单活工作单 | 恢复时负责人唯一 | 中断后靠聊天猜进度 |
| Controller 单写 | 状态原子、路由可预测 | 多角色互相改共享状态 |
| 结构化 Return | 交付可解析、旧消息可忽略 | 自然语言结论无法消费 |
| 追溯链与任务提交 | 变更、验证、回滚可定位 | “需求完成”没有事实边界 |
| 三层审查 | 计划、实现、目标分别验证 | 一次 Review 承担过多结论 |
| 冻结测试契约 | 测试结果可复跑、来源明确 | “已经测过”无法复核 |
这些收益共同指向一个能力：失败后仍能说明系统相信什么、为什么相信、下一步该由谁处理。
代价一：关键决策必须串行
一个需求只有一个活跃工作单，意味着设计、开发、审查不能同时修改同一事实版本。对于小改动，这会显得“流程太重”；对于范围不清、跨模块或高风险需求，它恰好防止并行修改制造更多不确定性。
可以用两层并行来平衡：
原则很简单：竞争同一事实解释权的动作串行；只读搜集、互不共享写入边界的动作可以并行。不要因为拥有多个 Agent 就同时启动多个“事实 Owner”。
代价二：Markdown 台账需要模式治理
Markdown 的优点是人能读、版本库能审、需求目录携带即用；缺点是它不是数据库。表头拼错、列数不一致、旧字段缺失，都可能让控制面失真。
因此，使用 Markdown 台账不能只靠约定。至少需要：
- 明确表结构、字段权限和稳定 ID 格式。
- 写入前做机械化结构校验。
- 对可确定的旧表头按列名规范化，拒绝未知或歧义结构。
- 让正文承载完整解释，台账只保存短字段与稳定引用。
当需求数量、并发写入者或跨系统查询显著增加时，台账也应有升级路径：例如把控制面迁移到数据库或事件存储，但仍保留 Markdown 作为可阅读的事实投影。关键不是存储介质，而是单写、版本和引用语义不能丢。
代价三：协议要持续维护
每增加一个角色、一个台账字段或一种打回路径，都会让协议更复杂。最危险的做法是把新规则散落在各个 Skill 的自然语言描述中，最后没有人知道路由和权限的唯一来源。
较稳妥的演进方式是：
- 将路由、Return 形状、字段权限放在中央契约中。
- 角色 Skill 只声明自己读取什么、写什么、在什么条件下暂停或交付。
- 为 Controller 的历史兼容、路由和结构校验准备可重复的离线验证。
- 每次修改协议都补充反例：旧 Return、重复 Return、缺少 focus、字段不兼容时系统应如何表现。
协议不是写完即结束的文档；它是一项需要测试的产品接口。
代价四：不是每个场景都值得完整流程
适合完整状态机的典型场景包括：跨多个代码仓库、涉及权限或数据迁移、需要用户确认、必须保留审计链、预计会有多次返工的需求。
相反，拼写修正、独立 bug 定位、一次性资料整理、纯只读解释，不应被强行塞进五阶段生命周期。流程的价值来自约束真实风险，而不是让所有请求看起来更正式。
| 场景 | 推荐强度 | 原因 |
|---|---|---|
| 跨模块业务需求 | 完整流程 | 范围、任务和验收都可能变化 |
| 涉及数据或权限的改动 | 完整流程 | 回滚与证据需求更高 |
| 单文件、低风险修复 | 轻量开发与验证 | 完整台账成本可能超过收益 |
| 只读代码解释 | 查询流程 | 不应产生工作单和状态写入 |
| 独立验收测试 | 手动测试能力 | 产出测试事实，不直接裁决生命周期 |
收尾：把智能放在判断，把确定性放在边界
AI 的价值在于理解输入、发现问题、提出方案和辅助执行；系统边界的价值在于防止这些能力在中断、并发、历史演进和责任切换中变得不可解释。两者不是替代关系。
一个成熟的 AI 协作系统，不是让模型拥有更多权限，而是让每一份权限都对应一个可验证的责任、一条可追溯的证据和一条可恢复的路径。流程因而会多一些约束，但团队会少一些“到底是谁改了、为什么通过、现在该怎么办”的猜测。
系列导航：