AI 时代，为什么产品经理反而更吃香了？

发表于 分类于
AI 时代，为什么产品经理反而更吃香了？

AI 时代，为什么产品经理反而更吃香了？

Lenny Rachitsky 最近更新了他每半年一次的科技行业就业市场报告。数据中有一个细节在社交媒体上引起不少讨论：从 2023 年中期开始，产品经理（PM）的岗位数量超过了设计师，此后差距持续拉大，目前 PM 需求是设计师的 1.27 倍。与此同时，PM 岗位总量达到了三年来的最高水平，全球超过 7,300 个开放岗位，比 2023 年初的低谷高出 75%。

在所有人都在讨论 AI 会替代哪些岗位的时候，这组数据显得有些”反直觉”。但如果你仔细想想 AI 正在怎样改变产品开发的流程，也许会发现这个趋势并不意外。几天前，Anthropic Claude Code 的产品负责人 Cat Wu 发表了一篇文章，详细描述了她作为 PM 如何用 AI 重塑自己的工作方式。而我自己作为一个 2005 年以后就没写过代码的 PM，在过去半年里也经历了一次类似的”角色升级”。

这篇文章想把这三个视角拼在一起：就业市场数据在说什么，AI 前沿的 PM 在怎么工作，以及我自己的实战体验。

一组反直觉的数据

先看 Lenny 这份报告里跟 PM 最相关的几组数字。

数据来源是 TrueUp，追踪全球超过 9,000 家科技公司的岗位变化。需要注意的是，这些数据只覆盖科技公司，不包括非科技公司和咨询机构的岗位。

PM 岗位三年新高。 全球科技公司有超过 7,300 个开放的 PM 岗位，比 2023 年初的低谷高出 75%，仅今年以来就上涨了近 20%。

PM 需求反超设计师。 2023 年中期之前，设计师的开放岗位比 PM 多。之后发生了反转，PM 需求持续拉开，目前是设计师的 1.27 倍。设计师岗位自 2023 年初以来几乎没有增长，全球约 5,700 个。

PM 需求与设计师需求的比例变化（来源：TrueUp / Lenny's Newsletter）

AI 相关岗位呈指数级爆发。 AI 方向的 PM 和工程师需求曲线陡峭上扬，增速远超其他岗位类型。

工程师岗位同样在涨。 全球超过 67,000 个工程师岗位开放，AI 并没有减少工程师需求（至少目前没有）。

Lenny 在报告中对设计师岗位停滞给出了一个猜测：因为 AI 让工程师可以更快地推进产品，传统设计流程被卷入的机会变少了。这一点我认为只说了一半。更完整的图景可能是这样的：AI 正在让”能把想法变成可运行的东西”这件事变得更容易，谁来做这件事的边界在模糊。在这个过程中，负责”决定做什么”和”判断做得好不好”的角色变得更重要了，而这正是 PM 的核心地盘。

AI 指数曲线上的产品经理

Cat Wu 在文章开头讲了一个她反复做的实验：每当 Anthropic 发布新模型，她都会用 Claude Code 给 Excalidraw（一个开源白板工具）加一个表格功能，看模型能做到什么程度。2024 年 10 月的 Sonnet 3.5 做不到，2025 年 6 月的 Opus 4 偶尔能成功，到 2026 年 3 月的 Opus 4.6，已经可以稳定地一次成功，甚至敢在几千名开发者面前做现场演示。

根据AI 安全评估机构 METR 的测试显示，Opus 4.6 有一半的概率能完成需要人类工作近 12 小时的软件任务。而 16 个月前 Claude Code 刚启动时，当时的前沿模型 Sonnet 3.5 只能完成大约 21 分钟级别的任务。16 个月，能力跳了大约 41 倍。

METR 测试：各代模型能完成的软件任务时长呈指数增长（来源：METR）

这种变化对 PM 的影响是巨大的：「传统产品管理的剧本建立在一个假设上——项目开始时技术上能做到什么，项目结束时大致也差不多。指数级进步的模型打破了这个假设。你在设计时考虑的约束条件，可能在项目进行到一半时就不存在了。」

换句话说，PM 过去的工作方式是”先调研，再写 PRD，然后交给工程团队按计划执行”，一个项目周期少则数周多则数月。这种方式在 AI 能力快速迭代的环境里行不通了，因为你今天认为的技术限制，下个月可能就消失了。

那新的工作方式长什么样？Cat Wu 总结了几个她所在团队（Claude Code 团队）的实践转变。

用短冲刺替代长路线图。 除了正式的产品路线图，团队鼓励每个人（工程师、PM、设计师）做”side quests”，自己找一个下午去验证一个想法。Claude Code 的几个热门功能就是这么来的，包括桌面端集成、AskUserQuestion 工具和 todo list 功能。

用 demo 和 eval 替代文档。 传统的站会被 demo 展示取代了。有人做了一个新想法的原型，内部用户试一试，有真实使用量的就继续打磨。因为用 Claude Code 做原型可以在一个下午完成，试错成本很低。Cat Wu 举了一个例子：团队成员 Noah 写了一份 plugins（插件系统）的规格文档，用 Claude Code 生成的原型已经接近生产级别，直接成为团队最终上线版本的基础。

每次新模型都重新审视已有功能。 以前产品发布后基本就是优化和维护。现在每次模型升级都是一个隐性提示：你之前做的东西，可能可以大幅改进了。Cat Wu 举了 Chrome 集成功能的例子：团队注意到用户在用 Claude Code 开发 Web 应用后，手动切到 Chrome 里的 Claude 去测试，两个工具之间来回复制粘贴指令。用户自己在”攒”一个工作流，说明这应该变成产品内置功能。

做简单的事。 这是 Anthropic 内部的一个原则。Cat Wu 用了 todo list 的例子：最初模型不够可靠，经常忘记更新自己的 todo 状态，团队就在系统提示词里每隔几条消息插入一个提醒。这是个 hack，但管用。后来新模型出来了，这个行为变成了自带能力，提醒就删掉了。类似的模式反复出现：系统提示词和工具描述曾经被精心设计来弥补模型的局限，每次模型升级都可以砍掉一些。Opus 4.6 发布时，提示词量减少了 20%。

这些做法的底层逻辑一致：在一个技术能力快速变化的环境里，PM 的价值不在于写一份完美的 PRD 然后等执行结果，而在于持续判断”现在能做什么”和”该做什么”之间的交汇点。

一个 PM 的”全栈”日常

AI 时代产品开发的角色变化：从瀑布流到交叉融合（来源：Anthropic）

Cat Wu 在文章中描述了她日常使用的三个工具，构成了一个完整的工作流。

Claude.ai 是思考伙伴。 不需要执行动作的时候用它：讨论策略方向、处理复杂人际情况、快速获取信息。

Claude Code 是建造工具。 所有输出是代码的工作走这个路径：原型、eval 脚本、数据分析工具。Cat Wu 提到，她用 Claude Code 做的项目累计花了”几百小时的提示词交互”，但没有手写过一行代码。她做过的事包括：用 Streamlit 搭建大规模用户反馈分析应用、跑 eval（AI 系统评估）来帮公司寻找新的可信基准测试，甚至搭建强化学习环境来理解模型训练过程。

Cowork 是执行助手。 日常事务走这个路径：邮件处理、待办清单、制作幻灯片、在 Slack 里搜索某个决策的历史背景、预订出差行程。

Anthropic 另一位产品经理 Lisa Crofoot 在一段配套视频中演示了一个更具体的场景。她所在团队的数据科学团队搭建了一个 BigQuery MCP（Model Context Protocol，一种让 AI 工具连接外部数据源的标准协议），把产品数据表接到了 Claude Code 上。Lisa 演示了怎么用自然语言查询产品数据：「看看过去三个月深色模式的使用占比」，Claude Code 自动写 SQL 查询、执行、生成可视化图表，还主动加了 7 天滚动平均线。整个过程不需要 PM 会写 SQL。「你只需要做数据的人类解读者」，Lisa 说。

她接着让 Claude 按用户订阅类型拆分数据，几秒钟后新的图表就出来了。她说如果自己手动做这件事，「可能要花几个小时甚至更长」。

另一个她提到的高频用法是生成 eval。Eval 是评估 AI 系统和 AI 产品表现的测试用例集。传统做法是 PM 手写几个测试场景，覆盖面有限。现在她的做法是给 Claude 描述产品体验和几个示例测试用例，让它扩展整个测试空间，「很快就从一两个例子变成五十个」。

Lisa 在视频结尾说了一句话，我觉得比”效率提升”更准确地描述了正在发生的事：「这不只是自动化。很多事情是我以前独立完成不了的。它实际上在扩展我个人能做到的事的边界。」

Decagon 的产品总监 Bihan Jiang 也有类似的描述：「Claude 提高了好的产品团队能构建的上限，并且大幅缩短了从想法到原型的距离。把一个可触摸的东西放到客户面前，过去需要几周的构建时间。现在我会先在 Claude Cowork 里拉入 Slack、代码库和文档的上下文，然后转到 Claude Code，几个小时内就有了可演示的东西。」

我的版本：从不写代码到修最多 bug

读 Cat Wu 的文章时，我在不少地方感到一种强烈的共鸣。因为在过去半年里，我经历了一个类似但规模小得多的版本。我之前在《3人团队，如何用AI对抗百人竞品》里写过这段经历，这里结合 Cat Wu 的框架做一些补充。

我在做一个智能健康戒指的创业项目，核心团队三个人。我的上一次写代码是 2005 年。但在过去几个月里，我是团队里定位并修复代码 bug 最多的人。

这件事是怎么发生的？和 Cat Wu 描述的路径几乎一模一样。我用 Claude Code 直接读代码库，它能看到完整的代码逻辑，不需要我把问题”翻译”成自然语言描述。有一次外部测试用户第一天就反馈被踢出登录，我让 Claude 从 token 验证逻辑开始追，十分钟后拿到了完整的根因分析，还顺带发现了一个此前没有人注意到的独立 bug。

但定位问题只是前半段。更重要的是后半段的决策。那次修复有两条技术路线，一条看起来更”彻底”（无状态 token），另一条保留了服务端控制能力（有状态 token + Redis 持久化）。我选了后者，因为我知道产品将来一定需要”主动踢人下线”的能力。这个判断不是技术判断，是产品判断。Claude 帮我看清了所有选项，但选哪条路是我的事。

后来我还独立部署了崩溃监控系统（Sentry）、做过全量代码审计、写过多份技术方案。这些在传统分工里全部是”研发的活”。

我们团队的变化和 Cat Wu 描述的 Claude Code 团队很像：角色在融合。研发开始在开发前写 PRD 草稿，我能直接读代码提出具体修改意见。没有人宣布要”打破边界”，只是当 AI 帮你补上以前不会的那部分，”这不是我的职责范围”这句话就站不住脚了。

最难被替代的角色，也是门槛变化最大的角色

回到开头的数据。PM 岗位在涨，设计师岗位停滞，AI 岗位爆炸。这组数据背后有一个更大的趋势：AI 正在重新定义产品开发链条上每个角色的价值。

PM 为什么难被替代？因为 AI 可以帮你写代码、做数据分析、生成测试用例、搭建原型，但有两件事它做不了：决定”该做什么”，以及判断”做得好不好”。优先级排序、产品取舍、用户同理心，这些是需要人类判断力的工作。Cat Wu 的原话是：「PM 的工作是在快速模型进步带来的模糊地带中创造清晰。」METR 的数据说 AI 能完成 12 小时的编码任务，但它没说 AI 知道哪个任务值得做。

与此同时，”谁能成为 PM”这件事正在发生根本变化。

过去招 PM 看的是经验：你做过几年 PM，带过什么产品，走过多少个完整的产品周期。这些经验之所以重要，是因为”理解技术实现”和”推动跨团队协作”需要时间积累。现在 AI 把这两件事的门槛大幅降低了。一个有工程背景的设计师、一个懂用户的数据分析师、一个技术出身的市场营销人员，都可能比一个纯靠经验的传统 PM 更适合这个岗位。

如果现在让我招一个 PM，我不看简历上有没有 PM 经验。我看三件事：

工程思维。 能不能理解一个系统的逻辑，知道改动 A 会影响 B 和 C。不需要会写代码，但需要能”读懂”一个系统的运行方式。这个能力决定了你能不能和 AI 协作去深入技术层面，而不是只能停留在表面。

产品判断。 能不能从用户角度做取舍。功能做不做、优先级怎么排、体验的标准线在哪里。这是 PM 最核心的价值，也是 AI 目前最帮不上忙的地方。

说清楚问题的能力。 你怎么描述一个问题，决定了 AI 能帮你做到什么程度。「帮我查一下这个 bug」和「从 token 验证逻辑开始读，看看用户会在什么情况下被意外踢出登录」，结果差距极大。这不是提示词技巧，是对问题本身的理解深度。

这三条能力和传统的”PM 经验”没有必然关系。一个写了十年代码的工程师可能天然具备第一条和第三条，只要补上第二条就是很好的 PM。一个长期面对客户的销售可能在第二条上有天然优势。

所以”PM 最难被替代”和”人人都可以转 PM”并不矛盾。被替代的是旧的 PM 定义：靠经验、靠流程、靠协调。留下来的是 PM 的核心：判断力、系统思维、清晰的表达。AI 降低了入场门槛，但提高了真正做好这个角色的标准。

Cat Wu 在文章结尾写道：「PM 的角色现在是同时追踪两件事：AI 正在如何改变你的工作方式，以及 AI 正在如何改变你的产品能做到什么。如果你能把这两件事都做好，你就不会是那个被 table tool 成功惊到的人，你会是那个早就预见到这一刻的人。」

我补充一条：你也不会是那个被 AI 替代的人。因为这些判断，恰恰是 AI 做不了的事。

参考来源