Claude Code产品负责人谈使用限制、透明度及“精益调控框架”

# Claude Code 产品负责人谈使用限制、透明度与"精简框架" 来源：https://arstechnica.com/ai/2026/05/claude-codes-product-lead-talks-usage-limits-transparency-and-the-lean-harness/ "我们没有宏伟蓝图，"Anthropic 的 Cat Wu 说——但这正是设计使然。 Claude Code 产品负责人 Cat Wu 在 Anthropic 于旧金山举办的 Code with Claude 2026 大会上发言。图片来源：Anthropic (https://www.youtube.com/watch?v=GMIWm5y90xA) 旧金山——在日益扩展的应用界面、不断增长的令牌和算力需求，以及迅速演变的用户群体中，Anthropic 并未为 Claude Code 制定长期路线图。然而，该公司押注这样的规划将被模型能力的提升以及开发者关于最佳使用方式的新信号所淘汰。这是 Ars 与 Anthropic 的 Claude Code 产品负责人 Cat Wu 进行 30 分钟对话后得出的结论。 上周，在旧金山市中心一座精心改造为活动场地的三层租车停车场内，Anthropic 举办了第二届年度 Code with Claude 开发者大会。据此前报道，这场为期一天的活动包括介绍 Managed Agents 新功能 (https://arstechnica.com/ai/2026/05/anthropics-claude-can-now-dream-sort-of/) 的主题演讲，以及宣布与 SpaceX 达成算力合作 (https://arstechnica.com/ai/2026/05/anthropic-raises-claude-code-usage-limits-credits-new-deal-with-spacex/)。 这项算力合作还伴随着将 Claude Code Pro 和 Max 计划用户的使用限制翻倍——这是对许多用户因算力紧张（尤其是最近几周）而感到沮丧的回应。 Anthropic 的产品——尤其是其用于智能体软件开发工具 Claude Code——受到了追捧。"我们非常努力地规划了每年增长 10 倍的世界，"Anthropic CEO Dario Amodei 在大会上说。"但结果我们遇到了 80 倍的增长，这就是我们在算力上面临困难的原因。" 用户增长的同时，人们使用公司模型的方式也发生了转变，从简单的聊天界面转向复杂、多智能体的工作流程，其需求是以前的数倍。 在算力紧张期间，Anthropic 一直在测试减少需求的解决方案，例如在高峰时段执行更严格的限制，或从其较便宜的订阅计划中移除 (https://arstechnica.com/ai/2026/04/anthropic-tested-removing-claude-code-from-the-pro-plan/) Claude Code。 过去一年里，Anthropic 发布了大量新功能、产品和用于与模型交互的界面。Claude Code 从 CLI 扩展到 IDE 再到桌面版，同时还推出了一批管理多个智能体的新工具。公司发布产品的节奏有时非常紧张且混乱。 与此同时，OpenAI 的 Codex、GitHub Copilot、Cursor IDE、Augment Code 等竞争对手也在这一领域推出各自的新产品和功能，有些通过更明确的上下文等差异化卖点来宣称提供更好的结果或更高的效率。 在活动现场，我与 Wu 讨论了 Anthropic 在这种背景下如何运作。 作为 Claude Code 的产品负责人，Wu 与其创建者 Boris Cherny 密切合作，确定要优先考虑哪些功能，以及 Anthropic 团队如何测试、使用和推出这些功能。她并不直接管理模型，但她描述的产品策略大胆押注：模型将继续快速改进，以至于很难为 Claude Code 这样的产品制定未来的规划。 据 Wu 所说，Claude Code 团队以大约一周为开发周期推出新产品或功能，在"狂野西部"般的实验中探索新的用例和方法。 我们讨论了用户对使用限制的沮丧、结构化数据在使 Claude Code 工作中的作用、IDE 集成、该工具的未来能力以及更多话题。 ## 与 Cat Wu 的对话 *本次采访经过编辑以追求简洁明了。* ***Ars**：你们推出产品的速度非常快，而且增加了许多不同的界面。有命令行、IDE 集成、桌面应用，然后还有 Code、Cowork、Managed Agents 等等之间的各种差异化。* *您是否仍然认为命令行是其核心？还是看到人们越来越多地转向桌面或网页应用？* **Wu**：我们实际上发现每个开发者都有不同的偏好，所以我们的使用量在这些界面之间相当分散。每一个都有大量用户。我认为核心仍然是 CLI。它仍然拥有最强大的用户功能，也是我们大部分功能最先落地的地方，而且对我们来说迭代速度最快。它也是我们团队大多数人使用的界面。 然而，我们确实看到团队内部正在从 CLI 逐渐转向桌面版，因为也许去年人们只用一个智能体，然后在一年时间里，他们开始打开六个终端选项卡，接着人们开始添加花哨的方式来监控一堆终端选项卡并接收通知，我认为人们现在已经到了"好吧，我不想再读十个选项卡了。我只想——我理解为什么人们需要图形界面了"的地步，所以很多人为了获得更丰富的视图而转向桌面版。 ***Ars**：按照你们推出新界面的速度，如果推演下去，从开发或产品的角度来看，可能会变得难以管理。你们需要维护所有这些针对不同目的的东西，而且对用户来说也可能越来越混乱。* *您是否认为未来可能会开始整合，还是认为这是最好的解决方案，因为你们为每种用户定制了专门的工具？* **Wu**：是的，我认为这有点像是一个演进过程。大多数人从 CLI 或 IDE 开始，然后到了需要管理大量智能体的阶段，你想知道哪些被卡住了，可以专注于它们，于是人们转向桌面版。 然后人们会说："等等，我只是把客户反馈渠道的消息复制粘贴到 Claude 里，然后在本地盯着它。"所以这就是为什么我们添加了这些更高级的东西，比如可以监视那个 Slack 频道（你从中获取反馈或数据等）来自动触发这些运行的例行程序……所有这些产品只是帮助您更轻松地激发模型智能的方式。我们实际上移除了脚手架。随着模型变得越来越聪明，我们会逐步移除系统提示词和工具描述中的部分内容。 我绝对可以看到一个世界，也许我们都回到文本框中，因为模型可能永远是正确的，所以你实际上不需要跟踪每个提示的每一步。它可能不会被卡住。所以我可以看到一个一切都合并的世界，但我认为在模型变得更好的同时，我们现在需要所有这些工具来满足人们当下的需求。 ***Ars**：这种方法是部分基于实时跟随用户的信号，而不是像很多公司那样——他们有一个宏伟的蓝图，这是我们的全年计划……* **Wu**：哦，我们没有宏伟蓝图！[笑。] ***Ars**：我能看出来！我不是说这不好，因为看起来你们正在推出各种东西来满足这些潜在的需求和信号。这与 OpenAI 的做法不同，他们正在谈论一个超级应用，对吧？您对那种将所有东西整合到一个为所有人做所有事情的超级应用的方法有什么看法？您认为这是一个坏主意吗？* **Wu**：我们有几条指导原则。一是我们相信模型将继续呈指数级增长，对我们来说，重要的是朝着趋势方向构建。 我认为我们对自己不知道确切正确形态这件事保持谦逊，但鼓励我们的团队尽可能多地探索，以找出最适合下一代模型的形态。 不知道您有没有读过《苦涩的教训》？ ***Ars**：嗯，读过。* *[《苦涩的教训》是计算机科学家、强化学习先驱 Richard Sutton 在 2019 年发表的一篇文章。其中部分观点认为，将特定领域的结构嵌入 AI 系统的努力往往"最终被证明是适得其反的"，而最终胜出的方法是那些能够随可用算力扩展的通用方法。]* **Wu**：是的，那是我们团队的指导原则之一。我认为这非常困难——因为模型变化太快——很难说这一定是下一个形态。我们有一些猜测。我们在内部大量试用这些想法，但我们对犯错持相当开放的态度，我们只需要与模型的能力保持非常紧密的联系。 ***Ars**：我知道其中一些东西来自于看到用户以某种方式使用，然后决定将其产品化并使其更方便。* *您现在是否看到了类似的东西，但尚未产品化，并且您在说："好的，我们需要在不久的将来考虑这个了"？* **Wu**：我们尽量快速地将确信转化为产品转变，理想情况下在一周左右。所以通常我们从感受到用户的需求到发布产品之间没有太大的延迟。 我认为可能还有一个更高的层次，Claude 可以预测你想要什么。比如，它可以主动知道："哦，你正在开发一个语音功能"，所以它应该监视 GitHub issues、Slack 和 Twitter 等渠道中关于语音 bug 或新功能请求的反馈，然后自动创建监测的例行程序。 这其实并不遥远，我认为这是即将到来的下一步……Claude 应该自行决定去监听关于你功能的反馈，然后决定如何通知你它的想法。这样工程师就不需要设置自动化，但 Claude 会自己思考："好的，这是你在做的东西，让我监测它，然后提出你今天可以做什么。" ***Ars**：使用这些工具的开发者对算力供不应求感到沮丧。限制是个问题。* *现在有一些工具会查看 IDE 对代码库的了解——这个函数在这些不同的地方被引用，等等——我们的想法是，这能更高效地梳理代码库，减少令牌使用，因为你有结构化数据。这是你们正在考虑的吗？还是你们有理由不朝这个方向走？* **Wu**：我们确实有插件可以告诉 Claude Code 这些语义信息。我们有可用的 LSP，例如，你可以说"我想跳转到这个函数定义的地方"，它就会直接跳到那个位置，无需搜索。 我们没有发现这能带来可衡量的性能提升，但我们把 Claude Code 设计得足够可扩展，如果你想要一个做这个的插件，它是可用的，你可以连接它。但我们发现 Claude Code 在不需要添加这些功能来导航代码库的情况下，已经很擅长生成高质量的代码了。 ***Ars**：问题与其说是代码质量，不如说是达到目标的效率，对吧？因为，人们再次对使用限制感到非常沮丧。有时人们试图为 LLM 引入某种结构，结果发现这有预料之外的隐藏成本。这就是您说的语义信息发生的情况吗？您是否有数据表明这不是正确的方向？* **Wu**：从评估来看，我们没有看到可衡量的变化。我认为我们总体上更倾向于提供一个更精简的框架，减少过于定制的工具，让开发者根据需要自行添加。所以除非一个工具能明显改善令牌性能或准确性，否则我们默认不会发布它。 我认为令牌效率一直是我们最关心的问题，因为我们只想给人们每令牌最大限度的智能，所以我们不断尝试减少它的方法，但实际做起来比我期望的要难。 对我们来说，最重要的是保持智能，所以我们只会发布那些我们认为能让模型更智能的东西，因为那才是我们的北极星，而不是令牌效率。 ***Ars**：对于某些用户来说，如果更透明，他们可能更容易接受令牌可用性的限制。但同时，我的印象是，真正透明地告知令牌使用情况——"这个任务花了这么多令牌，因为你做了这个而不是那个"——这实际上很难做到。* *我猜你们已经研究过如何与用户沟通这些信息。当你们尝试这样做时发现了什么？* **Wu**：我们确实收到了很多关于这方面的问题，比如："嘿，我的使用限制很快就用完了，它们去哪儿了？"我认为这完全合理，我们需要对此保持透明。诊断起来确实很难。 所以当人们有这些抱怨时，我们挑选几个人，与他们进行实时通话，我们实际上现场调试，因为你的完整对话记录完全存储在本地，所以你实际上已经在你的电脑上有了所有关于你使用了多少令牌的数据…… 我们注意到两种主要模式。一是，人们进行非常长的会话，离开两个小时，回来时缓存已经失效——当缓存失效时，发送下一个查询实际上要昂贵得多。所以我们开始显示一个通知，说："嘿，缓存已失效，如果你想开始新会话，请运行 /clear。"这只是一个提醒，告诉你恢复这个会话的成本很高。另外，当你运行 /usage 时，你实际上会看到："嘿，这些会话成本很高，因为你的缓存已失效。" 我们发现的另一种常见模式是，有些人安装了实际上告诉 Claude 启动大量子智能体的插件，所以有人在后台运行了上百个子智能体，这非常昂贵，因为这相当于 100 个 Claude Code 在运行，但他们没有意识到……然后我们添加了一些使用量显示，所以它会告诉你你正在使用大量的子智能体。 我认为我们还可以做更多，随着我们找出不良模式或令人担忧的模式，我们想向用户展示这些信息。 这确实非常困难。所以对我们来说保持透明非常重要，但在我们找到有用方式展示之前，我们需要对令牌去向有一个强有力的推断。 ***Ars**：最后一个问题：你们有非常不同类型的组织或用户在使用这个工具。有完全没有编程经验、进行 vibe-coding 的人，有经验丰富的个人开发者，有几十人规模的团队，还有大型企业。你们如何让这个工具为所有这些不同类型的用户和团队规模服务？因为他们有如此截然不同的需求。* **Wu**：我们试图让核心框架尽可能不做预设。它只是我们最小可行的一套工具——制定计划、做待办事项列表、编辑文件、还有少数几个，以及向用户提出澄清性问题。我们试图让它非常通用，然后让其他人引入适合他们的定制化。 我认为沿着这种采用轴线或类似的过程，我们发现，随着模型越来越好，采用率基本上沿着你谈到的轨迹增长。例如，Opus 4.5 对企业来说是一个巨大的突破。即使你不是一