第2章 PRD核心框架：标准结构、各模块目的、撰写原则

一份高质量的产品需求文档（PRD）并非随意堆砌需求的草稿，而是一套结构化、可追溯、可验证的工程蓝图。本章将深入解析PRD的核心框架——从标准结构到各模块的设计目的，再到撰写时必须遵循的原则。掌握这个框架，你将获得一个通用“骨架”，机会评分模型则作为核心“血液”贯穿其中，驱动需求优先级决策。

2.1 PRD标准结构的7大模块

结合业界最佳实践与机会评分的特殊要求，我们定义了以下标准PRD结构。该结构确保从“为什么做”到“做成什么样”的逻辑链路完整闭环。

2.2 核心模块的目的与撰写原则

以下是框架中最关键的4个模块——它们直接承载了“机会评分”的输入、计算与输出流程。我们结合用户场景与业务问题详细拆解。

2.2.1 业务背景与机会评分

目的：让所有阅读者（产品、开发、测试、业务方）在5分钟内理解“为什么要做这个功能”以及“它值不值得做”。

撰写原则：

• 数据前置：第一段就给出核心商业数据或用户问题严重程度。例如：“当前注册转化率仅2.1%，显著低于行业均值5.3%。用户访谈中，67%的用户在‘填写手机号’步骤流失。”
• 机会评分表固定位置：在模块最下方嵌入评分表。该表包含：机会维度（用户痛苦度、市场规模、可行性、战略匹配度等）、权重、原始分、加权总分。
• 避免空泛描述：不要写“用户体验不好”，而要写“用户完成一项任务的平均时间从3秒增加到15秒，NPS评分下降12分”。

2.2.2 用户场景与需求拆解

目的：将抽象的业务问题转化为具体的“用户-系统-行为”三元组，为方案设计提供最小颗粒度的输入。

撰写原则：

• 场景驱动：使用“在什么时间/地点/情绪下，用户试图完成什么任务”的句式。例如：“在月末对账高峰期，财务总监试图从异常交易列表中筛选出金额超过10万元的记录。”
• 需求颗粒度一致：每个需求点应是一个不可再分的原子操作。例如：“系统应支持按交易金额降序排列”是一个需求；“优化对账体验”则过于模糊，需要进一步拆解。
• 关联用户访谈原文：在需求点旁标记原始访谈ID。如“需求点R-002”对应“访谈记录-FD-210”第3行。这既是可追溯性要求，也为后续机会评分提供原始证据。

2.2.3 指标验证与验收标准

目的：将模糊的“做得好”转化为可量化的数字。这是机会评分模型中“置信度”维度的核心验证环节。

撰写原则：

• 业务指标与系统指标分层：业务指标（如“月活跃用户数提升5%”）用于衡量最终价值；系统指标（如“搜索响应时间<200ms”）用于验收技术实现。
• SMART原则：指标必须具体(Specific)、可测量(Measurable)、可达成(Achievable)、相关性高(Relevant)且有截止时间(Time-bound)。例如：“在上线后30天内，核心功能路径的日均完成率从45%提升至60%。” 这是可验证的。
• 验收标准与需求点1对1映射：每个原子需求点都应有对应的验收条件。例如：需求点“支持按日期范围筛选订单”——验收标准“在筛选组件中选择2024-06-01至2024-06-30，点击查询后，列表仅显示该时段内的订单数据，且查询耗时不超过1.5秒”。

2.2.4 方案表达与功能范围

目的：清晰界定该版本“做什么”和“不做什么”，避免需求蔓延。

撰写原则：

• 使用“功能范围清单”格式：明确列出“包含的功能列表（In Scope）”和“明确排除的功能列表（Out of Scope）”。Out of Scope 列表建议包含理由，例如：“暂不支持批量导入功能——因本次机会评分中该维度的可行性得分较低。”
• 交互描述优先于UI细节：在早期PRD中，用文字描述用户流程和系统反馈即可。只在关键决策点附上低保真原型说明（非代码，仅用HTML表格或示意图）。
• 方案应体现评分权衡：如果选择了方案A而非方案B，应当在方案表达中附带简短的评分对比，说明为何A在“开发成本”与“用户价值”上取得了更优的得分。

2.3 内联SVG：PRD核心框架与机会评分流程

下图展示了PRD核心模块之间的逻辑流。注意，“业务背景与机会评分”模块是起点，其输出直接影响“方案表达”的范围；而“用户场景与需求拆解”模块产生的原子需求，又将回流到“指标验证”模块形成闭环。

2.4 撰写原则总结：如何写出可直接用于“机会评分”的PRD

在撰写本章所述的每个模块时，请不断问自己以下三个问题，它们是你与“优秀产品经理”的分水岭：

1. 可追溯吗？ 我的每一个需求点、每一个评分维度，能否找到对应的原始用户访谈记录或数据报告？
2. 可验证吗？ 我的指标是否能在上线后由测试或数据分析师通过客观数据验证，而不依赖主观判断？
3. 可提效吗？ 我的PRD是否每个模块都直接服务于“机会评分”的计算与决策？是否存在与评分无关的冗余描述？