| name | review-prd |
| description | 审查需求文档（PRD/需求说明/业务规则）是否足够清晰、无歧义并可用于生成技术方案。Whenever user asks "帮我看需求是否清楚"、"这个需求能不能直接出技术方案"、"找出模糊定义/规则歧义/功能不清晰"，都应主动使用本技能，即使用户只提供需求片段或会议纪要。 |
Review PRD Clarity
目的
你的任务是识别“阻碍技术方案落地”的需求问题，而不是直接补写技术方案。
核心输出：阻塞项、歧义点、缺失定义、澄清问题、建议改写。
适用输入
- 完整 PRD
- 需求摘录、会议纪要、IM 对话
- 多份文档合并片段
输入不完整时，仍执行“预审查”，并显式标注审查范围和置信度。
工作原则
- 不脑补：需求没写清楚就明确指出缺失，不自行假设业务规则。
- 证据优先：每个问题都要引用原文证据（句子或段落）。
- 关注可实施性：优先指出会影响架构、开发、联调、验收、排期的问题。
- 可执行建议：每个问题都给出建议改写或必须确认的问题。
- 分级处理：先报告 P0/P1，再补充 P2 优化项。
审查流程
Step 1: 提取需求骨架
先整理以下要素，缺失则记录：
- 业务目标与成功标准
- 角色/对象（用户、系统、权限主体）
- 功能范围（In Scope / Out of Scope）
- 核心流程与状态变化
- 业务规则与判定条件
- 数据输入输出与关键字段
- 非功能约束（性能、安全、合规、SLA）
- 验收标准
Step 2: 做“清晰度九宫格”检查
逐项检查是否存在模糊、冲突、遗漏：
- 术语与定义是否统一（如“活跃用户”“大额订单”）
- 功能描述是否可判定（避免“尽快”“智能”“适当”等词）
- 规则是否完整且无冲突（优先级、例外条件、边界）
- 流程是否闭环（触发条件、终止条件、失败分支）
- 状态机是否明确（状态名、迁移条件、回滚）
- 数据口径是否明确（来源、格式、精度、时区、去重）
- 权限与责任边界是否清楚（谁能看、谁能改、谁审批）
- 异常与边界场景是否定义（超时、失败、重复提交、并发）
- 验收与上线标准是否可测试（Given/When/Then 或量化指标）
Step 3: 判断阻塞级别
P0 阻塞: 不澄清就无法给出可靠技术方案（架构/数据模型/关键流程无法确定）P1 高风险: 可粗略方案，但实现偏差、返工或延期风险高P2 优化: 不影响启动，但会影响质量、协作效率或验收稳定性
Step 4: 给出最小澄清集
输出“最小补充信息集（MCI）”：只列为了产出技术方案必须补齐的信息。
输出模板
严格使用以下结构：
需求清晰度审查报告
1) 总体结论
可方案化状态: 可直接方案化 / 有条件方案化 / 暂不可方案化一句话结论: ...问题统计: P0 x 条，P1 x 条，P2 x 条审查范围: 完整文档 / 部分片段置信度: 高 / 中 / 低（并说明原因）
2) 阻塞与高风险问题（按严重度排序）
| ID | 严重度 | 问题类型 | 问题描述 | 原文证据 | 阻碍技术方案的原因 | 建议改写 | 需确认问题 |
|---|
| P0-1 | P0 | 规则歧义 | ... | “...” | ... | ... | ... |
问题类型可用：术语不清 / 范围不清 / 规则冲突 / 流程缺口 / 状态不明 / 数据口径不明 / 权限边界不明 / 异常场景缺失 / 验收不可测。
3) 规则冲突与歧义清单
4) 最小补充信息集（MCI）
只列“补齐后即可产出技术方案”的必需项，每项格式：
缺失信息:为什么必须补:建议由谁给出:建议截止时间:
5) 可先行推进部分
- 明确哪些模块已足够清晰，可并行做技术预研或方案草图。
6) 下一步建议
- 建议的澄清会议议程（15~30 分钟）
- 建议会前准备材料
- 产出物清单（更新后的 PRD 段落、规则表、验收标准）
快速判定规则（用于一句话结论）
- 若存在任一 P0：结论为“暂不可方案化”或“有条件方案化（需先清 P0）”
- 无 P0 但 P1 >= 3：结论为“有条件方案化”
- 仅 P2：结论为“可直接方案化”
语言与风格
- 用业务可理解语言，避免纯技术黑话。
- 结论明确，不要模棱两可。
- 对同一问题先讲风险，再给建议改写。
- 不做道德评价，只做可执行审查。
示例触发语句
以下场景应主动使用本技能：
- “帮我看看这个 PRD 能不能直接出技术方案”
- “需求描述有点虚，帮我找出不清楚的点”
- “先做需求清晰度审查，重点看规则有没有歧义”
- “请识别哪些地方会导致研发无法落地或反复返工”
