Verbatim · 人类原话
「我需要一个能实现自动化对代码进行需求整理成 HTML 格式的 PRD、SDD，然后按照 docs 的分解的功能列表，挨个 Unit 开发完成前后端代码，并实现 Unit Test，形成 Unit Loop。当所有 Unit 开发完成，则实现 Integration Test 集成测试。如果集成测试有 Bug，则修改最早期的 PRD、SDD 文档，然后再开发各自的 Unit，实现 Unit 开发测试，然后再集成测试。实现一个小 Loop (Unit) 和一个大 Loop (Integration) 两层的 Loop 的自动化开发流程。然后人类的需求和反馈形成第三层 Loop——人类发送一个新的需求，更新到 PRD 文档中，然后依据 PRD 修改 SDD，再增量 Unit、Integration 开发，直至功能开发完成。」
结构化解析 · 6 条硬约束
| ID | 约束 | 系统侧承诺 | 对应 Agent / 组件 |
|---|---|---|---|
| R1 | PRD / SDD 必须是 HTML 格式 | 新 DocStore：HTML 模板 + section 级补丁 | PM · Architect |
| R2 | SDD 含可机读「功能列表」 | SDD 同步产 units.json（DAG 索引） | Architect |
| R3 | Unit 级前后端代码 + Unit Test | 每 Unit 触发 Coder → Tester | Coder · Tester |
| R4 | 全部 Unit 通过 → 集成测试 | LoopController L2 闸门 | LoopController · Integrator |
| R5 | 集成失败 → 回写 PRD/SDD → 再跑 Unit | BugTriager 归因 → Architect 应用 patch → 受影响 Unit reset | BugTriager · Architect |
| R6 | 人类新需求 → 增量重跑 | POST /api/devloop/requirement，PM 增量更新 PRD | PM |
三个隐含约束（用户没说但必须有）
H1 · 收敛性
无论哪一层 Loop，都必须有「全局 retry 预算」，避免死循环。
H2 · 可观测性
人类要能随时看到「现在卡在哪一步、哪个 Agent、哪个 Unit」。否则 L3 反馈失去意义。
H3 · 文档可追溯
每个 rev 的 PRD/SDD 都要归档，能 diff 出本轮反馈引入了什么变化。
用户原话 → 设计映射
把上面这段话从左到右画成「需求 → 设计」对照流：