agent_ops/03.迭代规划/00.迭代方法/01.迭代工作流与四步法.md

迭代工作流与四步法

版本： 2026-08-07
适用范围： 所有后续 LineUp 迭代

1. 为什么要统一四步法

从 04A.agent_tool_route 开始，一次迭代不再只是某个前端仓的局部改动，而可能同时联动：

• Runtime
• Adapter
• AppServer
• 协议文档
• Host 验收
• 联调与证据

如果没有统一方法，很容易出现：

• 规划写在一个地方；
• 评审写在另一个地方；
• 技术规范散落在实现仓；
• 跨项目边界没有统一判断依据。

因此，从现在开始，每次迭代都至少经过四个固定步骤。

2. 固定四步

第一步：规划

目标：

• 说明为什么做这个迭代；
• 冻结范围边界；
• 说明涉及哪些项目和端；
• 给出完成标准和不在范围内的内容。

标准产物：

• 01.迭代规划.md

第二步：设计评审

目标：

• 用独立视角检查规划中的产品边界、架构边界、状态机和风险；
• 清理 P0～P3 问题；
• 把必须回填的结论反映回主规划文档。

标准产物：

• 02.设计评审.md
• 如有多轮，可继续编号：03.设计评审（二）.md、04.设计评审（三）.md

第三步：技术实施规范

目标：

• 把已经冻结的产品/架构结论映射到具体模块、协议、状态、存储、测试和验收实现；
• 明确每个项目各自承担什么修改；
• 说明跨仓联调和验证方式。

标准产物：

• 05.技术实施规范.md

第四步：技术实施规范评审

目标：

• 检查技术规范是否真实覆盖冻结边界；
• 识别实现层遗漏、跨仓接口风险、测试缺口和不可实施部分；
• 清理 P0～P3 技术问题。

标准产物：

• 06.技术实施规范评审.md
• 如有第二轮，可继续编号

3. 实施后的补充步骤

虽然用户当前强调的是四步法，但一个完整迭代通常还需要：

• 实施
• 验收评审
• 证据归档

因此建议默认继续补齐：

• 08.验收评审.md
• 09.验收评审（二）.md
• evidence/

4. 进入实现的门槛

每个迭代在开始大规模实现前，至少应满足：

1. 主规划文档已写明范围与完成标准；
2. 设计评审中的 P0～P3 已清零；
3. 技术实施规范已把跨项目责任拆开；
4. 技术实施规范评审中的 P0～P3 已清零。

5. 状态定义

建议统一使用以下阶段状态：

• 规划中
• 设计评审中
• 技术规范中
• 技术评审中
• 开发实施中
• 待验收
• 已完成
• 已归档

6. 这套方法的核心收益

• 让每次迭代都有统一入口；
• 让跨项目修改不再只挂在某一个代码仓名下；
• 让设计结论、技术规范和验收标准之间形成可追溯链路；
• 让后续 agent 可以稳定接手迭代文档工作。