宜博 / lemonboss

real_project_reflection.md 10.2 KB

真实项目反推分析 — p-pyjha7 / p-bkhylu / p-v1mpcl

目的：不用虚构场景替代验证，而是用三个真实历史项目的实际交付物反推"如果当初 PRD 按 SKILL.md 方法论写，会有什么具体不同"。p-v1mpcl 无法定位到完整 PRD，本文档如实记录 这个发现本身（见三），不牵强附会一份不存在的分析。

一、p-pyjha7（lemonboss 产品官网首页）— 核心案例，已按 benchmark_v1.md §5 深度分析

定位：PRD data/companies/e2e-demo/runs/run_c7d233619784/nodes/rn_42eed93342c5/prd.md， 产出 data/companies/e2e-demo/projects/p-pyjha7/{index.html,styles.css,script.js}。 真实得分 50 分（待改进，封顶后），D5=3/D6=1。

具体反推：哪一句话会怎么改写，改写后会发生什么

原句（PRD §2 行为规则）："整体页面采用大字体、大图/大留白排版...不使用密集小字或拥挤布局。"

按 SKILL.md Step 4（描述性语言扫描），这句话里的"大图"必须当场决定：转成量化代理指标， 或删词改写。本次训练的 iteration_1_draft_prd.md 选择了前者，改写为：

"每个卖点区块必须包含至少 1 个插画/图标元素，尺寸 ≥120×120px（移动端）/ ≥200×200px（桌面端）， 或占区块可视面积 ≥25%"

改写后验收线索会怎么变：原 PRD §4 验收线索表五行里"大图"完全没有对应行；改写后§5 新增 一行"视觉-大图"，要求 DOM 中存在 <img>/<svg> 节点且尺寸达标，可用 getBoundingClientRect() 核验。

产出预计会有什么不同：goal-benchmark/planner-validator 按新验收线索表验收时， coder 若不放置任何图片元素会直接验收不过——这与真实历史形成直接对照：真实产出 index.html 全站 0 个 <img> 标签（已用 grep 核实），正是因为验收线索表没有承接这句话， coder 没有强制动机放图。如果当初 PRD 用这套方法论写，p-pyjha7 的真实产出大概率会至少 包含 3 个（每区块 1 个）插画/图标元素——不是猜测，是因为验收链路本身会因为多了这一行 判据而拦下"零图片"的实现。

另一处反推：BRD success_metrics"访客几十秒内判断是否是要找的产品"（转化类）在原 PRD 里从未被翻译成任何功能。按 Step 5B，本次训练在 iteration_1 新增了 F-4（CTA 入口按钮）。 产出预计会有什么不同：真实产出全站没有一个可点击的"了解更多/联系我们"入口；如果按 方法论新增 F-4 并配上验收线索"DOM 中存在可点击 CTA 节点+可点击热区≥44×44px"，产出会 多出一个明确的转化入口，这直接对应 D6 判据 B 从原稿 1 分可能提升到接近满分的路径。

二、p-bkhylu（lemonai.ai 产品介绍页）— 正面对照案例

定位：PRD data/companies/e2e-demo/runs/run_9168bd24f46c/nodes/rn_129f6b7d610a/prd.md， BRD 同 run nodes/rn_fb9937458d67/brd.md，产出 data/companies/e2e-demo/projects/p-bkhylu/{index.html,styles.css,app.js,DELIVERY.md,assets/img/}。 本次由子任务深读全文并按 benchmark_v1.md 逐维度打分（过程见下），实测得分 89.4 分（优秀）。

逐维度实测

维度 得分 关键依据
D1 5 F-1~F-10 每条都在同一行内直接配一个数值化验收线索（视口 390/768/1440/320/2560、耗时≤600ms、对比度≥4.5:1），没有"支持XX"式的空洞条目
D2 5 E-1~E-9 覆盖五类相关场景，E-4 把"越权"显式改写为"本页面无数据采集"并给出静态无登录页的理由，命中5分档"不适用+理由"标准
D3 4 绝大多数判据可脚本化（DOM计数/scrollWidth/对比度公式/boundingBox()，且 DELIVERY.md 显示这些确实用 Playwright 跑过），仅 F-3"每节标题只出现1个卖点主张"仍需人工语义判断，命中4分档
D4 5 §4 traceability 表逐条覆盖 4 条 in_scope，out_of_scope 全部显式列出未涉及，全文零技术栈词汇（技术选型显式留给SDD）
D5 4 见下"关键发现"
D6 4 判据B（业务度量翻译）满分：BRD 体验类目标（"访客10-60秒内看懂是什么/为什么"）被 F-2（首屏必须同时可见产品名+一句话卖点+主CTA，不需滚动）+ F-9（CTA 必须产生明确点击反应，不允许死链接）具体承接；判据A（内容深度）未完全达标：没有最小字数/信息密度门槛，但 F-7 要求"文案必须全部来自 lemonai.ai 真实内容，禁止编造"——比"不能为空"这条底线更严格，属部分满足

关键发现：D5=4 不是靠"承诺大图+验收线索兜住"，而是靠"根本不做兑现不了的视觉承诺"

对全文 grep「图/插图/视觉/大留白/丰富/有吸引力」，只命中两处：B-10（"如果展示图形元素， 必须是自制的，不能照搬 apple.com 的视觉"，这是一条约束句不是"要丰富"的承诺句）和 E-7 （图片加载失败兜底）。这份 PRD 正文从未出现"大图""图文并茂"这类词——它没有对着"视觉 丰富"这个不可控的目标下承诺，D5 高分是靠"克制表述、不承诺兑现不了的东西"拿到的， 不是本次训练原本设想的"承诺了→验收线索兜住了→产出因此丰富"这条正向证据链。

产出实测：index.html 里 <img> 标签计数为 3，均为 class="card__icon" width="40" height="40" 的小图标，不是主视觉大图——与这份 PRD 自身的克制表述完全吻合，是"PRD 写多少、产出就是多少" 的一致性证据，而不是"PRD 要求丰富视觉→产出真的丰富"的证据。

这对 SKILL.md 的修正意义：Step 4 目前的默认路径是"转成量化代理指标"（方案1）， "删词改写"排在方案2。p-bkhylu 案例说明当描述性词语本身缺乏可操作的量化路径、或团队没有 真实素材去兑现它时，删词改写往往是更诚实的选择，不是退而求其次的选项——已在 SKILL.md 附录A补充这条使用提示（"实在找不到合理量化代理时优先删词改写，不要硬造脱节判据"）， 本次真实案例进一步验证了这条提示的必要性：p-bkhylu 正是选择了"不承诺"路线并因此拿到高分， 证明这条路径在真实场景里确实可行、确实能拿到D5高分，不是本方法论臆造的兜底选项。

三、p-v1mpcl（taskId T-mt1qx0c4-95bf）— 如实记录：PRD 链路不完整，是管线缺陷，不是内容质量问题

结论先行：这个项目不存在可评分的 prd.md，原因不是"我没找到"，而是 timeline.ndjson 记录了一次被 planner-validator 明确抓到的真实管线缺陷。不为凑够3个完整案例编造分析。

证据链（run data/companies/e2e-demo/runs/run_d06717f10e5d/）：

  1. Attempt 0：org-planner-brd → org-planner-prd → org-planner-sdd → org-planner-benchmark 四个节点均自报 status: success，但 planner-validator（rn_585862b456b5）验收时发现 artifacts/ 目录下只有 goal-benchmark.json/project-root.json/task-goal.json， brd/prd/sdd 三份规划产物一份都没有真正写盘——节点自报成功和实际产物存在与否脱节， 验证的原文措辞是 verdict: "attributed", fail_reason: "impl_bug"。这是一个实现层 bug， 不是 PRD 内容质量问题。
  2. Remediation 触发重跑 prd + sdd，sdd 重跑因为拿不到 PRD 立即失败为 input_underspecified， 阻塞了整条子图。
  3. Attempt 1（当天 23:44-23:50 左右）：brd-planning 重跑这次真的写出了 brd.md （即本次调研找到的那份）；但 prd-planning（rn_7506589eea5d）重跑后 contract.json 导出的字段是 site_entry/site_assets/sections/screenshot_mockups/grounding_sources， 直接指向成品网站文件（index.html/style.css/script.js），没有 prd_path 字段—— 这个节点这一轮压根没有产出散文形式的 PRD 文档，而是折叠成了一份"网站结构规格"， 与最终交付物本身高度重合甚至可能被交付物覆盖。
  4. 次日（2026-08-21T09:36:10）org-planner 节点以完全相同的 remediation 文案再次失败/阻塞， sdd/benchmark/validator 及下游两个节点全部被标记 skipped——这个 run 最终没有走完 brd→prd→sdd→benchmark→validator 的完整闭环就终止了。

产出文件确实存在（index.html 8/21 00:43 生成，style.css/script.js 8/21 07:49 生成）， 但只能追溯到 brd.md 和 prd 节点那份"网站结构规格"，找不到独立的 sdd.md，timeline 里 也没有独立的 coder 节点执行记录——BRD→PRD→SDD→coder 这条链路对这个项目没有以常规 形态跑完。

这个发现对训练本身的意义：SKILL.md 是解决"PRD 内容质量"这一层问题的方法论， 但 p-v1mpcl 暴露的是更上游的一类失败——规划节点自报成功但产物没有真正落盘——这与 D1-D6 任何一个维度都无关，是内容评分体系生效之前就该被拦住的问题。建议记录为 SKILL.md 之外的独立发现，供 org-innovator 判断是否需要在 DevLoop 引擎层（而非 PRD 撰写方法论层）补一道"产物存在性"前置校验，不属于本次训练范围，不在 SKILL.md 里 处理这条。

四、三案例合并结论

  1. p-pyjha7 证明：结构完整（D1-D4 接近满分）不保证内容不单薄，根因是正文描述性用语 没有对应验收线索，SKILL.md Step 4 直接针对这个根因设计，本次训练的 iteration_1 反推 显示按方法论重写后可以把这个真实反例的模拟得分从 50 拉到 96（见 iteration_1_scores.json）。
  2. p-bkhylu 证明：D5 高分不必然来自"承诺视觉丰富+验收线索兜住"，也可以来自"不做兑现不了 的承诺"——这补充了 SKILL.md Step 4 方案 2（删词改写）在真实场景里的可行性证据， 而不只是理论上的兜底选项。
  3. p-v1mpcl 证明：内容质量方法论解决不了所有问题——存在一类管线层面的"规划产物没有 真正落盘"缺陷，这类问题在 D1-D6 评分体系生效之前就已经发生，如实记录、不纳入 SKILL.md。