name: PRD Tech Review
description: 撰写面向研发团队技术评审的产品需求文档(PRD)。适用于产品经理需要与后端、前端、数据研发进行需求评审会议前的文档准备。强调技术可评审性：接口定义、数据结构、状态流转、异常处理等研发关注点，确保需求评审会议高效进行。

PRD Tech Review（面向研发评审的PRD撰写）

帮助产品经理撰写能够通过研发技术评审的PRD文档。

核心原则

研发评审的本质：让研发团队能够准确理解需求，评估技术可行性和工作量。

好的评审PRD特征：
- 逻辑完整：没有遗漏的分支和边界
- 定义明确：术语、状态、规则无歧义
- 技术友好：包含研发关注的技术细节
- 可估时间：需求颗粒度适合工时评估

PRD 评审模板

# [功能名称] PRD

## 文档信息
| 字段 | 内容 |
|------|------|
| 版本 | v1.0 |
| 作者 | @产品经理 |
| 状态 | 待评审 / 评审通过 / 开发中 |
| 评审日期 | YYYY-MM-DD |
| 参与方 | 后端@xxx / 前端@xxx / 测试@xxx |

---

## 1. 需求背景（1页内）

### 1.1 业务问题
[用1-2句话说清楚要解决什么问题]

### 1.2 预期收益
| 指标 | 当前值 | 目标值 | 衡量方式 |
|------|--------|--------|----------|
| xxx  | xx     | xx     | xxx      |

### 1.3 影响范围
- 影响用户：[用户群体和预估量级]
- 影响系统：[涉及的系统/服务]
- 上下游依赖：[依赖的其他功能/接口]

---

## 2. 术语定义

| 术语 | 定义 | 示例 |
|------|------|------|
| xxx  | xxx  | xxx  |

> ⚠️ 评审前必须对齐术语，避免理解偏差

---

## 3. 功能需求

### 3.1 功能清单

| ID | 功能点 | 优先级 | 前端 | 后端 | 备注 |
|----|--------|--------|------|------|------|
| F01 | xxx | P0 | ✓ | ✓ | |
| F02 | xxx | P1 | ✓ | | |

### 3.2 功能详情

#### F01: [功能名称]

**功能描述**：
[一句话说明功能做什么]

**触发条件**：
- 前置条件：[用户/系统需要满足的条件]
- 触发动作：[什么操作触发此功能]

**处理逻辑**：

输入：xxx
处理：
1. 校验 xxx
2. 计算 xxx
3. 更新 xxx
输出：xxx

**业务规则**：

| 规则ID | 规则描述 | 示例 |
|--------|----------|------|
| R01 | xxx | xxx |
| R02 | xxx | xxx |

**异常处理**：

| 异常场景 | 处理方式 | 提示文案 |
|----------|----------|----------|
| 场景1 | 阻断/降级/重试 | "xxx" |

---

## 4. 状态定义（如有状态流转）

### 4.1 状态枚举

| 状态码 | 状态名 | 说明 | 可流转到 |
|--------|--------|------|----------|
| 10 | PENDING | 待处理 | PROCESSING, CANCELLED |
| 20 | PROCESSING | 处理中 | COMPLETED, FAILED |

### 4.2 状态流转图

```mermaid
stateDiagram-v2
    [*] --> PENDING: 创建
    PENDING --> PROCESSING: 开始处理
    PENDING --> CANCELLED: 取消
    PROCESSING --> COMPLETED: 处理成功
    PROCESSING --> FAILED: 处理失败
    FAILED --> PENDING: 重试
    COMPLETED --> [*]
    CANCELLED --> [*]

4.3 状态变更触发条件

5. 接口需求

5.1 接口清单

5.2 接口详情

创建订单

Request:

POST /api/v1/orders
Content-Type: application/json

{
  "user_id": 123456,       // 必填，用户ID
  "product_id": "P001",    // 必填，商品ID
  "quantity": 2,           // 必填，数量，>0
  "coupon_code": "SAVE10"  // 选填，优惠券码
}

Response - 成功:

{
  "code": 0,
  "message": "success",
  "data": {
    "order_id": "O202501220001",
    "status": "PENDING",
    "total_amount": 199.00,
    "created_at": "2025-01-22T10:00:00Z"
  }
}

Response - 失败:

{
  "code": 40001,
  "message": "商品库存不足",
  "data": null
}

错误码:

6. 数据需求

6.1 新增/变更字段

6.2 数据埋点

7. 交互设计

7.1 页面流程

flowchart LR
    A[商品详情] -->|点击购买| B[确认订单]
    B -->|提交| C[支付页]
    C -->|支付成功| D[订单详情]
    C -->|支付失败| E[支付失败页]

7.2 页面原型

[Figma链接 / 截图]

7.3 关键交互说明

8. 非功能需求

8.1 性能要求

8.2 兼容性要求

• 浏览器：Chrome 90+, Safari 14+
• App版本：iOS 14+, Android 8+

8.3 安全要求

• [ ] 敏感数据脱敏
• [ ] 接口鉴权
• [ ] 防重复提交

9. 验收标准

9.1 功能验收（Gherkin格式）

Feature: 创建订单

Scenario: 正常创建订单
  Given 用户已登录
  And 商品库存充足
  When 用户提交订单
  Then 订单创建成功
  And 返回订单ID

Scenario: 库存不足时创建订单
  Given 用户已登录
  And 商品库存为0
  When 用户提交订单
  Then 返回错误码 40001
  And 提示"商品库存不足"

9.2 验收Checklist

• [ ] 正常流程验证
• [ ] 异常流程验证
• [ ] 边界条件验证
• [ ] 性能指标验证
• [ ] 安全要求验证

10. 评审遗留问题

附录

A. 相关文档

• [设计稿链接]
• [技术方案链接]

B. 修订记录

## 评审前自检清单

```markdown
## PRD 评审前自检

### 完整性检查
- [ ] 所有功能点都有详细描述
- [ ] 异常场景已覆盖（至少5种以上）
- [ ] 状态流转完整（有状态图）
- [ ] 接口定义完整（Request/Response/错误码）
- [ ] 数据字段已说明（类型、是否必填、校验规则）

### 清晰度检查
- [ ] 术语定义表已填写
- [ ] 无"等"、"相关"、"其他"等模糊表述
- [ ] 业务规则用表格或伪代码明确
- [ ] 有具体示例说明边界情况

### 可评审性检查
- [ ] 需求颗粒度可评估工时（单个功能点 ≤ 3人天）
- [ ] 优先级标注清晰（P0/P1/P2）
- [ ] 依赖项已明确（上下游系统/接口）
- [ ] 时间节点已说明（上线时间/灰度计划）

### 技术友好检查
- [ ] 接口字段有类型和校验说明
- [ ] 状态码/错误码有定义
- [ ] 敏感操作有幂等性说明
- [ ] 批量操作有数量限制

常见评审问题及解决

评审会议流程建议

1. 背景说明（5分钟）
   - 业务问题和预期收益

2. 功能走读（20分钟）
   - 按功能清单逐个讲解
   - 重点讲解复杂逻辑和异常处理

3. 技术讨论（20分钟）
   - 接口设计合理性
   - 数据结构可行性
   - 性能和安全考量

4. 问题记录（10分钟）
   - 记录遗留问题
   - 确认问题Owner和截止时间

5. 工时评估（5分钟）
   - 各角色初步工时
   - 风险项识别

高频异常场景模板

评审时必须覆盖的异常场景：