plan-risks.html
8.8 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
<!doctype html>
<html lang="zh-CN">
<head>
<meta charset="utf-8" /><meta name="viewport" content="width=device-width,initial-scale=1" />
<title>风险与待决 · LemonBoss PRD</title>
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link href="https://fonts.googleapis.com/css2?family=Fraunces:opsz,wght@9..144,300;9..144,500;9..144,700&family=Inter:wght@400;500;600;700&family=JetBrains+Mono:wght@400;500;700&display=swap" rel="stylesheet" />
<link rel="stylesheet" href="assets/shell.css" />
</head>
<body data-page="plan-risks.html">
<div class="shell">
<aside id="sidebar"></aside>
<main class="page">
<header class="page-head">
<div class="crumb"><span class="pill">08 · PLAN</span><span class="sep">/</span><span>风险与待决</span></div>
<h1>风险与待决</h1>
<p class="deck">列出 7 个最值得在动工前讨论清楚的风险点。每条给出对策或留作待决的备选方案。</p>
</header>
<article class="body">
<section>
<h2>风险全表</h2>
<table>
<thead><tr><th>ID</th><th>风险</th><th>影响阶段</th><th>对策状态</th></tr></thead>
<tbody>
<tr><td>R1</td><td>无限循环(L2 改 SDD → 又失败 → 再改)</td><td>P3</td><td>✅ 有预算</td></tr>
<tr><td>R2</td><td>Agent 把 Bash 玩坏(inline JSON)</td><td>P2 起</td><td>✅ 已写入 prompt</td></tr>
<tr><td>R3</td><td>集成测试套件谁来写</td><td>P3</td><td>✅ 初版方案 A</td></tr>
<tr><td>R4</td><td>PRD/SDD 的 HTML diff 算法</td><td>P4</td><td>⚠️ 初版粗粒度</td></tr>
<tr><td>R5</td><td>与现有 EvolutionLoop 的关系</td><td>P2</td><td>✅ 抽公共函数</td></tr>
<tr><td>R6</td><td>跨 Unit 的命名 / 约定漂移</td><td>P3</td><td>✅ Architect 强制后缀</td></tr>
<tr><td>R7</td><td>Token 成本失控(无限 retry × Opus)</td><td>P2 起</td><td>⚠️ 需配置全局上限</td></tr>
</tbody>
</table>
</section>
<section>
<h2>逐条展开</h2>
<details class="acc" open>
<summary>R1 · 无限循环风险<span class="role">P3</span></summary>
<div class="inner">
<p><b>场景:</b>L2 失败 → 改 SDD → 再失败 → 再改 SDD…</p>
<p><b>对策:</b>三层预算守护</p>
<ul>
<li>每 unit retry ≤ 5 次(L1 内)</li>
<li>每 PRD rev 内 L2 修复轮次 ≤ 3 轮</li>
<li>BugTriager confidence < 0.5 立即上报 L3</li>
</ul>
<p>超出 → 项目挂起,发 SSE,等人类介入。绝不静默丢弃。</p>
</div>
</details>
<details class="acc">
<summary>R2 · Bash 中 inline JSON<span class="role">P2 起</span></summary>
<div class="inner">
<p>参见 <code>CLAUDE.md</code> L91-99。所有需要带 JSON body 的命令必须先写 <code>/tmp/*.json</code> 再 <code>curl -d @file</code>。</p>
<p><b>对策:</b>
<ol>
<li>在 Coder / Tester / Integrator 的 system prompt 中强制声明铁律</li>
<li>沙箱层 hook 检测 <code>-d '{...}'</code> 模式直接拒绝</li>
<li>Bash 工具增加 <code>jsonGuard</code> middleware(约 30 行)</li>
</ol>
</p>
</div>
</details>
<details class="acc">
<summary>R3 · 集成测试谁来写<span class="role">P3</span></summary>
<div class="inner">
<p>三种方案对比见 <a href="loops-l2.html">L2 页 · 集成测试套件从哪来</a>。<b>初版选 A:Architect 同步产 integration/spec.json</b>,理由:</p>
<ul>
<li>少一个 Agent,少一次握手</li>
<li>spec 与 SDD 同源演化,不会脱节</li>
<li>Architect 已经 Opus,能力够</li>
</ul>
<p>若 P3 实测发现 Architect 写 spec 质量差,回退到方案 B 单独加 IntegrationAuthor。</p>
</div>
</details>
<details class="acc">
<summary>R4 · PRD/SDD diff 算法<span class="role">P4 · 待决</span></summary>
<div class="inner">
<p>HTML 结构化 diff 比纯文本难。<b>初版策略:</b>section 级粒度,按 <code>data-rev</code> 属性区分新旧(每个 section 要么完全新,要么完全旧)。这避免文本级 diff 算法的复杂度。</p>
<p><b>已知限制:</b>同一 section 内修改不会高亮,只能整段标 changed。</p>
<p><b>P5+ 升级:</b>引入 <code>diff-dom</code> 做精细化 inline diff。但需要先看 P4 实测是否够用。</p>
</div>
</details>
<details class="acc">
<summary>R5 · 与 EvolutionLoop 的关系<span class="role">P2</span></summary>
<div class="inner">
<p>EvolutionLoop(在 <code>packages/evolution/</code>)负责 Skill 进化,是另一套独立系统。DevLoopController 负责工程化代码开发。<b>两者不交叉</b>。</p>
<p>唯一耦合:<code>retryWithReflection()</code> 抽到公共包供两者共用。从 <code>evolution-loop.js</code> 抽出约 80 行代码,外部接口保持不变。</p>
</div>
</details>
<details class="acc">
<summary>R6 · Unit 命名漂移<span class="role">P3</span></summary>
<div class="inner">
<p>BugTriager 输出 affected_units 是 string[],靠字符串匹配 UnitRegistry。如果不同轮 Architect 用 <code>auth-be</code> / <code>auth-backend</code> / <code>auth-server</code> 三种风格,归因会丢。</p>
<p><b>对策:</b>Architect 强制后缀(参见 <a href="agents-architect.html">Architect · ④ Unit 拆解策略</a>)。Schema 校验同时强制 <code>id =~ /^[a-z]+(-[a-z]+)*-(be|fe|mw|db)$/</code>。</p>
</div>
</details>
<details class="acc">
<summary>R7 · Token 成本失控<span class="role">P2 起 · 待决</span></summary>
<div class="inner">
<p>5 次 unit retry × 多 unit × 3 次 L2 修复 × Opus 模型 = 单项目可能烧几十刀。</p>
<p><b>对策:</b>
<ul>
<li>project.json 加 <code>token_budget</code> 字段(默认 5M tokens / 项目)</li>
<li>LoopController 每次 callAgent 后累计,超出立刻挂起</li>
<li>Tester 默认 Haiku(最便宜)</li>
<li>Dashboard 实时显示已用 token 与剩余预算</li>
</ul>
</p>
<p>具体阈值由 P2 实测 token 消耗后再定。</p>
</div>
</details>
</section>
<section>
<h2>开放问题</h2>
<p>以下是<b>没在本 PRD 给答案</b>的问题,需要在 P1 启动会前敲定:</p>
<ol>
<li><b>多人项目 / 协作:</b>同一项目能不能两个人同时发 L3 反馈?目前默认是「队列化」,但 UI 怎么显示?</li>
<li><b>代码归宿:</b>项目 shipped 后,<code>units/*/code/</code> 要不要自动提个 GitHub PR?还是留在 LemonBoss 文件系统里?</li>
<li><b>跨 Unit 共享库:</b>R6 提到的 <code>shared/</code> 在 P1~P4 留空。但「auth utils 给所有 Unit 共用」是个真实需求,要不要提前到 P3?</li>
<li><b>外部依赖(npm 包)安装权限:</b>Coder 跑 <code>npm install</code> 安装新包是否允许?目前默认禁,但很多前端 Unit 实际需要。</li>
<li><b>失败后人工 takeover:</b>项目 blocked 后,人类能否在 Dashboard 里<b>手动编辑</b>某个 Unit 的代码再 resume?这要不要算 L3 的一种 action?</li>
</ol>
<p class="sig">这五个问题不阻塞 P1 启动,但建议在 P3 前给答案。</p>
</section>
<section>
<h2>下一步</h2>
<div class="callout">
<b>动工前最后一关:</b>你(Yibo)读完整套 PRD,回复以下三个 yes / no:
<ol>
<li>三层 Loop 的边界划分是否准确?特别是 L2/L3 之间的「失败时先修文档」是否同意?</li>
<li>六个 Agent 的拆分粒度可以接受吗?有没有应该合并或拆细的?</li>
<li>四阶段排序 P1→P4 是否合理?是否要把 UI 提前?</li>
</ol>
</div>
<p>都 yes → 开 P1 PR。任一 no → 回来改这份 PRD 再说。</p>
</section>
</article>
<nav class="prev-next"></nav>
<footer class="site"><div><b>Section</b>08 · Plan</div><div><b>Page</b>plan-risks.html</div></footer>
</main>
</div>
<script src="assets/shell.js"></script>
</body>
</html>