AI 时代，产品经理的“翻译层”正在消失

产品经理的核心工作是什么？在用户和工程师之间做翻译。用户说“我想要一个能查看销售数据的东西”，PM 翻译成“需要一个包含 X、Y、Z 功能的 Dashboard，要有筛选器、图表、导出功能……”然后工程师照着做。

随着 AI 能力的进化，这个“翻译层”正在坍塌。

以前，PM 写完一份详细的规格书，交给工程师，等问题、澄清、等实现、评审、反馈、迭代。一个周期下来，几周就过去了。现在呢？他们写一个清晰的问题描述加约束条件，让 Agent 去做，一小时后就能看到能跑的代码。

工作效率从周变成了小时，这不仅是效率提升，更会带来工作方式的根本变化。

说翻译层正在坍塌的不是我，我自己不是 PM，不过和 PM 打交道很多。说这话的人叫 Shubham Saboo，Google Cloud 的高级 AI 产品经理，负责 ADK、Agent Builder、Agent Engine 这些产品，不是只会写 PPT 的传统 PM，也是个能写代码的技术实践者。。他最近写了一篇文章《The Modern AI PM in the age of Agents》（🔗 x.com/Saboo_Shubham_/article/2008742211194913117 🔗），讲 AI 智能体时代 PM 角色的变化。

他在 Google 待了三四个月，感觉发布了几年份的东西：Gemini 3 Pro 和 Flash、Multimodal Live API、Nano Banana Pro、Deep Research Agent、ADK 的 Java/Go/TypeScript 版本……这个发布节奏，放在几年前是不可想象的。

幕后的英雄是 AI Coding Agent。

【1】规格书正在变成产品本身

PM 的工作模式分成新旧两种：

旧模式是这样的：PM 想清楚要做什么 → 写规格书 → 交给工程师 → 工程师实现 → PM 评审 → 反馈迭代。PM 的产出是文档，工程师的产出是代码。

新模式变了：PM 想清楚要做什么 → 直接用 Agent 做出原型 → 自己评估 → 快速迭代 → 满意了再交给工程师做成生产级系统。PM 的产出直接就是能跑的东西。

你发现关键变化了吗？PM 不再是工程师的上游，而是变成了产品的第一个用户。

以前 PM 描述自己想要的，然后祈祷做出来的是对的。现在 PM 直接上手定义产品，实时看到效果。

规格书正在变成产品本身。你写的描述足够清晰，Agent 就能直接做出来。中间那个“翻译”环节，被压缩了。

【2】三项新技能

当实现不再是瓶颈，瓶颈就转移到上游——搞清楚该做什么。三个能力变得关键：

第一个叫“定义问题”。

以前这是 PM 的技能之一，现在这是唯一核心技能。你能不能把一个模糊的用户痛点，变成一个清晰的、有边界的问题，清晰到 Agent 能直接上手做？

这比听起来难得多。大多数时候，用户说的是“这个系统太难用了”，你得搞清楚：是哪里难用？是流程复杂还是界面混乱？是新手不会用还是老手嫌麻烦？“难用”这个词可以拆出几十种可能。定义问题，就是把这团乱麻理成一条线。

第二个叫“上下文喂养”。

这是没人谈但每个高效使用 Agent 的 PM 都在做的事。Agent 产出的质量，跟你喂给它的上下文质量直接挂钩。

早期用 Agent，随便写个提示“给我做个客户反馈的 Dashboard”，出来的东西技术上能跑，但完全没抓住重点。因为 Agent 不知道你的用户是谁、你的约束是什么、什么叫“好”。

想做得更好，可以维护一份“上下文文档”，每次启动项目前喂给 Agent。这里有一个框架，适用于任何需要和 AI 协作的场景：

一是具体的用户。不是抽象的“用户画像”，而是真实的人：他们是谁，在意什么，什么让他们放弃，什么让他们眼前一亮。

二是用户的原话。来自电话、工单、销售记录的直接引用。用他们的语言，不是你的总结。这能让 Agent 接触到真实的痛苦，而不是被抽象过的痛苦。

三是“好”长什么样。你团队认为设计得好的案例：自己过去的作品、竞争对手的、相邻产品的。给 Agent 看，而不是描述。

四是你试过什么、为什么失败。那些通常只存在于人脑子里的经验教训，那些被你们毙掉的方案和毙掉的理由。

五是真正影响方案的约束。不是所有约束，只是那些会实际改变产出的约束。

六是怎么知道成功了。具体的、可衡量的、能观察到的标准，不是模糊的愿景。

这六个要素，就是把“PM 脑子里的隐性知识”显性化、结构化。喂给 Agent，它就不是从零开始，而是带着你的全部背景知识在工作。

第三个叫“品味”。

当 Agent 能快速产出大量东西时，判断“这个能发布”还是“这个只是能跑”的能力就变得特别重要。

Agent 会很自信地产出看起来正确但完全跑偏的东西。你得有感觉，得有判断力。

怎么练？没有捷径，就是反复做、反复评估、反复学习什么叫“够好能发布”。

【3】两个思维转变

除了技能，还有两个思维方式的改变。

第一个：让第一版是错的。

以前 PM 的习惯是先在脑子里想清楚，尽量把所有边界情况都考虑到，再开始做。现在可以反过来：给 Agent 足够的背景，让它先出一个粗糙的版本，看看出来什么，然后根据“这里不对，因为……”来迭代。

你现在可以让 Agent 同时做两三个完全不同的方案，看哪个用起来感觉更对。这在以前太贵了，现在不过是一下午让 Agent 并行跑几个任务的事。

第二个：延迟收敛。

以前 PM 的本能是尽快消除模糊性，尽快把问题收敛成明确的规格书。现在可以在探索阶段故意保持模糊，让 Agent 帮你理解解决方案空间，不要太早锁定方向。

因为试错成本低了，多探索反而更高效。

文章说的情况非常适用于科技公司、初创团队、原型验证阶段。在这些场景下，PM 用 Agent 快速出原型、快速迭代，确实能极大提效。

但对于传统企业、B2B 产品、合规要求高的领域，这个“翻译层”未必能消失。金融、医疗、政府项目，“规格书→评审→实现”的流程可能是法规要求的，不是效率问题。

另外还有来自组织层面的阻力。PM 直接产出原型，会改变 PM 和工程师的协作关系、权力关系。工程师会怎么看“PM 写的代码”？这种组织变革的摩擦，可能比技能学习更难解决。

【4】翻译层消失后，剩下什么？

当翻译层消失后，剩下什么？

那些一直真正重要的东西：定义问题、用户共情、判断力和品味。

这些能力一直是 PM 工作的一部分，只是过去被大量的“翻译工作”稀释了。你花大量时间写文档、跟进度、开会澄清、来回沟通。现在这些被 Agent 压缩了，PM 终于可以把精力放在真正重要的事情上。

如果你的工作主要是把用户需求翻译成文档交给工程师，那是一个流程。流程会被自动化。

如果你的工作是把问题理解得如此深刻，以至于正确的解决方案变得显而易见，那你比以往任何时候都更有价值。