AI 指数时代的产品管理：PM 如何驾驭快速演进的模型智能

从 21 分钟到 12 小时：一场 41 倍的跨越

2024 年 10 月，我养成一个习惯：每当新版 Claude 模型发布，就用 Claude Code（当时还是内部工具）让 AI 在 Excalidraw 中添加一个表格工具。

每次新版模型发布，AI 都能做得更远一些，但始终无法完全成功。

然后，2025 年 6 月 Opus 4 发布，AI 开始偶尔成功——成功到我们把它录制成 Claude 4 模型发布的演示视频。

不到一年后，Opus 4.6 已经能在几秒钟内可靠地完成 Excalidraw 的功能请求，我们敢于在数千名专业开发者面前现场演示。

这就是模型进步的速度。

传统 PM 剧本正在失效

传统产品管理 playbook 建立在一个假设上：项目开始时技术上能做到的事情，与项目结束时大致相同。

PM 们会在前期收集足够的信息，对未来做出有把握的赌注，然后在接下来的几个月里按计划执行。

但指数级提升的模型打破了这个假设。

你设计时围绕的约束可能在项目中期就消失了。你脚下的大地在不断上升，团队需要围绕这个现实重新组织。

新的产品管理节奏是：快速实验、持续发布、押注有效的方法。

我的 AI 原生 PM 之旅

我的职业生涯始于 Scale AI 和 Dagster 等创业公司的产品工程师，后来成为风险投资人——在那个角色中，我仍然写代码来自动化工作中繁琐的部分，比如扫描 X 获取新公司发布动态，或检测开源项目何时获得关注。

2024 年 8 月，我加入 Anthropic 成为研究 PM 团队的 PM，连接研究团队和真实客户，以交付更好的模型。

当 Claude Code 那年秋天在内部可用时，我用它来加速工作中更手动化的部分——包括构建 Streamlit 应用来分析大规模用户反馈，运行评估来帮助公司找到可以信任的新基准。低门槛的构建意味着我可以探索远超我日常角色的东西，比如创建 RL 环境来更好地理解训练。

这些项目花费了数百小时的提示工程，但没有一行代码是手写的。

我的 AI 协作工作流

Claude Code 和 Cowork 等工具正在模糊产品开发生命周期中不同角色之间的界限。

我的工作流横跨三个产品：

工具	用途
Claude.ai	作为思维伙伴与 Claude 交谈，不需要它采取行动。讨论策略文档、如何处理棘手情况、获取快速答案
Claude Code	构建原型、评估和脚本，很多调用 Claude API。当输出是代码时使用
Cowork	处理其他一切：从零收件箱、追踪和执行待办事项、创建幻灯片、理解 Slack 中某段历史、预订工作旅行

行业 PM 的真实体验

“Claude 提高了优秀产品团队能构建的上限，并大大缩短了从想法到原型的时间。把有形的东西放到客户面前过去需要数周的构建。现在我先在 Claude Cowork 中开始，从 Slack、代码库和文档中拉取上下文，然后进入 Claude Code，在几个小时内就能做出可演示的东西。优秀的产品团队总是用真实客户测试他们的想法，这种直觉没有改变。改变的是我们实际上可以通过循环的高质量想法数量。”

— Bihan Jiang，Decagon 产品总监

“对我来说，在 AI 原生世界做 PM 既是创意工作也是学术工作。每个新模型版本都会改变可能性，我们在构建 Datadog 的 Bits AI SRE agent 时，通过对真实生产事件的离线评估来研究其优势和失败模式。我们还设计紧密的反馈循环，改进 UX 以暴露 agent struggles 的地方，并将这些洞察转化为产品改进。从这个意义上说，PM 的技艺已从前置定义确定性转变为加速发现。”

— Kai Xin Tai，Datadog 高级产品经理

拥抱 AI 指数曲线的四个转变

1. 短周期计划

传统 PM 思维将探索视为路线图锁定之前发生的事情。你做研究、写 PRD，然后交给工程团队构建。

我们用**Side Quest（支线任务）**代替长期路线图。支线任务是一个简短的自我指导实验，在你的官方路线图之外运行——花一个下午原型化一个想法、测试一个你以为超出范围的能力，或者只是看看当你推动模型超越预期时会发生什么。

Anthropic 最受欢迎的一些功能——Claude Code on Desktop、AskUserQuestion 工具和待办事项列表——就是这样诞生的。

2. 用演示和评估代替文档

我们的团队在很大程度上用原型优先思维取代了文档优先思维。我们不举办传统的站会，而是分享新想法的演示。内部用户尝试它们，有真正参与度的会被打磨并更广泛地分享。

因为你可以在一下午原型化，错误的赌注成本很低。

例如，当 Noah 与 Claude Code 分享他的插件规范时，返回的原型接近生产就绪。那个原型奠定了团队最终交付的基础，因为它使团队能够快速验证 UX。

技巧：写完规范后，发送给 Claude Code 看看它能否构建。即使是一个粗糙的原型也会改变对话。

3. 用新模型重新审视功能

现在，你发布一个功能，然后更好的模型出现，你的产品可能突然变得好得多。每个模型版本都是重新审视已构建内容的隐含提示。

最好的方法是成为每日活跃用户，并刻意要求它做你认为可能太难的事情。有时候它能成功——那是产品需要跟上的信号。

这就是 Claude Code with Chrome 发生的方式。我们注意到用户正在用 Claude Code 构建 Web 应用，然后手动切换到 Chrome 中的 Claude 来测试它。用户在这两个工具之间手动提示和复制粘贴指令。当这被内置为功能后，用户无需再手动拼接。

在原型化这些想法时，始终优先优化能力。使用比你认为需要的更多的 token。过早削减 token 成本是一个常见错误，可能会导致最终产品能力大打折扣。

4. 做简单的事

在 Anthropic，每个团队都有一条指导原则：做那个有效且简单的事。

如果你的产品巧妙地绕过模型限制，那个变通方法在下一个模型发布时会变得不必要。简单实现的价值在于：模型能力提升时，更容易替换新的能力。

当我们第一次在 Claude Code 中启动待办事项列表时，模型不能可靠地在完成时勾选项目。所以我们添加了系统提醒，每隔几条消息就会提示 agent 更新自己的待办事项列表。它有效，但是个 hack。下个模型发布后，这种行为自然出现了，我们完全移除了提醒。

我们看到这个模式反复出现：我们的系统提示和工具描述过去需要大量工程来补偿模型限制，我们能够在每个模型上减少提示，包括 Opus 4.6 减少了 20%。

数据说话：41 倍的跨越

根据 METR 的研究：

Sonnet 3.5 (new) 可完成人类约需 21 分钟的任务
Opus 4.6 可完成人类约需 近 12 小时的任务

16 个月内大约 41 倍的跳跃。

Claude Code 团队已经进化到与模型改进的速度保持同步。我们的角色正在融合：设计师写代码，工程师做产品决策，产品经理构建原型和评估。这之所以有效，是因为清晰的战略和目标让每个人都能自主优先排序。

PM 的工作是：在快速模型进步创造的模糊性中创造清晰，推动团队更大胆地思考可能性，清除通往更快速发布的障碍。

向前看

许多 PM 习惯于对完整产品体验有严格控制，但 AI 推动你放手才能走得快。在构建 AI 产品时，感觉就像冲浪——最重要的事情是保持在浪上。

作为一个完美主义者，这是我最难适应的转变。但 PM 的角色现在是：同时追踪两件事——AI 如何改变你的工作方式，以及它如何改变你产品中可能的事情。

做到这一点，你就不会在表格工具终于成功时而感到惊讶——你是那个预见它的人。

作者：Cat Wu，Anthropic Claude Code 产品负责人

来源：原文链接: https://claude.com/blog/product-management-on-the-ai-exponential

加载中...