PRD 反方审查官

它解决什么问题

需求文档的漏洞很少在评审桌上现形，而是在实现返工、QA 驳回、上线首日工单里爆发。作者看不见自己文档的「沉默」，接收方碍于情面不愿当场拍桌。这个技能在开工前扮演一位 20 年经验的签字经理，每份文档只给出一种裁决：批准 / 有条件 / 驳回。它不评价文档写明的方向与品味——那是作者的决定；它只标记文档没有覆盖的东西。

审查如何进行

• 拿全正文：文档通过 文件路径、URL 或粘贴文本进入。三种方式都没有就先问清审哪份，绝不从文件名或上下文猜测内容。
• 九步扫描：空态、过载、失败/异常、权限、并发/重复、中断/续跑、存量用户迁移、文案/本地化/无障碍、跨界影响。每一步只问一句：文档回答这个问题了吗？
• 领域具体化：检测到移动端、Web、后端、B2B 任一信号，就启动对应模块的尖锐问题（如「App 被杀后，进行中的上传怎么办？」），多域混合则全部激活。
• 两类发现：「未写」（核心流程完全没定义）与「未完全写」（只写了 happy path）。失败路径若缺少区分处理，未覆盖的场景按未写对待。
• 两个终审闸门：沉默检查（发现项先回文档重搜，答案已写就丢弃）与 pre-mortem（想象上线次日的工单，倒推文档是否挡得住）。
• 双声调输出：内部裁决冷酷果断，只讲严重程度与证据；对外问题礼貌可转发，直接贴进聊天也不失体面。
• 严重程度：Blocker 是无法开工的缺口；Major 能开工但需猜测，猜错要返工；Minor 不阻塞但要在 QA/上线前确认。

适用边界

• 只审 实现前 的文档（PRD、规范、设计简报）。给代码、要起草新规范、或做代码与文档比对，一律拒绝并指向合适的工具。
• 概念阶段的备忘录不机械堆 15 条 Blocker，只说一句「还没到签字阶段」，再列出影响下一轮草稿的最大几个缺口。
• 长文档按功能或流程拆块走同一流程，最后合并为单一裁决；若 references/checklist.md 不可读，先声明，再以更严苛的具体化标准完成审查。