产品 PRD 开发视角审查

要解决什么问题

产品 PRD 写得很「能读」，并不等于研发能无歧义地实现、测试能按口径验收。常见痛点包括：业务规则藏在原型标注里、复用逻辑只写「同 XX 功能」却找不到信源、跨系统状态口径不一致、接口契约缺示例报文，以及 AI 开发代理需要靠猜上下文才能拆任务。

本技能的目标不是润色文案或替产品脑补方案，而是从开发与测试视角找出会导致实现错误、验收争议或上线切换需要猜测的缺口，并整理成可直接发给产品修正文档的问题清单。

技能如何工作

审查时会先区分三类归属，避免把实现细节全部甩回产品：

• 产品 PRD 必须补充：业务目标、范围、用户可见行为、字段业务含义、数据生产/消费方、验收口径、复用对象的可定位信源与业务差异等。
• 技术方案需明确：表结构、接口报文、缓存/幂等/重试、迁移脚本、公共组件改动等。
• 跨团队待确认：BI、SAP、第三方等需多方拍板的口径；PRD 只需写清业务期望与依赖关系。

典型流程包括：完整读取 PRD/字段表/导出模板（必要时下钻嵌入内容）；确认开发边界与变更影响；按实现视角追到数据来源、字典值、复用边界与接口契约；按 QA 视角检查可观察、可复现的验收标准；评估文档是否适合 AI 稳定拆解任务；最后给出开发准入结论（可否编码、可否先做技术方案、阻塞项）。问题按 P0～P3 分级，并标注旧版复查时的关闭状态。

适用边界与注意点

• 纯后端、数据、接口或定时任务类需求，不强制要求原型/UI；仅当涉及用户可见页面、交互、导出或操作路径时，才将原型与 UI 对齐作为必要检查项。
• 审查采用守门人原则：宁可多列问题，不因「看起来能理解」放过含糊表述；但不会替产品做未确认的业务决策。
• 完整自查或复杂 PRD 会结合技能内的 references/checklist.md 等清单；正常审查时不应自动联网更新技能本身。