Simon Willison · 博客

呵

与Claude Code团队的Cat和Thariq围炉对话

A Fireside Chat with Cat and Thariq from the Claude Code team

二〇二六年七月二十一日 · 英文原文
摘要

本月初，Anthropic Claude Code团队Cat Wu与Thariq Shihipar在AI工程师世界博览会主持炉边谈话，讨论Claude Code、Claude Tag、Fable、编码agent安全、评估及工具设计。Claude Tag目前完成产品工程65%的PR，其自动模式是使能技术。Claude Code系统提示因新模型（如Fable 5、Opus 4.8）减少80%，移除示例与“不要做”指令可提升性能。Anthropic内部通过“ant fooding”和内部用户留存率决定功能发布，关键更改仍需人工审查，但外层代码审查已自动化。

本月初，我在AI工程师世界博览会（AI Engineer World's Fair）上与Anthropic Claude Code团队的Cat Wu和Thariq Shihipar共同主持了一场炉边谈话。我们讨论了Claude Code、Claude Tag、Fable、编码agent安全、评估（evals）、工具设计，以及Anthropic自身如何使用这些工具。该环节的完整视频现已在YouTube上发布。以下是经过编辑的文字记录，附有额外链接和我自己加粗的重点。如果你不想观看视频或通读整个文字记录，这里有一些顶层要点：

过去一年，你的日常工作发生了怎样的变化？ 1:05 Simon： Claude Code去年二月推出——到现在还不到一年半，最初它只是Claude Sonnet 3.7发布中的一个要点。既然我们现在有了真正为我们工作的编码agent，过去一年你的日常工作发生了怎样的变化？

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对齐，花费六个月时间，然后在编写第一行代码之前，写出一份关于如何实现它的详尽规范，这是非常典型的做法。现在情况完全反过来了。对于很多工程师来说，我想给在座各位的建议是，更多地培养你对“我们应该构建什么”的商业意识和产品意识，因为从产生想法到构建它的时间线大大缩短了——从六到十二个月缩短到可能只有一周。这意味着我们所有人都需要更好的品味，来判断什么值得构建，什么才能真正影响我们正在做的业务。因此，产品品味和商业意识的价值在提升，而在大多数产品领域，执行的价值则有所降低。当然，对于基础设施（infra）来说，确保所有细节正确仍然非常重要。

Thariq： 对我来说，重写现在变成好事了。

Simon： 以前最不该做的事，现在居然没问题了！

Thariq： 没错。所有《人月神话》里的东西——永远不要重写——我现在支持重写了。如果你有一个好的测试套件——而且我认为重写实际上会迫使你确保有一个好的测试套件——但我认为人们低估的是，代码库就是一个规范，而且它可能是你拥有的唯一一份规范副本，因为没有人知道代码库的每一个分支部分。你可以把这个产物作为工件，提炼它或创建它的其他版本。我们用Rust重写了Bun，效果很好——我现在就在用。

Simon： 你们还没有把Claude Code部署在Rust版的Bun上，对吧？ Thariq： 内部已经部署了。（实际上，看起来Anthropic在6月17日就开始向所有人推送基于Rust版Bun的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目前完成了我们产品工程PR的65%。

Simon： 是针对整个Anthropic，还是仅针对Claude Code团队？ Cat： 这只是针对我们的产品工程团队——我们内部版本的Claude Tag目前完成了我们产品PR的65%。这是一个巨大的转变；这超过了我们PR的50%。我们看到人们在Claude Code和Claude Tag之间分配工作的方式是：Claude Code仍然是你处理最复杂任务的最佳选择，当你与agent进行交互式迭代时。但Claude Tag非常适合让它主动代表你工作，这样你就不再需要为你正在开发的功能出现的所有bug报告手动启动Claude Code了。

Thariq： 对于非编码用例：例如，在这次谈话之前，我们问Claude Tag：“嘿，Fable什么时候发布？”我们想确保它与公告时间一致。Claude Tag会搜索我们的Slack，查看谁在说什么。作为你公司的搜索引擎，它非常有价值。它拥有你产品的所有上下文，所以你可以问它与指标相关的问题——通常当你做决定时，你希望它们有数据支持，所以你可以把它连接到你的事件存储。我看到我们的营销团队做这样的事情：“嘿，给我讲讲这个功能。”他们不是程序员，但Claude是程序员——它可以克隆代码库并说：“这就是这个功能，它看起来是这样的，这是我使用该功能的录屏。”它实现了各种各样的功能，我认为我们仍在探索的早期阶段。

Claude Tag作为团队协作层 10:06 Simon： 我使用编码agent时遇到的一个问题是，我知道如何作为个人使用它们，但我不太清楚如何在团队环境中使用它们。听起来Claude Tag是你们目前针对这类事情的团队协作层的答案。

Cat： 没错。目前我们很大一部分会话实际上已经是多人的了。也许我说：“嘿，我认为我们应该在Cowork中实现这个新功能”，然后我会@Claude Tag来做第一版。然后我会告诉Claude Tag：“分享你最终实现的录屏”，然后我会@设计团队来查看。他们会调整一下，然后交给工程团队完成最后的工作并发布到生产环境。这是一种非常流畅的体验。我们仍在努力解决引导同一会话的社交动态问题，但我们发现人们只是观察别人如何使用它，然后遵循这些社交规范——将Claude Tag集成到我们的团队中对我们来说非常直观。

Thariq： 这对于教导他人很棒，也有助于减少“slop”（低质量输出），因为每个人都能看到你一起使用Claude，这也会提升你使用Claude的水平。这让我想起了Midjourney如何通过在Discord频道中强制公开提示，来解决教导人们高级图像提示的挑战。

当构建成本大幅降低时，如何决定哪些功能值得构建？ 11:41 我发现有一件事非常困难，那就是既然实际构建功能的成本已经大幅下降，如何知道一个功能是否值得发布。 Simon： 你如何应对工程领域最困难的问题——优先级排序？当构建一个功能的成本现在低得多时，你如何决定哪些功能值得构建和发布？

Cat： 这是难点。我们有几种方法。一是我们每天都“吃自己的狗粮”。每当我们在自己的产品中想做某事但做不到时，我们不会寻找其他解决方案，而是修复我们的产品，使其能够支持这种情况。我们内部有非常浓厚的“吃狗粮”文化。在我们与世界分享产品之前，我们会先与Anthropic内部的每个人分享，并与一些早期客户分享，他们会给我们非常诚实的反馈——越尖锐越好——然后我们迭代，直到人们喜欢它。我们有一个内部标准，关于一个功能在分享给世界之前必须达到的活跃用户数和留存率。因为这个标准非常明确，每个工程师都知道他们要达到什么目标。我认为这也提升了我们的精致度，因为如果功能不够精致，用户就会流失——那我们就不应该发布这个功能。使用内部用户留存率来决定一个功能是否应该发布，对我来说非常有意义。

有没有一个让你感到惊讶的功能的例子？ 12:54 Simon： 有没有一个让你感到惊讶的功能的例子？你们推出后，参与度爆表——一个看起来不太可能发布，结果却变成了真正的产品功能。

Cat： 有一个。我们团队很多人喜欢远程控制。远程控制让你可以使用移动设备或网页浏览器中的Claude，连接到你在CLI中运行的本地Claude Code会话。我从来没有这个需求，因为我直接在手机上启动任务，它在云端会话中运行，不使用我的本地环境——我想是因为我做的编码任务非常简单。这是我当时不太理解的东西；我想，嘿，人们应该设置远程开发环境。但实际上，一旦我们推出了远程控制，很多和我交谈的人告诉我，他们每天晚上做的事情就是把笔记本电脑插上电源，打开一堆远程控制会话，锁屏，然后躺在沙发上用手机控制Claude Code。所以这已经成为我们现在正在深入的一个流程，我最初并不理解——但现在我理解了。

Claude Code中的每一行生产代码都有人工审查吗？ 14:20 会议的一个主题是审查：人们花多少精力去审查由编码agent为他们编写的代码。我非常想听听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是否做出了正确的决定，完全修复了bug，并通过了所有测试？这是起点，也是我们优化的目标，因为它最直接地符合用户的需求。但是，有很多行为会影响用户在使用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%。你能详细说说吗？你们能够去掉哪些类型的内容？

Thariq： 不仅仅是Fable——Opus 4.8也是，未来模型也会如此。我们现在为不同的模型使用不同的系统提示。我们看到的一个模式是，我们过度约束了Claude。最初的，可能是Opus 4左右的模型，需要很多示例，而移除示例非常有帮助，因为它比我们给出的示例更有创造力。

Simon： 这真的很有趣，因为我给人们的一个顶级提示技巧是：给它示例。如果这不再正确，那有点打破我的提示模型了。 Thariq： 我也是——听到这个我很惊讶。我认为现在更重要的是你给它的形状——你给Claude的工具、你的系统提示等等。我们做的另一件事是尝试给它更多上下文和更少的“不要这样做”指令，因为这对Claude来说是一个非常强烈的冲动，特别是如果它后来与用户指令冲突，这可能会让Claude非常困惑——“我有这个技能说这个，而系统提示说那个。”所以我们尝试总体上更少的硬约束，更多的上下文，更少的指令。这绝对是一门科学——需要一堆评估来构建。

Cat： 总的来说，当你提示这些模型时，你应该总是思考：我给出的指令是否存在边缘情况？ 当我们回顾并审查Claude Code系统提示中的所有指令时，我们发现了一些情况，是的，这个陈述90%是正确的，但有10%的情况它是不正确的。我们不想约束模型，或者让它困惑，以为它应该总是这样做。一个很好的例子是验证。这里的每个人都希望Claude验证它的工作，我们在提示中有一些指令说：如果你做了前端更改，总是要验证。但这是有限度的。如果它只是将文案从一个字符串改为另一个字符串，而用户说“快速修复并更新测试”，你可能不想验证。所以我们已经调整了措辞，从“总是验证，验证，验证”变成了类似：大多数时候，当你做前端工作时，你无法通过点击后端端点来完全理解体验，所以当你对用户体验进行较大更改时，请本地运行应用程序。事实上，那个指令可能也不好，因为什么是“较大更改”？也许它也应该测试小更改。总的来说，每当你给模型一个提示时，你应该思考一个善意的人可能会如何误解它，以便更好地理解模型可能会如何解释它——并软化提示，使其实际上是100%准确的，因为你100%的时间都在给模型这个提示。

Simon： 有趣的是，你在依赖模型的判断力——这必须是Opus/Fable级别的东西。一年前的模型没有必要的判断力来决定是否要测试一个更改。但是，如果你正在为广泛的模型构建，并试图为更便宜的任务运行更便宜的模型，这就会失效。

Cat： 正是因为这个原因，我们现在每个模型都有不同的系统提示。只有我们最前沿的模型才有这80%的token减少——较旧的模型仍然有完整的系统提示。

Simon： 你认为Fable和Opus足够聪明，可以用更多细节来提示Haiku，因为它们理解Haiku的判断力、品味较差吗？ Cat： 我们还没能评估它——我们没有任何硬数据来证明这一点。 Thariq： 有时较小的模型有一个棘手的问题，因为有时较大的模型在解决难题时可能比较小的模型更节省token。所以需要建立一些直觉——有时你几乎总是想要前沿智能。帕累托曲线在变化，很难找到。

Simon： 一年前，我不相信模型能写提示。今天，好的模型非常擅长提示——我的很多提示都是由模型写的，这感觉荒谬但效果很好。帮助我接受这一点的是思考子agent（subagents），这完全是一个Claude模型为另一个Claude模型设置提示。Thariq： 工作流（workflows）实际上是一个很好的例子，因为Claude不仅仅是提示一个子agent，而是提示多个子agent的编排，每个子agent都会得到一个非常详细的提示。这几乎比仅仅生成一个子agent高了一个层次。我还在我自己的机器上使用它，给它Gemini API并说：来，生成图片。它比我提示图像模型要勤快得多。这完全是Claude提示Claude，一路到底。

Cat： 我认为Claude也为工作流工具写了提示。 Simon： 我读过那个提示——是个好提示。这实际上是我对Anthropic的一个挫败感：你们发布了Claude Chat的提示，但没有包含工具提示和Claude Code的提示。我仍然需要运行一个代理来拦截它们。如果Claude Code的提示能被有意发布，我会非常喜欢——它们就是文档。它们是你了解工具能做什么以及如何工作的方式。 Cat： 我会记下这个功能请求。我会让Claude Tag来做。

有趣的是，OpenAI针对GPT-5.6的提示最佳实践也为其最新模型提供了类似建议：倾向于更精简的提示。移除重复的指令和示例，简化工具描述，可以提高任务性能和token效率。在一份内部编码agent评估运行的样本中，配置了更精简系统提示的配置将评估分数提高了大约10-15%，同时将总token减少了41-66%，成本降低了33-67%。

你引入一个新工具的标准是什么？ 28:06 Simon： Claude Code基本上是一个大工具包。你引入一个新工具的标准是什么？ 你如何决定何时值得在那个层面进行额外的工程工作？

Cat： 你想回答吗？你引入了我们最好的工具之一。 Thariq： 当我引入“询问用户问题”工具时，我的职业生涯达到了顶峰。这真的很难。特别是对于某些工具——“询问用户问题”是Claude用来问你的工具——所以很难评估，有时这更像是用户偏好问题。那时我们的评估较少，所以它非常基于“吃狗粮”——或者“ant fooding”，我们的蚂蚁版本。但总的来说，我们一直试图趋向于更少的工具。我们引入的最后一组工具，我想是任务工具——我们试图给Claude更通用的版本来做事。

文件编辑工具的最新演进是什么？ 29:03 我对文件编辑工具有着长期的兴趣——它们是旧的Aider代码编辑排行榜的主题，我饶有兴趣地观察着它们在不同编码agent中的演进，从基于搜索替换到基于行号再到更复杂的模式。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实例失控的风险？事实证明，他们非常信任他们的自动模式——并将其视为使Claude Tag成为可能的功能。 Simon： 让我们谈谈安全性和保障。我深知提示注入的风险，如果别人告诉我的Claude Code该做什么，可能会发生很多坏事。我仍然主要在YOLO模式下运行Claude Code，并对此感到非常内疚。Anthropic内部关于安全运行Claude Code的建议是什么？

Cat： 为什么不用自动模式？ Simon： 我开始使用自动模式了，但我对它还不够了解，不知道它有多安全。大约三周前，我开始默认使用自动模式。 Cat： 总的来说，在Anthropic内部，几乎每个人都使用自动模式。这是在Claude Code中安全地进行长时间运行工作的最佳方式。我们进行了广泛的压力测试。我们有数千个评估。我们委托了许多红队成员创建对抗性环境，以诱使Claude Code执行不良操作，并且我们已经缓解了他们发现的每一个问题。我们将在未来几周发布一些评估，但我们几乎已经缓解了所有攻击。

Simon： 这是一个很大的声明。 Cat： 我们会分享评估结果，以便大家评估，但我们非常勤勉地识别了Claude可能出错的所有方式，然后更新自动模式来应对。它不能100%捕捉到所有事情——那将是一个过于强烈的声明。但对于我们所关心的主要风险类别，如提示注入和数据泄露，风险远低于普通的人工审查员。我非常期待了解更多关于他们的评估和验证自动模式的方法。

Thariq： 简单说一下自动模式的工作原理——建立这个心智模型很有用。每当Claude执行一个轮次或一个bash调用时，都有一个Sonnet分类器在判断工具调用以及对话的上下文——你的指令。有一些关于权限的事情取决于你的请求：你不想一直授予git push权限，但如果你说“push this to GitHub”，你希望它去做——如果你说“不要push”，你希望它拒绝。自动模式会做到这一点。我经常遇到这种情况，Claude试图做一些事情，因为它非常乐于助人和主动，而自动模式看到“不要这样做”并把它提出来。所以它擅长处理你在提示中自己给出的动态权限，我认为这非常重要。它也能很好地与我们的沙箱基础设施配合工作，因为沙箱是那种有很多不同边缘情况，我们很难确定性地跟踪它们的东西。我们有一个沙箱，当某些东西需要逃逸沙箱时——比如一个网络请求——自动模式可以查看那个请求并问：这合理吗？——并允许它。

Simon： 我没想到自动模式也在与网络沙箱交互。 Cat： 它与用户否则会看到的任何权限提示进行交互。 Simon： 自动模式有多久了？作为一个我能访问的功能，它才推出几个月，对吧？（它于3月24日首次向公众开放。） Cat： 我们从一月份开始在Anthropic内部使用它，所以我们已经加固了相当长一段时间。Anthropic非常注重安全和保障，我们一直在与我们的对齐和安全团队广泛合作，以实现内部部署，建立这些评估，并在与世界分享之前使自动模式更加健壮。

Thariq： 这也是Claude Tag如此出色的原因——Claude Tag使用自动模式。我听到很多关于构建还是购买Slack机器人的问题，我想说：拜托，你可能不应该构建你自己的AI Slack机器人。有太多的攻击向量。你有一个反馈频道，用户可以发布反馈，现在你的机器人正在读取它。我们在自动模式上投入的工作——我们有一个通用的瑞士奶酪安全防御；我们还针对这些东西进行RL——我认为这正是让Claude Tag工作的原因。它与你的权限无缝协作，你不想在你的Slack中被提示注入。

除了自动模式，还有更多的安全措施在计划中吗？ 35:54 Simon： 除了自动模式，还有更多的安全措施在计划中吗？

Thariq： 我认为我们已经非常安全了。使用Claude Tag，你可以为Claude配置你自己的凭证，所以它不需要代表你行事——你可以将Claude作为一个身份，这也使得审计和检查Claude在做什么变得更容易。

Simon： 因为Claude Tag会受到任何能与它交谈的人的影响——它有更广泛的人群告诉它该做什么。 Thariq： 没错。当然，我们还有Fable的探测，这是我们安全和研究工作的下游效应。我认为这是你看到Anthropic作为一家AI安全公司真正产生回报的时刻：我们真的希望Claude能够以对齐的方式长时间运行，而自动模式必须基本无懈可击才能实现这一点——这都是我们作为AI安全公司的下游结果。

Cat： 我们还为那些希望更安全的远程控制用户推出了受信任设备。对于我们所有的远程环境，我们支持凭证注入。如果你希望Claude Code能够访问Datadog，但你不希望Claude Code本身持有Datadog凭证，你可以设置我们的身份和凭证管理系统，这样Datadog凭证只能由agent使用，但agent无法访问——当agent尝试发出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会议上做了一个演讲，我问：“嘿，你们有编辑好的视频吗？我很想发布它并与我的通讯团队分享。”他们说：“哦，这需要很长时间。”所以我要了原始文件。他们给我发了我演讲的视频、幻灯片的视频和音频文件，并说：“祝你好运。”我把这些给了Claude，连同我的HTML幻灯片，并说：“嘿，你能把这些编辑在一起吗？”它做的事情真是令人难以置信——我已经准备好发布了。它转录了整个视频。它注意到有时我的幻灯片视频有点奇怪——中间有一个自动更新的弹窗——然后它说：“哦，我可能不应该使用你的幻灯片视频。我要做的是把它切片，找出你在哪一页，然后改用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用工作流来做所有的研究。工作流太棒了——我们把它标榜为编码工具，但它对于旅行做深度研究也很棒。我还用它来计划我们的团队外出活动，它很擅长找到能容纳我们所有人的场地。我用工作流来研究我们可能想去的所有攀岩目的地，以及哪些地方有从我们所有人所在地直飞的航班。它会去Mountain Project找到所有我们难度级别的攀岩路线。它会找到Airbnb。我不喜欢徒步，所以我非常关心接近路线要非常短——从停车的地方到实际岩石的步行距离非常短——它会为此进行筛选。用现有的应用，我必须手动点击Mountain Project，但有了这个，我只需输入我们所有的偏好，它就成了我们的定制应用。

Simon： 所以你基本上是在为攀岩做“氛围编码”（vibe coding）版的Jira。 Cat： 没错。

观众提问：有计划构建评估工具和agent可观测性工具吗？ 49:23 最后我们留了几分钟给观众提问。 观众： 你们有近期计划构建更多的评估工具，让我们构建评估数据集，以及更多的可观测性工具来监控agent和工作流的性能吗？

Cat： 我们考虑过构建评估工具，但我认为限制因素实际上往往是客户需要很长时间才能构建出真正高质量的评估。所以我认为工具本身不是限制，更多的是如何构建出色评估的技能。这是一个我们既兴奋于内部投资，也希望未来能分享一些最佳实践的领域。

观众提问：记忆是如何设计的——你们会从文件转向数据存储吗？ 50:08 观众（Sai）： 我对记忆和多人协作很感兴趣。记忆目前是如何设计的？ 我假设它是围绕文件的。其次，你们有没有考虑过一个正交方向，即实际上需要一个数据存储来存储这些记忆，而不是文件，以便更好地扩展？

Thariq： 目前对于Claude Tag，记忆是特定于频道的。该频道中的每个Claude都有一个共享记忆，实例有一个会话——但会话可以贡献回主记忆。我们做了很多记忆研究，正确的记忆方式可能并不直观。我们一直在进行记忆实验。目前它在Claude Tag中的工作方式是每个频道一个markdown文件。

标签：ai, prompt-engineering, generative-ai, llms, anthropic, annotated-talks, coding-agents, claude-code, thariq-shihipar, cat-wu

译自 Simon Willison · 博客 · 录于 二〇二六年七月二十一日