Anthropic 的 Claude Code 团队内幕

Simon Willison·7月21日 20:54 UTC·作者 Simon Willison

关键信息

Anthropic 表示，Claude Tag 现在承担了 Claude Code 团队 65% 的产品工程 PR；Claude Code 的功能会先向员工发布，只有在内部人群中证明留存效果的功能才会继续对外推广。团队还提到，关键变更仍然需要人工审查，但产品的“外层”越来越多地依赖自动化代码审查，而且 Claude Code 的系统提示词最近缩短了 80%。

资讯摘要

Simon Willison 发布了一份炉边谈话的整理稿，这场对话是在 AI Engineer World’s Fair 上与 Anthropic 的 Claude Code 团队成员 Cat Wu 和 Thariq Shihipar 进行的。讨论主题包括 Claude Code、Claude Tag、Fable、编码代理安全、评测、工具设计，以及 Anthropic 如何在内部使用这些工具。一个重要信号是，随着模型能力提升，团队的工作方式发生了明显变化：早期使用 Claude Code 时，开发者需要对每一步都进行细致监督。Cat Wu 表示，现在很多实现工作都可以交给 Claude 去完成，这让团队有更多时间思考更有创造性的产品体验。她还提到，Fable 现在可以一次性完成很多任务。

Thariq Shihipar 说，系统输出质量已经高到需要以更严格的标准要求自己，他还用 Fable 做过视频剪辑，包括剪辑它自己的发布视频。整理稿还提到，Claude Tag 这款新的协作式 Slack 集成现在承担了 Claude Code 团队 65% 的产品工程 PR。Anthropic 会先把 Claude Code 功能发给员工，只有在内部人群中证明留存表现的功能才会继续向外推广。团队表示，关键改动仍然会人工审查，但产品外层越来越依赖自动化代码审查，而且 Claude Code 的系统提示词最近缩短了 80%。

资讯正文

与 Claude Code 团队的 Cat 和 Thariq 畅谈炉边对话

2026年7月21日

本月早些时候，我在 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 内部把自己用产品来“自我试用”称为“ant fooding”。

Anthropic 非常看好他们的 auto mode，并将其视为 Claude Tag 的赋能技术。

Thariq 建议，要用“去承担更有雄心的工作”来抵消编码代理带来的“深蓝效应”。

Fable 在视频剪辑方面相当能干，Thariq 还用它剪辑了自己的发布视频。

Anthropic “在公共场合内部协作”的文化是其成功的关键，这一点从他们在公开 Slack 频道中使用 Claude Tag 的方式就能看出来。

1:05

西蒙：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——很棒的模型，但你还得看权限提示。我们有种“失忆”似的感觉，这其实挺疯狂的，我会想，哦，自动模式一直都在，对吧？我甚至都不记得自己按过“yes”和“allow”了。对我来说，我试图推动自己去做的一件大事是，我们必须产出比以往更高质量的工作。输出质量极其高。我一直在大量用它剪视频，然后我就会想，好吧，它必须在几个小时内满足我们品牌团队极其严苛的要求，否则我们就根本做不了。我希望借助 Fable 来实现的转变也是如此：以比我们以往更快的速度，做出我们有史以来最好的作品。

Cat：我还记得我们刚推出 Claude Code 和 Sonnet 3.7 的时候，你得给它一个任务，然后几乎每一个它想做的小动作都得严密盯着。我会非常仔细地阅读每一条权限提示。我经常会说不——不，不，不，你检查这个文件了吗？你检查那个文件了吗？而现在，随着每一代模型的进步，这种体验都变得令人难以置信。我觉得我们都终于有机会退后一步，把更多琐碎的实现工作交给 Claude。它为我们腾出了很多时间，让我们去思考更有创意的工作，比如：既然我们知道 Claude Code 能实现其中很多东西，那我们应该为用户提供什么样的正确体验？而现在有了 Fable，这就是一次完全不同层级的跃升。我们发现，对我们的很多使用场景来说，现在你 वास्तव上可以用 Fable 一次性搞定大量功能。

Thariq：我还记得我第一次收到关于 Claude Code 的消息。我的一个好朋友跟我说：“你得去试试 Claude Code。”那大概是在 Opus 4 刚发布的时候，我试了之后就想，“哦，天哪，我现在必须去 Anthropic 工作。”那时候是 Opus 4——很棒的模型，但你还在读权限提示。我们对过去的很多事情有种不可思议的失忆感，我会想，哦，自动模式一直都在这里，对吧？我甚至都不记得按过“yes”和“allow”了。对我来说，我一直在逼自己去适应的一件大事是，我们必须做出比以往任何时候都更高质量的工作。输出质量高得惊人。我最近一直在用它剪视频，我会想，好吧，它必须在几个小时内满足我们品牌团队非常严苛的要求，否则我们就做不到。这就是我试着借助 Fable 去转变的方式：以比以往更快的速度，做出我们有史以来最好的作品。

西蒙：有什么在一年前还成立、但在这个新世界里你不再认为成立的传统软件工程原则吗？

Cat：我们在工程技能组合上看到的最大变化之一是：两年前，产品经理通常会去和一大堆客户交流，花六个月时间与跨职能团队就某份 PRD 达成一致，然后在写下第一行代码之前，先写出一份详尽的规格说明，精确描述我们会如何实现它。现在情况完全反了过来。对很多工程师来说，我想给在座各位的建议是，更多去培养你们对业务的理解和产品判断力，弄清楚我们到底应该做什么，因为从有想法到把它做出来的时间短得多了——已经从六到十二个月缩短到甚至可能只要一周。这意味着我们所有人都需要对什么值得去做、什么真正会推动我们所工作的业务产生变化，有更好的品味。所以，产品品味和商业判断力的价值在上升，而在大多数产品领域里，执行的重要性则略有下降。当然，对于基础设施来说，依然非常强调确保每一个细节都准确无误。

Thariq：对我来说，过去重写代码是不好的，而现在重写是好的。

西蒙：你本来觉得最糟糕的事，现在其实已经没问题了！

Thariq：没错。所有《人月神话》里的那套东西——永远不要重写——我现在是支持重写的。如果你有一套好的测试套件——而且我认为重写实际上会迫使你去确保自己有一套好的测试套件——但我觉得人们低估的一点是，代码库本身就是一种规格说明，也许它是你手里唯一的一份规格说明，因为没有人了解代码库里每一个分支部分。你可以把它当作一种工件来提炼，或者基于它创造其他版本。我们把 Bun 用 Rust 重写了，效果非常好——我现在本地就在用。西蒙：你们还没在 Claude Code 上用 Rust 版 Bun 进行发布，对吧？Thariq：我们内部已经在用了。

Simon：你现在最糟糕的做法，反而已经没问题了！

Thariq：没错。所谓《人月神话》里的那些东西——永远不要重写——我现在支持重写了。如果你有一套很好的测试套件——而且我认为重写实际上会迫使你确保自己有一套很好的测试套件——但我觉得人们低估的一点是，代码库本身就是一份规范，而且也许它是你手上唯一的一份规范，因为没人知道代码库里每一个分支部分。你可以把它当作一种产物，把它提炼出来，或者基于它创建其他版本。我们用 Rust 重写了 Bun，而且效果很好——它现在就在我这儿运行着。

Simon：你们还没有把运行在 Bun-in-Rust 上的 Claude Code 面向所有人发布，对吧？

Thariq：我们内部已经在用了。

（实际上看起来 Anthropic 已经从 6 月 17 日开始向所有人发布运行在 Bun-in-Rust 上的 Claude Code 了。）

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 目前承担了我们 65% 的产品工程 PR。

Simon：是对 Anthropic 全部团队都这样，还是只针对 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 是程序员——它可以克隆代码库，然后说：“这就是这个功能，这是它的样子，这是我使用这个功能时的录屏。”它能支持非常广泛的用途，我认为我们对这一点的理解还处在早期阶段。

Cat：Claude Tag 是一个生活在你们团队协作工具里的 Claude。我们上周把它上线到了 Slack 里。Claude Tag 与众不同的地方在于，它默认就是多人协作的。只要你把 Claude Tag 加进某个 Slack 频道，你就可以发言，你的队友也可以发言，你们可以一起在 PR 上协作。另一个很大的区别是，它是主动式的，而不是被动式的。你可以告诉 Claude Tag：“嘿，监控这个频道里的每一条 bug 报告，创建一个 PR 来修复它，并且标记最后改过这部分代码库的工程师。”在这个频道存续期间，它都会这样做，而你不需要手动再把它拉进来。第三个重大变化是，我们把团队记忆加进来了。如果你在频道里告诉 Claude Tag 你的偏好，它会在之后的每一条未来消息里记住这些偏好。如果你总是希望它排查故障，但不想让它排查警告，只要在频道里用自然语言告诉它这一点，它就会替你和团队里的其他人记住这些设置。<newline><newline>在内部，我们把 Claude Tag 看作是 Claude Code 的演进版。我们认为这代表了我们内部工作方式的一个重大转变。Claude Tag 目前承载了我们 65% 的产品工程 PR。<newline><newline>Simon：是整个 Anthropic 都是这样，还是只针对 Claude Code？<newline><newline>Cat：这只针对我们的产品工程团队——我们内部版本的 Claude Tag 目前承载了我们 65% 的产品 PR。这是一个巨大的转变；这已经超过了我们 PR 总量的 50%。我们看待大家如何在 Claude Code 和 Claude Tag 之间分配工作的方式是：Claude Code 仍然是处理最复杂任务的最佳地点，适合你和 agent 进行交互式迭代。但 Claude Tag 很适合让它代表你主动工作，这样你就不再需要为你正在做的功能所出现的所有 bug 报告，手动启动 Claude Code 了。<newline><newline>Thariq：而对于非编码场景也是如此：比如说，在这次演讲之前，我们问 Claude Tag：“嘿，Fable 什么时候发布？”我们想确保它和公告时间对得上。Claude Tag 会搜索我们的 Slack，看看是谁说了什么。作为你们公司内部的搜索引擎，它真的非常有价值。它掌握了你产品的全部上下文，所以你可以问它与指标相关的问题——通常当你做决策时，你会希望这些决策能受到指标结果的影响，所以你会把它接到你的事件存储上。我看到过我们的市场团队做这样的事情：“嘿，告诉我关于这个功能的信息。”他们不是程序员，但 Claude 是程序员——它可以克隆代码库，然后说：“这是这个功能，这是它的外观，这是我使用这个功能的录屏。” 它能支持各种各样的事情，我认为我们仍然还处在探索这些能力的早期阶段。

西蒙：我在使用编码代理时遇到的一个问题是，我知道怎么把它们当作个人工具来用，但并不太清楚该如何在团队环境中使用它们。听起来 Claude Tag 就是你们目前针对这种团队协作层面的答案。

Cat：没错。而且我们现在相当大一部分会话其实都是多人协作的。比如我可能会说：“嘿，我觉得我们应该在 Cowork 里实现这个新功能，”然后我会让 Claude Tag 先做第一轮处理。接着我会告诉 Claude Tag：“把你的最终实现录下来分享一下，”然后我会让设计团队介入看看。他们会调整一下，再交给工程团队把它收尾并上线到生产环境。整个体验非常流畅。我们仍在摸索如何在同一个会话里引导协作时的社交动态，但我们发现大家只是观察别人怎么用，然后遵循这些社交规范——对我们来说，把 Claude Tag 集成到团队里相当直观。

Thariq：这对教学很有帮助，也能减少乱写一通的内容，因为每个人都能看到你是如何一起使用 Claude 的，这某种程度上也会提升你使用 Claude 的水平。

这让我想起 Midjourney 是如何解决教人们高级图像提示词这一难题的：他们在 Discord 频道里强制公开提示词。

11:41

我自己也一直觉得很难的一件事，是在“真正构建功能的成本大幅下降”之后，判断一个功能到底值不值得现在就发版。

Simon：你们是怎么处理工程里最难的问题——优先级排序的？在如今开发一个功能便宜得多的情况下，你们如何决定哪些功能值得去做、值得发布？

Cat：这就是最难的部分。我们有几种处理方式。其中一种是我们每天都亲自使用自己的产品。每当我们发现，在自家产品里有些我们想做却做不到的事情时，我们不会去找别的解决方案，而是直接修我们的产品，让它支持那个用例。我们内部有非常强的“狗食”文化。在把产品分享给全世界之前，我们会先分享给 Anthropic 内部的所有人，以及一些早期客户，让他们给我们非常坦诚的反馈——越尖锐越好——然后我们不断迭代，直到大家真的喜欢它。我们内部有一条门槛：一个功能在向全世界发布之前，必须达到一定的活跃用户数和留存水平。因为这条门槛非常明确，每个工程师都知道自己要达到什么目标。我觉得这也提升了我们的打磨水平，因为如果功能不够精致，用户就会流失——那我们就不应该发布这个功能。

Simon：你们是怎么处理工程里最难的问题——优先级排序的？在如今开发一个功能便宜得多的情况下，你们如何决定哪些功能值得去做、值得发布？

利用内部用户留存来判断一个功能是否应该发布，我觉得非常合理。

Simon：你有没有一个让你感到意外的功能例子？你们把它推出去之后，参与度高得离谱——原本看起来不太可能上线的东西，最后却真的成了一个产品功能。Cat：有，我确实有一个。我们团队里很多人都很喜欢 remote control。remote control 让你可以用移动设备，或者在网页浏览器里的 Claude，连接到在 CLI 中运行的本地 Claude Code 会话。我自己从来没有这种需求，因为我通常会直接在手机上发起任务，它会在云端会话中运行，而不会使用我的本地环境——我想这是因为我做的都是非常简单的编码任务。这件事我一开始并没有完全理解；我当时还在想，嘿，大家应该直接搭好远程开发环境就好了。但在实际使用中，当我们推出 remote control 之后，我跟很多人聊过，他们都告诉我，他们每天晚上都会把笔记本电脑接上电源充电器，打开一堆 remote control 会话，锁上屏幕，然后躺在沙发上用手机控制 Claude Code。所以这已经变成了我们现在开始重点投入的一个使用流程，而这原本是我没想到的——但现在我明白了。

在这次大会上，一个贯穿始终的主题是 review：人们会花多少注意力去审查由编码代理为他们编写的代码。我非常想听听 Claude Code 团队对此的看法！

Simon：代码审查是怎么运作的？进入 Claude Code 的每一行生产代码，都会由人类来审查吗？如果不是，你们在做什么——又是如何保持质量的？

Thariq：这会根据任务有很大差异。对于重要领域，我们会有 code owner。system prompt 就是一个例子，我们在这方面有 code owner——你真的需要得到他们的批准。

Simon：所以，code owner 对代码的那个领域的质量直接负责。

Thariq：没错。

Cat：而且任何触及它的 PR，他们都需要批准。

Thariq：我们有自己的 code review GitHub bot 审查所有内容——它会出现在每个 PR 上，而且通常它承担了大部分审查工作。我在团队里见过的一件事是，对于更复杂的 PR，你可能会制作一个 artifact 来解释这个 PR，这样其他人就可以审查。我们也在验证、CI/CD 之类的方面投入很多，以确保任何时候只要出问题，我们都有测试。我们有一个非常稳健的环境，让 Claude 可以控制 Claude Code 并对其进行测试。所以代码审查是多管齐下的。

Cat：总体来说，我们正努力迈向一个不需要人类介入的世界。对于 Claude Code 核心，以及其他产品核心中最关键的变更，始终都会有 code owner，他们会手动审查所有变更。但越来越多地，对于外层的变更，我们实际上已经让 Claude code review 完整审查这些内容了。这听起来可能很吓人，但我们已经花了六个多月的时间才走到这一步，而且你需要一步一步来，才能建立对 code review 的信任。起初，我们对所有内容都进行人工审查，然后我们会逐渐说，好吧，对于那些涉及这些文件的代码变更，code review 能捕捉到 100% 的问题——所以我们实际上不需要人类再手动审查这些了。而当我们做 incident review 时，我们会查看导致事故的那些 PR，并说，好吧，我们要如何更新 code review 才能捕捉到这一点？——然后我们会把这些 PR 加入一个 eval 集，确保我们未来对 code review 的任何改动都不会让那个指标回退。把人类从代码审查流程中移除，是向前迈出的一大步。它听起来可能很可怕，也不是一夜之间就能做到的，但你可以通过在基础设施上持续投入很多个月来实现这一点，从而获得信心，确认 code review 能捕捉到你关心的一切。

Thariq：我们有自己的代码审查 GitHub bot 来审查一切——它会参与每一个 PR，而且通常承担了大部分审查工作。我在团队里见到的一种做法是，对于更复杂的 PR，你可能会制作一个说明该 PR 的 artifact，这样其他人随后就能审查。我们也在验证、CI/CD 以及类似方面投入很多，以确保任何时候只要出了问题，我们都有测试可依。我们有一个非常强大的环境，Claude 可以控制 Claude Code 并对其进行测试。所以，代码审查采取的是多管齐下的方法。

Cat：总体来说，我们正努力走向一个不需要人类介入的世界。对于 Claude Code 核心以及其他产品核心中最关键的改动，始终都会有一位 code owner，他们会手动审查所有变更。但越来越多地，对于外层的改动，我们实际上会让 Claude code review 完整地审查这些改动。这听起来可能相当吓人，但我们已经花了六个多月的时间才走到这一步，而且在建立对代码审查的信任过程中，你需要一步一步来。起初，我们对所有东西都进行人工审查；然后我们会越来越多地说，好吧，对于那些会触及这些文件的代码改动，代码审查已经能捕捉到 100% 的问题——所以我们实际上不需要人工再手动审查这些了。当我们做 incident review 时，我们会查看导致事故的那些 PR，然后说，好，我们该如何更新代码审查来捕捉到这一点？——接着我们会把这些 PR 加入一个 eval 集，确保我们未来对代码审查所做的任何改动都不会让这个指标倒退。把人类从代码审查流程中移除，是向前迈出的一大步。它听起来可能很可怕，也不是一夜之间就能做到的，但你确实可以通过数月时间对基础设施的投入来实现它，从而让你有信心，代码审查能够捕捉到你关心的一切。

所以，关键似乎是在自动化审查系统本身上持续迭代，以便随着时间推移建立对它们的信任。

17:20

我们深入讨论了 evals——这也是整个大会期间另一个热门话题。

西蒙：我知道，像 Opus 4.8 这样的模型，如果我让它帮我构建一个执行 SQL 查询并输出 JSON 的 JSON 端点，它基本上会直接做对——这不是我需要认真审查的东西。但如果来了一个新模型，我就不知道该怎么快速建立对 Fable 的信任，确认它不会犯 Opus 没有犯过的那些错误。新模型会怎样影响你对它能做什么、不能做什么的直觉？

Cat：我们之所以会随着时间不断建立这套评测基础，主要原因就是为了让新模型可以直接替换上来。当我们有了新模型，就会跑完整套评测集，并确保例如 Fable 确实比 Opus 4.8 更好——这样我们才有信心把它直接替换进去。

西蒙：这些模型评测是面向整个 Anthropic，还是只针对 Claude Code 团队？

Cat：两者都有。我们团队内部有评测，而且我们会对 Anthropic 内的每个代码仓库做代码审查，所以我们也有相应的评测。至于 auto mode 之类的功能，我们不仅在 Anthropic 内部对所有用户都做了评测——我们还委托了多位外部测试人员对其进行红队测试，构建带有 prompt injection 和恶意输入的环境，确保 auto mode 不会放行其中任何一项。

Simon：我想知道，我对系统提示词所做的改进是否真的改善了产品——这是一种最基本的、针对产品的评估方式，而我仍然没有很好的感觉去判断该怎么做。你们会做到对某个系统提示词的微调能带来更好的输出时，拥有完全的信心吗？

Cat：我们没有完全的信心，但我们会做很多工作来确保不会让性能倒退。起点是一套我们信任的外部评估，我们还会用一套规模更大的、我们同样信任的内部评估来补充。最开始，我们主要优化的是能力：在给定一个任务的完整定义和完整代码库的情况下，Claude 是否能做出正确决策、彻底修复 bug，并通过所有测试？这就是起点，也是我们优化的重点，因为它最直接对应用户想要的东西。但有很多行为会影响用户和 Claude Code 一起工作时的感受。比如，很多人非常不喜欢 Claude Code 说“该睡觉了”的时候。或者当它说“嘿，我已经完成了五个部分中的两个——你要我继续吗？”的时候，人们真的很不喜欢。是的，请继续。所以我们正在建立一套行为评估来捕捉这些问题。随着我们收到用户反馈——请大声地告诉我们你的用户反馈——我们会把优先级高的问题排好，逐个推进，并为每个问题建立相应的评估。这还不是 100% 覆盖，但提高覆盖率是我们的优先事项。

Simon：Claude Code 团队与 Anthropic 中最初负责训练模型的团队之间有多少互动？这是不是一种非常紧密的协作？

Cat：在 Anthropic 内部，我们大家都合作得非常紧密。我们经常开会，讨论我们对下一代模型能力的预期。我们的研究团队也非常出色，经常把这些内容公开分享——我们常常在博客文章里谈到，我们的目标是让模型能处理越来越长周期的任务，以及我们如何训练 Claude 本身变得诚实、无害且有帮助。我们也投入了大量精力，确保它能够与用户的意图保持一致，即使这种意图表达得比较模糊。当然，你最好尽可能具体地说明你想要什么，这样 Claude 就能拥有全部上下文——但即使你没有说得很具体，我们也会训练 Claude 作出合理的判断。这是一段富有成效的合作关系。

Simon：Claude Code 团队与 Anthropic 中最初负责训练模型的团队之间有多少互动？这是不是一种非常紧密的协作？

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。所以这里需要一点直觉——有时你真的就是想要前沿级智能，几乎总是如此。Pareto 曲线会发生变化，而且很难把握。

Simon：一年前，我不信任模型来写提示词。今天，优秀的模型在提示方面已经非常出色——我现在很多提示词都是模型写的，这听起来荒谬，但确实非常好用。让我逐渐接受这一点的，是我想到 subagents 这件事，它本质上就是一个 Claude 模型为另一个 Claude 模型设定提示词。Thariq：Workflows 其实就是一个很好的例子，因为这里并不只是 Claude 在提示一个单独的 subagent，而是在提示多个 subagent 的编排方式，而且每一个 subagent 都会得到非常详细的提示词。这几乎比单纯派生出一个 subagent 高了一个层级。我个人机器上也一直在这么用：我给它 Gemini API，然后说，来，生成图片。它在为图像模型写提示词这件事上，比我懒得多。说到底，就是 Claude 一路在给 Claude 写提示词。Cat：我觉得 Claude 还写了 workflow 工具的提示词。

Simon：我读过那个提示词——写得很好。实际上，我对 Anthropic 整体有一个不满：你们公开了 Claude Chat 的提示词，但没有把工具提示词和 Claude Code 的提示词也一并公开。我至今仍得跑一个代理去拦截它们。我真的很希望 Claude Code 的提示词能被有意地公开——它们就是文档。它们能让你知道这个工具能做什么，以及它是怎么工作的。Cat：我记下这个功能请求。我会让 Claude Tag 去做。

Simon：Thariq，今天早上你提到，因为 Claude Fable，Claude Code 的系统提示词已经缩减了 80%。你能再详细说说吗？你们具体删掉了哪些内容？

Thariq：不只是 Fable——Opus 4.8 也是，而且以后还会有未来的模型。现在我们针对不同模型有不同的系统提示词。我们观察到的一种模式是，我们对 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 只是在给单个 subagent 写提示词，而是在给多个 subagents 的编排写提示词，而且每一个 subagent 都会拿到非常详细的提示词。这几乎比简单地启动一个 subagent 高一个层级。我个人电脑上也一直在用它，把 Gemini API 交给它，然后说：来，生成图片吧。它在为图像模型写提示词这件事上，比我勤快多了。说到底，就是 Claude 一路给 Claude 写提示词。

Cat：我觉得 Claude 还给 workflow 工具写了提示词。

Simon：我读过那个提示词——写得很好。说实话，这正是我对 Anthropic 整体上有点不满的地方：你们会公开 Claude Chat 的提示词，但不会把工具提示词和 Claude Code 的提示词也一并公开。我现在还得跑一个代理去拦截它们。我很希望 Claude Code 的提示词能被有意公开出来——那就是文档。你只有通过它们，才能知道这个工具能做什么、是怎么工作的。

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

值得注意的是，OpenAI 针对 GPT-5.6 的提示词最佳实践也包括了类似建议，适用于他们最新的模型：

倾向于更精简的提示词删除重复的指令和示例，并简化工具说明，可以提升任务表现和 token 效率。在一组内部编码代理评测运行样本中，更精简的系统提示词配置将评测分数提高了约 10–15%，同时把总 token 数降低了 41–66%，成本降低了 33–67%。

倾向于更精简的提示词

删除重复的指令和示例，并简化工具说明，可以提升任务表现和 token 效率。在一组内部编码代理评测运行样本中，更精简的系统提示词配置将评测分数提高了约 10–15%，同时把总 token 数降低了 41–66%，成本降低了 33–67%。

28:06

Simon：Claude Code 基本上就是一大堆工具。你为引入一个新工具设定的门槛是什么？你怎么判断在那个层级做额外工程值不值得？

Cat：你想先回答吗？你引入了我们最好的工具之一。

Thariq：我职业生涯的巅峰就是我引入了 ask user question 工具。这个真的很难。尤其是对某些工具来说——ask user question 是 Claude 用来向你提问的工具——所以很难做评测，而且有时这更多是用户偏好问题。那时候我们的评测还比较少，所以很大程度上是基于我们自己“狗食测试”——或者说“蚂蚁食用”，这是我们的蚂蚁版本说法。不过总体而言，我们一直在努力把工具数量往更少的方向发展。我想我们最近引入的一组工具是 task 工具——而且我们会尝试给 Claude 更通用的做事方式。

我对文件编辑工具一直有一种长期的着迷——它们曾是旧版 Aider 代码编辑排行榜的主题，而我也一直饶有兴趣地观察它们在不同编码代理中的演进：从基于搜索替换，到基于行号，再到更复杂的模式。

Claude API 文档描述了一种文本编辑工具，并建议在基于 API 构建时使用它，但 Claude Code 在这里似乎采用了略有不同的方法。

Simon：最有意思的工具之一是文件编辑工具——你可以把文件编辑作为一个工具，或者告诉它用 sed 和 grep 之类的方式去做。你们文件编辑工具的最新演进是什么？

Thariq：我们现在仍然有这个工具，不过比如说，我们已经移除了 grep 和其他搜索工具——glob 工具——转而使用原生 bash。就像我在前面的演讲里说的，模型某种程度上更像生物学，而不是物理学，尤其是工具设计其实相当困难。我不确定 Cat 是否不同意、并认为评估它有一套科学方法，但我觉得工具设计更像是一门艺术，也许——或者说更像生物学。

Cat：我基本同意，不过总体来说，随着我们引入更多工具，我们会尽量把 cardinality 控制得很低，并确保我们添加的每一个工具和其他工具都有明确不同的功能，这样 Claude 就能很容易地区分何时该调用哪个工具。至于文件编辑，我们之所以保留它，实际上是因为我们可以把它渲染出来。当 Claude 做出文件更改时，我们会向用户展示，而且会有一个很好的专用界面，上面写着：你是否批准对这个文件的这次编辑？我们之所以有一个专门的文件编辑工具，是为了能确定无误地知道 Claude 正在进行文件更改，这样我们就能向用户展示这个漂亮的界面。很多刚完成上手流程的新用户仍然非常喜欢这种体验，所以我们一直保留着它。不过对我们很多现在处于 auto mode 的人来说——希望你不是处于 YOLO mode——我觉得这其实并不重要，我们大概完全可以把 file edit 删掉，也不会有任何问题。

这就是提示注入这个问题！还有谁能比 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% 的问题——那样的说法就太夸张了。但对于我们关注的主要风险类别，比如提示注入和数据外泄，风险都远低于普通人工审查者。

Cat：我们会把相关评测结果分享出来，方便大家进行评估，不过我们一直非常谨慎地识别 Claude 可能出错的各种方式，并据此更新 auto mode 来加以应对。它并不能捕捉到 100% 的问题——那样的说法就太夸张了。但对于我们所担心的主要风险类别，比如提示注入和数据外泄，其风险都比普通人工审阅者低得多。

我非常期待进一步了解他们的评测结果以及验证 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 出来多久了？作为我能接触到的一个功能，它也就推出几个月，对吧？

Simon：我之前没意识到自动模式也会和网络沙箱交互。

Cat：它会和用户原本会看到的任何权限提示交互。

Simon：自动模式有多长时间了？作为我能使用到的一个功能，它也就几个月前才推出，对吧？

（它于 3 月 24 日首次向公众开放。）

Cat：我们从 1 月起就在 Anthropic 内部使用它，所以已经对它进行了相当长一段时间的加固。Anthropic 对安全和保障极为重视，我们一直在更广泛地与对齐和安全保障团队协作，推动内部部署，构建这些评估，并在向世界分享之前让自动模式变得更加稳健。Thariq：这也是 Claude Tag 如此出色的原因——Claude Tag 使用了自动模式。我听过很多关于 Slackbot 是自己做还是买现成的讨论，我想说：拜托，你大概不应该自己做 AI Slackbot。攻击向量太多了。你有一个用户可以提交反馈的反馈渠道，而现在你的机器人正在读取它。我们在自动模式上投入的工作——而且我们在安全方面有一套通用的“瑞士奶酪”式防御；我们也会用 RL 来对抗这类问题——我认为这正是 Claude Tag 能发挥作用的原因。它能与你的权限无缝配合，而你也不希望在 Slack 里被 prompt injection。

Cat：我们从 1 月起就在 Anthropic 内部使用它，所以已经对它进行了相当长一段时间的加固。Anthropic 对安全和保障极为重视，我们一直在更广泛地与对齐和安全保障团队协作，推动内部部署，构建这些评估，并在向世界分享之前让自动模式变得更加稳健。

Thariq：这也是 Claude Tag 如此出色的原因——Claude Tag 使用了自动模式。我听过很多关于 Slackbot 是自己做还是买现成的讨论，我想说：拜托，你大概不应该自己做 AI Slackbot。攻击向量太多了。你有一个用户可以提交反馈的反馈渠道，而现在你的机器人正在读取它。我们在自动模式上投入的工作——而且我们在安全方面有一套通用的“瑞士奶酪”式防御；我们也会用 RL 来对抗这类问题——我认为这正是 Claude Tag 能发挥作用的原因。它能与你的权限无缝配合，而你也不希望在 Slack 里被 prompt injection。

Simon：除了自动模式之外，后面还有什么更进一步的安全性功能在路上吗？

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

Simon：因为 Claude Tag 会受到任何能和它对话的人的影响——给它出主意的人更多，范围也大得多。

Thariq：没错。当然，我们也有和 Fable 配合的 probes，这也是我们安全与研究工作的一个下游成果。我认为，这正是你看到 Anthropic 作为一家 AI 安全公司真正开始发挥作用的时刻：我们非常希望 Claude 能够在较长时间内以对齐的方式运行，而自动模式要想做到这一点，基本上必须毫无瑕疵——这一切都是我们作为 AI 安全公司这一定位的下游结果。

Cat：我们也为那些希望更安全的远程控制用户推出了受信任设备。对于我们所有的远程环境，我们都支持凭据注入。如果你希望 Claude Code 能访问 Datadog，但又不想让 Claude Code 本身持有 Datadog 凭据，你可以设置我们的身份与凭据管理系统，让 Datadog 凭据只能被代理使用，而代理本身无法访问——当代理尝试发起 Datadog 请求时，我们会即时把它们注入进去。

我非常喜欢这种凭据注入模式：Claude Code 可以通过代理访问某个 API，而这个代理既会审计请求，又会注入相关的 API 密钥——这样 Claude 就能访问需要认证的端点，但它自己并不拥有这些 API 凭据。

Thariq 在上午的主题演讲中谈到了 Fable-class 模型带来的某种悲伤感，我们在对话中进一步深入讨论了这个话题。我一直把这称为 Deep Blue。

Simon：让我们稍微谈谈人的因素吧。现在有很多人都感到一种失落，因为他们曾经认为自己在软件构建中的角色，如今很大一部分正在被模型所吞没。你怎么看这件事？过去一年半里，这改变了你对自己技艺以及你所创造价值的看法吗？

Thariq：Cat 和 Boris 总是很好的提醒，让你必须有更大的野心。他们总是说：我们的增长这么快，我们必须站在最前沿，我们必须尽我们所能做出最好的工作。这对我来说是一个持续不断的提醒——每当我在某件事上慢下来时，我就会想，好吧，我能不能做得更快？我能不能在这里更有野心一点？而很多时候答案就是 Claude，因为 Claude 会随着你的使用而不断变强——上一次我尝试这么做时，用的还是前一个模型。关于你提到的这种失落感：我觉得这是真实存在的。如果你只是想做和 LLM 出现之前一样的工作，而现在它变成了一条提示词，我觉得这会让人有点难过。抵消这种感觉的方法就是变得更有野心。我觉得 Jared 就是个很好的例子——他在奥克兰的公寓里，差不多用一年时间手写了全部 Zig 代码，几乎没怎么离开过家，而且做这件事时玩得特别开心。现在我看到他把整个 Bun 重写成 Rust，他也做得非常开心——这要更有野心得多，而这就是他抵消那种感觉的方式。总的来说，就是要问自己：我怎样才能做更大的事、做更多的事——我认为成功是有趣的。关键在于改变你的雄心。

“你通过更有雄心来抵消这一点”的说法，正好也准确概括了我自己对这个问题的看法。

Simon：那从产品管理的角度来看，Cat，这会是什么样子？Cat：我感觉产品角色每个月都在变化。我们团队里的所有 PM 都是工程师、设计师和 PM 的混合体——他们中的大多数其实以前都是全职工程师。对我们来说，这真的意味着只要哪里有缺口就去补上。如果我们有一个想法，但没能激发任何工程师去把它做出来，那我们就自己把它做出来，先记到笔记里，再去激励大家把它推向生产环境。如果设计看起来有点不对劲，那就找一个类似的页面，先做一版初稿设计，再拉上一个非常注重细节的人来填补空白。或者，如果我们注意到我们的团队和产品在公司内部的采用规模变得更大，更多人需要知道 Claude Code、Claude Tag 和 Cowork 接下来会有什么动作——那就把梳理整个发布日历这件事自动化，把状态更新异步化，这样我们就不用一直打扰别人，并确保我们在内部公告频道里的更新足够详细，而且直截了当。对我们来说，很大程度上就是要搞清楚：从一个好点子到把东西交到客户手里之间，现在到底差了什么，以及我们如何尽可能把这个过程自动化。

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

Cat：我感觉产品角色每个月都在变化。我们团队里的所有 PM 都是工程师、设计师和 PM 的混合体——他们中的大多数其实以前都是全职工程师。对我们来说，这真的意味着只要哪里有缺口就去补上。如果我们有一个想法，但没能激发任何工程师去把它做出来，那我们就自己把它做出来，先记到笔记里，再去激励大家把它推向生产环境。如果设计看起来有点不对劲，那就找一个类似的页面，先做一版初稿设计，再拉上一个非常注重细节的人来填补空白。或者，如果我们注意到我们的团队和产品在公司内部的采用规模变得更大，更多人需要知道 Claude Code、Claude Tag 和 Cowork 接下来会有什么动作——那就把梳理整个发布日历这件事自动化，把状态更新异步化，这样我们就不用一直打扰别人，并确保我们在内部公告频道里的更新足够详细，而且直截了当。对我们来说，很大程度上就是要搞清楚：从一个好点子到把东西交到客户手里之间，现在到底差了什么，以及我们如何尽可能把这个过程自动化。

这反映了我注意到的一点：当你能把代码产出速度提高这么多时，花在等待别人做决定上的时间，就会成为一个更加明显的瓶颈。能够自己做产品决策的工程师，行动速度会快得多，而把某个决策做错的代价也没那么高得让人难以承受。

41:50

西蒙：Claude 有哪个时刻让你感到惊讶？也就是它做出了你没想到它能做到的事情？

Thariq：我发过很多关于 Claude 视频编辑的内容，但最近我在 ACM Agentic 会议上做了一场演讲，我问他们：“嘿，伙计们，你们有剪好的视频吗？我很想发出来，也想和我的公关团队分享。”他们说：“哦，这得花很久。”于是我就要了原始文件。他们把我在台上讲话的视频、演示文稿的视频，还有音频文件发给了我，并说：“祝你好运。”我把这些连同我的 HTML 演示稿一起交给 Claude，说：“嘿，你能把这些直接剪在一起吗？”它做出来的效果真的令人难以置信——我已经准备把它直接发出去了。它会把整段视频转录出来。它还注意到我的演示文稿视频有时候有点奇怪——中间会弹出一个自动更新窗口——于是它会说：“哦，我大概不该用你的演示文稿视频。我要做的是把它切开，判断你现在讲到哪一页，然后改用 HTML 源文件。”于是它就会显示 HTML 源代码。然后它还有我的视频，但我在舞台上只占了很小一部分，所以它会动态裁切到我所在的位置——而我来回走动，它就会跟着我移动。与此同时，它还在转录我说的话。

西蒙：这是 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 的公司文化中，哪些部分能够独特地帮助 Anthropic 用这些工具提高生产力，其他公司应该借鉴？人们应该从你们这里学到哪些文化上的“小窍门”？

Cat：我想分享一个关于 Claude Tag 的例子。Claude Tag 在公共频道里使用效果最好，而且当你大多数频道都是公共频道时，它的表现也最好。Claude Tag 能够跨所有公共频道进行搜索，尽可能获取更多上下文，从而给你最准确的答案——而且只有在它能访问全部内容时，才能做到这一点。

Thariq：我在主题演讲里提到过这一点，但它对我来说太重要了，所以我想再次强调。创始人们说，我们不要和自己讨价还价，我认为这一点非常重要。你完全可以在脑海里想象各种取舍，然后说服自己不要去做某件雄心勃勃的事——也可以直接去尝试做那件雄心勃勃的事。我们经常会问：如果我们就这么做了会怎样？这真的是一种取舍吗？如果是，为什么——有什么证据证明这是一种真实的取舍，而不只是听起来合理的东西？让取舍自己显现出来。尽可能地大胆。

46:46

我忍不住也把这一点加进来了。

西蒙：你用 Claude 做过、只是因为“既然能做就做了”的最荒诞、最喜欢的东西是什么？

塔里克：我正在做一个 2D《街头霸王》格斗游戏，里面有我自己当角色——还有我的朋友们。它用 Claude Code 来提示 Gemini——说实话，Seedance 模型也相当不错——来制作视频动画。效果非常好；它在提示方面特别强，还能验证各个帧，检查某个动画到底好不好。

西蒙：你生成的是《街头霸王 2》那种级别的 2D 角色精灵吗？

塔里克：对，完全就是那种 2D sprites。动画看起来很惊艳。而且它还能算出 hitbox——它会像这样说：“哦，你的拳头在这里，我来画这个 JSON hitbox。”太不可思议了。

卡特：我的就简单多了。我是个很喜欢攀岩的人，我很多朋友也都攀岩，所以我们用 Claude Code 做了一个小应用，记录我们正在做的所有路线项目。我们也经常一起去户外，所以我们让 Claude 用 workflows 做各种研究。Workflows 非常棒——我们把它定位成一个编程工具，但它其实非常适合做旅行方面的深度研究。我还负责规划团队的 offsite 活动，它也很擅长找能容纳我们所有人的场地。我会用 workflows 去研究我们可能想去的攀岩目的地，以及从我们各自所在地点出发有哪些直飞航班。它会去 Mountain Project 上把符合我们难度等级的攀爬线路都找出来。它会去找 Airbnb。还有，我不喜欢徒步，所以我很在意它必须有非常短的 approach——也就是从停车处走到真正岩壁的距离要非常短——它也会按这个条件筛选。用现成的应用时，我得手动在 Mountain Project 里一点点点进去看，但用这个，我只要输入我们所有的偏好，它就变成了一个为我们量身定制的应用。

西蒙：所以你们基本上是在给攀山做 vibe coding Jira。

卡特：没错。

Cat：我的就简单多了。我是个很喜欢攀岩的人，我很多朋友也都爬岩，所以我们用 Claude Code 做了一个小应用，用来记录我们正在做的所有项目。我们也经常一起去户外，所以我们让 Claude 用 workflows 帮我们做各种研究。workflows 非常棒——我们把它包装成编码工具，但它其实特别适合做旅行方面的深度研究。我还负责安排团队的外出团建，它很擅长帮我们找到能容纳所有人的场地。我会用 workflows 去研究我们可能想去的攀岩目的地，以及从我们各自所在地出发有哪些直飞航班。它会去 Mountain Project 上找出所有符合我们等级的路线，帮我们找到 Airbnb。还有，我不喜欢徒步，所以我非常在意它的接近路程要很短——也就是从停车处走到真正岩壁的距离要非常短——而它会把这个条件过滤出来。用现有应用时，我得手动在 Mountain Project 里一点一点点进去看，但用这个工具，我只要输入我们所有的偏好，它就会变成一个专为我们定制的应用。

Simon：所以你们基本上是在给登山攀岩做 vibe coding 的 Jira。

Cat：没错。

49:23

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

观众：你们近期有没有计划为我们构建更多 eval 工具，用来搭建 eval 数据集，以及更多 observability 工具来监控 agents 和 workflows 的表现？Cat：我们考虑过做 eval 工具，但我觉得真正的限制因素往往其实是，客户要花很长时间才能做出真正高质量的 eval。所以我认为限制更多的不是工具本身，而是如何构建一个优秀 eval 的技能。这正是我们很愿意在内部持续投入、并且希望也能对外分享一些最佳实践的领域。

观众：你们近期有没有计划为我们构建更多 eval 工具，用来搭建 eval 数据集，以及更多 observability 工具来监控 agents 和 workflows 的表现？

Cat：我们考虑过做 eval 工具，但我觉得真正的限制因素往往其实是，客户要花很长时间才能做出真正高质量的 eval。所以我认为限制更多的不是工具本身，而是如何构建一个优秀 eval 的技能。这正是我们很愿意在内部持续投入、并且希望也能对外分享一些最佳实践的领域。

50:08

观众（Sai）：我对 memory 和 multiplayer 很感兴趣。现在 memory 是怎么设计的？我猜是围绕文件来做的。第二，你们有没有考虑过一种正交方向，也就是为了更好地扩展，实际上需要给这些 memories 配一个数据存储，而不是文件？Thariq：目前在 Claude Tag 里，memory 是按频道划分的。那个频道里的每个 Claude 都共享一份 memory，而这些实例有一个 session——但这个 session 可以把内容回写到主 memory 里。我们做了很多 memory 研究，而怎样才是正确的 memory 设计方式，有时候会很违反直觉。我们一直在做 memory 实验。现在 Claude Tag 的实现方式是，每个频道对应一个 markdown 文件。

受众（Sai）：我对记忆和多人协作很感兴趣。现在记忆是如何设计的？我猜是围绕文件来做的。其次，你们有没有考虑过一种正交方向，也就是实际上需要用数据存储来承载这些记忆，而不是文件，这样能更好地扩展？

Thariq：目前在 Claude Tag 里，记忆是按频道划分的。该频道里的每个 Claude 都共享同一份记忆，而各个实例有自己的会话——但会话可以把内容回写到主记忆里。我们做了很多记忆研究，而记忆究竟该怎么做，往往有点反直觉。我们一直在做记忆实验。就目前 Claude Tag 的工作方式来说，每个频道对应一个 markdown 文件。

来源与参考

收录于 2026-07-22