跳到主要内容
Nodary
免费开始

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

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

下载模板打开在线演示

6 个 Markdown 文件，打包为 .zip，7 kB

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

产品需求文档用户与证据需求设计与流程上线与指标决策与未决问题

下载前先读每一页

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

文档

文件 PRD 模板/产品需求文档.md

产品需求文档

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

一览

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

问题

谁有这个问题、它现在让对方付出了什么、你是怎么知道的。没有证据的问题只是猜测：把调研链接到 用户与证据。

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

[用两三句话写出问题]

目标和非目标

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

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

一行写清成功

上线一个月后，告诉你这件事是否成功的那一个指标。完整清单在 上线与指标。

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

PRD 的其他部分

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

这个模板可以自由使用、修改和分享。它来自 Nodary，在那里这些文件会以互相链接的文档地图形式导入。

下载模板6 个 Markdown 文件，打包为 .zip，7 kB

如何使用

  1. 先写问题，再写方案

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

  2. 让每条必须项都可验证

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

  3. 先评审，再保持准确

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

  4. 记录改了什么、为什么改

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

以地图形式导入 Nodary

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

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

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

Nodary 面向产品与研发团队
Nodary 中的实时看板视图，按状态（草稿、评审中、完成、受阻）分组显示文档，每张卡片带负责人和截止日期；所示示例项目是一款游戏。

写出团队真正会用的 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 的工具会保留文字和表格；请确认它们如何处理文件之间的链接。

延伸阅读

让需求留在团队工作的地方。

把模板导入 Nodary，PRD 就会变成一张由你的团队和 AI 智能体共同保持更新的地图。免费版包含两名成员、一个项目和十个文档，无需绑卡。

免费开始打开在线演示下载模板