# 迭代工作流与四步法

**版本：** 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 可以稳定接手迭代文档工作。