AI指数时代的产品管理：Claude Code产品主管分享

自从Claude Sonnet 3.5 (new)在2024年10月发布以来，我养成了一个习惯，每次测试新模型时，都会让Claude Code（当时是一个内部工具）向Excalidraw添加一个表格工具。随着每个新模型的推出，Claude都取得了一些进展，但仍然失败。

然后，随着Opus 4在2025年6月的发布，Claude开始偶尔成功，足以让我们把这个练习变成预先录制的演示用于Claude 4模型发布，以展示我们最新模型带来的可能性。

不到一年后，Opus 4.6能够可靠地一次性完成Excalidraw的功能请求，以至于我们觉得可以在数千名专业开发者面前进行现场演示。

模型进步的速度不断拓展可能性。传统的产品管理策略建立在这样的假设上：项目开始时技术上可能的事情，在项目结束时大致也是可能的。产品经理会提前收集足够的信息，以便对未来做出有信心的押注，然后在几个月内按照计划执行。

指数级改进的模型打破了这一假设。你围绕设计约束可能在中途消失。你是在脚下上升的地面上建设，团队需要围绕这一现实进行重组。新的人工智能产品管理节奏是快速实验、持续交付，并在有效的方法上加倍投入。

毫不奇怪，作为Anthropic的产品经理，我收到的最常见问题之一是我们的角色如何变化。以下是我学到的。

我与Claude Code的产品管理之旅

我的职业生涯始于Scale AI和Dagster等初创公司的产品工程师，然后成为风险投资人，在这个角色中我仍然编写代码来自动化工作中繁琐的部分，比如扫描X寻找新公司的公告，或检测开源项目是否正在获得动力。

我于2024年8月加入Anthropic，担任研究产品经理团队的产品经理，该团队连接我们的研究团队和真实客户，以交付更好的模型。那年秋天Claude Code在内部可用后，我使用它来加速工作中更手工的部分，包括构建Streamlit应用来分析大规模用户反馈，以及运行评估以帮助公司找到可信的新基准。低门槛的构建也意味着我可以在通常角色之外进行探索，比如创建强化学习环境以更好地理解训练。

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

设计新的产品管理工作流程

Claude Code并不是唯一支持我工作流程的工具。随着时间的推移，我找到了三种产品之间的自然分工：聊天协作工具（Claude.ai）、代理编码工具（Claude Code）和知识工作工具（Cowork）。

Claude.ai是我与Claude作为思想伙伴交谈的地方，无需它采取行动。我在这里交换策略文档的想法，如何处理棘手情况，并获得快速答案。

Claude Code是我构建原型、评估和脚本的地方，其中许多调用Claude API。当输出是代码时，我使用它。

Cowork是我做其他所有事情的地方，从收件箱清零，跟踪和执行待办事项，创建幻灯片，通过搜索Slack理解决策历史，以及预订工作旅行。

我与行业中的产品经理交流过，他们找到了自己的这种工作流程版本：

“Claude提高了优秀产品团队所能构建的上限，并大大缩短了从想法到原型的距离。将具体的东西呈现给客户过去需要数周的构建。现在我会从Claude Cowork开始，从Slack、代码库和文档中提取上下文，然后转移到Claude Code，在几个小时内得到可演示的东西。优秀的团队一直用真实客户测试想法，这种直觉没有改变。改变的是我们能够实际通过这个循环的高质量想法有多少。” - Bihan Jiang，Decagon产品总监

“对我来说，在人工智能原生世界做产品经理既要有创造力又要有学术性。每次新模型发布都会改变可能性，在构建Datadog的Bits AI SRE代理时，我们通过离线评估真实生产事件来研究其优势和失败模式。我们还设计紧密的反馈循环，优化用户体验以显示代理挣扎之处，并将这些见解转化为产品改进。从这个意义上说，产品经理的技艺已经从预先定义确定性转变为加速发现。” - Kai Xin Tai，Datadog高级产品经理

当今产品经理最令人兴奋的部分之一是这些工作流程不断演变，给我们带来更多杠杆。

拥抱人工智能指数

METR 发现，大约有一半时间，Opus 4.6可以完成人类需要近12小时的软件任务。当我们最初开始构建Claude Code时，Sonnet 3.5 (new)是前沿模型，METR测量它可以完成人类大约需要21分钟的任务。在16个月内大约增长了41倍。

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

以下是我们所接受的四个转变：

短期冲刺计划

传统的产品经理思维将探索视为在路线图锁定之前发生的事情。你进行研究，编写产品需求文档，然后将其交给工程团队构建。

我们没有长期路线图，而是鼓励团队中的每个人（工程师、产品经理、设计师）接取支线任务。支线任务是你于官方路线图之外进行的短期自导实验——花一个下午制作一个想法原型，测试你认为无法实现的能力，或只是看看当你比预期更用力地推动模型时会发生什么。

Anthropic 一些最受欢迎的功能——桌面版 Claude Code、AskUserQuestion 工具以及待办列表——就是这样产生的。

鼓励演示和评估，而非文档

我们团队已基本用原型优先思维取代了文档优先思维。我们不举办传统站会，而是分享新想法的演示。内部用户试用它们，那些获得真正参与度的想法会被打磨并更广泛地分享。因为你可以在一个下午完成原型制作，错误的投入成本很低。

例如，当 Noah 向 Claude Code 分享他的插件规格时，返回的原型已接近生产就绪。该原型锚定了团队最终发布的内容，因为它使团队能够快速验证用户体验。

专业提示：编写规格后，将其发送给 Claude Code，看看它能否构建它。即使是一个粗糙的原型也会改变对话。

除了演示，评估也可以帮助抽象产品变得更加具体。例如，对于代理团队——该功能允许用户协调多个Claude Code实例协同工作——Conner 手工制作了一组评估，以了解代理团队何时运行良好，何时不佳，以及要修复什么。衡量该功能是否有效使其改进更容易。

用新模型重新审视功能

现在，你发布一个功能，然后一个更好的模型出现，你的功能可能会显著更好。每次模型发布都是一个含蓄的提示，要求你重新审视已经构建的内容。

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

这就是Claude Code 搭配 Chrome功能得以实现的过程。我们注意到用户使用 Claude Code 构建 Web 应用，然后手动切换到 Chrome 中的 Claude 进行测试。用户手动提示并在两个工具之间复制粘贴指令。它运行得很好，以至于我们意识到这应该是一个内置功能。如果用户正在拼凑某些东西，那就是你可以构建到产品中的脚手架。

当为这些想法制作原型时，始终优先考虑能力。使用比你认为需要的更多的令牌。过早削减令牌成本并因此发布功能大打折扣的产品是一个常见错误。随着更便宜的模型出现，你总是可以在稍后降低成本，但首先你需要知道该功能是否可行。

做简单的事情

在 Anthropic，我们有一个跨团队的指导原则：做简单有效的事情。

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

当我们首次在 Claude Code 中推出待办列表时，模型在完成任务时并不总是可靠地勾选项目。因此，我们在每条消息中添加了系统提醒，定期提示代理更新自己的待办列表。这奏效了，但这是一种技巧。使用下一个模型，这种行为自然而然地出现，我们完全移除了提醒。我们反复看到这种模式：我们的系统提示和工具描述曾经针对模型限制进行大量工程化补偿，而我们已经能够削减每个模型的提示，包括为 Opus 4.6 削减了 20%。

展望未来

许多产品经理习惯于对完整产品体验有严格控制，但人工智能迫使你放手以快速行动。这种控制本能是 AI 产品管理要求你首先忘却的东西。

尤其是在构建 AI 产品时，这就像冲浪，最重要的是保持站在浪潮上。作为一个完美主义者，这是我最难适应的转变，但产品经理的角色现在是识别少数真正不可妥协的事项，并放弃其余的。

这些转变的最终效果是团队可以显著加速前进。当产品经理可以在一个下午从想法走到可用原型时，“如果我们试试……”和“来，试试这个”之间的差距几乎消失了。

在 Anthropic，产品经理并非唯一使用 Claude 转变工作流程的人。我们的数据科学、财务、市场营销、法务和设计团队也自行采用了这些工具。整个组织以相同速度前进，而不是等待交接。

现在，产品经理的角色是同时跟踪两件事：AI 如何改变你的工作方式，以及它如何改变你的产品可能实现的东西。做好这一点，当表格工具终于奏效时，你就不再感到惊讶。你就是那个预见它发生的人。

开始用Claude Code构建更好的产品。

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