很多人把 PRD 理解成一份"需求记录文档"——需求先存在于某个地方，然后被写进文档。这个过程恰恰是反的。需求不是被记录的，是被构造的。用户说"我想要一个搜索功能"，这不是需求，这是一个愿望。PRD 的工作是把这个愿望逐层拆解，直到每一行都变成一个可验证的工程约束。这篇笔记拆解 PRD 的底层逻辑、骨架结构和常见翻车点，最后附上一份可直接使用的模板。
一、PRD 的本质：把模糊性变成可验证的约束
Product Requirements Document，中文习惯叫"产品需求文档"。但"文档"这个词会误导人，让人以为重点是"写"。PRD 的核心职能不是记录，是消除模糊性。
拿"搜索功能"举例。用户提了这三个字，产品经理如果原样写进 PRD，开发拿到后会自行脑补一堆细节：搜哪些字段？精确匹配还是模糊匹配？结果怎么排序？搜不到显示什么？分页还是无限滚动？响应时间要求多少？每个人脑补的方向不一样，做出来的东西必然跟预期有偏差。
PRD 要做的事，就是把"搜索功能"拆成一组明确的约束：
- 搜什么：商品名称、品类标签、SKU 编码三个字段
- 怎么搜：前缀匹配 + 中文分词，支持多关键词 OR 查询
- 怎么排序：相关度权重 70% + 销量权重 30%，降序排列
- 搜不到：展示热门商品推荐，文案"未找到相关结果，为你推荐"
- 性能要求：P99 响应时间 < 300ms，支持 500 QPS 并发
每一行都在收窄模糊性。写完这些，"搜索功能"才从一个愿望变成一个可执行的工程任务。
这里有两个关键词：可验证和约束。不可验证的需求不是需求，是期望；不构成约束的描述不是规格，是建议。"搜索体验要好"无法验收，"P99 < 300ms"可以验收。PRD 里每一句话都应该回答一个问题：这句话能不能被测试？如果不能，它就不该出现在 PRD 里。
二、一份 PRD 的骨架：每个模块都在堵一种漏洞
一份完整的 PRD 不是模板填充练习。每个模块的存在都有具体的工程理由，删掉任何一个，都会在后续环节暴露出对应的问题。
项目概述：给所有人一个对齐的锚点
项目概述回答两个问题：为什么要做？做到什么算成功？听起来像废话，但这恰恰是项目失控的最常见源头——团队跑了两周，才发现每个人对"成功"的定义不一样。业务觉得成功是 GMV 涨 20%，开发觉得成功是功能按时上线，设计觉得成功是交互流畅。
SMART 原则在这里不是管理学教科书里的陈词滥调，而是一个非常具体的工程约束：
- ✗ “提升用户体验”——无法验收，交付时必然扯皮
- ✓ “将结账流程完成率从 45% 提升到 60%”——可直接对应一个埋点指标
北极星指标的意义在于：当需求评审陷入细节争论时，有一个东西能拉所有人回来——"这个改动对北极星指标有没有帮助？"没有这个锚点，需求范围会不可控地膨胀，因为每个看起来"也不错"的功能都有理由被加进来。
需求范围：划边界比列清单更重要
功能清单（模块、功能点、优先级）大家都会写，但真正值钱的是Out of Scope——明确写出不做什么。
需求蔓延（Scope Creep）不是发生在"多做了什么"的时候，而是发生在"没说清楚不做什么"的时候。开发到一半，业务方说"顺便把这个也加上吧"，如果 PRD 没有明确排除，这个请求就会变成一个没有边界的黑洞。Out of Scope 就是提前画好那条线：“V1.0 不做国际化、不做支付分账、不做数据导出”，后面谁要加，走变更流程，走排期，不走顺手。
P0/P1/P2 的分级也不是装饰。它的工程含义是：P0 是 MVP 最小集合，砍掉任何一个产品就不能上线；P1 是首版可缺但不影响核心闭环的功能；P2 是后续迭代。这个分级直接决定了工期不够时砍什么——先砍 P2，再砍 P1，P0 一个都不能动。没有这个分级，"砍需求"就变成一场没有规则的拉锯战。
功能详述：颗粒度是最难的判断
功能详述是 PRD 的核心，也是最容易翻车的地方。翻车有两个极端：写太粗，开发自行脑补细节，结果做出来跟预期不符；写太细，PRD 变成伪代码，维护成本极高，还限制了开发的实现空间。
合理的颗粒度标准是：写到"开发不会做出错误假设"为止，但不写到"替开发做实现决策"的程度。比如"订单金额 = 商品单价 × 数量 - 优惠金额"是业务规则，该写；"用 Redis 缓存商品价格，TTL 设为 30 分钟"是技术方案，不该写。
一个功能模块的完整描述需要覆盖四条线：
| 线索 | 覆盖什么 | 不写会怎样 |
|---|---|---|
| 主流程 | 用户从 A 到 B 的正常路径，每步写清"用户做什么 → 系统响应什么" | 开发只实现理想路径 |
| 分支流程 | 各种 if-then：取消操作、重复提交、条件不满足 | 边界场景没人处理 |
| 异常处理 | 网络断开、权限不足、数据为空、超时 | 线上必炸 |
| 业务规则 | 计算公式、限制条件、状态流转 | 各方对逻辑理解不一致 |
状态流转尤其值得画状态图。口头描述"订单有五个状态，互相之间怎么流转"一定会遗漏边界情况——“已退款"能不能回到"已发货”？"已取消"的订单能不能重新激活？一张状态图把这些全部钉死，比三段文字描述可靠得多。
非功能性需求：项目真正死掉的地方
大多数 PRD 把 80% 的篇幅给了功能需求，非功能性需求一笔带过。但项目真正出事的地方，几乎全在这里。
功能做错了，用户骂两句；性能不达标，系统直接不可用。搜索响应时间从 200ms 退化到 3s，功能上没任何问题，但用户已经流失了。一个促销活动上线，功能全部正常，但并发量扛不住，系统宕机两小时——这种事故每年都在发生。
非功能性需求要写具体数值，不是"响应要快"“系统要稳定”：
| 维度 | 模糊写法（无效） | 量化写法（有效） | 对技术方案的影响 |
|---|---|---|---|
| 性能 | 响应要快 | API P99 < 500ms，1000 QPS | 可能需要缓存层或异步队列 |
| 可用性 | 不能宕机 | SLA 99.9%（月停机 ≤ 43min） | 需要多可用区部署 |
| 兼容性 | 主流浏览器 | Chrome 90+、Safari 14+、不兼容 IE | 前端可用现代 CSS 特性 |
| 安全 | 注意数据安全 | 手机号脱敏存储、支付接口强制 HTTPS、后台二次验证 | 影响存储方案和认证架构 |
这些数字不是随便填的。它们直接影响架构决策。P99 < 500ms 意味着后端不能做全表扫描，需要加索引或缓存；99.9% 的 SLA 意味着单点部署不行，需要多机房容灾。非功能性需求本质上是在约束技术方案选型空间，它和功能需求同等重要。
验收标准：谁定义"完成"，谁掌握主动权
验收标准（Acceptance Criteria）是 PRD 里最容易被敷衍的部分。常见写法是"功能正常使用，无 bug"——这等于没写。
好的验收标准是可测试的断言：
- ✗ “搜索功能正常运行”
- ✓ “用户输入关键词后，300ms 内返回结果列表；结果按相关度降序；每页 20 条；无结果时展示推荐商品；支持翻页至第 10 页”
第二条可以直接转成测试用例。开发自测、QA 验收、上线回归，三方用同一套标准。这就消除了"产品觉得没做完、开发觉得做完了"的扯皮空间。
验收标准还有一个隐性作用：倒逼需求澄清。当你发现某个功能写不出可测试的验收标准时，说明这个需求本身还没想清楚。写不出验收标准的需求，不应该进入开发。
三、PRD 的三个典型翻车场景
翻车一：把解决方案当需求写
用户说"我想要一个下拉筛选器"。产品经理把这句话原样写进 PRD。开发做了下拉筛选器。上线后发现用户要筛选的维度有 30 个，下拉列表长得无法使用。
“下拉筛选器"是解决方案，不是需求。需求是"用户需要按属性快速筛选商品”。解决方案可以是下拉、标签云、搜索式筛选、侧边栏 Faceted Filter——选择哪个取决于筛选维度数量、屏幕空间、用户习惯。PRD 应该描述需求和约束，把方案选择的理由说清楚，而不是直接跳到实现形态。
翻车二：异常路径集体失踪
PRD 只写了 Happy Path（正常路径），开发也只实现了 Happy Path。上线第一天，用户在网络波动下重复提交三次，系统创建了三个重复订单。第二天，有人传了一段超长文本，输入框溢出，布局崩了。第三天，并发下单导致库存超卖。
异常处理不是"锦上添花"，是功能定义的一部分。一个没定义异常处理的功能，等于没定义完整。有几类异常必须覆盖：
- 网络异常：超时、断网、弱网。重复提交要防抖，请求要幂等
- 数据异常：空数据、脏数据、超长文本、特殊字符（XSS）、SQL 注入
- 并发异常：重复提交、同时编辑、库存超卖。靠锁机制或乐观并发控制
- 权限异常：未登录、无权限、Token 过期。要有明确的重定向逻辑
翻车三：需求不可追溯
上线后某个功能出问题，回头查 PRD，发现版本对不上。PRD 改过三轮，没人记录变更。谁也说不清"这个计算逻辑当初为什么这么设计"。
变更日志（Change Log）不是形式主义。每次需求变更，记录三件事：改了什么、为什么改、谁确认的。这不是为了追责，是为了让需求可追溯。半年后有人问"这个优惠叠加规则为什么是取最低折扣而不是叠加计算"，你能查到当时的决策依据，而不是拍脑袋重新定一个。
四、PRD 与研发流程的接口
PRD 不是孤立存在的文档，它在一个更大的流程里有明确的输入和输出。
输入端：用户调研、竞品分析、数据报表、业务方需求。这些原材料经过分析、筛选、优先级排序，变成 PRD 里的"背景与痛点"和"核心目标"。垃圾进，垃圾出——输入质量决定 PRD 质量。
输出端：PRD 经过评审后，被拆解为开发任务（Jira ticket / 飞书项目任务），每个任务对应 PRD 里的一个功能点或验收标准。测试用例从验收标准直接派生——一条验收标准对应一组测试用例。
这个接口意味着 PRD 的颗粒度要和研发流程匹配。PRD 写到功能模块级别，研发拆到任务级别。颗粒度太粗，拆任务的人得自己做产品决策，而他不掌握全部上下文；颗粒度太细，PRD 和任务大量重复，维护两份文档的成本极高。
一个经验法则：PRD 定义"做什么"和"做到什么程度"，不定义"怎么做"。技术架构、数据库设计、接口定义属于"怎么做"，应该在技术设计文档里。PRD 越界进入技术设计领域，是另一个常见的翻车点——产品经理定义了数据库字段，结果和实际查询性能需求冲突，开发不得不推翻重来。
五、写在模板之前
理解了 PRD 的骨架逻辑，再用模板才有意义。模板不是填空题的标准答案，而是一份风险检查清单——它确保你在写 PRD 时没有遗漏该覆盖的风险维度。
一份好的 PRD 不需要九个章节全部写满。两周的小迭代可能只需要项目概述、功能详述、验收标准三块。但不管多精简，三条底线必须守住：
- 目标可量化——"提升体验"不算目标，"完成率从 45% 到 60%"算
- 异常有覆盖——只写 Happy Path 的 PRD 等于没写完
- 验收可测试——写不出测试用例的需求，不该进开发
下面这份 PRD 提示词模板，把上面讨论的所有要素结构化了。拿来用时，根据项目复杂度裁剪。模板的价值不在于格式完整，在于它逼着你在每个环节问自己一个问题：这里还有没有模糊性？如果答案是有，就继续拆。
# 角色设定你是一位拥有10年经验的资深互联网产品经理，擅长将模糊的业务需求转化为结构清晰、可落地的PRD文档。你熟悉敏捷开发流程，善于平衡用户体验、商业目标与技术可行性。 ---# 任务目标请基于我提供的项目信息，生成一份完整、专业的产品需求文档（PRD）。 ---# 输入信息（请用户根据实际情况填写）## 1. 项目基本信息- 产品/项目名称：[填写]- 所属行业/领域：[填写，如电商、SaaS、社交、AI工具等]- 目标用户群体：[填写，如C端消费者、B端企业客户、内部运营人员等]- 项目周期/迭代版本：[填写，如V1.0 MVP、V2.3优化迭代]## 2. 背景与痛点- 当前面临什么问题？（数据/用户反馈/市场机会） - 为什么要做这个项目？ - 不做会有什么后果？## 3. 核心目标（需量化）- 业务目标：[如GMV提升20%、客服人效提升30%]- 用户目标：[如操作步骤从5步减少到2步]- 技术/运营目标：[如系统稳定性达到99.9%]## 4. 功能需求概述- 需要实现哪些核心功能模块？ - 各模块之间的依赖关系？ - 是否有对标/参考产品？## 5. 约束条件- 技术栈/平台限制：[如仅支持微信小程序、需兼容IE11]- 合规要求：[如 GDPR、等保三级、数据本地化]- 资源限制：[如2名前端、1名后端、工期6周]- 特殊限制：[如必须接入现有SSO系统]## 6. 补充材料（如有）- 用户调研报告、竞品分析报告 - 业务流程图草图、原型截图 - 相关数据报表 ---# 输出要求请按以下结构生成PRD，每个部分需详细且具体：## 1. 文档信息- 文档版本号、编写日期、编写人、评审记录## 2. 项目概述- 背景与痛点分析 - 项目目标（SMART原则） - 目标用户画像（含用户故事User Story） - 成功指标（北极星指标+辅助指标）## 3. 需求范围- 功能清单（表格形式：模块、功能点、优先级P0/P1/P2、备注） - 版本规划（MVP → 完整版路线图） - 明确排除范围（Out of Scope）## 4. 功能详述（核心部分）对每个P0/P1功能模块，包含： - **用户场景**：谁在什么情况下使用 - **前置条件**：使用前的状态要求 - **主流程**：正常操作路径（步骤编号+用户动作+系统响应） - **分支流程**：各种if-then场景 - **异常处理**：网络中断、权限不足、数据为空等 - **业务规则**：计算公式、限制条件、状态流转规则 - **界面要求**：关键字段、布局建议、交互说明 - **数据需求**：输入输出、字段定义、校验规则## 5. 非功能性需求- 性能指标（响应时间、并发量、吞吐量） - 兼容性要求（设备、浏览器、操作系统） - 安全与隐私（数据加密、脱敏规则、权限矩阵） - 可用性要求（无障碍设计、多语言、离线模式）## 6. 数据埋点与分析- 需要监控的核心指标 - 埋点事件清单（事件名、触发时机、属性参数） - 数据看板需求## 7. 风险评估与应对- 技术风险、业务风险、合规风险 - 应对预案## 8. 上线与验收- 验收标准（Acceptance Criteria，每条可测试验证） - 上线 checklist - 灰度发布策略 - 回滚方案## 9. 附录- 术语表 - 参考文档链接 - 变更日志 ---# 输出格式要求1. 使用Markdown格式，层级清晰2. 复杂逻辑用表格、流程图（Mermaid语法）、状态图呈现3. 关键决策点用【产品决策】标注，说明"为什么这样设计"4. 不确定或需确认的地方用【待确认】标注5. 语言风格：专业、简洁、无歧义，避免"可能""大概"等模糊词汇
