第7章 产品需求文档（PRD）撰写

PRD是产品经理最重要的输出物之一。一份好的PRD能让开发减少80%的疑问，一份差的PRD能让开发骂你三个月。

我是怕浪猫，这一章不讲PRD的格式模板（网上一搜一大把），只讲怎么写出一份"开发看了不骂人"的PRD。

7.1 初识需求文档

7.1.1 PRD 的作用与受众

PRD的全称是Product Requirement Document，产品需求文档。

PRD的核心作用

第一，对齐认知。产品、设计、研发、测试对同一个功能的理解必须一致。PRD是"共同语言"。

第二，减少沟通成本。好PRD能让开发"自己看懂"，而不是每次都要过来问。

第三，留下决策记录。为什么要做这个功能？设计的时候考虑了哪些场景？PRD回答了这些问题，后续迭代时才能知道当初为什么这么设计。

PRD的受众

一份PRD要同时满足四个受众的需求，所以需要"分层写作"——背景和目标写在前，设计和逻辑写在中间，细节和边界写在后。

7.1.2 PRD 的基本结构

一份完整的PRD包含以下部分：

第一部分：需求背景与目标（给老板和PM自己看）

• 为什么做这个需求？
• 希望达到什么目标？
• 优先级和排期如何？

第二部分：功能范围与用户故事（给所有人看）

• 这个功能包含哪些内容？
• 用户在什么场景下用这个功能？
• 用例（Use Case）拆解

第三部分：详细设计（给开发、设计、测试看）

• 页面原型（Axure链接或截图）
• 交互逻辑（点击后发生什么？）
• 数据定义（字段名、类型、取值范围）
• 异常流程（网络断了怎么办？数据为空怎么办？）

第四部分：非功能需求（给开发看）

• 性能要求（加载时间、并发量）
• 兼容性要求（支持哪些浏览器/系统版本）
• 安全要求（数据加密、权限控制）

第五部分：验收标准（给测试看）

• 每个功能点怎么测试？
• 验收通过的标准是什么？

7.1.3 PRD 与其他产品文档的关系（BRD/MRD）

产品经理要写的文档不止PRD。按产品周期，文档体系是这样的：

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元区间内的商品- 异常流程：- 用户未勾选任何条件就直接点击确定：面板关闭，搜索结果不刷新- 网络异常：提示"网络异常，请重试"- 没有符合条件的商品：展示"暂无符合条件的商品"

方法三：用表格描述数据字段

对于涉及数据展示的功能，用表格描述字段最清晰：

7.2.3 非功能需求（性能/安全/兼容性）

非功能需求经常被忽视，但恰恰是上线的"隐形杀手"。

性能需求

安全需求

• 用户密码必须加密存储（不可逆加密）
• 敏感数据（手机号、身份证）展示时必须脱敏
• 所有接口必须有鉴权机制
• 防止SQL注入、XSS等常见攻击

兼容性需求

7.2.4 交互说明与异常流程处理

异常流程是PRD里最容易遗漏的部分，但恰恰是最能体现产品经理专业度的部分。

常见异常场景与处理方式

交互状态说明

一个完整的PRD，应该覆盖一个功能的全部状态：

7.2.5 数据埋点与验收标准

数据埋点

每一个功能上线，都要能回答"这个功能用得怎么样"。埋点设计就是要回答这个问题。

埋点设计表：

验收标准

验收标准要"可测试"。不能说"搜索功能正常"，要说"输入关键词后1秒内返回搜索结果，结果列表正确展示商品名称、价格、图片"。

好的验收标准格式：Given（前置条件）When（操作） Then（预期结果）

举例：

【验收标准：搜索筛选功能】Given 用户已进入搜索结果页When 用户点击"筛选"按钮Then 页面应弹出筛选面板，其中包含"价格区间"、"商品分类"、"品牌"这三个筛选项Given 筛选面板已弹出When 用户选择"价格：100-500元"并点击"确定"Then 搜索结果应立即刷新，且仅展示价格在100-500元区间内的商品Given 筛选面板已弹出When 用户未选择任何条件直接点击"确定"Then 筛选面板关闭，搜索结果保持不变，不触发刷新

本章小结：PRD是产品经理最核心的输出物。背景不能只靠感觉，得有数据支撑；功能不能只写结果，得把场景讲清楚；异常情况不能遗漏，要尽可能穷举；验收标准更不能含糊，必须做到可测试、可执行。说到底，PRD写得扎不扎实，往往直接影响后续开发实现的质量。

觉得有用？收藏起来，下次写PRD直接照抄模板。

你见过最离谱的PRD是什么样的？评论区说说。

关注怕浪猫，下期我们讲"从0到1全流程产品设计"——从点子到产品，怕浪猫拆解这个过程中的每一个关键决策。

系列进度 7/16

下章预告： 第8章，怕浪猫带你走一遍"从点子到产品"的全流程。不是讲理论，而是用一个真实的案例——如何从"用户说想要更快的马"到做出一个改变行业的产品。全流程串通，一次性讲透。