产品岗位先被改写的，是工作重心

如果只看表面，产品经理确实像是最容易被生成式 AI 吃掉的一类角色。写需求文档、整理调研、做竞品分析、提炼会议纪要、输出用户故事，这些工作天然都是文本密集型任务，而文本恰好是大模型最先表现出高效率的领域。

也正因为如此，外界很容易把「AI 很会写文档」直接推成「产品经理会被替代」。但这个判断少看了一层。产品经理工作里最稀缺的部分，本来就是定义目标、处理冲突、决定边界，以及把「看起来都可以做」的东西压成一个团队真的能执行的顺序。

文档并不是产品经理最深的壁垒

Anthropic 在讲 eval 的文章里有一个很重要的信号：最靠近用户和流程的人，往往最适合定义评测任务。OpenAI 在 agent 指南里也不断强调，系统效果很大程度取决于指令、工具和人类介入设计。这两件事合在一起，几乎已经把 Agent 时代产品经理的新位置说清楚了。

产品经理最值钱的地方，重点是能回答几类更关键的问题。

  • 这个系统到底算成功了什么，失败了什么。
  • 它可以替用户做哪些事，哪些事绝对不能做。
  • 它什么时候应该自动前进，什么时候必须停下来问人。
  • 面对模糊需求、异常输入和相互冲突的目标时，哪个优先级更高。

这些东西都可以被写成文档，但它们本质上「目标与边界设计」。

Agent 产品会把产品经理往哪里推

一旦产品开始变成带工具、带循环、带审批的 Agent 系统，产品经理的职责会很明显地往三个方向上移。

  • 从写需求，转向定义成功。要把模糊目标压成样例、验收条件、拒绝条件和恢复路径。
  • 从列功能，转向画边界。要定义系统能动什么、不能动什么、需要谁确认、日志留到哪里。
  • 从交付页面，转向交付工作流。要关心的不再只是一个 UI，而是一条任务链怎么被执行、被中断、被复核。

这也是为什么我越来越不愿意把这类角色叫「会写 PRD 的产品经理」。更贴切的说法，可能是「Agent PM」或者「success definition owner」。

哪类产品经理会更早感到挤压

如果要说哪类产品经理最容易被 AI 冲到，答案也很清楚：把主要价值长期放在文档加工、会议转述、需求搬运和跨团队传话上的人。

因为这些工作虽然很辛苦，但它们的共同问题在于，目标和责任链往往都不够清楚。它们更像围绕流程运转的中介劳动，而不是围绕结果负责的判断劳动。AI 一旦能稳定生成概要、拆任务、统一格式、整理信息，这类价值就会迅速被稀释。

反过来，那些真正理解用户目标、知道业务冲突在哪里、会把系统边界写成可执行约束的产品经理，不但不会先消失，反而会变得更关键。因为系统越自动，团队越需要有人对「什么叫成功」负责。

产品经理不会先消失，但会先上移

我的倾向判断是：产品经理不会先被取代，产品经理会先被改写。被压缩的是「文档生产者」和「需求搬运工」这层角色；被抬高的是定义目标函数、设计审批节点、维护 eval 集、解释系统边界的人。

所以判断一个产品经理会不会在这轮变化里上移，最有用的问题也许「他能不能把一个含混目标，压成 Agent 和团队都能执行、都能验收、都能追责的工作流」。能做到这件事的人，不会被轻易替代。

更新附注

  • 版本：v1.1

更新日期：2026-04-01 更新原因：重写标题、首屏判断与结尾收束，把文章焦点进一步收拢到「成功定义与边界设计」这一岗位迁移方向。