本月初，我在 AI 工程师世界博览会主持了一场炉边谈话，与 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 这样的模型，在系统提示词中添加示例已不再是最佳实践。Claude Code 的系统提示词最近缩减了 80% 的规模。
- 同样地，列出“不要做 X，不要做 Y”的清单可能会降低最新模型的结果质量。
- Anthropic 内部的自产自用被称为“蚂蚁试吃”。
- Anthropic 非常相信他们的自动模式，并将其视为 Claude Tag 的一项赋能技术。
- Thariq 建议通过“在工作中更具雄心”来抵消编程智能体带来的“深蓝效应”。
- Fable 擅长编辑视频，Thariq 曾用它来编辑自己的产品发布视频。
- Anthropic 在内部公开工作的文化是其成功的关键，这从他们在公共 Slack 频道中使用 Claude Tag 的方式可见一斑。
在过去一年里，你的日常工作发生了怎样的变化？
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 做出的转变：做出我们有史以来最好的作品，比以往任何时候都快。
传统软件工程中，有哪些规则已经不再适用了？
Simon：在传统软件工程中，有哪些一年前还成立、但你认为在这个新世界里已经不再适用的规则？
猫：我们在工程技能方面看到的最大变化之一是：两年前，产品经理通常的做法是去和一群客户交谈，花六个月时间与跨职能团队就产品需求文档达成一致，并在写下第一行代码之前，就如何精确实现这个功能写出一份详尽的技术规格说明。现在情况完全反过来了。对于很多工程师来说，我会建议在场的人多培养自己的商业嗅觉和产品直觉，去判断我们应该构建什么，因为从产生想法到实际构建之间的时间线大大缩短了——从六到十二个月缩短到可能只需要一周。这意味着我们所有人都需要具备更好的品味，去判断什么东西值得构建，什么东西才能真正影响我们正在做的业务。因此，在大多数产品领域，产品品味和商业直觉的价值在上升，而执行力的价值则略有下降。当然，对于基础设施领域，确保所有细节正确仍然非常重要。
塔里克：对我来说，现在重写代码是件好事。
西蒙：以前最糟糕的做法，现在反而变得可行了！
塔里克：没错。所有那些《人月神话》里的说法——永远不要重写——我现在是支持重写的。如果你有一套好的测试套件——而且我认为重写实际上会迫使你确保有一套好的测试套件——但我觉得人们低估了一点：代码库本身就是一份规格说明，而且它可能是你拥有的唯一一份规格说明，因为没有人了解代码库的每一个分支。你可以把这个产物拿来，从中提炼或创建它的其他版本。我们用 Rust 重写了 Bun，效果很好——我现在就在用。
西蒙：你们还没有在 Rust 版的 Bun 上发布 Claude Code，对吧？
塔里克：我们内部已经在用了。
（实际上，看起来 Anthropic 从 6 月 17 日开始就已经向所有人推送了基于 Rust 版 Bun 的 Claude Code。）
非工程师人员用 Claude Tag 做些什么？
西蒙：最近另一个重大发布是 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 总数的一半。我们看到人们将工作分配给 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 频道中强制公开提示词，来解决教用户高级图像提示词这一挑战的。
当构建成本如此之低时，你如何决定哪些功能值得构建？
我自己发现非常困难的一件事是，既然实际构建功能的成本已经大幅下降，那么如何判断一个功能是否值得发布。
西蒙：你如何应对工程领域最棘手的问题——优先级排序？当构建一个功能的成本现在如此低廉时，你如何决定哪些功能值得构建和发布？
凯特：这正是难点所在。我们有几种处理方式。一是我们每天都在内部试用我们自己的产品。每当我们在自己的产品中想做某件事却做不到时，我们不会去寻找其他解决方案，而是修复我们的产品，使其能够支持这个场景。我们内部有非常浓厚的“吃自家狗粮”文化。在将产品分享给全世界所有人之前，我们会先分享给 Anthropic 内部的每个人，以及一些早期客户，他们会给我们非常诚实的反馈——越尖锐越好——然后我们不断迭代，直到人们喜欢上它。对于一项功能，我们在向全世界发布之前，会设定一个内部标准，包括活跃用户数量和留存率。因为这个标准非常明确，每个工程师都知道自己要达到什么目标。我认为这也提升了我们的精细度，因为如果功能不够完善，用户就会流失——那样我们就不应该发布这个功能。
利用内部用户留存率来决定是否发布一项功能，对我来说非常有道理。
有没有哪个功能让你感到意外？
西蒙：有没有哪个功能让你感到意外？你推出后，用户参与度爆表——某个原本不太可能发布的功能，最终却变成了一个真正的产品亮点。
Cat：我确实有一个。我们团队很多人非常喜欢远程控制功能。远程控制让你能用移动设备或网页浏览器中的 Claude，连接到你在 CLI 中运行的本地 Claude Code 会话。我从来没有这个需求，因为我直接在手机上启动任务，任务会在云端会话中运行，不会占用我的本地环境——我想是因为我做的都是非常简单的编码任务。这是我之前不太理解的一点；我当时想，嘿，大家应该直接搭建远程开发环境才对。但实际上，自从我们推出远程控制后，我交谈过的很多人都告诉我，他们每天晚上都会把笔记本电脑插上电源，打开一堆远程控制会话，锁屏，然后坐在沙发上用手机控制 Claude Code。所以这已经成了我们现在大力推广的一种工作流程，我最初并不理解——但现在我懂了。
Claude Code 中的每一行生产代码都会经过人工审查吗？
本次大会的一个核心主题是审查：人们花了多少精力去审查由编码智能体为他们编写的代码。我非常想听听 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 Code 完全负责审查。这听起来可能有点吓人，但我们为此经历了长达六个多月的过程，并且通过一步步的小改进来建立对代码审查的信任。起初，所有内容都由人工审查；然后我们逐渐开始说，好吧，对于涉及这些文件的代码变更，代码审查能 100% 捕捉到所有问题——所以我们实际上不再需要人工手动审查这些了。当我们进行事件复盘时，会查看导致问题发生的 PR，并思考：我们该如何更新代码审查来捕捉这类问题？——然后我们会把这些 PR 加入到一个评估集中，以确保未来对代码审查的修改不会使该指标倒退。将人类从代码审查流程中移除是一个巨大的进步。这听起来可能令人担忧，也不是一蹴而就的事情，但通过数月对基础设施的投入，让你有信心代码审查能捕捉到你关心的所有问题，这是可以实现的。
因此，关键似乎在于持续迭代自动化审查系统本身，以便随着时间的推移建立起对它们的信任。
一个新模型会如何影响你对它能力边界的直觉判断？
我们深入探讨了评估——这是整个大会期间的另一个热门话题。
Simon：我知道，如果让 Opus 4.8 帮我构建一个运行 SQL 查询并输出 JSON 的 JSON 端点，它就能直接做对——这部分我不需要仔细审查。但新模型出现后，我不知道如何快速建立对 Fable 的信任，确保它不会搞砸 Opus 原本不会出错的事情。新模型如何影响你对它能力边界的直觉判断？
Cat：我们之所以持续构建这个评估基准，主要目的就是让新模型能够即插即用。当有新模型时，我们会运行整套评估集，确保比如 Fable 严格优于 Opus 4.8——这样我们就有信心直接替换使用。
Simon：这些模型评估是针对整个 Anthropic 的，还是 Claude Code 团队专属的？
Cat：两者都有。我们团队有自己的评估，同时我们也会对 Anthropic 内部所有代码仓库进行代码审查，所以有相应的评估。对于自动模式这类功能，我们不仅对 Anthropic 内部所有用户进行评估，还委托了多个外部测试人员进行红队测试，构建包含提示词注入和恶意输入的环境，确保自动模式不会放过任何此类攻击。
如何建立信心，确保系统提示词的调整能带来更好的输出？
Simon：我想知道我做的系统提示词改进是否真的提升了产品——这是最基础的产品级评估，但我仍然不太清楚该怎么做。你们是否在做这样的事情，以至于对系统提示词的调整能带来更好的输出有十足把握？
Cat：我们并没有百分之百的把握，但我们做了大量工作来确保性能不会倒退。我们的起点是一套我们信赖的外部评估集，并辅以一套更庞大的内部评估集。最初，我们主要针对能力进行优化：给定一个任务的完整定义和全部代码库，Claude 能否做出正确决策、完全修复漏洞并通过所有测试？这是我们的出发点和优化目标，因为它最直接地满足了用户的需求。但还有许多行为会影响用户在使用 Claude Code 时的感受。例如，用户非常不喜欢 Claude Code 说“该睡觉了”。或者用户非常不喜欢它说“嘿，我完成了五分之二——你想让我继续吗？”是的，请继续。因此，我们正在建立一套行为评估来捕捉这些问题。随着我们收到用户反馈——请大声地向我们反馈你们的意见——我们会按优先级对问题进行排序，然后逐一解决，并为每个问题构建评估。这还无法做到 100% 覆盖，但提高覆盖率是我们的优先事项。
Claude Code 团队与模型训练团队之间有多少互动？
Simon：Claude Code 团队与 Anthropic 内部负责训练模型的团队之间有多少互动？这种合作是否非常紧密？
Cat：在整个 Anthropic，我们所有团队都合作得非常紧密。我们经常开会讨论下一代模型应该具备哪些能力。我们的研究团队在公开分享这方面也做得非常出色——我们经常在博客文章中谈到，我们的目标是让模型能够处理越来越长周期的工作，以及我们如何训练 Claude 本身做到诚实、无害且乐于助人。我们还投入了大量精力，确保它能与你的意图保持一致，即使你的意图表达得有些模糊。当然，你最好尽可能具体地说明你的需求，这样 Claude 就能掌握所有上下文——但即使你不够具体，我们也会教会 Claude 做出合理的假设。这是一次富有成效的合作。
系统提示词缩减了 80%——你们成功去掉了哪些内容？
这一节里包含了许多实用的提示词技巧！
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% 准确，因为你每次都会把这个提示词给模型。
Simon：这其中的迷人之处在于，你依赖的是模型的判断力——这肯定得是 Opus/Fable 级别的能力。一年前的模型还不具备判断是否要测试某个改动所需的判断力。但如果你要为多种模型构建系统，并试图用更便宜的模型处理更便宜的任务，这种做法就行不通了。
Cat：正是因为这个原因，我们现在针对每个模型都有不同的系统提示词。只有我们最前沿的模型才能实现 80% 的 token 缩减——较老的模型仍然使用完整的系统提示词。
Simon：你觉得 Fable 和 Opus 足够聪明，能给 Haiku 提供更详细的提示词吗？因为它们知道 Haiku 的判断力和审美能力较弱。
Cat：我们还没能对此进行评估——目前没有任何硬数据可以证明这一点。
Thariq：小模型有时会面临一个棘手的问题，因为大模型在处理难题时，往往比小模型更节省 token。所以这需要建立一些直觉——有时你几乎始终需要前沿智能。帕累托曲线会移动，很难找到最佳平衡点。
Simon：一年前，我不相信模型能写出提示词。如今，优秀的模型非常擅长写提示词——我的很多提示词都是由模型生成的，这听起来很荒谬，但效果确实很好。让我接受这一点的，是思考子智能体这个概念——它完全就是让一个 Claude 模型为另一个 Claude 模型设置提示词。
Thariq：工作流就是一个很好的例子，因为 Claude 不仅是为单个子智能体写提示词，而是为多个子智能体的编排写提示词，每个子智能体都会得到一个非常详细的提示词。这几乎比单纯生成一个子智能体高了一个层次。我还在自己的个人电脑上用过这个功能，给它 Gemini API，然后说：来，生成图片。它比我给图像模型写提示词时懒散得多。这完全就是 Claude 给 Claude 写提示词，层层递进。
Cat：我觉得工作流工具的提示词也是 Claude 写的。
Simon：我读过那个提示词——写得很好。这其实是我对 Anthropic 普遍感到不满的一点：你们发布了 Claude Chat 的提示词，但没有包含工具提示词和 Claude Code 的提示词。我仍然需要运行一个代理来拦截它们。我非常希望 Claude Code 的提示词能被有意地公开发布——它们就是文档。通过它们，你才能知道这个工具能做什么以及它是如何工作的。
Cat：我会记下这个功能请求。我会让 Claude Tag 去处理。
值得注意的是，OpenAI 针对 GPT-5.6 的提示词最佳实践也为其最新模型提供了类似建议：
倾向于使用更精简的提示词
移除重复的指令和示例，并简化工具描述，可以提升任务性能与模型 token 效率。在一组内部编码智能体评估运行样本中，采用更精简系统提示词的配置，评估分数提升了约 10–15%，同时总 token 量减少了 41–66%，成本降低了 33–67%。
你引入一个新工具的标准是什么？
西蒙：Claude Code 本质上就是一个大工具包。你引入一个新工具的标准是什么？你如何判断在哪个层面值得投入额外的工程工作？
凯特：你想回答这个问题吗？你可是引入了我们最好用的工具之一。
塔里克：我的职业生涯巅峰就是引入了“询问用户问题”这个工具。这真的很难。尤其对于某些工具来说——“询问用户问题”是 Claude 用来向你提问的工具——所以它很难评估，有时更多是用户偏好的问题。那时候我们的评估还比较少，所以主要基于内部自用测试——或者说是我们的“蚂蚁自用测试”版本。但总体而言，我们一直努力朝着减少工具数量的方向发展。我们最近引入的一组工具，我想是任务工具——并且我们尽量给 Claude 提供更通用的版本来完成各种事情。
你的文件编辑工具最新的演进是什么？
我对文件编辑工具有着长期的兴趣——它们曾是旧的 Aider 代码编辑排行榜的主题，我饶有兴趣地观察着它们在各种编码智能体中从基于搜索替换、到基于行号、再到更复杂模式的演进过程。
Claude API 文档描述了一个推荐用于基于 API 构建的文本编辑工具，但 Claude Code 在这方面似乎采用了略有不同的方法。
西蒙：最有趣的工具之一是文件编辑工具——你可以把文件编辑作为一个工具，也可以告诉它使用 sed 和 grep 等命令来操作。你的文件编辑工具最新的演进是什么？
Thariq：我们确实还有一个工具，但举例来说，我们已经移除了 grep 和其他搜索工具——也就是 glob 工具——转而使用原生 bash。就像我之前在演讲中说的，模型更像是一种生物学而非物理学，而工具设计尤其困难。我不确定 Cat 是否不同意，认为工具评估存在一套科学方法，但我认为工具设计更像是一门艺术，或者说——更像是一种生物学。
Cat：我基本同意，但总的来说，随着我们引入更多工具，我们会尽量保持工具数量较低，并确保我们添加的每个工具都与其他工具具有不同的功能，这样 Claude 就能很容易地区分何时调用哪个工具。至于文件编辑，我们之所以保留它，实际上是因为我们可以渲染它。当 Claude 修改文件时，我们会向用户展示，并且有一个很好的专用 UI 显示：你是否批准对此文件的此编辑？我们之所以有一个专用的文件编辑工具，是为了能够确定性地知道 Claude 正在修改文件，从而可以向用户展示这个漂亮的 UI。许多刚上手的新用户仍然非常喜欢这种体验，所以我们保留了它。但对于我们这些目前使用自动模式的人来说——希望你不是在用 YOLO 模式——我认为这其实无关紧要，我们很可能可以直接移除文件编辑工具，也完全没问题。
Anthropic 内部对于安全运行 Claude Code 有什么建议？
这是关于提示词注入的问题！还有谁比 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 权限，但如果你说“把这个推送到 GitHub”，你希望它能执行；而如果你说“不要推送”，你希望它能拒绝。自动模式就能做到这一点。我经常遇到这种情况，Claude 因为非常主动和乐于助人而试图做某事，而自动模式看到“不要这样做”就会将其拦截。所以它很擅长处理你在提示词中自行给出的动态权限，我认为这一点非常重要。它还能很好地配合我们的沙箱基础设施，因为沙箱本身就是那种存在大量边缘情况、我们很难确定性处理的东西。我们有一个沙箱，当某些操作需要脱离沙箱时——比如网络请求——自动模式可以查看该请求并判断：这合理吗？——然后决定是否允许。
Simon：我之前不知道自动模式还会与网络沙箱交互。
Cat：它会与用户原本会看到的任何权限提示进行交互。
Simon：自动模式推出多久了？作为一个我能使用的功能，它好像才上线几个月，对吧？
（该功能于 3 月 24 日首次向公众开放。）
Cat：我们从 1 月份起就在 Anthropic 内部使用它了，所以已经对它进行了相当长时间的加固。Anthropic 极其重视安全与保障，我们一直在与对齐和安全团队广泛合作，以便在内部推广部署、构建这些评估，并在向全球发布之前让自动模式更加稳健。
Thariq：这也是 Claude Tag 如此出色的原因——Claude Tag 使用了自动模式。我听过很多关于 Slackbot 是自建还是购买的讨论，我的想法是：拜托，你很可能不应该自己构建 AI Slackbot。攻击向量太多了。你有一个用户可以用来提交反馈的反馈渠道，现在你的机器人正在读取它。我们在自动模式上投入的工作——我们有一套通用的瑞士奶酪式安全防御体系；我们还针对这类问题进行了强化学习——我认为这正是 Claude Tag 能够成功的原因。它能与你的权限无缝协作，而你肯定不希望自己的 Slack 被提示词注入。
除了自动模式之外，还有更多安全措施在规划中吗？
Simon：除了自动模式之外，还有更多安全措施在规划中吗？
Thariq：我认为我们非常安全。使用 Claude Tag，你可以为 Claude 配置自己的凭证，这样它就不需要以你的身份行事——你可以将 Claude 作为一个独立的身份，这也使得审计和检查 Claude 的行为变得更加容易。
Simon：因为 Claude Tag 会受到任何能与它对话的人的影响——它有一个更庞大的人群在告诉它该做什么。
Thariq：没错。当然，我们还有通过 Fable 进行的探测，这是我们安全与研究工作的下游成果。我认为，此刻正是 Anthropic 作为一家 AI 安全公司的价值真正显现的时候：我们非常希望 Claude 能够长期以对齐的方式运行，而自动模式必须做到基本无懈可击才能实现这一点——这一切都源于我们是一家 AI 安全公司。
Cat：我们还为那些希望更安全的远程控制用户推出了可信设备。对于我们所有的远程环境，我们都支持凭证注入。如果你希望 Claude Code 能够访问 Datadog，但又不想让 Claude Code 本身持有 Datadog 的凭证，你可以设置我们的身份与凭证管理系统，这样 Datadog 凭证只能由智能体使用，但智能体本身无法访问——当智能体尝试发起 Datadog 请求时，我们会动态注入这些凭证。
我非常喜欢这种凭证注入模式：Claude Code 可以通过代理访问 API，而该代理既能审计请求，又能注入相应的 API 密钥——这样一来，Claude 无需直接持有 API 凭证，就能访问经过身份验证的端点。
过去一年半的经历，如何改变了你对自己这门手艺的看法？
塔里克在上午的主题演讲中谈到了 Fable 类模型带来的一种失落感，我们在随后的对话中对此进行了更深入的探讨。我一直把这种现象称为“深蓝时刻”。
西蒙：我们来聊聊人的因素。现在很多人感到失落，因为他们曾经视为自己在构建软件过程中所扮演的角色，正越来越多地被模型所取代。你怎么看这个问题？过去一年半的经历，如何改变了你对自己这门手艺以及你所创造价值的看法？
塔里克：卡特和鲍里斯一直在提醒我，你必须更有雄心。他们总是说：我们发展得这么快，我们必须站在前沿，我们必须尽最大努力做到最好。这对我来说是一个持续的提醒——每当我做事慢了，我就会想，好吧，我能做得更快吗？我能在这里更有雄心吗？而答案往往是 Claude，因为 Claude 会随着你的使用而变得更好——上次我尝试这个的时候，用的还是之前的模型。关于你提到的失落感：我认为这种感觉是真实的。如果你只是试图做 LLM 出现之前就在做的同样工作，而现在它只是一个提示词，那我觉得，这确实是一种悲哀的感觉。而抵消这种失落感的方法，就是变得更有雄心。我认为贾里德就是一个很好的例子——他在奥克兰的公寓里，大约用了一年时间手写了所有 Zig 代码，几乎足不出户，而且乐在其中。现在我看到他把整个 Bun 重写为 Rust，他同样乐在其中——这要有雄心得多，而这就是他抵消失落感的方式。总的来说，就是问自己如何去做更大的事、做更多的事——我认为成功本身就是乐趣。这正在改变你的雄心。
“而抵消这种失落感的方法，就是变得更有雄心”——这句话也精准地概括了我自己在这个问题上的立场。
西蒙：那么从产品管理的角度来看，这又是什么样的呢？
凯特：我觉得产品角色每个月都在变。我们团队里的所有产品经理都兼具工程师、设计师和产品经理的多重身份——他们中的大多数人以前其实是全职工程师。对我们来说，这意味着随时填补任何空缺。如果我们有了一个想法，但没有激发任何工程师去实现它，那我们就应该自己动手，把它写进笔记本，然后激励别人把它推向生产环境。如果设计看起来有点不对劲，我们就找一个类似的页面，先做一版初步设计，再找一位非常注重细节的人来填补空缺。或者，如果我们发现团队和产品在公司内部的采用率更大了，并且有更多人需要了解 Claude Code、Claude Tag 和 Cowork 接下来会有什么新功能——那我们就自动规划好整个发布日历，自动异步获取那些状态更新，这样就不用去打扰别人，同时确保我们在内部公告渠道的更新内容详尽且切中要点。对我们来说，关键在于理解一个好想法与将其交付给客户之间目前存在的差距是什么，以及如何尽可能地将这个过程自动化。
这反映了我注意到的一点：当你能以快得多的速度生成代码时，等待他人决策所耗费的时间就变成了一个更显著的瓶颈。能够做出产品决策的工程师，其推进速度会快得多，而且做出错误决策的代价也远没有那么高昂。
有没有哪个时刻，Claude 让你感到惊讶？
西蒙：有没有哪个时刻，Claude 让你感到惊讶？就是模型做了你原本认为它做不到的事情的时候？
Thariq：我发过很多关于 Claude 视频剪辑的内容，但最近我在 ACM 智能体大会上做了一场演讲，我问：“嘿，各位，你们有剪辑好的视频吗？我很想把它发出来，跟我的传播团队分享。”他们说：“哦，这个花的时间太长了。”于是我就去要原始文件。他们把我站在台上演讲的视频、演示文稿的视频以及音频文件发给了我，还说：“祝你好运。”我把这些素材连同我的 HTML 演示文稿一起给了 Claude，然后说：“嘿，你能把这些剪辑到一起吗？”它做出来的效果真的令人难以置信——我已经准备好发布了。它会转录整个视频。它注意到有时我的演示文稿视频有点奇怪——中间弹出了一个自动更新窗口——于是它判断：“哦，我可能不应该用你的演示文稿视频。我要做的是把它切分开，弄清楚你讲到了哪张幻灯片，然后改用 HTML 源代码来展示。”所以它展示了 HTML 源代码。然后它还有我的视频，但我只占了舞台的一小部分，所以它会动态裁切到我所在的位置——而且我在来回踱步，所以它会随着我的走动追踪我。同时它还在转录我所说的话。
Simon：这是用 Fable 做的，对吧？
Thariq：对，是用 Fable 做的。提示词写得不错，但只是一次性提示词。然后我让它添加一些有趣的动画和图形，结果我被彻底震撼了。它用到了 ffmpeg 和 Remotion。
这是 Thariq 的视频，展示了他如何使用 Fable 来剪辑 Fable 自己的发布视频，以及那个发布视频本身。
它还有什么做不到的？
我很尴尬地承认，我发现自己很难想出像 Fable 5 和 GPT-5.6 这样的前沿模型无法完成的任务。
Cat 仍然不认可它的 UX 设计能力：
Simon：它做不到什么？有哪些事情仍然让你感到失望——你还在等着 Claude Fable 6 来帮你解决？
Cat：我希望它在设计和用户体验方面有更好的品味。目前的情况是，如果我写出一条包含详细功能规格说明的提示词，它通常能按我的要求执行。但边距可能不对，或者界面还不够令人愉悦。它依赖于现有的应用设计最佳实践，但对于前沿的 AI 产品来说，还有许多我们尚未设计出来的全新交互体验。
Simon：存在一种“Opus 美学”——你看到某个东西就能说，“嗯，这是 Opus 设计的。”如果我们能超越这一点就好了。
Cat：是的。我非常期待未来的模型能成为交互设计方面的思想伙伴。
Thariq：它还有什么做不到的？我很希望看到它能更多地与现实世界互动。它能解决科学问题吗？它能统筹安排实验吗？这需要一定量的编码工作，但它还需要对更广阔的世界有另一种品味。
Anthropic 文化中的哪些部分，其他公司应该借鉴？
我觉得这会是一个很棒的收尾问题：
Simon：你们认为 Anthropic 公司文化中哪些部分独特地帮助了 Anthropic 高效利用这些工具，并且其他公司应该借鉴？有哪些文化上的“窍门”是人们应该向你们学习的？
Cat：我来分享一个关于 Claude Tag 的例子。Claude Tag 在公开频道中使用时效果最好，而且你们的大部分频道也应该是公开的。Claude Tag 能够搜索所有公开频道，获取尽可能多的上下文信息，从而给出最准确的答案——而它只有能访问所有信息时才能做到这一点。
Thariq：我在主题演讲中提到过这一点，但它对我太重要了，我想再强调一次。联合创始人说，我们不会和自己谈判，我认为这非常重要。你可以在脑子里想象各种权衡，然后说服自己不去做某件有雄心的事情——或者你也可以直接尝试去做那件有雄心的事情。我们经常问自己：如果我们直接去做会怎样？这是真正的权衡，还是不是？如果是，为什么——有什么证据证明这是真正的权衡，而不仅仅是一个听起来合理的说法？让权衡自己向你显现。尽可能保持雄心壮志。
你用 Claude 做过最离谱的东西是什么——纯粹因为你能做到？
我忍不住也把这个例子加了进来。
西蒙：你用 Claude 做过的最离谱的东西是什么——纯粹因为你能做到？
塔里克：我正在做一款 2D 街头霸王格斗游戏，里面有一个以我为原型的角色——还有我的朋友们。它用 Claude Code 来提示 Gemini——说实话 Seedance 模型相当不错——从而生成视频动画。效果很好；它在提示方面非常出色，还能验证帧画面，判断动画是否合格。
西蒙：你生成的是《街头霸王 2》那种级别的 2D 精灵图吗？
塔里克：对，没错——2D 精灵图。动画效果看起来棒极了。它还能算出碰撞框——它会说：“哦，你的拳头在这里，我来绘制 JSON 格式的碰撞框。”这太不可思议了。
凯特：我的就简单多了。我是个狂热的攀岩爱好者，我的很多朋友也攀岩，所以我们用 Claude Code 做了一个小应用，用来记录我们正在攻克的所有项目。我们也经常一起出去户外活动，所以我们会让 Claude 用工作流来做各种调研。工作流太棒了——我们把它定位成编码工具，但它在旅行深度调研方面也非常出色。我还用它来规划团队外出活动，它很擅长找到能容纳我们所有人的场地。我用工作流来调研所有我们可能想去的攀岩目的地，以及哪些地方有从我们各自所在地直飞的航班。它会访问 Mountain Project，找到所有符合我们难度等级的攀岩路线。它还会找 Airbnb。而且我不喜欢徒步，所以我非常在意攀岩路线是否离停车点很近——也就是从停车点到岩壁的步行距离非常短——它也能按这个条件筛选。用现有的应用，我得手动在 Mountain Project 里逐个点击，但有了这个，我只需要输入我们所有的偏好，它就成了一个为我们量身定制的应用。
西蒙：所以你基本上是在用 vibe coding 给攀岩活动做一个 Jira。
凯特：没错。
观众：有没有计划开发评估构建工具和智能体可观测性？
最后我们留了几分钟时间给观众提问。
观众：你们近期有没有计划开发更多评估工具，方便我们构建评估数据集，以及更多可观测性工具来监控智能体和工作流的性能？
Cat：我们考虑过构建评估工具，但我认为实际的限制因素往往是客户需要很长时间才能构建出真正高质量的评估。所以我觉得工具本身并不是主要瓶颈，更关键的是如何构建优秀评估的技能。这是我们既愿意在内部投入，也希望能在外部分享一些最佳实践的领域。
观众：目前记忆是如何设计的——你们会从文件转向数据存储吗？
观众（Sai）：我对记忆和多用户功能很感兴趣。目前记忆是如何设计的？我猜是基于文件。其次，你们有没有考虑过一个正交方向，即实际上需要为这些记忆使用数据存储而非文件，以便更好地扩展？
Thariq：目前对于 Claude Tag，记忆是按频道区分的。该频道中的每个 Claude 都有共享记忆，实例有会话——但会话可以回写到主记忆。我们做了大量记忆研究，有时正确的记忆方式并不那么直观。我们一直在进行记忆实验。目前 Claude Tag 中的实现方式是每个频道对应一个 Markdown 文件。
2026年7月21日
更多近期文章
- Kimi K3，以及我们仍能从鹈鹕基准测试中学到什么 - 2026年7月16日
- 新的 GPT-5.6 系列：Luna、Terra、Sol - 2026年7月9日
这是 Simon Willison 与 Claude Code 团队的 Cat 和 Thariq 进行的炉边谈话，发布于 2026年7月21日。
带注释的演讲
claude-code
thariq-shihipar
cat-wu