signjing 需求评审 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. "<指标描述>" — 缺少"<基线/阈值>"
汇总轮：去重与问题清单
执行步骤：
- 收集所有问题：汇总三轮中5个角色提出的全部问题
- 去重合并：识别本质相同的问题，合并为一条
- 定级输出：按严重程度排序输出问题清单
去重规则：
- 本质相同即合并：不同角色描述的同一缺陷点，合并为一条
- 合并时保留最高严重程度
- 合并后在"发现角色"列标注所有发现该问题的角色
- 合并后在"补充视角"列标注其他角色的观察角度
合并判断标准：
| 场景 | 处理方式 |
|---|---|
| 同一缺陷被多个角色提及 | 合并，保留最严重级别 |
| 不同章节描述同一问题 | 合并 |
| 同一问题的不同表现层面 | 合并，合并后描述应覆盖各层面 |
问题清单输出格式：
## 问题清单
| 序号 | 严重程度 | 问题类型 | 发现角色 | 补充视角 | 问题描述 | 修改建议 |
|------|----------|----------|----------|----------|----------|----------|
| 1 | 阻塞 | 完整性 | 后端工程师 | 测试工程师 | <描述> | <建议> |
| 2 | 重要 | 一致性 | 测试工程师 | 产品经理 | <描述> | <建议> |
| 3 | 建议 | 可测试性 | 产品经理 | - | <描述> | <建议> |
去重说明：共收集 N 个问题，合并去重后 M 个问题
## 优先级说明
- 阻塞：必须修改才能继续开发
- 重要：强烈建议修改，否则影响质量
- 建议：优化项，不影响核心流程
使用示例
触发方式： 用户粘贴或上传需求文档，发送"评审这个需求"或类似表达
典型对话：
用户：请评审这个需求文档
智能体：首先确认这是需求文档，然后开始第一轮完整性审查...
（按流程执行三轮审查+汇总）
注意事项
- 每个角色按固定格式输出，保持一致性
- 问题描述引用原文位置，便于定位
- 汇总时必须先去重再输出，避免重复问题
- 去重时保留最高严重程度，合并发现角色
- 排序规则：先按严重程度（阻塞 > 重要 > 建议），再按问题类型（完整性 > 一致性 > 可测试性）