SKILL.md — PRD 撰写方法论
训练对象：
prd-methodology-trial（独立试验节点） 依据：训练材料 knowhow_v1.md（4 流派调研 + e2e-demo 反面案例）+ benchmark_v1.md（6 维度评分标准） ——均在本体train/{hunt,digest}/下，供人工审阅训练过程，不是本 SKILL 运行时依赖 目标读者：任何要把 BRD 翻译成 PRD 的角色（如prd-planning），下笔前/自检时使用 目标：产出的 PRD 按 benchmark_v1.md 打分达到「优秀」档（≥80，及格线 65，见该文档三、3.3； 目标刻度取值理由见训练材料 evolve_report.md 一、目标分数对齐，位于train/evolve/下） 训练验证：2 轮 Small Loop（真实反面案例重写 96 分 / 全新虚构场景 97 分），均远超及格线且 相互印证方法论不是对单一案例的记忆式过拟合，详见train/evolve/下的 iteration_1_scores.json / iteration_2_scores.json / real_project_reflection.md
〇、先读懂你要解决的问题
prd-planning/agent.md 现有的"四类东西"检查表（功能清单/行为规则/异常边界/验收线索）只保证
结构完整，不保证内容够格。e2e-demo 真实案例（data/companies/e2e-demo/runs/run_c7d233619784/
nodes/rn_42eed93342c5/prd.md）证明了这一点：四类东西全部按字面要求写全，D1-D4 接近满分，
但正文写了"大图"、验收线索表里却没有任何一行提到图片——产出实测 0 个 <img> 标签；
文案要求只写"不能为空"——产出三段说明都卡在刚好非空的水平；BRD 的转化类业务度量
（"访客几十秒内判断是否是要找的产品"）从未被翻译成任何 CTA 功能。这份 PRD 按 benchmark_v1.md
打分只有 50 分（待改进），低于及格线。
本方法论要解决的核心问题：让"正文写了什么"和"验收线索表验什么"在写 PRD 的过程中 天然对齐，而不是事后靠审查发现脱节。做法不是加一道审查工序，而是把 D5/D6 检查点内嵌进 写作步骤本身——写正文的同一时刻就顺手写验收线索，而不是先写完全部正文再回头补验收线索表。
一、使用前提
- 你已经拿到上游
brd-planning的contract.json（exports.brd_path/in_scope/out_of_scope/success_metrics）。 success_metrics（BRD"做到什么算解决"）里如果出现转化/体验类表述（访客要不要行动、 要不要产生某种感受、要不要在多长时间内做出判断），先圈出来，第五步会用到。- 上游契约缺关键项（
out_of_scope空着、success_metrics全是形容词）不要硬补—— 这是prd-planning自身的既有规则（agent.md「说不清就别硬写」），本方法论不覆盖这条。
二、八步流程
Step 1 — 功能清单（对应 D1，权重 20）
每条功能一句话："谁 + 在什么场景下 + 做什么"。自检：这条功能摊开来能不能实现成 ≥2 种不同的东西？能，就是写虚了，继续拆细直到只剩一种实现路径。
Step 2 — 行为规则（对应 D1）
给每条功能的输入→输出确定映射，含默认值。反面信号（agent.md 原文）："只写了 『支持导出』，没写导出什么列、什么顺序、什么编码"。凡是出现"支持 XX"这种动词而不接 具体规则的句子，视为未完成，必须继续展开。
Step 3 — 异常与边界扫描（对应 D2，权重 12）
固定过一遍五类：空 / 超长 / 越权 / 并发 / 失败重试。对每一类，二选一： (a) 写明确表现规则，或 (b) 显式写"不适用 + 理由"（例如纯静态展示页可以对"越权"写 "不适用：无鉴权/数据写入场景"）。不允许整类不提——不提等于评分时判"整块省略"， 命中 D2 最低档。
Step 4 — 描述性语言扫描 + 就地挂验收线索（对应 D5，权重 20，核心步骤）
这是本方法论新增、直接针对 e2e-demo 案例根因设计的步骤，必须在写 Step 6 验收线索表 之前完成，且要在写下每一句描述性正文的同时执行，不要写完全部正文再回头补。
操作：逐句重读 Step 1-3 已经写下的正文（尤其"视觉风格""体验""风格调性"这类段落）， 标出所有描述性/形容词性用语——典型信号词：大 / 丰富 / 精美 / 有吸引力 / 简洁大气 / 专业 / 现代感 / 温馨 / 高级感 / 干净 / 舒适 / 有质感 / 沉浸感。
对标出的每一个描述性用语，做以下两件事之一，当场决定，不要拖到后面：
- 转成量化代理指标，用附录 A 的对照表或自己推导一个可编程核验的判据， 随手记在旁边（Step 6 会正式收进验收线索表）。例："大图" → "页面存在至少 N 个 宽度 ≥ XXXpx 的图片/插画元素，图片区域占卡片可视面积 ≥ M%"。
- 改写正文，删除这个形容词，换成本来就该写的具体规则（这往往说明这句话 本来就该属于 Step 2 行为规则，而不是模糊的风格描述）。真实案例 p-bkhylu 证明这条 路径完全可行：那份 PRD 全文没有出现"大图/图文并茂"这类承诺句，只写了"如展示图形 元素须为自制内容"这种约束句，因此 D5 拿到 4 分——不是因为它承诺了丰富视觉又兜住了 验收，而是它压根没做兑现不了的承诺。找不到合理量化代理时，删词改写不是退而求其次， 是更诚实的选择。
判断做完没有的标准：把 Step 1-3 正文再读一遍，如果还能找到一个形容词性词语 在你脑子里没有对应的量化判据，就是没做完。
特殊情况：如果 PRD 正文本身不涉及任何视觉/体验描述（纯功能性/数据型需求， 例如后台管理类 PRD），这一步确认"正文零描述性词汇"后可以跳过，直接空真满分—— 不要为了走流程硬造一个视觉要求。
Step 5 — 内容深度与业务度量翻译（对应 D6，权重 15，核心步骤）
判据 A：内容深度下限。凡是 PRD 涉及文案/说明性内容的功能（标题、简介、说明文字、 空状态提示等），不能只写"不能为空"。必须至少二选一：
- 给最小字数/字符数区间；或
- 要求内容包含至少一个具体名词/数据/场景化描述（禁止清单：不能是纯套话，例如 "很棒的产品""专业可信赖"这类不含具体信息的形容词堆砌，见附录 B 反例清单）。
判据 B：业务度量翻译。回到〇/一步圈出的 BRD 转化/体验类 success_metrics。
对每一条，问："功能清单里有没有一条能直接指出来的具体功能在承接这条度量？"
不能是"这几条功能加起来大概能覆盖"这种含糊说法——必须能指到具体一条 F-N。
常见承接形式：CTA 按钮 + 明确跳转目标、空状态引导、下一步入口。如果指不出来，
在功能清单里新增一条，不要跳过这一步指望验收线索表能补救——功能清单没有的东西，
验收线索也无从谈起。
若 BRD 本身不含转化/体验类度量（纯功能性需求），判据 B 视为不适用，只按判据 A 评分， 在 PRD 里显式写一句"BRD success_metrics 为功能性描述，本条不适用"，不要留空造成 "是漏了还是不适用"的歧义（呼应 D2 同样的"不适用要显式声明"原则）。
⚠️ 新增功能不能绕开 Step 1/Step 2 的确定性要求：Step 5B 为了承接业务度量新增的功能 （典型如 CTA 按钮），必须像其它功能一样写清具体触发条件/跳转目标/展示位置——"跳转到 范围内某个锚点"这种表述本身就是 Step 1 定义的"摊开成多种实现"的反面信号，必须精确到 具体锚点 ID/具体位置。为了修 D6 新加的功能反而在 D1 留了口子，等于拆了东墙补西墙 （训练迭代1曾真实踩过这个坑，D1 因此从5分掉到4分，迭代2改正后两项都保住了满分）。
Step 6 — 验收线索表（对应 D3，权重 18）
把 Step 1-5 积累的所有判据（功能验收 + Step 4 量化代理指标 + Step 5 业务度量对应功能
的验收）汇总成表。每一行自检："goal-benchmark 拿着这一行需不需要追问就能写出可度量
的验收维度？"——凡是还剩"看起来符合""体验良好"这类主观描述且没有数值/操作序列化的，
继续往下拆，拆到可编程核验或至少可复现操作序列为止。允许保留 1 处整体风格类判据带
轻微主观性（如"字号明显大于正文字号，视觉上一眼可辨"），但不能整表都是这种级别。
Step 7 — 需求可追溯性 + 技术中立性自检（对应 D4，权重 15）
- 逐条对照 BRD
in_scope：每一条能不能在 PRD 里指到至少一条具体功能/规则？指不到 就是漏了需求，回 Step 1 补。 - 逐条对照 BRD
out_of_scope：PRD 里有没有偷偷出现对应功能？出现就是扩了范围，删掉。 - 通读全文找具体技术方案词（框架名、中间件名、数据结构选型、具体算法）。 出现就改写成行为描述（agent.md 原句示例："用 Redis 缓存"→"同一查询 1 分钟内重复 请求返回一致结果"）。
Step 8 — 提交前自检清单
逐条打勾，任何一条打不了勾就不能提交：
- [ ] Step 1 每条功能只能摊开成一种实现（含 Step 5B 新增的功能，跳转目标/触发条件已精确到具体值）
- [ ] Step 2 每条行为规则有输入→输出映射 + 默认值
- [ ] Step 3 五类异常边界，每类"有规则"或"显式不适用"，没有整类空白
- [ ] Step 4 正文里找不到一个没有对应量化判据的描述性词语（或已确认正文零描述性词汇， 或已确认该词语已被删词改写而非留在正文里无人认领）
- [ ] Step 5A 文案类功能都有最小字数/具体化要求，不是只写"非空"
- [ ] Step 5B BRD 转化/体验类度量都能指到具体一条功能（或已显式声明不适用）
- [ ] Step 6 验收线索表每行可编程核验或可复现操作序列，主观判据不超过 1 处
- [ ] Step 7 in_scope 全覆盖、out_of_scope 零渗透、无技术选型越权
三、附录 A：描述性用语 → 量化代理指标 对照表（起始集，可扩充）
| 描述性用语 | 量化代理指标示例 |
|---|---|
| 大图 / 图文并茂 | 页面存在 ≥N 个宽度/高度 ≥ XXXpx 的图片/插画元素；图片区域占容器可视面积 ≥ M% |
| 大字体 | 主标题字号（px/rem）显著大于正文字号，给出具体数值区间或倍数关系 |
| 大留白 / 呼吸感 | 区块间垂直间距 ≥ N px，可用 CSS 计算属性核验 |
| 色彩丰富 | 页面使用的主题色数量 ≥ N 种，或给出具体配色方案约束（而非留白判断） |
| 简洁大气 / 有质感 / 高级感 | 通常无法直接量化，优先拆成"大字体+大留白+统一配色"等已量化的子判据组合表达，避免保留原词单独出现在正文却无验收行 |
| 有吸引力 / 专业可信赖 | 优先转成可核验的构成要素（是否含权威背书元素、是否含具体数据展示等），或如确无法量化则删除该形容词，改写为具体规则 |
| 沉浸感 / 现代感 | 同上，拆解为动效/配色/字体等已知可量化维度，不保留原词孤立存在 |
用法提示：如果一个描述性词语实在找不到合理的量化代理，优先删词改写（Step 4 方案 2）， 不要为了凑一行验收线索硬造一个和词语本身脱节的判据（例如给"专业可信赖"硬配一条 "页面能正常加载无报错"——这种判据和词语原意无关，属于 train-05 里 D5=2 分档的反例）。 真实案例 p-bkhylu 证明"根本不做兑现不了的承诺"是可行且能拿高分的真实路径，不只是 理论兜底选项，详见
real_project_reflection.md二。
附录 B：文案套话反例清单（判据 A 用）
以下类型的文案即使非空也不满足 Step 5A："很棒的产品""专业的服务""优质的体验""值得信赖"—— 共同特征：不含任何具体名词/数据/场景，替换成任何其它产品都成立。要求文案至少含一个 具体名词（功能名/数据/使用场景）才算通过。
附录 C：业务度量关键词分类（判据 B 用）
转化/体验类关键词（命中任一即需要走 Step 5B）：转化、点击、注册、购买、下单、留资、 几秒/几十秒内判断、决定是否、意愿、引导、下一步、说服、打动。 纯功能性关键词（不触发 Step 5B，仅按判据 A 评分）：查得到、筛得出、导得出、算得对、 状态一致、响应正确。
附录 D：方法论边界（本轮训练明确不覆盖的问题）
真实案例 p-v1mpcl 暴露了一类与 PRD 内容质量完全无关的失败模式：规划节点自报成功但
产物没有真正落盘（planner-validator 抓到的 impl_bug）。这属于 DevLoop 引擎层的
产物存在性校验问题，不是"PRD 写得够不够格"的问题，本方法论不处理，也不应该处理——
内容质量方法论的前提是"PRD 文档确实存在"，这个前提本身的保障不在本方法论范围内。
详见 real_project_reflection.md 三。