reviewing-prd

reviewing-prd — SKILL.md

变体： standard · 适用时机： 将已完成（或已修订）的 PRD 作为验收门槛进行评判——检查它是否可规划，然后给出 VERDICT: approve|revise，并列出可执行的发现。

概述

此技能是 PRD 编写/评判配对中的评审部分。由手头有一份已完成 PRD的评审者加载，用一个问题来评判该 PRD：能否据此规划后续构建？ 它会应用固定的 12 项可规划性检查清单——与 authoring-prd 所遵循的标准相同，确保编写标准和评审标准不会偏离——检测伪造的证据，然后给出一条可由机器解析的判定，以及作者可在一轮修订中处理的发现。这是一个验收门槛——它不会编写、修复或重写 PRD；它会评判并返回发现，由编写者进行修订。

何时启用

• 已完成的 PRD 需要在下游规划开始前作出接受/修订决定。
• 你是刚刚编写 PRD 的编写者的独立评审者/把关人。
• 在先前给出 revise 判定后，重新评判修订后的 PRD。
• 评判修订过的 PRD（带版本的变更）——应用限定于变更范围的评审（cond-12）。

不要在以下情况启用：

• 编写或修复 PRD → 使用 authoring-prd。此技能绝不编写 PRD。
• 评审工程设计文档——feature-spec、technical-design、plan、ADR 或 RFC → 使用 design-review 技能。该门槛会依据代码库验证工程声明；此门槛评判产品是否可规划，不用于 PRD 的工程类下游文档。
• 检查模板/章节是否符合要求 → 这是模板方面的问题。此技能评判的是是否达到质量标准，而不是每个标题是否都存在。
• 评审其他任何类型的文档。

工作流

第 1 步：以全新、独立的视角通读整份 PRD

从头到尾阅读 PRD，像第一次看到它一样，不受作者的说明影响。你的立场是把关人，负责把关下一步（规划）：只有当发现表明无法按文档所述规划构建时，它们才有分量。留意哪些声明、指标、范围描述或依赖关系起着关键作用——第 2 步会仔细审查这些内容。如果这是一次修订，也要阅读变更日志/版本差异（cond-12）。

第 2 步：运行 12 项可规划性检查清单——逐项评判

对于每项适用的条件，判断其为通过还是存在缺口。只有存在真实且明确指出的不足时，条件才算未通过——“我会换一种说法”不算缺口。对于每个缺口，记录确切位置和缺失内容（第 4 步会将其转化为可执行的发现）。条件 9–12 是 v1.2.0 中新增的；每项都包含比例性收缩规则，因此不会仅因 PRD 内容简略就判定其不通过（cond-10 中的无孤立项核心要求仍是不会收缩的基线——只有其矩阵会在 PRD 内容简略时收缩）。

能力边界检查项（如下）仅在 capability_record 被注入编写调用且可作为评审上下文时适用。若未提供，则将其视为不适用——在没有定义边界时，不要因文档缺少能力边界标记而扣分。

1. 问题有证据支撑，而非凭空断言。 有证据佐证——定性证据（访谈、工单、反馈）和／或定量证据（转化率、流失率、流失节点）——并且有具体量化（例如“第 3 步的流失影响了 42% 的新账户”），且以真实的用户任务为出发点。若问题只是空泛断言，或证据含糊、没有来源、规模或受影响人群，则标记为 Gap。
2. 用户／角色具体明确。 至少明确主要用户角色及其真实需求和场景（用户故事）。若用户只是泛泛的“用户”，没有可供规划者据此设计的需求／场景，则标记为 Gap。
3. 成功指标可衡量（并设有护栏）。 最多约 4 个结果指标（对于精简项目，一个指标也足够），每项都要有目标值和衡量方法。若指标没有目标值或衡量方法，或只是虚荣指标，则标记为 Gap；列出 10 个未经优先级排序的 KPI 也属于 Gap。护栏检查： 仅当核心指标明显可被操纵，且会损害某个已明确的目标时，才标记缺少护栏／反向指标（不要臆测“可能被操纵”）。不要因为精简的 PRD 只有一个有效指标就要求修改。
4. MVP 边界有充分依据。 明确划分范围内与范围外，列出非目标和发布标准。若 v1 包含所有内容、没有非目标，或没有“可发布”标准，则标记为 Gap。
5. 功能具体且可规划。 功能集及其验收标准足够具体，能够据此拆解里程碑／任务，且可独立测试（Given/When/Then 是强有力的标志）。若功能只是抽象目标，没有可测试的“完成”标准，则标记为 Gap。
6. 没有捏造证据。 每条引用／统计／数字都真实且可核实，或明确标注为待验证的假设。对于精确但没有来源的数字和无法追溯的研究，应保持怀疑——AI 撰写的 PRD 极易捏造看似可信的引用／数据。若证据疑似捏造却被当作事实呈现，则标记为 Gap（严重）。明确标注的假设不属于 Gap。绝不能让捏造的数字以事实之名过关。（不可折叠的基准——适用于任何规模。）
7. 公开列出风险、依赖项背景和待解问题。 坦诚说明真实的未知事项和风险（风险需列出可能性／影响及缓解措施；待解问题需逐项列出），而非将其掩盖。若 PRD 给人一种错误的完整感，则标记为 Gap。（依赖项的完整性归入 cond-11；此项关注的是是否如实披露风险／未知事项。）
8. 清晰明确，没有歧义。 避免行话，术语前后一致（每个实体只有一个名称），确保跨职能读者对每项需求的理解一致。若歧义会导致两位规划者构建出不同的内容，则标记为 Gap。（不可折叠的基准。）
9. 非功能需求需有目标值。 针对该类型项目，列出关键的非功能需求类别，并为每类设定可检查的数值目标（视情况包括性能／SLO／安全／隐私／无障碍 WCAG 2.2 AA／可扩展性／合规性）。若关键的非功能需求只是模糊的形容词（如“应当快速／安全”），却没有目标值，则标记为 Gap。折叠规则： 精简的内部工具所需类别较少；如果明确说明某项非功能需求按尽力而为处理，则不属于 Gap——不要强求无关紧要的工具满足其不需要的 SLO。
10. 可追溯（无孤立项）。 通过结构化交叉核对目标部分与需求／功能部分：每项功能至少支撑 1 个已明确的目标，且每个目标至少对应 1 项功能；指标关联目标；用户故事有验收标准。若某项功能不支撑任何已明确的目标，或某个目标没有对应功能，则标记为 Gap。折叠规则： 只有一个目标／一项功能的微型 PRD 可轻松实现追溯。（无孤立项规则的不可折叠基准——任何规模下，不支撑目标的功能都有问题；折叠规则仅表示小型 PRD 无需复杂矩阵。）
11. 列明依赖项。 公开说明会影响排期的跨团队及外部依赖项（服务、数据、第三方、所需审批）。若阻碍排期的硬性依赖项被埋在正文中或完全缺失，则标记为 Gap。折叠规则： 没有外部依赖项的独立工具自然满足要求（“无”是有效答案）。
12. 修订完整性（仅限增量范围——仅在评审修订时适用）。 评审变更及其连带影响，而非完整重审未变更的 PRD：(a) 变更涉及的内容达到可规划标准；(b) 有变更历史（谁／何时／改了什么／为什么）；(c) 已标记被取代的内容，而非悄然删除；(d) 连带影响完整——下游追溯链没有断点（例如删除功能后，其指标／验收标准变成孤立项）。折叠规则： 全新项目不适用此项；范围清晰、追溯完整的增量修订应 approve——不要因为小幅修订没有重新论证未变更的部分而误判为需要修改。
13. **能力覆盖（无能力记录时为不适用）：**所有活跃的 L1 能力领域都作为命名的范围章节列出。

**作者辅助工具根据结果而非是否使用来评判。**指标／优先级框架（North Star／OKR／HEART／AARRR；RICE／MoSCoW／Kano）、特定原型的补充内容、GTM／发布／支持准备情况、机会规模估算、事前验尸分析和 JTBD 标注法都是作者的辅助工具——应评判结果（选择了合适的指标、边界有据可依、完整度符合原型），绝不要求使用具名框架或设置特定章节。要求提供 bar 未列出的 GTM 章节、RICE 评分或「ML 章节」，属于臆造条件错误（参见反模式）。

适度原则。「具体到足以据此规划」应与项目规模相称。精简的项目可以合理地省略不需要的章节——满足每项适用条件的精简且完整的 PRD 应予通过。评判决策是否完整，而不是字数。不要因为内容简短，或省略了不适用的章节，就认定存在缺漏（内容更丰富的模板包含更多可选章节——应依据 bar 评判，而不是看模板章节是否齐全）。

步骤 3：决定结论

• 通过——每项适用条件均符合。可以按 PRD 中的内容规划构建。即使你能想到文风上的改进，也应予以通过；标准是能否据此规划，而非是否完美。
• 修改——一项或多项适用条件存在明确缺漏，导致无法规划（例如，指标没有目标、未列出非目标、功能描述抽象、统计数据凭空捏造、影响重大的 NFR 模糊不清、功能没有关联目标、关键依赖埋藏在文中、修改内容没有变更日志等）。

不要为了体现投入，或索要锦上添花的内容而要求修改。条件要么满足，要么不满足。

步骤 4：给出结论和可执行的发现

结论单独占一行——原样写出 VERDICT: approve 或 VERDICT: revise，不得使用代码围栏、引号或添加其他文字（此处的围栏仅作示意）：

VERDICT: approve

然后在后续行中列出发现。结论为 revise 时，每项发现都必须可执行——指出未通过的条件（编号／名称）、准确位置，以及修复方法，让作者可以一次性解决。结论为 approve 时，可以列出不影响通过的备注，但不要让这些备注暗示必须修改。

好的发现会指出缺漏并给出修复方法：

修改 — NFR（条件 9）：API PRD 中写了「必须很快」，但没有目标值。修复：指定一个数值目标，例如「滚动 30 天内 p95 < 300ms」。 修改 — 可追溯性（条件 10）：功能「批量导出」没有对应任何已声明目标。修复：将其关联到某个目标，或将其移至非目标。

不好的发现含糊不清，无法采取行动：

需求部分可以写得更好。（具体是哪项需求？为何不符合？如何修复？）

规则

硬性规则（绝不违反）：

• 只输出一行判定：VERDICT: approve 或 VERDICT: revise——该字面标记必须独占一行，除此之外不得包含任何内容。下游工具会解析它。
• 只评审，不代写。 返回问题；不要重写、修正或补全 PRD。由作者修改。
• 统一评审标准。 按照第 2 步中的 12 项条件进行评审——这与作者撰写时采用的标准相同。不要自行增加条件或设定更严格的私人标准。
• 不得擅自增加条件。 对作者辅助工具（框架、原型叠加、GTM、机会规模估算、事前验尸）的评判应基于结果，而不是要求必须以某个名称出现。“还应该有 GTM／竞争／ML 章节”或“应该使用 RICE”——若这些不是列出的条件，就会导致评审标准偏离撰写标准。禁止这样做。
• 不得错误要求修改。 PRD 满足所有适用条件时，即使内容很精简，也应予以批准（精简 PRD 中，条件 9–12 可能不适用）。只有存在真实且明确的问题时才要求修改。
• 不得错误批准。 绝不能为了表示友好而对确实存在的问题视而不见。
• 捏造内容属于阻断问题。 怀疑证据是编造的，一律要求修改，直到找到来源或删除为止；绝不能将其当作事实放过。
• 根据文档获得的上游输入进行评审。 按其 depends_on 集合进行评估。上游内容未产出，绝不能成为要求修改的理由；文档忽略了已产出且应当参考的上游内容，则可以作为合理的问题指出。
• 修订 = 仅评审变更范围。 评审修订时，应检查变更及其影响范围（条件 12），而不是重新评审整份未变更的 PRD。
• 每条修改意见都必须可执行——指出未满足的条件、具体位置和明确的修复方式。

偏好（可覆盖）：

• 按严重程度排列问题——先列阻断性问题，再列轻微问题。
• 在每条意见中注明条件编号／名称，便于作者对应评审标准。
• 批准说明应尽量精简，并明确标注为非阻断项。

易错点

• 因内容齐全而批准，而非判断是否可规划。 每个章节都可能齐全，但 PRD 仍然无法据此规划（指标没有目标值、功能描述抽象、NFR 含糊）。应判断能否规划构建工作，而不是模板是否填满。
• 对精简项目错误要求修改。 小型项目的 PRD 本来就应当简短；不适用的章节被省略或合并（没有 NFR 矩阵、没有依赖项、没有变更日志）并不构成问题。因内容简短而凭空制造问题，或因更丰富模板中的可选章节为空而要求修改，是最常见的评审错误。
• 擅自增加条件。 要求提供评审标准中未列出的 GTM／竞争／ML 章节或特定框架，会增加私人要求，导致评审标准偏离。应评判结果，而非目录结构。
• 提出推测性的防护要求。 如果 PRD 所述目标并未受到威胁，就不要指出“理论上这个指标可能被操纵”。只有当某个指标显然容易被操纵，且会损害某个已述目标时，条件 3 的防护检查才适用。
• 轻信看似权威的数字。 没有可追溯来源的精确统计数据，是证据可能遭到捏造的典型迹象，而非严谨的表现。
• 修订时重新评审整份 PRD。 条件 12 仅适用于变更范围；不要要求修改未触及且已获批准的章节。
• 将此评审与工程设计评审混为一谈。 评审 PRD 时应看产品规划是否可行，而不是代码是否一致。不要对 PRD 套用功能规格／ADR／RFC 的审核门槛，也不要依赖这些门槛。
• 判定标记格式错误。 “Approved”、“LGTM”、“needs work”或藏在段落中的判定都无法被解析。请单独一行输出字面标记 VERDICT: approve|revise。

反模式

• 不加判断地批准。 草草浏览后就批准——虚构的指标或无依托的功能一旦放行，就会污染后续计划。
• 吹毛求疵地要求修改。 把措辞、格式或锦上添花的内容包装成缺口，并以此阻止通过。
• 默默改写。 “直接修好更省事”——在评审过程中代写，会模糊产出与评判之间的界限。
• 凭空添加条件。 “还应该包含竞争分析 / GTM 章节” / “应该采用 RICE”，但这些并不属于 12 项条件门槛。
• 对轻量 PRD 的 NFR / 可追溯性要求过严。 向简单的内部工具索要 SLO，或要求只有一个目标的 PRD 提供可追溯性矩阵——条件要求应按比例降低。
• 含糊其辞的判定。 “基本批准，但是……”或写两行判定。只能有一个决定，而且必须是一个 token。

输出

针对一份 PRD 的单条评审结果：

• 一行判定——单独一行，逐字写作 VERDICT: approve 或 VERDICT: revise。
• 发现项——若判定为 revise，每个阻断性缺口列出一条可执行的发现项（未通过的条件 + 位置 + 具体修复方法）；若判定为 approve，可选择添加非阻断性备注。

抽象的消费者是负责协调产出→评审循环的对象：approve 表示接受 PRD 并进入下一阶段（规划）；revise 表示将发现项退回给产出方，进行范围明确的修订。

相关内容

• authoring-prd——配对工具中的产出部分；它按照本技能评判所依据的同一项 12 条件可规划性门槛编写 PRD。将二者配对可确保门槛只有一个来源，避免产出与评审标准偏离。
• design-review 技能——用于评审工程设计文档（feature-spec、technical-design、plans、ADRs、RFCs）的配套门槛。门槛各不相同；PRD 不使用此技能。
• PRD 模板 / content-template 工具——负责章节结构；本技能评判的是是否达到门槛所要求的质量，而非结构是否合规。

渐进式披露

• references/plannability-bar.md——扩展说明 12 项检查条件，包含每项条件的通过 / 缺口信号及已完成的发现项示例（包括结构性可追溯性检查、可博弈性门槛、NFR 承载范围，以及按变更范围审查修订）。当边界条件需要更明确的通过 / 缺口判定时加载。
• references/sources.md——评审方法和虚构内容检测指南的研究来源。

正文预算

• description ≤ 1,024 个字符（agentskills.io 上限）。Claude 在列表中会将 description + when_to_use 合计截断至 1,536 个字符。
• 正文约 500 行 / 5,000 个 token（软性目标——优先保证质量；若持续超过 700 行 / 7,000 个 token，则标记）——每轮都保留在上下文中。
• 每个参考文件：超过 10k 个 token 时警告，超过 25k 时错误。参考文件总量：超过 25k 个 token 时警告，超过 50k 时错误。