PRD 结构拆解

一份可落地、可对齐的 PRD,不是功能清单的堆砌,而是按「模块→字段→视角」三层结构组织起来的决策载体。本章拆解 PRD 的四个核心维度:模块组成、字段规范、读写视角差异、典型模板,帮你在写 PRD 时知道“该放什么、怎么写、给谁看”。

PRD 核心模块组成

标准产品 PRD 由以下 5 个模块构成,每个模块解决一个特定的协作问题:

模块解决什么问题典型产出物
文档头信息版本追溯、责任归属、同步状态版本记录、作者、状态标签
业务背景为什么做、做多大、不做哪些目标陈述、范围边界、ROI 预估
功能描述怎么做、逻辑是什么、异常怎么处理功能列表、业务规则、流程分支
交互说明界面长什么样、操作反馈、状态变化原型标注、交互状态图、异常提示
验收标准怎样算完成、达标指标、通过条件验收清单、指标阈值、边界用例
避坑提醒: 模块缺失是 PRD 返工的第一原因。缺少“业务背景”会导致设计与开发频繁追问“为什么”;缺少“验收标准”则测试阶段无据可依。

字段规范详解

每个模块内部包含若干关键字段,字段的填写质量直接决定下游理解和执行效率:

所属模块关键字段填写规范
文档头信息版本号、状态、作者、最后更新日期每次修改必须递增版本号,状态从“草稿→评审中→定稿”流转
业务背景业务目标、用户痛点、范围说明、ROI目标需量化(如“支付转化率提升 15%”),范围明确“做/不做”
功能描述功能列表、核心逻辑、异常处理、权限规则逻辑用分支条件穷举,异常场景单独列出
交互说明页面布局、操作路径、反馈状态、极限态对齐 Figma 标注,每个交互元素需标注默认/悬停/出错状态
验收标准功能指标、性能阈值、通过率、边界用例标准必须可测量,避免“流畅”“美观”等主观描述
字段规范的核心原则: 每个字段只服务一个目的,不混写“怎么做”和“为什么做”。业务背景字段只写目标与范围,不写具体功能;功能描述字段只写逻辑与规则,不写交互细节。

读写视角差异

同一份 PRD,不同角色读取的深度和关注点完全不同。理解视角差异才能写出“一人写、多人用”的高效文档:

角色关注重点阅读方式常见读不懂的点
产品经理(写)完整自洽、目标清晰、逻辑穷尽自上而下逐模块通读忽略版本管理导致多人协作混乱
设计师(读)交互细节、视觉规范、极限状态聚焦交互说明模块,跳读业务背景缺少异常态标注,需反复追问
开发工程师(读)逻辑规则、数据字段、边界条件重点读功能描述,略读业务背景逻辑分支遗漏导致返工
测试工程师(读)验收标准、边界用例、通过条件直接定位验收标准模块,反向对照功能描述验收标准不可量化,无法判定通过
写作误区: 不要试图让 PRD 的所有段落被所有人读完。正确做法是按模块分层,让每个角色能“跳读”到自己需要的部分,同时通过字段规范保证信息完整。

典型模板结构

以下是一份经过多个项目验证的 PRD 模板骨架,可直接复用为章节大纲:

章节内容说明字段示例
1. 文档信息版本、状态、作者、变更记录v1.2 / 评审中 / 张三 / 2025-06-10
2. 业务背景目标、范围、ROI、相关项目目标:首单转化率提升 15% / 范围:仅限新用户
3. 用户场景角色、流程图、场景描述角色:C 端买家 / 流程:搜索→加购→支付
4. 功能需求功能列表、逻辑规则、异常处理规则:优惠券不可与秒杀叠加 / 异常:库存不足弹窗
5. 交互说明页面布局、交互状态、极限态状态:默认/悬停/点击/加载/空态/错误态
6. 数据字段字段定义、数据类型、来源字段:coupon_id / 类型:String / 来源:优惠券中心
7. 验收标准功能指标、性能阈值、通过条件指标:页面加载 ≤1.5s / 通过率:100% 核心用例通过
8. 附录术语表、参考资料、变更记录术语:ROI、UV、CVR / 参考:竞品分析报告 v2.0
模板使用建议: 根据项目阶段裁剪章节。MVP 阶段可合并“功能需求”与“交互说明”,但“验收标准”不能删减,它是 PRD 与 Figma 联调的最终对齐依据。

模块 · 字段 · 视角 对应关系

以下全景图展示 PRD 三大核心维度——模块组成、字段规范、读写视角——之间的映射关系:每个模块对应一组关键字段,同时决定了不同角色的阅读重点。

PRD 结构拆解全景图 模块组成 字段规范 读写视角 文档头信息 版本 / 状态 / 作者 全员:版本一致 业务背景 目标 / 范围 / ROI PM&设计:目标对齐 功能描述 逻辑 / 规则 / 异常 开发:逻辑实现 交互说明 原型 / 标注 / 状态 设计:交互落地 验收标准 指标 / 通过率 / 边界 测试:标准验证 对应关系:每个模块 → 一组字段规范 → 一个主要读者角色,三者共同构成 PRD 的可执行结构 模块决定“放什么”,字段决定“怎么写”,视角决定“给谁看”