与 Claude Code 团队的 Cat 和 Thariq 的炉边对谈
原文由 Simon Willison 于 发布，订阅该博客
本月早些时候，我在 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 这类模型，在系统提示词中添加示例 已不再是最佳实践。Claude Code 的系统提示词最近 缩减了 80%。
- 同样，一长串“不要做 X、不要做 Y”式的禁令，反而会降低最新模型的输出质量。
- 在 Anthropic 内部，吃自己的狗粮（dogfooding）被叫做“ant fooding（吃蚂蚁粮）”。
- Anthropic 非常看好自身的自动模式（auto mode），并将其视为 Claude Tag 得以实现的关键技术。
- Thariq 建议用“更有雄心”的工作来对冲由代码智能体引发的深蓝（Deep Blue）式失落感。
- Fable 已经 能够胜任视频剪辑，Thariq 就用它剪辑了其自身的发布视频。
- Anthropic 在内部公开透明的工作文化是其成功的关键，这一点在他们如何在公开 Slack 频道中使用 Claude Tag 上体现得淋漓尽致。
过去一年里，你们的日常工作发生了怎样的变化？
Simon： Claude Code 是去年 2 月发布的——至今还不到一年半，最初只是 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： 哪一条一年前还被视为真理的软件工程常识，在这个新世界里已经不再成立了？
Cat： 我们看到的工程技能组合最大的转变之一是：两年前，典型的做法是产品经理先去访谈大量客户，再花半年时间和跨职能团队对齐一份 PRD，把每个实现细节都写得清清楚楚，然后才开始写第一行代码。现在则完全反了过来。对在座的很多工程师，我想说的是，要更多地培养你们对该做什么的商业嗅觉和产品嗅觉，因为从有想法到把东西做出来的周期已经大大缩短——从六到十二个月，缩短到可能只要一周。这意味着我们所有人都需要对“什么值得做、什么能真正撬动业务”有更好的判断力。所以产品品味和商业 sense 的价值在提升，而对执行本身的强调在大多数产品领域相对降低了。当然，对于基础设施领域，确保每个细节都正确仍然至关重要。
Thariq： 对我来说，就是重写现在是好事。
Simon： 过去最忌讳的事现在居然可行了！
Thariq： 没错。《人月神话》里说的“永远不要重写”——我现在支持重写了。如果你有一套完善的测试套件——而且我认为重写这件事本身就会迫使你去确保测试套件是完善的——但我觉得人们低估的一点是，代码库本身就是一份规格说明书，而且可能是你唯一的规格说明书，因为没有人能完全搞懂代码库中所有的分支逻辑。你可以把这份产物拿来提炼或衍生出其他版本。我们把 Bun 用 Rust 重写了，效果非常好——现在在我这里已经跑起来了。
Simon： 你们还没把基于 Rust 版 Bun 的 Claude Code 发出去吧？
Thariq： 内部已经在用了。
（事实上，Anthropic 似乎已于 6 月 17 日开始向所有人推送基于 Rust 版 Bun 的 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，还是仅指 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 频道中公开输入提示词，来教会用户掌握高级图片提示技巧的做法。
当构建成本大幅降低时，你们如何判断哪些功能值得做？
我自己就深感困扰的是，既然实际构建功能的成本已经大幅降低，如何判断一个功能是否值得发布。
Simon： 你们如何应对工程中最难的问题——优先级排序？当构建功能的成本已经低得多时，你们如何决定哪些功能值得构建和发布？
Cat： 这确实很难。我们有几种做法。一是我们每天都在深度试用自己的产品。每当我们发现产品中有想做却做不到的事，我们不会去找别的变通方案，而是直接把产品改到能支持这个场景。我们在内部有非常浓厚的试用文化。在把产品推向全世界之前，我们会先在整个 Anthropic 内部发布，并邀请一些会给出非常直言不讳反馈的早期客户——越尖锐越好——然后不断迭代，直到大家真正喜欢它。我们有一个内部标准：一个功能必须达到一定的活跃用户数和留存率，才会对外发布。因为这个标准非常清晰，每个工程师都知道自己要达成什么目标。我认为这也提升了我们的打磨程度，因为如果功能不够精致，用户就会流失——那这个功能就不该发布。
用内部用户留存来决定功能是否发布，在我看来非常有道理。
有没有哪个功能的上线效果出乎你们的意料？
Simon： 你有没有遇到过让你意外的功能？就是那种你们发布后，用户参与度爆棚、原本觉得不太可能成为正式产品功能，结果却成了真正亮点的例子？
Cat： 我有一个。团队里很多人都喜欢远程控制（remote control）。它可以让你用手机或浏览器中的 Claude，连接到在 CLI 本地运行的 Claude Code 会话。我自己从来没有这种需求，因为我是在手机上直接发起任务，让它在云端会话中运行，完全不依赖本地环境——我想是因为我做的都是比较简单的编程任务。起初我不太理解这个功能，我想，大家直接搭个远程开发环境不就行了吗。但在我们推出远程控制后，很多跟我聊过的人告诉我，他们每晚的做法是把笔记本插上电源，打开一堆远程控制会话，锁屏，然后在沙发上用手机操控 Claude Code。所以这已经成了一种我们现在正着力深化的工作流——起初我没 get 到，但现在懂了。
Claude Code 的每一行线上代码都会经过人工审核吗？
贯穿本次大会的一个核心主题就是审核：人们会花多少精力去审查代码智能体为他们编写的代码。我非常想听听 Claude Code 团队对此的看法！
Simon： 代码审查是怎么做的？进入 Claude Code 的每一行线上代码都会经过人工审查吗？如果不是，你们如何保证质量？
Thariq： 这很大程度上取决于任务。对于重要领域我们设有代码负责人（code owners）。系统提示词就是一个例子，那里必须得到负责人的批准。
Simon： 所以代码负责人要直接为该区域代码的质量负责。
Thariq： 没错。
Cat： 而且任何触及该区域的 PR 都必须经过他们批准。
Thariq： 我们有代码审查 GitHub 机器人会审查所有内容——每个 PR 都会经过它，很多时候它承担了大部分审查工作。我在团队中看到的一种做法是，对于更复杂的 PR，你可能会做一个说明产物来解释这个 PR，以便其他人审查。我们在验证、CI/CD 等方面投入了很多，确保任何失败都有对应的测试。我们有一个非常完善的环境，让 Claude 可以操控 Claude Code 并对其进行测试。所以我们是多管齐下地做代码审查。
Cat： 总体上，我们正努力朝着人类无需参与每个环节的方向发展。对于 Claude Code 核心以及其他产品核心部分的最关键改动，始终会有代码负责人，他们会人工审查所有变更。但越来越多的情况下，对于外层的改动，我们实际上已经完全交给 Claude code review 来审查了。这听起来可能有点吓人，但我们为此花了六个多月的时间才走到这一步，而且需要通过循序渐进的方式来建立对代码审查的信任。起初我们对所有东西都做人工审查，然后逐渐放开——比如，对于触及某些文件的代码改动，代码审查已经能 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 是否做出了正确决策、完全修复了 bug 并通过了所有测试？这是起点，也是我们最优先优化的目标，因为它最直接地反映了用户的诉求。但还有很多行为会影响用户与 Claude Code 共事时的感受。比如，人们非常讨厌 Claude Code 说“该去睡觉了”。或者人们非常讨厌它说：“嘿，我完成了五部分中的两部分——要我继续吗？”当然要继续。所以我们正在构建一套行为评测来捕捉这些问题。随着收到用户反馈——请大声告诉我们你们的反馈——我们会按优先级排序，逐一为每个问题构建评测。这不是 100% 的覆盖，但提升覆盖率是我们的重点。
Claude Code 团队与模型训练团队之间的协作有多紧密？
Simon： Claude Code 团队与 Anthropic 内部负责训练模型的团队之间有多少互动？合作紧密吗？
Cat： 在 Anthropic 内部，我们大家都合作得非常紧密。我们经常会面，讨论下一代模型应该具备什么能力。我们的研究团队在这方面也非常公开——我们经常在博客文章中提到，我们的目标是让模型能够胜任越来越长周期的任务，并训练 Claude 做到诚实、无害且有帮助。我们也投入了大量精力确保它能与你的意图对齐，即使你的意图表达得比较模糊。当然，你最好尽量具体地说明你想要什么，给 Claude 充分的上下文——但即便你不够具体，我们也会教 Claude 做出合理的假设。这是富有成效的合作。
系统提示词缩减了 80%——你们都删掉了哪些内容？
这一节有超多实用的提示词技巧！
Simon： Thariq，你今天早上提到 Claude Code 的系统提示词因为 Claude Fable 缩减了 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： 一年前我还不信任模型来写提示词。如今优秀的模型非常擅长写提示——我的很多提示都是模型写的，这听起来很荒谬但却非常有效。让我接受这一点的是对子智能体（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 效率。在一组内部代码智能体评测中，采用更精简系统提示词的配置，评测分数提升了约 10–15%，同时总 token 减少了 41–66%，成本降低了 33–67%。
引入一个新工具的标准是什么？
Simon： Claude Code 本质上就是一大袋工具。你们引入新工具的标准是什么？如何判断值得在这一层做额外工程？
Cat： 你来回答？你可是引入了我们最好用的工具之一的人。
Thariq： 我职业生涯的巅峰就是引入了 ask user question 工具。这真的很难。尤其是有些工具——ask user question 是 Claude 用来向你提问的工具——所以很难评测，有时更多取决于用户偏好。那会儿我们的评测还很少，所以很大程度上靠内部试用——用我们的说法是“ant fooding”。但总体上我们一直在朝着更少工具的方向努力。上一批引入的工具我想是 task 工具——我们尽量给 Claude 更通用的能力去做事。
文件编辑工具的最新演进是怎样的？
我一直对文件编辑工具很着迷——这曾是旧版 Aider 代码编辑排行榜的主题，我也一直在关注不同代码智能体中文件编辑工具的演进，从基于搜索替换，到基于行号，再到更复杂的模式。
Claude API 文档中描述了一个文本编辑工具，它是推荐用于 API 开发的工具，但 Claude Code 似乎在这方面采用了略有不同的方法。
Simon： 最有意思的工具之一就是文件编辑工具——你可以把它作为工具提供，也可以让它用 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： 我们在 Anthropic 内部从一月份就开始用了，所以已经打磨了相当长一段时间。Anthropic 极其重视安全与安保，我们在全公司范围内与对齐和保障团队紧密合作，以推动内部推广、构建这些评测，并在向外界发布前让自动模式更加稳健。
Thariq： 这也是 Claude Tag 如此出色的原因——Claude Tag 使用了自动模式。我听到很多关于 Slack 机器人的自建还是外购的讨论，我的看法是：你大概不该自己去造一个 AI Slack 机器人。攻击面太多了。你有一个用户可以发反馈的频道，而现在你的机器人正在读取它。我们在自动模式上投入的工作——我们还有一套通用的瑞士奶酪式防御；我们也针对这些做了强化学习——我认为这才是让 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 凭证的情况下访问需要鉴权的接口。
过去一年半如何改变了你们对自身技艺的理解？
Thariq 在上午的主旨演讲中谈到了一种由 Fable 级别模型带来的悲伤感，我们在对话中对此进行了更深入的探讨。我把这种感受称为深蓝（Deep Blue）。
Simon： 我们来聊聊人的因素。很多人现在感到一种失落感，因为他们曾视为自身在软件构建中角色的很多部分，正在被模型所取代。你们怎么看待这个问题？过去一年半如何改变了你们对自身技艺以及自身价值的看法？
Thariq： Cat 和 Boris 时刻提醒着我们要更有雄心。他们总说：我们发展得如此之快，必须走在最前沿，必须做到最好。这对我来说是持续的提醒——每当我在某件事上慢下来，我就会想：我能做得更快吗？我能在这里更有雄心吗？而答案往往是 Claude，因为 Claude 在不断变好——上次我尝试时，用的还是上一个模型。关于失落感：我认为这是真实存在的。如果你只是想做和 LLM 出现之前同样的工作，而现在它变成了一条提示词，我想那确实会有点悲伤。而抵消这种感受的方式就是更有雄心。我觉得 Jared 就是一个很好的例子——他在奥克兰的公寓里用一年时间手写了所有的 Zig 代码，几乎足不出户，并且乐在其中。现在我看到他把整个 Bun 用 Rust 重写，他乐在其中的程度更甚——这要雄心得多，而这正是他抵消失落感的方式。总的来说，就是去思考如何做更大的事、做更多的事——我认为成功本身就是有趣的。这是在改变你的雄心。
“抵消这种感受的方式就是更有雄心”——这也恰好概括了我自己在这个问题上的立场。
Simon： Cat，从产品管理的角度来看，这又是怎样的？
Cat： 我感觉产品经理的角色几乎每个月都在变。我们团队里的所有 PM 都是工程师、设计师、PM 的混合体——他们中的大多数过去都是全职工程师。对我们来说，这真的意味着在任何出现缺口的地方补位。如果我们有一个想法，却没有激发任何工程师去实现它，那我们就应该自己把它做出来，放进笔记本里，再去激励大家把它推向生产。如果设计看起来有点不对劲，那就找一个类似的页面，先做一版设计，再 @ 那个非常注重细节的人来补齐差距。或者如果我们注意到团队和产品在公司内部的采用率越来越高，更多人需要了解 Claude Code、Claude Tag 和 Cowork 的后续规划——那就把整个发布时间表的梳理自动化，把那些状态更新异步化，这样就不用去打扰别人，并确保我们在内部公告频道中的更新完整、切中要点。对我们来说，关键在于理解从一个好点子到把它交付给客户之间当下存在什么缺口，以及如何尽可能地将其自动化。
这也印证了我的一个观察：当代码产出速度大幅提升后，等待他人决策所造成的阻塞，会成为更加突出的瓶颈。能够做出产品决策的工程师可以跑得快得多，而做出错误决策的代价也远没有过去那么高。
Claude 有没有哪个瞬间让你们感到意外？
Simon： 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： 我希望它能有更好的设计和 UX 品味。现在如果你写一份详细说明功能行为的提示，它通常能按预期实现。但边距可能会不对，界面也还不够让人愉悦。它会依赖现有的应用设计最佳实践，但对于前沿 AI 产品，有太多全新的交互体验是我们尚未设计出来的。
Simon： 有一种 Opus 美学——你一看就能说：“嗯，这是 Opus 设计的。”要是能突破这种风格就好了。
Cat： 是的。我非常期待未来的模型能成为交互设计的思想伙伴。
Thariq： 还有哪些做不到？我很希望看到它能更多地与真实世界互动。它能解决科学问题吗？能编排实验吗？其中有些部分涉及编程，但还需要对更广阔世界有另一种品味。
Anthropic 的哪些企业文化值得其他公司借鉴？
我觉得这会是一个很好的收尾问题：
Simon： 你们认为 Anthropic 的哪些企业文化独特地帮助了 Anthropic 高效地使用这些工具，是其他公司应该借鉴的？大家应该从你们这里学走哪些文化技巧？
Cat： 我就分享一个关于 Claude Tag 的。Claude Tag 在公开频道中效果最好，而当你们的大多数频道都是公开的时效果更佳。Claude Tag 能够搜索所有公开频道以获取尽可能多的上下文，从而给出最准确的答案——而这只有在它能访问所有内容时才有可能。
Thariq： 我在主旨演讲中提过，但这对我太重要了，我想再强调一次。创始人常说我们“不和自己讨价还价”，我认为这非常重要。你可以在脑海中想象各种权衡，然后说服自己不要去做一件有雄心的事——或者你可以直接去尝试做那件有雄心的事。我们经常会问：如果我们直接去做呢？这是一个真正的权衡吗？如果不是，为什么——有什么证据证明这是一个真正的权衡，而不仅仅是听起来合理？让权衡自己显现出来。尽可能地保持雄心。
你们用 Claude 做过的最离谱、最“就因为能做所以做了”的东西是什么？
我还是忍不住又加了这个问题。
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： 没错。
观众提问：未来有无打造评测数据集和智能体可观测性工具的计划？
最后我们留了几分钟给观众提问。
观众： 你们近期是否有计划打造更多帮助我们构建评测数据集的评测工具，以及更多用于监控智能体和工作流表现的可观测性工具？
Cat： 我们考虑过打造评测工具，但我认为真正的限制因素往往在于客户需要花很长时间才能构建出真正高质量的评测。所以工具本身并不是瓶颈，更多是“如何构建出色的评测”这项技能。这是一个我们既希望在内部投入，也希望对外分享最佳实践的领域。
观众提问（Sai）：现在的记忆机制是如何设计的——未来会从文件转向数据库存储吗？
观众（Sai）： 我对记忆和多人协作很感兴趣。现在的记忆是如何设计的？我猜是基于文件的。其次，你们是否考虑过另一个方向，即真正需要一个数据库来存储这些记忆，而不是文件，以便更好地扩展？
Thariq： 目前 Claude Tag 的记忆是按频道隔离的。每个频道中的 Claude 共享同一份记忆，各个会话有自己的上下文——但会话可以回写到主记忆中。我们做了很多记忆相关的研究，什么样的记忆方式才是最合适的，这一点可能并不直观。我们一直在做记忆实验。目前 Claude Tag 的记忆实现是每个频道一个 markdown 文件。
评论
登录后参与讨论