1.1 为什么产品团队必须先定义 PRD
在每一次产品迭代中，业务方提出的“结算需增加运费险提示”看似简单，但开发理解的可能是“在结算页加一行文字”，测试关注的则是“运费险显示规则与订单金额联动”。没有一份统一的 产品需求文档（PRD），团队就会陷入各自解读，最终交付物偏离真实需求。PRD 就是那个把“谁、在什么场景下、遇到了什么问题、需要怎样解决”翻译成技术侧可执行的“需求蓝图”。
核心认知： PRD 不是“写完了就存档”的静态文档，而是贯穿整个产品生命周期的单一真相来源（Single Source of Truth）。它承载了从用户调研到验收交付的全部关键决策。
1.2 定义：PRD 到底是什么
PRD（Product Requirements Document）是用结构化语言描述产品功能、业务流程、交互细节、数据规则、验收标准的技术文档。它在需求分析阶段形成，面向开发、测试、设计、运维等角色，确保所有人对“做什么”达成共识。
| 角色 | 从 PRD 获得的输入 | 典型痛点（无 PRD） |
|---|---|---|
| 产品经理 | 需求优先级判断、版本边界划定 | 需求反复变更，无法追溯决策 |
| 架构师/开发 | 业务逻辑、数据流转、异常处理 | 自行猜测业务含义，返工率高 |
| 测试工程师 | 测试用例设计、边界条件、验收标准 | 漏测核心场景，线上事故频发 |
| UI/UX | 交互细节、状态机、错误提示文案 | 设计稿与业务脱节，反复改稿 |
1.3 在需求阶段的位置：需求漏斗的“收敛点”
一个完整的需求链路通常经历五个阶段：用户调研 → 业务分析 → 需求拆解 → 文档化 → 评审确认。PRD 位于文档化与评审确认之间，它承前启后，将模糊的用户故事转化为无歧义的规格说明。
- 用户调研：通过访谈、数据、竞品分析收集原始诉求。
- 业务分析：评估价值、优先级、技术可行性。
- 需求拆解：将大需求拆分为可独立开发的最小功能单元。
- 文档化（PRD 生成）：为每个功能单元编写详细规则、流程图、数据字典。
- 评审确认：产品、开发、测试三方逐条确认，达成一致后进入开发。
1.4 对开发和测试的输入作用
PRD 是开发实现的唯一行为规范，也是测试用例设计的核心依据。一张表格可以直接说明两者的依赖关系：
| 下游角色 | PRD 提供的具体要素 | 使用方式 |
|---|---|---|
| 后端开发 | 接口定义、业务逻辑、状态流转、异常处理 | 编写 API、设计数据库、实现核心算法 |
| 前端开发 | 页面交互、输入校验、反馈文案 | 开发组件、绑定事件、处理输入输出 |
| 测试 | 功能流程、边界值、预期结果、验收标准 | 编写测试用例、设计边界测试、冒烟测试 |
关键实践： 测试工程师在评审 PRD 时发现问题，要比开发完成后发现再修改成本低 10~100 倍。因此 PRD 中必须包含可量化的验收标准（如：“用户点击提交后，0.5 秒内展示成功提示”），否则测试只能猜测“完成”的定义。
1.5 本章核心结构图：PRD 在需求生命周期中的位置
下图直观展示了 PRD 如何作为需求阶段的输出，对下游开发与测试产生直接输入，并最终通过验收验证是否满足原始需求。图中包含 7 个节点、6 条流向线，清晰勾勒出 PRD 在团队协作中的枢纽角色。
1.6 本章知识要点回顾
- PRD 定义： 产品需求文档，是团队对“需求做什么”的统一约定。
- 生命周期位置： 处于需求分析与评审之间，是需求漏斗的收敛点。
- 对开发的输入： 提供业务逻辑、接口定义、状态流转等具体实现依据。
- 对测试的输入： 提供功能流程、边界条件、验收标准，支撑测试用例设计。
- 常见陷阱： PRD 缺少验收标准 → 测试无法量化“通过”；PRD 存在歧义 → 开发按自己理解实现 → 返工甚至上线事故。
⚠️ 避坑重点： 不要将 PRD 写成“业务需求说明书”（BRD）。PRD 应面向技术侧，包含数据结构、异常流程、错误码等细节；而 BRD 通常只描述业务价值与高层目标。混淆两者会导致开发找不到关键实现指引。