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

AI 时代，产品经理的“翻译层”正在消失 AI 时代，产品经理的“翻译层”正在消失 Modified January 13 他在 Google 待了三四个月，感觉发布了几年份的东西：Gemini 3 Pro 和 Flash、Multimodal Live API、Nano Banana Pro、Deep Research Agent、ADK 的 Java/Go/TypeScript 版本……这个发布节奏，放在几年前是不可想象的。 幕后的英雄是 AI Coding Agent 。 规格书正在变成产品本身 PM 的工作模式分成新旧两种： 旧模式： PM 想清楚要做什么 → 写规格书 → 交给工程师 → 工程师实现 → PM 评审 → 反馈迭代。PM 的产出是文档，工程师的产出是代码。 新模式： PM 想清楚要做什么 → 直接用 Agent 做出原型 → 自己评估 → 快速迭代 → 满意了再交给工程师做成生产级系统。PM 的产出直接就是能跑的东西。 你发现关键变化了吗？ PM 不再是工程师的上游，而是变成了产品的第一个用户。 以前 PM 描述自己想要的，然后祈祷做出来的是对的。现在 PM 直接上手定义产品，实时看到效果。 规格书正在变成产品本身。 你写的描述足够清晰，Agent 就能直接做出来。中间那个"翻译"环节，被压缩了。 三项新技能 当实现不再是瓶颈，瓶颈就转移到上游——搞清楚该做什么。三个能力变得关键： 第一：定义问题 以前这是 PM 的技能之一，现在这是 唯一核心技能 。你能不能把一个模糊的用户痛点，变成一个清晰的、有边界的问题，清晰到 Agent 能直接上手做？ 这比听起来难得多。大多数时候，用户说的是“这个系统太难用了”，你得搞清楚：是哪里难用？是流程复杂还是界面混乱？是新手不会用还是老手嫌麻烦？“难用”这个词可以拆出几十种可能。定义问题，就是把这团乱麻理成一条线。 第二：上下文喂养 这是没人谈但每个高效使用 Agent 的 PM 都在做的事。 Agent 产出的质量，跟你喂给它的上下文质量直接挂钩。 早期用 Agent，随便写个提示“给我做个客户反馈的 Dashboard”，出来的东西技术上能跑，但完全没抓住重点。因为 Agent 不知道你的用户是谁、你的约束是什么、什么叫“好”。 想做得更好，可以维护一份“上下文文档”，每次启动项目前喂给 Agent。这里有一个框架，适用于任何需要和 AI 协作的场景： 1. 具体的用户 — 不是抽象的“用户画像”，而是真实的人：他们是谁，在意什么，什么让他们放弃，什么让他们眼前一亮。 2. 用户的原话 — 来自电话、工单、销售记录的直接引用。用他们的语言，不是你的总结。这能让 Agent 接触到真实的痛苦，而不是被抽象过的痛苦。 3. “好”长什么样 — 你团队认为设计得好的案例：自己过去的作品、竞争对手的、相邻产品的。给 Agent 看，而不是描述。 4. 你试过什么、为什么失败 — 那些通常只存在于人脑子里的经验教训，那些被你们毙掉的方案和毙掉的理由。 5. 真正影响方案的约束 — 不是所有约束，只是那些会实际改变产出的约束。 6. 怎么知道成功了 — 具体的、可衡量的、能观察到的标准，不是模糊的愿景。 这六个要素，就是把"PM 脑子里的隐性知识"显性化、结构化。喂给 Agent，它就不是从零开始，而是带着你的全部背景知识在工作。 第三：品味 当 Agent 能快速产出大量东西时，判断“这个能发布”还是“这个只是能跑”的能力就变得特别重要。 Agent 会很自信地产出看起来正确但完全跑偏的东西。你得有感觉，得有判断力。 怎么练？没有捷径，就是反复做、反复评估、反复学习什么叫“够好能发布”。 两个思维转变 除了技能，还有两个思维方式的改变。 第一个：让第一版是错的。 以前 PM 的习惯是先在脑子里想清楚，尽量把所有边界情况都考虑到，再开始做。现在可以反过来：给 Agent 足够的背景，让它先出一个粗糙的版本，看看出来什么，然后根据“这里不对，因为……”来迭代。 你现在可以让 Agent 同时做两三个完全不同的方案，看哪个用起来感觉更对。这在以前太贵了，现在不过是一下午让 Agent 并行跑几个任务的事。 第二个：延迟收敛。 以前 PM 的本能是尽快消除模糊性，尽快把问题收敛成明确的规格书。现在可以在探索阶段故意保持模糊，让 Agent 帮你理解解决方案空间，不要太早锁定方向。 因为试错成本低了，多探索反而更高效。 文章说的情况非常适用于科技公司、初创团队、原型验证阶段。在这些场景下，PM 用 Agent 快速出原型、快速迭代，确实能极大提效。 但对于传统企业、B2B 产品、合规要求高的领域，这个“翻译层”未必能消失。金融、医疗、政府项目，“规格书→评审→实现”的流程可能是法规要求的，不是效率问题。 另外还有来自组织层面的阻力。PM 直接产出原型，会改变 PM 和工程师的协作关系、权力关系。工程师会怎么看“PM 写的代码”？这种组织变革的摩擦，可能比技能学习更难解决。 翻译层消失后，剩下什么？ 当翻译层消失后，剩下什么？ 那些一直真正重要的东西：定义问题、用户共情、判断力和品味。 这些能力一直是 PM 工作的一部分，只是过去被大量的“翻译工作”稀释了。你花大量时间写文档、跟进度、开会澄清、来回沟通。现在这些被 Agent 压缩了，PM 终于可以把精力放在真正重要的事情上。 如果你的工作主要是把用户需求翻译成文档交给工程师，那是一个流程。流程会被自动化。 如果你的工作是把问题理解得如此深刻，以至于正确的解决方案变得显而易见，那你比以往任何时候都更有价值。 他在 Google 待了三四个月，感觉发布了几年份的东西：Gemini 3 Pro 和 Flash、Multimodal Live API、Nano Banana Pro、Deep Research Agent、ADK 的 Java/Go/TypeScript 版本……这个发布节奏，放在几年前是不可想象的。 幕后的英雄是 AI Coding Agent 。 规格书正在变成产品本身 PM 的工作模式分成新旧两种： 旧模式： PM 想清楚要做什么 → 写规格书 → 交给工程师 → 工程师实现 → PM 评审 → 反馈迭代。PM 的产出是文档，工程师的产出是代码。 新模式： PM 想清楚要做什么 → 直接用 Agent 做出原型 → 自己评估 → 快速迭代 → 满意了再交给工程师做成生产级系统。PM 的产出直接就是能跑的东西。 你发现关键变化了吗？ PM 不再是工程师的上游，而是变成了产品的第一个用户。 以前 PM 描述自己想要的，然后祈祷做出来的是对的。现在 PM 直接上手定义产品，实时看到效果。 规格书正在变成产品本身。 你写的描述足够清晰，Agent 就能直接做出来。中间那个"翻译"环节，被压缩了。 三项新技能 当实现不再是瓶颈，瓶颈就转移到上游——搞清楚该做什么。三个能力变得关键： 第一：定义问题 以前这是 PM 的技能之一，现在这是 唯一核心技能 。你能不能把一个模糊的用户痛点，变成一个清晰的、有边界的问题，清晰到 Agent 能直接上手做？ 这比听起来难得多。大多数时候，用户说的是“这个系统太难用了”，你得搞清楚：是哪里难用？是流程复杂还是界面混乱？是新手不会用还是老手嫌麻烦？“难用”这个词可以拆出几十种可能。定义问题，就是把这团乱麻理成一条线。 第二：上下文喂养 这是没人谈但每个高效使用 Agent 的 PM 都在做的事。 Agent 产出的质量，跟你喂给它的上下文质量直接挂钩。 早期用 Agent，随便写个提示“给我做个客户反馈的 Dashboard”，出来的东西技术上能跑，但完全没抓住重点。因为 Agent 不知道你的用户是谁、你的约束是什么、什么叫“好”。 想做得更好，可以维护一份“上下文文档”，每次启动项目前喂给 Agent。这里有一个框架，适用于任何需要和 AI 协作的场景： 1. 具体的用户 — 不是抽象的“用户画像”，而是真实的人：他们是谁，在意什么，什么让他们放弃，什么让他们眼前一亮。 2. 用户的原话 — 来自电话、工单、销售记录的直接引用。用他们的语言，不是你的总结。这能让 Agent 接触到真实的痛苦，而不是被抽象过的痛苦。 3. “好”长什么样 — 你团队认为设计得好的案例：自己过去的作品、竞争对手的、相邻产品的。给 Agent 看，而不是描述。 4. 你试过什么、为什么失败 — 那些通常只存在于人脑子里的经验教训，那些被你们毙掉的方案和毙掉的理由。 5. 真正影响方案的约束 — 不是所有约束，只是那些会实际改变产出的约束。 6. 怎么知道成功了 — 具体的、可衡量的、能观察到的标准，不是模糊的愿景。 这六个要素，就是把"PM 脑子里的隐性知识"显性化、结构化。喂给 Agent，它就不是从零开始，而是带着你的全部背景知识在工作。 第三：品味 当 Agent 能快速产出大量东西时，判断“这个能发布”还是“这个只是能跑”的能力就变得特别重要。 Agent 会很自信地产出看起来正确但完全跑偏的东西。你得有感觉，得有判断力。 怎么练？没有捷径，就是反复做、反复评估、反复学习什么叫“够好能发布”。 两个思维转变 除了技能，还有两个思维方式的改变。 第一个：让第一版是错的。 以前 PM 的习惯是先在脑子里想清楚，尽量把所有边界情况都考虑到，再开始做。现在可以反过来：给 Agent 足够的背景，让它先出一个粗糙的版本，看看出来什么，然后根据“这里不对，因为……”来迭代。 你现在可以让 Agent 同时做两三个完全不同的方案，看哪个用起来感觉更对。这在以前太贵了，现在不过是一下午让 Agent 并行跑几个任务的事。 第二个：延迟收敛。 以前 PM 的本能是尽快消除模糊性，尽快把问题收敛成明确的规格书。现在可以在探索阶段故意保持模糊，让 Agent 帮你理解解决方案空间，不要太早锁定方向。 因为试错成本低了，多探索反而更高效。 文章说的情况非常适用于科技公司、初创团队、原型验证阶段。在这些场景下，PM 用 Agent 快速出原型、快速迭代，确实能极大提效。 但对于传统企业、B2B 产品、合规要求高的领域，这个“翻译层”未必能消失。金融、医疗、政府项目，“规格书→评审→实现”的流程可能是法规要求的，不是效率问题。 另外还有来自组织层面的阻力。PM 直接产出原型，会改变 PM 和工程师的协作关系、权力关系。工程师会怎么看“PM 写的代码”？这种组织变革的摩擦，可能比技能学习更难解决。 翻译层消失后，剩下什么？ 当翻译层消失后，剩下什么？ 那些一直真正重要的东西：定义问题、用户共情、判断力和品味。 这些能力一直是 PM 工作的一部分，只是过去被大量的“翻译工作”稀释了。你花大量时间写文档、跟进度、开会澄清、来回沟通。现在这些被 Agent 压缩了，PM 终于可以把精力放在真正重要的事情上。 如果你的工作主要是把用户需求翻译成文档交给工程师，那是一个流程。流程会被自动化。 如果你的工作是把问题理解得如此深刻，以至于正确的解决方案变得显而易见，那你比以往任何时候都更有价值。 🔗 原文链接： https://mp.weixin.qq.com/s/V2HHzGP4... https://mp.weixin.qq.com/s/V2HHzGP4... 原创 宝玉 宝玉AI2026年1月13日 06:06 产品经理的核心工作是什么？ 在用户和工程师之间做翻译。 用户说“我想要一个能查看销售数据的东西”，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》，讲 AI 智能体时代 PM 角色的变化。