PRD 歧义扫描

要解决什么问题

研发在评审 PRD 之前，常见问题不是「没写功能」，而是一词多义、未定义术语、段落间互相打架，以及「做什么」写清了、「做到什么程度」整类缺失。这类问题在评审会上往往不会被系统性提出来，却会在开发、联调、上线后变成返工和线上工单。

本技能在不代写完整 PRD、不擅自裁定业务规则的前提下，把用户粘贴的需求正文整理成可拿去问产品的材料。

技能如何工作

扫描输出五类结果：

• 歧义 — 模糊量词、术语口径不一致
• 缺口 — 状态机、权限、失败态、数据归属等未写清之处
• 冲突假设 — 前后段落结论不一致
• 待澄清问题清单 — 建议用「能否确认…」句式，按影响高/中/低排序
• 风险等级 — 便于研发优先处理阻碍项

每条问题通常包含：原文短摘录、问题说明、建议提问、影响级别。另设非功能需求专项：按性能与容量、权限与可见性、数据留存与删除、失败与边界、兼容与迁移、可观测、国际化/多端七维对照；PRD 未写 ≠ 无要求，不得用行业默认值填空，只有用户明确「本期不做/沿用现有标准」才可标不适用并记出处。该类缺口建议单独成组，避免混在功能歧义里被忽略。

适用边界

• 适合：评审前找坑；研发读完需求后列问题清单
• 不适合：直接代写一版 PRD；只要验收标准列表（可配合 acceptance-criteria-writer，先扫再写 AC）
• 红线：不把猜测写成「产品已决定」；不删改用户需求结论；原文过短则先列「信息不足以评审」再扫
• 限制：不验证业务真实性、不读外部需求系统；覆盖度依赖原文质量；非功能七维不覆盖行业强制条款（如医疗、金融专项）