导读：AI时代产品经理的职责不是传统职责的简单叠加，而是范式转移。本文从能力边界设计、Prompt工程、实验管理、数据飞轮、人机协作五个维度，拆解AI产品经理岗位职责的具体变化，帮你理解老手艺如何在新战场上重新开张。

上个月，一个认识了挺久的产品哥们跟我吐槽。

他在传统互联网公司干了五年，从助理做到高级产品经理，履历光鲜，项目也拿得出手。去年他觉得AI是趋势，业余时间啃了几篇论文，玩了玩ChatGPT，还自己捣鼓了一个用AI整理读书笔记的小工具。年底跳槽去了一家做AI应用的公司，title还是产品经理，薪资涨了40%。

面试的时候，他跟CTO聊大模型、聊RAG、聊Agent，聊得挺开心。CTO说，你对AI的理解在业务产品里够用了，进来吧。

听起来挺完美对吧。

结果入职第一周，他就懵了。不是因为不懂AI，而是因为懂AI，跟懂AI产品经理要怎么干活，完全是两码事。

第一天，他习惯性地打开Figma准备画原型。设计师看了一眼说，这页面不用画太细，就是一个输入框加一个大面积的内容展示区。他愣了，问他，那我产品细节体现在哪？设计师说，在Prompt里。

第二天，他写了一份特别详细的PRD，功能逻辑、异常处理、状态流转，应有尽有。leader看完说，功能逻辑写得不错，但Prompt部分你再细化一下，还有评估集也得补。他才发现，在AI团队里，PRD的核心不是功能逻辑，是Prompt怎么写、怎么测、怎么评估好坏。

第三天，他按以前的习惯组织了一场需求评审，说要开发一个智能推荐功能。算法工程师听完说，这个需求我们先跑个实验对比一下，RAG方案和微调方案哪个效果更好，下周给你数据。他当场有点恍惚，因为在他的经验里，需求评审的结果要么是「做」，要么是「不做」。这里怎么变成了「先试试」？

他跟我说，那一刻他感觉自己过去五年积累的那套工作方法，在这个岗位上好像突然失效了。

我跟他说，不是失效了，是游戏规则变了。

一

传统互联网产品经理的职责，基本可以被框进一个标准公式里。

收集需求，分析优先级，画原型，写PRD，跟进开发，验收上线，看数据，做迭代。这个循环跑顺了，就是一个合格的产品经理。

这个公式的底层假设是，产品是确定的。你知道你要做什么，你知道开发能做出来，你知道上线后用户会怎么用。你的核心能力，是在这个确定性系统里做最优决策。

但AI产品，从一开始就是不确定的。

你不知道模型会怎么理解用户的输入，你不知道同样的Prompt跑十次会不会得到十个不同的结果，你不知道上线后用户会用什么样的奇葩方式把你的产品玩坏。

所以AI时代的产品经理，职责不是在那个标准公式里做得更精致，而是要重新写一个公式。

二

第一个变化，从「设计功能」变成了「设计能力边界」。

传统产品经理画原型图，每一个按钮、每一个页面、每一次跳转，都是精确设计的。用户体验的每一处细节，都掌控在产品经理手里。

AI产品经理面对的是一块橡皮泥。

模型能力是弹性的，你可以让它很保守，也可以让它很开放。保守意味着安全但无聊，开放意味着有趣但危险。你的职责不是设计一个确定的功能，而是划定一条边界，让模型在这条边界内自由发挥，同时确保它不会越界伤害用户。

这就像一个游乐园的设计师。传统产品经理设计的是过山车，轨道固定，用户上去就知道会发生什么。AI产品经理设计的是整个游乐园的围栏和安全规则，里面的设施是活的，会自己变化，你要确保无论它们怎么变，都不会伤到游客。

这个职责的变化，要求你拥有一种以前不太需要的能力，叫「风险预判」。

不是预判用户会不会喜欢某个功能，是预判模型在什么情况下会犯错、犯什么错、错的后果有多严重。然后提前设计好防护机制。

三

第二个变化，从「写需求文档」变成了「设计Prompt和评估体系」。

传统产品经理的PRD，是写给开发看的。里面写清楚这个功能要什么、不要什么、逻辑是什么、异常怎么处理。开发看完PRD，就知道怎么写代码了。

AI产品里，PRD的概念在瓦解。

你写的不是需求文档，你给模型写的是「指令」，也就是Prompt。但Prompt不是写一次就完事的，它需要不断调优。今天这个Prompt在这个场景下表现很好，明天换了一批用户，可能就不行了。

更关键的是，你怎么知道Prompt好不好？

传统产品的好坏有明确指标，转化率提升了、留存率下降了、点击率多少，数字说话。

AI产品的好坏，很多时候没有单一指标。模型的回答「好」还是「不好」，是一个主观判断。你需要设计一套评估体系，定义什么叫「好回答」，然后批量测试，看模型在多大程度上满足了这个定义。

这意味着AI产品经理的工作中，多了一块以前很少做的事，叫「建测试集」。

你要收集几百几千个真实场景的问题，标注出理想答案，然后让模型去跑，看能打多少分。这个测试集不是一次性的，要持续维护、持续扩充。

本质上，你是在给模型出考卷，而且要不停地出新考卷。

四

第三个变化，从「项目管理」变成了「实验管理」。

传统产品的开发流程是线性的。这个版本做ABC三个功能，排好优先级，定好 deadline，开发一个一个做，测试一个一个验，到点上线。

AI产品的开发流程是网状的。

同一个功能，可能有五种不同的技术方案。用RAG还是微调？用哪个基座模型？temperature设多少？要不要加system prompt？这些不是拍脑袋决定的，是要跑实验的。

跑一轮实验，发现方案A准确率高但速度慢，方案B速度快但偶尔会胡说。怎么选？没有标准答案，要看业务场景更在意什么。

产品经理的职责，不是排期推进，而是设计实验、分析结果、做 trade-off 决策。

这要求你对技术有比以前更深的理解。不是要你写代码，但你要能听懂算法工程师说的每个参数是什么意思，你要能判断某个实验结果是不是真的可信，你要能在信息不完备的情况下选一个「当前最优」的方案。

以前项目经理也能做的事，现在只有产品经理能做。因为决策的复杂度上去了，不再是「做不做」的问题，而是「怎么做更好」的问题。

五

第四个变化，从「数据分析」变成了「数据飞轮设计」。

传统产品上线后，产品经理看数据，用户点了多少、看了多久、流失在哪一步。然后根据数据结论，规划下一个版本的优化方向。

这里的数据，是「反馈」。产品发出去了，用户用了，产生行为数据，你拿回来分析。

AI产品里，数据不仅是反馈，还是「燃料」。

模型表现不好，原因往往是训练数据不够、不够多样、不够贴近真实场景。用户每一次使用，都是在帮你生产新的训练素材。用户的每一次纠错，都是在帮你标注数据。

AI产品经理要设计的，不是看数据的仪表盘，而是让数据自动流回模型、让模型自动变好的机制。

这叫数据飞轮。

具体来说，你要设计一套机制，把用户的高价值交互自动筛选出来，清洗，标注，然后定期回流到训练流程里。你还要设计激励机制，让用户愿意花时间给你反馈，愿意纠正模型的错误。

这完全不是传统数据分析的范畴了。这是在设计一个自我进化的系统。

六

第五个变化，从「用户体验设计」变成了「人机协作体验设计」。

这是最本质的变化。

传统产品，用户和界面交互。界面是你设计的，用户是被动的，你提供什么，用户就用什么。

AI产品，用户和模型协作。模型不是被动响应，它有自己的「想法」（虽然这个想法是概率生成的）。用户和模型之间，是一种双向的、动态的关系。

产品经理要设计的，不再是「用户怎么用这个产品」，而是「用户怎么和这个产品一起完成一件事」。

这个差别太大了。

举个例子。你设计一个AI写作助手。传统思路是，用户点「生成大纲」，AI给一个大纲，用户点「生成正文」，AI给正文。每一步都是用户发起，AI响应。

协作思路是，用户写了一段开头，AI主动说，我注意到你这里埋了一个伏笔，需要我在后面帮你收回来吗？或者，用户写到一半卡住了，AI不是说「我来帮你写」，而是说「你好像在想怎么过渡，我有几个思路，你要不要听听？」

前者是工具，后者是搭档。

设计搭档的体验，和设计工具的体验，是完全不同的两件事。

七

说到这，你可能发现了一个规律。

AI时代的产品经理职责，不是传统职责的「加法」，而是「范式转移」。

不是说你以前做的事还要做，然后再多做几件AI相关的事。而是很多以前的职责消失了或者被弱化了，同时新增了一些以前根本不存在的职责。

弱化甚至消失的，是什么？

精细的原型设计，弱化了。因为AI产品的界面往往极其简单，就是一个输入框，体验的核心不在界面，在背后的模型。

复杂的功能规划，弱化了。因为产品不再是一堆功能的集合，而是一个能力的容器。你规划的不是「做什么功能」，而是「开放多少能力」。

严格的项目排期，弱化了。因为模型调优的进度很难精确预估，很多时候是「试到好为止」，而不是「到点上为止」。

新增出来的，是什么？

边界设计、Prompt工程、评估体系建设、实验设计、数据飞轮、人机协作模式。这些在传统产品里要么不存在，要么是边缘职责，现在在AI产品里变成了核心。

八

回到开头那个产品哥们。

他听完我说的这些，沉默了一会儿，问我，那我过去五年积累的东西，真的都没用了吗？

我说，恰恰相反，你积累的那些东西，决定了你能不能把新的职责做好。

对用户需求的敏感度，帮你判断模型该开放多少能力。

对业务的深度理解，帮你设计更精准的评估体系。

对数据的熟悉，帮你更快地搭起数据飞轮。

对项目推进的经验，帮你管理更复杂的实验节奏。

底层能力都在，只是表现形式变了。

就像一个好的棋手，学会了围棋，再学象棋，规则变了，但算计的能力、预判的能力、做决策的能力，都在。

AI时代的产品经理，不是一份新工作，是老手艺在新战场上的重新开张。

战场变了，规则变了，但打胜仗需要的那些东西，从来没变。