风险与待决

列出 7 个最值得在动工前讨论清楚的风险点。每条给出对策或留作待决的备选方案。

风险全表

ID	风险	影响阶段	对策状态
R1	无限循环（L2 改 SDD → 又失败 → 再改）	P3	✅ 有预算
R2	Agent 把 Bash 玩坏（inline JSON）	P2 起	✅ 已写入 prompt
R3	集成测试套件谁来写	P3	✅ 初版方案 A
R4	PRD/SDD 的 HTML diff 算法	P4	⚠️ 初版粗粒度
R5	与现有 EvolutionLoop 的关系	P2	✅ 抽公共函数
R6	跨 Unit 的命名 / 约定漂移	P3	✅ Architect 强制后缀
R7	Token 成本失控（无限 retry × Opus）	P2 起	⚠️ 需配置全局上限

逐条展开

R1 · 无限循环风险P3

场景：L2 失败 → 改 SDD → 再失败 → 再改 SDD…

对策：三层预算守护

• 每 unit retry ≤ 5 次（L1 内）
• 每 PRD rev 内 L2 修复轮次 ≤ 3 轮
• BugTriager confidence

超出 → 项目挂起，发 SSE，等人类介入。绝不静默丢弃。

R2 · Bash 中 inline JSONP2 起

参见 CLAUDE.md L91-99。所有需要带 JSON body 的命令必须先写 /tmp/*.json 再 curl -d @file。

对策： 1. 在 Coder / Tester / Integrator 的 system prompt 中强制声明铁律 2. 沙箱层 hook 检测 -d '{...}' 模式直接拒绝 3. Bash 工具增加 jsonGuard middleware（约 30 行）

R3 · 集成测试谁来写P3

三种方案对比见 L2 页 · 集成测试套件从哪来。初版选 A：Architect 同步产 integration/spec.json，理由：

• 少一个 Agent，少一次握手
• spec 与 SDD 同源演化，不会脱节
• Architect 已经 Opus，能力够

若 P3 实测发现 Architect 写 spec 质量差，回退到方案 B 单独加 IntegrationAuthor。

R4 · PRD/SDD diff 算法P4 · 待决

HTML 结构化 diff 比纯文本难。初版策略：section 级粒度，按 data-rev 属性区分新旧（每个 section 要么完全新，要么完全旧）。这避免文本级 diff 算法的复杂度。

已知限制：同一 section 内修改不会高亮，只能整段标 changed。

P5+ 升级：引入 diff-dom 做精细化 inline diff。但需要先看 P4 实测是否够用。

R5 · 与 EvolutionLoop 的关系P2

EvolutionLoop（在 packages/evolution/）负责 Skill 进化，是另一套独立系统。DevLoopController 负责工程化代码开发。两者不交叉。

唯一耦合：retryWithReflection() 抽到公共包供两者共用。从 evolution-loop.js 抽出约 80 行代码，外部接口保持不变。

R6 · Unit 命名漂移P3

BugTriager 输出 affected_units 是 string[]，靠字符串匹配 UnitRegistry。如果不同轮 Architect 用 auth-be / auth-backend / auth-server 三种风格，归因会丢。

对策：Architect 强制后缀（参见 Architect · ④ Unit 拆解策略）。Schema 校验同时强制 id =~ /^[a-z]+(-[a-z]+)*-(be|fe|mw|db)$/。

R7 · Token 成本失控P2 起 · 待决

5 次 unit retry × 多 unit × 3 次 L2 修复 × Opus 模型 = 单项目可能烧几十刀。

对策： - project.json 加 token_budget 字段（默认 5M tokens / 项目） - LoopController 每次 callAgent 后累计，超出立刻挂起 - Tester 默认 Haiku（最便宜） - Dashboard 实时显示已用 token 与剩余预算

具体阈值由 P2 实测 token 消耗后再定。

开放问题

以下是没在本 PRD 给答案的问题，需要在 P1 启动会前敲定：

1. 多人项目 / 协作：同一项目能不能两个人同时发 L3 反馈？目前默认是「队列化」，但 UI 怎么显示？
2. 代码归宿：项目 shipped 后，units/*/code/ 要不要自动提个 GitHub PR？还是留在 LemonBoss 文件系统里？
3. 跨 Unit 共享库：R6 提到的 shared/ 在 P1~P4 留空。但「auth utils 给所有 Unit 共用」是个真实需求，要不要提前到 P3？
4. 外部依赖（npm 包）安装权限：Coder 跑 npm install 安装新包是否允许？目前默认禁，但很多前端 Unit 实际需要。
5. 失败后人工 takeover：项目 blocked 后，人类能否在 Dashboard 里手动编辑某个 Unit 的代码再 resume？这要不要算 L3 的一种 action？

这五个问题不阻塞 P1 启动，但建议在 P3 前给答案。

下一步

动工前最后一关：你（Yibo）读完整套 PRD，回复以下三个 yes / no：

1. 三层 Loop 的边界划分是否准确？特别是 L2/L3 之间的「失败时先修文档」是否同意？
2. 六个 Agent 的拆分粒度可以接受吗？有没有应该合并或拆细的？
3. 四阶段排序 P1→P4 是否合理？是否要把 UI 提前？

都 yes → 开 P1 PR。任一 no → 回来改这份 PRD 再说。