Prd Prototype Review

SKILL.md

---
name: prd-prototype-review
description: 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特性：多门店、多角色、数据敏感、操作高频
- 复杂功能（如数据打通引擎）需评估技术可行性，必要时降级为技术预研
- 安全相关功能（如强制停业）必须考虑二次验证和审计追踪
- 大数据量场景必须考虑性能方案（虚拟滚动、懒加载、分区）