PRD 是什么 —— 从"想清楚"到"写下来能开工"

本课导读

第一单元的五层模型解决了"按什么顺序想清楚"，这个单元解决下一个问题："想清楚之后，怎么写成一份别人拿去就能干活的文档"。这份文档在行业里有个通用名字：PRD（Product Requirements Document，产品需求文档）。本课先看全景：一份典型的 PRD 由哪 8 个部分组成、每部分和五层模型怎么对应、以及 PRD 最重要的一个隐藏属性——它是写给谁看的。预计 30 分钟。

一份典型 PRD 的 8 个部分

把开篇那张图重制成表格，并标注每部分回答的问题：

部分	回答的问题	一句话职责
① 产品概述	为什么做？	说明功能目的，以及它如何支撑更大的产品目标
② 用户角色	给谁做？	识别功能服务谁、他们怎样与它交互
③ 问题场景	解决什么？	描述用户工作流中这个功能要解决的具体情境
④ 功能需求	做什么？	定义预期的产品行为和功能
⑤ 工作流与边界情况	怎么运转？	记录用户流程与各场景下的异常情况
⑥ 依赖	靠什么？	指出集成关系、先后次序、系统间关系
⑦ 验收标准	怎么算做完？	确立验证功能就绪的条件
⑧ 成功指标	怎么算做对？	定义上线后评估功能影响的指标

8 个部分天然分成四组，记这四组比记八条容易：

• 为什么 + 给谁（①②③）：把战略层和用户需求浓缩进文档开头
• 做什么（④⑤）：文档的正文主体，对应范围层的功能规格 + 结构层的流程设计
• 靠什么（⑥）：工程现实——这个功能不是孤岛
• 怎么验（⑦⑧）：两把不同的尺子——⑦量"做完了吗"（上线前），⑧量"做对了吗"（上线后）

PRD 和五层模型的关系：一个管想，一个管说

把两张图叠在一起看，对应关系立刻浮现：

• 产品概述、成功指标 ← 战略层的产品目标与成功指标，原样进文档
• 用户角色 ← 战略层的用户细分与画像
• 问题场景 ← 范围层"需求三来源"里最可靠的那个：用户调研挖出的真实卡点，写成场景故事
• 功能需求 ← 范围层的功能规格（三纪律直接沿用）
• 工作流与边界情况 ← 结构层的交互设计：主流程 + "然后呢"的全部分支
• 依赖、验收标准 ← 五层模型没展开的部分——因为 Garrett 讲的是设计决策，而 PRD 还要服务工程协作，这两块是协作补丁

所以一句话定位：五层模型是思考框架，PRD 是这份思考面向执行团队的输出格式。想不清就写，PRD 变成字数游戏；想清了不写，决策只活在你脑子里——两头都得占。

PRD 最重要的隐藏属性：读者

文档的质量不由作者定义，由读者能不能拿它干活定义。一份 PRD 至少有四种读者，各自来找不同的东西：

• 工程师：翻功能需求和边界情况——"这个字段可以为空吗？失败了显示什么？"
• 设计师：翻用户角色和工作流——"这个流程几步？谁在用？"
• 测试：直接把验收标准变成测试用例
• 三个月后的你自己：翻产品概述——"当初为什么做这个来着？"

由此推出三条写作纪律：

1. 能开工是唯一标准：写完自问"工程师读完会不会来问我问题？"每个预料中的提问，都是文档里的一个洞
2. 不是越长越好：PRD 的敌人不是短，是歧义和缺漏。一页纸把 8 部分说清楚的 PRD，好过三十页的正确的废话
3. 活文档：需求会变。PRD 要有版本与变更记录，改了要通知读者——过期的 PRD 比没有 PRD 更危险，因为它带着权威性误导人

✍️ 练习

练习 1：内容安检

下面五条内容，哪些该进 PRD？该进的话进哪个部分？不该进的说明去哪：

1. "撤销按钮使用 #8A8F98 描边、8px 圆角"
2. "导出功能依赖笔记服务的批量读取接口，该接口本月底才上线"
3. "用户 A 反馈：整理三个月笔记时找不到批量导出，只能一篇篇复制"
4. "数据库选 PostgreSQL 还是 MySQL"
5. "导出的 zip 中每篇笔记为独立 .md 文件，文件名取笔记标题"

✅ 参考答案

1. 不进——表现层细节，归设计稿/风格指南
2. 进 · 依赖——典型的时序依赖，不写进去排期必爆
3. 进 · 问题场景——真实用户的真实卡点，正是场景故事的原材料
4. 不进——技术选型归技术方案文档；PRD 说"要什么行为"，不说"用什么实现"
5. 进 · 功能需求——具体、可检验的行为定义（注意它顺手通过了范围层三纪律）

判断口诀：行为与目的进 PRD，视觉归设计稿，实现归技术方案。

练习 2：给旧文档验伤

找一份你工作中见过的需求文档（或回忆一次"口头需求"），对照 8 部分打勾：哪些部分有？哪些缺？缺的部分后来是否真的引发了返工、扯皮或延期？

✅ 参考思路

最常见的缺失分布：边界情况（缺了 → 开发中途"那网断了怎么办"现场拍脑袋）、依赖（缺了 → 上线前夜发现要等另一个团队的接口）、成功指标（缺了 → 功能上线即结案，没人知道它有没有用，下次决策依旧拍脑袋）。你会发现缺失的几乎从来不是"功能需求"本身——人人都记得写要做什么，教训全在做什么之外的 7 个部分里。

📝 随堂测验

随堂测验0 / 5 题正确

1. PRD 的 8 个部分可以归成四组，正确的分组是？

A前端、后端、测试、运营B为什么+给谁（概述/角色/场景）、做什么（需求/工作流）、靠什么（依赖）、怎么验（验收标准/成功指标）C战略、战术、执行、复盘D必做、应做、可做、不做

2. 验收标准和成功指标都是“验”，区别在于？

A没有区别，写一个就行B验收标准量“做完了吗”（上线前，验证功能就绪）；成功指标量“做对了吗”（上线后，评估实际影响）C验收标准给老板看，成功指标给工程师看D成功指标更重要，验收标准可以省略

3. PRD 与五层模型的正确关系是？

A两者是竞争关系，选一个用B五层模型是思考框架（管想清楚），PRD 是面向执行团队的输出格式（管说清楚）——想不清就写是字数游戏，想清不写决策只活在脑子里CPRD 已过时，五层模型是替代品D五层模型只适用于网站，PRD 只适用于 App

4. “这里放一个蓝色描边圆角按钮”写进 PRD 的问题是？

A蓝色不好看B越过了楼层——PRD 主体在战略/范围/结构层，应规定行为（此处可撤销），表现层细节归设计稿C写得不够详细D没有问题，越具体越好

5. 为什么说“过期的 PRD 比没有 PRD 更危险”？

A占用存储空间B它带着文档的权威性误导读者——需求变了文档没变，团队会理直气壮地做错C会被审计发现D并不危险，写过就有价值

本课小结

• PRD 8 部分四组：为什么+给谁（概述/角色/场景）、做什么（需求/工作流）、靠什么（依赖）、怎么验（验收/指标）
• 与五层模型的分工：五层管想清楚，PRD 管说清楚；依赖与验收是面向工程协作的补丁
• 质量标准只有一条：读者拿它能不能开工——每个预料中的提问都是文档的洞
• 三纪律：能开工是唯一标准、敌人是歧义不是篇幅、活文档要有版本与变更通知
• 楼层纪律：行为与目的进 PRD，视觉归设计稿，实现归技术方案

下一课从文档开头写起：产品概述、用户角色、问题场景——PRD 的前三分之一决定了读者信不信你后面写的一切。