AI产品经理到底该干什么？代码便宜以后，最贵的是判断写什么

如果现在重新招一个 AI 产品经理，我觉得 JD 第一行不该写熟悉需求分析和项目管理。

太像旧世界了。

第一行应该写得更直接一点。

会不会把一个模糊想法，用 Agent 和 vibe-coding 在两天内做成能试的东西。

这句话听起来有点野。

但差不多就是现在的真实变化。

以前 PM 最重要的动作是把需求讲清楚，让工程、设计、运营、测试都知道接下来该干什么。

现在不够了。

现在一个 AI PM 至少要会六件事。

会拆 Agent。

会 vibe-coding 做原型。

会写评估标准。

会给模型准备上下文。

会设计权限和人工兜底。

会把用户反馈喂回系统。

这六件事听起来像技术活。

但其实都是产品活。

只是它们长得不再像传统 PRD 里的章节了。

先说 Agent。

很多人一听 Agent，就以为是在产品里塞一个聊天框。

用户问一句，它答一句。

这当然也是 Agent，但太窄了。

真正的 Agent 产品经理，要想的是一条工作流怎么被机器接住。

比如销售同事每天要看新线索。

旧做法是打开 CRM，看公司官网，翻 LinkedIn，搜新闻，判断这家公司值不值得跟进，然后写一封邮件。

如果让 Agent 做，PM 要拆的不是一句帮我找客户。

你要拆成更小的动作。

它先从哪里拿线索。

哪些字段算有效。

什么样的公司要打高分。

什么信息不能编。

什么时候只起草邮件，不能直接发送。

什么时候必须提醒人类复核。

这才是 Agent 设计。

不是把模型接进来，而是把一段原本靠人脑粘合的流程，拆成模型能执行、能停下、能被检查的步骤。

OpenAI 的 Workspace Agents 为什么值得关注，也不是因为它又能聊天了。

而是它把软件采购、产品反馈、周报、销售线索、供应商风险这些公司里的重复流程，做成团队可以共享的 Agent。

这就是一个信号。

AI 产品经理以后要设计的，越来越不是单个页面，而是一段会自己往前走的流程。

再说 vibe-coding。

这个词已经有点被玩坏了。

好像大家打开 Cursor、Claude Code、Codex，随便喊两句，产品就自己长出来了。

不至于。

但它确实改变了 PM 的工作方式。

以前 PM 有个想法，第一反应是写文档。

现在更好的第一反应可能是做一个粗糙原型。

不是为了替代工程师。

而是为了减少废话。

比如你想做一个 AI 会议纪要功能。

旧流程可能是先写，支持上传录音，自动总结重点，生成待办，支持导出。

每一句都对。也都没用。

因为它太像任何一个会议纪要产品了。

如果你会 vibe-coding，你可以直接让工具做一个最小原型。

用户上传一段转写文本。

系统先识别谁承诺了什么。

再把待办按负责人拆开。

再生成一段可以直接发到飞书群里的消息。

你把这个拿给用户看。

用户会立刻告诉你，真正有用的是那条飞书消息，不是那份漂亮总结。

这一下就值了。

PM 做原型，不是为了炫技。

是为了更早被现实打脸。

越早越好。

脸疼一点，项目少死一点。

第三件事，是会写评估标准。

AI 产品最可怕的地方，是它很容易看起来已经好了。

一个客服 Agent 回答得像模像样。

一个周报 Agent 写得也挺顺。

一个设计 Agent 出图还挺高级。

但它到底好不好？

不能只靠感觉。

AI PM 要会把好拆成可检查的东西。

拿客服 Agent 举例。

不能只说回答准确。

你要写清楚，它不能编政策，不能承诺退款，不能泄露用户隐私，遇到愤怒用户要转人工，超过两轮没解决要升级工单。

再拿代码 Agent 举例。

不能只说能修 bug。

你要写清楚，它必须跑测试，必须解释改了哪些文件，不能改无关代码，遇到权限问题要停下来问。

这就是评估。

很多 AI 产品做不起来，不是模型太弱。

是人根本没定义什么叫做对。

模型只好自由发挥。

自由发挥四个字，放在舞台上很美。

放在企业流程里，通常比较吓人。

第四件事，是上下文工程。

提示词当然重要，但只会写提示词不够。

真正的产品问题是，Agent 到底能看到什么。

它需要哪些文档。哪些历史案例。哪些用户反馈。哪些系统权限。哪些东西不能给它看。

很多公司一上来就抱怨 AI 不懂业务。

你仔细一看，业务资料散在十几个群、三份过期文档、两个没人维护的表格里。

人都看不懂。模型凭什么懂。

AI PM 要做的，很大一部分是把公司变得对 AI 可读。

不是把所有资料都塞进去。

而是知道不同任务需要哪些上下文。

客服 Agent 需要最新政策和历史工单。

销售 Agent 需要客户画像和跟进记录。

产品反馈 Agent 需要用户原话、产品路线、已知 bug、重要客户权重。

同一个模型，吃到不同上下文，表现会完全不一样。

所以 AI PM 不是只写一句你是一个资深产品经理。

拜托，模型一天要扮演八百个资深。

它缺的不是头衔。它缺的是上下文。

第五件事，是权限和兜底。

这是很多 demo 里最容易被跳过的部分。

因为 demo 世界很干净。

真实公司不干净。真实公司有权限。有审批。有合规。

有老板半夜突然问，这封邮件谁让它发出去的。

所以 AI PM 不能只问 Agent 能做什么。

还要问它不能做什么。它能不能删数据。能不能发邮件。能不能改价格。能不能把内部信息发到外部系统。

出了低置信度结果，谁来接管。

一个好 Agent 产品，应该有刹车。

而且刹车要设计得很顺。

不是每一步都弹窗问你。

那叫把用户逼疯。

也不是一路狂奔到终点。

那叫把法务逼疯。

中间这个分寸，就是产品经理的活。

第六件事，是反馈回路。

AI 产品不是上线以后就稳定了。

它更像一个会犯错、会被用户教坏、也会被流程卡住的新人同事。

你不能只看使用量。

还要看它在哪些地方被打断。哪些回答被用户改写。哪些任务总是转人工。哪些步骤每次都超时。哪些错误一犯再犯。

这些东西要回到提示词、知识库、权限、流程和评估集里。

不然你只是把一个不稳定的东西发出去了。

然后每天祈祷它今天心情好。

这不是产品管理。

这是赛博求签。

讲到这里，再回头看 AI 产品经理到底该干什么。

就没那么玄了。

不是每天研究十个新工具截图发朋友圈。

也不是把 PRD 交给 AI 生成，然后假装自己升级了。

AI PM 的日常会更像这样。

上午和用户聊，确认他真正痛的是线索跟进慢，不是 CRM 不好看。

中午用 vibe-coding 搭一个极简原型。

下午把流程拆成三个 Agent 步骤，一个查资料，一个打分，一个写邮件草稿。

傍晚补上评估标准和权限边界，不让它自动发送。

第二天找五个销售试用，看他们到底改了哪些话。

第三天把这些改动变成新的示例和规则。

这才像 AI 产品经理。

你每天都在把一个模糊问题，变成一个能被机器执行、能被人类检查、能被业务验证的系统。

这件事以前也有人做。

只是以前中间隔着很厚的工程成本。

现在中间那层变薄了。

薄到一个 PM 不能再躲在协调后面。

你要更早面对真实用户。

更早面对真实原型。

也更早面对自己的判断。

所以我不觉得 AI PM 会消失。

但那种只会写需求、排会议、催进度的 PM，会越来越尴尬。

因为 AI 让做东西变快了。

一旦做东西变快，做错东西也会变快。

以前一个错误需求，可能要两个月才暴露。

以后可能两天就能做出来，三天就能上线，第四天就开始污染用户体验。

挺吓人。

这就是为什么代码便宜以后，判断写什么变贵了。

AI 产品经理真正要练的，不是一套新黑话。

是把 Agent、vibe-coding、评估、上下文、权限、反馈这些新技能，变成自己判断产品的手和脚。

说到底还是那件老事。

做对的东西。

只是现在，机器能帮你跑得很快。

所以你更不能跑错方向。