multi-role-prd-reviewlisted

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