Jul 22, 2026

Simon Willison × Claude Code 团队：围炉对话——编程代理、Claude Tag、系统提示词与编码的未来（2026-07-22）

本文为翻译/转载，原文使用 CC BY-NC-SA 4.0 协议发布。原文作者：Simon Willison 原文标题：A Fireside Chat with Cat and Thariq from the Claude Code team 原文链接：https://simonwillison.net/2026/Jul/21/cat-and-thariq/ 原文发布：2026-07-21 本博客不参与任何商业变现（含 ads / 付费 / affiliate），本译文遵循 CC BY-NC-SA 4.0 条款发布。

【译者按】

这篇对话发生在 2026 年 7 月的 AI Engineer World’s Fair 上，Simon Willison 与 Anthropic Claude Code 团队的产品负责人 Cat Wu 和工程师 Thariq Shihipar 进行了一场极其坦诚的围炉对话。彼时，Claude Tag（Anthropic 的 AI Slack 协作工具）刚发布一周、Claude Fable 5 刚解决订阅危机、Claude Code 的 system prompt 刚刚暴减 80%——几乎每个话题都是当下最新鲜的行业热点。

对于中文读者而言，这篇对话的价值在于：它不是 PR 公关稿，而是 Anthropic 团队内部实践的坦诚输出——包括他们在代码审查中逐步”去掉人类”的过程、用内部留存率决定是否发版的方法论、以及针对 AI Slackbot 安全性的”瑞士奶酪防御”思维。这些经验比任何官方文档都更贴近实战。中文圈目前还在大量使用”给 AI 举例子”的旧式提示工程，而这篇对话直接宣告了那个时代对前沿模型已经结束。

【正文】

本月早些时候，我在 AI Engineer World’s Fair 上与 Anthropic Claude Code 团队的 Cat Wu 和 Thariq Shihipar 主持了一场围炉对话。我们讨论了 Claude Code、Claude Tag、Fable、编程代理安全、评估方法、工具设计，以及 Anthropic 自己如何使用这些工具。

完整视频现已在 YouTube 上线。以下是经过编辑的对话实录，附有额外链接和我加粗的重点。

如果你不想看视频或通读全文，这里是一些顶级要点：

Claude Tag（Claude 的新协作 Slack 集成）现在完成了 Claude Code 团队65% 的产品工程 PR。
Claude Code 的功能先对 Anthropic 员工开放，只有证明了用户留存率的功能才会正式发布。
对 Claude Code 的关键变更仍需人工审查，但团队越来越依赖自动化代码审查来处理产品的”外层”变更。
对于 Fable 5 乃至 Opus 4.8 这样的模型，在 system prompt 中加示例已不再是最佳实践。Claude Code 的 system prompt 最近缩减了 80% 的规模。
同样，“不要做 X，不要做 Y”之类的列表也会降低最新模型的输出质量。
Anthropic 内部的”dogfooding”（吃自己的狗粮）被称为 “ant fooding”。
Anthropic 非常相信他们的 auto mode，并将其视为 Claude Tag 的基础技术。
Thariq 建议用”更有野心”来抵消编程代理带来的”深蓝”（Deep Blue）焦虑。
Fable 在视频剪辑方面表现胜任，Thariq 用它剪辑了 Fable 自己的发布视频。
Anthropic 在内部”透明工作”的文化是他们成功的关键，Claude Tag 在其公开 Slack 频道中的使用方式正体现了这一点。

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

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——很好的模型，但你还是要读权限提示。有趣的是我们的健忘症有多严重——我觉得，“哦，auto mode 不是一直在吗？“我甚至不记得按过”是”和”允许”。对我来说，我在努力推动自己的是我们必须做出比以前任何时候质量更高的工作。输出质量已经非常高。我一直在用它做很多视频剪辑，它必须在几小时内满足我们品牌团队极其严格的要求——否则就做不了。这就是我想通过 Fable 实现的转变：用比以往更快的速度，做出我们有史以来最好的工作。

有什么传统的软件工程原则已经不再成立？

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 做什么？

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 的 65%，还是只是 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 作为团队协作层

Simon： 我在使用编程代理时遇到的一个问题是，我知道如何作为个人使用它们，但我不太清楚如何在团队环境中使用它们。听起来 Claude Tag 是你们当前对这个问题的答案——作为团队协作层。

Cat： 没错。我们现在有很大比例的会话实际上是多人模式。比如我说：“嘿，我觉得我们应该在 Cowork 中实现这个新功能。“然后我@Claude Tag 先做一版。然后我告诉 Claude Tag：“分享你最终实现的录屏。“然后我@设计团队看一下。他们给出意见，然后传给工程团队做最后冲刺并发布到生产环境。这是一个非常流畅的体验。我们仍在摸索共同操纵同一会话的社交动态，但我们发现人们只是观察别人怎么用，然后遵循那些社交规范——将 Claude Tag 融入我们的团队已经相当直观了。

Thariq： 这对教学也很有帮助，还能减少”屎山”，因为所有人都能看到你如何使用 Claude，这本身就提升了每个人使用 Claude 的水平。

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

当构建成本变得如此低廉，如何决定哪些功能值得构建？

Simon： 你怎么处理工程中最难的问题——优先级排序？当构建一个功能的成本如此低廉时，你如何决定哪些功能值得构建并发布？

Cat： 这是最难的事情。我们有几种方法。一个是我们每天都吃自己的狗粮。每当我们在自己的产品中想做某事但做不到时，我们不会去找其他解决方案，而是修复我们的产品来支持这个场景。我们内部有非常浓厚的 dogfooding 文化。 在我们将产品分享给全世界之前，我们先分享给 Anthropic 内部的每个人，以及一些早期客户，他们会给出非常诚实的反馈——越直接越好——然后我们迭代直到人们喜欢它。我们有一个内部门槛，衡量一个功能在分享给世界之前需要达到的活跃用户数和留存率。 因为这个门槛非常明确，每个工程师都知道他们要达到什么目标。我认为这也提升了我们的打磨水准，因为如果一个功能不够精致，人们会流失——那我们就不该发布它。

用内部用户留存率来决定是否发布一个功能——这个思路非常有道理。

有没有让你惊喜的功能例子？

Simon： 有没有一个让你感到惊喜的功能的例子？ 你发布后参与度爆表——一个本不觉得会火却变成了真正的产品功能？

Cat： 确实有一个。我们团队很多人喜欢 remote control（远程控制）。 Remote control 让你用移动设备或网页浏览器中的 Claude，连接到你在 CLI 中运行的本地 Claude Code 会话。我从来没有这个需求，因为我直接在手机上启动任务，然后在云端运行，不使用我的本地环境——我想是因为我做的编码任务都很简单。一开始我并不理解；我想，嘿，人们应该设置远程开发环境。但实际上，一旦我们推出了 remote control，这么多跟我聊过的人告诉我，他们每晚的做法是：把笔记本电脑插上电源，打开一堆远程控制会话，锁屏，然后从沙发上用手机控制 Claude Code。这已经成为了我们正在深入投入的工作流程——我最初没有理解，但现在我理解了。

Claude Code 的每一行生产代码都会被人类审查吗？

Simon： 代码审查是怎么做的？进入 Claude Code 的每一行生产代码都有一个人来审查吗？ 如果没有，你们在做什么——如何保证质量？

Thariq： 这很大程度上取决于任务。对于重要的领域，我们有代码负责人。 system prompt 就是一个例子——我们有代码负责人，你必须得到他们的批准。

Simon： 所以代码负责人直接对该领域代码的质量负责。

Thariq： 对。

Cat： 他们需要批准任何涉及该领域代码的 PR。

Thariq： 我们有我们的代码审查 GitHub bot 审查一切——它参与每一个 PR，而且通常它做大部分的审查工作。我在团队中看到的一个情况是，对于更复杂的 PR，你可能会创建一个 artifact 来解释这个 PR，这样其他人就可以审查。我们在验证、CI/CD 等方面投入了很多，以确保任何失败都有对应的测试。我们有一个非常健壮的环境，Claude 可以控制 Claude Code 并测试它。所以代码审查有多种手段。

Cat： 总的来说，我们正在努力走向一个人类不需要在循环中的世界。对于 Claude Code 核心以及其他产品核心的最关键变更，始终有一个代码负责人，他们会手动审查所有变更。但越来越多地，对于”外层”的变更，我们实际上让 Claude 的代码审查来完全审查那些。这听起来有点吓人，但我们经过了一个超过六个月的渐进过程才走到这一步，建立对代码审查的信任需要一步步来。一开始我们对所有东西都做人工审查，然后逐渐地我们说，好，对于涉及这些文件的代码变更，代码审查能 100% 捕获所有问题——所以我们实际上不再需要人工手动审查那些了。而当我们进行事故复盘时，我们查看导致事故的 PR，然后说，好，我们如何更新代码审查来捕获这个问题？ ——我们把这些 PR 拿来，加入 eval 集，确保将来对代码审查的修改不会让那个指标退步。把人类从代码审查循环中移除是一个很大的进步。听起来可能有点吓人，也不是一夜之间就能做到的事，但你可以通过对基础设施进行数月的投资来实现，从而获得代码审查能捕获所有你在意的问题的信心。

关键似乎在于不断迭代自动审查系统本身，以逐渐建立对它们的信任。

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

Simon： 我知道 Opus 4.8，如果我要它构建一个运行 SQL 查询并输出 JSON 的 JSON 端点，它一定能做对——这不是我需要仔细审查的东西。但新模型来了，我不知道如何快速建立对 Fable 的信任，不让它搞砸 Opus 不会搞砸的事。新模型如何影响你对它能做什么不能做什么的直觉？

Cat： 我们不断构建 eval 基础的主要原因，是为了让新模型可以成为即插即用的替代品。当有新模型时，我们运行整个 eval 集，确保比如 Fable 严格优于 Opus 4.8——这给了我们信心直接替换上去。

Simon： 这些模型评估是整个 Anthropic 的，还是 Claude Code 团队自己用的？

Cat： 两者都有。我们团队有自己的 eval，而且我们在 Anthropic 内的每一个仓库上都运行代码审查，所以我们有对应的 eval。对于像 auto mode 这样的东西，我们不仅有在所有 Anthropic 用户上的 eval——我们还委托了多个外部测试人员进行红队测试，创建包含提示注入和恶意输入的环境，确保 auto mode 不会让其中任何一个通过。

如何建立对 system prompt 改动能产生更好输出的信心？

Simon： 我想知道我对 system prompt 的改进是否真的改善了产品——这是最基本的产品级评估，我仍然没有很好的方法来做这件事。你们是否做到了可以完全确信对一个 system prompt 的修改能带来更好的输出？

Cat： 我们没有完全的信心，但我们做了很多来确保不回归性能。 起点是一套我们信任的外部 eval，我们用一套更大的内部 eval 来补充。首先，我们主要优化的是能力：给定一个完整的任务定义和完整的代码库，Claude 是否能做出正确的决策、完全修复 bug、并通过所有测试？这是我们的起点和优化目标，因为它最直接地反映了用户想要的东西。但还有很多行为会影响用户与 Claude Code 协作时的感受。比如，人们真的很不喜欢 Claude Code 说”该去睡觉了”。或者人们真的很不喜欢它说：“嘿，我完成了五部分中的两部分——你要我继续吗？“是的，请继续。所以我们正在建立一套行为评估来捕获这些。 随着我们获得用户反馈——请大声告诉我们你们的反馈——我们对优先级问题进行排序，逐个解决并为每个问题构建 eval。这不是 100% 的覆盖率，但这是我们正在努力提升的方向。

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

Simon： Claude Code 团队与在 Anthropic 训练模型的团队之间有多少互动？ 合作密切吗？

Cat： 在整个 Anthropic，我们都紧密合作。我们经常开会讨论我们对下一代模型的期望。我们的研究团队在公开透明方面也做得很好——我们经常在博客文章中谈到我们正致力于越来越长的”长程任务”，以及我们如何训练 Claude 诚实、无害且有用。我们还投入了大量精力确保它能够理解你的意图，即使你的表达有些模糊。当然，尽量具体地说明你想要什么，这样 Claude 就有所有上下文——但即使你不具体，我们也教 Claude 做出合理的假设。这是一个富有成效的合作关系。

system prompt 减少了 80%——你们去掉了什么？

Simon： Thariq，你今天上午提到由于 Claude Fable，Claude Code 的 system prompt 减少了 80%。能详细说说吗？你们去掉了什么样的内容？

Thariq： 不只是 Fable——Opus 4.8 也是这样，未来的模型也会如此。我们现在为不同模型准备了不同的 system prompt。我们看到的一个模式是，我们过度约束了 Claude。早期的 Opus 4 等模型需要很多例子，而去除例子非常有帮助，因为模型比我们给它的例子更有创造性。

Simon： 这很有意思，因为我给人们的一个顶级提示就是：给它例子。如果这个不再成立了，那有点颠覆我的提示工程认知。

Thariq： 我也是——我听到这个时也很惊讶。我认为现在更重要的是你给它的”形状”——你给 Claude 的工具、你的 system prompt 等。我们做的另一件事是尝试给它更多上下文和更少的”不要这样做”指令，因为这对 Claude 来说是一个很强的冲动，尤其如果它后来与用户的指令冲突，那会让 Claude 非常困惑——“我有这个技能说这样，system prompt 又说那样。“所以我们努力做到更少的硬约束，更多的上下文，更少的指令。这确实是一门科学——需要大量的 eval 来构建。

Cat： 一般来说，在给这些模型写提示时，你应该始终思考：我给的这个指令有没有边缘情况？ 当我们重新审查 Claude Code system prompt 中的所有指令时，我们发现了一些情况，其中这句话 90% 正确，但确实有 10% 的情况它不成立。我们不想约束模型，或让它困惑，认为总是应该这样做。一个很好的例子是验证。每个人都希望 Claude 验证它的工作，我们的提示中有一些指令说：如果你做了前端变更，一定要验证。但这有个限度。如果只是把一段文案改成另一段文案，而用户说”快速修复一下，更新测试”，你可能不需要验证。所以我们已经把措辞从”总是验证，验证，验证”调整成了类似：大多数情况下当你在做前端工作时，你无法完全通过后端端点来理解体验，所以当你在用户体验方面做了较大的改动时，请在本地运行应用。而说实话，这个指令可能也不够好，因为什么是”较大的改动”？ 也许小的改动也应该测试。总之，每当你给模型写提示时，你应该思考一个善意的人可能如何误解它，以便更好地理解模型可能如何解读——然后软化提示，使其 100% 准确，因为你 100% 的时间都在给模型这个提示。

Simon： 令人着迷的是你们依赖模型的判断力——这必须是 Opus/Fable 级别才做得到的。一年前的模型没有足够的判断力来决定是否测试一个变更。但如果你要为各种模型构建产品，并尝试用更便宜的模型处理更便宜的任务，这个方案就不适用了。

Cat： 正是因为这个原因，我们现在每个模型有不同的 system prompt。只有最前沿的模型才有这 80% 的 token 缩减——较老的模型仍然保留完整的 system prompt。

Simon： 你觉得 Fable 和 Opus 是否足够聪明，能为 Haiku 写更详细的提示，因为它们理解 Haiku 的判断力和品味较差？

Cat： 我们还没有办法评估——没有硬数据来证明这一点。

Thariq： 小模型有时有个棘手的问题，因为有时候大模型处理一个难题时反而比小模型更 token 高效。所以需要建立一些直觉——有时你几乎总是想要前沿智能。帕累托曲线在移动，很难找到最佳点。

Simon： 一年前我不信任模型来写提示。今天好的模型非常善于写提示——我的很多提示都是模型写的，这感觉很荒谬但效果很好。让我接受这一点的是思考子代理（subagents）的概念——本质上就是 Claude 为另一个 Claude 模型设置提示。

Thariq： 工作流（Workflows） 实际上是一个很好的例子，因为 Claude 不仅仅是提示单个子代理，而是提示多个子代理的编排，每个子代理都得到一个非常详细的提示。这几乎比单纯生成一个子代理高了一个层级。我还在我的个人机器上使用它，给它 Gemini API 说：来，生成图片。它比我本人提示图像模型勤奋多了。简直是 Claude 提示 Claude 一路向下。

Cat： 我觉得工作流工具的提示也是 Claude 写的。

Simon： 我读过那个提示——写得不错。实际上这是我对 Anthropic 的一个不满：你们公布了 Claude Chat 的提示，但没有包括工具提示和 Claude Code 的提示。我仍然需要运行代理来拦截它们。我真希望 Claude Code 的提示被正式发布——它们是文档。它们是你了解这个工具能做什么以及如何工作的方式。

Cat： 我记下这个功能请求了。我会让 Claude Tag 去做。

有趣的是，OpenAI 针对 GPT-5.6 的最新提示工程最佳实践也包含类似建议：

偏好精简提示

移除重复指令和示例，简化工具描述，可以提升任务性能和 token 效率。在内部编程代理 eval 运行的样本中，精简 system prompt 的配置使评估分数提高了约 10-15%，同时总 token 减少了 41-66%，成本降低了 33-67%。

引入一个新工具的门槛是什么？

Simon： Claude Code 本质上就是一大包工具。引入一个新工具的门槛是什么？ 你如何决定什么时候值得在那个层面做额外的工程工作？

Cat： 你要回答吗？你介绍过我们最好的工具之一。

Thariq： 我的职业巅峰就是引入了”ask user question”（向用户提问）工具。这真的很难。尤其对一些工具来说——“ask user question”是 Claude 用来问你的工具——所以很难评估，有时这更偏向用户偏好。那时候我们的 eval 更少，所以主要靠 dogfooding——或者说”ant fooding”，我们内部版本的”蚂蚁食粮”。但总的来说，我们一直倾向于减少工具的数量。我想我们上次引入的一套工具是 task tool——我们努力给 Claude 更通用的版本来做事。

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

Simon： 最有趣的工具之一是文件编辑工具——你可以把文件编辑作为一个工具，或者告诉它使用 sed 和 grep 来做事情。文件编辑工具有什么最新的演进？

Thariq： 我们仍然有一个，但比如我们移除了 grep 和其他搜索工具——glob 工具——转而使用原生 bash。就像我今天上午说的，模型更像生物学而不是物理学，工具设计尤其困难。我不确定 Cat 是否不同意，觉得这其中有科学评估方法，但我觉得工具设计更像一门艺术——或者说生物学。

Cat： 我在很大程度上同意，但总的来说，随着我们引入更多工具，我们努力保持较低的工具数量，并确保每个工具有区别于其他工具的独特功能，以便 Claude 能很容易地区分何时调用哪个。对于文件编辑，我们保留它的原因实际上是因为我们可以渲染它。我们在 Claude 做文件变更时向用户展示一个漂亮的专用 UI，说：你批准这次对这个文件的编辑吗？我们之所以有专门的文件编辑工具，是因为我们希望能够确定性地知道 Claude 正在做文件变更，这样我们就可以向用户展示这个漂亮的 UI。很多刚上手的新用户仍然很喜欢这个体验，所以我们保留了下来。但对于很多已经使用 auto mode 的人来说——希望你不是在使用 YOLO 模式——我觉得这其实不重要，我们可能可以直接移除文件编辑工具，完全没问题。

Anthropic 内部关于安全运行 Claude Code 的建议是什么？

Simon： 我们来谈谈安全。我深刻意识到提示注入的风险，如果别人告诉我的 Claude Code 做什么，可能会发生很多坏事。我仍然主要在 YOLO 模式下运行 Claude Code，并为此感到极度内疚。Anthropic 内部关于安全运行 Claude Code 有什么建议？

Cat： 为什么不用 auto mode？

Simon： 我开始在用 auto mode 了，但我不够了解它有多安全。大概三周前，我开始默认使用 auto mode。

Cat： 在 Anthropic 内部，几乎每个人都在用 auto mode。这是安全地在 Claude Code 中进行长时间工作的最佳方式。我们做了广泛的安全测试。我们有数千个 eval。我们委托了许多红队测试人员创建对抗性环境来诱骗 Claude Code 执行恶意操作，我们已经缓解了他们发现的每一个问题。我们将在未来几周发布一些 eval，但我们基本上已经缓解了所有攻击。

Simon： 这是个大话。

Cat： 我们会分享 eval 结果让大家评估，但我们已经非常勤勉地识别了所有 Claude 可能出错的方式，并更新了 auto mode 来防范。它不能 100% 捕获所有东西——那样说就太过了。但对于我们关心的主要风险类别，比如提示注入和数据泄露，风险远低于普通人肉审查员。

我非常期待了解更多关于他们的 eval 以及验证 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 极其关注安全，我们一直在与对齐和安全团队广泛合作，以推动内部部署、构建这些 eval，并在分享给世界之前让 auto mode 更加健壮。

Thariq： 这也是 Claude Tag 为什么这么好的原因——Claude Tag 使用了 auto mode。我听到很多关于 Slackbot 是自建还是购买的讨论，我想说：拜托，你们可能不应该自己构建 AI Slackbot。有太多的攻击面了。你有一个用户可以发布反馈的反馈频道，现在你的 bot 正在读取它。 我们在 auto mode 上的投入——以及我们有一个通用的瑞士奶酪防御机制用于安全；我们还用 RL 对此进行对抗训练——我认为这才是 Claude Tag 能够工作的真正原因。它能无缝地与你的权限协同工作，而且你不想在你的 Slack 中被提示注入。

除了 auto mode，还有更多安全方面的东西在开发中吗？

Simon： 除了 auto mode，还有更多安全方面的发展吗？

Thariq： 我觉得我们非常安全了。使用 Claude Tag，你可以为 Claude 配置自己的凭据，这样它不需要以你的名义行动——你可以让 Claude 作为一个身份，这也更容易审计和检查 Claude 在做什么。

Simon： 因为 Claude Tag 受任何能与它交谈的人影响——它有一个更广泛的人群来告诉它做什么。

Thariq： 没错。而且当然，我们还有 Fable 的探测（probes），这是我们安全和研究工作的下游成果。我认为这是你看到 Anthropic 作为 AI 安全公司真正产生回报的时刻：我们真的希望 Claude 能够在很长一段时间内以对齐的方式运行，而 auto mode 必须基本上无懈可击才能做到这一点——这都是我们作为 AI 安全公司的下游成果。

Cat： 我们还为想要更安全的远程控制用户推出了受信任设备。对于所有远程环境，我们支持凭据注入（credential injection）。如果你希望 Claude Code 能够访问 Datadog，但你不希望 Claude Code 本身持有 Datadog 凭据，你可以设置我们的身份和凭据管理系统，使得 Datadog 凭据只能被代理使用但不能被代理访问——当代理尝试发出 Datadog 请求时，我们实时注入凭据。

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

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

Simon： 我们来谈谈人的因素。很多人感到一种失落感——他们曾经认为自己在构建软件中的角色正在被模型取代。你怎么看？过去一年半如何改变了你对自己手艺和自己增加价值的看法？

Thariq： Cat 和 Boris 一直提醒你必须更有野心。他们总是说：我们在快速增长，我们必须站在前沿，我们必须做出最好的工作。这对我来说是一个持续的提醒——任何我做事慢了的时候，我就想，好，我能做得更快吗？我能在这里更有野心吗？而答案往往是 Claude，因为 Claude 随着你的使用变得越来越好——上次我尝试这个是用之前的模型。关于失落感：我认为这是真实的。如果你只试图做 LLM 之前就在做的工作，而现在它只是一个提示，我觉得这确实有点悲哀。 而抵消这一点的方式就是更有野心。 我觉得 Jared 是一个很好的例子——他在奥克兰的公寓里大约用了一年的时间手工编写了所有的 Zig 代码，很少出门，而且做得非常开心。现在我看到他用 Rust 重写了所有的 Bun，他非常乐在其中——这更有野心，这就是他抵消失落感的方式。总的来说就是要问我如何做更大的事情，做更多——我觉得成功是有趣的。它改变的是你的野心。

“抵消这一点的方式就是更有野心”——这句话很好地捕捉了我在这个问题上的立场。

Simon： Cat，从产品管理的角度来看，这是什么样的？

Cat： 我觉得产品角色每个月都在变。我们团队所有的 PM 都是工程师、设计师、PM 的混合体——他们中的大多数人以前实际上是全职工程师。对我们来说，这意味着在任何有缺口的地方补上去。如果我们有一个想法，但没有激发任何工程师去构建它，那我们就应该自己构建，放进 notebook 里，然后激励别人把它带向生产。如果设计看起来有点不对，那就拿一个类似的页面，做第一版设计，然后@一个非常注细节的人来填补空白。或者，如果我们注意到团队和产品在公司的采用率在增长，更多的人需要了解 Claude Code、Claude Tag 和 Cowork 接下来的动向——那么我们就自动化整个发布日历，自动化异步获取状态更新，这样就不会打扰别人，并确保我们内部公告频道中的更新既详尽又切中要点。对我们来说，这非常关乎理解从一个好想法到把东西交到客户手中之间的缺口是什么，以及我们如何尽可能地将这个过程自动化。

这反映了我注意到的现象：当你能够以快得多的速度产出代码时，等待别人决策的时间就变成了更显著的瓶颈。能够做产品决策的工程师可以快得多地推进，而做出错误决策的成本也大大降低了。

什么时候 Claude 让你惊讶过？

Simon： 什么时候 Claude 让你惊讶过？ 当模型做了你认为它做不到的事情？

Thariq： 我发了很多关于 Claude 视频剪辑的帖子。最近我在 ACM Agentic 会议上做了一个演讲，我问：“嘿，你们有剪辑好的视频吗？我想发出来分享给传播团队。“他们说：“哦，太慢了。“所以我要了原始文件。他们给我发了我在台上演讲的视频、幻灯片 deck 的视频、以及音频文件，说：“祝你好运。“我把这些给了 Claude，还有我的 HTML deck，说：“嘿，你能把这些剪辑到一起吗？” 它做的真的令人难以置信——我觉得可以直接发布了。它转录了整个视频。它注意到有时候幻灯片 deck 的视频有点问题——中间有一个自动更新的弹窗——然后它就判断：“哦，我可能不应该用你的幻灯片视频。我要做的是把它切片，找出你当前在哪一页，然后改用 HTML 源。” 于是它显示 HTML 源。然后它有我的视频画面，但我只占了舞台的一小部分，所以它动态地裁剪画面到我在舞台上的位置——我在踱步，所以它会跟踪我的位置。它还在转录我说的话。

Simon： 这是 Fable，对吧？

Thariq： 对，是 Fable。这是一个好提示，但只是一次性的提示。然后我让它添加一些有趣的动画和图形，我被彻底震撼了。它使用 ffmpeg，它使用 Remotion。

Cat： 我的就简单多了。我是一个狂热的攀岩爱好者，我的很多朋友也攀岩，所以我们用 Claude Code 建了一个小应用来记录我们在做的路线项目。我们还经常一起户外攀爬，所以我们让 Claude 用 Workflows 做所有的调研。Workflows 太神奇了——我们把它定位为编码工具，但它在旅行深度调研方面也很棒。我还用 Workflows 规划团队的团建活动，它很擅长找能容纳我们所有人的场地。我用 Workflows 调研所有我们可能想去的攀岩目的地，以及哪些地方从我们各自的位置有直飞航班。它去 Mountain Project 找到我们难度级别的所有路线。它找 Airbnb。我不喜欢徒步，所以我特别在意从停车的地方到岩壁的步行距离非常短——它会过滤掉这些信息。用现有的应用我必须手动点进 Mountain Project，但有了这个，我只需要输入我们所有的偏好，它就变成了一个为我们定制的应用。

Simon： 所以你基本上是在用 vibe coding 为攀岩造一个 Jira。

Cat： 没错。

观众提问：你们有计划构建评估工具和代理可观测性吗？

观众： 你们有没有近期计划构建更多的评估工具来帮助我们构建评估数据集，以及更多的可观测性工具来监控代理和工作流的性能？

Cat： 我们考虑过构建评估工具，但我认为限制因素实际上是客户构建高质量的评估需要很长时间。所以我觉得工具不是瓶颈，更多的是构建好的评估的技能。这是我们很乐意在内部投入并希望对外分享最佳实践的领域。

观众提问：记忆（Memory）现在是如何设计的？会不会从文件转向数据库？

观众（Sai）： 我对记忆和多人协作感兴趣。记忆现在是如何设计的？ 我猜是基于文件的。第二，你们有没有考虑过一个正交方向——实际上需要一个数据存储来支持记忆，而不是文件，以便更好地扩展？

Thariq： 现在 Claude Tag 的记忆是频道特定的。该频道中的每个 Claude 都有一个共享记忆，各个实例有会话记忆——但会话可以回写到主记忆中。我们做了很多记忆研究，记忆的正确做法有时候并不直观。我们一直在做记忆实验。现在 Claude Tag 中记忆的实现方式是一个频道一个 markdown 文件。

【译者注】

Deep Blue（深蓝）：Simon Willison 造的词，指开发者因 AI 编程能力远超人类而产生的存在性焦虑。类比国际象棋大师卡斯帕罗夫输给 IBM 深蓝后的心理冲击。参见 Simon 专栏《Deep Blue》（2026 年 2 月）。
ant fooding：Anthropic 内部的”吃自己狗粮”谐音版。因为 Anthropic 的 logo 是蚂蚁（ant），所以内部称 dogfooding 为 ant fooding。
Credential Injection（凭据注入）：代理不直接持有 API 密钥，而是在发起请求时由中间层实时注入。这是一种新型安全模式，类似于 Kubernetes 的 ServiceAccount token 注入机制。Anthropic 的实现允许代理使用第三方服务（如 Datadog）的数据，但代理本身甚至无法读取这些凭据。
Sonnet Classifier：在 Auto Mode 中，Anthropic 使用一个单独的 Sonnet 模型作为分类器，实时判断 Claude 的每一个工具调用是否安全。这是”多层防御”（瑞士奶酪模型）的一环。
Vibe Coding：Andrej Karpathy 造的词，指不再逐行写代码，而是通过自然语言描述需求、让 AI 生成代码，开发者只负责”感受”结果是否正确的开发方式。