PRD 歧义扫描
用途
在需求评审前，对用户粘贴的 PRD/需求稿做扫描，交付：
- 歧义 — 一词多义、未定义术语、模糊量词
- 缺口 — 缺状态机/权限/失败态/数据归属等
- 冲突假设 — 段落间互相矛盾之处
- 待澄清问题清单 — 可直接拿去问产品
- 风险等级 — 高/中/低（阻碍开发者优先）
空表见 references/ambiguity-scan-template.md。
本技能不代写完整 PRD，不主写验收标准（可用 acceptance-criteria-writer），不擅自裁定业务规则。
适用场景
- 适合: 评审前找坑；研发读需求后列问题。
- 不适合: 「直接帮我写一版 PRD」「只要 AC 列表」。
怎么使用(普通用户)
- 「用 PRD 歧义扫描，评审前扫这份需求」
- 「标出含糊点和要问产品的问题，先别写 AC」
- 「看看有没有互相打架的假设」
使用步骤
1. 获取原文
用户粘贴需求正文；过短则提示补充。不臆造未出现的功能。
2. 分三类标注
每条含：原文摘录（短）、问题说明、建议提问、影响（高/中/低）。
3. 输出问题清单
按影响降序；问题用「能否确认…」句式，便于评审会使用。
3.1 非功能需求专项（最常见的整类缺口）
PRD 写清了「做什么」却不写「做到什么程度」，是缺口里最成体系的一类——它不会在评审会上被提出，却会在上线后变成事故。逐项对照，PRD 未提及的一律进缺口而不是默认值：
| 维度 | 该问什么 | 不问的后果 |
|---|---|---|
| 性能与容量 | 预期并发/数据量级？可接受响应时间？超出后是排队、降级还是报错？ | 按小数据量实现，上量即崩 |
| 权限与可见性 | 谁能看、谁能改？跨部门/跨租户是否隔离？导出受不受限？ | 上线后才发现越权可见，只能紧急下线 |
| 数据留存与删除 | 存多久？谁能删？删除是软删还是硬删？ | 与隐私要求冲突，需返工改存储 |
| 失败与边界 | 依赖不可用时怎么办？部分成功如何呈现？重复提交如何处理？ | 每个异常分支都成为线上工单 |
| 兼容与迁移 | 存量数据怎么办？旧版本客户端如何处理？ | 发版即产生两套不兼容数据 |
| 可观测 | 出问题时怎么定位？需要哪些埋点或日志？ | 故障时无从排查 |
| 国际化/多端 | 是否需多语言、多时区、多端一致？ | 后期改造成本远高于一开始设计 |
判定规则：
- 非功能项未写 ≠ 无要求，一律列入缺口并标注影响；不得用「一般都是……」补默认值。
- 只有用户明确说「本期不做/沿用现有标准」时才可标不适用，并记下这句话的出处。
- 本节缺口通常整类缺失（而非单点），建议在待澄清问题里单独成组呈现，避免混在功能歧义中被忽略。
4. 红线
- 不把猜测写成「产品已决定」
- 不删改用户需求结论，只列问题
- 不为非功能项填写行业默认值——未写就是缺口
输出格式
# PRD 歧义扫描：{标题或主题}
## 摘要
- 高风险项数: …
- 建议会前必答: …
## 歧义
1. …
## 缺口
1. …
## 冲突假设
1. …
## 待澄清问题（按优先级）
1. …
## 备注
- 本扫描不替代产品决策；未列出不等于无其他风险
示例
输入（节选）:
标题: 订单备注
正文: 用户可在下单时填写备注；备注很长时也要支持；客服要能看到；有的备注要加密；默认大家都看得到。
输出（节选）:
# PRD 歧义扫描：订单备注
## 摘要
- 高风险项数: 2
- 建议会前必答: 长度上限；谁可见；何为「加密」
## 歧义
1. 「很长」无上限与单位 → 问: 最大字符数/是否允许附件？
2. 「大家都看得到」与「有的要加密」主语不清 → 问: 默认可见角色与加密触发条件？
## 缺口
1. 缺编辑/删除时效与审计 → 问: 支付后能否改备注？
2. 缺敏感词/违规内容策略 → 问: 是否过滤/人工审？
## 冲突假设
1. 「默认大家都看得到」vs「有的备注要加密」可能冲突 → 需统一可见性模型
## 待澄清问题（按优先级）
1. 备注长度与存储上限是多少？
2. 默认可见角色有哪些？加密备注的密钥/权限模型是什么？
3. 下单后是否允许修改备注？
常见问题(FAQ)
- 用户要我直接改 PRD: 只给问题清单，改写需用户明确要求且另开任务。
- 只要验收标准: 引导
acceptance-criteria-writer，可先扫再写 AC。 - 原文极短: 先列「信息不足以评审」的缺口，再扫。
已知限制
- 不验证业务真实性
- 不读取外部需求系统
- 覆盖度依赖原文质量
- 非功能专项按七维对照，不覆盖行业特有的专项要求（如医疗、金融的强制条款）
变更说明
- 0.1.1: 新增「非功能需求专项」（原扣分点）——七维对照表（性能容量、权限可见性、数据留存删除、失败与边界、兼容迁移、可观测、国际化多端），各给「该问什么」与「不问的后果」；配三条判定规则：未写不等于无要求、不得填行业默认值、只有用户明说不做才可标不适用且需记出处；并要求该类缺口单独成组呈现，避免混在功能歧义中被忽略。红线补「不为非功能项填写行业默认值」。
- 0.1.0: 首发。把需求文档整理成歧义、缺口与冲突假设三类问题清单。
