Commit 4c6d232556a9dbe9bddaedec93ca013ad998a2f7
1 parent
7ead6ef4
feat(prd-planning): 把训练出的 PRD 方法论手工套进生产本体，真实回归验证有效
在 prd-planning/agent.md 加了「描述性语言扫描」+「内容深度下限」+「业务度量翻译」三段 具体操作（对应 36 号文档训练出的 SKILL.md Step 4/5），soul.md 加一条对应工作原则。 用同一个 e2e-demo 首页任务重新跑了一次端到端回归验证：新 PRD 把"大图/简洁大气"等形容词 逐条翻译成量化规则，最终产出的 index.html/style.css 精确对应这些数值（视觉元素 min-height:320px、区块间距 96px/56px 等），文案不再卡在"非空"这条线——训练效果在 真实任务里得到验证。 回归过程中发现一个新的、独立于本次改动的引擎缺陷：org-coder-test 被反向打回后产出 「建议重跑 org-coder-validator」的诊断文件，引擎把诊断文件里的 infra_flake 标记当成 了这个节点自己的执行结果，导致原地重跑但从不路由到诊断建议的目标节点，陷入没有熔断线 的确定性死循环。记进 30 号文档，留待后续修复。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Showing
4 changed files
with
73 additions
and
1 deletions
docs/README.md
| ... | ... | @@ -47,7 +47,7 @@ Graph Agent 架构重构（27 系列）。**已完成的阶段文档已移入 `d |
| 47 | 47 | | [27-p4-parallel-and-artifacts.md](./todo/system-design/27-p4-parallel-and-artifacts.md) | **P4（回收编号）并行执行与产物索引** — 📝 设计中，未实现。fan-out 真并发 + 同 agent 多实例隔离 + `files.json` 产物索引。三个 Phase，C 可插队 | |
| 48 | 48 | | [28-followups.md](./todo/system-design/28-followups.md) | 28 号（Agent 注册表统一）的遗留清单 — 主文档已在 `done/`，这份装没做完的：dream 机制（设计见 29 号，已实现，见下）、`source_kind`（✅已删）/`legacy_path`（不能删）删列、三项「已实施未验证」。任务态清理（✅已实现，见下）。§五 是**已立起来的守卫清单**（别重复造，也别删） | |
| 49 | 49 | | [29-dream-design.md](./todo/system-design/29-dream-design.md) | **dream（经验汇流）**— ✅ 已实现。定时整理所有 agent 在所有公司的记忆，提炼后跨公司沉淀（不泄漏公司信息）。四条取舍已拍板并实现：去敏独立判定、四落点分层写入（经验/`SKILL.md`/`soul.md`/`agent.md`，受管区块+三道闸门）、每日定时（串行+空转保护）、引用真伪自动查、REST+控制台入口（`/api/dream/*`、`/dream`）。`innovator-evolver` 真 CLI 跑通一次。**仍缺的**：「结论对不对」只能人抽查；「套进 org/work graph 来跑」评估后用户选了不做（作用域不匹配，见文内 §5.7） | |
| 50 | -| [30-task-delegation-reliability-gaps.md](./todo/system-design/30-task-delegation-reliability-gaps.md) | **任务委派可靠性现状**— 📝 调研记录，非设计方案。DevLoop `runUnit`、Company 招聘装配、Graph 执行三条链路核对结论一致：都是「失败预算耗尽 → 停等人工」，没有「卡住了主动通知人」这一层；DevLoop 当前还默认走 mock，真实 CLI 成功率无实证数据 | | |
| 50 | +| [30-task-delegation-reliability-gaps.md](./todo/system-design/30-task-delegation-reliability-gaps.md) | **任务委派可靠性现状**— 📝 调研记录，非设计方案。DevLoop `runUnit`、Company 招聘装配、Graph 执行三条链路核对结论一致：都是「失败预算耗尽 → 停等人工」，没有「卡住了主动通知人」这一层；DevLoop 当前还默认走 mock，真实 CLI 成功率无实证数据。2026-08-23 追加真实实例：`infra_flake` 原地重跑没有熔断线，真撞上过一次确定性死循环（节点把诊断结论误判成自己的执行结果，反复重跑却从不路由到诊断建议的目标节点），比本文档原先的模式更隐蔽——连"卡住"本身都不容易从节点状态看出来 | | |
| 51 | 51 | | [31-work-graph-fail-fallback-coverage.md](./todo/system-design/31-work-graph-fail-fallback-coverage.md) | work graph 兜底边覆盖不全 — ✅ 已完成（除入口节点外强制兜底边，`planner.json`/`executor-fanout.json` 补 6 条边），978/978 单测通过；2026-08-21 又用真实 LLM 起了一条新任务做端到端回归验证，`org-planner-sdd` 自判失败后自动打回 `org-planner-prd`（3 次，零人工介入），修复确认生效 | |
| 52 | 52 | | [36-prd-agent-methodology-training-feasibility.md](./todo/system-design/36-prd-agent-methodology-training-feasibility.md) | 📝 **调研 + 阶段一/二均已完成**。回应"落地页太单薄是不是该用 Innovator 先训练专业 agent、再用 Dream 持续迭代"——认同方向。**阶段一**：`graph-engine.js` 结算节点后把 `success`/`fail:<reason>` 写进本体 `memory.md`（此前只有人类对话路径会写，Dream 天天空转）。**阶段二**：新建独立试验节点 `prd-methodology-trial` 走真实 Hunt→Digest→Evolve，2 轮收敛（96/97 分，真实基线 50 分），三个真实历史项目反推验证方法论有效；过程中连带修复同一个 2026-08-16 改名批次遗留的 5 处 `innovator`→`org-innovator` 死链（后端两处硬编码、前端"重新训练"按钮、`/api/agent/list` 展示 id 来源的四个 `config.json`），以及 `AgentScaffold` 默认模板一处裸相对路径缺陷。结论：FDE 对方法论类角色确实管用，但收敛速度/验收严谨度依赖任务书显式写明的自纠正要求，非免人工黑盒。环节 3（训练产物 → 雇佣本体转换）尚未开工 | |
| 53 | 53 | | [35-validation-rigor-and-body-readiness-proposal.md](./todo/system-design/35-validation-rigor-and-body-readiness-proposal.md) | 📝 **复盘 + 改进方案，四条提案全部已实施**。承接 31/32/33/34 号的复盘结论：任务结果差主要是架构问题（完整性闸门 `missingBodyDefinition` 只在招聘时查、图执行侧完全没有第二道防线——新发现）+ 一个具体的招聘装配可靠性 bug，不是 agent 能力问题。提案 A：本体不完整时图执行前置判 `fail_reason=body_not_ready`，不扣预算。提案 D：`goal-contract.js` 的 `evidence_hint` 命中浏览器类关键词的维度必须有证据支撑，否则判不过。提案 C：新增 `scripts/visual-acceptance-check.mjs` 复用检查工具。提案 B：控制台「验收证据」小节展示每个维度有没有证据支撑 | | ... | ... |
docs/todo/system-design/30-task-delegation-reliability-gaps.md
| ... | ... | @@ -79,6 +79,37 @@ |
| 79 | 79 | |
| 80 | 80 | --- |
| 81 | 81 | |
| 82 | +## 四、2026-08-23 追加：`infra_flake` 原地重跑没有熔断，真撞上过一次无限循环 | |
| 83 | + | |
| 84 | +**背景**：36 号文档阶段二把训练出的 PRD 方法论手工套进 `prd-planning` 后，起了一条新的 | |
| 85 | +e2e-demo 端到端回归验证效果，跑到 `org-coder` 子图时撞见：`org-coder-test`（`unit-tester`） | |
| 86 | +被 `org-coder-validator` 的 `missing_required_input` 失败反向打回后，没有走"重测实现"这条 | |
| 87 | +常规路径，而是自己产出了一份 `validator-triager/v1` schema 的诊断文件（判断被测站点本身没问题， | |
| 88 | +问题出在 `org-coder-validator` 那次运行自身的输入解析，建议"只重跑 org-coder-validator"）—— | |
| 89 | +这份诊断文件里带着 `fail_reason: "infra_flake"` 字段，**被引擎当成了 `org-coder-test` 这个节点 | |
| 90 | +自己的执行结果**，触发 `routeFailure` 里 `infra_flake` 的"原地重跑，不烧 attempt、不烧 | |
| 91 | +backward_count"分支。因为每次重跑产出的诊断内容都一样（同样的真实检查、同样的结论）， | |
| 92 | +陷入了确定性死循环：`unit-tester` 被反复调用产出同一份"该重跑 validator"的建议，但引擎 | |
| 93 | +从不读它 `target_node` 字段、只会一遍遍重跑产出诊断的那个节点本身——`org-coder-validator` | |
| 94 | +真正在等的那次重跑永远不会发生。观测到时已经循环 4 次以上，`spent.agent_calls` 涨到 35/100， | |
| 95 | +`wallclock` 逼近预算上限。 | |
| 96 | + | |
| 97 | +**跟本节 §三"共性模式"的关系**：`infra_flake` 这条自愈路径本身是为"基础设施抖动"设计的 | |
| 98 | +（§四.D.2.1），特意**不计入**失败预算/backward_count，理由是"这不是节点自己的错，不该烧 | |
| 99 | +它的重试额度"——但这也意味着它是**唯一一条没有熔断线的失败路径**：`LOOP_HARD_CAP_RUN`/ | |
| 100 | +`LOOP_HARD_CAP_EDGE` 管不到它，只有任务级总预算（agent_calls/tokens/wallclock）能兜底， | |
| 101 | +而这次真实撞到的循环恰好会一直产生"看起来正常"的诊断内容，不会被识别为异常，直到把 | |
| 102 | +预算耗光——是本节"卡住了没人主动通知"这条共性模式里最隐蔽的一种：连"卡住" | |
| 103 | +本身都不容易从节点状态一眼看出来（`ready`↔`fail`↔`ready` 快速循环，轮询间隔稍长就会 | |
| 104 | +误判成"在正常推进"）。 | |
| 105 | + | |
| 106 | +**没有当场修**（这次实测是手动叫停 + 转去直接读实际产出物评估，绕过了这个节点，没有改 | |
| 107 | +`graph-engine.js` 的 `infra_flake` 处理逻辑）。真要修，方向大概两个：① `infra_flake` 加一层 | |
| 108 | +"连续 N 次产出内容雷同"的去重熔断；② 让 `routeFailure` 认得这类"triager"schema 里的 | |
| 109 | +`target_node` 字段，真的路由过去而不是重跑产出诊断的节点本身——后者更像是把 `org-coder-test` | |
| 110 | +临时客串"triager"这个用法本身该不该存在的问题，需要先搞清楚这条 backward 边的设计意图 | |
| 111 | +是"重测"还是"诊断转发"，不确定的情况下不要贸然改引擎通用逻辑。 | |
| 112 | + | |
| 82 | 113 | ## 参考 |
| 83 | 114 | |
| 84 | 115 | - DevLoop 阶段现状：[27-graph-agent-architecture.md](./27-graph-agent-architecture.md) | ... | ... |
system/agents/prd-planning/agent.md
| ... | ... | @@ -65,6 +65,36 @@ brd-planning → prd-planning → sdd-planning → goal-benchmark → planner-va |
| 65 | 65 | 下游会照着多做一轮，烧的是同一个 root run 的预算池。 |
| 66 | 66 | - BRD 的每条 `success_metrics` → 至少一条 PRD 行为规则能支撑它被测出来。 |
| 67 | 67 | |
| 68 | +### 类别 4 的具体做法：描述性语言扫描 + 内容深度/业务度量翻译 | |
| 69 | + | |
| 70 | +（2026-08-23 补：source 见 `docs/todo/system-design/36-prd-agent-methodology-training-feasibility.md` | |
| 71 | +阶段二训练——真实案例 `run_c7d233619784/nodes/rn_42eed93342c5/prd.md` 证明"四类东西字面写全" | |
| 72 | +不保证内容够格：正文写了"大图"，验收线索表却没有一行提图片，产出实测 0 个 `<img>` 标签； | |
| 73 | +文案只要求"不能为空"，产出卡在刚好非空的水平；BRD 的转化类 `success_metrics` 从未被翻译成 | |
| 74 | +任何 CTA 功能。下面两步专门堵这个口子，**写正文的同一时刻就顺手做**，不要写完全部正文再回头补。） | |
| 75 | + | |
| 76 | +**描述性语言扫描**：逐句重读你写下的正文（尤其"视觉风格"/"体验"段落），标出所有描述性/ | |
| 77 | +形容词性用语（大 / 丰富 / 精美 / 有吸引力 / 简洁大气 / 专业 / 现代感 / 高级感 / 有质感……）。 | |
| 78 | +对每一个，当场二选一： | |
| 79 | +1. **转成量化代理指标**：例"大图"→"页面存在 ≥N 个宽度 ≥XXXpx 的图片/插画元素，图片区域 | |
| 80 | + 占卡片可视面积 ≥M%"；"大留白"→"区块间垂直间距 ≥N px"。实在找不到合理代理指标，走 2。 | |
| 81 | +2. **删词改写**：把形容词删掉，换成本来就该写的具体规则——这往往说明这句话本来就该是 | |
| 82 | + "行为规则"而不是风格描述。删词改写不是退而求其次，是更诚实的选择（不做兑现不了的承诺， | |
| 83 | + 本身就是一种可以拿高分的真实路径）。 | |
| 84 | +做完的标准：正文里找不到一个还没对应量化判据、也没被删掉的形容词性词语。 | |
| 85 | +（纯功能性需求正文本身零描述性词汇的，确认后跳过这一步，不要为了走流程硬造视觉要求。） | |
| 86 | + | |
| 87 | +**内容深度下限**：凡涉及文案/说明性内容的功能（标题/简介/说明文字/空状态提示……）， | |
| 88 | +不能只写"不能为空"。至少二选一：给最小字数/字符数区间；或要求内容包含至少一个具体 | |
| 89 | +名词/数据/场景化描述（"很棒的产品""专业可信赖"这类不含具体信息的套话不算数）。 | |
| 90 | + | |
| 91 | +**业务度量翻译**：回头看 BRD 的 `success_metrics`，凡出现转化/体验类表述（访客要不要 | |
| 92 | +行动、要不要在多长时间内做出判断、点击/注册/购买/留资/引导/说服）——问自己："功能清单里 | |
| 93 | +有没有一条能直接指出来的具体功能在承接这条度量？"指不出来就**在功能清单里新增一条** | |
| 94 | +（常见形式：CTA 按钮 + 明确跳转目标），不要指望验收线索表能补救。新增的功能同样要过 | |
| 95 | +"输入→输出确定映射"这道关——"跳转到某个锚点"不精确到具体锚点 ID，等于为了补这里 | |
| 96 | +在别处开了新口子。BRD 不含转化/体验类度量的，显式写一句"本条不适用"，不要留空。 | |
| 97 | + | |
| 68 | 98 | ### 说不清就别硬写 |
| 69 | 99 | |
| 70 | 100 | 上游契约缺关键项、或 BRD 与 task-goal 明显对不上时，**不要编一份看起来完整的 PRD**。 |
| ... | ... | @@ -168,5 +198,9 @@ attempt-{n}.json ← 本轮回执，引擎读它判本节点成功/失败 |
| 168 | 198 | 7. traceability 是真能逐条回扣的，还是我为了好看编的？ |
| 169 | 199 | 8. 有 remediation_note 的话，「下一轮必须」几条我逐条做完并写进 addressed[] 了吗？ |
| 170 | 200 | 9. contract.json 我这一轮完整重写了吗？attempt-{n}.json 的 n 是本轮 attempt 号吗？ |
| 201 | +10. 正文里还能不能找到一个没对应量化判据、也没被删词改写的形容词性词语（大/丰富/精美/ | |
| 202 | + 有吸引力……）？找得到就是没做完"描述性语言扫描"。 | |
| 203 | +11. 文案类功能是不是只写了"不能为空"？BRD 的转化/体验类 success_metrics 有没有一条 | |
| 204 | + 能直接指到具体功能承接（不是"这几条加起来大概覆盖"）？ | |
| 171 | 205 | </thought> |
| 172 | 206 | ``` | ... | ... |
system/agents/prd-planning/soul.md
| ... | ... | @@ -28,3 +28,10 @@ BRD 说"è¦è§£å†³ä»€ä¹ˆé—®é¢˜"，SDD 说"æ‰“ç®—æ€Žä¹ˆé€ "，ä¸é—´é‚£å¥**"é€ å‡ |
| 28 | 28 | |
| 29 | 29 | 6. **å¯è¿½æº¯ä¼˜å…ˆäºŽå¥½çœ‹**：`traceability` é‚£ä¸€æ ¼æ˜¯ `planner-validator` 第一个查的。 |
| 30 | 30 | 编一份对ä¸ä¸Šå·çš„追溯表，比ä¸å†™è¿˜ç³Ÿâ€”—它会让审查者放æ¾è¦æƒ•ã€‚ |
| 31 | + | |
| 32 | +7. **形容è¯ä¸æ˜¯éœ€æ±‚，è¦ä¹ˆé‡åŒ–è¦ä¹ˆåˆ 掉**：写下"大图""简æ´å¤§æ°”""有å¸å¼•åŠ›"这类è¯çš„那一刻， | |
| 33 | + 就该当场决定它对应一æ¡ä»€ä¹ˆæ ·çš„å¯ç¼–程判æ®ï¼›ç»™ä¸å‡ºæ¥å°±åˆ 掉æ¢æˆå…·ä½“规则，ä¸è¦ç•™åœ¨æ£æ–‡ | |
| 34 | + 里指望验收线索表事åŽå…œä½ã€‚四类东西å—é¢å†™å…¨ä¸ç‰äºŽå†…å®¹å¤Ÿæ ¼â€”â€”çœŸå®žäº‹æ•…ï¼ˆ2026-08-23 | |
| 35 | + è®ç»ƒé˜¶æ®µéªŒè¯ï¼Œè§ 36 å·æ–‡æ¡£ï¼‰è¯æ˜Žè¿‡ä¸€æ¬¡ï¼šæ£æ–‡å†™äº†"大图"，验收线索å´ä¸€è¡Œæ²¡æ，产出 | |
| 36 | + æœ€åŽ 0 å¼ å›¾ç‰‡ï¼Œå…¨ç¨‹æ²¡æœ‰ä¸€æ¥æŠ¥é”™ã€‚åˆ è¯æ”¹å†™ä¸æ˜¯å¦¥å，是更诚实：ä¸æ‰¿è¯ºå…‘现ä¸äº†çš„东西， | |
| 37 | + 本身就是一ç§èƒ½æ‹¿é«˜åˆ†çš„真实路径。 | ... | ... |