# PRD 到底要写什么：把成品上看不出来的决定写下来

用“成品上看不出来的决定才值得写”这条判据，讲清 PRD 必须落到纸面上的几块内容、哪些该留给工程和设计，以及它和用户故事、功能清单的区别

> 需求文档 · 团队协作 · 角色边界 · 约 6 分钟 · 10 月 14 日

## 本篇要点

1. PRD 要写的判据不是“重要不重要”，而是“产品做出来以后从成品上看不看得出来”——看不出来的才写，看得出来的不必重抄。
2. 按这条判据，必须落到纸面上的是：问题与证据、目标与非目标、范围与验收标准（含失败路径）、成功指标与基线、依赖风险与未决问题。
3. 不该由产品经理写进 PRD 的是技术实现和视觉交互细节：谁手里有信息谁定，PRD 只记录需要跨角色对齐的决定。
4. 产品经理唯一必须自己定的是做什么、不做什么、先做什么、什么算成功——这几件事没有别的角色能替你定。
5. 功能清单是一串已经选定的方案，用户故事是故意含糊的对话占位符，PRD 是整篇论证，卡片只是其中一节；只有卡片没有论证，容易做出每张票都自洽、合起来却不成形的产品。
6. 判断该写哪一种，看它还能不能被否掉：还能被否掉就写一页纸提案，决定已做才写 PRD。
7. 决定还没做、没有决策可做这两种情况下，完整 PRD 是负担；长度该由待定决策的数量决定，而不是功能数量。
8. PRD 一旦写出来自带“已经定了”的引力，所以它应该跟在产品探索之后，而不是用来替代探索。

---

上一篇结尾留了一句话：写完一张用户故事卡片之后，最该问团队的不是“写得清楚吗”，而是“哪里不对”。真做下去，很快会撞上下一个问题：卡片一次只讲一件事，那围绕整件事的背景——为什么要做、做多大、不做什么、怎么算成功——放在哪里？

通常的答案是 PRD（Product Requirements Document，产品需求文档）。但这个词带给新人的困惑比答案多：有人说它是产品经理最重要的产出，有人说它早该扔了。这两种说法可以同时成立，因为它们说的不是同一件事。

这篇回答的是：问题已经想清楚了，一份 PRD 该把什么落到纸面上，什么不该由产品经理写进去，以及它和用户故事、功能清单差在哪里。

## 一条判据：写下来的是成品上看不出来的东西

先给判据，再给清单：

**产品做出来以后，从成品本身看不出来的决定，才值得写下来；能从成品看出来的，不必重抄一遍。**

文档的作用是承载会随人走、随时间蒸发的东西。功能上线三个月后，没人能从界面上读出当初是为谁解决什么问题，负责的人也早换了；这类信息只能靠文字留下。反过来，界面上明摆着的东西，写进文档只会让人多读一遍。

按这条判据过一遍：

- **为什么做。** 从成品和代码里都反推不出来。
- **明确不做什么。** 最容易蒸发，因为它在成品上完全不可见：你只能看到做了的，看不到被主动放弃的。
- **怎么算成功，基线是多少。** 界面显示不出“转化率从 40% 涨到 55%”，更显示不出 40% 是起点。
- **边缘情况和失败路径当时怎么定的。** 做出来或许能反推结果，但“为什么这样处理”通常反推不出来。

反过来，**功能清单**（功能做出来，界面上就写着它是什么）、**技术实现方式**（代码里全都有）、**视觉和交互细节**（原型里全都有），都不必写。

这条判据顺手解释了另一件常被搞混的事：功能清单和 PRD 不是同一种东西的长短两版，而是两种东西。

## 一份最小可用的 PRD 长什么样

接着上一篇那张连锁餐饮的卡片往下写。你已经确认了问题：店长每周一早上要拿上周全部门店的关键经营数据向区域经理汇报，现在得在三个页面之间来回抄。围绕这张卡片，一页纸的 PRD 大致含这几块。

**问题与证据。** 一段话说清谁在什么时候遇到什么麻烦，以及你怎么知道它是真的：访谈过几个店长、客服工单里有没有相关抱怨、每周实际花多少时间在这件事上。

**目标与非目标。** 目标是可衡量的结果，不是功能。“把周一早上的数据准备时间从大约 40 分钟降到 5 分钟以内”是目标，“做一个导出按钮”是功能。非目标是这一版明确不做的事，比如不做定时自动推送、不做移动端适配。把不做什么写下来，相当于给范围装了一道闸门：后面有人中途加需求时，你不是在说“不”，而是指回整队人早就同意过的那个决定[3][5]。

**范围与验收标准。** 这一版包含哪些能力，以及每一条怎么算做完。上一篇的 Given-When-Then 放在这里，另外补上失败路径：如果上周数据只入库了一半，页面显示什么？一个区域下面有 60 家门店，表格怎么处理？这些是工程和测试最需要、又最不可能替你猜的地方。

**成功指标与观察窗口。** 一到三个数字，带上基线和上线后观察多久。没有基线，上线之后没人能判断它到底有没有用。

**依赖、风险、未决问题。** 这件事依赖上周数据在周一几点前入库，最大的风险是数据延迟。还没定下来的问题要写清谁负责、什么时候给答案，否则它们会一直躺在那儿。

可以看出，这几块没有一块是在描述界面。

## 哪些不该由产品经理写

前面“技术实现、视觉细节不用写”背后，是一个更一般的原则：**谁手里有信息，谁定这件事；PRD 只记录需要跨角色对齐的决定。**

技术方案（工程侧的 tech spec）由工程定，因为他们最清楚现有系统扛不扛得住；视觉与交互由设计定；工期由团队一起估。产品经理不该替他们把这些定死，一是你真没有那个信息，二是一旦写死，本来该被讨论的地方就不再被讨论了——这和上一篇讲的“卡片写得越像功能清单，讨论结束得越早”是同一个毛病[1][6]。

那产品经理必须定的是什么？只有一小类：**做什么、不做什么、先做什么、什么算成功。** 这几件事没有别的角色能替你定，也没有别的文档能替你承载。

Marty Cagan 提醒过一条边界：PRD 本身不坏，坏的是用它**替代**产品探索，而不是在探索之后把细节落下来[1]。如果还没验证过用户会不会用、技术上做不做得出来，一份写满需求的 PRD 只是把猜测包装成了既定事实。他还说过一句很准的话：PRD 一旦真的写出来，这份文档自有一种引力，人们不太会再去质疑里面的“需求”，而是默认它们已经成立[1]。

## 它和用户故事、功能清单不是同一样东西

**功能清单**是一串已经选定的方案。问题不在错，而在于它把“做什么”和“为什么做”压成一行行没有来由的条目，别人无法判断哪一条可以换、哪一条不能动。

**用户故事卡片**是故意写得含糊的占位符，一次一张，用来开启对话。含糊是它的设计意图，代价是把一堆卡片堆在一起，你仍然看不到整件事的问题、边界和成功标准。

**PRD 是整篇论证，卡片是其中的一节。** 只留卡片、不留论证的团队，容易做出“每张票都自洽、合起来却不成形”的产品[5]。

判断该写哪一种，看它还能不能被否掉：**还能被否掉，就写一份给决策者看的一页纸提案；决定已经做了、接下来只是要把它做对，才写 PRD。** 前者回答“值不值得做”，后者回答“做成什么样才算对”[4]。

## 什么时候干脆不要写

有两种情况，完整 PRD 是负担：决定还没做的时候，还能被否掉就写详细需求，是最贵的一种确认方式——你在花时间规定一件可能根本不会发生的事[4]；这件事没有决策可做的时候，改一句文案、修一个 bug，一张 ticket 就够了。

篇幅也由**待定的决策数量**决定，不是由功能数量决定。单个功能一页到两页通常够；新产品、跨多个团队、涉及合规的，才需要四到十页。有个很好用的删减标准：某一段读完之后，不会改变任何人要建的东西或要测的东西，就删掉它[5]。

最后一句：PRD 是活文档，不是签完字就冻结的合同。冻结式的做法适合一年只有一次发布机会的团队；在持续发布的团队里，实现过程中发现了新约束，就回去改文档，并在底部记一笔改了什么[2][5]。

## 术语表

- PRD（产品需求文档）：把已经想清楚的问题落成一份跨角色可对齐的文档，回答“做成什么样才算对”，而不是“值不值得做”。
- 非目标（non-goals）：这一版明确不做的事，跟目标同等重要，作用是给范围装一道闸门，挡住中途加进来的需求。
- 技术方案文档（tech spec）：工程侧描述“怎么做”的文档，与 PRD 分开写，避免两边的读者读到不属于自己的内容。
- 一页纸提案（one-pager）：给有否决权的人看的短文档，回答“值不值得做”，决定做出之后才转成 PRD。
- 活文档：会随实现过程中的新约束被修改并记录变更的文档，与签字后冻结的合同式做法相对。

## 来源

1. [SVPG: Discovery vs. Documentation — Marty Cagan 讲 PRD 本身不坏，坏的是用它替代产品探索，以及 PRD 写出来后的“引力”问题](https://www.svpg.com/discovery-vs-documentation/)
2. [SVPG: How To Write a Good PRD — 规格写得过少与过多分别会出什么问题，以及“少即是多”的取舍](https://www.svpg.com/wp-content/uploads/2024/07/How-To-Write-a-Good-PRD.pdf)
3. [Atlassian: What is a Product Requirements Document (PRD)? — 一份 PRD 需要的“刚好够用”的章节，含假设、用户故事，以及“我们不做什么”](https://www.atlassian.com/agile/product-management/requirements)
4. [Thinkr: One-Pager or PRD — 一页纸提案与 PRD 回答的问题、读者和失败模式的对照](https://usethinkr.com/blog/one-pager-vs-prd)
5. [ProductOS: What is a product requirements document (PRD)? — 各章节对应的失败模式、篇幅如何随决策量变化，以及“每张票自洽却合不成产品”](https://productos.dev/blog/product-requirements-document)
6. [ClickHelp: PRD vs MRD, BRD, Tech Spec, and User Stories — PRD 与 tech spec 的边界：PRD 说用户该体验到什么，tech spec 说系统怎么交付](https://clickhelp.com/clickhelp-technical-writing-blog/prd-vs-mrd-brd-tech-spec-and-user-stories-whats-the-difference/)

---

原文：https://pangzhengboyin.com/articles/what-a-prd-should-and-should-not-contain-a352fb82

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com