只会写文档的产品经理没有未来，AI编程智能体正在终结“翻译官”时代
神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：翻译式PM已死：当执行成本被AI抹平，深刻的问题定义与独特的产品品味，成了职业唯一的护城河。文章来自编译。
上周，我写了写我是怎么用 AI 智能体（Agents）工作的。没想到，这篇文章发酵出一个更大的话题——关于产品经理（PM）这一角色本身正在发生的变革。
比如，“上下文策展”（context curation）如何变成了一项没人提起、但凡是高效人士都已掌握的技能。再比如，我是如何利用 AI Studio 和 Claude Code，在短短几个小时内将零散的创意转化为可运行的原型。
我在 X 上点击了发布，合上电脑，第二天醒来发现收到了成千上万条通知。
仅仅几个小时内，这篇文章就疯传开来。你们当中有很多人都产生了共鸣，分享了自己的故事，并进一步推动了这场讨论。
过去，产品经理的工作本质上是“翻译”。
你跟客户沟通，归纳他们面临的问题，编写需求文档（specs），然后交给工程师。你是“用户需求”与“实际产品”之间的桥梁。而 PM 的价值，就体现在这个翻译层级上。
而现在，这一层正在被压缩。
当智能体能够接收一个定义清晰的问题并生成可运行的代码时，产品经理的工作重心就转移了。你不再是为工程师做翻译，而是要将意图打磨得足够清晰，让智能体可以直接根据它来采取行动。
需求文档正在变成产品本身。
我在自己和几十位产品经理身上都看到了这种变化。以前，产品经理要写一份详尽的文档，交接下去，等待提问，进行澄清，等待开发，评审，给出反馈，再迭代。整个周期耗时数周。而现在，他们只需写下一份带有约束条件的清晰问题陈述，将其交给智能体，一小时内就能审阅运行中的代码。
从“我知道该做什么”到“东西做出来了”之间的时间差消失了。但“确定该做什么”的工作并没有变简单，反而变得更重要了。
你不需要亲自动手写代码，但你必须清楚地知道自己想要什么，清晰到智能体能够直接开发出来。需求文档与原型正合二为一。你只需描述需求，观察它成型，纠正偏差，然后迭代。瓶颈已不再是执行层面。
而且，产品发布的节奏只会越来越快。
我在 Google 工作了大概三四个月，感觉我们在这段时间里发布的产品抵得上过去几年的 AI 进展。仅在这个窗口期内，我们就推出了 Gemini 3 Pro 和 Flash、多模态实时 API（Multimodal Live API）、Nano Banana Pro、深度研究智能体（Deep Research Agent）、Google Interactions API、Java/Go/TypeScript 版本的 ADK 等等。
得益于 AI 编程智能体，大大小小的 AI 公司都在以这种速度推进。曾经定义产品开发的周期——从季度规划、月度冲刺到周度发布——正在被压缩成一种更接近于“创意的持续部署”的状态。
当实现的门槛下降得如此之快，瓶颈就开始向上游转移。稀缺资源不再是工程开发能力，而是判断哪些东西真正值得去做。
产品经理的新技能组合
问题塑造（Problem shaping）：我认识的最优秀的产品经理一直都很擅长这一点，但以前这只是众多技能中的一项。而现在，它是“核心”技能。你能不能把一个模糊的客户痛点塑造得足够清晰，让一个或一组智能体能够据此行动？你能不能识别出真正关键的约束条件？你能不能清晰地表达出成功的标准是什么？
需求文档不再是一份文件，而是一个边界清晰、定义良好的问题。
上下文策展（Context curation）：这是一项没人挂在嘴边、但每个擅长与智能体协作的产品经理都已掌握的技能。智能体产出的质量，与你喂给它的上下文质量成正比。
刚开始与智能体合作时，我会给出模糊的提示词：“帮我做一个客户反馈仪表盘”。我得到的东西在技术上行得通，但完全没抓到重点。因为它不了解我们的用户，不了解我们的限制条件，也不了解我们对“好产品”的定义。
现在，我会维护一份“上下文文档”，在开始任何项目前先喂给智能体。久而久之，我摸清了这些文档中真正关键的内容：
具体的、真实的用户。不是那种虚构的用户画像，而是真实的细节：他们是谁，他们在乎什么，什么会让他们放弃，什么会吸引他们的注意力。
用用户的话描述问题。直接引用通话记录、工单或销售记录。使用他们的语言，而不是你总结后的语言。这能让智能体锚定在真实的痛苦上，而不是抽象的痛苦。
定义什么是“好”。提供团队认为设计良好的案例。你过去的作品、竞争对手的产品或相关联的产品。直接展示，而不是单纯描述。
尝试过什么以及为什么失败。那些通常存在于人们脑海中的组织经验。你已经否决掉的方案以及原因。
塑造解决方案的约束条件。不是所有的限制，而是那些真正会改变产品最终形态的限制。
如何判断行得通。具体的，而非模糊的。一些你真正可以衡量或观察到的指标。
现在，当我要求智能体制作原型时，它不再是从零开始。它知道我们在为谁开发，知道用户到底说了什么，知道什么是好的标准，也知道哪些路已经走不通了。正因为输入的信息足够具体，输出的结果才能严丝合缝。
评估能力与品味：品味一直被低估了。但当智能体能够快速且大量地产出时，品味就成了最重要的技能。这真的解决问题了吗？它处理了那些关键的极端情况（edge cases）吗？这是我们应该发布的版本，还是仅仅是一个能跑起来的版本？
这比听起来要难。智能体会非常自信地生成看起来正确、实则南辕北辙的东西。你需要通过不断的练习（reps）来培养这种品味。
没有捷径：你必须亲自动手去开、评估，去感受“达到发布标准”与“技术上可行”之间到底有什么区别。
思维模式的转变
这是我现在的思考方式：
旧模式：PM 思考该做什么 → 编写文档 → 工程师开发 → PM 评审 → 迭代
新模式：PM 思考该做什么 → PM 配合智能体开发 → PM 评估 → 快速迭代 → (满意后) 交给工程师上线生产环境
AI 时代的产品经理不再只是移交需求。他们会自己进行第一轮迭代的“氛围编程”，在可运行的软件上获得真实反馈，而不是对着幻灯片或 Figma 原型指手画脚。工程师的角色也随之转变，他们不再是你意图的翻译者，而是成为了如何让产品更好、更具备生产就绪能力的合作者。
这改变了你与产品的关系。你不再是描述需求并寄希望于它能被正确实现，你是在实时地、直接地塑造它。
要有迭代思维。允许第一版是错的。不要试图在开始前就在脑子里把它想得完美无缺。给智能体提供丰富的背景信息，让它先打个草稿。看看产出，做出反应，然后迭代。比起试图提前想清楚每一个极端情况，你从“这儿不太对，因为……”中能学到更多。
我经常让智能体同时尝试两三种完全不同的方案，只为了在使用时感受哪一个最对路。以前这么做的成本很高，现在，这不过是周二下午开启几个并行智能体就能搞定的事。
对含糊容忍更长时间。过去 PM 的本能是尽快把模糊的想法转化成文档。现在的本能则是留在模糊地带进行探索。不要过早地锁定一个方案，在做决定之前，让智能体帮你充分理解可能的解决方案空间。
如何入门
如果你是一名尚未尝试这种工作方式的产品经理，可以从这里开始：
挑选一个你真正面临的小问题。不是那种虚构的问题，而是现在正让你心烦的事。比如一份必须手动汇总的报告，一个繁琐的工作流，或者一个你希望存在的原型。
在输入提示词之前，花 30 分钟写一份上下文。参考上文“上下文策展”部分的完整清单。
把智能体引向这个问题，观察会发生什么。不要指望完美，把它当作一个起点。对它做出反馈，引导它，不断迭代。
重复做十次。针对不同的问题，不同的复杂度。你会逐渐培养出直觉：什么样的方法有效，什么样的背景信息重要，以及如何评估产出。这种直觉就是产品经理的新技能。
那些能够脱颖而出的产品经理，一定是那些对问题理解得如此透彻，以至于解决方案对他们和他们所使用的智能体来说都显而易见的人。
我会根据任务在 AI Studio、Cursor、Antigravity 和 Claude Code 之间切换。工具本身并不重要，重要的是养成每天与智能体协作的习惯，锻炼这种“肌肉记忆”。
最后，送给各位一句话……
如果你的工作主要是将客户需求翻译成给工程师看的文档，那只是一个工作流。而工作流终将被自动化。
如果你的工作是“深刻地理解问题，以至于正确的解决方案会自然浮现”，那么你将比以往任何时候都更有价值。智能体会将这种深刻的理解转化为上线的产品，其速度远超以往任何团队。
每个产品经理都应该问问自己：当“翻译层”消失后，还剩下什么？
对于最优秀的产品经理来说，答案是：所有真正重要的东西。
理解问题、同理心、判断力、品味。这些一直是产品经理工作的一部分。而现在，它们正在变成工作的全部！
译者：boxi。
