PRD（Product Requirements Document，产品需求文档）是软件行业里描述"要做什么"的文档。传统上它由产品经理写，需要专业训练。
现在的情况变了：AI 可以生成 PRD，你只需要审阅。但审阅同样需要方法。
PRD 解决什么问题
一句话：把"大家以为我们要做什么"变成"白纸黑字的我们要做什么"。
它的价值在后期显现：
| 场景 | 没有 PRD | 有 PRD |
|---|---|---|
| 开发中发现理解不一致 | 互相指责 | 查文档 |
| 验收时争议 | 各执一词 | 按文档验收 |
| 需求变更 | 说不清是不是变更 | 有基准可对照 |
| 后期加功能 | 不知道原来怎么设计的 | 有据可循 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
PRD 最重要的作用不是"指导开发"，而是提供基准。有了基准，"这是不是需求变更""这是不是 bug"就有了客观判断依据。
AI 生成的 PRD 长什么样
通常包含这些章节：
| 章节 | 内容 | 你要不要看 |
|---|---|---|
| 背景与目标 | 为什么要做这个 | 看一眼 |
| 用户与角色 | 谁用、什么权限 | 重点看 |
| 功能清单 | 逐条列出功能 | 重点看 |
| 字段定义 | 数据表与字段 | 重点看 |
| 业务流程 | 状态流转图 | 重点看 |
| 页面结构 | 有哪些页面 | 看 |
| 非功能要求 | 性能、安全、兼容性 | 可跳过 |
| 技术选型 | 用什么技术实现 | 无技术背景可跳过 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
真正需要你认真看的是中间四项：角色权限、功能清单、字段定义、业务流程。
重点审阅一：功能清单
看什么：
- 有没有遗漏你明确提过的功能
- 有没有多出你没要求的功能（可能是通用模板带进来的）
- 每条功能的描述是否具体到可以验收
一条合格的功能描述应该是：
“"报价单支持导出 PDF，包含公司抬头、客户名称、产品明细、税率、有效期、业务员联系方式。"”
而不是：
“"支持导出功能。"”
后者无法验收——什么样的导出算完成？
重点审阅二：字段定义
这是最容易出错、也最少被认真看的部分。
示例：
| 字段名 | 类型 | 说明 |
|---|---|---|
| customer_status | 枚举 | 取值：new / quoted / sampling / won / lost |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
你要检查的是：
- 字段名对应的业务含义对不对
- 取值是否覆盖了你业务里的所有情况
- 有没有多出或用不到的字段
- 必填/选填设置是否合理
一个真实的高频错误：方案里把"客户状态"定义为"潜在客户/意向客户/成交客户"，而你的业务实际是"新询盘/已报价/打样中/成交/关闭"。如果不在此刻纠正，系统里的状态和你的实际流程对不上，用起来会非常别扭。
重点审阅三：业务流程
看状态流转图（或描述）：
```
新询盘 → 已报价 → 打样中 → 谈判中 → 已成交
↓
已关闭
```
检查三件事：
- 每个状态是否对应你真实的业务阶段
- 流转方向是否正确（有没有走不通的路径）
- 异常出口是否存在（能不能取消、能不能退回上一状态）
第三点最常被遗漏：没有异常出口的流程图，意味着异常情况无法在系统中处理。
重点审阅四：角色与权限
| 角色 | 权限 |
|---|---|
| 业务员 | 查看和编辑自己的客户 |
| 主管 | 查看全部，可审批折扣 |
| 管理员 | 全部权限 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
检查：
- 角色划分是否符合你们的组织架构
- 权限是否过宽（如所有人都能看成本价）
- 是否有需要协作的场景（如多人跟进一个大客户）
四个文档陷阱
陷阱一：看起来很全，但都是套话
"系统应具备良好的用户体验" "支持灵活的权限配置"——这类表述无法验收。看到就要求改具体。
陷阱二：功能很多，但都不是你要的
AI 有时会堆砌通用功能（如"支持数据看板""支持消息通知"）。这些不是坏事，但如果它们挤占了你真正需要的功能的注意力，就要警惕。
判断标准：对照你最初提的需求，逐条打勾。你没提过的功能，问一句"这个是必需的吗"。
陷阱三：字段全是通用的
如果字段表里全是"name、status、created_at"这类通用字段，而没有你业务特有的字段（如"电镀工艺""模具编号""认证类型"），说明方案没有真正理解你的业务。
陷阱四：没有边界说明
一份好的方案应该写明"本系统不包含什么"。没有边界说明的方案，后期容易产生"我以为包含这个"的争议。
审阅 PRD 时最有用的一个问题："照这个文档做出来，我的某个具体业务场景能跑通吗？" 挑一个你最熟悉的真实场景，在脑子里走一遍。走不通，就说明文档有问题。
确认之后：PRD 就是验收标准
方案确认后，PRD 应该被当作验收依据保管好。后期验收时逐条对照：
| PRD 中的功能 | 是否实现 | 是否符合描述 |
|---|---|---|
| 报价单导出 PDF | ✓ | ✓ |
| 客户状态流转 | ✓ | 缺少"已关闭"状态 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
这样做验收，比凭感觉判断"好不好用"要可靠得多。
AI 生成的需求文档，我需要逐字审吗？+
强烈建议看，尤其是字段定义和业务流程这两部分。这两处出错，系统做出来会与你的实际业务对不上，而返工成本很高。不需要看的是技术选型和非功能要求（性能、安全等），这些通常由技术方负责。一个折中做法：让对方把字段定义和流程用业务语言讲一遍，你确认理解一致即可，不必自己读完整份文档。
PRD 需要写多详细？+
够验收就行。判断标准是：拿着文档，能否判断"这个功能做完了没有"。太粗（"支持订单管理"）无法验收；太细（每个按钮的位置）会拖慢进度且容易过时。对中小企业项目，一份 10–30 页、包含功能清单、字段定义、流程图的文档通常够用。真正重要的是"可验证"，而不是页数的多少。
签了 PRD 之后还能改吗？+
能改，但要走变更流程。这正是 PRD 的价值所在——它提供了判断"这是不是变更"的基准。在文档范围内的调整不算变更，超出范围的算。因此建议在开始时就预留一些弹性：把"必须要的"和"最好有的"分开标注，前者写进文档，后者作为二期。这样既保证了范围可控，也保留了调整空间。
本文 PRD 审阅方法适用于 AI 生成与人工编写的各类需求文档。