---
name: req-review
description: PRD 评审方法论。用于需求评审、PRD 文档审查、评审意见编写。当执行 /req review 或需要评审 PRD 文档时使用。
---

# PRD 评审方法论

PRD 评审是需求流程的关键质量关卡。

## 评审流程

```
PRD 提交 → 结构检查 → 清晰度评估 → 技术可行性 → 数据模型 → API 审查 → 结论
```

## 结构完整性检查

| 检查项 | 必须 | 说明 |
|--------|:----:|------|
| 基本信息 | ✓ | 编号、标题、日期、作者 |
| 需求背景 | ✓ | 为什么需要这个功能 |
| 目标用户 | ✓ | 面向的用户群体 |
| 功能描述 | ✓ | 详细功能需求 |
| 数据模型 | ✓ | 数据库表结构 |
| API 设计 | ✓ | RESTful 接口 |
| 验收标准 | ✓ | 验收条件 |
| 用户故事 | ○ | As a... I want... |
| 页面原型 | ○ | 如有 Stitch 原型则必审：布局合理性、与 PRD 描述一致性 |
| 非功能需求 | ○ | 性能、安全 |

## 需求清晰度（SMART 原则）

| 原则 | 检查点 |
|------|--------|
| **S**pecific | 描述是否具体明确 |
| **M**easurable | 是否有量化指标 |
| **A**chievable | 技术上是否可行 |
| **R**elevant | 是否与业务目标相关 |
| **T**ime-bound | 是否有时间范围 |

**示例**：
- ❌ "用户可以搜索需求"
- ✅ "用户可按编号精确搜索、按标题模糊搜索、按状态筛选，结果分页显示"

## 技术可行性

| 维度 | 评估内容 |
|------|----------|
| 技术栈兼容 | 现有栈是否支持 |
| 架构影响 | 是否需修改架构 |
| 第三方依赖 | 是否引入新依赖 |
| 性能影响 | 潜在性能问题 |
| 安全考量 | 安全风险 |

## 数据模型验证

| 检查项 | 说明 |
|--------|------|
| 表结构 | 字段类型、约束、索引 |
| 关联关系 | 外键、多对多 |
| 命名规范 | 符合项目规范 |
| 扩展性 | 预留扩展字段 |
| 查询性能 | 常用查询有索引 |

## API 设计审查

| 检查项 | 标准 |
|--------|------|
| RESTful | URL 用名词，HTTP 方法语义正确 |
| 响应格式 | `{success, data, message}` |
| 错误处理 | 明确的错误码 |
| 分页 | `?page=1&page_size=20` |
| 版本控制 | `/api/v1/...` |

## 界面原型检查（如有）

当 PRD 包含 Stitch 生成的原型时，评审人应检查：

| 检查项 | 说明 |
|--------|------|
| 页面覆盖 | 原型页面覆盖了 PRD 中描述的主要功能 |
| 布局一致 | 布局与 PRD 功能描述一致（无遗漏关键元素） |
| 交互合理 | 导航、表单、操作按钮逻辑合理 |
| 数据展示 | 列表、详情、表单字段完整 |

## 评审结论模板

**通过**：
```
✅ PRD 评审通过

【结论】文档完整，需求清晰，方案可行，建议批准。
【肯定】需求背景清晰、数据模型合理、API 规范
【建议】（非阻塞）补充性能测试用例
【评审人】xxx  【时间】2026-xx-xx
```

**驳回**：
```
❌ PRD 评审驳回

【原因】
1. 数据模型缺少索引
2. API 缺少错误处理
3. 搜索需求描述模糊

【修改要求】
□ 补充索引设计
□ 明确错误码
□ 细化搜索实现

【驳回人】xxx  【时间】2026-xx-xx
```

## 常见驳回原因

| 类别 | 问题 | 建议 |
|------|------|------|
| 结构缺失 | 缺数据模型或 API | 补充技术设计 |
| 需求模糊 | 描述不具体 | 按 SMART 重写 |
| 边界不清 | 缺异常处理 | 补充边界条件 |
| 设计缺陷 | 模型/API 不合理 | 重新设计 |
| 范围过大 | 难以实现 | 拆分为多需求 |
| 验收不明 | 缺验收标准 | 补充验收条件 |