夜雨聆风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的质量，决定了开发实现的质量。
觉得有用？收藏起来，下次写PRD直接照抄模板。
你见过最离谱的PRD是什么样的？评论区说说。
关注怕浪猫，下期我们讲"从0到1全流程产品设计"——从点子到产品，怕浪猫拆解这个过程中的每一个关键决策。
系列进度 7/16
下章预告： 第8章，怕浪猫带你走一遍"从点子到产品"的全流程。不是讲理论，而是用一个真实的案例——如何从"用户说想要更快的马"到做出一个改变行业的产品。全流程串通，一次性讲透。