# Product Multi Role Stepwise Requirement Review

> 多角色分步骤需求评审；模拟5角色从完整性、一致性、可测试性三维度审查需求文档；输出优先级排序的问题清单

- Skill: `signjing/product-multi-role-stepwise-requirement-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add signjing/product-multi-role-stepwise-requirement-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/signjing/product-multi-role-stepwise-requirement-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: signjing (https://skillmd.com/u/signjing)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/signjing/product-multi-role-stepwise-requirement-review

---


# 需求评审 Skill

## 任务目标
- 对用户提交的需求文档进行系统性多角色评审
- 从5个专业视角发现3类问题：完整性、一致性、可测试性
- 输出结构化的问题清单，含严重程度、问题类型、修改建议

## 评审流程

### 第一轮：完整性审查
**审查目标**：检查需求文档是否遗漏关键内容

**执行方式**：依次以5个角色身份发言，每个角色按固定格式输出

#### 【产品经理】
**视角**：用户场景和业务流程
**输出格式**：
```
【产品经理】完整性审查
场景覆盖分析：
- 已覆盖场景：<列举>
- 未覆盖场景：
  1. <场景名> — <缺失说明>
  2. <场景名> — <缺失说明>
业务流程缺口：
- 异常流程：<说明>
- 降级流程：<说明>
```

#### 【测试工程师】
**视角**：边界条件和异常路径
**输出格式**：
```
【测试工程师】完整性审查
边界条件缺失：
1. <边界条件> — <风险说明>
2. <边界条件> — <风险说明>
异常路径缺失：
- 输入异常：<说明>
- 状态异常：<说明>
- 依赖异常：<说明>
```

#### 【后端工程师】
**视角**：接口定义和数据结构
**输出格式**：
```
【后端工程师】完整性审查
接口定义缺失：
- <接口名>：<缺失说明>
- <接口名>：<缺失说明>
数据结构缺失：
- <数据实体>：<缺失说明>
状态流转缺失：
- <状态A> → <状态B>：<未定义说明>
```

#### 【前端工程师】
**视角**：用户操作路径和页面状态
**输出格式**：
```
【前端工程师】完整性审查
操作路径缺失：
- <用户操作>：<未定义说明>
- <用户操作>：<未定义说明>
页面状态缺失：
- <页面/组件>：<状态说明>
前后端契约缺失：
- <数据字段>：<契约说明>
```

#### 【业务运营】
**视角**：运营规则和配置策略
**输出格式**：
```
【业务运营】完整性审查
运营规则缺失：
1. <规则名>：<缺失说明>
配置项缺失：
- <配置项>：<默认值/范围说明>
兜底策略缺失：
- <场景>：<兜底说明>
```

---

### 第二轮：一致性审查
**审查目标**：检查需求内部是否存在矛盾

#### 【产品经理】
**视角**：业务规则逻辑矛盾
```
【产品经理】一致性审查
规则冲突：
1. <规则A> vs <规则B>：<矛盾说明>
2. <规则A> vs <规则B>：<矛盾说明>
前置条件矛盾：
- <场景>：<矛盾说明>
```

#### 【测试工程师】
**视角**：跨章节描述冲突
```
【测试工程师】一致性审查
功能描述冲突：
- 第<X>章 vs 第<Y>章：<冲突说明>
验收标准冲突：
- <标准A> vs <标准B>：<不一致说明>
```

#### 【后端工程师】
**视角**：数据定义前后不一致
```
【后端工程师】一致性审查
字段定义矛盾：
- <字段>：<位置1>定义为<定义1>，<位置2>定义为<定义2>
枚举值矛盾：
- <枚举>：<不一致说明>
状态定义矛盾：
- <状态>：<矛盾说明>
```

#### 【前端工程师】
**视角**：交互规则和视觉状态不一致
```
【前端工程师】一致性审查
交互规则冲突：
- <操作A> vs <页面B>：<不一致说明>
状态展示冲突：
- <状态>在<页面>显示<样式1>，在<页面>显示<样式2>
```

#### 【业务运营】
**视角**：运营规则与产品规则矛盾
```
【业务运营】一致性审查
规则打架：
- <运营规则> vs <产品规则>：<矛盾说明>
配置与功能矛盾：
- <配置> vs <功能>：<不一致说明>
```

---

### 第三轮：可测试性审查
**审查目标**：检查需求描述是否可被验证

#### 【产品经理】
**视角**：验收标准是否模糊
```
【产品经理】可测试性审查
模糊验收标准：
1. "<标准描述>" — 无法量化，建议改为"<量化标准>"
2. "<标准描述>" — 主观判断，建议增加"<客观指标>"
```

#### 【测试工程师】
**视角**：能否写出明确测试用例
```
【测试工程师】可测试性审查
无法测试的描述：
1. "<需求描述>" — <无法验证的原因>
2. "<需求描述>" — <无法验证的原因>
需要明确的点：
- <待明确项>
```

#### 【后端工程师】
**视角**：成功/失败判断条件是否明确
```
【后端工程师】可测试性审查
判断条件缺失：
1. "<逻辑描述>" — 成功/失败的边界未定义
2. "<逻辑描述>" — 异常情况处理未说明
```

#### 【前端工程师】
**视角**：交互效果是否有判定标准
```
【前端工程师】可测试性审查
无法验证的效果：
1. "<交互效果>" — <判定标准缺失>
展示效果模糊：
- "<效果描述>" — 建议增加"<具体标准>"
```

#### 【业务运营】
**视角**：效果指标是否量化
```
【业务运营】可测试性审查
无法量化的指标：
1. "<指标描述>" — 当前描述为"<主观描述>"，建议量化为"<具体目标>"
2. "<指标描述>" — 缺少"<基线/阈值>"
```

---

### 汇总轮：去重与问题清单

**执行步骤**：
1. 收集所有问题：汇总三轮中5个角色提出的全部问题
2. 去重合并：识别本质相同的问题，合并为一条
3. 定级输出：按严重程度排序输出问题清单

**去重规则**：
- **本质相同**即合并：不同角色描述的同一缺陷点，合并为一条
- 合并时保留**最高严重程度**
- 合并后在"发现角色"列标注所有发现该问题的角色
- 合并后在"补充视角"列标注其他角色的观察角度

**合并判断标准**：
| 场景 | 处理方式 |
|------|----------|
| 同一缺陷被多个角色提及 | 合并，保留最严重级别 |
| 不同章节描述同一问题 | 合并 |
| 同一问题的不同表现层面 | 合并，合并后描述应覆盖各层面 |

**问题清单输出格式**：

```
## 问题清单

| 序号 | 严重程度 | 问题类型 | 发现角色 | 补充视角 | 问题描述 | 修改建议 |
|------|----------|----------|----------|----------|----------|----------|
| 1 | 阻塞 | 完整性 | 后端工程师 | 测试工程师 | <描述> | <建议> |
| 2 | 重要 | 一致性 | 测试工程师 | 产品经理 | <描述> | <建议> |
| 3 | 建议 | 可测试性 | 产品经理 | - | <描述> | <建议> |

去重说明：共收集 N 个问题，合并去重后 M 个问题

## 优先级说明
- 阻塞：必须修改才能继续开发
- 重要：强烈建议修改，否则影响质量
- 建议：优化项，不影响核心流程
```

---

## 使用示例

**触发方式**：
用户粘贴或上传需求文档，发送"评审这个需求"或类似表达

**典型对话**：
```
用户：请评审这个需求文档
智能体：首先确认这是需求文档，然后开始第一轮完整性审查...
（按流程执行三轮审查+汇总）
```

## 注意事项
- 每个角色按固定格式输出，保持一致性
- 问题描述引用原文位置，便于定位
- 汇总时必须先去重再输出，避免重复问题
- 去重时保留最高严重程度，合并发现角色
- 排序规则：先按严重程度（阻塞 > 重要 > 建议），再按问题类型（完整性 > 一致性 > 可测试性）