AI 时代的 PM 到底在做什么

一个让我不安的现象

我在一家做 AI 外贸产品的创业公司当 PM。上个季度，我们接入的上游大模型厂商——不管是 OpenAI、Anthropic、Google，还是国内那几家——又发布了新版本模型。而在它上线、我们把它接进产品的那天，整个产品团队没有任何情绪波动。

会议照开，需求照评，迭代照排。模型从 X 变成了 X+1，我们的产品形态没有任何变化——它只是把一个更聪明的模型，塞进了一个早就定义好的 workflow 里。

那一刻我意识到，我们公司不是 AI 原生组织。我们做的也不是 AI 原生产品。我们只是一个把 AI API 包装成 SaaS 的传统软件公司。

这不是某一家公司的问题。这是当下绝大多数挂着“AI”招牌的中国创业公司的真实状态。而这个状态背后，藏着一个 PM 行业还没认真讨论过的问题：

AI 时代的 PM，到底在做什么？

互联网时代，PM 的工作是用数据定义“好”

字节式的 PM 方法论，是过去十年中文互联网最成熟的产品体系。

它的核心是：用户行为产生数据，数据告诉你什么功能 work，什么不 work。A/B test、留存、DAU、ARPU——这一整套指标，本质上是让用户用脚投票，来反推什么是“好的产品”。

这套方法论的强大，在于它把“什么是好”这件事，从主观判断变成了客观测量。PM 不需要靠经验、直觉、领导喜好做决策——数据替你做决策。

但它有三个前提：

第一，你需要海量用户产生统计显著的数据。 第二，这些用户行为可以被采集、被量化。 第三，行为分布要相对稳定，不能今天是 A 明天是 B。

这三个前提，AI 产品全部不满足。

AI 时代，用户体验和模型行为耦合了

互联网产品的用户体验，是 UI 决定的。按钮放哪里、流程怎么走、文案怎么写——这些都是产品经理拍板的事。模型在这套体系里，只是后台的一个组件，跟数据库、缓存没区别。

AI 原生产品不一样。一个 AI 销售助手生成的邮件好不好、一个代码 Agent 写出来的代码能不能用、一个对话产品给出的回答有没有温度——这些不是 UI 决定的，是模型每一次输出决定的。

也就是说，用户体验和模型行为耦合在一起了。你不能再像传统 PM 那样，把“用户体验”和“技术实现”分开来谈。在 AI 原生产品里，这两件事是同一件事。

这个耦合带来一个直接后果：PM 价值定义权的载体变了。

互联网时代，PM 通过 PRD 定义产品。PRD 是给人看的——给设计师、给工程师、给老板。 AI 时代，PM 通过什么定义产品？

答案是：benchmark

这个词听起来像算法工程师的事——大部分中文 AI 圈的 PM，把 benchmark 理解成“模型能力测试集”，觉得是研究员该关心的东西。

错了。Benchmark 在 AI 产品语境下的本质，是把“什么是好的产品”这件事，从主观判断变成机器可执行的规范。

它不是测试集。它是 PRD 的代码化形式。

你给一个 AI 销售邮件功能写 benchmark 的过程，本质就是回答这些问题：

• 一封“好邮件”需要满足哪些维度？（相关性、个性化、说服力、合规性……）
• 每个维度怎么打分？5 分是什么样，3 分是什么样？
• 边界 case 怎么处理？客户是欧洲人和东南亚人，标准一样吗？
• 哪些维度的加权，最能预测“客户真的回复了”？

回答完这些问题，你的产品就被定义完了。 Benchmark 写完，产品需求就完成了——剩下的是工程问题。

这就是为什么 Anthropic 的 CPO Mike Krieger 在公开访谈里说：“如果你来 Anthropic 面试 PM，我们想看你怎么思考 eval。这种人才不够多。”

OpenAI 的 CPO Kevin Weil 说得更直接：“写 eval 会成为 PM 的核心技能之一。”

这两句话不是行业领袖在带节奏。这是他们在告诉所有人：AI 时代 PM 的工作发生了载体级的迁移。

Benchmark 的两层结构

但真正让我兴奋的，不是“PM 要会写 eval”这件事——这只是表层。

真正深的洞察是：好的 AI benchmark，从来不是一个东西，是两层东西。

第一层（L1）：用户侧的成功。客户回复了、成交了、续费了、推荐给朋友了——这是产品在用户身上产生的最终效果。

第二层（L2）：Agent 侧的成功。模型输出符合规范、信息完整、语气合适、没有幻觉——这是 Agent 在技术执行层面“做对了事”。

这两层经常错位，而且错位的方向很反直觉。

举个具体例子。一封 AI 生成的销售邮件，可能 L2 维度全部满分——相关性 5 分、合规 5 分、语气 5 分——但客户没回。也可能某封邮件 L2 维度上有瑕疵，但因为某一句话戳到了客户的真实痛点，客户回复了。

L2 是过程指标，L1 是结果指标。 L2 是近端的、可解构的、可观测的，L1 是远端的、整体性的、跨场景的。 L2 是“产品有没有正确地做事”，L1 是“产品有没有做正确的事”。

德鲁克 60 年前讲过这句话。它在 AI 时代，终于有了一个具体的、可执行的载体——就是 benchmark 的双层结构。

为什么这个翻译，只有 PM 能做

现在请你诚实地想一个问题：L1 和 L2 之间的翻译，该谁来做？

候选人有四个：

算法工程师：擅长 L2（他们就在写模型），但结构性地不擅长 L1——他们的训练不包含深度理解用户、业务、场景。让算法定义 benchmark = 只有 L2 没有 L1 = 产品技术指标漂亮但用户不买单。这是为什么很多大模型公司 benchmark 跑得很高，但产品扑街。

用户研究员：擅长 L1（他们就在研究用户），但不懂模型怎么工作，无法把“用户的成功”拆解到 Agent 的可观测行为上。让用研定义 benchmark = 只有 L1 没有 L2 = 标准说了想要什么，工程不知道怎么做。

领域专家：擅长定义自己领域里的 L1，但通常不懂 AI 的能力边界——要么定义出模型根本做不到的标准，要么错过模型能做到的更高标准。

PM：PM 这个角色诞生以来唯一不变的本质就是——“理解用户 + 理解技术 + 翻译两者”。

互联网时代，PM 把“用户需求”翻译成“产品功能”，由工程师实现。 AI 时代，PM 把“用户的成功”（L1）翻译成“Agent 的成功”（L2），由算法和工程实现。

这件翻译工作，在结构上，只有 PM 的训练能胜任。算法从技术往上看够不到 L1，用研从用户往下看够不到 L2，领域专家从业务横着看两头都够不到——PM 是唯一一个被训练成“同时看两层”的角色。

所以“AI PM 必须懂 eval”这句话，不是技能升级。

它是 PM 角色本质，在 AI 时代终于显形。

PM 行业的悄然分化

如果你认同上面这套推导，你会得出一个让人不太舒服的结论：

PM 这个职业正在分化成两种，而且差距每个月都在扩大。

第一种 PM（我称之为 Type A）：还停留在“提需求 + 跟进度 + 看数据”的传统范式里。AI 在他眼里是一个黑箱——他写“AI 要友好礼貌”，剩下的让算法搞定。这种 PM 在 AI 包皮型产品（SaaS 加个 AI 助手）里还能活，但在真正的 AI 原生组织里，会被边缘化。

第二种 PM（Type B）：核心工作就是定义模型行为标准 + 设计 eval 体系。他不只是和模型打交道，他用模型的语言定义产品。他能写 prompt、能设计 rubric、能用数据驱动算法决策。在 AI 原生组织里，这种 PM 才是真正的产品负责人。

OpenAI 的 CPO 在公开访谈里说过一个判断：“这两层 PM 的差距每个月都在扩大。AI 公司需要 Type B PM，他们承担不起靠 vibes 出活的人。”

我把这句话翻译一下：

5 年后，不懂 eval 的 PM，会像今天不懂 SQL 的 PM——还能找到工作，但已经不在主战场。

你想成为哪种 PM？

我写这篇文章，不是为了给“AI PM”这个标签镀金。

事实上，我对“AI PM”这个标签本身没什么感情。我感兴趣的是一件更具体的事：

当你脑子里能清晰地把一个 AI 产品的好坏，拆解成 L1 和 L2 两层，并用代码化的方式定义出来——你才真的进入了 AI 原生产品的设计语境。

否则，你做的还是 SaaS，只是塞了个模型进去。

我自己也才走到这条路的入口。我在外贸公司每天做的 ToB Agent eval，我硕士论文要做的中文工具调用 benchmark，我业余时间写的 galgame skill——这三件事在外人看来是三件事，但它们的本质是同一件事：

把模糊的判断标准，变成可执行的指令和可衡量的指标。

这是 AI 时代 PM 真正的内功。

所以这篇文章不是答案，是一个邀请——

你写过完整的 eval 吗？你能把你产品的“好”拆成 L1 和 L2 吗？你的下一份工作，是去做 Type A 还是 Type B？

如果你也在想这些问题，欢迎来聊。