我们仍在用 10 年前的思维框架，描述10年后的产品形态
“AI产品革命”都快三年了，还没个像样的 PRD 模板出来，实在不像样。
这篇文章，或许可以“救命”：
1. 论述传统产品与 AI 产品的 PRD 有何不同 2. AI 产品尤其是 Agent 产品的 PRD 应该怎么写 3. 一个 4 万+字的 AI 产品 PRD 模板
我在搜索引擎搜索「AI产品 PRD」，结果中除了人人都是产品经理社区的一篇文章外，其他结果要么是怎么用 AI 写 PRD 的、要么是 AI 生成的没有信息量的水稿。
传统产品的 PRD 叙事结构已经不太适配当下热门的 AI 产品了。
新旧 PRD 的叙事差异
传统产品 PRD 的叙事是围绕「人」的需求、「人」的故事、「人」的旅程展开的。
通过论述什么人在什么场景下为达成什么目标所以需要什么功能来完成整个产品设计思路的呈现和要求陈述。
过去是用户-产品这样的二元交互：我们设计好一个产品，用户与产品交互，获取自己想要的结果。
所以我们在设计产品的时候，要考虑用户的种种可能性：
• 用户不点这个按钮的话，有其他选项么？ • 用户会不会在这里输入奇奇怪怪的内容？ • 这个功能是用户想要的东西么，伪需求？ • ……
所以传统产品的 PRD 要先写需求背景，再写用户故事，然后是用户旅程，之后才是功能清单、说明。
「人」是整个产品设计过程中最大的不确定性，一切都围绕把「人」的行为抽象出来。
但是产品引入 AI 大模型后，「人」不再是唯一的不确定性了，整个交互变成了用户-模型-产品三元。
要理解这个新的“三元”，需要对产品进行一下拆解。
目前主流的 AI 产品都是模型嵌入型，即大模型与传统的三方技术相当，作为一个 API 或者功能嵌入进来，跟查天气差不多。
但是，随着模型变得越来越强，交互形态会越来越倾向于“人与模型交互”，然后“模型与「产品」交互全程代理人完成需求”的三元交互形态。
所以，传统 PRD 里花大量笔墨描写的“用户故事”和“用户旅程”可以淡化了，取而代之的应该是“模型故事”和“模型旅程”：
• 模型故事用来描述大模型以 什么角色，在什么场景下，为了完成用户的什么目标，需要调用哪些程序获取上下文；• 模型旅程用来描述大模型在整个任务完成过程中如何 感知、规划、行动和反馈的一系列动作旅程。
整个产品中，不确定因素和所有程序的主要服务对象变成了大模型。
换句话说，对于 Agent 型产品，我们 PRD 的主叙事需要变成“我们如何为模型提供服务，让它能更好的服务用户”。
新 PRD 的结构
嵌入型 AI 产品的 PRD
对于“嵌入型 AI 产品”，它们无非以下两种情况：
1. 老树开新花：原本就可以正常运行的产品，现在把其中的某些环节替换成 AI 大模型来实现，以期有更好的交互体验。典型如“AI客服”类赋能型产品。 2. 久旱逢甘霖：由来已久的需求，传统技术解决不了，现在终于可以用 AI 大模型技术产品化解决了。典型如“AI写作”类创作生成产品。
在这两类产品里，AI 是产品实现逻辑中一个“写死”的环节：它接收一个固定的输入、按要求给出一个预期的输出。
没有感知、没有决策、没有手脚，跟查天气的 API 接口没有任何区别。
这种情况的产品设计中，PRD 完全可以采用传统的叙事逻辑，只需要额外增加三个板块即可：
1. AI引入可行性分析：为什么引入AI（输入弹性or规则弹性）、AI 的可控性论述(规则语言化&上下文可得性&能力边界) 2. 提示词设计逻辑：模型角色、核心挑战、设计策略的可行性分析、完整提示词、输出约束 3. 评估和测试标准：输入输出的可容纳弹性空间、不可控节点、重点关注维度、评估测试数据集要求
关于“AI引入可行性分析”，我一般从输入弹性、规则可语言化水平、示例可得性、输出弹性、重复度、容错空间几个维度拆解。
前两个与 AI 最相关的两个维度，决定了能不能引入 AI，后面 4 个主要用来评估引入价值。
关于“提示词设计”部分，“嵌入型”产品里大模型本质上跟常规通过 API 调用三方工具没啥太大区别，不涉及到模型的“自主性”，相对简单。
这个板块，可以论述一下上下游情景、处理逻辑和模型的不可控风险：
1. 上下游情景，对应到大模型需要的输入（上下文构建）和输出（是否需要结构化、格式） 2. 处理逻辑，即大模型扮演的角色和完成任务的方式 3. 不可控风险，比如模型有可能输出非结构化，或者输出 JSON 是带着```json标识符号
实际上，一个优秀的提示词，本身已经是当前节点的 PRD 了。
提示词贴出来大家也就知道这里在干嘛、有啥风险了，因为相同的信息，你也应该通过提示词告知大模型。
评估和测试标准，在 Agent 类产品的 PRD 模版里有，这先不赘述。
Agent 型产品的 PRD
Agent 型产品才能撑起真正的“AI 产品革命”，它的底层思维是相信大模型可以，即便它有数不清的不确定性。
产品经理的职责就是尽最大可能消灭这些不确定性，释放大模型的能量。
如前所述，我们要像过去梳理人的不确定性一样，从模型需求、模型故事、模型作业流程等维度抽丝剥茧的把所有潜在的问题找出来。
逐个澄清，通过传统技术和一轮一轮的提示词优化，解决它们。
所以，回到 Agent 型产品的 PRD，我建议专门增加三个板块：模型故事、Agent工作流程和 Agent 的提示词设计。
接下来，我以字节开源的 deer-flow 产品为例，反向思考，回到产品立项的起点，用我们以上的框架模拟一下这款产品的 PRD。
Agent 产品 PRD 模版
先说明：
文档是根据 deer-flow 的开源代码反推产品功能和交互，在此基础上推演了产品的目标用户和需求痛点，然后再基于此推演了用户故事和用户旅程，进一步设计了各项功能。
因此，文档并没有涵盖原始产品的所有功能。其中的提示词设计思路也是从功能需求反推的。完整提示词为原始提示词的中文翻译。
如有雷同，请发offer。
文档包含了常规 PRD 的需求背景、产品定位、用户故事，但没搞原型图（毕竟人家产品都发布了，再画原型图实在没意义）。
即便是模拟的 PRD，也有 4 万+字，没法贴在文章里，完整文档的链接在文末。
前面针对为什么要增加新的板块的论述已经比较清楚了，这里就不再赘述了。
简单串一下每一个板块的撰写思路：
• 模型故事板块：描述模型在接收到用户需求后，如何思考、规划、执行和验证的过程。 • Agent 工作流程设计板块：描述单 Agent 执行任务或多 Agent 分工协作的过程，核心是任务目标如何在流程中被执行、各流程节点如何传递数据。使用流程图和时序图呈现： • 流程图是外部视角：理清任务如何一步步被消解掉 • 时序图是内部视角：数据如何传递、如何加工 • 提示词设计板块：围绕系统中的 Agent 设计，每个 Agent 一个/一组提示词，以角色、挑战、策略、提示词和输出控制 5 个板块呈现。 • 评估标准和测试数据集板块：围绕整个流程中所有已经 list 出来的模型不确定性组织物料，规则和测试数据对应每个 Agent 或模型交互节点中潜在的风险。
一些缺陷：
• 模型上下文需求的论述和呈现：任何一个与模型交互的节点，都应该有充足的模型上下文构建策略论述，但是我暂时还没想好把它放在 PRD 文档的哪个板块。我在模型故事板块每个模型故事最后增加了一个“为什么需要这些”，初衷是解释当前模型对 上下文的需求，但它显然应该有更充分的论述和构造策略。• 一个产品从构思到上线过程中一定会遇到大量被卡主的问题，其中大部分是边做、边发现、边迭代的。但是这个 PRD 是从完全体倒推的，绕不开“上帝视角”问题。我在拆解的过程一旦完成了“这个实现太巧妙了”的惊叹，就很难再假装这个问题没有被发现、被解决了，所以文档中有很多“使用 XX 工具处理”这样的表述。 • 这份模拟 PRD 文档更适合作为立项后项目实施推进，立项前的场景引入 AI 可行性分析和引入价值分析没写。
组个局
这么冗长密集的文字，能看到这里，我猜你应该正在创造真正的 AI 产品。
我正在计划组织一个纯 AI 产品的交流群，如果你有以下共识，欢迎建联：
希望一起构建这样的交流氛围
▪ 讨论真正的工程问题（提示词、上下文、工具…），而不是“哪个 AI 可以画原型图”
▪ 大模型能力和边界（幻觉、推理、上下文压缩…），而不是“还是不知道 9.8 和 9.11 谁大啊”
▪ 创新模型交互和体验，而不是“不就是个 AI 浏览器么”或者“炸裂了”
为了确保质量，需要你：
▪ 在做 AI 大模型产品（可以独立开发），而不只是使用、爱好、想学习
▪ 愿意且能够交流、讨论 AI 的应用经验和心得，而不只是围观
▪ 理解大模型的基本原理和独特价值，而不是炸裂或垃圾的二元对立
▪ 不捧杀不贬低，理性的基于工程和真实经验 battle 具体问题
我可以提供：
▪ 每周固定分享一个 AI 项目的拆解
▪ 相对前沿和及时的 AI 行业资讯和产品体验心得
▪ 还算不错的工程经验和提示词功底
▪ 投入一定精力维护这个群
