Prd Prototype Review

PRD与产品原型深度评审专家。读取需求PRD和产品原型文档，按多维度进行严苛但建设性的评审，输出结构化评审报告，并自动落地补丁到PRD和原型文档中。当用户要求"评审PRD/原型"、"review需求文档"、"检查原型完整性"、"补充异常分支/边界情况"、"评审报告"时触发。支持餐饮SaaS、B端后台、多角色权限系统等复杂产品的PRD-原型评审闭环。

PRD与原型深度评审

概述

对需求PRD和产品原型文档进行结构化深度评审，发现问题、输出报告、自动落地补丁。评审原则：严苛但建设性，区分"必须改"和"建议改"。

评审工作流

第1步：读取并理解文档

1. 读取用户指定的PRD文档和原型文档
2. 理解产品背景、目标用户、核心功能
3. 识别文档版本、基于的竞品、生成时间

第2步：按维度逐项评审

加载 references/review-dimensions.md 获取完整评审维度清单，按以下三大类执行：

A. PRD需求评审

• 需求完整性：P0/P1/P2是否覆盖全面，有无遗漏行业标配
• 需求明确性：每个REQ是否有验收标准（Given-When-Then）
• 需求冲突：不同需求间是否存在逻辑冲突或边界模糊
• 竞品对标：竞品分析是否准确，差异化设计是否有竞争力
• API设计：命名规范是否统一，是否有完整端点清单
• 数据模型：实体关系是否清晰，主键/外键/索引是否合理
• 业务规则一致性：状态流转、审批链、数据隔离是否自洽

B. 原型评审

• 页面完整性：是否覆盖所有PRD需求
• 交互合理性：流程是否顺畅，操作步骤是否最优
• 异常覆盖：异常分支是否全面，有无遗漏关键场景
• 边界情况：是否覆盖核心业务风险点
• 信息架构：导航结构是否清晰，菜单拓扑是否完整
• 视觉一致性：组件规范是否统一
• 竞品差异：差异化设计实现成本是否合理

C. 风险识别

• 技术可行性：功能在现有技术栈下是否可实现
• 性能风险：大表查询、批量操作、数据打通等是否有隐患
• 安全合规：数据隔离、权限控制、日志审计是否满足合规
• 实施复杂度：MVP范围是否清晰，优先级排序是否合理

第3步：输出评审报告

输出结构化评审报告，保存为 评审报告-{模块名}.md，包含：

1. 总体评分：PRD + 原型分别打分（满分10分）
2. 问题清单：按严重程度分级
   • 🔴 严重（阻塞级，必须修复）
   • 🟠 重要（高风险，影响质量）
   • 🟡 建议（中风险，优化体验）
3. 每个问题包含：问题描述、影响范围、改进建议、优先级
4. PRD优化补丁：仅输出需要修改的具体段落，标注修改原因
5. 原型优化补丁：仅输出需要调整的具体页面/流程，标注修改原因
6. 风险矩阵：可能性×影响=等级，附缓解措施

第4步：落地补丁（可选，需用户确认）

用户确认后，按优先级逐个补丁落地：

1. PRD补丁：

   • 补充验收标准（Given-When-Then）
   • 补充/修正数据模型
   • 补充API设计规范
   • 修正业务规则
   • 补充导入导出规范
   • 补充数据迁移策略

2. 原型补丁：

   • 补充信息架构图（导航结构、菜单拓扑、面包屑规范）
   • 补充异常分支和边界情况
   • 补充性能边界（虚拟滚动、分页、异步执行）
   • 补充并发编辑冲突处理
   • 合并缺失的页面设计

第5步：验证与汇报

1. 更新文档版本号（如v1.0→v1.1）
2. 更新变更日志
3. 更新待确认清单（标注责任人+时间节点）
4. 汇报完成进度和剩余待办

评审标准参考

加载 references/review-dimensions.md 获取详细评审检查清单和评分标准。

输出规范

评审报告格式

markdown

# {产品名} — {模块名} 评审报告

## 一、总体评分
| 维度 | 评分 | 满分 | 说明 |

## 二、问题清单
### 严重问题（🔴 阻塞级）
| # | 问题 | 影响 | 建议 | 优先级 |

### 重要问题（🟠 高风险）
| # | 问题 | 影响 | 建议 | 优先级 |

### 建议问题（🟡 中风险）
| # | 问题 | 影响 | 建议 | 优先级 |

## 三、PRD优化补丁
## 四、原型优化补丁
## 五、风险矩阵
## 六、总结与建议

补丁落地原则

• 精准修改：仅修改需要改动的段落，不全文重写
• 标注原因：每个补丁标注关联的问题编号（如"关联 🔴 S03"）
• 版本管理：修改后更新文档版本号和变更日志
• 验收标准：PRD每个REQ补充3-5条Given-When-Then
• 边界覆盖：每个核心流程补充异常分支和边界场景

注意事项

• 评审要"严苛但建设性"，不要只说"不好"，要给出具体改进方向
• 区分「必须改」和「建议改」，避免过度设计
• 考虑B端SaaS特性：多门店、多角色、数据敏感、操作高频
• 复杂功能（如数据打通引擎）需评估技术可行性，必要时降级为技术预研
• 安全相关功能（如强制停业）必须考虑二次验证和审计追踪
• 大数据量场景必须考虑性能方案（虚拟滚动、懒加载、分区）