你的 PRD 看起来没问题。这就是问题。
ship 到生产环境的缺陷，永远是你从内部看不到的缺陷。你整个 PM 职业生涯都在做房间里唯一看不到它们的人。
George（prodmgmt.world）认为这不是能力问题。各级 PM 都把写 PRD 描述为最难的部分。审查应该是轻松的部分，是 kickoff 前的胜利圈。然后高管审查发生，文档被某个三周来根本没碰过它的人在 15 分钟内撕碎。这种不对称感觉像针对个人，但原因是结构性的。
为什么你看不到自己的缺陷
写 PRD 时，你脑袋里的每个模糊点都已经变成了自信的句子。你写文档是为了说服，不是为了压力测试。等你重读时，你在读你想写的，不是你写的。
人类校对员通过倒着读来抓住拼写错误，因为正向阅读会触发大脑的模式补全，你会填入你想写的词。同样的机制适用于逻辑。你写了"用户可以实时编辑"和"我们离线优先同步"，你的大脑把它们读成两个独立的真命题，而不是对你从未决定构建的 CRDT 架构的静默承诺。
为什么人类审查也失败
传统修复方案是让同事或经理审查。实践中这在 FAANG 以下级别几乎从不产生结构性批评，即使在那里也被"谁读什么"的政治所塑造。
PRD 审查的社交动态天然对抗对抗性阅读：
- 审查者是也有自己 PRD 要写的同事，不想开启一场耗时的对抗
- 审查者是本周要批准五份文档的经理，没有带宽为每个文档建模架构影响
- 审查者是 EM，他对好 PRD 的心理模型是"足够具体让工程能估算"，不是"内部一致到不会静默承诺我们没选择的未来"
所以文档得到措辞评论、几个澄清问题、一个盖章。结构性缺陷存活下来。它们存活到功能 ship、支持工单开始涌入、有人问这怎么通过审查的。诚实答案是没人对抗性地读过它。他们同情地读了它——这是审查者对会在午餐时见到的同事默认会做的事。
AI 对抗性审查：不是"有没有冲突"
几乎还没有 PM 在用的廉价修复方案是：在送给人之前，先把 PRD 过一遍对抗性审查者。
有趣的部分不是你用 AI 做这个。有趣的是你怎么 prompt 它。
如果你问 AI"这些需求有没有冲突？"，AI 回答有或没有。它可能列几个听起来通用的矛盾。输出正确且无用。感觉像 checklist，因为你要求的就是 checklist。
如果你改问 AI"扮演一个强硬、不讲理的高级产品高管，那种 ship 过四个产品、对实现中会坏什么变得不讲理地具体的人，审查这份 PRD"，输出形状就变了。
这个角色有观点。角色命名具体的矛盾："你的用户可以实时编辑的需求与你的离线优先同步需求冲突，后者静默承诺你要构建一个 CRDT 系统却不说出来。两台设备重连时谁拥有冲突解决 UX？"
一个是 checkbox。另一个是 contextual catch，能 survive cover test：不处理这个点很难 defend 这份 PRD。
三种最常见的隐藏缺陷
一个 prompt 得好的 tough-exec 角色会 surface 几种在人类审查中几乎从不被抓到的具体失败模式。其中三种最值得命名，因为它们泛化最广。
1. 未声明的交接（The Unstated Handoff）
你的 PRD 说"推荐引擎将与通知系统集成。"谁拥有这个集成？两个系统之间的契约是什么？当推荐团队的 sprint 优先级与通知团队冲突时会发生什么？
你没回答是因为你没意识到你在静默承诺两个团队做一个没人拥有的交接。这个角色抓住它，因为角色的职责是问"谁做这工作"，而你的职责是假设它会被完成。
2. 静默冲突（The Silent Conflict）
你的 PRD 第三节说"用户可以随时导出所有数据"，第七节说"我们压缩归档数据以优化成本。"这不是同一个需求。它们以只有同时把两者放在工作记忆中才会浮现的方式冲突，而人类审查者不会自然地这样做，因为他们在线性阅读。
角色找到它，因为角色把文档当作整体读，而不是当作段落序列。
3. 拥有战略的 TBD（The TBD That Owns the Strategy）
你的 PRD 说"企业访问控制，细节 TBD。"这是一个被打扮成占位符的延期战略决策，它将在压力下被做出——可能是在你 $2M ARR 潜在客户的安全审查期间，可能由 PRD 写作时不在房间的人做出。
PRD 中的每个"TBD"都是一份未来谈判，交给客户安全问卷到达时刚好 on call 的工程师。角色命名这个，因为角色见过 TBD 变成 deal-breaker 时会发生什么，它知道"我们晚点再 figuring out"是产品管理中最昂贵的句子。
时间投资的不对称
初级 PM 花三周写 PRD。高管 15 分钟撕碎它。这两个数字之间的差距是产品管理中最令人沮丧的经历之一。
对抗性 AI 在 PM 进房间前抓住高管会抓住的大部分东西。成本是 15 分钟和零地位。PM 私下修复结构性缺陷，然后带着已经 survive 过它即将面对的那种批评的文档走进审查。高管觉得 PM 异常敏锐。实际上 PM 停止给人类看初稿，开始给他们看第三版。
对初级 PM 来说，二阶效应才重要。你可以运行 Director 级别的批评角色，而不承担向真实 Director 展示未成熟作品的政治风险。你得到反馈，没有地位成本。你在前三次高管审查中不被撕碎所保护的职业资产是真实的，而且大部分是隐形的——直到你看着一个同事被撕碎，意识到你曾经是那个同事。
三阶效应：判断力编码
比前两个都重要的三阶效应是：连续六个月让每个 PRD 过对抗性批评的 PM 获得复利收益——他们建立模式识别。
二十轮"这个需求静默承诺你构建 X"之后，他们开始在写进去之前抓住战略角落。判断力编码进自身。他们变成不同类型的 PM，不是因为他们有新工具，而是因为他们有被结构化反馈塑造的新习惯。
这是我认为被低估的部分。你在第一个月修复的 PRD 值得练习。你在第十二个月不需要修复的 PRD——因为你从没写出那个缺陷——才是真正的产品。
如何实践
自己写 tough-exec 角色 prompt 很直接；难的是在你需要时准备好它，把它接入你实际运行的工作流，以及能跨 PRD 比较批评因为结构一致。
维持这个系统的纪律是当你试图手工维护时最先 decay 的部分。
George 的 PM OS 预建了 200+ skills，包括 tough-exec 角色，批评跨六个维度结构化：跨团队交接、冲突需求、可维护性、战略影响、清晰度、可行性。你粘贴 PRD，得到批评，每次结构相同。Skill 与操作层的其余部分组合，所以同一个角色可以审查你的路线图、one-pager 或 post-mortem，无需重写 prompt。