如何用 AI 撰写产品需求文档（附免费模板）

产品需求文档（PRD）是一份简短、通俗的说明，描述你要做什么、面向谁、必须实现哪些功能，以及你如何判断它是否有效。AI 能大幅加快撰写速度：你提供粗略的笔记，它会把这些内容整理成结构化的章节、用户故事和边界情况。你的任务是提供 AI 无法替你做出的决定——目标、范围以及哪些内容不做——并检查它补充的内容。

本指南涵盖 PRD 应包含的内容、借助任意 AI 助手逐步起草的方法、每个章节的提示词，以及一份可以直接复制的填写模板。

PRD 的作用（以及它不是什么）

PRD 要回答四个问题：

1. 为什么要做这个？要解决什么问题，为了谁？
2. 第一个版本必须做到什么？
3. 第一个版本不做什么？
4. 如何判断它是否成功？

PRD 不是技术设计。它不规定使用哪种数据库或框架——那属于单独的技术规格说明（如果需要的话）。它也不是营销简报或商业计划书。PRD 只聚焦产品的行为，这样才对每位读者都有用：设计师、开发者、负责签字确认的干系人，或是把它转化为代码的 AI 应用构建工具。

谁需要 PRD

• 独立创始人，希望在范围蔓延之前就把它遏制住。
• 小型团队，需要一个能记录“我们已达成的共识”的地方。
• 聘请自由职业者或代理机构的人，因为清晰的 PRD 能让报价更清楚。参见雇佣开发者还是用 AI 构建。
• 用 AI 构建产品的人，因为 PRD 中的用户故事和数据清单比零散的想法清单更适合作为提示词。

AI 擅长什么，又不擅长什么

最常见的失误是把倒数第二行反过来：AI 会自信地用关于你用户的合理猜测来填补空白。对于它写下的任何关于用户、市场规模或用户行为的内容，都应当视为需要核实的问题，而不是既定事实。

第一步：把你已知的内容倒出来

在使用任何提示词之前，先写下粗略的笔记。用要点列出即可，涵盖：

• 问题是什么，用一两句话从用户的角度描述。
• 谁面临这个问题。要具体：“拥有 10–40 位客户的自由记账人”，而不是“小企业”。
• 他们目前怎么解决（用电子表格、邮件，或一个他们不喜欢的工具）。
• 能让第一版算作成功的那一个结果。
• 你已经确定不做的内容。
• 硬性约束：截止日期、预算、必须适配手机、必须与你已在用的某个工具集成。

如果你还没有和遇到这个问题的人聊过，先去做这件事。如何验证应用想法提供了一种实用的方法。基于猜测写成的 PRD，只是一份格式漂亮的猜测。

第二步：让 AI 生成第一版草稿

粘贴你的笔记，并要求它按固定结构生成草稿。以下提示词效果较好：

这是我对某个产品的笔记。请把它们整理成一份产品需求文档，严格使用以下章节：概述、问题、用户、目标与成功指标、范围（纳入 / 不纳入）、带验收标准的用户故事、数据、权限、边界情况、待解决问题。篇幅控制在两页以内。不要编造关于用户或市场的事实——凡是我的笔记中没有说明的内容，请把问题写在“待解决问题”下面。

最后这条指令很关键。要求 AI 把未知内容归入“待解决问题”，而不是自行填补，会得到诚实得多的草稿。

第三步：逐节打磨

按章节逐一检查草稿。以下后续提示词会有所帮助：

问题与用户

用一两句话，从用户的角度重写问题陈述。不要出现解决方案的字眼。

如果问题陈述中提到了你的产品，那它描述的其实是解决方案，而不是问题。

目标与成功指标

为第一版建议三个成功指标，要求是在少量用户的前提下，能在第一个月内衡量。对每个指标说明我将如何衡量。

选择一到两个即可。“二十位记账人在一个月内每周使用一次”是可衡量的。“提高生产力”则不可衡量。

范围

列出本 PRD 中所有可以推迟到后续版本、而不影响核心流程的内容。

AI 工具往往会不断添加功能。这条提示词让它反其道而行之。要狠一点：大多数第一版 PRD 都太大了。什么是 MVP解释了为什么更小的第一版能让你学到更多。

用户故事与验收标准

将每项需求写成用户故事（“作为[用户]，我希望[行为]，以便[结果]”），并用 Given / When / Then 格式写出两到四条验收标准。

验收标准是你之后用来测试的检查清单。“给定某个已预约的时段，当另一位客户查看日历时，则该时段不显示”是可测试的。“预约功能运行良好”则不可测试。

边界情况与权限

对每个用户故事，列出以下情况会发生什么：数据为空、输入无效、网络缓慢或请求失败，以及用户无权访问时。

这正是 AI 发挥作用的地方。它能快速发现人们容易忽略的空状态和权限漏洞。

第四步：像怀疑者一样审查

把整份文档再通读一遍，检查以下内容：

• 每一条关于用户的说法都来自你或研究，而不是来自 AI。
• 范围“不纳入”的部分至少与“纳入”的部分一样长。
• 每个用户故事都有验收标准，且他人无需问你就能测试。
• 数据章节列出了应用保存的每一类记录，以及谁可以查看。
• 待解决问题都有负责人和截止日期。
• 没有混入技术细节，除非它是真正的约束（“必须支持离线使用”是需求；“使用 Redis”不是）。

然后把它发给一位会使用或开发这个产品的人，请对方说说哪里不清楚。对方提出的问题，就是你的漏洞。

可填写的 PRD 模板

将以下内容复制到文档中，并替换方括号中的内容。确实不适用的章节可以删除。

产品名称：[名称] 负责人：[负责决策的人] 状态：[草稿 / 审阅中 / 已确认] — 最后更新：[日期]

1. 概述

[两到三句话：这是什么、面向谁，以及主要成果。]

2. 问题

[从用户角度描述的问题。他们目前怎么做，为什么这样很痛苦。]

3. 用户

4. 目标与成功指标

• 目标：[第一版必须实现的成果]
• 指标：[如何衡量，以及目标值]
• 非目标：[人们可能误以为本版本要做、但其实不做的内容]

5. 范围

第一版包含：

• [功能]
• [功能]

第一版不包含：

• [功能，以及它为何可以推迟]
• [功能，以及它为何可以推迟]

6. 用户故事

**故事 1：**作为[用户]，我希望[行为]，以便[结果]。

• 给定[情境]，当[行为]，则[结果]。
• 给定[情境]，当[行为]，则[结果]。

**故事 2：**作为[用户]，我希望[行为]，以便[结果]。

• 给定[情境]，当[行为]，则[结果]。

7. 数据

8. 权限

[谁可以登录、存在哪些角色，以及每个角色可以查看和修改哪些内容。]

9. 边界情况

• [空状态：还没有数据时显示什么]
• [无效输入：邮箱错误或字段缺失时会发生什么]
• [访问：有人打开了不该打开的页面时会发生什么]

10. 集成与约束

[支付、邮件、现有工具、截止日期、预算、必须适配的设备。]

11. 待解决问题

从 PRD 到提示词

一份好的 PRD 几乎可以直接转化为 AI 应用构建工具的提示词：

• 概述、用户和数据表构成你的第一条提示词。
• 每个用户故事对应一条后续提示词。
• 每条验收标准都是你在预览中要测试的内容。
• **“第一版不包含”**列表，就是你暂时不会去要求的内容。

一次只构建一个故事，并在进入下一个之前检查其验收标准，这比把整份 PRD 粘贴进去、一次性要求所有功能要可靠得多。如何为 AI 应用构建工具撰写提示词对提示词方面有更详细的说明。

常见错误

• 把解决方案写成了问题。“用户需要一个仪表盘”是解决方案。“店主在不打开每张发票的情况下，无法看出哪些发票已逾期”才是问题。
• **没有“范围之外”的部分。**没有它，每次讨论都会重新打开范围问题。
• **让 AI 编造用户。**AI 虚构的用户画像看起来很真实，但其实并不存在。
• **无法衡量的指标。**如果你无法计数，那它就不是指标。
• **从不更新。**一份与你正在构建的产品不再一致的 PRD，比没有更糟。保留“最后更新”日期，并在决策变化时更新它。

在 Mythex 中使用 PRD

如果你在 Mythex 中构建，可以直接把 PRD 粘贴到聊天中。使用 Plan（计划） 模式很适合 PRD：智能体会读取它，提出一个方案和步骤清单，你可以在计划标签页中审阅；只有当你点击 Build（构建） 后，它才会开始修改文件。你还可以把应该始终适用的部分——受众、品牌、规则——保存为项目知识，这样就不必在每次聊天中重复说明。聊天文档介绍了 Build、Plan 和 Ask 三种模式，而模板则是在撰写完整文档之前，快速了解第一版可能是什么样子的好方法。

常见问题