PRD文档审核

先解决什么问题

许多 PRD 在评审会上看起来“讲清楚了”，真正到开发与测试落地时，才会暴露三类硬伤：范围边界没有被显式约束、文档文字与逻辑不足以指导实现、验收标准缺失或相互冲突。结果就是研发按理解实现，测试按理解写用例，返工成本高。这个技能的目标不是改写产品经理的话术，而是把一份需求文档投进一套固定检查维度里，输出可追踪的问题清单，让“哪里不清楚、为什么不通过、下一步改什么”直接落在纸面。

核心能力与关键步骤

技能按固定五维审核，名称与顺序不可改写：需求边界、文章易读性、文章整体的逻辑性、能否指导开发进行开发、能否指导测试进行测试用例编写和测试。每个维度必须给出：结论（通过 / 部分通过 / 不通过）、依据、具体问题，并引用文档章节或原文片段来支撑判断，而不是泛泛评价。

执行流程也很明确：

1. 先确认输入：用户提供的 PRD 文件路径或粘贴文本；如果材料缺失，先索取再开始审核。
2. 通读全文，先建立对范围、角色、主流程、业务规则与验收的整体印象。
3. 打开 checklist.md，按照五维检查点逐项核对，而不是凭经验自由发挥。
4. 汇总问题并标注严重程度：严重 / 建议，同时给出可执行的修订建议。
5. 按报告模板输出结构化审核结果：每个维度有结论与依据，有问题清单与修改方向，并给出总评。

在判定口径上，技能把“严重”定义为会导致范围不清、开发无法落地、测试无法写出可判定用例，或存在明显矛盾；“建议”则是不影响主流程落地，但会降低效率或引入歧义。并且规则明确：任一维度存在未解决的“严重”问题，总评不得判为“通过”，避免用一句“整体还行”把关键风险吞掉。

适用边界与注意点

这套方法适合结构化、可追溯的 PRD / 需求文档审核，尤其是团队希望把质量关口前移到需求阶段时使用。它不替代产品决策，也不负责直接改写业务方案；它能做的是把文档放在统一维度下检查，并把修订建议写成可执行条目。使用时需要注意两点：一是检查深度依赖 checklist.md 的覆盖度，技能应严格按清单执行，而不是只挑显眼问题；二是审核结论必须可回溯，尽量指出章节 / 原文片段，否则团队很难据此修改。

附加资源

• checklist.md：提供五维详细检查点，用于逐项核对并形成一致评审口径。