代理时代的现代 AI PM（译）

代理时代的现代 AI PM （译）

PM 的工作，过去本质上是一层“翻译”。

你和客户沟通，整理他们的问题，写需求文档，然后交给工程师。 你是连接“人们需要什么”和“最终被构建出来的东西”之间的桥梁。 价值，就存在于这层翻译之中。

而这层翻译，正在被压缩。

当智能代理可以直接接收一个结构良好的问题，并产出可运行的代码时，PM 的工作开始发生变化。 你不再是为工程师做翻译的人。 你要做的，是把“意图”表达得足够清晰，让代理可以直接对其采取行动。

Spec，正在变成产品本身。

Image

我在自己身上、以及几十位 PM 同行身上，看到了这一变化。 过去，一个 PM 会写一份详尽的需求文档，交接出去，等待问题反馈，反复澄清，等待实现，评审，给反馈，再迭代。 这个周期通常以“周”为单位。

现在，PM 写的是一个清晰的问题定义，加上约束条件，把代理指向它，然后在一小时内评审一份可运行的代码。

从“我知道该做什么”，到“它已经在这了”，中间的时间被压缩了。 但“知道该做什么”这件事，并没有变简单。 它变得更加重要了。

你不需要亲自写代码。 你需要把你想要的东西想清楚，清楚到代理可以直接把它构建出来。

Spec和原型，正在合二为一。 你描述你想要什么，看着它成形，进行修正，再迭代。 瓶颈不再是实现。

而交付速度，只会越来越快。

我在 Google 只待了大约 3–4 个月，却感觉我们已经发布了好几年的 AI 进展。 仅在这段时间里：Gemini 3 Pro 和 Flash、多模态实时 API、Nano Banana Pro、Deep Research Agent、Google Interactions API、ADK Java / Go / TypeScript，还有更多。

几乎所有规模的 AI 公司，都在以这样的速度发布产品，背后原因正是 AI 编码代理。 曾经定义产品开发节奏的周期——季度规划、月度冲刺、每周发布——正在被压缩成更接近“持续部署想法”。

当实现门槛下降得如此之快，瓶颈自然会向上游移动。 稀缺资源，不再是工程能力。 而是：到底什么值得被构建。

新的 PM 技能栈

问题塑形（Problem shaping）我认识的最优秀 PM，一直都擅长这一点。 但过去，它只是众多技能之一。 现在，它是唯一真正关键的技能。

你能否把一个模糊的客户痛点，塑造成一个足够清晰的问题，让一个代理，或一组代理，能够直接行动？ 你能否识别出真正重要的约束？ 你能否清楚地说明，什么才算成功？

Spec不再是一份文档。 它是一个边界清晰、结构完整的问题。

上下文策展（Context curation）这是几乎没人谈论，但每一个能高效使用代理的 PM 都已经掌握的能力。 代理产出质量，与你提供的上下文质量，几乎成正比。

我刚开始使用代理时，给的提示非常模糊： “帮我做一个客户反馈的仪表盘。”

得到的结果“技术上可用”，但完全偏离重点。 它不理解我们的用户、我们的限制条件，也不理解对我们而言什么才算“好”。

现在，我会在每个项目开始前，维护一套上下文文档，先喂给代理。 随着实践增多，我逐渐明确了这些文档中真正重要的内容：

用户本身。不是用户画像，而是真实的人：他们是谁，在意什么，什么时候会放弃，什么时候会被吸引注意力。

问题，用他们自己的话描述。直接来自电话、工单或销售记录的原话。用他们的语言，而不是你的总结。这能让代理锚定真实的痛点，而不是被抽象化后的痛点。

什么是“好”。团队认为设计良好的例子。你们过去的作品、竞品、相邻产品。展示出来，而不是描述。

你已经尝试过什么，以及为什么失败。通常只存在于人脑中的组织记忆。被否定过的方案，以及否定的原因。

塑造解决方案的关键约束。不需要所有约束，只要那些真的会改变结果的。

你将如何判断它是否成功。具体、可观察、可衡量，而不是模糊感受。

当我现在让代理做原型时，它并不是从零开始。 它知道我们为谁构建，用户实际说过什么，什么是好，什么已经失败过。 输出之所以贴合，是因为输入足够具体。

评估与品味（Evaluation and Taste）品味被严重低估了。 但当代理可以高速、大规模地产出内容时，它反而成了最重要的能力。

这是否真的解决了问题？ 是否覆盖了真正重要的边界情况？ 这是我们应该发布的版本，还是只是一个“能跑”的版本？

这比听起来要难。 代理会非常自信地生成“看起来正确”，但本质上完全偏题的东西。 你需要足够多的实践，才能形成判断力。

没有捷径。 你必须亲自构建、评估、反复感受，才能区分 “已经好到可以上线” 和 “只是技术上成立”。

心智模型的转变

我现在是这样理解的：

旧模型： PM 想清楚做什么 → 写需求 → 工程师实现 → PM 评审 → 迭代

新模型： PM 想清楚做什么 → PM 用代理把它做出来 → PM 评估 → 快速迭代 →（满意后）交给工程师上线到生产环境

AI PM 不再只是交付需求。 他们自己完成第一版的“感觉”，并基于真实可运行的软件获取反馈，而不是 PPT 或 Figma。

工程师的角色，更多变成了协作者： 让产品更好、更稳、更可上线，而不是替你翻译意图。

你与产品的关系发生了变化。 你不再是描述想要什么，然后祈祷它被正确实现。 你是在实时塑造它。

用迭代的方式思考。 允许第一版是错的。 不要试图在开始之前就在脑中把一切想完美。

先给代理足够丰富的问题上下文。 让它给出一个粗糙的第一版。 看看结果。 回应它。 继续迭代。

你会从“这不太对，因为……”中，学到远比提前穷举边界情况更多的东西。

我经常让代理并行构建两到三个完全不同的方案，只是为了看看哪个在我实际使用时“感觉对”。 过去这很昂贵。 现在，这只是一个普通的周二下午，加上几个并行代理。

延长不确定性的存在时间。 过去 PM 的本能，是尽快把模糊压缩成 Spec。 现在的本能，是在探索阶段停留得更久。 不要过早收敛到某个方案。 让代理先帮你理解整个解空间，再做承诺。

如何开始

如果你是一个还没这样工作过的 PM，可以从这里开始：

选一个你真实存在的小问题。不是虚构的。是此刻正在困扰你的。 一个需要手动整理的报告。 一个很烦的流程。 一个你希望存在的原型。

在提示代理之前，先花 30 分钟写上下文。 完整清单见上面的“上下文策展”。

把代理指向它，看看会发生什么。 不要期待完美。 期待一个起点。 对它作出反应，引导它，迭代。

做十次。 不同的问题。 不同的复杂度。

你会形成一种直觉：什么有效，什么上下文重要，如何评估输出。 这种直觉，就是新的 PM 核心能力。

能真正成长起来的 PM，是那些对问题理解得足够清晰，以至于解决方案对他们、也对代理而言，都变得显而易见的人。

我会根据任务在 AI Studio、Cursor、Antigravity 和 Claude Code 之间切换。 工具本身没那么重要。 重要的是每天与代理协作，建立这块肌肉。

最后，留给你一个问题。

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

如果你的工作是： “把问题理解得足够深，以至于正确的解决方案自然浮现”， 那你的价值比以往任何时候都更高。

代理只是把这种理解，放大成产品交付的速度，远超任何传统团队。

每一个 PM 都应该问自己一个问题： 当翻译层消失之后，还剩下什么？

对最优秀的 PM 来说，答案是： 一切真正重要的东西。

理解问题。 用户共情。 判断力。 品味。

这些一直都是 PM 工作的一部分。 现在，它们正在变成全部。