作者 Cat Wu（Claude Code 产品负责人）的主要论点：
指数级迭代的模型让传统 PM 的「前期调研 → 锁定路线图 → 执行」模式失效了——你围绕某个约束设计的方案，可能在项目中途就因为新模型而不再需要。
她提出了四个实践转变：
- 短冲刺 + 支线任务：用下午级别的自主实验代替季度路线图
- Demo / Evals 优先于文档：原型成本极低，错了也不贵
- 新模型发布 = 重新审视已有功能：用户自己拼出来的 workaround 就是产品该内置的东西
- 做最简单的方案：绕过模型限制的 hack 会在下一个模型上变成负债，Opus 4.6 让他们减少了 20% 的 prompt 工程
Claude Code 产品负责人 Cat Wu 分享了产品管理团队如何在模型能力快速演进的背景下，调整工作流程与产品路线图。
自 2024 年 10 月 Claude Sonnet 3.5（新版） 发布以来，我养成了一个习惯：每次有新模型发布，就用 Claude Code（当时还是内部工具）来测试它——让它给 Excalidraw 添加一个表格工具。每次测试，Claude 都能比上一版走得更远，但始终未能完成任务。
直到 2025 年 6 月 Opus 4 发布，Claude 才开始偶尔成功——成功率已经高到足以将这个演示录制下来，作为 Claude 4 模型发布会的预录演示片段，用以展示最新模型的能力边界。
不到一年后，Opus 4.6 已经能够可靠地一次完成 Excalidraw 功能请求，稳定到可以在数千名专业开发者面前进行现场演示。
模型进步的速度持续拓展着可能的边界。传统产品管理方法论建立在一个假设之上：项目启动时技术能做到什么，项目结束时大致还是那样。产品经理会在前期收集充分信息，对未来做出有把握的判断，然后按计划执行数月。
而指数级提升的模型打破了这个假设。你围绕某个约束设计好方案，这个约束可能在项目中途就消失了。你是在不断上升的地基上建造，团队需要围绕这个现实重新组织。新的产品管理节奏是：快速实验、持续交付、押注有效的方向加倍投入。
作为 Anthropic 的产品经理，"我们的角色在如何变化？"是我被问到最多的问题之一。以下是我的思考与总结。
我与 Claude Code 产品管理的缘起
我职业生涯起步于 Scale AI、Dagster 等初创公司的产品工程师，后来转型为风险投资人。在 VC 阶段，我仍然在写代码，用来自动化工作中繁琐的部分——比如扫描 X（推特）上新公司的动态公告，或者检测开源项目是否在快速获得关注度。
2024 年 8 月，我以产品经理身份加入 Anthropic，加入了 Research PM 团队——这个团队的职责是连接研究团队与真实用户，推动更好的模型落地。当年秋天，Claude Code 在内部开放使用，我很快用它来加速工作中更手动的部分，包括搭建 Streamlit 应用来分析大规模用户反馈，以及运行评估（evals）帮助公司寻找新的可信基准。较低的构建门槛也让我得以超出常规职责去探索，比如创建强化学习环境来更好地理解训练机制。
这些项目耗费了我数百小时与 Claude Code（Sonnet 3.5 新版驱动）的对话，但没有一行代码是我手写的。
设计新的产品管理工作流
Claude Code 和 Cowork 这类工具正在模糊产品开发生命周期中各角色之间的边界。
随着时间推移，我逐渐形成了一套自然的分工体系，跨三款产品协作：
-
Claude.ai：思维伙伴。当我需要和 Claude 对话、而不需要它采取行动时使用。我用它碰撞策略文档的想法、处理棘手情况，以及快速获取答案。
-
Claude Code：构建工具。当产出是代码时使用——搭建原型、运行评估、编写脚本，其中很多脚本本身也会调用 Claude API。
-
Cowork：其他一切。从清空收件箱、跟踪和执行待办事项、制作幻灯片，到搜索 Slack 历史了解某个决策的来龙去脉，再到预订出差行程。
我与业界多位产品经理交流，他们都找到了自己版本的类似工作流：
"Claude 提升了优秀产品团队所能构建的上限，并大幅缩短了从想法到原型的距离。过去，把一个想法变成可以展示给用户的东西需要数周时间。现在，我会先在 Claude Cowork 里整合来自 Slack、代码库和文档的上下文，然后转到 Claude Code，几小时内就能有可演示的东西。优秀的产品团队向来都懂得用真实用户来验证想法，这个本能没有变。变化的是，我们能真正跑完这个验证循环的高质量想法，比以前多得多了。"
——Bihan Jiang，Decagon 产品总监"在我看来，AI 原生时代的 PM 工作既是创意性的，也是学术性的。每次新模型发布都改变了可能性的边界。在构建 Datadog 的 Bits AI SRE 智能体时，我们通过在真实生产事故上的离线评估来研究模型的优势和失效模式，同时设计紧密的反馈循环，优化 UX 来暴露智能体的薄弱环节，再把这些洞察转化为产品改进。从这个意义上说，PM 的核心工作已经从'前期定义确定性'转变为'加速发现过程'。"
——Kai Xin Tai，Datadog 高级产品经理
作为产品经理，这个时代最令人兴奋的地方之一，就是这些工作流仍在持续演进，并给我们带来越来越大的杠杆。
拥抱 AI 指数级增长
METR 的研究 发现，Opus 4.6 约有一半概率能完成人类需要将近 12 小时才能完成的软件任务。当我们最初开始构建 Claude Code 时，Sonnet 3.5（新版）是前沿模型，METR 测量到它可以完成人类约需 21 分钟的任务。也就是说，16 个月内，能力提升了约 41 倍。
Claude Code 团队也在随模型能力的快速提升而演进。我们的角色边界开始融合：设计师会提交代码，工程师会参与产品决策，产品经理会搭建原型和评估体系。这之所以可行，是因为清晰的战略和目标让每个人都能自主排优先级。产品经理的工作，是在快速的模型进步制造的不确定性中建立清晰感，推动团队对可能性有更大的想象，并扫清快速交付路上的障碍。
以下是我们拥抱的四个转变：
1. 用短冲刺规划
传统产品管理思维把探索视为路线图锁定之前的事情：做调研、写 PRD，然后交给工程团队去构建。
我们换了一种方式：鼓励团队所有人（工程师、产品经理、设计师）去做「支线任务」（side quest）。所谓支线任务，是你在正式路线图之外主动发起的短期自主实验——某个下午花时间把一个想法原型化，测试一个你以为遥不可及的能力，或者只是把模型往你预期之外的方向使劲推一推。
Anthropic 一些最受欢迎的功能——Claude Code Desktop 版、AskUserQuestion 工具、待办事项列表——都是这样诞生的。
2. 用 Demo 和评估取代文档
我们团队基本上已经用「原型优先」取代了「文档优先」的思维方式。我们不再做传统的站立会议，而是分享新想法的 Demo。内部用户试用后，获得真实反馈和参与度的原型会被打磨、更大范围分享。因为一个下午就能做出原型，押错的成本极低。
举个例子：Noah 把 Plugins（插件）的需求说明书发给 Claude Code，Claude Code 返回了一个接近生产就绪的原型。这个原型成了团队最终交付版本的锚点，因为它让团队可以快速验证 UX 设计的方向。
一个小技巧：写完需求文档之后，把它发给 Claude Code，让它试着把它构建出来。哪怕只是一个粗糙的原型，也会改变后续的讨论方式。
除了 Demo，评估（evals）也能让抽象的产品构想变得更具体。以智能体协作（Agent Teams）为例——这个功能允许用户协调多个 Claude Code 实例并行工作——Conner 手工设计了一套评估集，用来理解智能体协作在什么情况下有效、在什么情况下失效，以及如何改进。量化地衡量功能是否在工作，让改进方向变得更加清晰。
3. 随新模型重新审视已有功能
现在，你上线了一个功能，然后更好的模型发布了，你的功能可能可以大幅改善。每次模型发布，都是对已有功能重新审视的隐性信号。
捕捉这些时机最好的方式，是自己成为日活用户，并刻意去做你认为可能超出模型能力边界的事情。有时候它成功了，那就是产品需要跟进的信号。
Claude Code 与 Chrome 的集成就是这样发现的。我们注意到用户会用 Claude Code 构建 Web 应用，然后手动切换到 Claude in Chrome 去测试。用户自己在两个工具之间手动传递指令和复制粘贴。这个土办法有效到让我们意识到：这应该是一个内置功能。用户在自己拼凑出来的 workaround，就是你需要构建进产品里的脚手架。
在原型阶段，永远优先追求能力上限。用比你认为需要的更多的 token。过早削减 token 成本是个常见错误，结果往往是上线了一个能力大打折扣的功能。等更便宜的模型追上来之后，成本自然可以降下来，但首先你需要验证这个功能在能力上是否可行。
4. 做最简单的事
在 Anthropic，有一条跨团队的指导原则：做那个有效的最简单方案。
如果你的产品巧妙地绕过了某个模型局限，那么当下一个模型发布时，这个 workaround 就变成了不必要的复杂性。这就是「做最简单的事」的意义所在：实现越简单，越容易在新能力到来时做替换。
Claude Code 刚上线待办事项列表时，模型不能可靠地在完成任务后勾选条目。于是我们加了系统提醒，每隔几条消息就推动智能体更新自己的待办列表。这个方案有效，但本质上是个 hack。随着下一个模型发布，这个行为直接就有了，提醒就可以删掉了。我们反复看到这个规律：过去我们的 system prompt 和工具描述经过大量工程优化来弥补模型局限，而随着每个模型迭代，我们能裁减掉越来越多的这类提示——Opus 4.6 就让我们减少了 20% 的 prompt 内容。
展望
许多产品经理习惯于对完整的产品体验保持严格把控，但 AI 迫使你学会放手，才能快速前进。尤其是在构建 AI 产品时，感觉就像在冲浪，最重要的事是留在浪头上。作为一个完美主义者，这是我最难适应的转变，但产品经理的工作现在变成了：找出真正不可妥协的少数几件事，然后放手让其他的去。
这些转变累积起来的结果是：产品团队的移动速度显著加快。当一个产品经理可以在一个下午从想法变成可工作的原型，"要不要试试……"和"来，你试试这个"之间的距离几乎消失了。
在 Anthropic，不只是产品经理在用 Claude 重塑工作流。数据科学、财务、市场营销、法务和设计团队都在自发地使用这些工具。整个组织以相同的速度前进，而不是在一个个交接环节中等待。
产品经理现在要同时追踪两件事：AI 如何改变你的工作方式，以及 AI 如何改变你产品的可能性边界。把这两件事都做好，你就不会在表格工具终于跑通时感到惊讶——你会是那个早就预见到它会成功的人。
开始用 Claude Code 构建更好的产品。
致谢： 本文作者 Cat Wu，Claude Code 产品负责人，现于 X 和 LinkedIn 上活跃。感谢 Bihan Jiang 和 Kai Xin Tai 对本文的贡献。