AI 会取代产品经理吗：四种路径与真实边界

围绕“AI 会不会消灭产品经理岗位”的讨论，常见说法大致有四类：

1. 产品经理工作会被完整自动化
2. 产品经理职责会被设计、工程、管理层吸收
3. AI 提升效率后，企业只需要更少的产品经理
4. 不是岗位本身被替代，而是 AI 泡沫破裂后整体就业市场收缩

把这四条路径拆开看，会更容易得到可执行的判断。结论先放前面：

• 产品经理岗位被完整自动化，概率不高
• 职责边界会变化，部分团队会出现角色收敛
• AI 会改变产品经理的工作方式，但未必直接减少需求
• 真正更现实的风险，反而来自市场周期和资本回撤

产品经理会被完整自动化吗？

结论：大多数产品经理岗位不属于短期内可被完整自动化的类型，但低维度、偏交付型的岗位更容易受影响。

“完整自动化”指的是，AI agent 或其他 AI 系统，能够独立完成今天由人类产品经理承担的主要职责。

这件事直觉上就不太容易发生。翻译、文案、编码这类工作，语言本身就是核心媒介，而且训练样本充足。产品管理不同，它很大一部分发生在现实协作环境里，依赖讨论、协调、达成共识、承担决策后果。仅靠吞入书籍、文章、论坛讨论，模型很难真正学会这些。

用“工作维度”判断自动化概率

一个有用的判断框架是 job dimensionality，也就是一份工作包含多少种不同任务。

• 仓库工人的任务相对集中，比如拣货、打包、分拣、搬运，维度较低
• 大型公司 CEO 的工作涉及决策、沟通、战略、组织、关系管理等，维度较高

通常，维度越低，越容易自动化；因为企业更倾向于在“能自动化绝大部分任务”的前提下取消岗位。

产品管理大多属于高维度工作。以一个成熟的产品经理为例，常见任务就包括：

• 用户研究
• 市场分析
• 数据分析
• 需求澄清
• 优先级排序
• 战略判断
• 跨团队协调
• 沟通说服
• 实验设计
• 结果衡量

这类岗位不是单一技能堆出来的，而是多种任务互相补位。AI 可以接手其中一部分，但要把整份工作都吃掉，并不容易。

哪类产品岗位更容易暴露在自动化风险下？

更容易被影响的，通常是偏 delivery product owner 的角色，也就是主要把 roadmap 转成 backlog、user story、交付文档的人。

这类岗位的问题在于：

• 工作维度更窄
• 决策权更小
• 创造性空间更有限
• 更容易被误解为“文档生产”和“流程转译”

所以从理论上说，它们更容易被自动化。

但这里有一个常见误区：把一个岗位表面上看起来简单，就当成它真的简单。
即便是交付型 PO，通常也在做很多没有被正式写进 JD 的工作，比如：

• 在研发和业务之间做实时澄清
• 处理模糊需求里的冲突
• 补齐上下文
• 识别风险
• 平衡短期交付和长期质量

如果企业只是机械地把这类岗位缩编，或者让 1 个 PO 覆盖原来 5 个团队，最后常见结果不是“效率更高”，而是产品质量和业务结果一起下滑。

用“不可约复杂度”判断哪些工作难以被替代

另一个更贴近知识工作的框架，是 Irreducible Complexity Index，IRX。它关注五种“天然抗自动化”的工作特征：

• Being there（Physical Situatedness）：是否需要人在特定场景中实时感知和行动
• Making hard calls（Contested Success）：是否需要在高风险、存在争议的情境下做决定并承担结果
• Combining across fields（Multi-Domain Entanglement）：是否需要同时整合多个彼此强相关的领域
• Solving the genuinely new（Genuine Novelty）：是否经常面对全新问题，而不是套用既有解法
• Taste（Aesthetic Judgment）：是否依赖“什么算好”这类无法完全被规则或指标定义的判断

产品经理虽然没有被直接列入这个模型的职业示例，但大概率会落在 高 IRX 的知识工作者 区间。这意味着：

• 工作不是纯流程化的
• 很多价值来自判断，而不是执行
• 不少任务没有标准答案
• 决策后果需要有人负责

这类岗位不容易被彻底替代。

相对地，偏交付支持的 PO 在这五个维度上的分数可能更低，因此结构性风险更高，但通常也还没有低到会像会计、合规这类强流程岗位那样直接暴露。

职责会不会被别的角色吸收？

结论：会发生，而且已经在发生，但这不等于产品工作消失。关键不在岗位名称，而在谁能把这份工作真正做完。

现在流行的说法是“full-stack builder”：一个人同时覆盖工程、设计和产品。沿着这个思路，很多人进一步推演：既然 AI 已经能补足很多技能短板，那设计师、工程师、创始人、管理者就可以顺手把产品经理的活也做了。

这类推演并非完全没有现实基础。早在生成式 AI 爆发之前，就已经有一些公司长期没有设立传统意义上的专职产品经理，产品职责由创始人、高级管理者、设计师和工程师共同承担。

但有一点必须说清：取消岗位，不等于取消工作。

无论组织图怎么改，下面这些事总得有人做：

• 市场研究
• 战略制定
• 优先级排序
• 需求定义
• 实验验证
• 跨团队协调
• 结果衡量

真正的问题是：谁来做，做得怎么样，能不能持续做。

哪些团队适合弱化产品经理角色？

没有专职 PM 的模式，只在特定条件下容易成立：

如果这些条件不成立，强行去 PM 化，常见结果是产品工作被隐性转嫁：

• 工程师做了额外的产品判断，但没人承认这是 PM 工作
• 设计师承担了用户研究和方案定义，但没有足够决策权
• 经理和创始人做了大量优先级决策，但缺少稳定机制

从账面上看，像是少了一个岗位；从实际运行看，只是把工作拆散了，而且未必更高效。

AI 也可能让产品经理更值钱

另一面同样成立：AI 不只是在削弱产品经理，也在强化产品经理。

借助 AI，产品经理已经可以更直接地参与很多过去要依赖他人的工作：

• 快速做原型
• 组织和分析用户研究
• 辅助撰写甚至贡献生产级代码
• 生成分析框架、实验方案、规格初稿
• 提高跨角色沟通效率

所以组织未必会得出“不要 PM”的结论，也可能得出相反结论：更强的 PM 能覆盖更多关键链路，反而更值得配置。

一些 AI 原生公司仍在大量招聘 PM，就是这个逻辑。因为当工程端构建速度变快后，“该做什么、不该做什么、先做什么”的价值会进一步放大。

角色收敛更可能是局部的，而不是彻底合并

现实里更常见的，不是所有岗位彻底并成一个人，而是出现不同程度的 partial convergence：

• 开发负责人兼任代理 PM
• PM 同时承担一部分设计工作
• 设计师深度参与需求定义
• 创始人直接担任产品 owner

真正的“一人公司式全收敛”会因为 AI 变得更容易，但对大多数企业来说仍然是少数情况。

所以比起争论岗位标题，不如讨论一件更实际的事：在当前业务、组织和团队能力约束下，产品工作怎样分配最合理。

AI 提升效率后，企业会需要更少的产品经理吗？

结论：不能简单推出“效率更高，所以 PM 更少”。前提是先定义什么叫产品经理的效率，而这件事本身就很难。

很多管理者和 CFO 会偏爱这个理论，因为它听上去很整齐：AI 能让 1 个 PM 支持更多团队，于是企业自然可以少招 PM。

问题在于，这个推理通常建立在错误的“产出指标”上。

用输出衡量 PM，往往会得出错误结论

如果把产品经理效率定义成：

• 提了多少 ticket
• 写了多少 PRD
• 产出了多少 user story
• 跟进了多少需求项

那么 AI 的确能把这些数字迅速拉高。

但这和用代码行数衡量工程师效率一样，经常会把团队带偏。因为这些只是产品活动的表层产物，不是价值本身。

产品经理真正关键的贡献，往往发生在更靠前的位置：

• 识别问题而不是堆方案
• 选择值得做的方向
• 在不确定中做取舍
• 判断优先级
• 验证假设
• 控制机会成本
• 让团队构建“正确的东西”

如果这些判断出了问题，AI 生成再多规格文档，只会更快地把错误产品送进研发。

工程更快之后，“决定做什么”反而更重要

一个容易被忽略的变化是：AI 提高了构建速度，也抬高了决策质量的重要性。

当工程团队生成代码、搭建原型、推进实现的速度越来越快时，组织的瓶颈会逐渐从“做得出来吗”转向“该做什么”。

也就是说：

• build cost 在下降
• wrong build cost 可能在上升

因为错误决策会被更快执行，浪费也会被更快放大。

这正是产品管理价值上升的地方。不是因为要写更多文档，而是因为需要更高质量的判断。

PM 的能力模型本来就不容易量化

产品经理职业发展体系里，常见的评价维度包括：

• Leadership
• Impact
• Scope
• Execution
• Communication
• Vision
• Strategy
• Collaboration
• Planning
• Technical skills

这些维度大多偏定性，而且彼此交织。它们并不像客服工单处理量那样容易被标准化计数。

AI 的确可以帮助产品经理在这些方面做得更好，但很难直接换算成“一个 PM 现在等于过去 X 个 PM”。这种线性推导通常过度简化了现实。

顺带一提，经济学上也一直存在争论：生产率提升究竟会不会直接减少岗位数量。价格弹性、Devon’s effect 等问题都说明，这件事远没有“更高效率=更少岗位”那么直接。

更现实的风险是不是岗位市场本身收缩？

结论：这是四种路径里最值得严肃对待的一种。

如果说前三种更多是在讨论“AI 如何改变产品经理工作”，第四种讨论的则是另一件事：即便岗位本身没有被技术替代，市场也可能因为 AI 泡沫、资本回撤和行业收缩而变差。

这条路径之所以更现实，不是因为它一定会发生，而是因为历史上这种模式反复出现过。

为什么 AI 泡沫风险会影响 PM 就业？

目前已经能看到一些信号：

• 一些 AI 公司估值偏高
• 面向基础设施的多万亿美元级投入未必都能得到合理回报
• 金融市场对 AI 主题集中度较高，风险暴露明显
• 对“AI 会带来巨量生产率提升”的说法，质疑声并不少

如果市场情绪转冷，进入 Gartner 所说的 trough of disillusionment，可能出现的链式反应是：

1. VC 冻结或回撤投资
2. 二级市场抛售 AI 相关股票，之后外溢到更广泛科技板块
3. 企业客户削减 AI 采购，继而削减更大范围的技术支出
4. AI 公司，尤其是创业公司，现金流承压甚至关闭
5. 整个科技行业跟着缩编，非 AI 公司也会裁员或收缩

这种情况下，PM 失业并不是因为“AI 已经会做 PM 的工作”，而是因为公司本身活不下去，或者统一削减 headcount。

历史上类似的冲击有多大？

2000 年互联网泡沫破裂后，大约损失了 40 万个 IT 岗位。IT 行业失业率从 2000 年的 2.2% 上升到 2002 年峰值 6.3%，技术就业市场花了 3 到 4 年才逐步恢复。

今天科技行业体量更大，AI 投入规模也更高，因此一旦发生泡沫破裂，冲击可能更大。
当然，市场环境和当年也不完全一样，所以不能机械类比，也不能直接断言一定会崩。

眼下已经能看到一些“归因于 AI”的裁员，但很多情况更接近另一种逻辑：大公司为了挪出预算去投数据中心和 AI 芯片，先在别处压缩成本。到目前为止，还看不到明确的全面崩盘迹象。

个人和团队现在该怎么应对？

结论：与其焦虑岗位标题，不如提高自己在“定义正确问题、推进正确决策、交付真实结果”上的价值密度。

如果要把这四种路径对应到实际行动，可以分成团队层面和个人层面。

团队层面该怎么判断

先回答几个实际问题：

1. 团队里的产品工作，究竟由谁承担？
2. 这些人是否真的具备市场、策略、优先级、实验和结果分析能力？
3. AI 是在补强判断，还是只是在加速文档生产？
4. 如果减少 PM，哪些隐性工作会掉地上？
5. 当前业务的瓶颈，是“做不出来”，还是“做错了”？

如果瓶颈主要在方向判断、跨部门协调、复杂利益平衡，那么 PM 价值通常不会下降，反而会更明显。
如果岗位本身长期被压缩成“写需求、管 backlog、跟排期”，那它自然更容易被 AI 或其他角色吞掉。

个人层面该怎么做

更稳妥的方向有三个：

• 减少对高风险公司的暴露

  • 尽量从高波动、下一代概念项目，转向现金流更稳、需求更确定的业务
  • 这不能保证安全，但能降低单点风险

• 让自己的贡献更接近业务结果

  • 尽量把工作与收入、留存、增长、成本、效率等结果建立联系
  • 这对 PM 不容易，但非常重要

• 拓宽并加深产品能力

  • AI 工具使用能力
  • 用户研究
  • 数据分析
  • 原型和实验设计
  • 技术理解与一定的代码能力
  • 战略和优先级判断
  • 跨团队影响力

真正更有防御性的，不是“会不会写 prompt”，而是在 AI 加速执行的环境里，仍然能持续做出更好的产品判断。

最终该怎么看待“PM 已死”这类论断？

结论：这类说法大多过度简化。产品经理岗位会演化，但远没到“自然死亡”的程度。

为什么类似判断会反复流行？原因通常有几类：

• 有人本来就不认同产品管理这个角色
• 有人借“AI 消灭某岗位”吸引注意力
• 有人只是重复当下流行的说法

但现实比口号复杂得多。

AI 当然会改变产品经理的工作方式，也会迫使很多团队重新分配职责边界。一些偏低维度、偏交付支持的岗位，确实会承受更大压力。部分组织会尝试去 PM 化，部分组织会让 PM 更深地介入设计、研究甚至工程。

这些变化都是真的。

但更本质的事实没有变：只要组织还需要判断市场机会、定义问题、做优先级取舍、协调执行并对结果负责，产品工作就不会消失。
在好的公司里，随着构建速度提高，决定“该做什么”的价值往往只会更大。

比起追逐“岗位会不会消失”的情绪化结论，更值得做的是两件事：

• 盯住技术和市场趋势，但别被热词带着跑
• 持续把能力押注在高价值判断和真实结果上

关于

关注我获取更多资讯

📢 公众号

💬 个人号