第4章：PRD结构模板：标准章节、必填字段与附录要求

4.1 适用场景

本章模板适用于公司内部所有B端、C端及后台管理系统的PRD编写工作。当产品经理开始编写一个新项目、大型迭代或跨团队协作需求的PRD时，必须以此模板为基准，确保文档结构统一，方便研发、测试、UI及运营人员快速定位关键信息。

4.2 前置条件

1. 已完成《项目/需求启动会》或《需求全景评审》，输出需求全景图与用户故事地图。
2. 已确认产品版本号、里程碑节点及本次迭代范围。
3. 已准备《竞品分析报告》或《用户反馈汇总》作为背景数据。

4.3 输入输出物

输入物	输出物
需求全景图、用户故事地图、竞品分析报告	标准PRD文档（含必填字段与附录）
项目启动会议纪要	PRD变更记录表（初始版本）

4.4 责任边界

产品经理负责PRD正文；研发及QA应在PRD发布前完成技术可行性标注；UI可在PRD终稿阶段提供交互示意。

• 产品经理：编写主体内容，同步版本历史。
• 开发工程师（Tech Lead）：在“技术实现”附录中标注兼容性、环境依赖及变更风险。
• 测试工程师：审核验收标准的可测性，回写测试用例关联。

4.5 标准章节与必填字段

下表示PRD正文必须包含的章节及每个章节内“必填字段”清单。缺失任一字段将视为PRD不完整，无法进入技术评审。

序号	标准章节	必填字段	说明/示例
1	需求背景	目标用户、业务痛点、核心收益	“B端客服：平均工单处理时间＞30分钟；期望降至15分钟”
2	产品范围	本版包含功能列表、不包含功能列表	包含：工单实时指派；不包含：多坐席协同编辑
3	用户交互流程	主流程泳道图、异常流程说明	泳道图需标注角色及系统边界
4	功能详述	前置条件、触发入口、界面原型、操作步骤、页面规则、后置条件	每条功能必须包含“后置条件”，否则QA无法确认退出状态
5	非功能性需求	性能指标（TP99/并发数）、兼容性要求、安全合规	查询接口TP99＜200ms；支持Chrome/Firefox/企业微信
6	验收标准	通过/失败条件、验证数据、回归范围	每条标准必须包含“预期结果”与“实际结果”字段

4.6 操作步骤：构造标准PRD章节

4.6.1 组装需求背景章节

1. 定义目标用户群体（一句话描述）。
2. 量化业务痛点（使用数据或用户访谈摘要）。
3. 明确期望收益（降本/增效/体验提升的具体指标）。

4.6.2 定义产品范围

1. 列出“本次包含功能”，每项功能必须有可验证的产出。
2. 明确“本次不包含功能”，避免需求范围蔓延。

包含功能：
- 工单智能分类（基于关键词+历史数据）
- 工单优先级排序（P0/P1/P2三级）
不包含功能：
- 多语种自动翻译（延至第三个版本）
- 实时坐席调度（需配合大屏模块）

4.6.3 编写功能详述（必填字段验证）

每个功能点必须包含以下完整字段，缺一不可。

• 前置条件：用户已登录且拥有该权限。
• 触发入口：“工单详情页→更多操作→智能分类”。
• 界面原型：标注关键交互元素（按钮/输入框/状态变化）。
• 操作步骤：1、点击；2、弹窗；3、确认；4、反馈。
• 页面规则：弹窗默认宽度600px；确认后加载状态不超过3秒。
• 后置条件：工单状态更新为“分类完成”，触发通知。

4.7 附录要求

PRD正文后必须附带以下实体附录，不提供附录即算文档不完整。

附录编号	附录名称	必填内容
A	数据字典	字段名、类型、长度、枚举值、业务定义
B	接口清单	接口名、请求方式、入参/出参说明、依赖系统
C	埋点设计	事件名称、触发时机、采集参数
D	变更记录	版本、时间、变更人、变更摘要

4.8 异常处理

异常场景	处理方式
需要多版本并行维护	在PRD开头标注“版本分支”，每版本独立文件夹维护附录
研发提出技术约束导致字段修改	PM更新PRD版本号，并在变更记录附录中说明改动点及影响范围
附录冲突（如数据字典与接口字段不一致）	以数据字典为准，接口附录需标注“参考数据字典版本号”

4.9 记录材料

• PRD模板版本号：V2.1（2025-03-15发布）。
• 模板审批记录：PMO + 技术VP 签批版本。
• 本次PRD正文对应的Jira Epic链接：https://jira.xxx.com/browse/EPIC-1234。

4.10 验收标准

1. PRD正文包含需求背景、产品范围、用户交互流程、功能详述、非功能性需求、验收标准共计6个标准章节。
2. 每个功能详述具备全部6个必填字段（前置条件、触发入口、界面原型、操作步骤、页面规则、后置条件）。
3. 附录至少包含数据字典、接口清单、埋点设计、变更记录4项。
4. 未出现“不包含功能列表”为空或缺失的情况。

4.11 PRD结构模板示意图