AI 协作工程化 05：把返工变成协议，DRET 与精确修复集合
返工并不可怕，模糊返工才可怕。开发者说“方案有问题，麻烦重新看一下”，审查者说“这一批都需要再改”，看起来是在协作，实际把问题范围、已完成工作和下一步责任全都丢回了上下文。
在可审计的 AI 工作流中，返工不应是一句自然语言建议，而应是一种有编号、有状态、有关闭条件的协议。这里把 Developer 发起的“执行设计回交”简称为 DRET：它表示当前计划已经不能提供一条合法的执行路径，需要回到设计阶段补齐事实。
什么时候应该回交设计
Developer 不应把每个实现困难都升级为 DRET。能在既有计划内处理的编译错误、边界遗漏、测试失败，仍属于开发责任。只有当问题需要新的业务决策、会改变任务目标或边界、现有方案互相矛盾，才需要把它交回设计。
| 情形 | 正确处理 |
|---|---|
| 代码实现与计划一致，但测试失败 | 在当前开发工作单内修复与补证据 |
| 审查发现 diff 漏了一个已计划的调用点 | 回 Developer，按既有计划修复 |
| 设计没有定义失败状态如何呈现 | 建立 DRET，回 Designer 决策 |
| 外部接口约束与方案假设冲突 | 建立 DRET，回 Designer 修订方案 |
这个区分保护了两个边界：Developer 不把设计责任静默接走，Designer 也不被迫处理所有实现细节。
DRET 应该包含什么
一个可用的回交记录至少要说明：影响哪些设计项和任务、为什么当前计划不可执行、已经完成了哪些局部交付、哪些范围仍未完成。它必须是稳定事实，而不是会话里的临时解释。
id: DRET-001
state: open
design_ids: [DES-005]
task_ids: [TASK-011]
summary: 外部回调缺少失败状态契约，当前计划无法完成状态展示
reason_ref: development.md#dret-DRET-001
partial_product_refs:
- development.md#execution-TASK-011其中 partial_product_refs 很重要。返工不意味着已完成工作全部作废；它记录哪些局部事实仍然有效，避免 Designer 重新调查已经被验证过的内容。
回交的闭环不应由原作者关闭
一个常见但不可靠的做法，是 Designer 修改计划后直接把 DRET 标为已解决。问题在于：Designer 只能证明“我改了方案”，不能证明“方案已经经得起独立审查”。
更强的闭环是：DRET 由 Developer 创建为 open，Designer 修改正式设计，随后 Design Reviewer 对这次修改进行独立审查；只有审查通过，Controller 才关闭恰好这一组入站 DRET。
这个过程多了一道门，但换来了清晰的因果关系：开发发现的问题、设计的修订、独立审查的结论，三者都能定位。
覆盖范围不等于修复范围
返工协议最容易被误用的地方，是把“本次看到的所有对象”当作“下游都要重做的对象”。无论是设计审查、实现审查还是验收审查，都要区分两组集合。
- 完整覆盖集合：本次结论基于哪些对象形成，供审计和下一次审查读取。
- 精确修复集合：下一位角色真正需要修改、重新执行或重新验证的对象。
假设一个 Review 覆盖 TASK-011、TASK-012、TASK-013，只发现 TASK-012 的实现错误。报告可以保留三项覆盖，Return 的上下文也可以携带三项；但 Developer 只能被要求修复 TASK-012。重新送审时，再由新的审查事实覆盖完整有效范围。
为什么“统一打回全部”会破坏系统
| 做法 | 直接后果 | 长期成本 |
|---|---|---|
| 打回整批任务 | 开发范围被无谓放大 | 审查周期变长，误改风险上升 |
| 只记录发现问题的任务 | 其他已审对象从证据链消失 | 后续无法证明覆盖是否完整 |
| 回交时不记录局部交付 | 已验证工作被重复调查 | 返工越来越昂贵 |
| Designer 自己关闭回交 | 修订没有独立验证 | “文档已改”被误当作问题已解决 |
精确修复集合的目标不是让流程更复杂，而是让每一次返工都小到足以理解、实施和验证。
小结
DRET 把“计划不再可执行”从一句口头结论变成可追溯事实；精确修复集合把“需要改什么”从模糊批次缩小为明确对象。两者结合，才能让返工成为修复回路，而不是重新开始。
下一篇从返工回路转向测试：如何让验收声明变成冻结、可重复执行的测试契约，而不是一次性的聊天判断。
系列导航：