3.0 PRD 模板

• 一套可直接复制使用的 PRD 模板

---

[产品/功能名称] - 产品需求文档 (PRD)

0. 文档信息

0.1 文档状态

• 当前版本: [例如：5.1稿]
• 当前阶段: [例如：需求评审 / UI设计中 / 开发中 / 已上线]
• 创建人: [你的名字]
• 创建日期: [YYYY-MM-DD]
• 最后更新: [YYYY-MM-DD]
• 核心干系人: [产品、研发、设计、测试、业务等关键角色的负责人姓名]

0.2 更新记录

参考"三阶段迭代"原则，清晰地记录文档的迭代过程，让团队成员了解需求的演变。

版本号	版本状态	更新人	更新日期	核心更新内容
1.1	需求初稿	[姓名]	YYYY-MM-DD	初步阐述需求背景、目标和核心价值
2.1	方案评审稿	[姓名]	YYYY-MM-DD	补充核心业务流程、功能流程图和原型交互说明
2.2	方案评审稿	[姓名]	YYYY-MM-DD	根据项目评审会建议，修改XX功能逻辑
3.1	开发交付稿	[姓名]	YYYY-MM-DD	合入最终UI设计稿，补充边缘Case、埋点方案和上线计划
...	...	...	...	...

0.3 相关文档

列出所有与本项目相关的参考资料，方便团队成员查阅。

• 市场调研报告: [链接]
• 竞品分析文档: [链接]
• 用户研究/访谈纪要: [链接]
• 项目立项书 (如有): [链接]
• 交互原型 (Figma/Axure等): [链接]
• UI设计稿 (MasterGo/Figma等): [链接]
• 数据埋点需求文档 (单独维护时): [链接]
• 技术方案设计文档: [链接]

0.4 名词解释

对文档中可能引起歧义或团队不熟悉的专有名词进行解释。

术语	解释
[例如：UGC]	[User Generated Content，用户生产内容]
[例如：CTR]	[Click-Through Rate，点击率]
...	...

一、 需求背景与目标 (对应"需求初稿"核心内容)

1.1 项目概述

用一两句话高度概括这个产品/功能是做什么的，让读者快速建立初步认知。

[例如：本项目旨在为XX平台增加一个“AI智能摘要”功能，自动为长篇文章生成核心内容摘要，帮助用户在30秒内快速了解文章主旨。]

1.2 要解决的核心问题 (Problem Statement)

详细描述我们为什么要做这个需求。目标用户是谁？他们在什么场景下遇到了什么具体问题或痛点？这些问题带来了什么负面影响？

• 目标用户画像: [描述1-3个核心用户群体的特征，例如：知识工作者、大学生、内容创作者等]
• 用户场景 (Scenario): [描述用户在什么样的时间、地点和情境下会使用我们的产品]
• 核心痛点 (Pain Point):
  1. 痛点一: [例如：信息过载，用户每天需要阅读大量行业报告，但时间有限，无法全部精读，导致错过关键信息。]
  2. 痛点二: [例如：阅读效率低，对于非母语或专业性强的文章，理解门槛高，阅读耗时长。]
  3. 痛点三: [...]

1.3 用户故事 (User Stories)

从用户的视角出发，以“作为一名<角色>，我想要<完成某项任务>，以便于<实现某个价值>”的格式，来描述具体的需求。

• 故事一: 作为一名内容运营，我想要一键为长篇文章生成内容摘要，以便于快速生成社交媒体推广文案，提升工作效率。
• 故事二: 作为一名普通读者，我想要在阅读前快速浏览文章核心观点，以便于判断这篇文章是否值得花时间深入阅读。
• 故事三: [...]

1.4 项目目标与价值

阐述做这个项目的商业价值和用户价值是什么，以及我们期望达成什么样的具体目标。

• 用户价值: [对用户来说，这个功能有什么好处？例如：节省阅读时间、提升信息获取效率等。]
• 商业价值: [对公司来说，这个功能有什么好处？例如：提升用户活跃度、增加用户粘性、建立技术壁垒等。]
• 项目目标 (SMART原则):
  • [S] Specific (具体的): [例如：上线后，XX功能的使用率达到XX%]
  • [M] Measurable (可衡量的): [例如：通过数据埋点追踪功能点击率、摘要生成成功率、用户满意度评分等]
  • [A] Achievable (可实现的): [基于现有资源和技术能力，该目标是可达成的]
  • [R] Relevant (相关的): [该目标与公司“提升用户效率”的战略方向一致]
  • [T] Time-bound (有时限的): [在产品上线后3个月内达成]

1.5 需求范围

明确本次迭代“做哪些”和“不做哪些”，有效管理团队预期，避免范围蔓延。

• In-Scope (范围内):
  1. [功能点一]
  2. [功能点二]
  3. ...
• Out-of-Scope (范围外):
  1. [本次不做，但未来可能考虑的功能点一]
  2. [本次不做，但未来可能考虑的功能点二]
  3. ...

1.6 需求列表 (Requirements List)

将宏观需求拆解为具体的需求点，并进行优先级排序。

需求ID	模块	需求描述	优先级	状态	备注
R001	摘要生成	用户可以在文章页点击“生成摘要”按钮	高	规划中	核心功能
R002	摘要展示	生成的摘要以卡片形式在文章顶部展示	高	规划中
R003	用户反馈	用户可以对摘要质量进行“赞”或“踩”的评价	中	规划中	用于模型迭代
R004	复制分享	用户可以一键复制摘要内容或分享给好友	中	规划中	提升传播性
R005	历史记录	用户可以在个人中心查看历史生成的摘要	低	规划中	V2.0考虑
...	...	...	...	...

二、 方案概述 (对应"方案评审稿"核心内容)

这部分旨在从宏观层面介绍产品方案，让团队对产品的整体结构和流程有清晰的认识。

2.1 核心业务流程图 (Business Flow)

描述用户如何通过一系列操作完成核心任务的完整流程，体现业务逻辑。

图注: [对上述流程图进行必要的文字补充说明]

2.2 核心功能流程图 (Function Flow)

展示产品的主要页面和功能模块是如何组织和串联起来的，体现信息架构。

图注: [对上述流程图进行必要的文字补充说明]

2.3 信息架构图 (IA)

展示产品包含的所有信息内容，以及它们之间的层级和组织关系。

• 首页
  • 导航栏
  • 推荐列表
• 文章详情页
  • 文章内容
  • AI摘要模块
  • 评论区
• 个人中心
  • 个人信息
  • 历史记录
    • 摘要历史
  • 设置

三、 细节方案 (对应"开发交付稿"核心内容)

这部分是对产品方案最详尽的描述，是研发、设计和测试同学工作的直接依据。

3.1 功能详述：[模块/功能点一，例如：AI摘要生成与展示]

按功能模块或页面进行拆解，逐一说明。

3.1.1 页面原型与交互说明

• UI设计稿: [附上该功能最终确认的UI设计稿截图或链接]
• 交互逻辑:
  1. 初始状态:
     • 在文章标题下方，摘要模块默认不显示。
     • 在页面右侧悬浮一个“生成摘要”的图标按钮。
  2. 触发操作:
     • 用户点击“生成摘要”按钮。
     • 按钮变为“生成中...”的加载状态，并有动效，不可再次点击。
  3. 成功状态:
     • 加载结束后，悬浮按钮消失。
     • 在文章标题下方，平滑展开摘要卡片。
     • 卡片内容包括：摘要文本、“赞”、“踩”、“复制”、“分享”四个操作按钮。
  4. 失败状态 (网络/服务异常):
     • 按钮恢复为“生成摘要”的初始状态。
     • 在页面顶部弹出Toast提示：“摘要生成失败，请检查网络后重试”。
  5. 空状态 (文章过短无法生成):
     • 点击按钮后，在页面顶部弹出Toast提示：“文章篇幅较短，无需生成摘要”。
• 数据需求:
  • 前端需向后端传递当前文章的Article_ID。
  • 后端返回摘要内容Summary_Text及摘要Summary_ID。

3.1.2 边缘Case处理

• 用户在摘要生成过程中退出页面怎么办？ [定义处理逻辑，例如：中断生成请求]
• 用户快速、反复点击“生成摘要”按钮怎么办？ [定义处理逻辑，例如：做防抖处理]
• 摘要内容过长，在卡片中如何显示？ [定义处理逻辑，例如：最多显示N行，超出部分...展开]

3.2 功能详述：[模块/功能点二，例如：用户反馈]

...（重复3.1的结构，描述下一个功能点）...

3.3 非功能性需求

• 性能需求:
• 兼容性需求: [例如：需要兼容Chrome、Safari、Firefox三大主流浏览器的最新两个版本，以及iOS和Android系统]
• 数据统计/埋点需求:

事件名称	触发时机	页面/位置	上报参数	备注
click_generate_summary	点击“生成摘要”按钮时	文章详情页-悬浮按钮	article_id
summary_generate_success	摘要生成成功时	-	article_id, duration	duration为耗时(ms)
click_summary_like	点击摘要“赞”按钮时	文章详情页-摘要卡片	summary_id

四、 上线计划与运营

定义需求的生命周期和上线后的相关事宜。

4.1 上线排期 (Roadmap)

• 需求评审: [YYYY-MM-DD]
• UI/UX设计: [YYYY-MM-DD] ~ [YYYY-MM-DD]
• 研发阶段: [YYYY-MM-DD] ~ [YYYY-MM-DD]
• 测试阶段: [YYYY-MM-DD] ~ [YYYY-MM-DD]
• 预计上线日期: [YYYY-MM-DD]

4.2 A/B测试方案 (如需要)

• 测试目标: [例如：验证新的摘要卡片UI是否能提升用户反馈率]
• 实验分组:
  • A组 (对照组): 使用旧版UI
  • B组 (实验组): 使用新版UI
• 流量分配: [A组50%，B组50%]
• 核心指标: [用户反馈率（点赞+点踩次数/摘要展示次数）]
• 上线/下线标准: [当B组核心指标显著优于A组，且无负向指标，则全量上线]

4.3 灰度发布计划 (如需要)

• 第一阶段: [YYYY-MM-DD]，对公司内部员工开放。
• 第二阶段: [YYYY-MM-DD]，对1%的种子用户开放。
• 第三阶段: [YYYY-MM-DD]，逐步放量至10%、50%，直至全量。

五、 附录

存放一些不属于正文但对项目有重要参考价值的信息。

• 会议纪要: [链接]
• 用户反馈原始记录: [链接]
• Q&A:
  • Q1: [研发/测试提出的问题]
  • A1: [产品经理的解答]