Claude 官方博客｜AI 指数级增长下的产品管理

来源: Claude 官方博客 | 作者: Cat Wu（Anthropic Claude Code 产品负责人） 发布日期: 2026-03-19 | 内容类型: 独白/博客文章 原始内容: 116 行 | 总结方法: 金字塔原理 + SCQA + 渐进式总结 本总结未使用 Shownotes 辅助信息

执行摘要

Cat Wu 以 Excalidraw 表格工具的模型测试为引子，论证了指数级进步的模型正在打破传统产品管理的核心假设——“项目开始时的技术可能性等于结束时的技术可能性”。她提出 AI 时代产品管理的新节奏：快速实验、持续交付、加倍投入有效方向。具体方法论包括四个转变：以短周期冲刺替代长期路线图、用演示和 eval 替代文档、每次模型升级重新审视已有功能、以及始终选择最简方案。她还分享了自己在 Claude.ai + Claude Code + Cowork 三工具之间形成的分工体系。

SCQA 框架

要素	内容
情境 (S)	AI 模型能力正以指数级速度提升——Sonnet 3.5 到 Opus 4.6，16 个月内 METR 任务完成能力跳跃约 41 倍
矛盾 (C)	传统产品管理建立在”技术可能性在项目周期内大致不变”的假设上，但模型指数级进步让项目中途的技术约束可能完全消失
问题 (Q)	在模型能力持续指数增长的环境下，产品团队应如何调整工作方式和决策逻辑？
答案 (A)	短周期冲刺、原型优先于文档、每次模型升级重新审视功能、做简单的事——让产品管理从”前期定义确定性”转向”持续加速发现”

核心论点结构

中心论点：指数级提升的模型打破了传统产品管理的核心假设，团队必须从”计划执行”模式切换到”快速实验、持续发现”模式。

传统 PM 方法论失效
- 传统方法假设技术可能性在项目周期内稳定，PM 前期做判断、后期执行计划
- 模型指数进步让”你围绕其设计的限制条件可能在项目进行到一半时就消失”
- Excalidraw 表格工具案例：从 Sonnet 3.5 失败 → Opus 4 偶尔成功 → Opus 4.6 可靠一次性完成，时间跨度不到两年
三工具分工体系重新定义 PM 工作流
- Claude.ai 用于思考碰撞（策略文档、棘手问题、快速问答）
- Claude Code 用于构建（原型、eval、脚本，输出为代码）
- Cowork 用于知识工作（邮件、待办、幻灯片、Slack 搜索、差旅预订）
- Cat Wu 此前数百小时的 Claude Code 项目”没有一行代码是手写的”
四个关键转变
- 以短周期冲刺替代长期路线图：鼓励”支线任务”（side quests），Claude Code on Desktop、AskUserQuestion、待办清单均由此诞生
- 用演示和 eval 替代文档：原型优先，错误赌注代价低；Noah 的 plugins 规格说明直接生成接近生产就绪的原型
- 每次模型升级重新审视功能：Claude Code with Chrome 就是发现用户在两个工具间手动复制粘贴后内建的功能
- 做简单的事：待办清单最初需要系统提醒 hack，下一个模型后行为开箱即用，hack 被移除；系统提示在 Opus 4.6 减少了 20%
角色融合与自主优先级
- 设计师提交代码，工程师做产品决策，PM 构建原型和 eval
- 清晰的战略和目标让每个人能自主确定优先级
- PM 的新角色：“在模糊性中创造清晰度，推动团队更大胆思考，扫清更快交付的障碍”

章节摘要

一、引言：Excalidraw 测试的演进

Cat Wu 用一个持续性的模型测试——让 Claude Code 为 Excalidraw 添加表格工具——展示模型进步的速度。从 Sonnet 3.5 每次失败，到 Opus 4 偶尔成功并做成预录演示，到 Opus 4.6 敢现场在数千名开发者面前演示。由此引出核心命题：传统 PM 方法论建立在技术可能性稳定的假设上，指数级模型进步打破了这个假设。

二、Cat Wu 的职业路径与 Claude Code

Cat Wu 从 Scale AI/Dagster 的产品工程师起步，转型为风险投资人（期间仍写代码自动化工作），2024 年 8 月加入 Anthropic 担任 Research PM。她用 Claude Code 构建了 Streamlit 分析应用、运行 eval、甚至创建 RL 环境，“数百小时的提示，没有一行手写代码”。

三、三工具分工的新工作流

形成了 Claude.ai（思考伙伴）、Claude Code（代码输出）、Cowork（知识工作）的自然分工。引用了 Decagon 产品总监 Bihan Jiang 和 Datadog 高级 PM Kai Xin Tai 的实践验证。

关键观点：

【Bihan Jiang】“Claude 提升了优秀产品团队能够构建的上限，并且大幅缩短了从想法到原型的距离”
【Kai Xin Tai】“PM 的技艺已经从前期定义确定性转向了加速发现”

四、拥抱 AI 指数级增长的四个转变

引用 METR 数据：Opus 4.6 能完成人类需近 12 小时的任务，16 个月内实现约 41 倍跳跃。提出四个转变：短周期冲刺（支线任务）、演示和 eval 优先于文档、每次模型升级重新审视功能、做简单的事。每个转变都配有 Claude Code 团队的具体案例。

五、展望未来

PM 需要同时追踪两件事：AI 如何改变工作方式，以及 AI 如何改变产品中的可能性。核心心态转变：从完美主义控制转向”识别少数不可妥协的事项，其余放手”。整个 Anthropic 组织（数据科学、金融、市场、法务、设计）都在用 Claude 工具，全组织同速运转。

关键洞察

“你是在不断升高的地面上建造东西” Cat Wu 用这个比喻描述模型指数进步对产品开发的影响——地基在变，围绕当前限制的设计可能随时过时，团队必须围绕这个现实重新组织。
支线任务（Side Quests）是创新的温床 不是正式的创新项目或 hackathon，而是鼓励每个人（工程师、PM、设计师）花一个下午做路线图之外的自驱实验。Anthropic 多个最受欢迎的功能由此诞生。
用户的拼凑就是产品的脚手架 当发现用户在两个工具间手动复制粘贴来完成任务时，这不是用户习惯，而是产品缺失的信号。Claude Code with Chrome 即由此而来。
始终优先优化能力，而非成本 过早削减 token 成本是常见错误，会导致交付能力大打折扣。“你总是可以在更便宜的模型跟上来后降低成本，但首先你需要知道这个功能到底是否可行。”
简单方案的自然淘汰效应 围绕模型限制的 hack 会在下一代模型中变得不必要。系统提示越简单，替换新能力时就越容易。Opus 4.6 的系统提示比前代减少了 20%。

可行建议

写完规格说明后立刻交给 Claude Code 构建原型：即使粗糙的原型也能改变讨论方向（来源：Cat Wu）
日活使用自己的产品，刻意测试”太难”的任务：模型能做到时就是产品需要跟上的信号（来源：Cat Wu）
建立三工具分工：思考用 Claude.ai，代码用 Claude Code，知识工作用 Cowork（来源：Cat Wu）
每次模型升级后重新审视已有功能：功能可能因模型进步而戏剧性提升（来源：Cat Wu）
做简单的事，不要过度工程化绕过模型限制：下一个模型可能让 hack 变得多余（来源：Cat Wu）

名言金句

“你是在一块不断升高的地面上建造东西，团队需要围绕这个现实重新组织。” — Cat Wu

“PM 的技艺已经从前期定义确定性转向了加速发现。” — Kai Xin Tai，Datadog 高级产品经理

“如果用户在拼凑什么东西，那就是你可以内建到产品中的脚手架。” — Cat Wu

“使用比你认为需要的更多的 token。过早削减 token 成本是一个常见错误。” — Cat Wu

“做简单且有效的事。你的实现越简单，在新能力到来时就越容易替换。” — Cat Wu

资源清单

人物/概念

名称	类型	提及语境
Cat Wu	人物	Anthropic Claude Code 产品负责人，本文作者
Bihan Jiang	人物	Decagon 产品总监，分享 Claude 工作流实践
Kai Xin Tai	人物	Datadog 高级 PM，分享 Bits AI SRE agent 构建经验
Noah	人物	Anthropic 团队成员，plugins 规格说明原型案例
Conner	人物	Anthropic 团队成员，agent teams eval 案例
METR	机构	测量前沿 AI 模型任务完成时间的研究机构
Side Quests（支线任务）	概念	路线图之外的短期自驱实验，Anthropic 的创新方法论

产品/工具

名称	提及语境
Claude Code	Anthropic 的智能编码工具，Cat Wu 日常使用
Claude.ai	聊天协作伙伴，用于思考碰撞
Cowork	知识工作工具（邮件、待办、幻灯片、Slack 搜索）
Excalidraw	用作模型能力测试的画布工具
Claude Code on Desktop	由支线任务诞生的功能
Claude Code with Chrome	由观察用户拼凑行为而内建的功能
Bits AI SRE agent	Datadog 构建的 AI SRE agent

本总结由 transcript-summarizer skill 生成 方法论：金字塔原理 (Minto) + SCQA + 渐进式总结 (Forte) + In Vivo Coding 原始文件：transcript.md

AI 指数级增长下的产品管理

自 2024 年 10 月 Claude Sonnet 3.5 (new) 发布以来，我养成了一个习惯：每当新模型发布时，我都会让 Claude Code（当时还是内部工具）为 Excalidraw 添加一个表格工具。每次新模型都能走得更远一些，但仍然会失败。

随后，2025 年 6 月 Opus 4 发布时，Claude 开始偶尔成功完成这个任务，频率足够高，以至于我们把这个实验变成了 Claude 4 模型发布会上的一个预录演示，展示最新模型能做到什么。

不到一年后，Opus 4.6 已经能够可靠地一次性完成 Excalidraw 功能需求，可靠到我们敢在数千名专业开发者面前进行现场演示。

模型进步的速度不断拓展着可能性的边界。传统的产品管理方法论建立在一个假设之上：项目开始时技术上能做到的事，到项目结束时大致也还是那些。PM 会在前期收集足够的信息来对未来做出有信心的判断，然后按照计划执行数月之久。

指数级提升的模型打破了这个假设。你围绕其设计的限制条件可能在项目进行到一半时就消失了。你是在一块不断升高的地面上建造东西，团队需要围绕这个现实重新组织。新的产品管理节奏是：快速实验、持续交付、加倍投入有效的方向。

毫不意外，作为 Anthropic 的产品经理，我被问得最多的问题之一就是我们的角色正在如何变化。以下是我学到的。

我与 Claude Code 的产品管理之旅

我的职业生涯始于 Scale AI 和 Dagster 等初创公司的产品工程师，之后成为风险投资人。在这个角色中，我仍然会写代码来自动化工作中枯燥的部分，比如扫描 X 上的新公司公告，或者检测开源项目何时获得增长势头。

2024 年 8 月，我加入 Anthropic 担任 Research PM 团队的产品经理，该团队在研究团队和真实客户之间架起桥梁，以交付更好的模型。那年秋天 Claude Code 在内部上线后，我用它加速了工作中更偏手动的部分，包括构建 Streamlit 应用来分析大规模用户反馈，以及运行 eval 来帮助公司找到值得信赖的新基准。低门槛的构建能力也意味着我可以探索远超我通常角色范围的领域，比如创建 RL 环境来更好地理解训练过程。

这些项目花费了数百小时的 Claude Code 提示（由 Sonnet 3.5 (new) 驱动），但没有一行代码是手写的。

设计新的产品管理工作流

像 Claude Code 和 Cowork 这样的工具正在模糊产品开发生命周期中各角色之间的界限。

Claude Code 并非驱动我工作流的唯一工具。随着时间推移，我在三个产品之间形成了自然的分工：聊天协作伙伴（Claude.ai）、智能编码工具（Claude Code）和知识工作工具（Cowork）。

Claude.ai 是我与 Claude 作为思考伙伴交流的地方，不需要它执行操作。我在这里碰撞策略文档的想法、处理棘手情况的方案，以及快速获取答案。

Claude Code 是我构建原型、eval 和脚本的地方，其中许多会调用 Claude API。当输出是代码时，我用这个。

Cowork 是我做其他一切事情的地方，从清空收件箱、跟踪和执行待办清单、制作幻灯片、通过搜索 Slack 了解某个决策的历史，到预订工作差旅。

我与业界各种产品经理交流过，他们都找到了自己版本的这套工作流：

“Claude 提升了优秀产品团队能够构建的上限，并且大幅缩短了从想法到原型的距离。以前要把一个可触摸的东西放到客户面前需要数周的开发。现在我会先在 Claude Cowork 中开始，引入来自 Slack、代码库和文档的上下文，然后转到 Claude Code，几个小时内就能拿出一个可演示的东西。优秀的产品团队一直都在用真实客户测试自己的想法，这种本能没有改变。改变的是我们实际上能让多少高质量的想法通过这个循环。” —— Bihan Jiang，Decagon 产品总监

“对我来说，在 AI 原生世界中做 PM 既是创造性的也是学术性的。每次新模型发布都改变了可能性的边界，在构建 Datadog 的 Bits AI SRE agent 时，我们通过对真实生产事件的离线评估来研究其优势和失败模式。我们还设计了紧密的反馈循环，通过优化 UX 来暴露 agent 的薄弱环节，并将这些洞察转化为产品改进。从这个意义上说，PM 的技艺已经从前期定义确定性转向了加速发现。” —— Kai Xin Tai，Datadog 高级产品经理

作为产品经理，当下最令人兴奋的部分之一是，这些工作流在不断演进，给予我们更大的杠杆。

拥抱 AI 指数级增长

METR. (2026, March). Task-Completion Time Horizons of Frontier AI Models. https://metr.org/time-horizons/

METR 发现，大约一半的时间里，Opus 4.6 能够完成人类需要近 12 小时才能完成的软件任务。当我们刚开始构建 Claude Code 时，Sonnet 3.5 (new) 是最前沿的模型，METR 测量其能完成人类大约 21 分钟的任务。这在 16 个月内实现了大约 41 倍的跳跃。

Claude Code 团队不断演进以跟上模型改进的速度。我们的角色正在融合：设计师提交代码，工程师做产品决策，产品经理构建原型和 eval。这之所以可行，是因为清晰的战略和目标让每个人都能自主确定优先级。产品经理的工作是在快速模型进步带来的模糊性中创造清晰度，推动团队更大胆地思考可能性，并扫清更快交付的障碍。

以下是我们拥抱的四个转变：

以短周期冲刺来规划

传统的产品经理思维将探索视为路线图锁定之前发生的事情。你做完调研，写完 PRD，然后交给工程团队去构建。

我们没有采用长期路线图，而是鼓励团队中的每个人（工程师、产品经理、设计师）去做”支线任务”。支线任务是你在官方路线图之外运行的短期自驱实验——花一个下午来原型化一个想法、测试一个你认为不可能的能力，或者只是看看当你比预期更用力地推动模型时会发生什么。

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

鼓励演示和 eval，而非文档

我们的团队已经在很大程度上用原型优先的思维取代了文档优先的思维。我们不再举行传统的站会，而是分享新想法的演示。内部用户尝试它们，那些获得真实使用的会被打磨并更广泛地分享。因为你可以在一个下午内完成原型，错误的赌注代价很低。

例如，当 Noah 与 Claude Code 分享他的 plugins 规格说明时，返回的原型已经接近生产就绪。那个原型锚定了团队最终交付的产品，因为它让团队能够快速验证 UX。

专业建议：写完规格说明后，发给 Claude Code 看它能不能构建出来。即使是一个粗糙的原型也能改变整个讨论。

除了演示之外，eval 也可以帮助让一个抽象的产品变得更具体。例如，对于 agent teams——一个让用户协调多个 Claude Code 实例协同工作的功能——Conner 手工制作了一套 eval 来理解 agent teams 什么时候效果好、什么时候不好、以及该修什么。衡量功能是否有效使得改进它变得更容易。

用新模型重新审视已有功能

现在，你发布一个功能，然后一个更好的模型出来，你的功能可能会有戏剧性的提升。每次模型发布都是一个隐含的提示，让你重新审视已经构建的东西。

捕捉这些时刻的最佳方式是成为日活用户，并刻意要求它做你认为可能太难的事情。有时候它成功了，这就是一个信号：产品需要跟上。

Claude Code with Chrome 就是这样诞生的。我们注意到用户用 Claude Code 构建 Web 应用，然后手动切换到 Chrome 中的 Claude 来测试。用户在这两个工具之间手动提示、复制粘贴指令。这个方式运行得足够好，以至于我们意识到这应该是一个内置功能。如果用户在拼凑什么东西，那就是你可以内建到产品中的脚手架。

在原型化这些想法时，始终优先优化能力。使用比你认为需要的更多的 token。一个常见错误是过早削减 token 成本，结果交付了一个能力大打折扣的东西。你总是可以在更便宜的模型跟上来后降低成本，但首先你需要知道这个功能到底是否可行。

做简单的事

在 Anthropic，我们有一个贯穿每个团队的指导原则：做简单且有效的事。

如果你的产品巧妙地绕过了一个模型限制，那个变通方案在下一个模型发布时就会变成不必要的复杂性。这就是为什么”做简单的事”很重要：你的实现越简单，在新能力到来时就越容易替换。

当我们首次在 Claude Code 中推出待办清单时，模型不能可靠地在完成任务后打勾。所以我们每隔几条消息添加系统提醒，周期性地推动 agent 更新自己的待办清单。这管用，但是个 hack。到了下一个模型，这个行为开箱即用，我们就完全移除了那些提醒。我们反复看到这个模式：我们的系统提示和工具描述曾经被大量工程化以弥补模型局限，而随着每个模型的进步我们都能精简提示——Opus 4.6 就减少了 20%。

展望未来

许多产品经理习惯于对完整的产品体验拥有紧密的控制，但 AI 推动你放手以便快速行动。尤其在构建 AI 产品时，感觉就像冲浪，最重要的是留在浪上。作为一个完美主义者，这是我最难适应的转变，但产品经理的角色现在是识别少数真正不可妥协的事项，其余的则放手。

这些转变的净效果是产品团队可以显著加速。当产品经理能在一个下午内从想法到可用原型，“如果我们试试……”和”来，试试这个”之间的鸿沟几乎消失了。

在 Anthropic，产品经理并不是唯一在用 Claude 改造工作流的人。我们的数据科学、金融、市场营销、法务和设计团队都主动采用了这些工具。整个组织以相同的速度运转，而不是等待交接。

PM 的角色现在是同时追踪两件事：AI 如何改变你的工作方式，以及它如何改变你产品中的可能性。做好这一点，你就不会在表格工具终于能用时感到惊讶——因为你是那个预见到它的人。

立即使用 Claude Code 构建更好的产品。

致谢： 本文由 Anthropic Claude Code 产品负责人 Cat Wu 撰写。你可以在 X 和 LinkedIn 上找到她。她感谢 Bihan Jiang 和 Kai Xin Tai 对本文的贡献。