PRD Review

对需求文档进行系统性风险识别和评分，提供深度根因分析及可执行改进建议，助力决策和项目推进。

requirement-review - 需求文档深度评估 Skill

能力描述

对 PRD/需求文档进行深度聚焦式评估，识别系统性风险和根因问题，提供可执行的改进建议。

核心特点：

• 🔍 深度聚焦：Top 3 风险 + Top 3 建议，每个都深挖根因
• 📊 量化评分：5 维度综合评分，明确是否建议进入开发
• 🔗 行业对标：参考头部产品做法，避免闭门造车
• 💰 成本评估：分析"现在做"vs"后期还债"的成本差异
• 🚦 决策清单：明确什么必须改（阻塞）、什么可以延后

---

使用方式

触发条件

用户提供需求文档（Feishu 云文档链接、Markdown 文本、或文件），说：

• "评估这个需求文档"
• "帮我看看这个 PRD"
• "review 一下这个需求"

输入要求

必需：

• 需求文档内容（链接或文本）

可选：

• 评估重点（如"重点关注风险"、"看看有没有遗漏"）
• 项目背景（如"这是 P0 项目，下周上线"）

---

评估框架

一、综合评分（5 维度）

维度	权重	评估要点
结构完整性	20 分	背景/目标/用户故事/验收标准是否完整
逻辑一致性	25 分	需求之间无矛盾、优先级清晰、依赖关系明确
可执行性	25 分	需求具体可转化、技术可行、资源/时间有估算
价值对齐	20 分	与业务目标一致、ROI 清晰、有 MVP 思路
表达质量	10 分	语言简洁无歧义、术语一致、图表辅助

决策阈值：

• ≥80 分：🟢 建议进入开发
• 70-79 分：🟡 有条件进入开发（需解决阻塞问题）
• <70 分：🔴 建议迭代后再评审

---

二、Top 3 风险（深度分析模板）

每个风险必须包含：

markdown

### 风险 X：[一句话概括本质]

> 引用原文关键描述

**深层问题：**
这不是"[表面问题]"，而是"[本质问题]"。

**风险场景分析：**
| 场景 | 当前逻辑 | 风险 |
|------|---------|------|
| 场景 1 | ... | ... |
| 场景 2 | ... | ... |

**为什么这是系统性风险：**
- 短期影响：...
- 长期影响：...
- 修复成本：现在是 X，后期是 5-10X

**真正的问题：**
[一句话点破产品设计背后的真实问题]

---

三、Top 3 建议（深挖根因模板）

每个建议必须包含：

markdown

### 建议 X：[从"当前设计"改为"建议设计"]

**当前设计：** [描述现状]
**建议设计：**

[结构化描述建议方案]

text

**为什么这样设计：**
- [理由 1]
- [理由 2]

**行业参考：** [对标产品做法]

**成本评估：**
- 实现成本：[增加 X% 工作量]
- 不做的成本：[后期重构成本是现在的 5-10 倍 / 安全合规风险 / ...]

---

四、决策建议

markdown

## 🚦 决策建议

**必须解决（阻塞开发）：**
1. [问题] + [对应风险/建议编号]
2. ...

**可延后（不影响上线）：**
- [问题] + [原因]

**建议上线节奏：**
- Week 1：[任务]
- Week 2-3：[任务]
- ...

---

输出格式

markdown

# 📋 需求文档评估（深度聚焦版）

## 综合评分：**XX/100** 🟡 有条件进入开发

---

## 🔴 Top 3 风险（深度分析）

### 风险 1：...

### 风险 2：...

### 风险 3：...

---

## 💡 Top 3 建议（深挖根因）

### 建议 1：...

### 建议 2：...

### 建议 3：...

---

## ✅ 亮点（保持）

- ...

---

## 🚦 决策建议

**必须解决（阻塞开发）：**
1. ...

**可延后（不影响上线）：**
- ...

**建议上线节奏：**
- ...

---

评估原则

✅ 要做

1. 深挖根因：不问"有什么问题"，问"为什么这是问题"
2. 系统思考：单个功能问题 → 系统性风险
3. 成本视角：现在做 vs 后期还债的成本对比
4. 行业对标：头部产品怎么做，为什么
5. 可执行：每个建议都有具体方案，不是空话

❌ 不做

1. 表面问题："文案有错别字"、"格式不统一"（除非影响理解）
2. 主观偏好："我觉得应该..."（没有依据的个人意见）
3. 过度设计：建议超出当前项目范围的功能
4. 模糊建议："建议优化"、"需要考虑"（无具体方案）

---

迭代机制

每次评估后自问：

1. 风险是否挖到了根因？还是停留在表面？
2. 建议是否可执行？开发拿到能直接做吗？
3. 决策清单是否清晰？什么是阻塞项、什么是可延后？
4. 行业对标是否有说服力？是真实案例还是编造？

用户反馈循环：

• 如果用户说"不够深" → 加强根因分析，多问"为什么"
• 如果用户说"太复杂" → 保持深度，精简表达
• 如果用户说"没用" → 检查建议是否可执行、是否有成本评估

---

示例（蓝湖引流 PRD 评估）

风险示例

原文："导入后，LH 新增成员不会自动同步到 MG 团队" + "减员无需同步"

深层问题： 这不是"功能设计"，而是数据一致性债务。

风险场景：

场景	当前逻辑	风险
LH 新增成员	不同步	新人无法访问 MG 团队资源 → 体验割裂
LH 成员离职	不同步	离职人员仍保留 MG 权限 → 安全合规风险

为什么这是定时炸弹：

• 企业客户审计时会发现权限不一致
• 一旦出安全事件，责任归属不清
• 后期修复成本远高于现在设计完整同步逻辑

---

版本历史

• v1.0 (2026-03-07)：初始版本，基于 3 轮迭代沉淀
  • 5 维度评分框架
  • Top 3 风险 + Top 3 建议深度分析模板
  • 决策清单（阻塞项 vs 可延后）
  • 行业对标 + 成本评估要求