与 Claude Code 团队的 Cat 和 Thariq 炉边对谈A Fireside Chat with Cat and Thariq from the Claude Code team

2026年7月21日

本月早些时候，我在AI工程师世界博览会上主持了一场炉边谈话，嘉宾是来自Anthropic Claude Code团队的Cat Wu和Thariq Shihipar。我们讨论了Claude Code、Claude Tag、Fable、编程代理安全、评估、工具设计，以及Anthropic内部如何使用这些工具。

本次活动的完整视频现已在YouTube上发布。以下是经过编辑的文字记录，其中添加了额外的链接以及我加粗的重点内容。

如果您不想观看视频或通读整篇文字记录，这里有几条核心要点：

过去一年里，你的日常工作发生了怎样的变化？

1:05

Simon：Claude Code 是去年二月发布的——到现在还不到一年半，它最初只是 Claude Sonnet 3.7 发布时的一个项目符号。既然现在我们有了这些真正能为我们效力的编程代理，过去一年里你们的日常工作发生了怎样的变化？ Cat：我记得当我们刚推出 Claude Code 和 Sonnet 3.7 时，你给它一个任务，就必须密切监视它试图做的每一件小事。我会极其仔细地阅读每一个权限提示。我会经常拒绝——不，不，不，你检查这个文件了吗？你检查那个文件了吗？而现在，随着每一代模型的更新，情况变得令人难以置信。我觉得我们都有机会退后一步，将更多繁琐的实现工作委派给 Claude。这释放了我们大量的时间，让我们可以思考更具创造性的工作，比如：既然我们知道 Claude Code 能实现很多功能，那么我们应该为用户提供什么样的正确体验？现在有了 Fable，这又是一次完全不同的质的飞跃。我们看到，在很多用例中，你现在确实可以用 Fable 一次性搞定大量功能。 Thariq：我记得我收到的第一条关于 Claude Code 的短信。我最好的一个朋友说，“你得去试试 Claude Code。”那大概是 Opus 4 发布的时候，我试了一下，心想，“哦，靠。我现在必须去 Anthropic 工作了。”那可是 Opus 4——很棒的模型，但你还是得盯着权限提示。我们有点健忘，这挺疯狂的，我现在觉得，哦，自动模式一直都在这儿，对吧？我甚至都不记得我点过“是”和“允许”。对我来说，我正努力推动自己去做的一件大事是，我们必须做出比以往质量更高的工作。它的输出质量极高。我用它剪辑了一大堆视频，我心想，好吧，它必须在几个小时内满足我们品牌团队极其严格的要求，否则我们就没法用它。这就是我试图用 Fable 实现的转变：做出我们做过的最好的工作，而且比以往任何时候都快。

传统软件工程中的哪些常规做法已经不再适用了？

3:39

Simon：一年前在传统软件工程中被认为是真理的某件事，你觉得在这个新世界里不再适用了？Cat：我们在工程技能方面看到的最大转变之一：两年前，产品经理去和一群客户沟通，在六个月内与跨职能团队就某个 PRD 达成一致，并在写下第一行代码之前写一份关于我们将如何实现它的详尽规范，这是很典型的做法。现在情况完全反过来了。对于很多工程师，我想给在座的各位的建议是，培养更多的商业直觉和产品直觉，去思考我们到底应该构建什么，因为从有想法到构建出来的时间线大大缩短了——从六到十二个月缩短到甚至可能只要一周。这意味着我们所有人都需要对什么是值得构建的、什么能真正改变我们所从事的业务有更好的品味。因此，在大多数产品领域，产品品味和商业直觉的价值提升了，而执行层面的要求稍微降低了。当然，对于基础设施来说，仍然非常强调确保所有细节都正确无误。Thariq：对我来说，就是现在重写代码是件好事了。Simon：以前你能做的最糟糕的事情现在其实没问题了！Thariq：没错。所有《人月神话》里的那些东西——永远不要重写——我现在支持重写了。如果你有一套好的测试套件——而且我认为重写实际上会迫使你确保拥有一套好的测试套件——但我认为人们低估的是，代码库本身就是一种规范，而且可能是你拥有的唯一一份规范副本，因为没有人知道代码库的每一个分支部分。你可以把它当作一个产物，去提炼它或创建它的其他版本。我们用 Rust 重写了 Bun，效果非常好——它现在对我来说就是实时运行的。Simon：你们还没有在 Bun-in-Rust 上发布 Claude Code，对吧？Thariq：内部我们已经在用了。

（实际上，看起来 Anthropic 已经在 6 月 17 日开始向所有人发布基于 Bun-in-Rust 的 Claude Code 了。）

非工程师人员在使用 Claude Tag 做什么样的事情？

6:36

Simon：最近另一个重磅发布是 Claude Tag——算下来，现在才推出一周左右，至少对我们其他人来说是这样。我了解到在 Anthropic 内部，非工程师群体大量使用它。非工程师们都在用 Claude Tag 做些什么呢？Cat：Claude Tag 是一个存在于你团队协作工具中的 Claude。上周我们在 Slack 中上线了它。Claude Tag 的不同之处在于它默认支持多人协作。一旦你将 Claude Tag 添加到 Slack 频道，你就可以参与进来，你的队友也可以参与进来，你们可以一起协作处理 PR。另一个重大区别是它是主动的，而不是被动的。你可以告诉 Claude Tag：“嘿，监控这个频道里的每一个 bug 报告，提交一个 PR 来修复它，并标记最近修改过这部分代码的工程师”，它就会在频道的整个生命周期内一直这么做，而不需要你手动去标记它。第三个重大转变是我们加入了团队记忆功能。如果你在频道里告诉 Claude Tag 你的偏好，它会在未来的每一次发帖中记住这些偏好。如果你总是希望它调试故障，但不希望它调试警告，只需在频道里用自然语言告诉它，它就会为你和团队里的其他人记住这一点。在内部，我们将 Claude Tag 视为 Claude Code 的进化。我们认为这是内部工作方式的一次重大转变。Claude Tag 目前完成了我们产品工程团队 65% 的 PR。Simon：是整个 Anthropic，还是仅限 Claude Code？Cat：这只是针对我们的产品工程团队——我们内部版本的 Claude Tag 目前完成了我们 65% 的产品 PR。这是一个巨大的转变；这超过了我们 PR 总数的 50%。我们看到人们在 Claude Code 和 Claude Tag 之间分配工作的方式是：当你与智能体进行交互式迭代时，Claude Code 仍然是处理最复杂任务的最佳场所。但 Claude Tag 非常适合让它主动为你工作，这样你就不需要再为正在开发的功能所出现的所有 bug 报告手动启动 Claude Code 了。Thariq：对于非编码场景：例如，在这次演讲之前，我们问了 Claude Tag：“嘿，Fable 什么时候发布？”我们想确保能和公告的时间对上。Claude Tag 会搜索我们的 Slack，看看谁说了什么。作为你公司的搜索引擎，它非常有价值。它拥有你产品的所有上下文，所以你可以问它与指标相关的问题——通常在决策时，你希望根据指标反映的情况来做决定，所以你可以把它连接到你的事件存储库。我看到我们的营销团队做过这样的事情：“嘿，给我讲讲这个功能。”他们不是程序员，但 Claude 是程序员——它可以克隆代码库并说：“这是该功能，这是它的样子，这是我使用该功能的录屏。”它赋能了各种各样的事情，我认为我们在探索这些可能性方面还处于早期阶段。

Claude Tag 作为团队协作层

10:06

Simon：我在使用编程智能体时遇到的一个问题是，我知道作为个人如何使用它们，但不太清楚如何在团队环境中使用。听起来 Claude Tag 是你们目前针对这类团队协作层的解决方案。 Cat：完全正确。实际上，我们很大一部分的会话现在都是多人协作的。比如我可能会说：“嘿，我觉得我们应该在 Cowork 中实现这个新功能”，然后我会 @ Claude Tag 来做第一版。接着我会告诉 Claude Tag：“分享你最终实现的录屏”，然后我会 @ 设计团队来看看。他们会稍作调整，然后交给工程团队去完成最后一步并发布到生产环境。这整个过程非常流畅。我们仍在摸索在同一个会话中协作时的社交动态，但我们发现人们只需观察别人的用法，就会遵循这些社交规范——对我们来说，将 Claude Tag 整合进团队是非常直觉化的。 Thariq：它非常适合用来教人，也能减少低质量产出，因为大家都在看你一起使用 Claude，这也会反过来提升你使用 Claude 的水平。

这让我想起了 Midjourney 是如何通过在其 Discord 频道中强制公开提示词，来解决教人们高级图像提示词这一难题的。

当构建功能的成本大幅降低时，你如何决定哪些功能值得构建？

11:41

我自己觉得非常困难的一件事是，既然实际构建功能的成本已经大幅下降，如何判断一个功能是否值得发布。

Simon：你如何应对工程领域最难的问题——优先级排序？当构建功能的成本变得如此低廉时，你如何决定哪些功能值得构建和发布？ Cat：这确实是个难题。我们有几种应对方法。一是我们每天都在内部使用自己的产品（dogfooding）。每当我们在产品中想做某件事却做不到时，我们不会去寻找其他替代方案，而是直接改进我们的产品以支持该场景。我们内部有非常浓厚的 dogfooding 文化。在向全世界所有人发布产品之前，我们会先在 Anthropic 内部共享，并交给一些早期客户，他们会给出非常诚实的反馈——越犀利越好——然后我们不断迭代，直到人们爱上它。在向全世界发布之前，我们对一个功能必须达到的活跃用户数和留存率设有内部标准。因为这个标准非常明确，每个工程师都知道自己的目标。我认为这也提升了我们的产品打磨水平，因为如果功能不够完善，用户就会流失——那我们就不应该发布这个功能。

用内部用户留存率来决定一个功能是否应该发布，对我来说非常有道理。

你们有没有哪个功能让你感到意外的例子？

12:54

Simon：你有没有一个让你感到惊讶的功能例子？你把它发布出去，参与度直接爆表——本来不太可能发布的东西，结果变成了真正的产品功能。Cat：我确实有一个。我们团队里很多人喜欢远程控制功能。远程控制让你可以使用移动设备，或者网页浏览器中的 Claude，连接到运行在你 CLI 中的本地 Claude Code 会话。我从来没有这种需求，因为我直接在手机上启动任务，它在云端会话中运行，不使用我的本地环境——我想可能是因为我做的编码任务非常简单。这是我之前没有完全理解的事情；我当时想，嘿，人们应该直接设置远程开发环境。但在实践中，一旦我们推出了远程控制，我交流过的很多人告诉我，他们每天晚上做的事情就是把笔记本电脑插上电源，打开一堆远程控制会话，锁屏，然后躺在沙发上用手机控制 Claude Code。所以这已经成为我们现在正在顺应的一种工作流，我最初没明白——但现在我懂了。

在 Claude Code 中，人类会审查生产环境的每一行代码吗？

14:20

本次大会的核心主题之一是审查：人们会花多少精力去审查编程代理为他们编写的代码。我非常想听听 Claude Code 团队对此的看法！

Simon：代码审查是如何运作的？进入 Claude Code 的每一行生产代码是否都有人工审查？如果没有，你们是怎么做的——如何保持质量？Thariq：这在很大程度上取决于任务。对于重要区域，我们有代码所有者。系统提示词就是一个例子，我们有专门的代码所有者——你确实需要获得他们的批准。Simon：所以代码所有者直接对该区域代码的质量负责。Thariq：没错。Cat：而且他们需要批准任何涉及该区域的 PR。Thariq：我们有代码审查 GitHub 机器人来审查所有内容——这适用于每个 PR，而且通常它承担了大部分的审查工作。我在团队中看到的一种情况是，对于更复杂的 PR，你可能会制作一个 artifact 来解释该 PR，以便其他人进行审查。我们在验证、CI/CD 等方面投入了大量精力，以确保任何时候出现故障，我们都有相应的测试。我们有一个非常强大的环境，Claude 可以在其中控制 Claude Code 并对其进行测试。因此，代码审查是一种多管齐下的方法。Cat：总的来说，我们正试图迈向一个不需要人工介入的世界。对于 Claude Code 核心以及其他产品核心的最关键更改，始终会有代码所有者，并且他们会手动审查所有更改。但越来越多地，对于外层的更改，我们实际上让 Claude 代码审查来完全审查这些内容。这听起来可能有些可怕，但我们经历了一个长达六个多月的过程才走到这一步，你需要采取循序渐进的步骤来建立对代码审查的信任。一开始，我们对所有内容都进行人工审查，然后我们逐渐会说，好吧，对于涉及这些文件的代码更改，代码审查已经能 100% 捕捉到其中的问题——所以我们实际上不需要人工来手动审查这些了。当我们进行事故审查时，我们会查看导致事故的 PR，并说，好吧，我们该如何更新代码审查来捕捉到这种情况？——然后我们将这些 PR 添加到 eval set 中，以确保我们未来对代码审查的更改永远不会导致该指标倒退。将人工从代码审查环节中移除是向前迈出的一大步。这听起来可能有些可怕，而且这不是一夜之间就能做到的事情，但通过几个月的基础设施投资，你可以做到这一点，从而让你确信代码审查正在捕捉你所关心的所有问题。

所以关键似乎在于不断迭代自动化审查系统本身，以便随着时间的推移建立对它们的信任。

一个新模型如何影响你对它能做什么和不能做什么的直觉？

17:20

我们深入探讨了 evals——这是整个大会上的另一个热门话题。

Simon：我知道，如果我让 Opus 4.8 构建一个运行 SQL 查询并输出 JSON 的 JSON 端点，它肯定能做对——这不是我需要仔细审查的东西。但当新模型出现时，我不知道如何快速建立对 Fable 的信任，确信它不会搞砸 Opus 没搞砸的事情。新模型是如何影响你对它能做什么和不能做什么的直觉的？ Cat：我们随着时间推移不断建立这个评估库的主要原因，是为了让新模型能够直接替换。当我们有了新模型时，我们会运行整个评估集，确保例如 Fable 严格优于 Opus 4.8——这给了我们直接替换它的信心。 Simon：那些模型评估是针对整个 Anthropic 的，还是 Claude Code 团队专属的？ Cat：两者都有。我们团队有评估，而且我们在 Anthropic 内部的每个代码库都进行代码审查，所以我们也有相关的评估。对于像自动模式这样的功能，我们不仅在 Anthropic 内部的每个用户中进行了评估——我们还委托了多个外部测试人员进行红队测试，创建包含提示词注入和恶意输入的环境，以确保自动模式不会让任何这些攻击通过。

你如何建立信心，确信对系统提示词的微调能带来更好的输出？

18:41

Simon：我想知道我所做的系统提示词改进是否真的改进了产品——这是最基本的产品特定评估形式，但我仍然不太清楚该怎么做。你们在做这件事吗，以至于你们有完全的信心确信对系统提示词的微调能带来更好的输出？ Cat：我们没有完全的信心，但我们做了很多工作来确保性能不会倒退。起点是一套我们信任的外部评估，我们用一套更大的、我们信任的内部评估来补充它。首先，我们主要优化能力：给定一个任务的完整定义和完整的代码库，Claude 是否做出了正确的决定，完全修复了错误，并通过了所有测试？这是起点，也是我们优化的目标，因为它最直接地反映了用户的需求。但是有很多行为会影响用户在使用 Claude Code 时的感受。例如，人们真的不喜欢 Claude Code 说该睡觉了。或者人们真的不喜欢它说：“嘿，我完成了五个部分中的两个——你想让我继续吗？”是的，请继续。所以我们正在建立一套行为评估来捕捉这些问题。随着我们收到用户反馈——请大声向我们反馈你们的用户意见——我们对优先级问题进行排序，逐一解决，并为每个问题建立评估。这并不是 100% 的覆盖率，但提高覆盖率是我们的优先事项。

Claude Code 团队和模型训练团队之间有多少互动？

20:21

Simon：Claude Code 团队与 Anthropic 内部最初训练模型的团队之间有多少互动？这是一种非常紧密的合作关系吗？Cat：在整个 Anthropic，我们的工作都非常紧密。我们经常开会讨论我们对下一代模型能力的期望。我们的研究团队在公开这些信息方面也做得非常出色——我们经常在博客文章中谈论我们如何致力于越来越长周期的任务，以及我们如何训练 Claude 本身使其诚实、无害且有用。我们还投入了大量精力来确保它与你的意图保持一致，即使你的意图表达得比较模糊。当然，请尽量具体地说明你的需求，这样 Claude 就能获得所有的上下文——但即使你不具体，我们也会教导 Claude 做出合理的假设。这是一段卓有成效的合作关系。

系统提示词减少了 80% —— 你们删减了哪些内容？

21:24

这一部分有太多有用的提示技巧了！

Simon: Thariq，你今天早上提到，由于 Claude Fable，Claude Code 的系统提示词减少了 80%。你能详细说说吗？你们去掉了哪些内容？

有趣的是，OpenAI 针对 GPT-5.6 的提示词最佳实践为其最新模型提供了类似的建议：

偏好精简的提示词 移除重复的指令和示例，并简化工具描述，可以提高任务性能和 token 效率。在内部编程智能体评估运行的样本中，采用精简系统提示词的配置将评估得分提高了约 10–15%，同时将总 token 数减少了 41–66%，成本降低了 33–67%。

你们引入新工具的标准是什么？

28:06

Simon: Claude Code 基本上就是一大堆工具。你们引入新工具的标准是什么？你们如何决定什么时候值得在这个层面上做额外的工程开发？ Cat: 你想回答吗？你引入了我们拥有的最好的工具之一。 Thariq: 我引入 ask user question 工具时，我的职业生涯达到了巅峰。这真的很难。特别是对于某些工具——ask user question 是 Claude 用来向你提问的工具——所以很难评估，而且有时这更多是用户偏好的问题。那时我们的评估比较少，所以非常依赖吃自己的狗粮（dogfooding）——或者叫“吃蚂蚁粮”（ant fooding），我们的蚂蚁版本。但总的来说，我们一直倾向于使用更少的工具。我想我们引入的最后一套工具是 task 工具——而且我们尽量给 Claude 更通用的版本来完成任务。

你们的文件编辑工具的最新演进是什么？

29:03

长期以来，我一直对文件编辑工具非常着迷——它们曾是旧版 Aider 代码编辑排行榜的主题，我饶有兴致地观察了它们在不同编程智能体中的演进，从基于搜索和替换，到基于行号，再到更复杂的模式。

Claude API 文档描述了一个推荐用于基于 API 构建的文本编辑工具，但 Claude Code 似乎在这里使用了略有不同的方法。

Simon: 最有趣的工具之一是文件编辑工具——你可以把文件编辑作为一个工具，或者你可以告诉它使用 sed 和 grep 以那种方式做事。你们的文件编辑工具的最新演进是什么？ Thariq: 我们仍然有一个，但例如我们移除了 grep 和其他搜索工具——glob 工具——转而使用原生的 bash。就像我之前在演讲中说的那样，模型更像生物学而不是物理学，而工具设计尤其困难。我不确定 Cat 是否不同意并认为它的评估有科学依据，但我认为工具设计更像是一门艺术，也许——或者是一门生物学。 Cat: 我在很大程度上同意，但总的来说，随着我们引入更多的工具，我们尽量保持较低的工具基数，并确保我们添加的每个工具与其他每个工具都有不同的功能，这样 Claude 就能非常容易地分辨何时调用哪个工具。对于文件编辑，我们保留它的原因实际上是因为我们可以渲染它。当 Claude 进行文件更改时，我们会向人们展示，并且有一个漂亮的专用 UI 显示：你批准对这个文件的编辑吗？我们有一个专用文件编辑工具的原因是为了让我们能确定性地知道 Claude 正在更改文件，这样我们就可以向人们展示这个漂亮的 UI。许多刚上手的新用户仍然非常喜欢这种体验，所以我们保留了它。但对于我们中许多现在处于自动模式的人来说——希望你们不是处于 YOLO 模式——我认为这实际上并不重要，我们可能直接移除文件编辑也完全没问题。

Anthropic 内部对于安全运行 Claude Code 有什么建议？

30:58

这就是提示词注入问题！还有谁比 Anthropic 的员工更适合解释 Anthropic 是如何看待提示词注入攻击导致其 Claude Code 实例失控的风险的呢？

事实证明，他们非常信任自己的 auto mode——并认为正是这个功能促成了 Claude Tag。

Simon：我们来谈谈安全性和保障性。我深知提示词注入的风险，如果别人告诉我的 Claude Code 该做什么，可能会发生很多糟糕的事情。我大部分时间仍然在 YOLO 模式下运行 Claude Code，并对此感到非常内疚。Anthropic 内部对于安全运行 Claude Code 有什么建议？ Cat：为什么不用 auto mode 呢？ Simon：我开始使用 auto mode 了，但我对它的了解还不够，不知道它有多安全。大概从三周前开始，我默认使用 auto mode。 Cat：在 Anthropic 内部，几乎每个人都在使用 auto mode。这是在 Claude Code 中安全地进行长时间运行工作的最佳方式。我们进行了大量的压力测试。我们有数千个评估。我们委托了许多红队成员创建对抗性环境，试图诱骗 Claude Code 执行不良操作，并且我们已经缓解了他们发现的每一个问题。我们将在未来几周内发布一些评估，但我们基本上已经缓解了所有攻击。 Simon：这是一个很大的承诺。 Cat：我们会分享相关的评估供大家评判，但我们在识别 Claude 可能出错的所有方式，然后更新 auto mode 来应对这些问题方面一直非常严谨。它并不能 100% 捕捉所有问题——那样说就太夸张了。但对于我们关注的主要风险类别，比如提示词注入和数据泄露，其风险远低于普通的人类审查员。

我非常期待能进一步了解他们的评估以及验证 auto mode 的方法。

Thariq：简单介绍一下 auto mode 是如何工作的——建立这种心智模型很有用。每当 Claude 进行一轮对话或一次 bash 调用时，都会有一个 Sonnet 分类器来评判该工具调用以及对话的上下文——也就是你的指令。有一些关于权限的事情取决于你的请求：你不想总是授予 git push 权限，但如果你说“把这个推送到 GitHub”，你希望它能执行——而如果你说“不要推送”，你希望它能拒绝。auto mode 就能做到这一点。这种情况经常发生在我身上，Claude 因为非常乐于助人和主动而试图做某事，而 auto mode 看到“不要这样做”并将其呈现出来。因此，它非常擅长处理你在提示词中动态赋予的权限，我认为这非常重要。它还能与我们的沙箱基础设施很好地配合，因为沙箱这种东西有很多不同的边缘情况，我们很难确定性地遵循它们。我们有一个沙箱，当某些操作需要逃离沙箱时——比如网络请求——auto mode 可以查看该请求并询问：这合理吗？——然后允许它执行。 Simon：我还没意识到 auto mode 也会与网络沙箱进行交互。 Cat：它会与用户原本会看到的任何权限提示进行交互。 Simon：auto mode 出现多久了？作为一个我可以使用的功能，它只有几个月的历史，对吧？

（它首次向公众开放是在 3 月 24 日。）

Cat: 我们从一月份起就在 Anthropic 内部使用它了，所以我们已经对它进行了相当长时间的加固。Anthropic 极度关注安全与保障，我们一直在对齐和安全保障团队之间广泛合作，以实现内部推广，构建这些评估，并在向世界发布之前让 auto mode 变得更加稳健。Thariq: 这也是 Claude Tag 如此出色的原因——Claude Tag 使用了 auto mode。我听过很多关于 Slackbot 是自建还是购买的讨论，我的态度是：拜托，你们可能不应该自己构建 AI Slackbot。攻击面太多了。你有一个用户可以发布反馈的反馈频道，现在你的机器人会读取它。我们在 auto mode 上投入的工作——我们有一套通用的“瑞士奶酪”安全防御模型；我们也针对这些东西进行了强化学习（RL）——我认为这才是让 Claude Tag 真正起作用的原因。它与你的权限无缝协作，而且你肯定不希望在你的 Slack 中被提示词注入。

除了 auto mode 之外，还有其他安全方面的计划吗？

35:54

Simon: 除了 auto mode 之外，还有其他超越 auto mode 的安全计划吗？Thariq: 我认为我们非常安全。使用 Claude Tag，你可以为 Claude 提供你自己的凭证，因此它不需要代表你行事——你可以将 Claude 作为一个身份，这也使得审计和检查 Claude 正在做什么变得更加容易。Simon: 因为 Claude Tag 会受到任何能与之对话的人的影响——它有一个大得多的人群在告诉它该做什么。Thariq: 没错。当然，我们在 Fable 中也有探针，这是我们安全和研究工作的下游效应。我认为这一刻你真的能看到 Anthropic 作为一家 AI 安全公司所带来的回报：我们非常希望 Claude 能够在长时间内以对齐的方式运行，而 auto mode 必须基本上完美无缺才能实现这一点——这都是我们作为一家 AI 安全公司的下游成果。Cat: 我们还为那些希望更安全的远程控制用户推出了受信任设备。对于我们所有的远程环境，我们都支持凭证注入。如果你希望 Claude Code 能够访问 Datadog，但又不希望 Claude Code 本身持有 Datadog 凭证，你可以设置我们的身份和凭证管理系统，使得 Datadog 凭证只能被代理使用，而不能被代理访问——当代理尝试发出 Datadog 请求时，我们会动态插入它们。

我非常喜欢这种凭证注入模式，Claude Code 可以通过代理访问 API，而该代理既审计请求又注入相关的 API 密钥——这样 Claude 就可以在不持有 API 凭证本身的情况下访问经过身份验证的端点。

过去一年半的时间如何改变了你对自己手艺的看法？

37:53

Thariq 在今天上午的主题演讲中谈到了 Fable 级模型带来的一种失落感，我们在对话中进一步深入探讨了这个话题。我一直把这称为“深蓝”（Deep Blue）。

Simon：我们来谈谈人的因素。现在很多人感到一种失落感，因为他们认为自己在构建软件中的许多角色正在被模型所取代。你怎么看待这个问题？过去一年半的时间如何改变了你对自己手艺和所创造价值的看法？ Thariq：Cat 和 Boris 很好地提醒了你必须更有雄心。他们总是说：我们增长得这么快，我们必须处于最前沿，我们必须做到最好。这对我来说是一个不断的提醒——每当我在某件事上进展缓慢时，我就会想，好吧，我能做得更快吗？我能在这里更有雄心吗？而通常答案就是 Claude，因为 Claude 会随着你的使用变得越来越好——我上次尝试这个时，用的是之前的模型。关于你提到的失落感：我认为这是真实的。如果你只是试图做和 LLM 出现之前一样的工作，而现在它变成了一个提示词，我想，这确实有点令人伤感。而弥补这一点的方法就是更有雄心。我认为 Jared 就是一个很好的例子——他在奥克兰的公寓里花了大约一年时间手写了所有的 Zig 代码，几乎没离开过家，并且乐在其中。现在我看到他把所有的 Bun 重写成 Rust，他也乐在其中——这要更有雄心得多，这就是他弥补失落感的方式。总的来说，就是问自己如何做更大的事情、做更多的事情——我认为成功是有趣的。这在于改变你的雄心。

“弥补这一点的方法就是更有雄心”这句话很好地概括了我自己在这个问题上得出的结论。

Simon：那么 Cat，从产品管理的角度来看，这具体是怎样的情况？ Cat：我觉得产品这个角色每个月都在变化。我们团队所有的 PM 都是工程师、设计师和 PM 的混合体——他们中大多数人以前实际上是全职工程师。对我们来说，这实际上意味着在任何出现空缺的时候随时补位。如果我们有一个想法，但没有激发任何工程师去构建它，那我们就应该自己去构建它，把它放进 notebook 里，然后激发人们把它推向生产环境。如果设计看起来有点偏差，我们就找一个类似的页面，做一遍初步设计，然后拉一个注重细节的人来填补空白。或者如果我们注意到我们的团队和产品在公司内部的采用率更高了，更多的人需要知道 Claude Code、Claude Tag 和 Cowork 接下来会有什么新动态——那我们就自动化地制定整个发布日历，自动化地异步获取这些状态更新，这样我们就不会打扰别人，并确保我们在内部公告渠道中的更新详尽且切中要害。对我们来说，这很大程度上是理解从一个好想法到把东西交付给客户之间目前的差距是什么，以及我们如何尽可能将其自动化。

这反映了我注意到的一个现象：当你能以快得多的速度产出代码时，因等待他人决策而受阻所花费的时间就会成为一个更加明显的瓶颈。能够做出产品决策的工程师可以走得快得多，而且做出错误决策的代价也不再那么高昂。

Claude 有什么让你感到惊讶的时刻吗？

41:50

Simon：Claude 有没有哪个时刻让你感到惊喜？也就是模型做到了你认为它做不到的事情？ Thariq：我发过很多关于 Claude 视频剪辑的帖子，但最近我在 ACM Agentic 大会上做了一次演讲，我问：“嘿，大家有剪辑好的视频吗？我想把它发出来并分享给我的公关团队。”他们说：“哦，那要花很长时间。”所以我索要了原始文件。他们发给我我在台上讲话的视频、演示文稿的视频和音频文件，并说：“祝你好运。”我把这些连同我的 HTML 演示文稿一起给了 Claude，并说：“嘿，你能把这些剪辑在一起吗？”它做的事情真的令人难以置信——我已经准备好发布了。它转录了整个视频。它注意到有时我的演示文稿视频有点奇怪——中间弹出了一个自动更新的窗口——于是它说：“哦，我可能不应该使用你的演示文稿视频。我要做的是把它切片，弄清楚你在哪张幻灯片上，然后改用 HTML 源码。”所以它展示了 HTML 源码。接着它处理了我的视频，但我只占据了舞台的一小部分，所以它动态裁剪到我在舞台上的位置——而且我在来回走动，所以它在我走动时一直追踪我。同时它还在转录我说的话。 Simon：这是 Fable，对吧？ Thariq：是的，这是 Fable。这是一个很好的提示词，但只是一个单次提示词。然后我让它添加一些有趣的动画和图形，我简直被惊艳到了。它用 ffmpeg，也用 Remotion。

这是 Thariq 关于他如何使用 Fable 来剪辑 Fable 自己的发布视频的视频，而这里就是那个发布视频。

它还做不到什么？

43:36

我很不好意思承认，我一直觉得很难想出像 Fable 5 和 GPT-5.6 这样的前沿模型无法完成的任务。

Cat 仍然不看好它的 UX 设计能力：

Simon：它做不到什么？有哪些事情仍然让你感到失望——你在等待 Claude Fable 6 来帮你解决？ Cat：我希望它有更好的设计和 UX 品味。现在的情况是，如果我写出一个带有详细规格的提示词，说明我希望某个功能如何运作，它通常就会那样运作。但是内边距可能不对，或者界面还不够令人愉悦。它依赖于现有的应用程序设计最佳实践，但对于前沿的 AI 产品，还有许多我们尚未设计的新交互体验。 Simon：有一种 Opus 美学——你可以看着某个东西说：“是的，那是 Opus 设计的。”如果我们能超越这个阶段就好了。 Cat：是的。我非常期待未来的模型有望成为交互设计的思维伙伴。 Thariq：它做不到什么？我很乐意看到它与现实世界进行更多互动。它能解决科学问题吗？它能统筹实验吗？这需要一些编程工作，但它还需要对更广阔世界的另一种品味。

其他公司应该借鉴 Anthropic 文化的哪些部分？

45:11

我觉得这会是一个很好的压轴问题：

Simon: 你认为 Anthropic 公司文化的哪些部分独特地帮助了 Anthropic 高效使用这些工具，并且值得其他公司借鉴？大家应该从你们这里采纳哪些文化技巧？ Cat: 我分享一个关于 Claude Tag 的。当你在公共频道中使用它，并且你的大多数频道都是公开的时候，Claude Tag 的效果最好。Claude Tag 能够搜索所有公共频道以获取尽可能多的上下文，从而为你提供最高准确率的答案——而只有当它能访问所有内容时，它才能做到这一点。 Thariq: 我在主题演讲中提到过这一点，但它对我来说太重要了，我想再次强调。联合创始人说我们不要跟自己妥协，我认为这非常重要。你可以在脑海中想象各种权衡，然后说服自己放弃一些有野心的计划——或者你也可以直接去尝试做那些有野心的事情。我们经常问自己：如果我们直接做了会怎样？这真的是一个权衡吗？如果是，为什么——有什么证据表明这是一个真正的权衡，而不仅仅是听起来合理的事情？让权衡自己显现出来。尽可能保持你的野心。

你用 Claude 做过的最喜欢的一件荒谬的事情是什么，仅仅是因为你能做？

46:46

我也忍不住把这个加了进来。

Simon: 你用 Claude 做过的最喜欢的一件荒谬的事情是什么，仅仅是因为你能做？ Thariq: 我正在做一个 2D 街头霸王格斗游戏，里面有我作为一个角色——还有我的朋友们。它使用 Claude Code 来提示 Gemini——老实说 Seedance 模型相当不错——来制作视频动画。效果很好；它非常擅长写提示词，而且它可以验证帧来检查动画是否做得好。 Simon: 你生成的是街头霸王 2 级别的 2D 精灵图吗？ Thariq: 是的，完全正确——2D 精灵图。动画看起来棒极了。它还能算出判定盒——它会说，“哦，你的拳头在这里，我来画 JSON 判定盒。”这太不可思议了。 Cat: 我的要简单得多。我是一个狂热的攀岩者，我的很多朋友也攀岩，所以我们用 Claude Code 建立了一个小应用，用来记录我们正在进行的所有项目。我们也经常一起去户外，所以我们让 Claude 用 workflows 做所有这些研究。Workflows 非常棒——我们把它定位为一个编码工具，但它用于旅行深度研究也非常出色。我还计划我们团队的异地活动，它很擅长寻找能容纳我们所有人的场地。我用 workflows 研究我们可能想去所有攀岩目的地，以及从我们所有人所在的地方哪里有直飞航班。它会去 Mountain Project 找到所有符合我们等级的攀岩路线。它还会找 Airbnb。我不喜欢徒步，所以我非常在意“接近性”要非常短——从停车的地方到实际岩石的步行距离要非常短——它会对此进行过滤。使用现有的应用程序，我必须手动点击浏览 Mountain Project，但有了这个，我只需输入我们所有的偏好，它就是为我们量身定制的应用程序。 Simon: 所以你基本上是在为攀岩进行 vibe coding Jira。 Cat: 完全正确。

观众：有计划开发评估构建工具和智能体可观测性吗？

49:23

在最后，我们留了几分钟给观众提问。

观众：你们近期有计划构建更多的评估工具供我们创建评估数据集，以及更多的可观测性工具来监控智能体和工作流的性能吗？Cat：我们考虑过构建评估工具，但我认为真正的限制因素往往是客户需要花费很长时间才能构建出真正高质量的评估。所以我认为工具本身并不是主要制约因素，更大的制约在于如何构建优秀评估的技能。在这个领域，我们很乐意在内部进行投入，并希望能在外部分享一些最佳实践。

观众：目前的内存是如何设计的——你们会从文件转向数据存储吗？

50:08

观众（Sai）：我对内存和多人协作很感兴趣。目前的内存是如何设计的？我猜是基于文件的。其次，你们有没有考虑过一个正交的方向，即实际上需要用数据存储而不是文件来保存这些内存，以便更好地扩展？Thariq：目前在 Claude Tag 中，内存是特定于频道的。该频道中的每个 Claude 都有共享内存，并且实例都有一个会话——但会话可以回馈给主内存。我们进行了大量关于内存的研究，但什么是正确的内存处理方式有时并不直观。我们一直在进行内存实验。目前在 Claude Tag 中的运作方式是每个频道一个 markdown 文件。