**关键洞察**：PRD不是“需求说明书”，而是“决策记录器”。它应记录每个需求背后的用户访谈结论、竞品分析依据、以及被否决的备选方案，让读者理解“为什么做A而不做B”。
#### 1.2 典型读者角色：每个读者只关心自己的那部分
PRD的读者不是一个“抽象的产品团队”，而是具有不同关注点的具体角色。下表列出了最常见的六类读者及其核心诉求：
| 读者角色 | 关注焦点 | 典型问题 | 阅读部分 |
|---------|---------|---------|---------|
| 产品经理（协作者） | 需求链路完整性 | “这个功能的前置依赖是什么？” | 业务背景、用户场景、验收标准 |
| 交互/视觉设计师 | 用户使用流程 | “用户如何进入这个页面？操作反馈是什么？” | 用户故事、界面原型、异常流程 |
| 研发工程师 | 逻辑边界与数据规则 | “这个字段的枚举值有哪些？并发场景怎么处理？” | 功能逻辑、数据结构、API定义 |
| 测试工程师 | 验证条件与通过标准 | “什么算‘排序正确’？边界值是几？” | 验收标准、性能指标、异常场景 |
| 运营/市场人员 | 上线协同与用户触达 | “什么时候上线？用户怎么知道？” | 灰度计划、埋点需求、运营资源 |
| 管理层/业务方 | 投入产出比与风险 | “这个功能需要多少人天？ROI怎么衡量？” | 优先级、业务目标、验收指标 |
**避坑提示**：很多PRD会写成“研发导向”——只描述功能逻辑，缺少业务背景和验收标准。这导致设计师不理解“为什么要这样交互”，测试不知道“怎样算通过”。一份好的PRD应当让每个角色在自己的关注部分找到答案，而不需要去其他文档里补信息。
#### 1.3 文档核心目标：对齐、约束、可验证
PRD不是“堆砌需求”的文档，它有三个不可替代的目标：
1. **对齐认知**：让所有角色对“做什么”“不做什么”“优先级”达成统一理解，避免开发到一半出现“我以为你要的是A”的争议。
2. **约束范围**：明确本次迭代的边界——哪些需求在本批次实现，哪些延后，哪些明确不做。这是管理“需求蔓延”的第一道防线。
3. **可验证**：每一个需求点都必须有对应的验收方式。如果写了一个需求但无法验证是否实现，这个需求就是“伪需求”。
**常见误区**：有些团队把PRD当作“启动开发的申请单”——写完评审后便束之高阁，后续沟通全靠口头或IM。这种做法会导致需求在执行过程中发生不可追溯的变更，最终交付物与原始意图偏离。
以下是一张PRD价值结构图，展示了从业务问题到交付标准的完整链路：
**课程适用建议**：如果你是首次接触PRD，建议将本章作为“检查清单”——每次写PRD前，先问自己三个问题：① 这个需求的业务背景是什么？② 谁将阅读这个文档？③ 我能否在评审会上说出“这个功能做完了，验收条件是什么”？这三个问题覆盖了PRD最核心的价值。