1. PRD 的核心价值与产品协作中的定位
产品需求文档（PRD）是产品团队与设计、开发、测试、业务等各方对齐需求意图的核心交付物。本章将明确 PRD 的定义、它与原型的关系，以及在需求生命周期中扮演的角色。
1.1 PRD 定义：共识的“书面契约”
- PRD（Product Requirements Document）是对产品功能、流程、约束、验收标准的系统性描述。
- 它的核心价值不是“写完就完”，而是让所有参与者在同一信息源下决策、讨论、评审。
PRD ≠ 功能清单
真正的 PRD 必须包含用户场景、业务规则、数据约束、异常流程、验收标准——而不仅仅是“需求列表”。
真正的 PRD 必须包含用户场景、业务规则、数据约束、异常流程、验收标准——而不仅仅是“需求列表”。
1.2 PRD 与原型的关系：图文互补
原型（线框图/高保真）展示界面交互的“形”，PRD 解释界面背后的“逻辑”。二者缺一不可。
| 维度 | PRD | 原型 |
|---|---|---|
| 表达方式 | 文字+规则+流程图 | 视觉设计+交互动效 |
| 覆盖范围 | 前/后台交互、异常、权限、边界条件 | 主流界面、正常流程 |
| 变更管理 | 版本号+修改日志跟踪 | 需重新生成图片/链接 |
| 验收依据 | 验收检查表+指标 | UI 一致性检查 |
对齐建议：在原型上将每个交互区域标注编号（如 A-1、B-2），在 PRD 中按编号逐一说明规则——实现“原型有标号，PRD 有对应”。
1.3 PRD 在需求生命周期中的角色
需求生命周期通常包含：用户调研 → 需求分析 → PRD 编写 → 原型对齐 → 评审 → 开发 → 测试 → 验收 → 发布。PRD 是连接“需求来源”与“实现验证”的桥梁。
如上图所示，PRD 编写位于需求分析之后，原型对齐与评审之前。它既是分析结果的编码器，也是后续环节的统一参考源。
1.4 PRD 的核心交付物模板（第1章概览）
一个完整的 PRD 通常包含以下章节，本课程后续章节将逐一拆解：
- 用户场景与用例：描述谁在什么情况下做什么。
- 业务流程与规则：正常路径、分支、异常。
- 功能需求与约束：数据、权限、集成点。
- 原型标注说明：与原型编号一一对应的规则解释。
- 验收检查表：可测试的通过/失败条件。
常见误区别踩：有些团队把 PRD 写成“作文”或者“清单”，缺少结构化。PRD 必须让任何一个新人拿到后，能理解业务逻辑并写出测试用例——这才是合格的标准。
1.5 课程章节地图参考
本教程共30章，从“为什么写 PRD”到“PRD 模板、版本管理与对齐方法”，每章结合用户场景、业务问题、用户访谈、需求拆解、方案表达、指标验证、验收标准、交付物模板展开。本章是起点，后续将深入每个模块。