主题
01 - PRD 的结构与写作规范
前言
写 PRD 就像盖房子画图纸 — 你不需要亲手搬砖，但图纸画得好不好， 直接决定了房子盖得正不正、工人返工多不多。
本篇将系统地讲解：PRD 给谁看、怎么写、写什么、怎么才算写得好。
一、PRD 的目的与受众
1.1 PRD 的核心目的
PRD 不是写给自己看的笔记，它是一份正式的协作文档，核心目的有三个：
+-------------------------------------------------------+
| PRD 的三大核心目的 |
+-------------------------------------------------------+
| |
| 1. 说清楚「做什么」 --> 功能范围、边界条件 |
| 2. 说清楚「为什么做」--> 业务背景、用户价值 |
| 3. 说清楚「做成什么样」--> 验收标准、成功指标 |
| |
+-------------------------------------------------------+1.2 PRD 的受众分析
PRD 不是只给一种人看的。不同角色关注 PRD 的不同部分：
| 受众角色 | 关注重点 | 他们的核心诉求 |
|---|---|---|
| 工程师 | 功能需求、接口定义、逻辑规则、异常处理 | "告诉我具体要怎么实现" |
| UI/UX 设计师 | 交互说明、用户场景、信息架构 | "告诉我用户怎么用这个功能" |
| QA 测试 | 验收标准、边界条件、异常场景 | "告诉我怎么判断做对了" |
| 项目经理 | 排期依据、依赖关系、上线计划 | "告诉我工作量和时间线" |
| 老板/领导 | 背景目的、业务价值、成功指标 | "告诉我为什么要做、做了有什么好处" |
| 运营同事 | 灰度策略、上线时间、用户通知 | "告诉我什么时候上、怎么配合" |
PRD 文档
+--------+
| |
+--------+--------+---------+
| | | |
v v v v
+--------+ +------+ +-----+ +--------+
| 工程师 | | 设计师| | QA | | 老板 |
+--------+ +------+ +-----+ +--------+
|功能需求 | |交互 | |验收 | |背景 |
|逻辑规则 | |说明 | |标准 | |目的 |
|异常处理 | |原型 | |边界 | |价值 |
+--------+ +------+ +-----+ +--------+写作建议：写 PRD 的时候，心里要装着这些读者。 每写一段，想想："如果我是工程师/设计师/QA，看到这段能不能直接干活？"
二、PRD 的标准结构（十大章节详解）
一份完整的 PRD 通常包含以下 10 个章节。当然，不同公司、不同项目可能会有所调整， 但这个结构是业界公认的"最全面版本"，可以根据实际情况裁剪。
+================================================================+
| PRD 标准结构总览 |
+================================================================+
| |
| +----------------------------------------------------------+ |
| | 1. 文档信息 | |
| | 版本号 / 作者 / 日期 / 审核人 / 状态 | |
| +----------------------------------------------------------+ |
| | |
| +----------------------------------------------------------+ |
| | 2. 背景与目的 | |
| | 为什么要做？解决什么问题？ | |
| +----------------------------------------------------------+ |
| | |
| +----------------------------------------------------------+ |
| | 3. 目标与成功指标 | |
| | 做到什么程度算成功？用什么数据衡量？ | |
| +----------------------------------------------------------+ |
| | |
| +----------------------------------------------------------+ |
| | 4. 用户故事 | |
| | 从用户视角描述需求场景 | |
| +----------------------------------------------------------+ |
| | |
| +----------------------------------------------------------+ |
| | 5. 功能需求 | |
| | 详细的功能描述、业务规则、异常处理 | |
| +----------------------------------------------------------+ |
| | |
| +----------------------------------------------------------+ |
| | 6. 非功能需求 | |
| | 性能 / 安全 / 兼容性 / 可用性 | |
| +----------------------------------------------------------+ |
| | |
| +----------------------------------------------------------+ |
| | 7. 交互说明与原型链接 | |
| | 页面流转、交互细节、设计稿链接 | |
| +----------------------------------------------------------+ |
| | |
| +----------------------------------------------------------+ |
| | 8. 数据埋点需求 | |
| | 需要采集哪些用户行为数据 | |
| +----------------------------------------------------------+ |
| | |
| +----------------------------------------------------------+ |
| | 9. 上线计划与灰度策略 | |
| | 怎么发布？先放多少量？回滚方案？ | |
| +----------------------------------------------------------+ |
| | |
| +----------------------------------------------------------+ |
| | 10. 附录 | |
| | 术语表 / 参考文档 / 历史版本 | |
| +----------------------------------------------------------+ |
| |
+================================================================+2.1 文档信息
这是 PRD 的"身份证"，让读者快速了解这份文档的基本信息。
| 字段 | 说明 | 示例 |
|---|---|---|
| 文档标题 | 明确的功能名称 | 购物车功能 PRD |
| 版本号 | 语义化版本，区分大改和小改 | v1.2 |
| 作者 | 文档负责人 | 张三 |
| 创建日期 | 首次创建时间 | 2026-04-01 |
| 最后更新 | 最近修改时间 | 2026-04-20 |
| 审核人 | 谁审核通过的 | 李四（技术负责人） |
| 文档状态 | 当前状态 | 草稿 / 评审中 / 已通过 / 已归档 |
版本号管理规范：
v1.0 --- 首次发布
v1.1 --- 小修改（文案调整、补充说明）
v1.2 --- 中修改（新增功能点、修改业务规则）
v2.0 --- 大改版（需求范围大幅变化）Tips：很多新人忽略版本管理，导致团队看到的不是同一个版本的 PRD。 每次修改完，一定要更新版本号和修改记录。
2.2 背景与目的
这一章回答："我们为什么要做这个功能？"
写作要点：
- 描述当前的问题或痛点（用数据说话）
- 说明做了这个功能后的预期收益
- 关联公司或部门的战略目标
反面教材：
"用户需要购物车功能。"
正面教材：
"当前用户在浏览商品后，只能逐个下单购买，无法批量结算。 数据显示，63% 的用户在一次访问中会浏览 3 件以上商品， 但由于没有购物车，每次只能购买 1 件，导致客单价仅为 89 元。 通过上线购物车功能，预计客单价可提升 40% 至 125 元， 同时减少用户重复下单的操作成本，提升购买转化率。"
2.3 目标与成功指标
光说"做了有好处"不够，必须量化：
| 指标名称 | 当前值 | 目标值 | 衡量方式 |
|---|---|---|---|
| 客单价 | 89 元 | 125 元 | 订单平均金额 |
| 购买转化率 | 12% | 18% | 加购用户中完成支付的比例 |
| 一次购买多件的比例 | 5% | 30% | 订单中包含2件以上商品的比例 |
SMART 原则：
S - Specific 具体的 不说"提升用户体验"，说"减少下单步骤"
M - Measurable 可衡量的 必须有数字
A - Achievable 可达成的 别定一个不可能的目标
R - Relevant 相关的 和业务目标有关
T - Time-bound 有时限的 上线后 30 天内达成2.4 用户故事
用户故事是以用户的语言来描述需求的方式，格式固定：
作为 [某类用户]，我想 [做某件事]，以便 [获得某种价值]。
示例：
| 编号 | 用户故事 | 优先级 |
|---|---|---|
| US-01 | 作为购物用户，我想把喜欢的商品加入购物车，以便稍后统一结算 | P0 |
| US-02 | 作为购物用户，我想修改购物车中商品的数量，以便按需购买 | P0 |
| US-03 | 作为购物用户，我想删除不需要的商品，以便购物车保持整洁 | P0 |
| US-04 | 作为购物用户，我想看到商品价格变动提醒，以便做出购买决策 | P1 |
| US-05 | 作为购物用户，我想在库存不足时收到提示，以便及时调整 | P1 |
优先级定义：
P0 — 必须做，没有就不能上线
P1 — 应该做，上线后尽快补齐
P2 — 可以做，看排期决定
P3 — 锦上添花，有空再做2.5 功能需求
这是 PRD 最核心、篇幅最大的部分。每个功能点都要讲清楚：
功能描述模板：
功能编号：FR-001
功能名称：加入购物车
优先级：P0
触发条件：用户在商品详情页点击"加入购物车"按钮
前置条件：用户已登录、商品处于在售状态
基本流程：
1. 用户点击"加入购物车"
2. 系统检查库存是否充足
3. 若库存充足，商品加入购物车，数量默认为1
4. 购物车图标显示动画，角标数字+1
5. 弹出 Toast 提示"已加入购物车"
异常流程：
- 库存不足：提示"库存不足，当前仅剩X件"
- 已达购买上限：提示"该商品限购X件"
- 未登录：跳转登录页，登录后自动加入
业务规则：
- 同一商品重复加购，数量累加而非新增一行
- 单个商品购买上限为 99 件（或商家设定的限购数）
- 购物车最多容纳 200 种不同商品
验收标准：
[x] 正常加购后，购物车数量正确增加
[x] 库存不足时，弹出正确的提示文案
[x] 未登录用户加购后，跳转登录再回来加购成功关键原则：每个功能描述，都要包含"正常流程"和"异常流程"。 新手 PM 最常犯的错误就是只写了正常情况，忽略了异常处理。
2.6 非功能需求
非功能需求（NFR）描述系统"应该具备什么能力"，而不是"应该做什么功能"。
| 类别 | 要求 | 说明 |
|---|---|---|
| 性能 | 购物车页面加载时间 < 2 秒 | 在 4G 网络环境下 |
| 性能 | 加购操作响应时间 < 500ms | 用户可感知的操作延迟 |
| 并发 | 支持 1000 QPS 的加购请求 | 大促期间的峰值 |
| 安全 | 购物车数据仅本人可见 | 不能看到别人的购物车 |
| 安全 | 价格以服务端为准 | 防止前端篡改价格 |
| 兼容性 | iOS 13+, Android 8+ | 覆盖 95% 以上用户 |
| 兼容性 | Chrome/Safari/Firefox 最新 2 个版本 | Web 端 |
| 可用性 | 购物车服务可用性 >= 99.9% | 全年宕机不超过 8.76 小时 |
2.7 交互说明与原型链接
这一章节通常需要配合设计师一起完成：
需要包含的内容：
- 页面级的交互流程图
- 关键页面的线框图（或高保真设计稿链接）
- 动画、转场效果说明
- 空状态、加载状态、错误状态的展示
页面状态枚举：
+------------------+ +------------------+ +------------------+
| 空购物车状态 | | 正常购物车状态 | | 加载中状态 |
| | | | | |
| +-----------+ | | +------------+ | | |
| | 空状态 | | | | 商品列表 | | | Loading... |
| | 插画图 | | | | - 商品A | | | [骨架屏] |
| | | | | | - 商品B | | | |
| +-----------+ | | +------------+ | | |
| | | | | |
| "购物车是空的" | | [去结算] 按钮 | | |
| [去逛逛] 按钮 | | | | |
+------------------+ +------------------+ +------------------+
+------------------+ +------------------+
| 网络错误状态 | | 部分失效状态 |
| | | |
| 网络不给力 | | - 商品A (正常) |
| 请检查网络设置 | | - 商品B (失效) |
| | | 已下架/无库存 |
| [重试] 按钮 | | |
+------------------+ +------------------+2.8 数据埋点需求
数据埋点是产品迭代的"眼睛"。没有埋点，你就不知道用户是怎么用你的产品的。
埋点类型：
| 类型 | 说明 | 示例 |
|---|---|---|
| 页面浏览（PV） | 用户访问了哪个页面 | 购物车页面被打开 |
| 点击事件 | 用户点了哪个按钮 | 点击"去结算"按钮 |
| 曝光事件 | 某个元素展示给了用户 | 购物车中的推荐商品曝光 |
| 业务事件 | 关键业务动作完成 | 加购成功、删除商品 |
埋点需求表：
| 事件名称 | 事件类型 | 触发时机 | 携带参数 |
|---|---|---|---|
| cart_page_view | PV | 进入购物车页面 | user_id, cart_item_count |
| cart_add_click | 点击 | 点击加入购物车 | product_id, sku_id, price |
| cart_add_success | 业务 | 加购成功 | product_id, quantity, source |
| cart_delete_click | 点击 | 点击删除按钮 | product_id |
| cart_checkout_click | 点击 | 点击去结算 | selected_count, total_price |
2.9 上线计划与灰度策略
功能做完不是直接全量上线，而是分步骤放量：
灰度发布流程：
内部测试 灰度 1% 灰度 10% 灰度 50% 全量 100%
+--------+ +--------+ +--------+ +--------+ +--------+
| 团队内 | ---> | 随机 | ---> | 扩大 | ---> | 观察 | ---> | 全部 |
| 使用 | | 1% 用户| | 10% | | 数据 | | 用户 |
| 验证 | | 验证 | | 用户 | | 稳定 | | 可用 |
+--------+ +--------+ +--------+ +--------+ +--------+
| | | |
v v v v
修复 Bug 观察核心指标 观察性能/体验 确认无异常
完善功能 有问题可回滚 收集用户反馈 正式全量需要包含的内容：
- 预计上线日期
- 灰度比例和时间节点
- 每个灰度阶段的关注指标
- 回滚方案（出问题怎么办）
- 上线公告 / 运营配合事项
2.10 附录
附录是补充材料，用来存放不适合放在正文中的内容：
- 术语表：解释文档中出现的专业术语
- 参考文档：相关的技术文档、设计文档链接
- 修改记录：每次版本更新的变更内容
- FAQ：评审过程中提出的问题和结论
修改记录示例：
| 版本 | 日期 | 修改人 | 修改内容 |
|---|---|---|---|
| v1.0 | 2026-04-01 | 张三 | 初始版本 |
| v1.1 | 2026-04-10 | 张三 | 补充非功能需求 |
| v1.2 | 2026-04-15 | 张三 | 根据评审反馈修改异常流程 |
| v2.0 | 2026-04-20 | 张三 | 新增价格变动提醒功能 |
三、好 PRD vs 差 PRD 的对比
| 维度 | 好的 PRD | 差的 PRD |
|---|---|---|
| 背景描述 | 有数据支撑，说明问题严重性 | "用户需要这个功能" 一句话带过 |
| 目标设定 | 量化指标 + 时间节点 | "提升用户体验" 模糊不清 |
| 用户故事 | 覆盖多种用户角色和场景 | 只有一个笼统的描述 |
| 功能描述 | 正常流程 + 异常流程 + 边界条件 | 只有正常流程 |
| 业务规则 | 明确、无歧义，有优先级 | 含糊不清，"视情况而定" |
| 文案 | 给出具体文案或文案规范 | "弹一个提示" 但不说提示什么 |
| 设计说明 | 附带原型/线框图，标注交互细节 | "参考竞品 XX" |
| 异常处理 | 列举各种异常场景和处理方案 | 完全不提异常情况 |
| 验收标准 | 可执行的检查清单 | 没有验收标准 |
| 版本管理 | 有版本号、修改记录 | 没有版本号，不知道是哪版 |
| 数据需求 | 明确的埋点表和指标 | "上线后看看数据" |
| 排版格式 | 结构清晰，善用表格和列表 | 大段文字，没有层次 |
差的 PRD: 好的 PRD:
+------------------+ +------------------+
| 一大段文字 | | 1. 背景(有数据) |
| 没有结构 | | 2. 目标(可量化) |
| 没有表格 | | 3. 用户故事 |
| 没有异常处理 | | 4. 功能需求 |
| "你们看着做吧" | | - 正常流程 |
| | | - 异常流程 |
| | | - 业务规则 |
| | | 5. 验收标准 |
+------------------+ +------------------+
开发看完一脸懵 开发看完能干活四、写 PRD 的常见错误与避坑指南
错误 1：只写了"正常流程"
你以为的用户路径： 实际的用户路径：
打开 -> 加购 -> 结算 打开 -> 加购 -> 网断了
打开 -> 加购 -> 库存没了
打开 -> 加购 -> 退出 -> 3天后回来
打开 -> 加购 -> 加购 -> 超出限购
......避坑方法：每个功能至少想 3 种异常情况。问自己：
- 如果网络断了呢？
- 如果数据为空呢？
- 如果用户疯狂点击呢？
- 如果同时有两个人操作呢？
错误 2：需求描述模糊
| 模糊的写法 | 清晰的写法 |
|---|---|
| 弹一个提示 | 页面底部弹出 Toast，文案"已加入购物车"，2 秒后自动消失 |
| 展示商品列表 | 按加购时间倒序展示，每页 20 条，下拉加载更多 |
| 做一个搜索功能 | 支持按商品名称模糊搜索，输入 2 个字符后开始搜索，300ms 防抖 |
| 用户体验要好 | 页面加载完成时间 < 2s，操作反馈延迟 < 300ms |
错误 3：缺少边界条件
常见需要考虑的边界条件：
- 数值边界：最小值、最大值、为0的情况
- 文本边界：空字符串、超长文本、特殊字符、Emoji
- 时间边界：跨天、跨月、时区
- 权限边界：未登录、登录过期、被封禁
- 设备边界：小屏手机、平板、横屏
错误 4：把"怎么实现"写进 PRD
PRD 应该描述"做什么"，而不是"怎么做"。技术方案是工程师的职责。
| 不应该出现在 PRD 中 | 应该出现在 PRD 中 |
|---|---|
| 用 Redis 做缓存 | 购物车数据需要实时同步 |
| 用 MySQL 存储 | 购物车数据需要持久化，清除缓存后仍可恢复 |
| 前端用 React 实现 | 页面需支持 iOS/Android/Web 三端 |
| 用消息队列异步处理 | 加购操作需要在 500ms 内响应 |
唯一例外：如果技术选型对产品体验有直接影响（如选择 WebSocket 做实时推送 vs 轮询方案会影响消息实时性），可以在 PRD 中提出建议，但注明"建议方案"。
错误 5：写完就扔，不维护
PRD 是一个活文档，从需求评审到上线后复盘，都可能需要更新。
PRD 的生命周期：
撰写 --> 评审 --> 修改 --> 定稿 --> 开发中更新 --> 上线后归档
| | | | | |
v v v v v v
v0.1 反馈 v0.2~0.9 v1.0 v1.1~1.x 标记归档
草稿 意见 修改版 正式版 开发中调整 进入知识库错误 6：没有优先级，什么都是 P0
如果所有需求都是"最高优先级"，就等于没有优先级。
错误做法: 正确做法:
P0: 加入购物车 P0: 加入购物车
P0: 修改数量 P0: 修改数量
P0: 删除商品 P0: 删除商品
P0: 价格变动提醒 P1: 勾选结算
P0: 优惠券推荐 P1: 价格变动提醒
P0: 商品比价 P2: 优惠券推荐
P0: 心愿单 P3: 商品比价
P3: 心愿单五、PRD 写作的黄金法则
最后，总结几条在实战中非常管用的写作法则：
法则 1：一个需求对应一个完整描述
不要用"同上""参考前面"来偷懒。每个功能点都独立完整，方便工程师单独查看。
法则 2：用示例代替抽象描述
不好："支持多种排序方式。"
好："支持以下排序方式：加购时间（默认）、价格从低到高、价格从高到低。"
法则 3：用表格代替大段文字
同样的信息，表格比文字段落更容易阅读和查找。
法则 4：写给最不了解业务的人看
假设读者对业务一无所知。如果他能看懂你的 PRD，说明你写得足够清楚。
法则 5：评审前让别人先看一遍
正式评审前，先找一个同事快速过一遍，看看有没有明显的遗漏或歧义。
本篇小结
+--------------------------------------------------------------+
| 本篇核心要点 |
+--------------------------------------------------------------+
| |
| 1. PRD 的受众不同，关注点不同 -- 写的时候心里装着读者 |
| 2. PRD 标准结构 10 大章节 -- 按需裁剪，但不能缺核心部分 |
| 3. 好 PRD 的标准：清晰、完整、无歧义、可验收 |
| 4. 六大常见错误：只写正常流程、描述模糊、缺边界条件、 |
| 写实现方案、不维护、没有优先级 |
| 5. 黄金法则：用示例、用表格、写给不懂的人看 |
| |
+--------------------------------------------------------------+上一篇: 模块概览
下一篇: 02 - 完整 PRD 模板 + 范例