第7章 产品需求文档（PRD）撰写
PRD是产品经理最重要的输出物之一。一份好的PRD能让开发减少80%的疑问，一份差的PRD能让开发骂你三个月。
我是怕浪猫，这一章不讲PRD的格式模板（网上一搜一大把），只讲怎么写出一份"开发看了不骂人"的PRD。
7.1 初识需求文档
7.1.1 PRD 的作用与受众
PRD的全称是Product Requirement Document，产品需求文档。
PRD的核心作用
第一，对齐认知。产品、设计、研发、测试对同一个功能的理解必须一致。PRD是"共同语言"。
第二，减少沟通成本。好PRD能让开发"自己看懂"，而不是每次都要过来问。
第三，留下决策记录。为什么要做这个功能？设计的时候考虑了哪些场景？PRD回答了这些问题，后续迭代时才能知道当初为什么这么设计。
PRD的受众
| 受众 | 关注点 | PRD要怎么写 |
|---|---|---|
| 开发 | 怎么实现 | 逻辑清晰、边界明确、数据定义完整 |
| 设计 | 怎么设计 | 交互逻辑、状态定义、边界处理 |
| 测试 | 怎么测试 | 异常情况、边界条件、验收标准 |
| 老板 | 做什么、为什么 | 背景、目标、优先级 |
一份PRD要同时满足四个受众的需求，所以需要"分层写作"——背景和目标写在前，设计和逻辑写在中间，细节和边界写在后。
7.1.2 PRD 的基本结构
一份完整的PRD包含以下部分：
第一部分：需求背景与目标（给老板和PM自己看）
- 为什么做这个需求？
- 希望达到什么目标？
- 优先级和排期如何？
第二部分：功能范围与用户故事（给所有人看）
- 这个功能包含哪些内容？
- 用户在什么场景下用这个功能？
- 用例（Use Case）拆解
第三部分：详细设计（给开发、设计、测试看）
- 页面原型（Axure链接或截图）
- 交互逻辑（点击后发生什么？）
- 数据定义（字段名、类型、取值范围）
- 异常流程（网络断了怎么办？数据为空怎么办？）
第四部分：非功能需求（给开发看）
- 性能要求（加载时间、并发量）
- 兼容性要求（支持哪些浏览器/系统版本）
- 安全要求（数据加密、权限控制）
第五部分：验收标准（给测试看）
- 每个功能点怎么测试？
- 验收通过的标准是什么？
7.1.3 PRD 与其他产品文档的关系（BRD/MRD）
产品经理要写的文档不止PRD。按产品周期，文档体系是这样的：
| 文档 | 全称 | 阶段 | 受众 | 核心内容 |
|---|---|---|---|---|
| BRD | Business Requirements Document | 立项前 | 老板、投资人 | 商业价值、市场规模、ROI |
| MRD | Market Requirements Document | 立项后 | 产品、市场、运营 | 市场需求、用户画像、竞品分析 |
| PRD | Product Requirements Document | 开发中 | 开发、设计、测试 | 功能需求、交互逻辑、数据定义 |
| FSD | Functional Specification Document | 开发后 | 开发、测试 | 功能规格、接口定义（技术向） |
BRD讲"为什么做这个项目"，MRD讲"市场需要什么"，PRD讲"产品要做什么"。分工明确，不要混在一起。
7.2 撰写产品需求文档
7.2.1 需求背景与目标描述
需求背景怎么写
好的背景描述 = 痛点 + 数据 + 目标
举例：
【需求背景】
当前用户在搜索商品时，搜索结果页只按"综合"排序，用户无法按价格、销量等维度筛选。
数据表明：搜索结果页的跳出率高达42%，用户反馈中"找不到想要的商品"占比31%。
【需求目标】
上线搜索筛选功能，预期降低搜索结果页跳出率至30%以下。不好的背景描述：
【需求背景】
用户需要搜索筛选功能。区别很明显：好的背景有数据支撑，有目标定义；不好的背景只有一句空洞的描述。
需求目标怎么写
目标要可衡量。不能说"提升用户体验"，要说"搜索结果页跳出率从42%降低到30%以下"。
好的目标公式：动词 + 指标 + 数值 + 时间
举例：
- 提升搜索转化率 从18% 到 22% 在Q3前
- 降低下单流程流失率 从35% 到 25% 在V2.0上线后
- 提升新用户次日留存 从32% 到 38% 在Q4前
7.2.2 功能需求详细说明
功能需求是PRD的核心。怎么写才能没有歧义？
方法一：用用户故事（User Story）描述功能
用户故事格式：作为一个[用户角色]，我希望[做什么]，以便于[达到什么目的]。
举例：
作为一个搜索用户，
我希望在搜索结果页能按价格排序，
以便于快速找到符合预算的商品。用户故事的好处：把功能"还原到场景"中，避免只写功能不看场景。
方法二：用用例（Use Case）描述交互
用例格式：
- 参与者：谁在用这个功能
- 前置条件：用户进入这个功能前是什么状态
- 主流程：用户做了什么，系统响应了什么
- 异常流程：如果出错了怎么办
举例：
【用例：搜索筛选】
- 参与者：已登录用户
- 前置条件：用户已进入搜索结果页
- 主流程：
1. 用户点击"筛选"按钮
2. 系统弹出筛选面板
3. 用户选择"价格：100-500元"
4. 用户点击"确定"
5. 系统刷新搜索结果，只显示价格100-500元的商品
- 异常流程：
- 用户未选择任何条件直接点击确定：关闭面板，不刷新结果
- 网络异常：提示"网络异常，请重试"
- 无符合条件的商品：展示"暂无符合条件的商品"方法三：用表格描述数据字段
对于涉及数据展示的功能，用表格描述字段最清晰：
| 字段名 | 数据类型 | 说明 | 示例 |
|---|---|---|---|
| 商品ID | Long | 唯一标识 | 123456789 |
| 商品名称 | String | 最多30字 | 苹果手机壳 |
| 商品价格 | Decimal | 单位：元，保留两位小数 | 99.00 |
| 商品销量 | Integer | 累计销量 | 1024 |
| 商品图片 | String | 图片URL | https://... |
7.2.3 非功能需求（性能/安全/兼容性）
非功能需求经常被忽视，但恰恰是上线的"隐形杀手"。
性能需求
| 场景 | 指标 | 目标值 |
|---|---|---|
| 页面加载 | 首屏加载时间 | < 1.5秒 |
| 搜索响应 | 搜索结果返回时间 | < 500ms |
| 并发 | 同时在线用户数 | 支持10万+ |
| 接口 | API响应时间 | < 200ms（P95） |
安全需求
- 用户密码必须加密存储（不可逆加密）
- 敏感数据（手机号、身份证）展示时必须脱敏
- 所有接口必须有鉴权机制
- 防止SQL注入、XSS等常见攻击
兼容性需求
| 平台 | 最低版本要求 |
|---|---|
| iOS | iOS 13.0及以上 |
| Android | Android 8.0及以上 |
| Web | Chrome 80+、Safari 14+ |
| 微信小程序 | 基础库 2.0+ |
7.2.4 交互说明与异常流程处理
异常流程是PRD里最容易遗漏的部分，但恰恰是最能体现产品经理专业度的部分。
常见异常场景与处理方式
| 异常场景 | 处理方式 |
|---|---|
| 网络断开 | 提示"网络异常，请检查网络连接"，并提供重试按钮 |
| 接口超时（>5秒） | 显示loading状态，超时后提示"加载超时，请重试" |
| 数据为空 | 显示空状态页面，引导用户进行下一步操作 |
| 服务器错误（5xx） | 显示"系统繁忙，请稍后再试"，并记录错误日志 |
| 无权限访问 | 显示"暂无权限"，并提供申请权限的入口 |
| 版本过低 | 强制更新提示，引导用户去应用商店更新 |
交互状态说明
一个完整的PRD，应该覆盖一个功能的全部状态：
| 状态 | 说明 | 视觉表现 |
|---|---|---|
| 初始状态 | 用户第一次进入时的状态 | 引导提示、空状态 |
| 加载状态 | 数据加载中的状态 | loading动画、骨架屏 |
| 空状态 | 没有数据时的状态 | 空状态插画+引导文案 |
| 正常状态 | 有数据时的正常展示 | 完整内容展示 |
| 错误状态 | 出现异常时的状态 | 错误提示+重试入口 |
| 操作反馈状态 | 用户操作后的反馈 | Toast提示、弹窗确认 |
7.2.5 数据埋点与验收标准
数据埋点
每一个功能上线，都要能回答"这个功能用得怎么样"。埋点设计就是要回答这个问题。
埋点设计表：
| 事件名 | 触发时机 | 上报参数 | 说明 |
|---|---|---|---|
| search_filter_click | 用户点击筛选按钮 | user_id, search_keyword | 统计筛选功能使用率 |
| search_filter_apply | 用户点击确定应用筛选 | user_id, filter_conditions | 统计筛选条件分布 |
| search_result_impression | 搜索结果曝光 | user_id, result_list | 统计搜索结果点击率 |
验收标准
验收标准要"可测试"。不能说"搜索功能正常"，要说"输入关键词后1秒内返回搜索结果，结果列表正确展示商品名称、价格、图片"。
好的验收标准格式：Given（前置条件）When（操作） Then（预期结果）
举例：
【验收标准：搜索筛选功能】
Given 用户已进入搜索结果页
When 用户点击"筛选"按钮
Then 弹出筛选面板，包含"价格区间"、"商品分类"、"品牌"三个筛选项
Given 筛选面板已弹出
When 用户选择"价格：100-500元"并点击"确定"
Then 搜索结果刷新，只显示价格在100-500元之间的商品
Given 筛选面板已弹出
When 用户未选择任何条件直接点击"确定"
Then 关闭筛选面板，搜索结果不刷新PRD写得好不好，看三个维度：逻辑是否闭环（主流程+异常流程全覆盖）、细节是否到位（数据字段+交互状态+边界条件）、验收是否可测（验收标准清晰可执行）。三个维度都达标，才是一份合格的PRD。
本章小结：PRD是产品经理最重要的输出物。背景要有数据支撑，功能要有场景还原，异常要全部穷举，验收要可测试可执行。记住：PRD的质量，决定了开发实现的质量。
觉得有用？收藏起来，下次写PRD直接照抄模板。
你见过最离谱的PRD是什么样的？评论区说说。
关注怕浪猫，下期我们讲"从0到1全流程产品设计"——从点子到产品，怕浪猫拆解这个过程中的每一个关键决策。
系列进度 7/16
下章预告： 第8章，怕浪猫带你走一遍"从点子到产品"的全流程。不是讲理论，而是用一个真实的案例——如何从"用户说想要更快的马"到做出一个改变行业的产品。全流程串通，一次性讲透。