# 真实项目反推分析 — 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`。