121 lines
2.8 KiB
Markdown
121 lines
2.8 KiB
Markdown
# 迭代工作流与四步法
|
||
|
||
**版本：** 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 可以稳定接手迭代文档工作。
|