工具箱 · 第 2 篇

PRD 怎么写：模板与工具

PRD（Product Requirements Document，产品需求文档）是产品经理最核心的产出物之一。它不是写给自己看的，而是写给开发、设计、测试、运营看的——它要回答一个核心问题：“我们到底要做什么，做成什么样。”

很多新人对 PRD 有一种恐惧感，觉得这是一份“很正式、很长、很难写”的文档。其实不是。PRD 的本质是把需求讲清楚，形式可以非常灵活——有些团队用 Word，有些用飞书文档，有些甚至用一张表格就搞定。

关键不在于格式多规范，而在于读你文档的人能不能看完就动手干活，不用再来问你十遍。

PRD 的核心结构

不管你用什么模板、什么工具，一份好的 PRD 应该包含以下几个模块。

1. 需求背景

回答“为什么做这个需求”。

这是整份文档最容易被忽略、却最重要的部分。开发工程师不是执行机器，他们需要理解“为什么”才能做出更好的技术决策。

写法示例：

背景： 近 30 天数据显示，新用户注册流程的第三步（手机号验证）流失率达 42%，远高于行业平均水平（约 20%）。通过用户访谈发现，主要原因是验证码短信延迟高（平均 15 秒），导致用户失去耐心直接退出。

目标： 将第三步流失率从 42% 降低到 25% 以内。

注意几个要点：

• 用数据说话，不要写“很多用户反馈体验不好”这种模糊表述
• 写清楚衡量标准，让团队知道“做到什么程度算成功”
• 交代信息来源，数据从哪来的、用户访谈了几个人，增加可信度

2. 需求范围

回答“这次做什么，不做什么”。

明确边界非常重要。如果不写清楚“不做什么”，开发评审时一定会问“那这个场景要不要处理？那个情况要不要考虑？”——然后需求范围不断膨胀，排期不断延长。

写法示例：

本期做：

• 接入新的短信通道（阿里云短信），将验证码下发时间缩短到 5 秒内
• 增加“60 秒后可重新发送”的倒计时提示
• 验证码输入框支持自动填充（iOS / Android）

本期不做：

• 不改注册流程的其他步骤
• 不做语音验证码（后续版本考虑）
• 不改现有的图形验证码逻辑

3. 用户故事 / 使用场景

回答“用户在什么情况下会用到这个功能”。

用户故事的经典格式是：作为 [某类用户]，我想要 [完成某个动作]，以便 [达到某个目的]。

写法示例：

场景 1： 小王是一个新用户，通过朋友分享的链接下载了 App。他在注册时输入了手机号，点击“获取验证码”后等了 20 秒还没收到短信，于是点了“重新发送”，结果收到了两条验证码，不知道该输哪个——最终直接卸载了 App。

优化后的预期体验： 小王点击“获取验证码”后 3 秒内收到短信，输入框自动填充验证码，整个过程不超过 10 秒。

场景描述要具体。不要写“用户注册时可能遇到问题”，而是写出一个活生生的人在具体环境下的具体行为。这样开发和设计才能代入场景去思考。

4. 功能详细描述

回答“具体怎么做，做成什么样”。

这是 PRD 篇幅最长的部分，需要把每一个功能点拆细到开发可以直接写代码的程度。

每个功能点应该包含：

• 功能说明：用文字描述功能的逻辑
• 交互说明：点击某个按钮后发生什么，页面怎么跳转
• 原型图：配合文字说明，嵌入或链接到原型
• 异常处理：网络错误、输入异常、超时等情况怎么处理
• 文案：按钮文字、提示语、错误信息的具体文案

写法示例：

功能：验证码倒计时

• 用户点击“获取验证码”按钮后，按钮变为灰色不可点击状态，显示“重新发送（60s）”
• 倒计时每秒更新，从 60 递减到 0
• 倒计时结束后，按钮恢复可点击状态，文案变为“重新获取”
• 用户在倒计时期间切到后台再回来，倒计时继续（不重置）
• 同一手机号 24 小时内最多发送 10 次验证码，超出后提示“发送次数过多，请明天再试”

5. 数据埋点

回答“上线后怎么衡量效果”。

这部分很多新人 PM 会遗漏，但它直接决定了你上线后能不能验证需求的效果。

写法示例：

6. 排期与里程碑

回答“什么时候做完”。

这部分通常在需求评审会上和开发一起确认，PM 先给出一个预期时间，然后根据技术评估调整。

阶段	负责人	预计时间
设计出图	设计师 A	4.16 – 4.18
前端开发	前端 B	4.19 – 4.23
后端开发	后端 C	4.19 – 4.22
联调测试	测试 D	4.24 – 4.25
灰度上线	PM	4.26

PRD 的三种“保真度”

不同场景下，PRD 的详细程度应该不同。

一页纸 PRD（轻量版）

适用场景： 小需求、bug 修复、运营配置类需求。

格式可以是飞书文档里一个简短的段落，甚至是 JIRA 工单里的描述字段。核心信息压缩在一页以内：背景 + 做什么 + 验收标准。

标准 PRD

适用场景： 中等规模的功能迭代，需要跨角色评审。

包含上面提到的完整结构（背景、范围、场景、详细描述、埋点、排期），通常 3-10 页。

产品方案书（重量版）

适用场景： 全新产品或大型功能模块从 0 到 1，需要拉齐多个部门。

在标准 PRD 的基础上增加：市场分析、竞品对比、商业模式、用户画像、数据预估（DAU / 收入模型）、长期规划。通常 10 页以上，有时配合 PPT 做汇报。

选择原则： 用最小的文档量传达最完整的信息。小需求写一页纸就够了，硬往标准模板里套反而浪费所有人的时间。

用什么工具写 PRD

飞书文档 / 钉钉文档

国内团队的主流选择。

优势在于和协作平台打通——文档里可以 @同事、插入 JIRA 链接、嵌入 Figma 原型、用评论功能做异步讨论。大部分国内互联网公司（字节、美团、快手等）的 PM 日常就是在飞书文档里写 PRD。

推荐理由： 如果你的团队已经在用飞书/钉钉，那就直接在里面写，不要额外引入工具。

Notion

个人项目和小团队的利器。

Notion 的优势是灵活性极高——数据库视图、看板、时间线、嵌入各种第三方内容。你可以在一个 Notion 页面里同时放需求描述、原型链接、开发排期和数据埋点表。

劣势是国内访问速度不稳定，且企业版价格较高。

语雀

阿里系背景，国内访问友好。

语雀的文档编辑体验不错，支持画板、表格、思维导图嵌入。如果你在阿里系公司或者偏好国产工具，语雀是一个稳定的选择。

Confluence

大厂和外企的传统选择。

Confluence 是 Atlassian 全家桶的一部分，和 JIRA 深度集成。在使用 JIRA 做项目管理的团队中，PRD 通常写在 Confluence 里，方便和开发任务双向链接。

缺点是编辑体验比较“古老”，页面加载慢，新人上手需要适应。

Word / Google Docs

传统但有效。

在一些传统行业或非互联网公司，PRD 仍然用 Word 写。Google Docs 则在外企中很常见。格式自由度高，但协作效率不如在线文档平台。

怎么选

简单原则：团队用什么你就用什么。 PRD 工具不是个人选择题，而是团队协作的一部分。如果团队在飞书上办公，你非要用 Notion 写 PRD，那就是在制造信息孤岛。

如果是个人练习或者面试作品集，推荐用 Notion——排版好看、可以生成公开链接、面试官打开就能看。

PRD 写作的 7 个避坑指南

1. 不要写“用户可以……”

“用户可以搜索商品”——这句话什么信息都没有传达。搜索框在哪？支持什么搜索条件？结果怎么排序？没有搜到怎么办？

应该写： 用户在首页顶部点击搜索栏，输入关键词后实时展示搜索建议（最多 10 条），点击搜索或建议项后跳转到搜索结果页，结果按综合排序默认展示，空结果页展示“未找到相关商品”提示及热门推荐。

2. 不要在 PRD 里写技术实现方案

“用 Redis 缓存搜索结果”“用 WebSocket 做实时推送”——这些是开发的决策，不是 PM 应该写的。

应该写： 搜索结果需要在 500ms 内返回（性能要求），消息需要实时送达（功能要求）。把“需要什么”讲清楚，至于“怎么实现”交给开发。

3. 不要忘记异常状态

一个页面至少有四种状态需要覆盖：

• 正常态：有数据正常展示
• 空态：没有数据时展示什么
• 加载态：数据还没加载出来时展示什么
• 错误态：网络错误或接口异常时展示什么

每一种状态都需要在 PRD 里明确描述。

4. 文案要写死，不要留给开发猜

“展示一段提示文字”——开发会问你：什么文字？

应该写： 按钮文案“立即注册”，加载提示“正在验证，请稍候……”，错误提示“网络异常，请检查网络后重试”。

5. 别把 PRD 写成小说

PRD 是工具文档，不是散文。用短句、用列表、用表格，能用一行字说清楚的不要写一段话。没有人愿意读 5000 字的长段落来找一个按钮的交互逻辑。

6. 标注变更记录

需求在评审后经常会有调整。每次修改都应该在文档顶部标注：

变更记录 | 日期 | 修改内容 | 修改人 | |——|———|——–| | 4.16 | 新增验证码发送频率限制（24 小时 10 次） | PM 小李 | | 4.15 | 初版 | PM 小李 |

这样开发在实现过程中看到的永远是最新版本，也能追溯改了什么。

7. 写完自己先“评审”一遍

提交评审之前，把自己当成开发读一遍：如果我是开发，看完这份文档能不能直接开始写代码？有没有哪里看不懂需要再问 PM？ 如果有，那就是你还没写清楚的地方。

一句话总结

好的 PRD 不是写得最长的，而是让团队读完不用再问你第二遍的。 背景讲清楚、范围划清楚、细节写到位、异常全覆盖——做到这四点，你的 PRD 就已经超过 80% 的新人了。

下一篇我们聊聊 PM 日常高频使用的另一类工具——流程图与思维导图。