业务篇 · 01 · PRD 编写规范
本章目标
让 PRD 成为可执行、可评审、可测试的文档，而不是一篇作文。
一、什么是合格的 PRD
不合格的 PRD（常见反例）：
| 反例 | 问题 |
|---|---|
| "系统要支持高并发" | 没有量化 |
| "用户体验要好" | 无法验证 |
| "登录接口处理一下异常" | 异常范围未定义 |
| "数据实时同步" | "实时"的阈值未定义 |
| "参考 xxx 的做法" | 指向不明确的外部参考 |
合格的 PRD 必须满足：
- 可测性：每条需求都有明确的验收标准（Given-When-Then）
- 完整性：核心流 + 异常流 + 边界 + 数据规则都齐全
- 一致性：术语统一，没有前后矛盾
- 可追踪：每条需求有唯一 ID，可追溯到业务目标
二、PRD 的标准结构
# [需求名称] - v[版本号]
## 1. 概述
1.1 背景（为什么做）
1.2 目标（做成什么样）
1.3 非目标（明确不做什么）
1.4 术语表
## 2. 用户与场景
2.1 目标用户
2.2 典型使用场景
2.3 用户故事地图
## 3. 功能需求
3.1 功能清单（带优先级）
3.2 详细需求（每条带验收标准）
3.3 异常场景
3.4 业务规则表
## 4. 非功能需求
4.1 性能要求（QPS、响应时间、容量）
4.2 安全要求
4.3 兼容性要求
4.4 可访问性要求
## 5. 数据规则
5.1 数据字典
5.2 数据关系
5.3 数据校验规则
## 6. 交互设计
6.1 流程图
6.2 状态机
6.3 原型链接
## 7. 对依赖方的要求
7.1 对开发的要求
7.2 对测试的要求
7.3 对运维的要求
## 8. 风险与边界
8.1 已知风险
8.2 超出范围的事项
8.3 遗留决策
## 9. 变更历史
三、每个小节的写作要点
1. 概述
背景必须回答三个问题：
- 这个需求解决什么问题？
- 为什么现在做？
- 不做会怎样？
非目标是 PRD 的"防御层"，明确写出"本期不做什么"，避免开发 / 测试反复确认。
2. 用户与场景
用用户故事地图展开：
用户: 小张（企业采购员）
场景: 月末做采购报表
需求: 批量导出带筛选条件的订单
价值: 从每月 4 小时减少到 10 分钟
3. 功能需求（核心）
每条需求的写法（见 02-user-stories.md）：
### REQ-001 批量导出订单
**优先级**: P0
**关联用户故事**: US-042
**验收标准**:
- Given: 用户已登录且在订单页
- When: 选中 ≤ 10,000 条订单，点击"导出"
- Then:
- 系统在 60 秒内生成 xlsx 文件
- 文件包含 [订单号、时间、金额、状态] 4 列
- 导出成功后自动下载
- 数据过滤条件与页面展示一致
**业务规则**:
- 单次导出最多 10,000 条
- 超过 10,000 条要求用户细化筛选条件
- 导出记录保留 30 天，可重复下载
**异常场景**:
- 网络断开 → 提示"请重试"，不产生半成品文件
- 并发导出 → 同用户 30 秒内只能发起一次
- 数据过多 → 前端提示"请缩小筛选范围"
**数据规则**:
- 金额保留 2 位小数
- 时间用 YYYY-MM-DD HH:MM:SS，时区：UTC+8
4. 非功能需求
必须量化：
| 类型 | 反例 | 正例 |
|---|---|---|
| 性能 | "要快" | P99 响应时间 ≤ 500ms |
| 并发 | "支持高并发" | 单实例 QPS ≥ 1000 |
| 容量 | "存储大量数据" | 保留最近 3 年，约 1 亿条 |
| 安全 | "要安全" | 符合 OWASP Top 10；密码存储用 bcrypt |
| 兼容 | "支持主流浏览器" | Chrome ≥ 90、Edge ≥ 90、Safari ≥ 14 |
5. 业务规则表（决策表）
复杂逻辑用决策表，不用大段文字：
| 条件: 金额 | 条件: 会员等级 | 条件: 是否首购 | 结果: 折扣 |
|---|---|---|---|
| < 100 | 任意 | 任意 | 0% |
| ≥ 100 | 普通 | 否 | 5% |
| ≥ 100 | 普通 | 是 | 10% |
| ≥ 100 | VIP | 否 | 15% |
| ≥ 100 | VIP | 是 | 20% |
四、PRD 评审流程
产品写初稿 ──► 内部评审 ──► 跨部门评审 ──► 定稿
（产品内部） （测试 + 开发）
跨部门评审的 Checklist
测试视角（可测性）：
- 每条需求有验收标准
- 异常场景齐全
- 边界值明确
- 数据规则清晰
开发视角（可实现性）：
- 技术可行性已评估
- 依赖服务已评估
- 工期估算合理
运维视角（可运营性）：
- 监控埋点需求明确
- 降级方案已考虑
- 容量评估已完成
详细评审模板见 templates/testing/requirements/requirements-testability-review.md。
五、PRD 的版本管理
版本号规则
v<主版本>.<次版本>.<修订号>
- 主版本：大范围重写，不向下兼容
- 次版本：新增功能点
- 修订号：bug 修正、文字调整
必须有变更历史表
## 变更历史
| 版本 | 日期 | 变更人 | 主要变更 |
|------|------|-------|---------|
| v1.0.0 | 2026-04-10 | 张三 | 初版 |
| v1.1.0 | 2026-04-15 | 张三 | 新增批量导出功能 |
| v1.1.1 | 2026-04-18 | 李四 | 修正 REQ-003 的金额计算规则 |
六、PRD 禁忌清单
- ❌ 用截图代替文字描述（截图会过期且不可搜索）
- ❌ 用"等等"、"之类的"（范围不明确）
- ❌ 引用口头沟通（"王总说过..."）
- ❌ 写技术实现（那是开发设计文档的事）
- ❌ 没有版本号
- ❌ 没有 Owner