AI 协作工程化 03：让设计可执行，从需求点到代码提交的追溯链
“完成需求”是一个过于宽泛的说法。它可能表示写完方案、提交了代码、跑过测试，或者只是认为功能看起来合理。只要这些表达没有落到稳定对象上，审查者就无法知道哪里被实现、哪里没有实现、某次回滚会影响什么。
可执行设计的关键不是文档写得多，而是把不同阶段的事实连成一条短而完整的链路：需求点、设计项、任务、执行、审查和验证都能相互定位。
把抽象目标分解成稳定对象
一条常用的最小链路可以这样定义：
RP（需求点）
-> DES（设计项）
-> TASK（可独立交付的任务）
-> execution（实际执行）
-> review（实现审查）
-> acceptance（需求验收）每一层都回答不同问题。
| 对象 | 核心问题 | 不应该承担的责任 |
|---|---|---|
| RP | 用户要获得什么效果，边界是什么 | 具体文件怎么改 |
| DES | 采用什么方案、影响哪些对象 | 提交如何拆分 |
| TASK | 哪个最小改动可独立实施、验证、回滚 | 汇总整个需求的进度 |
| execution | 代码和验证实际发生了什么 | 修改需求目标 |
| review | 证据是否支持通过或打回 | 替代开发或设计 |
这不是为了给文档编号，而是为了给每个判断留下一条可验证的来路。
TASK 是交付边界，不是待办事项
很多计划中的“任务”其实是模块名，例如“改订单模块”或“补充接口”。这种任务无法独立验证，也无法安全回滚。一个合格的 TASK 至少需要界定：允许改动的范围、预期行为、验证方式、失败处理和回滚边界。
可以用一个简单的判断题检验粒度：
如果只撤销这个 TASK 的提交，系统是否仍能回到一个可解释的状态？
如果答案是否定的，它可能只是一个大任务中的步骤；如果答案肯定，但与其他改动没有共享不可分割的不变量，它就应该保持独立。
让 Git 提交成为证据的一部分
一个 TASK 最好对应每个受影响仓库中的一笔本地提交。提交信息或正文包含 TASK-* 和关联 RP-*，开发记录再记录分支、提交引用、实际 diff 范围和验证结果。
这不是要求所有提交都要“好看”，而是让审查可以落在事实层：
- 计划说要改哪个入口，diff 是否真的覆盖该入口？
- 当前提交有没有混入其他需求或用户已有改动？
- 回滚时能否定位仅属于这个 TASK 的修改？
- 后续修改替代旧实现后，旧审查结论是否还适用？
如果没有代码变更，例如纯验证重跑或证据补充，也应明确记录“无新增本地提交”和原因。虚构一个空提交只会污染追溯链。
覆盖范围和修复范围必须分开
审查最容易犯的错误，是把发现问题的局部集合误当作整个审查范围。正确做法是同时保留两组信息：
- 覆盖范围：本次实际审查了哪些需求点、任务和执行记录。
- 精确修复集合：其中哪些对象必须由下游行动。
例如，一个实现审查覆盖了 TASK-011 和 TASK-012，只发现 TASK-012 的错误。审查报告应保留完整覆盖范围，但 Developer 的行动范围只应是 TASK-012。否则要么丢失 TASK-011 已经被审查的事实，要么诱发不必要的全量重做。
事实更新后，证据也有有效期
追溯链不是静态的。如果同一 TASK 的实现被重新执行，原来的代码 diff 和验证证据可能已经不代表当前实现；对应的审查行需要显式失效或被新事实替代。反过来，追加需求也不应改写旧需求点，而应创建新对象并保留旧链路作为兼容背景。
这就是为什么“最新一段报告说通过了”不够。验收要检查的是：每一条当前有效 execution，是否仍有适用于它的通过审查链。
常见的断链方式
| 断链方式 | 为什么危险 | 修正方式 |
|---|---|---|
| 需求点直接指向代码文件 | 跳过方案和任务边界 | 经 DES 与 TASK 建立中间语义 |
| 一个 TASK 包含多个独立改变 | 无法独立验证和回滚 | 按不变量与提交边界拆分 |
| 审查只写“已通过” | 无法知道通过什么 | 记录对象 ID、证据引用和范围 |
| 重做代码却保留旧审查 | 旧证据失效但看起来仍有效 | 用新 execution 和新 review 替代 |
小结
可追溯链不是项目管理负担，而是让“完成”变成可证明事实的最小结构。它让设计、代码、审查和验收都能回答同一个问题：这项需求是通过哪一组可复核证据被认为完成的？
下一篇把视角从对象链路转向质量机制：为什么设计、实现和验收不能合并为一次“统一审查”。
系列导航：