PRD 质量评分基准 v1 — prd-methodology-trial
生成者：innovator-digest（Phase 2 Digest） 输入：
../hunt/knowhow_v1.md（167行）+../hunt/sources.json（14条来源） 日期：2026-08-23 训练对象：「工程类方法论」技能（PRD 撰写质量评分），非爬虫抓取类技能
〇、设计前提（写给后续读者，避免误判本文档意图）
这套 benchmark 不是给 prd-planning 自己用的写作检查表——那份检查表已经存在，就是
prd-planning/agent.md 本身（knowhow §3 摘录）。这套 benchmark 回答的是一个更上游的问题：
一份字面上不违反 prd-planning 任何一条判据的 PRD，能不能保证下游产出不单薄？
knowhow §4 的核心发现是：答案是"不能"。e2e-demo 反面案例的 PRD 在结构完整性/可追溯性上
接近满分，但产出依然单薄，根因是"四类东西"检查表本身对内容深度/视觉丰富度/转化路径三类
维度没有覆盖。所以这套 benchmark 必须比 prd-planning 自查表多看一层——不只是"四类东西写全
了没有"，还要看"写全的东西够不够撑住产出天花板"。
一、最终维度设计（6 维度 + 权重）
| 维度 | 名称 | 判据来源 | 权重 | 所属组 |
|---|---|---|---|---|
| D1 | 功能清单可执行性 | knowhow §5-A1/A2，agent.md 表 #1/#2 | 20 | A（结构/可追溯） |
| D2 | 异常边界覆盖度 | knowhow §5-A3，agent.md 表 #3 | 12 | A |
| D3 | 验收线索可度量性（核心锚点） | knowhow §5-A4，agent.md 第16-17行+表#4 | 18 | A |
| D4 | BRD 可追溯性与技术中立性 | knowhow §5-A5/A6，agent.md 第29/63-65/121-122行 | 15 | A |
| D5 | 正文要求-验收线索映射完整性（产出天花板·主） | knowhow §5-B8，§4.3/§4.4 反面案例核心发现 | 20 | B（内容/天花板） |
| D6 | 内容深度下限与业务度量翻译完整性（产出天花板·辅） | knowhow §5-B7/B9 | 15 | B |
A 组合计权重 65，B 组合计权重 35——B 组不是点缀分：D5 单项权重(20)与 D1(20)并列全场最高， 理由见五、benchmark 自检——纯加权和曾经在自检中把 e2e-demo 这份"结构满分但内容单薄"的 PRD 打到 76.4 分（接近"合格"档），暴露了单纯加权和无法表达"天花板"语义的问题，因此在三、总分算法 里追加了封顶规则，不是靠调权重把分数硬压下去。
二、逐维度评分标准
判据来源里出现的行号引用均指
system/agents/prd-planning/agent.md原文行号（已在 §3 全文摘录核对）。
D1 功能清单可执行性（权重 20）
判据锚点（agent.md 第16-17行原文）："sdd-planning 拿着它能直接设计模块"。
| 分数 | 判据 |
|---|---|
| 5 | 每条功能都写清"谁/场景/做什么"且不可摊开成 ≥2 种不同实现；每条行为规则给出输入→输出确定映射+默认值（格式/顺序/编码等选项都写明） |
| 4 | 功能清单完整，但 1-2 条行为规则缺默认值或某个分支未穷举，不影响主路径可实现 |
| 3 | 至少 1 条功能可摊开成 ≥2 种不同实现（设计者需要额外猜测），或行为规则大面积只给了"支持 XX"没给输入输出映射 |
| 2 | ≥2 条功能存在歧义或行为规则大量缺失，sdd-planning 需要反复追问才能设计 |
| 1 | 功能清单形同虚设（如"支持导出"没有任何列/格式/顺序说明），sdd-planning 完全无法基于此设计模块 |
D2 异常边界覆盖度（权重 12）
判据来源：agent.md 表 #3「异常与边界：空/超长/越权/并发/失败重试时必须怎么表现」， knowhow §3 原文强调"这一类最常被整块省略"。
| 分数 | 判据 |
|---|---|
| 5 | 空/超长/越权/并发/失败重试五类中，与本次需求相关的类别全部有明确表现规则；不相关的类别在文中显式注明"不适用+理由" |
| 4 | 覆盖了全部相关类别，但未显式声明哪些类别不适用（读者需要自行判断是遗漏还是不适用） |
| 3 | 仅覆盖部分相关场景，或只写了泛化的"异常时报错"没有具体表现 |
| 2 | 仅有 happy path，零星提及异常但无法作为验收依据 |
| 1 | 完全没有异常与边界章节/内容（整块省略） |
D3 验收线索可度量性（权重 18，核心锚点）
判据锚点（agent.md 第16-17行原文）："goal-benchmark 拿着它能直接写出可度量的验收维度"，
对应表 #4「可判真假的验收线索：写'功能正常'，下游只能照抄成不可度量的维度」。
| 分数 | 判据 |
|---|---|
| 5 | 每条功能/规则都挂有可操作判据（可读取的 DOM 状态/可计算的数值/可复现的操作序列），goal-benchmark 无需追问即可直接转成验收脚本 |
| 4 | ≥80% 条目可直接转成验收脚本，少量整体风格类判据带一定主观性但仍可核验（如用 CSS 数值对比代替目测） |
| 3 | 部分验收线索仍是"看起来符合"级别的主观描述，无法直接写脚本，需要人工目测 |
| 2 | 多数验收线索是"功能正常"类废话，goal-benchmark 只能照抄 |
| 1 | 完全没有验收线索章节，或所有条目都是不可度量的形容词 |
D4 BRD 可追溯性与技术中立性（权重 15）
判据来源：agent.md 第63-65行「in_scope→至少一条 PRD 功能 / out_of_scope 不许出现」+ 第29行「PRD 写技术方案是最常见的越权」+ 第121-122行「traceability 必须能逐条回扣，不是装饰」。
| 分数 | 判据 |
|---|---|
| 5 | BRD 每条 in_scope 都能在 traceability 表里指到具体 PRD 条目，out_of_scope 零渗透，且全文没有出现具体技术方案（框架/中间件/数据结构选型） |
| 4 | 回扣基本完整，但有 1 处 traceability 条目对应关系含糊，或出现 1 处轻微技术选型倾向但不影响下游自由选择 |
| 3 | 有 1 条 in_scope 没有被任何 PRD 条目覆盖，或 traceability 表是摆设（条目对不上/笼统带过） |
| 2 | out_of_scope 有条目被偷偷实现，或多条技术方案越权（替 sdd-planning 做了选型决定） |
| 1 | 没有 traceability 章节，或 BRD 与 PRD 关联完全无法追溯 |
D5 正文要求-验收线索映射完整性（权重 20，产出天花板·主）
判据来源：knowhow §4.3/§4.4 e2e-demo 反面案例核心发现 + §5 候选维度 8。
判据：逐句扫描 PRD 正文（尤其行为规则/视觉风格段落）里出现的每一处描述性/形容词性要求 （例如"大图""丰富""有吸引力""简洁大气"等），检查 §4 验收线索表是否存在与之对应的、 可核验的条目（不能只是重复同一句形容词——"大图"必须转化成类似"页面存在至少 N 个 ≥XXpx 的图片/插画元素"这种可核验判据，才算"有对应"）。
特殊规则：若正文完全不包含任何描述性/形容词性用语（纯功能性/数据型需求，如后台接口类 PRD），此维度视为空真（vacuously satisfied）计 5 分——不适用不等于满分掩盖，这条规则只对 "正文确实零描述性词汇"的片段生效，一旦出现任何描述性词汇就必须逐条核对。
| 分数 | 判据 |
|---|---|
| 5 | 正文所有描述性/形容词性要求都能在验收线索表里指到至少一条对应的可核验条目；或正文本身不含描述性词汇（空真） |
| 4 | ≥90% 的描述性要求有对应验收条目，剩余 ≤1 处遗漏且该处对产出观感影响较小 |
| 3 | 有 1-2 处明显的描述性要求（如"大图""丰富"）完全没有对应验收条目，该要求可以被字面忽略 |
| 2 | ≥3 处描述性要求没有验收条目支撑，或验收线索表本身系统性偏向"结构性/技术性"判据、完全回避内容/视觉主观维度 |
| 1 | 正文出现描述性要求，但验收线索表整体缺失或与正文要求完全脱节 |
D6 内容深度下限与业务度量翻译完整性（权重 15，产出天花板·辅）
判据来源：knowhow §5 候选维度 7 + 9。
判据 A（内容深度）：对涉及文案/说明性内容的功能，PRD 是否只要求"非空"，还是规定了最小 信息密度（最少字数/是否需要具体数据、例子、场景化描述）。
判据 B（业务度量翻译）：BRD"做到什么算解决"里涉及转化/体验类的度量（如"访客几十秒内 判断是否是要找的产品"这类转化类目标），是否被功能清单中至少一条具体、可执行的功能承接， 而不是被结构性功能"顺带"覆盖。若 BRD 本身不含转化/体验类度量（纯功能性需求），判据 B 视为 不适用，只按判据 A 评分。
| 分数 | 判据 |
|---|---|
| 5 | 文案类功能有明确的最小信息密度要求（不只是非空），且 BRD 每条转化/体验类业务度量都能指到至少一条具体功能 |
| 4 | 两项判据中一项完全达标，另一项部分达标（如转化度量被结构性功能部分覆盖但缺关键引导） |
| 3 | 两项都只是部分覆盖，或只满足"非空"这类下限没有更进一步要求 |
| 2 | 转化/体验类业务度量完全没有被翻译成任何功能，文案类要求也只写"非空" |
| 1 | 完全没有考虑内容深度或业务度量翻译，PRD 对文案的唯一要求是"不能为空" |
三、总分计算方法
3.1 加权和
加权和 = Σ(维度得分/5 × 维度权重) （满分 100）
3.2 封顶规则（天花板机制）
knowhow §4.4 原句："验收线索表覆盖什么维度，就决定产出天花板卡在哪"——这句话字面意义就是 "D5/D6 低分应该封顶总分，而不只是拉低加权平均"。加权平均是"稀释"，不是"封顶"：A 组 四个维度只要接近满分，就足够把 B 组的低分稀释成一个仍然体面的总分（本文档五、benchmark 自检里第一次尝试就踩了这个坑，76.4 分）。因此追加硬性封顶规则：
若 D5 ≤ 2 → 总分上限 45
若 D5 = 3 → 总分上限 65
若 D5 ≥ 4 → D5 不封顶
若 D6 ≤ 2 → 总分上限 50
若 D6 = 3 → 总分上限 70
若 D6 ≥ 4 → D6 不封顶
最终得分 = min(加权和, D5 对应上限（如触发）, D6 对应上限（如触发）)
3.3 判定等级
| 分数区间 | 等级 | 处置建议 |
|---|---|---|
| ≥80 | 优秀 | 可直接进入 sdd-planning |
| 65-79 | 合格 | 可进入 sdd-planning，标记薄弱维度供关注 |
| 50-64 | 待改进 | 不建议进入 sdd-planning，需重写薄弱维度后重新评分 |
| 不合格 | 判定为"写虚了"，需要重写核心维度 |
及格线（passing_score）= 65（合格档下限），见 industry_avg_score.md。
四、对 knowhow §5 十条候选维度的逐条取舍
| 候选 | 来源 | 取舍 | 落地形式 | 理由 |
|---|---|---|---|---|
| A1 功能清单完整性 | §5-A1 / agent.md 表#1 | 采用 | 并入 D1 | 与 A2 同属"sdd-planning 能否直接设计模块"这一锚点判据的两个子面（清单完整 vs 规则确定），拆成两个维度会对同一件事重复计分，合并为 D1 |
| A2 行为规则确定性 | §5-A2 / agent.md 表#2 | 采用 | 并入 D1 | 同上 |
| A3 异常边界覆盖度 | §5-A3 / agent.md 表#3 | 采用 | 独立成 D2 | knowhow 原文强调"这一类最常被整块省略"，是与 D1（歧义）完全不同的失败模式（遗漏），且高频出现在真实案例里，单独计权重才不会被 D1 的高分掩盖 |
| A4 验收线索可判真假性 | §5-A4 / agent.md 第16-17行+表#4 | 采用 | 独立成 D3（核心锚点） | 任务书明确要求直接复用"sdd-planning...goal-benchmark..."原句作为锚点；D3 是这句话里"goal-benchmark"那一半的直接对应，必须独立成维度并给足权重 |
| A5 BRD 回扣完整性 | §5-A5 / agent.md 第63-65+121-122行 | 采用 | 并入 D4 | 与 A6 同属"不许扩权/不许漏改 BRD 既定范围"这一类判据 |
| A6 技术中立性 | §5-A6 / agent.md 第29行 | 采用 | 并入 D4 | 技术选型越权本质上也是"替下游做了不该做的决定"，与 traceability 共享同一判定逻辑；评分标准里保留两条独立判据（traceability 完整 + 无技术选型渗透），任一违反都拉低本维度分，不会因合并而漏判 |
| B7 内容深度是否有下限 | §5-B7 | 采用 | 并入 D6 | 可操作化为"文案类功能是否只要求非空 vs 有最小密度要求（字数/具体名词/场景化描述）"，具备可判定性 |
| B8 正文形容词-验收线索映射 | §5-B8 | 采用 | 独立成 D5（产出天花板核心） | e2e-demo 案例揭示的最核心新发现，任务书明确要求独立维度+实质权重；可操作化为"逐句扫描正文描述性用语，核对验收线索表是否有对应条目"，是十条候选里唯一直接可机械核对的 B 组维度，不存在"卡在哪"的操作性障碍 |
| B9 业务成功度量→功能翻译完整性 | §5-B9 | 采用 | 并入 D6 | 与 B7 同属"内容/体验类目标有没有被真正翻译成可执行东西"，可操作化为"BRD 转化/体验类度量能否指到至少一条具体功能"，具备可判定性 |
| B10 PRD 详尽度与任务量级匹配（Appetite） | §5-B10 | 舍弃（本轮） | 不纳入评分维度 | 可操作性不足，具体卡在哪：要给"这个量级该写多细"设阈值，前提是先有一套任务复杂度分级标准（如 S/M/L），本仓库目前没有这套分级体系，也没有历史案例数据可供校准分级边界。强行设定阈值（比如"3 类功能以下配几行异常边界算合适"）本身就是主观拍脑袋，比它想避免的主观性更强。建议记录为未来候选：若后续 DevLoop 引入任务复杂度分级机制，可回头把 Appetite 概念接入 D1/D2 的评分权重调节，而不是作为独立维度 |
五、benchmark 自检：对 e2e-demo 真实 PRD 打分
样本：data/companies/e2e-demo/runs/run_c7d233619784/nodes/rn_42eed93342c5/prd.md
（对应 BRD .../rn_36f1845d1b53/brd.md，产出 data/companies/e2e-demo/projects/p-pyjha7/）。
真实系统记录：attempt-0.json verdict = produced，单轮过验收，无 remediation 回合。
5.1 逐维度打分
D1 功能清单可执行性 = 5 F-1~F-4 每条都写清"谁在什么场景下做什么"，区块数量/顺序/滚动方式/URL 行为/响应式断点 （320/375/768/1024/1440/1920 六个具体宽度）全部给了确定的输入→输出映射，几乎不存在二义 实现空间。
D2 异常边界覆盖度 = 5 §3 列了 6 种边界场景：断点边界值、极端窄屏、文字超长换行、连续快速点击、连续切换点击、 JS 禁用容错——覆盖了本任务真正相关的"超长/类并发（连续点击）/失败降级（JS 禁用）"三类， "空/越权"在纯展示型静态页场景下确实不适用。覆盖充分。
D3 验收线索可度量性 = 4
F-1~F-4 四条验收线索全部是可编程核验的判据（DOM 节点计数、scrollY 变化、
document.location.href 前后对比、scrollWidth<=innerWidth 数学公式）。唯一弱一档的是
第 5 行"视觉风格"验收线索——"字号明显大于正文字号（视觉上一眼可辨）"仍带主观目测成分，
未完全数值化。≥80% 条目可直接转脚本，符合 4 分档。
D4 BRD 可追溯性与技术中立性 = 5
§5 traceability 表逐条把 5 条 BRD in_scope 对应到具体 PRD 条目，并明确列出 7 条 out_of_scope
均未涉及；全文未出现任何具体技术栈/框架选型（技术栈显式留给 sdd-planning）。
D5 正文要求-验收线索映射完整性 = 3 ← 关键维度 逐句核对 §2 视觉风格段"整体页面采用大字体、大图/大留白排版...不使用密集小字或拥挤布局"：
- "大字体" → §4 有对应条目（"字号明显大于正文字号"）✓
- "大留白/呼吸感" → §4 有对应条目（"区块间有可见的垂直间距"）✓
- "大图" → §4 验收线索表五行里没有任何一行提到图片/插画元素，产出实测
index.html全站 0 个<img>标签、0 个 icon（已用grep核实）。这是一处明确的、正文出现但验收线索 未覆盖的描述性要求，命中 3 分档"有 1-2 处明显的描述性要求完全没有对应验收条目"。
D6 内容深度下限与业务度量翻译完整性 = 1 ← 关键维度
- 判据 A：§2 对文案类内容的唯一要求是"标题和说明都不能为空"，没有任何最小字数/信息密度/ 具体化要求。产出实测三段说明文字均为单句泛化描述（约 50-60 字），无数据、无具体案例、 无场景化细节支撑。
- 判据 B：BRD §3"做到什么算解决"里"访客在几十秒内判断这是不是我要找的产品"是一条转化类 业务度量，但 F-1~F-4 全部是结构性/行为性功能，功能清单里从未出现任何 CTA/下一步引导 相关功能，产出实测全站没有一个可点击的"了解更多/联系我们"入口。两项判据均完全落空， 命中 1 分档。
5.2 第一次计算：纯加权和（暴露问题）
D1 = 5/5×20 = 20.0
D2 = 5/5×12 = 12.0
D3 = 4/5×18 = 14.4
D4 = 5/5×15 = 15.0
D5 = 3/5×20 = 12.0
D6 = 1/5×15 = 3.0
─────────────────────
合计 = 76.4
76.4 分落在"合格"档（65-79），接近"优秀"下限。这正是任务书警告的失败信号： 如实计算下来，这套 benchmark 第一版设计会把一份"四类东西全过但产出单薄"的 PRD 判定为 "可以进入下游"——benchmark 设计失败。
根因诊断：加权和是"稀释"机制，不是"天花板"机制。A 组四个维度分数都在 4-5 分区间， 凭 65% 的权重占比就足够把 D5=3、D6=1 这两个真正暴露问题的低分稀释成一个体面总分。这不是 权重分配错了（B 组已经拿到 35% 的实质权重，D5 单项权重与 D1 并列全场最高），而是"加权平均" 这个数学形式本身表达不了 knowhow §4.4 那句话——"验收线索表覆盖什么维度，就决定产出天花板 卡在哪"说的是卡死，不是打折。
5.3 修正：引入封顶规则后重算
按三、3.2 的封顶规则：
- D5 = 3 → 触发"总分上限 65"
- D6 = 1（≤2）→ 触发"总分上限 50"
最终得分 = min(76.4, 65, 50) = 50
50 分落在"待改进"档（50-64），低于及格线 65，与真实产出的实际观感（结构扎实但内容
单薄、无图无 CTA）一致，也低于"合格"门槛——这套 benchmark 在加入封顶规则后，能够正确地
不给这份 PRD 放行，即便 DevLoop 引擎本身把它判成了 verdict: produced 单轮过验收。
这个落差本身就是本次调研要交付的核心结论：现有 prd-planning 自查表 + 引擎验收链路
对"结构完整"和"内容够不够格"是两件事，前者已经被守住，后者目前没有任何节点在守。
本套 benchmark 的存在意义就是把后者显式量化出来。
5.4 结论
- 自检证明：不封顶的纯加权和设计是错的，已修正为加权和+封顶规则的组合算法（三、3.2）。
- e2e-demo 真实 PRD 最终得分 50（待改进），符合"这是一份应该被打回去要求补内容深度/ 视觉元素/转化路径的 PRD"的预期判断。
- 该结果同时用作
industry_avg_score.md的真实基线（及格线以下）。