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 风险（深度分析模板）
每个风险必须包含：
### 风险 X：[一句话概括本质]
> 引用原文关键描述
**深层问题：**
这不是"[表面问题]"，而是"[本质问题]"。
**风险场景分析：**
| 场景 | 当前逻辑 | 风险 |
|------|---------|------|
| 场景 1 | ... | ... |
| 场景 2 | ... | ... |
**为什么这是系统性风险：**
- 短期影响：...
- 长期影响：...
- 修复成本：现在是 X，后期是 5-10X
**真正的问题：**
[一句话点破产品设计背后的真实问题]
三、Top 3 建议（深挖根因模板）
每个建议必须包含：
### 建议 X：[从"当前设计"改为"建议设计"]
**当前设计：** [描述现状]
**建议设计：**
[结构化描述建议方案]
**为什么这样设计：**
- [理由 1]
- [理由 2]
**行业参考：** [对标产品做法]
**成本评估：**
- 实现成本：[增加 X% 工作量]
- 不做的成本：[后期重构成本是现在的 5-10 倍 / 安全合规风险 / ...]
四、决策建议
## 🚦 决策建议
**必须解决（阻塞开发）：**
1. [问题] + [对应风险/建议编号]
2. ...
**可延后（不影响上线）：**
- [问题] + [原因]
**建议上线节奏：**
- Week 1：[任务]
- Week 2-3：[任务]
- ...
输出格式
# 📋 需求文档评估（深度聚焦版）
## 综合评分：**XX/100** 🟡 有条件进入开发
---
## 🔴 Top 3 风险（深度分析）
### 风险 1：...
### 风险 2：...
### 风险 3：...
---
## 💡 Top 3 建议（深挖根因）
### 建议 1：...
### 建议 2：...
### 建议 3：...
---
## ✅ 亮点（保持）
- ...
---
## 🚦 决策建议
**必须解决（阻塞开发）：**
1. ...
**可延后（不影响上线）：**
- ...
**建议上线节奏：**
- ...
评估原则
✅ 要做
- 深挖根因：不问"有什么问题"，问"为什么这是问题"
- 系统思考：单个功能问题 → 系统性风险
- 成本视角：现在做 vs 后期还债的成本对比
- 行业对标：头部产品怎么做，为什么
- 可执行：每个建议都有具体方案，不是空话
❌ 不做
- 表面问题："文案有错别字"、"格式不统一"（除非影响理解）
- 主观偏好："我觉得应该..."（没有依据的个人意见）
- 过度设计：建议超出当前项目范围的功能
- 模糊建议："建议优化"、"需要考虑"（无具体方案）
迭代机制
每次评估后自问：
- 风险是否挖到了根因？还是停留在表面？
- 建议是否可执行？开发拿到能直接做吗？
- 决策清单是否清晰？什么是阻塞项、什么是可延后？
- 行业对标是否有说服力？是真实案例还是编造？
用户反馈循环：
- 如果用户说"不够深" → 加强根因分析，多问"为什么"
- 如果用户说"太复杂" → 保持深度，精简表达
- 如果用户说"没用" → 检查建议是否可执行、是否有成本评估
示例（蓝湖引流 PRD 评估）
风险示例
原文："导入后，LH 新增成员不会自动同步到 MG 团队" + "减员无需同步"
深层问题： 这不是"功能设计"，而是数据一致性债务。
风险场景：
| 场景 | 当前逻辑 | 风险 |
|---|---|---|
| LH 新增成员 | 不同步 | 新人无法访问 MG 团队资源 → 体验割裂 |
| LH 成员离职 | 不同步 | 离职人员仍保留 MG 权限 → 安全合规风险 |
为什么这是定时炸弹：
- 企业客户审计时会发现权限不一致
- 一旦出安全事件，责任归属不清
- 后期修复成本远高于现在设计完整同步逻辑
版本历史
- v1.0 (2026-03-07)：初始版本，基于 3 轮迭代沉淀
- 5 维度评分框架
- Top 3 风险 + Top 3 建议深度分析模板
- 决策清单（阻塞项 vs 可延后）
- 行业对标 + 成本评估要求