第3章：从零到一的PRD框架搭建：标准章节结构、核心元素清单、各模块目的、组织原则
3.1 为什么PRD需要“框架思维”？
很多B端产品经理在编写PRD时，习惯于“想一点写一点”，或者从网上找到一个模板直接套用。这种“填空式”写作的后果是：需求文档的结构东拼西凑，逻辑断层严重。开发看完后频繁追问场景，测试写出的用例与核心业务目标脱节。
在一个从零开始的B端系统项目中，PRD框架不是套话，而是指导“用户在什么业务场景下，通过什么角色，触发什么流程，系统应完成什么响应，并验证其价值”的思考路径。缺少框架，你的PRD就是一盘散沙；拥有框架，你才能做到需求完整、逻辑闭环、便于评审。
避坑提醒：不要把“需求背景”写成“公司简介”，不要把“功能描述”写成“技术实现方案”。PRD文档要回答的问题是：“我们要帮谁解决什么业务问题，系统怎么做，怎么证明做对了？”而不是“开发用什么语言、什么接口、什么框架来实现”。
3.2 标准章节结构：B端PRD要有哪些“骨架”？
一张标准的B端PRD结构表，是框架的起点。下面是我在多个从零到一项目中验证过的“七段式”结构，涵盖了业务、需求、方案、验收四个核心阶段。
| 章节模块 | 核心元素 | 模块目的 |
|---|---|---|
| 1. 业务背景与目标 | 业务现状、痛点描述、项目目标（定量指标）、收益预估 | 说明“为什么做”，让团队理解业务价值，对齐投入预期 |
| 2. 用户画像与使用场景 | 目标角色定义、使用场景列表、用户故事示例 | 明确“谁用、在什么情况下用”，避免功能失焦 |
| 3. 需求范围与优先级 | 功能清单（Epic/Story）、MoSCoW优先级、版本规划 | 划定“做什么、不做什么”，控制项目边界 |
| 4. 业务流程与规则 | 泳道图/流程图、业务判定规则、异常流程、前置条件 | 通过可视化逻辑让开发、测试准确理解业务流转 |
| 5. 页面与交互原型 | 页面截图/低保真原型、字段说明、操作交互规则 | 具象化系统界面，减少“文字描述与开发理解”的偏差 |
| 6. 数据与验收标准 | 核心数据字段定义、验收用例、通过/关闭标准 | 量化“做成什么样才算成功”，指导测试与交付 |
| 7. 附录与交付物模板 | 术语表、用户反馈记录、竞品调研摘要、变更日志 | 沉淀上下文信息，方便后期维护与新人交接 |
实战经验：这套结构在面向“企业内部OA审批系统”和“SaaS供应链平台”两个不同类型项目中验证过，唯一需要调整的是“业务流程与规则”章节在复杂业务场景下可能拆成2-3个子章节，但整体骨架不变。
3.3 核心元素清单：一个都不能少
在“七段式”结构的基础上，有几个元素是高频遗漏点，需要单独拎出来重点检查。
- 场景与问题的对应关系表：每个功能点必须能回溯到至少一个用户场景或业务痛点，避免“为了做功能而做功能”。
- 角色权限矩阵：B端系统核心特征是“多角色协同”，缺少权限定义的PRD会在开发阶段产生大量返工。
- 异常流程分支：至少有30%的PRD问题出在“流程异常耦合”上，例如：审批拒绝后是否允许二次提交、数据校验失败后用户能否保存草稿。
- 验收指标（KPI/Oracle）：不是技术指标，而是业务指标，例如：“订单审批效率提升20%”、“数据导出时间从5秒降到1秒内”。
- 依赖与前置条件：有哪些外部系统接口、数据同步时效、依赖第三方SDK等，必须提前写明，否则开发排期会严重失真。
效率技巧：可以做一个“核心元素自查表”以表格形式放入PRD附录，每次写完文档后逐行检查，打勾确认，可以大幅降低评审时被揪出缺漏的概率。
3.4 各模块目的：不只是“写出来”，要“说明白”
很多新人把PRD当成“功能说明书”来写，模块目的描述非常笼统。下面是每个章节的“目的解码”：
| 模块 | 真正要完成的目的 |
|---|---|
| 业务背景与目标 | 让非业务方（开发、测试、UI设计师）产生代入感，回答“为什么要花资源做这件事” |
| 用户画像与场景 | 避免把所有用户当作“同一类人”，区分高频场景与低频场景，指导功能优先级决策 |
| 需求范围与优先级 | 建立需求决策机制，防止“需求蔓延”；同时作为项目排期的输入 |
| 业务流程与规则 | 最小化文字描述的歧义，用流程图为沟通语言让各方达成一致 |
| 页面与交互原型 | 降低认知负载，让开发无需反复脑补“界面长什么样” |
| 数据与验收标准 | 从“把功能做完”升级到“把业务价值交付”，是UAT测试的必备输入 |
| 附录与交付物 | 提供决策上下文，让未来接手的人能看懂“当时为什么这么设计” |
3.5 组织原则：让PRD“好读”且“好审”
同样一份内容，组织结构不同，评审效果天差地别。我总结了四个核心组织原则：
- 按“认知流”组织，而不是按“开发流”：先讲业务场景，再讲功能细节，最后讲技术约束。让读者像读故事一样自然理解。
- 坚持“一个功能点对应一个验收标准”：需求拆分到足够细的颗粒度（通常是2-4天开发量），每个颗粒都有明确的验收条件。
- 用图表代替长段文字：一项针对PRD阅读效率的研究显示，配合流程图、表格的PRD比纯文字版PRD理解效率提升40%以上。
- 预留“变更追踪区”：在PRD文档最前面设置一个版本变更记录表，每次修改都注明“修改人、时间、修改内容、修改原因”。这能大幅降低后续“吵架”成本。
3.6 PRD框架结构图：一个实例
下面这张SVG结构图完整展示了“从零到一”的PRD框架组织路径，所有模块按“业务→需求→方案→验收”的认知流排布，箭头方向代表阅读与评审的自然顺序：
3.7 实战案例：一个“报销审批系统”的PRD框架应用
为了让你更直观地理解上述框架，我以一个简化版的企业内部报销审批系统为例，展示各模块的核心内容：
| 章节模块 | 核心内容示例 |
|---|---|
| 业务背景与目标 | 目前报销纸质流程平均耗时2天，财务审核重复粘贴票据效率低。目标：线上化后审批时效压缩到4小时内，人力成本降低30%。 |
| 用户画像与场景 | 员工：出差后提交报销单，高频场景是“差旅费用报销”；主管：在手机端快速审批，低频但紧急场景是“出差途中审批”；财务：批量审核并导出Excel做账。 |
| 需求范围与优先级 | MUST：报销单提交、审批流、影像上传；SHOULD：发票OCR识别；COULD：自动生成财务凭证；WON‘T：预算实时控制结合。 |
| 业务流程与规则 | 泳道图包含员工提交→主管审批（金额≤5000元可自动，否则转事业部总监）→财务审核→打款；异常场景：驳回时员工可修改后重新提交，超过7天未操作则自动退回。 |
| 页面与交互原型 | 包含报销单填写页面（字段：部门、事由、明细、金额、附件）、审批操作页（通过/驳回/转审）、财务批量审核列表（多选、批量导出）。 |
| 数据与验收标准 | 验收用例：用例1：员工提交报销单后5分钟内主管收到待办提醒；用例2：OCR识别准确率≥95%（以测试200张发票为准）；用例3：从提交到打款的全流程时长≤4h。 |
| 附录与交付物 | 包含“报销类型字典”、“预算中心成本代码表”、变更日志（V1.0.0初始版）、用户访谈纪要PDF。 |
3.8 PRD框架的“组织原则”自检清单
写完PRD后，对照下面三个问题做一次“原则自检”：
- [认知流检查]：一个不熟悉业务的人读这份PRD，是否能在30分钟内理解“谁、在哪、遇到什么问题、系统怎么解决、怎么验证效果”？如果不能，说明组织顺序有问题。
- [追溯性检查]：随机抽取一个验收标准，能否反向找到它对应的业务目标？如果找不到，说明需求拆解和验收标准脱节了。
- [完整性检查]：是否遗漏了异常流程？是否有“前置依赖”没有写出来？“角色权限”是否覆盖了所有使用场景？边界条件是否在需求“不做”清单中有说明？
避坑提醒：不要急于“填充内容”，在开始写任何功能描述之前，先用15分钟画出上面那种“框架结构图”，确认各模块之间的关系和顺序，再动笔。很多评审会上被卡住，就是因为框架本身就不通，结果改来改去都只是“缝缝补补”。
3.9 本章小结：PRD框架是团队的“认知地图”
从零到一的PRD框架搭建，本质上是搭建一张“让所有相关方都能看懂”的认知地图。它不是模板的堆砌，而是对业务、需求、方案和验收的系统性梳理。标准的结构、清晰的元素、有重点的目的、符合认知逻辑的组织原则，是你写出“一次过”PRD的基础。本章中给出的“七段式”结构和核心元素清单，建议你在自己的项目中直接复用，并根据实际业务做适度调整。