signjing 需求评审
任务目标
对需求文档进行多角色独立评审，每个角色从专业视角输出问题和改进建议。
评审角色
| 角色 | 关注维度 |
|---|---|
| 产品经理 | 用户场景完整性、业务流程遗漏、验收标准清晰度 |
| 测试工程师 | 边界条件、异常路径、可测试性 |
| 后端工程师 | 数据流转闭环、规则二义性、实现一致性 |
| 前端工程师 | 交互断点、状态切换、操作路径覆盖 |
| 业务运营 | 规则合理性、兜底策略、配置灵活性 |
评审流程
- 接收需求文档 — 用户提供需求内容
- 角色独立评审 — 5个角色按序思考，各自输出本角色独特发现
- 去重整合 — 后置角色需跳过已提及内容，确保无重复
- 格式化输出 — 按角色分组输出
输出格式
每个角色只输出其他角色未提及的独特发现，避免信息重复：
【产品经理】
- 场景分析：<用户场景是否完整>
- 流程检查：<业务流程有无遗漏>
- 验收标准：<标准是否可衡量、可验证>
- 建议：<改进方向>
【测试工程师】
- 边界条件：<需要测试的边界情况>
- 异常路径：<可能的错误处理场景>
- 可测试性：<哪些描述无法写出测试用例及原因>
- 建议：<补充或明确的方向>
【后端工程师】
- 数据流转：<输入-处理-输出是否闭环>
- 规则明确性：<核心规则是否有二义性>
- 实现一致性：<不同开发者是否会有不同理解>
- 建议：<技术层面的补充要求>
【前端工程师】
- 交互完整性：<操作路径是否有断点>
- 状态覆盖：<各状态切换是否描述清楚>
- 异常反馈：<用户操作结果反馈是否完整>
- 建议：<交互细节补充>
【业务运营】
- 规则合理性：<现有规则是否符合业务实际>
- 兜底策略：<异常情况如何处理>
- 配置灵活度：<规则是否支持配置化调整>
- 建议：<运营视角的优化点>
使用示例
- 示例1：
- 输入：提供完整的产品需求文档（PRD）
- 预期产出：5个角色的独立评审意见
- 要点：评审内容需具体到条款，避免泛泛而谈
资源索引
本 Skill 无额外脚本或资源，纯自然语言评审任务。
注意事项
- 去重优先：后置角色必须先判断内容是否被前置角色覆盖，只输出独有发现
- 产品经理 → 测试工程师 → 后端工程师 → 前端工程师 → 业务运营（按此顺序）
- 例如：后端工程师发现"状态机描述不清"，测试工程师已提及类似问题则跳过
- 问题指出需具体，避免"建议进一步明确"等模糊表述
- 同一问题涉及多角色时，只在最相关的角色下输出，其他角色跳过