本月初，我在 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 内部的自产自用（dogfooding）被称为“蚂蚁试食”（ant fooding）。
• Anthropic 非常看好他们的自动模式，并将其视为 Claude Tag 的使能技术。
• Thariq 建议，要抵消编程智能体带来的“深蓝效应”，可以在自己承接的工作上“更有野心”。
• Fable 在视频剪辑方面能力不俗，Thariq 就用它来剪辑 Fable 自己的发布视频。
• 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：有没有一条传统软件工程的原则，一年前还成立，但你觉得在这个新世界里已经不再适用了？

Cat：我们在工程技能方面看到的最大变化之一是：两年前，产品经理去跟一群客户聊，花六个月时间与跨职能团队对齐PRD，然后在写第一行代码之前，写出一份详尽的技术规格说明，这是很典型的做法。现在情况完全反过来了。对很多工程师来说，我会给在场的人的建议是，多培养自己的商业嗅觉和产品判断力，搞清楚我们到底应该做什么，因为从产生想法到把它做出来的时间线大大缩短了——从六到十二个月缩短到可能只要一周。这意味着我们所有人都需要更好的品味，判断什么值得做，什么真正能推动我们所做的业务。所以产品品味和商业判断力的价值上升了，而在大多数产品领域，执行力的价值略有下降。当然，对于基础设施来说，确保所有细节都正确仍然是非常重要的事情。

Thariq：对我来说，最大的变化是重写现在变成了一件好事。

Simon：以前最糟糕的事情，现在反而变成好事了！

Thariq：没错。所有《人月神话》里说的——永远不要重写——我现在是支持重写的。如果你有一套好的测试套件——而且我认为重写实际上会迫使你确保自己有一套好的测试套件——但我觉得人们低估的一点是，代码库本身就是一份规格说明，而且可能你手上只有这一份规格说明，因为没有人知道代码库的每一个分支部分。你可以把它当作一个产物，从中提炼或者创建它的其他版本。我们用Rust重写了Bun，效果非常好——我现在就在用它。

Simon：你们还没有把Claude Code跑在Rust版Bun上对外发布，对吧？

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 目前负责了我们产品 PR 的 65%。这是一个巨大的转变；这超过了我们 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：我确实有一个。我们团队里很多人喜欢远程控制功能。远程控制让你可以用移动设备或浏览器里的 Claude，连接到你在命令行中运行的本地 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 是否能做出正确的决策、彻底修复所有 bug、并通过全部测试？这是我们的出发点和优化目标，因为它最直接地反映了用户的需求。但还有很多行为会影响用户在使用 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%。

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

Simon：Claude Code 基本上就是一个装满工具的大袋子。你引入一个新工具的标准是什么？你如何判断在那一层面投入额外的工程开发是值得的？

Cat：你想回答这个问题吗？你可是引入了我们最好用的工具之一。

Thariq：我的职业生涯巅峰就是引入了“询问用户问题”这个工具。这真的很难。尤其是某些工具——ask user question 是 Claude 用来向你提问的工具——所以它很难做评测，而且有时候这更多是用户偏好问题。当时我们的评测还比较少，所以很大程度上是基于“吃自己的狗粮”（dogfooding）——或者说是我们蚂蚁版的“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：我们从 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 凭据本身。

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

Thariq 在上午的主题演讲中谈到了 Fable 级模型带来的一种失落感，我们在对话中进一步深入探讨了这一点。我一直把这种现象称为“深蓝时刻”。

Simon：我们来聊聊人的因素。现在很多人感到一种失落，因为他们原本视为自己在构建软件中的角色，正被模型大量取代。你怎么看这件事？过去一年半如何改变了你对自己这门手艺以及你所创造价值的看法？

Thariq：Cat 和 Boris 就是很好的提醒，让你必须更有野心。他们总说：我们发展得太快了，我们必须站在前沿，我们必须做到最好。这对我来说是一个持续的提醒——每当我做事慢了，我就会想，好，我能做得更快吗？我能在这里更有野心吗？而很多时候答案就是 Claude，因为 Claude 会随着你的使用而变得更好——上次我试这个的时候，用的还是之前的模型。关于你说的失落感：我认为这是真实存在的。如果你只是试图做 LLM 出现之前就在做的同样的工作，而现在它变成了一条提示词，那我觉得确实是一种悲哀的感觉。而抵消这种失落感的方式，就是变得更有野心。我觉得 Jared 就是一个很好的例子——他在奥克兰的公寓里，用大约一年时间手写了全部 Zig 代码，几乎没出过门，而且乐在其中。现在我看到他把整个 Bun 用 Rust 重写，他也乐在其中——这件事野心大得多，而这就是他抵消失落感的方式。总的来说，就是问自己如何去做更大的事、做更多的事——我觉得成功是有趣的。这改变的是你的野心。

“抵消这种失落感的方式，就是变得更有野心”——这句话也精准地概括了我自己在这个问题上的立场。

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

Cat：我觉得产品这个角色真的是每个月都在变。我们团队里所有的产品经理都是工程师、设计师、产品经理的混合体——他们大多数人以前其实都是全职工程师。对我们来说，这真的意味着哪里有缺口就往哪里补。如果我们有了一个想法，但没有激发任何工程师去把它做出来，那我们就应该自己动手做，把它放进 notebook 里，然后激发别人把它带到生产环境。如果设计看起来有点不对劲，那就找一个类似的页面，先做一版初稿设计，再拉一个非常注重细节的人来填补空缺。或者如果我们注意到我们团队和产品在公司内部的采用率更大了，更多的人需要知道 Claude Code、Claude Tag 和 Cowork 接下来会推出什么——那就让我们自动化整个发布日历的规划，自动化获取那些异步状态更新，这样就不用去打扰别人，同时确保我们在内部公告频道里的更新内容详尽且切中要点。对我们来说，这很大程度上就是理解一个好想法和把它送到客户手中之间目前存在的差距是什么，以及我们如何尽可能多地自动化这个过程。

这反映了我注意到的一点：当你能以快得多的速度产出代码时，花在等待别人做决定上的时间就变成了一个更明显的瓶颈。能够做产品决策的工程师可以推进得飞快，而做出一个错误决策的代价也不再那么令人望而却步。

有没有哪个时刻 Claude 让你感到惊讶？

Simon：有没有哪个时刻 Claude 让你感到惊讶？就是模型做了你以为它做不到的事情的时候？

Thariq：我发过很多关于 Claude 视频剪辑的内容，但最近我在 ACM Agentic 会议上做了一场演讲，我问：“嘿，各位，你们有剪辑好的视频吗？我想把它发出来，和我的传播团队分享。”他们说：“哦，剪辑花了太长时间。”于是我要了原始文件。他们把我上台讲话的视频、演示文稿的视频和音频文件发给了我，说：“祝你好运。”我把这些连同我的 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 做过最离谱、纯粹因为“能造出来”就造了的东西是什么？

这个我也忍不住要放进来。

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：没错。

观众：有没有计划做评测构建工具和智能体可观测性方面的东西？

最后我们留了几分钟给现场观众提问。

听众：你们近期有没有计划构建更多的评测工具，方便我们构建评测数据集，以及更多的可观测性工具来监控智能体和工作流的性能？

Cat：我们考虑过构建评测工具，但我认为真正的瓶颈往往在于，客户需要花很长时间才能构建出真正高质量的评测。所以我觉得工具本身并不是主要制约因素，更重要的是如何构建出色评测的技能。这是我们既愿意在内部投入、也希望对外分享一些最佳实践的领域。

听众：记忆功能目前是如何设计的——你们会不会从文件转向数据存储？

听众（Sai）：我对记忆和多人在线功能很感兴趣。记忆功能目前是如何设计的？我猜是基于文件的。其次，你们有没有考虑过一个正交方向，即这些记忆实际上需要数据存储而不是文件，以便更好地扩展？

Thariq：目前 Claude Tag 中的记忆是按频道区分的。该频道中的每个 Claude 都有共享记忆，实例有会话——但会话可以回写到主记忆。我们做了很多记忆方面的研究，而正确的记忆实现方式有时并不那么直观。我们一直在进行记忆实验。目前 Claude Tag 中的实现方式是每个频道对应一个 markdown 文件。

2026 年 7 月 21 日