产品需求文档

PRD (Product Requirements Document)

也常被叫作：需求文档需求说明PRD产品说明

产品与需求通常止于「主路径」约 1 分钟读完

你可能会这么说

「把「要做成什么样」写成一份谁都能看懂的文档，AI 照着做不跑偏。」

产品需求文档 PRD (Product Requirements Document)

把给谁解决什么问题、页面长什么样、流程怎么走、边界在哪，写成一份 AI 照着做不会跑偏的文档。

PRD 就是把需求从「脑子里的话」变成「白纸黑字的约定」：给谁解决什么问题、页面有哪些、每条流程怎么走、字段是什么、这版不做什么。它不要求写得像正式合同，但要求写到「换一个人，或者换一个 AI，照着做不会做出另一个东西」。

对用 AI 做事的人来说，PRD 最大的价值是当裁判。AI 做完你说「这不是我要的」，它说「我就是按你说的做的」——这时候只有白纸黑字的文档能仲裁。没写清的地方，就是你们吵架的地方；写清了，就没有争议。所以 PRD 的关键不是长度，是每一条都具体到能验证：什么情况、做什么、看到什么。

别把 PRD 想成要花一整天写的正式文件。小项目三五百字就够：一段话说给谁、解决什么；一个清单列页面和功能；一段写流程；一段写「这版不做」。真正要花心思的是「不做什么」那部分——你和 AI 都倾向于往里加东西，边界就是挡这个的墙。

长什么样真实可交互，不是截图

一份 PRD 该有的四块

1 给谁、解决什么问题

2 页面与功能清单

3 关键流程：入口 → 动作 → 结果

4 这版明确不做什么

第四块最容易被跳过，也最值钱——没有边界，AI 会顺手把登录、后台、排行榜都加进来。

拆开看，里面有这几块

1
背景与目标 Background
给谁解决什么问题，为什么现在做。一两段话就够。
2
范围清单 Scope
这版要做的页面和功能，一条一条列，别写形容词。
3
流程 Flows
关键路径怎么走：入口、步骤、结果、出错怎么办。
4
字段与规则 Details
表单有哪些字段、什么格式、什么不能为空。涉及数据时别省。
5
边界 Non-goals
这版明确不做什么。防范围蔓延的墙。

常见的有哪几种

一句话 PRDOne-pager

一段目标 + 一个功能清单 + 一段边界。

用在：小改动、个人项目

标准 PRDStandard

目标、范围、流程、字段、边界五块齐全。

用在：要外包、要多轮迭代

验收式 PRDAC-backed

每个功能都配几条验收标准。

用在：给 AI 做，验收标准是它的紧箍咒

容易搞混？这样区分

产品需求文档 ≠ 用户故事 User Story

用户故事是一句话方向（给谁、为什么）；PRD 是完整规格（页面、字段、流程、边界）。先有故事定方向，再展开成 PRD 定细节。

看用户故事

产品需求文档 ≠ 验收标准 Acceptance Criteria

PRD 说「要做什么」，验收标准说「怎么算做成了」。PRD 里每个功能配几条验收标准，是最好的组合。

看验收标准

产品需求文档 ≠ 项目计划 Project Plan

PRD 是「做什么」；项目计划是「谁、什么时候做完」。文档写得再好，也替代不了排期和检查。

什么时候用得上

给 AI 派大活

写完 PRD 再让它动手，比来回对话十轮省时间，也省得它自由发挥。

两个人对需求吵架

回到 PRD 找原文，文档里没有的条文不算数。

改需求时

改的是 PRD 本身，别只在对话里口头改。一版一版存好，才能看出范围是怎么变的。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

【范围】这是一份需求文档，请按它实现，不要超出文档内容
【目标】给［谁］解决［什么问题］。本版包含：
  - 页面：［页面清单，每个页面一句话说明核心内容］
  - 功能：［功能清单，一条一个，尽量具体］
  - 流程：［核心流程第几步做什么］
  - 字段/规则：［必填项、格式、限制］
【边界】本版明确不做：［登录/后台/排行榜/多语言…］。文档没写的功能不要自己加；拿不准的先问我
【交付】实现前先发我一份「你的理解」：用几句话复述这份文档的范围和边界，我确认后你再动手；做完给我：改了哪些文件、我打开哪一步能看到每个功能、文档里哪些条目你没实现或改了实现方式（逐条说明，没验证的写「未验证」）

最值钱的两句是「实现前先复述范围」和「文档没写的功能不要自己加」：前者让 AI 动手前先证明它读懂了，后者直接堵住它顺手加功能的习惯。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「主路径」这层：真实用户的正常操作能走通，不靠特殊参数。

要亲眼看到这些，才算数

找一个不了解这项目的人读一遍，他能说出「给谁、做什么、不做什么」三件事吗？
每个功能条目都能对上一个可操作的结果（点了什么、看到什么），而不是形容词。
「不做」清单存在，且和你心里的真实意图一致。
让 AI 按文档实现后，逐条对照：文档写的都做了吗？文档没写的出现了吗？
改过需求吗？如果改过，PRD 有没有跟着改，还是已经和现状对不上了。

它常这么糊弄你

「PRD 已写完」——但通篇是「体验要好、功能强大」。要求每一条都能被验证，形容词不算。
「按 PRD 实现完毕」——但他加了你文档里没有的登录页。加功能必须先问你，文档是裁判。
「这个需求文档和聊天里说的一样」——以文档为准，聊天记录不算。让他按文档逐条对。
边界写在「以后再说」——但 AI 把「以后再说」当成「现在顺手做了」。明确写「本版不做」。

PRD 本身只是文字，停在「概念」层；它的真实质量要到实现后对照才暴露，所以这里按「主路径」要求：真人能按文档走通、文档外没有多余的东西。想更严谨，就升级成验收式 PRD 逐条勾。

考考你选一个你觉得对的

一份 300 字的 PRD 和一份 3000 字的 PRD，差别主要在哪？

想再深挖一点靠谱出处

Product requirements document（产品需求文档）Wikipedia ↗How to write product requirements（Atlassian）Atlassian ↗

# 产品需求文档 (PRD (Product Requirements Document))

> 把给谁解决什么问题、页面长什么样、流程怎么走、边界在哪，写成一份 AI 照着做不会跑偏的文档。

**你可能会这么说**：把「要做成什么样」写成一份谁都能看懂的文档，AI 照着做不跑偏。

PRD 就是把需求从「脑子里的话」变成「白纸黑字的约定」：给谁解决什么问题、页面有哪些、每条流程怎么走、字段是什么、这版不做什么。它不要求写得像正式合同，但要求写到「换一个人，或者换一个 AI，照着做不会做出另一个东西」。 对用 AI 做事的人来说，PRD 最大的价值是当裁判。AI 做完你说「这不是我要的」，它说「我就是按你说的做的」——这时候只有白纸黑字的文档能仲裁。没写清的地方，就是你们吵架的地方；写清了，就没有争议。所以 PRD 的关键不是长度，是每一条都具体到能验证：什么情况、做什么、看到什么。 别把 PRD 想成要花一整天写的正式文件。小项目三五百字就够：一段话说给谁、解决什么；一个清单列页面和功能；一段写流程；一段写「这版不做」。真正要花心思的是「不做什么」那部分——你和 AI 都倾向于往里加东西，边界就是挡这个的墙。

**也叫**：需求文档、需求说明、PRD、产品说明

## 你可以这样告诉 AI

```text
【范围】这是一份需求文档，请按它实现，不要超出文档内容
【目标】给［谁］解决［什么问题］。本版包含：
  - 页面：［页面清单，每个页面一句话说明核心内容］
  - 功能：［功能清单，一条一个，尽量具体］
  - 流程：［核心流程第几步做什么］
  - 字段/规则：［必填项、格式、限制］
【边界】本版明确不做：［登录/后台/排行榜/多语言…］。文档没写的功能不要自己加；拿不准的先问我
【交付】实现前先发我一份「你的理解」：用几句话复述这份文档的范围和边界，我确认后你再动手；做完给我：改了哪些文件、我打开哪一步能看到每个功能、文档里哪些条目你没实现或改了实现方式（逐条说明，没验证的写「未验证」）
```

## 怎么验证他真的做到了

通常止于层级：**主路径** — 真实用户的正常操作能走通，不靠特殊参数

- [ ] 找一个不了解这项目的人读一遍，他能说出「给谁、做什么、不做什么」三件事吗？
- [ ] 每个功能条目都能对上一个可操作的结果（点了什么、看到什么），而不是形容词。
- [ ] 「不做」清单存在，且和你心里的真实意图一致。
- [ ] 让 AI 按文档实现后，逐条对照：文档写的都做了吗？文档没写的出现了吗？
- [ ] 改过需求吗？如果改过，PRD 有没有跟着改，还是已经和现状对不上了。

常见糊弄：
- 「PRD 已写完」——但通篇是「体验要好、功能强大」。要求每一条都能被验证，形容词不算。
- 「按 PRD 实现完毕」——但他加了你文档里没有的登录页。加功能必须先问你，文档是裁判。
- 「这个需求文档和聊天里说的一样」——以文档为准，聊天记录不算。让他按文档逐条对。
- 边界写在「以后再说」——但 AI 把「以后再说」当成「现在顺手做了」。明确写「本版不做」。

来源：https://mickerbook.com/reference/t/prd/