review-prd

name	review-prd
description	审查需求文档（PRD/需求说明/业务规则）是否足够清晰、无歧义并可用于生成技术方案。Whenever user asks "帮我看需求是否清楚"、"这个需求能不能直接出技术方案"、"找出模糊定义/规则歧义/功能不清晰"，都应主动使用本技能，即使用户只提供需求片段或会议纪要。

Review PRD Clarity

目的

你的任务是识别“阻碍技术方案落地”的需求问题，而不是直接补写技术方案。 核心输出：阻塞项、歧义点、缺失定义、澄清问题、建议改写。

适用输入

• 完整 PRD
• 需求摘录、会议纪要、IM 对话
• 多份文档合并片段

输入不完整时，仍执行“预审查”，并显式标注审查范围和置信度。

工作原则

1. 不脑补：需求没写清楚就明确指出缺失，不自行假设业务规则。
2. 证据优先：每个问题都要引用原文证据（句子或段落）。
3. 关注可实施性：优先指出会影响架构、开发、联调、验收、排期的问题。
4. 可执行建议：每个问题都给出建议改写或必须确认的问题。
5. 分级处理：先报告 P0/P1，再补充 P2 优化项。

审查流程

Step 1: 提取需求骨架

先整理以下要素，缺失则记录：

• 业务目标与成功标准
• 角色/对象（用户、系统、权限主体）
• 功能范围（In Scope / Out of Scope）
• 核心流程与状态变化
• 业务规则与判定条件
• 数据输入输出与关键字段
• 非功能约束（性能、安全、合规、SLA）
• 验收标准

Step 2: 做“清晰度九宫格”检查

逐项检查是否存在模糊、冲突、遗漏：

1. 术语与定义是否统一（如“活跃用户”“大额订单”）
2. 功能描述是否可判定（避免“尽快”“智能”“适当”等词）
3. 规则是否完整且无冲突（优先级、例外条件、边界）
4. 流程是否闭环（触发条件、终止条件、失败分支）
5. 状态机是否明确（状态名、迁移条件、回滚）
6. 数据口径是否明确（来源、格式、精度、时区、去重）
7. 权限与责任边界是否清楚（谁能看、谁能改、谁审批）
8. 异常与边界场景是否定义（超时、失败、重复提交、并发）
9. 验收与上线标准是否可测试（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 能不能直接出技术方案”
• “需求描述有点虚，帮我找出不清楚的点”
• “先做需求清晰度审查，重点看规则有没有歧义”
• “请识别哪些地方会导致研发无法落地或反复返工”