SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场prd-reviewer

prd-reviewer

写作与研究

查看项目

更新于 10-16 01:56

技能介绍

PRD Reviewer 是一个面向产品需求文档（PRD）评审的 AI 技能，自身定位为“需求评审会议的 AI 化”，目标是对 PRD 进行全方位、360 度审查，确保其质量达到“准出”标准。它是 PRD 进入 HLD 阶段前的守门环节。

用途

该技能用于在 PRD 完成后进行评审，回答 PRD 是否可以进入下一阶段的问题。它以独立视角审视需求，不修改 PRD，只提出问题与改进建议。

工作模式

技能区分两种模式：

  • formal_design：用户要求完整新功能文档或正式全量准出时，执行完整流程、模板、追溯和适用门禁。
  • bounded_change（amendment）：对已有工件的有限增量，读取有限增量规则，检查受影响行为、授权、兼容性及直接依赖，仅给出该范围结论，不签全量证书。整改 delta 仍须满足可靠完整初审的复用条件。

模式由实际职责、信任、契约、失败语义与批准范围决定，不按行数或文件数判断；即使“两行修改”改变权限边界，仍需对应有权 Owner 决策。

主要能力

技能按多个维度审查 PRD：

  1. 结构完整性：是否包含所有必填章节、是否遵循标准结构、是否有空白或占位符未填写。
  2. 业务逻辑（PM 视角）：业务背景是否清晰、用户故事是否完整、业务规则有无遗漏或矛盾、边界情况是否考虑、成功指标是否可量化且数据来源明确。
  3. 需求清晰度（开发视角）：需求描述是否有歧义、能否据此编写 HLD、功能边界是否清晰、依赖和约束是否明确。
  4. 可测试性（QA 视角）：验收标准是否可测试、测试场景是否足够、边界条件是否有对应验收标准。
  5. 业务方视角：业务现状描述是否准确、变更影响评估是否完整、是否遗漏利益相关方。
  6. 内容边界：是否越界到 HLD 领域（如 API 路径、数据库设计、技术选型）、方案建议与最终决定的边界是否清晰。
  7. 证据可追溯性：“相关能力识别”表格每行是否都有来源、业务现状描述是否有依据、是否存在无依据猜测。
  8. 一致性：术语是否前后一致、需求描述是否内部矛盾、优先级标注是否合理。
  9. Traceability Metadata：是否存在 TRACEABILITY-METADATA block、是否满足 prd-profile-v1、requirement/source document/derived_from 关系是否完整。
  10. 1:N 拆分场景审查：当 PRD 属于 BRD 拆分场景（检测 PRD 元信息是否包含“索引文档”或“关联 PRD”字段）时，检查索引文档是否存在及其 BRD 需求覆盖矩阵覆盖率是否达到 100%、本 PRD 是否被正确列入索引、覆盖范围是否清晰、与关联 PRD 是否存在需求重叠或遗漏、跨 PRD 依赖是否声明及协调方式是否明确。

问题分级

审查发现的问题分为三级：

  • P0 阻塞：必须修复才能准出，处理方式为不放行、要求修改。示例包括缺少必填章节、成功指标无法量化或缺少数据来源、需求内部矛盾、越界到 HLD 领域、关键业务规则缺失、“相关能力识别”无来源依据、缺少或无法解析 TRACEABILITY-METADATA block、schema.profile 不是 prd-profile-v1、requirement 缺少稳定 REQ-* 或缺少 acceptance_criteria，以及 1:N 场景下索引文档不存在或 BRD 需求覆盖率低于 100%。
  • P1 严重：准出前必须修复，任一未关闭 P1 不放行。示例包括用户故事覆盖不完整、边界情况未考虑、验收标准不够具体、术语使用不一致、业务现状描述无依据，以及 1:N 场景下未标注覆盖范围、未引用索引文档、跨 PRD 依赖未声明、与关联 PRD 存在重叠或遗漏。
  • P2 建议：可以后续优化，记录但不阻塞放行。

注意：P2 不按数量阻断；缺证据不等于产品缺陷；提前门禁失败不取消独立安全检查；完成本轮评审不等于批准工件。

使用方式

用户提供 PRD 文件路径或直接粘贴 PRD 内容即可触发审查流程。

工作流程分为若干阶段：

  • 阶段零（准备）：读取 PRD 文档并确认文件路径，收集上下文（读取项目相关文档以验证业务现状描述、检查来源是否存在）。traceability metadata 校验须直接执行脚本，命令为：

    python3 "$TESTANY_ENG_ROOT/scripts/trace_lint.py" --format json <PRD文件路径>

    随后处理 trace-lint 结果：error/blocking issue 必须解析成具体缺陷或证据缺口并说明准出影响，不将脚本级别直接映射为产品 P0；warning 按实际影响分级，无实质风险的提示作为 optional/P2，不默认升级 P1；info 作为备注。不得跳过必要脚本而声称 metadata 通过。

  • 阶段一：按 8 大维度逐一审查并记录问题。

  • 阶段二：问题汇总与分级，计算各维度 1–5 星评分，确定审查结论（不通过、待补证据/未准出、通过）。

  • 阶段三：按审查报告模板输出结果，直接在对话中展示。

  • 阶段四：放行决策。不通过时要求修改 PRD，修改后可再次触发审查；待补证据时列出具体缺口、影响范围及补证动作，准出保持未批准；通过时输出准出证书，PRD 可进入 HLD 阶段。

审查通过时输出准出证书；如仍有 P2，放入“遗留建议 / Residual Suggestions”。

迭代审查：用户修改 PRD 后可再次调用进行复审，复审会记录“第 N 轮”，并在最终准出证书中展示审查历程。

适用场景

  • PRD 完成后需要评审、审查 PRD、进行需求评审。
  • 需要检查 PRD 质量是否达到准出标准。
  • 需要从 PM、开发、测试、业务方等多角色视角对 PRD 进行系统性检查。
  • 属于 BRD 拆分场景（1:N）的 PRD，需要检查覆盖范围与跨 PRD 依赖。

触发词包括：“审查 PRD”“review PRD”“PRD 评审”“需求评审”“检查 PRD 质量”“/prd-reviewer”。

核心原则与限制

核心原则包括：守门人心态（宁可多挑问题，不可漏过缺陷）；独立视角（假设从未见过该需求）；有限复审（只在授权修复与复审范围内继续，不为获得通过擅改 PRD）；基于证据挑战；360 度多角色审查；强制校验追溯元数据。

语言方面，默认跟随用户输入语言；用户显式指定时以用户指定为准；不因 SKILL.md 是中文而强制输出中文；TRACEABILITY-METADATA 的字段名、枚举值、ID、comment markers 始终保持英文；如使用模板或派发子任务，继续传递同一个 output_language。

禁止行为：禁止放水（不能因为“差不多”就放行）；禁止越权（不修改 PRD，只提出问题和建议）；禁止模糊反馈（问题描述必须具体，指出章节和内容并给出改进建议）；禁止无依据质疑。

参考文档包括：references/review-checklist.md、references/report-templates.md、references/report-templates.en.md，以及 traceability schema 相关文档。

关于收费、价格、平台支持范围等具体信息，资料中暂未提供。