# 产品需求文档（PRD）模板

六份互相链接的文档，带一个功能从问题走到上线：为谁而做、必须做到什么、流程如何、怎样判断它成功了，以及一路上的每个决定。以 Markdown 文件下载：任何编辑器都能打开，在 GitHub 和 Obsidian 里会显示图表，也能以地图形式导入 Nodary。

免费，无需账户，无需邮箱。随意使用、修改和分享。

[下载模板 (.zip)](https://nodary.ai/downloads/prd-muban.zip)

## 下载前先读每一页

概览一屏就能读完，并链接到五个部分：开发、设计和客服各自找到自己的那一页，改动也始终很小。斜体行说明该写什么；示例都围绕同一个示例功能：会过期的分享链接。

- 产品需求文档: 大家最先读的一页：问题、目标、包含什么和不包含什么，以及通往每个部分的链接。
- 用户与证据: 功能为谁而做，他们现在没有它时怎么做，以及问题背后的调研。
- 需求: 功能必须做什么，每条需求都带优先级和证明它的检查。
- 设计与流程: 用户如何走完这个功能：流程、界面、状态和边界情况。
- 上线与指标: 怎样知道它成功了，如何逐步上线，以及什么情况会让你回滚。
- 决策与未决问题: 每个改变了 PRD 的决定、由谁做出、为什么，以及仍未解决的问题。

### 产品需求文档

_使用方法：斜体行是写作提示。用你自己的话替换它们，然后删除。方括号里的值由你填写。让这一页保持在一屏之内：匆忙的读者、新同事或 AI 智能体最先读的就是它。_

#### 一览

| 字段 | 这个功能 |
| --- | --- |
| 功能 | [名称] |
| 一句话 | [上线后用户能做什么] |
| 产品负责人 | [姓名] |
| 技术负责人 | [姓名] |
| 设计负责人 | [姓名] |
| 状态 | [草稿、评审中、已批准、已上线] |
| 目标版本 | [日期或版本] |

#### 问题

_谁有这个问题、它现在让对方付出了什么、你是怎么知道的。没有证据的问题只是猜测：把调研链接到_ [用户与证据](https://nodary.ai/zh/templates/prd#doc-users)。

_示例（一个示例功能）： 有人把文档分享给客户评审，之后就忘了这个链接还在。几个月后它依然能打开。上个季度有三位客户问过，怎样让链接在指定日期失效。_

[用两三句话写出问题]

#### 目标和非目标

_目标写的是用户那边会有什么变化，而不是团队要做什么。非目标是防止范围悄悄扩大的那些决定。_

- 目标：[用户能做到什么，或不再需要做什么]
- 目标：[...]
- 非目标：[这个版本有意不做的事]
- 非目标：[...]

#### 一行写清成功

_上线一个月后，告诉你这件事是否成功的那一个指标。完整清单在_ [上线与指标](https://nodary.ai/zh/templates/prd#doc-launch)。

[指标] 在 [日期] 前从 [基线] 提升到 [目标]。

#### PRD 的其他部分

_每个部分都是独立的文档。链接到它，而不是复制它，这样每个事实只存在一处，也只在一处修改。_

- [用户与证据](https://nodary.ai/zh/templates/prd#doc-users)：功能为谁而做，以及问题背后的调研
- [需求](https://nodary.ai/zh/templates/prd#doc-requirements)：它必须做什么，含优先级和验收标准
- [设计与流程](https://nodary.ai/zh/templates/prd#doc-design)：流程、界面、状态和边界情况
- [上线与指标](https://nodary.ai/zh/templates/prd#doc-launch)：指标、上线和上线检查清单
- [决策与未决问题](https://nodary.ai/zh/templates/prd#doc-decisions)：谁在何时为何做了什么决定，以及还有哪些未决

_这个模板可以自由使用、修改和分享。它来自_ [Nodary](https://nodary.ai/zh)_，在那里这些文件会以互相链接的文档地图形式导入。_

### 用户与证据

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_功能为谁而做，以及你对他们了解多少。这里的每一句话都应该指向它的来源。_

#### 为谁而做

| 谁 | 想做什么 | 被什么挡住 |
| --- | --- | --- |
| [主要用户] | [...] | [...] |
| [次要用户] | [...] | [...] |

_示例（一个示例功能）： 一位客户经理把方案草稿分享给客户，留一周时间收集意见。现在她要设提醒去关掉链接，有时还会忘记。_

#### 现在，没有这个功能时

_用户现在一步步怎么做，包括各种变通办法。变通办法往往就是你能拿到的最好规格。_

1. [步骤]
2. [步骤]
3. [变通办法]

#### 证据

| 来源 | 说了什么 | 日期 | 链接 |
| --- | --- | --- | --- |
| [客户访谈] | [...] | [日期] | [...] |
| [客服工单] | [...] | [...] | [...] |
| [使用数据] | [...] | [...] | [...] |

#### 未决问题

- [ ] [问题]，[谁来回答]，[截止时间]

相关文档： [产品需求文档](https://nodary.ai/zh/templates/prd#doc-overview) · [需求](https://nodary.ai/zh/templates/prd#doc-requirements) · [设计与流程](https://nodary.ai/zh/templates/prd#doc-design)

### 需求

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_每条需求一行，写成用户能做的一件事。优先级分为必须、应该、可以：所有必须项都通过，版本才发布。_

#### 用户故事

| 编号 | 作为 | 我想要 | 以便 | 优先级 |
| --- | --- | --- | --- | --- |
| R1 | [用户] | [...] | [...] | [必须、应该、可以] |
| R2 | [...] | [...] | [...] | [...] |
| R3 | [...] | [...] | [...] | [...] |

_示例（一个示例功能）： R1。作为分享文档的人，我想选择链接失效的日期，以便项目结束时客户失去访问权限。必须。_

#### 验收标准

_为每条必须项写出证明它有效的检查。写到测试人员或 AI 智能体不用问你也能执行。_

| 需求 | 假如 | 当 | 那么 |
| --- | --- | --- | --- |
| R1 | [起始情况] | [一个操作] | [别人能检查的结果] |
| R1 | [...] | [...] | [...] |

#### 非功能需求

| 方面 | 需求 |
| --- | --- |
| 性能 | [...] |
| 安全与隐私 | [...] |
| 无障碍 | [...] |
| 语言 | [...] |
| 兼容性 | [浏览器、设备、版本] |

#### 不在范围内

- [这个版本不做什么，以及原因]
- [...]

#### 未决问题

- [ ] [问题]，[谁来回答]，[截止时间]

相关文档： [用户与证据](https://nodary.ai/zh/templates/prd#doc-users) · [设计与流程](https://nodary.ai/zh/templates/prd#doc-design) · [上线与指标](https://nodary.ai/zh/templates/prd#doc-launch)

### 设计与流程

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_链接设计文件，而不是粘贴进来。这里保留流程和背后的决定，让文字和界面永远不互相矛盾。_

#### 用户流程

_主路径：从用户起步的地方到他得到的结果。团队画不出来，就说明还没定下来。_

```mermaid
flowchart LR
  n0["入口"]
  n1["第一步操作"]
  n2["关键选择"]
  n3["确认"]
  n4["结果"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
```
_主流程：从 [用户从哪里开始] 到 [用户得到什么]_

#### 界面

| 界面 | 用途 | 设计链接 | 状态 |
| --- | --- | --- | --- |
| [界面] | [...] | [...] | [草图、线框、定稿] |
| [界面] | [...] | [...] | [...] |

#### 状态

_每个界面的状态都比顺利路径多。设计好一个就勾掉一个，或者写明它为什么不会发生。_

- [ ] 空状态：暂时没有内容
- [ ] 加载中
- [ ] 出错，以及用户接下来能做什么
- [ ] 没有权限
- [ ] 网络很慢或已断开
- [ ] 超长文本和超大数字

#### 边界情况

| 情况 | 会发生什么 |
| --- | --- |
| [...] | [...] |
| [...] | [...] |

_示例（一个示例功能）： 有人在结束日期过后一分钟打开链接：他看到的是链接已过期以及该找谁，而不是错误页面。_

#### 未决问题

- [ ] [问题]，[谁来回答]，[截止时间]

相关文档： [需求](https://nodary.ai/zh/templates/prd#doc-requirements) · [上线与指标](https://nodary.ai/zh/templates/prd#doc-launch)

### 上线与指标

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_一个主指标，两三个次要指标，再加一个护栏指标：主指标提升时，它不能变差。_

#### 指标

| 指标 | 类型 | 基线 | 目标 | 衡量方式 | 复查日期 |
| --- | --- | --- | --- | --- | --- |
| [...] | [主] | [...] | [...] | [...] | [日期] |
| [...] | [次要] | [...] | [...] | [...] | [...] |
| [...] | [护栏] | [...] | [...] | [...] | [...] |

#### 逐步上线

| 阶段 | 谁能用到 | 日期 | 进入下一阶段的条件 |
| --- | --- | --- | --- |
| [内部] | [团队] | [...] | [...] |
| [测试版] | [...] | [...] | [...] |
| [所有人] | [...] | [...] | [...] |

#### 上线检查清单

- [ ] 帮助文章已写好
- [ ] 客服团队已了解
- [ ] 版本说明已起草
- [ ] 分析事件已检查
- [ ] 回滚已演练

#### 回滚

_什么情况会让你关掉这个功能，以及怎么关。在上线前决定，那时还没有人对结果放不下。_

- 出现以下情况就回滚：[...]
- 方式：[开关、版本、脚本]
- 谁来决定：[姓名]

相关文档： [产品需求文档](https://nodary.ai/zh/templates/prd#doc-overview) · [需求](https://nodary.ai/zh/templates/prd#doc-requirements) · [决策与未决问题](https://nodary.ai/zh/templates/prd#doc-decisions)

### 决策与未决问题

**负责人：** [姓名] · **状态：** 草稿 · **上次审阅：** [日期]

_某个决定改变 PRD 时，在这里加一行，并更新受影响的那一页。日志写原因；页面写现在的事实。_

#### 决策日志

| 日期 | 决定 | 决定人 | 原因 | 修改的页面 |
| --- | --- | --- | --- | --- |
| [日期] | [...] | [...] | [...] | [...] |

_示例（一个示例功能）： 链接一直有效到所有者所在时区最后一天结束，而不是到 UTC 午夜。由产品负责人和技术负责人决定，因为测试期间其他时区的客户提前一天失去了访问权限。修改的页面：需求。_

#### 未决问题

| 问题 | 谁来回答 | 截止时间 | 答案 |
| --- | --- | --- | --- |
| [...] | [姓名] | [日期] | [...] |

相关文档： [产品需求文档](https://nodary.ai/zh/templates/prd#doc-overview) · [需求](https://nodary.ai/zh/templates/prd#doc-requirements) · [上线与指标](https://nodary.ai/zh/templates/prd#doc-launch)

## 如何使用

### 先写问题，再写方案

先和负责实现的工程师、设计师一起填好概览里的问题、目标和非目标。如果你们三人对问题都没有共识，就先停在这里。

### 让每条必须项都可验证

给每条必须实现的需求写上别人也能检查的验收标准。没人能测试的需求只是愿望。

### 先评审，再保持准确

需求就绪后发起评审，有决定改变需求时就更新 PRD。停在启动会那一天的 PRD，到上线时已经是错的。

### 记录改了什么、为什么改

每个决定连同做决定的人一起记入决策日志。有人问这个功能为什么这样工作时，答案就在一个链接之外。

## 以地图形式导入 Nodary

Nodary 是一个为 AI 而生的工作区，团队的文档在这里互相链接，而不是越堆越多。导入 .zip 后，PRD 会带着下面的五个部分一起出现，页面之间的链接保留，图表自动绘制。把它设为评审中，并请工作区或项目的所有者或管理员批准，查看自你上次访问以来的改动，再让通过 MCP 连接的 AI 智能体在写代码之前先读需求。

1. 打开一个项目的地图，点击“导入”。
2. 选择“文件夹或 ZIP”标签页，再点击“选择 ZIP 文件”。
3. 选中下载的文件，检查目录结构，然后导入。

免费版每个工作区可容纳十个文档，项目自己的页面也算在内：模板的六份文档放进新工作区后还能再放三份。Nodary 还内置了一页式的产品规格（PRD）模板。

## 写出团队真正会用的 PRD

PRD 失败有两种方式：它描述了一个没人质疑过的方案，或者启动会之后就不再更新。下面这些习惯能同时避免这两种情况。

### 从问题出发

在任何方案之前，先写清楚谁有这个问题、它让对方付出了什么。对问题有共识的团队，很少为界面争吵。

### 说清楚不做什么

非目标也是决定。把它们写下来，功能才不会一周一周地膨胀。

### 让需求可以验证

“快”和“好用”无法检查。“链接在结束日期后一分钟内无法再打开”可以实现，也可以测试。

### 用必须、应该、可以排优先级

所有必须项都通过，版本才发布。应该和可以，是日期临近时用来取舍的部分。

### 链接证据

每一条关于用户的说法都链接到访谈、工单或数据，让评审的人能去核实，而不是只能相信。

### 让它保持鲜活

决定改变 PRD 时就更新它，并写明原因。最终它描述的应该是上线的东西，而不是第一周的计划。

## 关于 PRD 的问题

### 什么是 PRD？

产品需求文档（product requirements document，PRD）在功能或产品开工之前描述它：要解决什么问题、为谁而做、必须做到什么、如何衡量成功、哪些不在范围内。通常由产品经理负责；工程师、设计师、客服，以及越来越多的 AI 编程智能体都会读它。

### PRD 应该包含什么？

至少包括问题及其证据、目标和非目标、用户、带优先级和验收标准的需求、主要流程和边界情况、成功指标、上线计划，以及决策和未决问题的日志。这个模板为每一组内容准备了一份文档。

### PRD 应该写多长？

长到团队能把功能做出来并测试，而不用把同一个问题问你两遍。概览应该一屏读完；需求随决定增长，而不是随想法增长。

### PRD 和技术设计文档有什么区别？

PRD 说明功能必须做什么、为什么。技术设计文档说明系统怎样做到：架构、数据、接口和风险。先写 PRD，再把两者链接起来。

### AI 智能体能用 PRD 吗？

能。由互相链接的文档组成的 PRD，能给智能体提供它需要的上下文。在 Nodary 中，通过 MCP 连接的智能体，比如 Claude、ChatGPT 或 Cursor，会以你的权限先读需求和决策日志，再动手写。

### 能在 Nodary 之外使用这个模板吗？

能。文件是普通的 Markdown：Obsidian 会把解压后的文件夹当作仓库打开，所有链接都能用；GitHub 会显示文件和图表。逐个文件导入 Markdown 的工具会保留文字和表格；请确认它们如何处理文件之间的链接。

本页地址: https://nodary.ai/zh/templates/prd