初始化 agent_ops 文档治理体系

2026-08-07 16:56:51 +08:00
commit 10840909ab
75 changed files with 15750 additions and 0 deletions
@@ -0,0 +1,120 @@
+# 迭代工作流与四步法
+
+**版本：** 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 可以稳定接手迭代文档工作。