夜雨聆风PRD（Product Requirements Document），产品需求文档。
每个产品经理都知道要写，但真正写好的，凤毛麟角。
我见过太多PRD：要么像散文——洋洋洒洒几千字，开发看了三页就放弃；要么像Excel——全是字段罗列，没有上下文，看完不知道这个功能要解决什么问题。
做了6年产品经理，写了上百份PRD，被开发怼过无数次之后，我总结了一套「让开发不再骂人」的PRD模板。
不多不少，7个模块，每一条都有存在的理由。
— — —
一、写PRD最常见的3个错误
错误1：把PRD写成功能说明书
只写「系统需要什么功能」，不写「为什么需要这个功能」「谁在什么场景下用」.
开发最怕这种PRD——他不知道你要解决什么问题，只能自己猜。猜错了，返工；猜对了，他觉得这是他的功劳不是你的。
错误2：不分优先级，什么都写P0
一份PRD里50个需求全是「紧急重要」，等于没有优先级。开发一看，反正也做不完，那就按自己理解的顺序来。
结果你最想要的功能，偏偏排到了最后。
错误3：只写「做什么」，不写「验收标准」
需求写完了，测试的时候和开发扯皮：「我说的不是这个意思」「你这个实现不对」.
为什么扯皮？因为PRD里没有明确的验收标准。你脑中的理想实现，和开发理解的实现，很可能完全不是一回事。
— — —
二、PRD模板（7个模块）
模块1：文档信息（1页纸说清楚背景）
别小看这一页。很多人打开PRD直接翻到功能描述，连这个需求从哪来的都不知道。
① 文档基本信息
字段 | 内容 |
项目名称 | |
PRD版本 | V1.0 |
产品经理 | |
创建日期 | |
最近更新 | |
需求来源 | 客户需求 / 内部规划 / 竞品对标 / 数据驱动 |
关联文档 | 技术方案、竞品分析报告、原型图链接 |
② 需求背景
用2-3段话说清楚：
- 为什么要做这个需求？（业务痛点 / 市场机会 / 客户要求）
- 不做会怎样？（损失什么 / 错过什么）
- 做了能带来什么？（效率提升 / 成本降低 / 收入增长）
③ 目标用户与使用场景
用户角色 | 使用场景 | 核心诉求 | 使用频率 |
角色A： | 在XX场景下 | 需要解决XX问题 | 每天/每周/偶尔 |
角色B： | |||
角色C： |
这一步很多人会跳过，但它决定了你的功能设计方向。不同角色的诉求不同，优先级也不同。
④ 项目目标与成功指标
需求上线后，用什么指标衡量是否成功？
指标 | 当前值 | 目标值 | 衡量方式 |
例：任务处理效率 | 平均2小时 | 平均30分钟 | 系统数据统计 |
模块2：业务流程（让所有人看到全貌）
在写具体功能之前，先用流程图把整体业务串一遍。这一步的意义在于：
- 让开发、测试、业务方对「系统要怎么运转」达成共识
- 发现流程中的异常分支和边界情况
- 梳理不同模块之间的依赖关系
流程图不需要多精美，但必须包含：
- 正常流程（主流程，最理想的路径）
- 异常流程（出错了怎么办、超时了怎么办、权限不够怎么办）
- 角色标注（每一步是谁在操作）
- 系统边界（哪些是系统自动处理，哪些需要人工介入）
建议用工具：Visio、draw.io、ProcessOn，手绘拍照也行，关键是逻辑清楚。
模块3：功能需求（PRD的核心）
这是PRD的主体部分。每个功能用统一的格式描述，确保开发读完不会产生歧义。
功能需求描述模板
字段 | 填写说明 | 示例 |
功能名称 | 简洁明了 | 审批流程管理 |
功能描述 | 一句话概括 | 支持自定义多级审批流程 |
用户角色 | 谁可以用 | 管理员、部门负责人 |
前置条件 | 使用前需满足什么 | 用户已登录且具有审批权限 |
主流程 | 正常操作步骤 | 1.进入审批列表 2.选择待审批项 3.查看详情 4.同意/驳回 |
异常流程 | 出错了怎么办 | 审批超时自动转交上级；网络中断提示重试 |
业务规则 | 约束条件 | 驳回必须填写原因，字数不少于10字 |
验收标准 | 怎么算做完了 | 审批流程可配置，支持1-5级，流转时间不超过3秒 |
几个关键原则：
- 每个功能一段，不要把多个功能混在一起写
- 业务规则要量化，不要写「适当的」「合理的」，写具体的数字和条件
- 验收标准要可验证，测试拿着标准就能判断做没做完
- 异常流程至少覆盖3种：权限异常、数据异常、网络异常
功能清单总览
在详细描述之前，先列一个总览表，方便快速浏览：
序号 | 模块 | 功能名称 | 优先级 | 复杂度 | 状态 |
1 | 模块A | 功能1 | P0 | 高 | 待开发 |
2 | 模块A | 功能2 | P0 | 中 | 待开发 |
3 | 模块B | 功能3 | P1 | 低 | 待开发 |
4 |
模块4：非功能需求（容易被忽略的致命项）
很多PRD只写功能需求，上线后才发现性能不行、安全不达标、数据丢了回不来。非功能需求不写清楚，背锅的永远是你。
性能要求
指标 | 要求 | 说明 |
响应时间 | 页面加载不超过3秒 | 首屏渲染时间 |
并发量 | 支持XX用户同时在线 | 峰值并发 |
数据处理量 | 支持XX条记录查询 | 大数据量场景 |
安全要求
维度 | 要求 |
权限控制 | 基于角色的访问控制（RBAC），最小权限原则 |
数据加密 | 敏感信息传输加密存储加密，符合等保要求 |
审计日志 | 关键操作记录日志，可追溯 |
数据备份 | 每日自动备份，保留30天 |
兼容性要求
维度 | 要求 |
浏览器 | Chrome 80+、Edge 80+、Firefox 75+ |
分辨率 | 最低1366×768，适配1920×1080 |
移动端 | 响应式布局，适配iOS/Android主流机型 |
可用性要求
- 系统可用性不低于99.9%（全年宕机不超过8.76小时）
- 计划内维护提前24小时通知
- 故障恢复时间不超过4小时
模块5：数据需求（数据从哪来、怎么存、怎么用）
数据需求是连接产品和开发的桥梁。很多需求变更都源于数据结构没想清楚。
① 数据实体关系
列出核心数据实体及其关系，不需要画完整的ER图，但关键实体要标注清楚。
实体 | 核心字段 | 说明 |
用户 | 用户ID、姓名、部门、角色、状态 | 系统核心用户信息 |
审批单 | 审批单ID、发起人、审批状态、审批结果 | 审批流程核心实体 |
② 数据迁移要求（如涉及）
- 需要迁移哪些历史数据？
- 数据格式是否需要转换？
- 迁移完成后如何验证数据完整性？
③ 数据字典
关键枚举值、状态码、字典项提前定义，避免开发自由发挥导致前后端不一致。
字段名 | 枚举值 | 含义 | 备注 |
审批状态 | 0-待审批 | 流程已发起，等待审批 | |
1-已通过 | 审批通过 | ||
2-已驳回 | 审批驳回，需填写原因 | ||
3-已撤销 | 发起人主动撤销 |
模块6：界面原型与交互说明
PRD不是原型，但PRD需要配合原型。
原型要求
- 不需要高保真，线框图即可，但页面布局要清晰
- 标注交互规则：点击后跳转哪里、弹窗还是新页面、操作后刷新哪部分
- 标注状态变化：按钮什么状态可用、什么状态置灰、错误提示怎么显示
- 原型链接放在PRD开头，方便随时对照
交互说明模板
场景 | 操作 | 系统响应 | 提示信息 |
正常提交 | 点击「提交」按钮 | 校验通过→提交成功→刷新列表 | 提交成功 |
必填项为空 | 点击「提交」按钮 | 校验失败→不提交→定位到第一个空字段 | 请填写必填项 |
提交失败 | 点击「提交」按钮 | 网络异常→不提交→保留已填内容 | 网络异常，请稍后重试 |
模块7：版本规划与发布策略
① 版本拆分
不要把所有功能堆在一个版本里。按优先级和依赖关系拆分成多个迭代版本。
版本 | 核心功能 | 预计上线时间 | 前置依赖 |
V1.0（MVP） | 核心流程跑通，满足最小可用 | 无 | |
V1.1 | 优化体验，补充异常处理 | V1.0上线反馈 | |
V2.0 | 高级功能，性能优化 | V1.1稳定运行 |
② 灰度发布策略（如需要）
- 灰度范围：先开放XX%用户
- 观察指标：重点关注XX数据
- 回滚方案：如出现问题，XX分钟内回滚
— — —
三、几个实战心得
心得1：PRD不是写给自己看的
PRD的读者是开发、测试、业务方、领导。不同的人关注点不同：开发看功能逻辑和异常处理，测试看验收标准，业务方看页面效果和交互流程，领导看项目目标和成功指标。
所以PRD要分层：一页纸摘要给领导，详细功能给开发和测试，原型给业务方确认。
心得2：写PRD之前，先画流程图
很多人拿到需求就开始写功能描述，写到一半发现流程走不通，又回头改。
正确顺序：先理清业务流程→ 再确定功能列表 → 最后写详细描述。流程通了，功能描述就不会有逻辑漏洞。
心得3：需求评审比写PRD更重要
PRD写得再好，不开评审会也是白搭。评审会上开发提出的每一个问题，都是你遗漏的边界情况。
建议：评审前把PRD提前1-2天发给开发预读；评审会上重点讨论业务逻辑和异常处理，不要逐字读PRD；评审后务必出变更记录。
心得4：PRD是活文档，不是交了就完
需求在开发过程中一定会变。关键是每次变更都要记录：改了什么、为什么改、影响了哪些模块。
用修订记录表管理版本变更，不要在原文上直接改了不通知任何人。
— — —
四、PRD发布前自查清单
☐ 需求背景和目标是否清晰（为什么做、做什么、做到什么程度）
☐ 目标用户和使用场景是否明确（谁用、什么场景、什么诉求）
☐ 业务流程图是否覆盖主流程和异常分支
☐ 每个功能是否有：主流程、异常流程、业务规则、验收标准
☐ 非功能需求是否涵盖性能、安全、兼容性、可用性
☐ 数据实体和字典定义是否完整
☐ 原型交互标注是否清晰
☐ 优先级是否合理（不要全是P0）
☐ 版本拆分是否可执行
☐ 变更记录是否已更新
— — —
写PRD这件事，没有银弹。
但有一套好模板，至少能保证你不遗漏关键信息、不犯低级错误、不跟开发反复扯皮。
这套模板我用了6年，每一行都是踩坑踩出来的。希望对你有用。
关注本号，回复「PRD」，获取本文配套的Word模板文件，直接套用。