PRD与原型深度评审

概述

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

评审工作流

第1步：读取并理解文档

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

第2步：按维度逐项评审

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

A. PRD需求评审

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

B. 原型评审

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

C. 风险识别

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

第3步：输出评审报告

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

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

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

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

PRD补丁：
- 补充验收标准（Given-When-Then）
- 补充/修正数据模型
- 补充API设计规范
- 修正业务规则
- 补充导入导出规范
- 补充数据迁移策略
原型补丁：
- 补充信息架构图（导航结构、菜单拓扑、面包屑规范）
- 补充异常分支和边界情况
- 补充性能边界（虚拟滚动、分页、异步执行）
- 补充并发编辑冲突处理
- 合并缺失的页面设计

第5步：验证与汇报

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

评审标准参考

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

输出规范

评审报告格式

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

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

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

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

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

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

补丁落地原则

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

注意事项

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

Prd Prototype Review

安装到 Tokeny（自动）

SKILL.md