AI 产品经理为什么不能只会写 Prompt？

可以先说结论：AI 产品经理当然要会写 Prompt，但如果只会写 Prompt，通常只能完成一次模型调用，还不能证明自己做出了一个可以交给用户的产品。

你花十分钟写好一段 Prompt，模型第一次就给出了漂亮结果。截图发出去，大家都说：“这个 AI 产品不错。”

但当第二个用户换了一种问法，第三次生成出现事实错误，接口突然变慢，或者结果根本无法判断对错时，你会发现：刚才完成的只是一次成功调用，还不是一个稳定的产品。

Prompt 很重要。它决定模型如何理解任务、按照什么格式输出、需要遵守哪些限制。但 AI 产品经理还要继续回答：为什么做、为谁做、什么叫做好，以及模型做不好时怎么办。

Prompt 很重要，但它解决的是局部问题

如果任务只是把一段文字改写得更通顺，或者按照固定格式做一次摘要，一段设计良好的 Prompt 可能已经够用。

可一旦进入真实产品，问题就会变复杂。

用户不会永远按照示例输入；模型不会每次给出完全一致的答案；产品还会受到速度、成本、数据权限、隐私和异常情况的影响。此时，继续修改措辞可能改善结果，却无法替代产品设计。

OpenAI 的 Agent 构建指南把系统的基础组成概括为模型、工具和指令；Anthropic 的工程实践也强调，要根据问题选择最简单的可行方案，并在确实能够改善结果时再增加工作流和系统复杂度。

Prompt 是 AI 产品的重要组件，但不是 AI 产品的全部。

更准确地说：Prompt 管行为，产品管承诺

Prompt 解决的是“模型在这一轮里应该怎么做”。产品需要解决的则是“我们向用户承诺什么结果，以及在什么条件下兑现”。这两件事经常被混在一起。

例如，“根据用户资料生成一份分析报告”是一条模型指令；“用户在十分钟内拿到一份来源可追溯、关键结论可修改、失败后不会丢失进度的报告”才是产品承诺。

这里用乘法而不是加法，是因为任何一项接近零，整体体验都会坍塌：模型很聪明但资料来源错误，不能用；结果准确但等待时间不可接受，也不能用；正常路径很好但失败后覆盖用户数据，仍然不能用。

可以用四层结构检查一个 AI 产品

多数“Prompt Demo”只覆盖第三层的一小部分。AI 产品经理的工作，是把四层连接起来，并对层与层之间的断点负责。

Demo 能运行，为什么还不等于产品成立？

Demo 往往展示的是一条最顺利的路径：输入是准备好的，网络是正常的，模型也恰好给出了理想答案。

真实用户带来的却是大量“没按剧本来”的情况。有人只输入半句话，有人上传错误文件，有人要求系统完成能力范围之外的任务。即使输入完全相同，模型输出也可能发生变化。一次好结果只能说明这次尝试成功，不能说明产品已经可靠。

所以，AI 产品经理不能只问“模型能不能生成”，还要问：

• 什么结果算合格？
• 哪些错误可以接受，哪些错误必须拦截？
• 系统失败以后，是重试、降级，还是交给人工？
• 用户是否知道内容由 AI 生成，能否修改和反馈？

产品的价值，不是让模型偶尔惊艳一次，而是让目标用户在真实场景中稳定地完成任务。

AI 产品经理真正要负责的六件事

一、先判断问题是否值得用 AI 解决

不是所有需求都需要大模型。规则明确、答案固定的任务，传统程序可能更快、更便宜，也更稳定。

AI 更适合处理语言理解、非结构化信息和需要一定判断的任务。产品经理首先要判断：用户真正遇到了什么问题，AI 在其中提供了什么不可替代或明显更好的价值。

二、把用户目标变成一条完整任务链路

用户要的不是“调用一次模型”，而是完成一件事。

例如，用户想生成一份产品分析，完整链路可能包括资料收集、来源核验、信息归类、结论生成、人工修改和最终导出。Prompt 只负责其中某一步，产品经理要设计的是整条流程。

三、提前定义什么叫做得好

“感觉不错”不能成为长期的验收标准。

在开发前就应该准备代表真实场景的测试样例，并明确检查维度：事实是否准确、格式是否完整、关键信息是否遗漏、任务是否完成，以及响应时间和成本能否接受。

没有成功标准，就无法判断换模型、改 Prompt 或调整流程以后，产品究竟变好了还是变差了。

评估不能只有“回答看起来不错”

一个更完整的评估体系至少要分四层。越靠上越接近用户价值，越靠下越适合快速定位问题。

这四层不能互相替代。模型评分提高，不代表用户完成任务更快；用户满意，也不代表产品可以忽略事实错误。产品经理要做的是建立从底层异常到用户结果的因果链，而不是只盯着一个漂亮分数。

四、设计模型出错时的处理方式

AI 产品不会因为 Prompt 写得足够长就不再犯错。

低风险任务可以允许用户重新生成或手动修改；涉及隐私、付款、删除和对外发送等高风险操作，则需要更严格的权限、确认和人工介入。安全边界也不能只写在提示词里，还要落实到产品规则和系统权限中。

先给错误分类，再决定谁来处理

“模型答错了”不是一个足够具体的问题。至少要区分下面几类失败：

• 输入失败：资料缺失、格式错误、用户意图不清。优先通过表单约束、示例和澄清问题处理。
• 知识失败：缺少信息、来源过期或检索错误。需要补充来源、显示证据并允许用户纠正。
• 推理失败：事实都有，但模型得出了错误结论。需要固定测试集、分步检查或人工复核。
• 执行失败：工具调用、权限、网络或外部系统异常。需要幂等、重试、超时和状态恢复。
• 边界失败：系统执行了不应自动执行的高风险动作。需要系统级权限和人工确认，而不是只依赖 Prompt。

分类的意义在于：不同失败需要不同的产品机制。把所有错误都交给“再优化一下 Prompt”，只会让提示词越来越长，却没有真正增加系统的可控性。

五、平衡效果、速度与成本

能力最强的模型未必适合每一个步骤。产品经理需要判断哪些任务需要更强模型，哪些任务可以使用更快、更便宜的方案，是否需要缓存、分步处理或确定性规则。

真正的产品选择，很少只有“效果最好”这一个目标。

六、让真实反馈进入下一轮迭代

上线不是结束，而是第一次接触真实问题。

哪些输入最容易失败？用户在哪一步离开？他们会修改模型的哪些内容？这些记录比团队内部反复猜测更有价值。AI 产品经理要把失败案例沉淀成新的测试样例，再决定是调整 Prompt、补充数据、改变流程，还是缩小产品承诺。

在写 PRD 之前，先写一份“最小产品契约”

传统 PRD 容易先写页面和功能，AI 产品则更适合先冻结一份短小但可验证的产品契约。它不是法律文件，而是团队对产品边界的共同理解。

有了这份契约，团队才知道哪些问题应该改 Prompt，哪些应该改交互、数据、工具、权限或业务承诺。它也让“做完了”从一种感觉，变成可以共同检查的状态。

一个例子：从热门提示词到可检查的工作流

我此前看到 xxd 分享的一段“半照片半手绘”图片提示词：画面上半部分保留真实照片，下半部分把同一个主体重新表现成手绘插画。

如果只是复制提示词，也能生成不错的图片。但重复使用以后，问题很快出现：照片可能被改得不像原图，下半部分容易机械描摹，上下色彩断开，不同图片的构图也不稳定。

于是，我做的不是把原始创意说成自己的，而是对它进行结构化整理和工作流适配，补充了一组可以执行和检查的规则：

• 每张照片单独输出，不做拼图；
• 统一使用 3:4 竖版，上下各占 50%；
• 上半部分尽量保留主体、光影和原有色彩；
• 下半部分提取轮廓、姿态和叙事关系，再进行插画转译；
• 配色从原图提取，保留纸张、水彩和彩铅质感；
• 对人物的脸和手、复杂建筑、品牌标志及图片小字进行人工检查。

它还不是一款完整产品，但已经不再只是一段碰运气的提示词，而是一套规则更明确、可以重复、可以检查的工作流。

这一步的价值，不只是让某一张图更好看，而是让下一个人换一张照片以后，仍然知道系统要做什么、结果要怎么看、哪里需要人工确认。

如果继续把它做成产品，还缺三条闭环

• 输入闭环：上传前检查分辨率、主体清晰度和内容风险；不适合的照片要解释原因，而不是直接生成一个差结果。
• 质量闭环：用建筑、人物、宠物、夜景等固定样例做回归，检查主体保持、上下构图、色彩一致性和文字错误。
• 交付闭环：生成失败可恢复，结果可对比、可重新生成，用户能够保留原图，并知道哪些区域需要人工检查。

到了这里，产品经理关心的已经不只是“怎样画得更像”，而是“怎样让不同用户带着不同照片进来，都能得到可理解、可检查、可继续处理的结果”。这就是从 Prompt 思维切换到产品思维。

从工作流走向产品，还需要什么？

我后来把同样的思路放进公开的 product-manager-workflow 项目：先定义问题和用户场景，再确认成功指标、范围与风险，之后才进入需求、研发协作、上线验证和复盘。

它目前是一套公开工作流，不是成熟的商业软件；但它提醒我，做 AI 产品时最容易跳过的，恰恰是那些看起来不如 Prompt 炫目的工作——边界状态、异常路径、验收标准、发布、回滚和复盘。

这些事情不会出现在一张漂亮的模型截图里，却决定了产品能不能真的交到用户手中。

更难的一步：产品上线以后，如何从 1 走到 N

读到小普rel的文章《做出来已经不值钱了：AI 产品真正的分水岭在 1-N》时，我很认同它提醒的一件事：今天用 AI 做出一个能运行的 Demo 越来越容易，真正稀缺的是上线以后持续理解用户、定位失败并推出第二个版本的能力。

这也让“AI 产品经理不能只会写 Prompt”有了另一层含义：Prompt 不仅不能替代产品设计，也不能替代产品运营。上线不是验收结束，而是第一次拿到真实分布。

测试阶段面对的是团队准备好的样例，线上面对的却是用户自己的语言、资料和目标。用户意图会变化，知识会更新，模型供应商也可能调整底层行为。因此，产品上线前画出的能力边界不会永久稳定，它需要被持续观察和校准。

上线后的核心不是“多改几次”，而是建立三个闭环

这三个闭环不是上线以后才临时补的功能。对话留存边界、反馈字段、版本记录和回归集结构，需要在 0–1 阶段就设计好。否则最早、也往往最有价值的一批真实案例会变成无法分析的聊天记录。

Case 闭环：不要只等用户点“踩”

显式评价当然有价值，但很多不满意不会变成一条反馈。用户更常见的动作，是换一种说法重新提问、不断补充限制、提前退出、手动大幅改写结果，或者干脆不采用。

因此，AI 产品的行为数据不能只记录按钮点击，还应该在合法、透明并保护隐私的前提下，关注与任务结果有关的信号：

• 同一会话中，用户是否围绕同一目标反复提问；
• 生成结果是否被复制、保存、导出或继续编辑；
• 任务在哪个步骤被放弃，放弃前发生了什么；
• 模型结果被人工修改了哪些部分；
• 系统是否频繁触发重试、降级或人工接管。

接下来不能只是把这些内容堆进表格。每个代表性失败都要完成一次转化：记录原始输入，标注失败原因，写出期望行为和通过标准，再进入回归集。只有做到这一步，用户反馈才从“素材”变成可以反复使用的产品资产。

迭代闭环：先判断改哪一层，再动 Prompt

看到一条差评就往 Prompt 里加一句规则，是最容易发生的“伪迭代”。时间久了，提示词会变成谁也不敢删除的补丁集合：每一条都有历史原因，却没人知道它对整体结果还有什么影响。

更稳妥的方式，是先回答两个问题：

1. 这是孤立案例，还是已经形成稳定的一类失败？孤例先进入案例库观察；成类后再确定优先级。
2. 模型知道怎么做，只是没有按要求表达；还是它缺少完成任务所需的信息与能力？前者可能改 Prompt，后者通常要改检索、工具、流程或人工节点。

每次修改都应该带着三项记录：为什么改、改了哪一层、回归结果如何。Prompt、工作流和模型配置也要有明确版本。这样当新版本出现退化时，团队才能找到变化来源，而不是靠记忆猜测。

模型闭环：产品没改，行为也可能发生变化

AI 产品依赖的模型、检索服务和外部工具都可能更新。即使团队没有发布新代码，产品的实际行为也不一定永远相同。

因此，回归评估不应只在改 Prompt 时运行，还要定期在固定样本上执行。出现新模型时，也不能只看通用排行榜，而要用自己的场景样本比较：关键任务是否变好、旧能力是否退化、延迟与成本是否可接受。

更换模型至少需要四个步骤：离线对比、少量灰度、用户指标观察和可验证的回滚。一个没有真正演练过的回滚按钮，在风险发生时不一定能发挥作用。

真正难复制的，不是 Prompt，而是反馈环

Prompt、界面、模型选择和公开工作流都可能被快速模仿。更难复制的是长期积累的场景案例、失败分类、评测样本，以及从发现问题到完成验证的迭代机制。

这不是因为别人永远拿不到同样的技术，而是因为场景数据和团队判断需要时间形成。一个小团队未必拥有最强的通用模型，却可能在一个足够具体的场景里拥有更短的反馈路径。

0–1 证明你能把想法做出来；1–N 证明你能从真实世界里继续学习。

想转型 AI 产品经理，可以从一个小项目开始

新手不必一开始就做复杂 Agent。选择一个具体的小问题，走完下面这条链路，比堆很多概念更有价值：

1. 找到一个真实用户反复遇到的问题；
2. 说明为什么使用 AI，而不是普通规则；
3. 明确输入、输出和完成标准；
4. 做出只解决核心问题的最小版本；
5. 准备一组固定测试样例；
6. 设计失败、超时和高风险情况的处理方式；
7. 让真实用户使用，并记录失败案例；
8. 完成一次公开上线，再把过程整理成作品集。

作品集真正有说服力的部分，不是你用了多少新名词，而是你如何做出判断、处理失败，并把一个想法推到可验证的结果。

项目复盘时，至少能回答这十个问题

1. 目标用户原来如何完成这件事，真正的摩擦在哪里？
2. 为什么这里应该用 AI，而不是规则、搜索或普通表单？
3. 你向用户承诺的结果是什么，不承诺什么？
4. Prompt 在流程中负责哪一步，其他步骤由什么机制负责？
5. 你用哪些真实样例定义了成功与失败？
6. 最常见的三类错误是什么，各自如何恢复？
7. 哪些动作允许自动完成，哪些必须由用户确认？
8. 质量、速度和成本之间做过什么取舍？
9. 上线以后收集了哪些反馈，如何进入下一轮测试？
10. 如果换一个模型，产品的哪些能力仍然成立？

最后一个问题尤其重要。一个产品如果全部价值都绑定在某个模型的一次惊艳输出上，它更像能力演示；当用户价值、流程和评估体系能够独立存在时，产品才拥有持续迭代的基础。

结语

会写 Prompt，像学会了第一组和弦；真正做产品，是把它写成一首能够排练、能够演出，出了状况也能继续完成的歌。

所以，AI 产品经理需要追求的，不是“我能让模型说出一句漂亮的话”，而是：我能让用户借助 AI，可靠地完成一件原来很难完成的事。

我是浪人李白，一个爱听摇滚的 AI 产品经理。我会继续分享 AI 产品实践、独立开发，以及从想法走到上线的真实过程。

你现在正在做的，究竟是一段 Prompt、一套工作流，还是一个能够交给用户的产品？