PRD 产品需求文档编写指南：结构与步骤

PRD（产品需求文档）是产品开发流程中用于向研发与测试团队说明"本次发布必须包含哪些能力"的文档。ProductPlan 指出，PRD 通常被用于瀑布式环境，但在敏捷中同样可以使用。它不描述具体实现方案，而是牢牢扎根于用例与期望功能。

PRD 与 MRD 的区别

MRD（市场需求文档）回答的是"市场机会与业务理由"——客户需求、市场机会、产品或其发布的商业论证。PRD 则不再涉及市场机会与收入，只聚焦于用例与功能。它列出的每一项功能或能力通常都会配一个用例。基于 PRD，工程团队会编写功能规格说明（描述如何实现）、架构设计文档，UX 团队产出线框与原型，QA 则会编写覆盖每个用例的测试计划。

简言之：MRD 说明"为什么要做"，PRD 说明"要做什么"。

PRD 应包含哪些模块

一份完整的 PRD 通常包含以下部分：

  • 目标 / 目的（Objective/Goal）：解释为什么构建这个功能，希望达成什么。
  • 功能（Features）：每个功能至少包含描述、目标和用例；复杂功能可以拆成子项，每个子项也应尽量附带用例。同时可以说明范围外（out-of-scope）的内容。
  • UX 流程与设计说明（UX Flow & Design Notes）：这个阶段不需要像素级线框，而是描述整体用户工作流，确保发布目标能达成。
  • 系统与环境要求（System & Environment Requirements）：支持哪些终端环境，例如浏览器、操作系统、内存与处理能力。
  • 假设、约束与依赖（Assumptions, Constraints & Dependencies）：假设是预期成立但未保证的前提（如"所有用户都有网络连接"）；约束是最终实现不能逾越的限制（预算或技术限制）；依赖是产品依赖的外部条件（如依赖 Google Maps 提供路线功能）。

创建 PRD 的步骤

假设 MRD 已经存在，ProductPlan 建议按以下顺序推进：

  1. 与产品营销对齐：先确认本次发布背后的业务驱动因素，确保理解一致。
  2. 确定范围：使用团队已有的需求优先级方法，确定哪些进入本次发布。
  3. 起草文档：基于每个功能收集到的笔记与用户反馈撰写正文。
  4. 多轮评审：尽量与产品团队的其他成员一起过几轮，尽可能提前回答潜在问题。
  5. 与业务方确认：把完整 PRD 分发给业务侧干系人，确认他们对发布目标和功能一致认可。
  6. 交给工程：与工程团队讨论澄清、回应挑战，必要时更新 PRD，目标是"后面不再有意外"。
  7. 传递给下游：达成一致后，文档进入 UX 设计、功能规格说明和测试计划阶段。

把所有这些团队纳入创建与评审过程，能让每个人都对"要交付什么、如何惠及业务、对用户有何影响"达成一致。

一份 PRD 的骨架长什么样

与其纠结模板，不如看一份能落地的骨架。以"给后台加一个导出功能"为例：

目标：让运营在 10 分钟内导出任意时间段的订单数据
功能：订单导出
  描述：按筛选条件导出 CSV/Excel，支持 5 万行上限
  用例：运营选择 6/1-6/30 的已支付订单 → 点击导出 → 后台异步生成 → 邮件+站内信通知下载
范围外：自定义报表模板、定时自动导出
系统要求：Chrome/Safari 最新两个大版本；CSV 用 UTF-8 with BOM（避免 Excel 乱码）
假设：订单量 < 100 万行；依赖：对象存储可用
约束：导出必须在 3 分钟内完成，否则超时

注意"用例"写得越具体，QA 越好写测试，研发越好估工时。含糊的"支持导出"四个字，是 PRD 里最常见的坑。

一次 PRD 翻车的复盘

某个团队给"会员积分"功能写 PRD，只写了"用户可以获得积分并兑换"，结果研发按"积分可抵扣任意商品"实现，上线后运营才发现规则是"仅限部分商品"，又花了两周返工。复盘时发现：PRD 没写"范围外"，也没写积分过期策略。这两行字如果当时写清楚，能省下两周。

教训是：范围外（out-of-scope）和边界条件（过期、上限、负数）才是 PRD 最容易漏、也最值钱的部分。

评审时问哪几个问题

评审 PRD 时，值得逐条过一遍这些问题：

  • 每个功能都有用例吗？没有用例的功能，为什么要做？
  • 范围外写了什么？边界条件（上限、过期、异常）覆盖了吗？
  • 依赖项是否有人负责跟进？假设是否需要升级成正式需求？

在 AI 时代 PRD 的定位

Mind the Product 曾指出，AI 时代静态 PRD 已经无法独自承担规格说明的职责——"什么是好的输出"需要可运行的评估集。但对大多数网站与业务应用，PRD 仍是目标、边界与用例的可靠载体；把 PRD 的"为什么/为谁"与评估集的"做什么"结合起来，是最务实的做法。撰写范围时，也可以同步参考技术栈评估指南，确保功能需求与实现方案在立项阶段就对齐。

16IDC 观察

对建站与 SaaS 团队，PRD 的核心价值是让"要做什么"在动手前达成一致。不必追求长篇大论，但目标、功能、用例、系统要求、假设约束五大模块缺一不可，且一定要经过多轮评审。更完整的分析流程，可参考本站需求分析分类。

原文来源：https://www.productplan.com/learn/product-requirements-document/
参考：Atlassian 的 PRD 指南 https://www.atlassian.com/agile/product-management/product-requirements-document