SuperMe 访谈多家公司产品经理，分析 AI 时代 PM 工作方式的变化

最近在 SuperMe，我们采访了从初创公司到上市公司的众多产品经理，以了解他们的工作流程如何随 AI 而改变。下面我将呈现一些发现、一些见解，以及一些关于未来走向的真诚疑问。

本文由以下 SuperMe 档案审阅：Julie Zhou、Ami Vora、Shishir Mehrotra、Sachin Rekhi、Aparna Chennapragada

感谢阅读 Casey Accidental！免费订阅即可收到新文章并支持我的工作。

AI 正在成为 PM 工作的上下文层

我们交谈过的每位 PM 都有以 AI 为核心的工作流程。PM 过去常常在众多不同的应用和浏览器标签页之间来回切换来完成工作：文档编辑器、多个分析工具、Slack、工单系统、wiki、幻灯片制作工具。

别误会，他们仍然使用这些工具。但他们倾向于在 AI 工具内部使用它们。MCP 被采用以将工作流集中到一处、而不是在应用和标签页之间切换的程度，怎么强调都不为过。这些工具中许多的界面可能已经不再重要，因为那已不是它们被消费的地方。

称之为工作空间也显得不准确。似乎正在发生的是，PM 们围绕他们的全部工作构建了一个个性化的上下文层。有些人使用大量本地文件，有些人使用大量 MCP 集成，有些人使用大量自定义技能。这个公式看起来是：偏好的模型 + 公司上下文 + 个人上下文 + 公司工具。

有些人亲自构建了这些，以便在未来跨公司和新职位复用。为什么这看起来是必要的？你的 AI 工作环境使用时间越长就越有价值，但其中积累的大部分上下文属于你的雇主，换工作时就会消失。新职位感觉比以前更像从零开始。

PM 们将上下文带入他们最喜欢的 AI 环境，在那里完成所有的分析以及策略和信息的撰写，完成后导出到相应的内容渠道，无论是幻灯片、文档、电子邮件还是 Slack 消息。确保那一个界面拥有上下文，比擅长 SQL / Jira / [在此插入工具] 重要得多。技能允许针对公司特定的标准来规定工作流中某些部分的运作方式，比如分析或幻灯片 / 文档格式。

PM 更高效了，但他们的团队未必更有影响力

从 PM 到工程师再到设计师，每个人似乎都工作更努力、交付更多。每个团队都在产出更多代码、更多规格、更多原型，修复更多 bug，编写更多评估，管理更多仪表盘。令人惊讶的是，很少有 PM 认为产出的剧增带来了相应的业务成果增长。

AI 似乎让以前在经济上不划算的工作变得足够便宜而可以去做。那些未被排定优先级的工作。那些不产生杠杆效应的工作。那些过去一直留在待办列表里的工作。跟上所有这些工作，实际上让 PM 们用于规划最有影响力工作的时间变少了。

但这也让停止做这些任务变得不容易。如果现在每家公司都用 AI 更快地处理 bug 和低价值的功能请求，客户的期望是否已经上升到如果我们不做就会落伍的程度？这个答案在今天很大程度上是不可知的。

AI 移动了传统产品开发中的瓶颈

产品经理过去要花大量时间等待工程开发完成。即使与最优秀的工程师合作，这个过程也很缓慢且昂贵。随着代码生成变得容易，产品开发流程中的瓶颈已经转移到了其他地方：

• 设计

• 与更广泛产品的功能集成

• 处理边缘情况

• 组织协调一致

• 共享的产品原则。

AI 消除了一个限制，同时暴露了其他几个限制。组织尚未围绕这些新限制重新设计其产品开发流程，而底层技术的变化速度仍快于这些流程稳定下来的速度。

AI 生产力如今已是基本门槛。产品判断力重新成为差异化因素

一种新兴的期望是，产品经理应该能够：

• 自行查询数据

• 制作原型

• 修改提示词

• 编写代码

• 构建内部工具

• create agents

• define evals

人们越来越感觉到，产品经理（PM）的标准已经从「足够懂技术以确保做出好的决策并推动落地」过度转向了「亲自展示良好的技术能力」。这造成了一种奇怪的激励：PM 们更努力地证明自己是技术型、AI 原生的，却更没有时间去判断团队产出的东西是否本就不该存在。

在 AI 出现之前，工程资源的稀缺迫使人们进行优先级排序。AI 消除了一部分稀缺性，却没有取代优先级排序机制。人们感觉到，无论在大组织还是小组织内部，优先级排序的能力都需要被重新发现和重视。历史上 PM 的优先级排序能力之所以重要，部分原因在于这样的认知：

• 代码是一种杠杆

• 但是代码很昂贵

• 所以你把它留给最好的想法

对于其他所有事情，我们要么不做，要么用人工方式来做。

优先级排序还发挥了另外两个重要作用：

• 它控制了面向客户的变化速度

• 它淘汰了糟糕的想法

当团队开始以更快的速度发布时，越来越多的新功能更快地触达客户，造成困惑，而其中很多概念本就不该被开发，因为它们不是好想法。现在产品变得更难理解，代码库也是如此。

对于更成熟的组织来说，利用 AI 提升效率只是基本要求。真正被看重的是利用 AI 为客户和业务创造此前无法实现的价值。这实际上是技能与流程的结合。品味，或者说知道什么是好的，是 PM 在这样一种能改变可构建产品类型的新技术面前需要重新培养的技能。原则——我们定义人类和智能体据以执行的基本事实——是新的流程，PM 让团队围绕共识达成一致的能力因此变得至关重要。只有当 PM 让自己的判断对他人可理解、可复用时，AI 才会提升判断力的价值。

围绕 AI 集中化并不意味着完全信任 AI

产品经理把 AI 用在方方面面，但这并不意味着他们信任 AI。他们所做的，是制定一套精细的技巧，来决定 AI 可以被信任到什么程度。AI 能知道什么、能替你决定什么，是我们访谈的所有产品经理的关键决策点。有些人信任它处理数据和查询。有些人永远不会把原始数据交给它。有些人会交出原始数据，但希望拿回原始数据，而不是被平滑处理过的结论。

每个产品经理都见过 AI 过度依赖给定的上下文，抹平了细微差别——而最有用的产品洞察往往就藏在这些细微差别之中。某种程度上，产品经理的 AI 工作流越成熟，就越不会盲目信任 AI。一项新技能正在浮现：如何弄清楚该给 AI 什么，以最好地提升你自己的表现：

• 它拥有的上下文

• 允许它做的综合分析

• 它能替你执行什么

• 哪些地方仍需要人的判断

• 哪些内容需要由人来核实

与 AI 协作的三种运行模式

从我们的研究中，我们看到了使用 AI 的三种常见反应。每个组织的起步方式大致相同：

使用 AI -> 体验到神奇效果 -> 开始更快地构建 -> 体验到错误

在那之后发生的事情，定义了经历这一切的个人、团队或组织。这不是三种类型的公司。同一家公司内部的不同团队运作方式可能不同，甚至同一个团队在发展的不同阶段也可能在不同模式之间切换。

反应 1：保护下行风险

“万一它错了怎么办？”

一些团队在经历了 AI 幻觉或错误之后，收紧了流程。他们只针对特定用例批准非常具体的 AI 工具。这些组织对垃圾内容（slop）的排斥如此强烈，以至于它们比 AI 出现之前可能更注重数据的准确性和呈现。严格的关卡、强大的幻灯片文化，被发现错误使用 AI 会带来严重后果。

这些团队并不反 AI，但他们对公司以及个人内部声誉的损失都非常敏感。这个角色就变成了：弄清楚谁需要批准这件事，他们需要什么证据，以及我如何让它足够安全以便推进。与 AI 相关的创新往往发生在业余时间的个人项目中。他们不想因为组织的谨慎而在未来所需的技能上落后。

虽然 Claude 是我们的研究参与者最常用的界面，但我们发现他们围绕什么进行集中化，多少有些随机，取决于他们的 IT 部门告诉他们可以使用什么。初创公司往往可以使用任何他们想要的东西，而大公司要么必须使用非常具体的公司工具，要么只能访问整个生态中随机的一个子集。Claude 加上 Cursor、Codex 或 Gemini 中的一个（但不是全部）是最常见的配置。或者对于微软系的公司，允许使用 Copilot，可能再加一个其他工具。他们在这些工具中能使用哪些 MCP 插件也不一致。

不同团队对这些问题的清晰程度各不相同。有些团队有非常明确的门控流程，但更多团队则是靠心照不宣地摸索组织中谁掌握着软实力。PM 们会一直兜圈子，直到找到决策者。了解组织的运作方式正变得越来越有价值。这倒不是说它对 PM 从来就不重要，而是在优先级和流程不断变化的当下，知道该找谁谈、并且与他们有默认的信任，是一种当下怎么高估都不为过的硬通货。没有它的 PM 压力山大，而拥有它的 PM 则要少操心得多。

这种应对方式的优势在于质量控制。问题在于，公司可能会花费大量精力来保护其现有地位，而竞争对手却发现了某种从根本上全新的东西，从而侵蚀了该地位的价值。

这类应对方式的决定性特征是，团队对 AI 的恰当与不恰当用途有着非常明确的认知，并且会围绕这些边界进行强有力的执行。

应对方式 2：最大化上行空间

“为什么不试试呢？”

与第一类团队不同，第二类团队默认会去尝试新东西。他们积极投入，接受自己的一部分工作可能是垃圾产出（slop），但总体上他们会完成更多工作，并且能从这种新的迭代速度中更快地学习。如果你能构建得更快，就能学得更快——这个想法是合理的，但学习离不开围绕它的一些流程。

这些团队比以往任何时候都更努力，完成的工作也多得多，但他们并没有成长得更快。有些团队蒙着眼睛埋头苦干。有些则指出，尽管交付量增加了 10 倍，但他们并没有成长得更快。他们正处于对生产力/影响力不匹配这一问题的不同认知阶段。但所有人都相信自己是 AI 原生的，这为他们现在或未来在别处的公司带来了一定的工作保障。

似乎出了问题的一部分在于，「交付更快 -> 更多实验 -> 更快学习 -> 更快增长」这一论点正在失效，因为事情发生得太快，以至于你交付的能力超过了你学习的能力。

PM 们正在构建 AI 幕僚长或中央工具，以跟踪一堆本就不该被批准的项目更新。垃圾实验导致垃圾内部工具，进而在内部造成组织混乱，在外部造成客户对产品的困惑。内部由 AI 撰写的更新，又催生了用来汇总和阅读所有更新的 AI 工具。所有这些东西都在内部被使用，但收益何在？

技能是 AI 原生通货的最初形式。几位 PM 提到 AI 采用中存在一种表演成分。可见的 AI 活动可能成为你跟上潮流的一种证明。黑客松变成了发布新技能，而不是构建新事物。这里面多少有点「卖铲子」的梗。其中一些技能有很好的来源，有些影响力大到人们会试图在新公司重新复刻它们，但许多不过是「假装你是……」之类的提示词。

组织垃圾（slop）是指一个组织生成工作的速度快于其评估、协调或吸收这些工作的能力时所发生的情况。这似乎是应对方式 2 中公司的决定性特征。

应对方式 3：优化 AI 以产生影响

“这重要吗？”

我们在这个类别中看到的团队，主要关心的是他们构建的东西是否能对用户或业务指标产生积极影响。他们把 AI 让他们能够构建以前无法构建的东西，视为影响这些指标的杠杆。是的，他们关心生产力，但如果它最终没有转化为更多的增长或更多的利润，他们就得不到任何功劳。如果你因此构建得更快、学习得更快，那很好。如果你构建得更快却没有学到任何东西，那你就浪费了很多人的时间。

他们通过产品直觉和良好的优先级排序这层滤镜来看待 AI 带来的任何超额收益。他们不把 token 消耗等同于进展。他们要么需要让客户，要么需要让 CEO/CFO 对他们发布的东西印象深刻。他们拥有的工具比回答 2 中的公司少，但他们对这些工具更有信心。他们的工作存在于文档和电子表格中，而不是像回答 1 中的公司那样存在于幻灯片中。

而这些工作既是为了他们的内部 agent，也是为了供同事使用而写的。每一份产出都是为人类和 agent 这两个一等公民而写的。许多 PM 甚至已经为这种转变改变了他们的默认风格或格式，用 markdown 或 HTML 取代了文档和幻灯片。

他们构建了大量的内部 agent 和令人惊叹的功能。当这些内部 agent 影响到其他职能部门的工作时，PM 面临着真正的张力。这可能会给 CFO 留下深刻印象，但不会给公司其他部门的朋友们留下深刻印象。他们的工作保障很好，但公司本身通常已经历过裁员和某种形式的重大组织变革。

看起来我们在第三个桶中观察到的团队是从第二个桶开始的。也许团队必须先被 AI 淹没，才能学会如何明智地约束它。

那么 PM 现在的工作是什么？

PM 目前正面临着巨大的组织变革。他们迄今为止的整个职业生涯都围绕着一个关于稀缺性的基本事实：我们无法构建客户想要的一切，所以我们必须进行优先级排序。AI 承诺了富足。我们突然可以构建一切，于是我们就这么做了。但这并没有带来应许之地。因此，PM 及其组织逐渐意识到，这种富足使得旧工作描述中的某些部分变得更加重要。能够构建一切的能力，使得决定不构建什么变得更有价值。

在经历了一段期望 PM 自己成为工程师的短暂时期后，工程团队正在重新接管大部分实现机制。PM 越来越负责应该发生什么、为什么发生、支配产品行为的原则，以及应该如何评估成功。关于通过 PRD 还是原型来传达这一愿景存在争论，但这场争论掩盖了一个事实：评估（eval）正在成为核心的产品产出。最初的战略文档或 PRD 正重新出现，成为让 agent 和人类都能理解我们打算构建什么的产出。评估则定义了我们是否做到了。

AI 让 PM 更容易构建了。它并没有让知道什么值得构建变得更容易。把这部分做对的 PM，才会是真正把 AI 转化为更好产品的人。

向 my SuperMe 了解更多关于这些见解的信息。

Currently listening to my textural noise playlist.

感谢阅读 Casey Accidental！免费订阅以接收新文章并支持我的工作。