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

# 与 Claude Code 团队的 Cat 和 Thariq 炉边谈话 来源：https://simonwillison.net/2026/Jul/21/cat-and-thariq/ 2026 年 7 月 21 日 本月早些时候，我在 AI 工程师世界博览会（https://www.ai.engineer/worldsfair/2026）上主持了一场炉边谈话，嘉宾是 Anthropic Claude Code 团队的 Cat Wu 和 Thariq Shihipar。我们聊了 Claude Code、Claude Tag、Fable、编程代理安全、评估、工具设计，以及 Anthropic 团队自身如何使用这些工具。 整场谈话的视频现已在 YouTube（https://www.youtube.com/watch?v=uU5Gv2h8-9g）上提供。以下是经过编辑的文稿副本，附有额外链接和我自己加粗的重点。 如果你不想看视频或通读整篇文稿，这里有几个要点： - Claude Tag（Claude 新的协作式 Slack 集成）目前为 Claude Code 团队**落地了 65% 的产品工程 PR**。 - Claude Code 先向 Anthropic 员工发布功能，**并且只发布那些在该群体中表现出用户留存的功能**。 - 对 Claude Code 的变更仍由人工审核，但团队越来越依赖自动化代码审查来处理产品的“外层”。 - 对于 Fable 5 甚至 Opus 4.8 这样的模型，在系统提示中添加示例**已不再是最佳实践**。Claude Code 的系统提示最近**缩减了 80% 的大小**。 - 同样，列出“**不要做 X，不要做 Y**”之类的规则可能会降低最新模型的结果质量。 - Anthropic 内部的内部试用（https://en.wikipedia.org/wiki/Eating_your_own_dog_food）被称为“**蚂蚁食粮**”。 - Anthropic **非常相信他们的自动模式（https://code.claude.com/docs/en/auto-mode-config）**，并将其视为 Claude Tag 的使能技术。 - Thariq 建议通过“**在工作中更加雄心勃勃**”来抵消编程代理引发的“深蓝（https://simonwillison.net/2026/Feb/15/deep-blue/）”效应。 - Fable **擅长编辑视频**，Thariq 用它（https://twitter.com/trq212/status/2064826394589442448）来编辑自己的发布视频。 - Anthropic 在公共（内部）工作的文化是其成功的关键，正如他们在公共 Slack 频道中使用 Claude Tag 所展示的那样。 #### 在过去一年里，你的日常工作发生了怎样的变化？ 1:05（https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=65s） > **Simon：** Claude Code 是在去年 2 月推出的——到现在还不到一年半，最初它只是 Claude Sonnet 3.7 发布（https://www.anthropic.com/news/claude-3-7-sonnet）中的一个要点。**在过去一年里，你的日常工作发生了怎样的变化**，既然我们现在有了真正能为我们工作的编程代理？ > **Cat：** 我记得我们刚推出 Claude Code 和 Sonnet 3.7 时，你给它一个任务，就必须密切监视它试图做的每一件小事。我会非常仔细地阅读每个权限提示。我经常说不行——不，不，不，你检查过这个文件吗？你检查过那个文件吗？而现在，随着每一代模型的更新，情况变得不可思议。我感觉**我们都有了机会后退一步，将更多琐碎的实现工作委托给 Claude**。它释放了我们大量时间，让我们能思考更有创意的工作，比如：既然我们知道 Claude Code 能实现很多功能，那么我们应该为用户提供什么样的正确体验？而如今有了 Fable，这又是一个完全不同的阶梯式改进。**我们看到，对于许多用例，现在可以用 Fable 一次性完成大量功能**。 > **Thariq：** 我记得我收到关于 Claude Code 的第一条消息。我最好的朋友之一说：“你得去试试 Claude Code。”那大概是 Opus 4 刚发布的时候，我试了试，然后想：“哦，靠。我现在得去 Anthropic 工作了。”那是 Opus 4——很棒的模型，但你还在阅读权限提示。我们有多健忘，这有点疯狂，我甚至觉得自动模式一直都在，对吧？我甚至不记得曾经按过“是”和“允许”。对我来说，我要推动自己做到的是**我们必须比以往做出更高质量的工作**。输出质量高得惊人。**我一直在用它大量编辑视频**，我想，好，它必须在几个小时内满足我们品牌团队非常苛刻的要求，否则我们就没法做。**这就是我试图通过 Fable 实现的变化：以比以往更快的速度做出我们有史以来最好的工作**。 #### 传统的软件工程中，哪些观点已不再成立？ 3:39（https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=219s） > **Simon：** 传统的软件工程中，有哪些观点在一年前还成立，但现在你觉得在这个新世界里已经不再适用？ > **Cat：** 我们在工程技能方面看到的最大变化之一是：两年前，典型的做法是产品经理去和一群客户交谈，花六个月时间与跨职能团队对齐，写一份 PRD，然后在写第一行代码之前就制定出详细规范，精确说明如何实现。现在情况完全反过来了。对于很多工程师，我想给在场的人的建议是**更多地培养你对应该构建什么东西的商业意识和产品意识**，因为从想法到实现的时间线大大缩短了——从六个月到十二个月缩短到可能只要一周。这意味着我们所有人都需要有更好的品味，判断什么值得构建，什么才能真正影响我们所在的业务。所以，**产品品味和商业意识的价值上升了，而在大多数产品领域，执行的价值略有下降**。当然，对于基础设施，仍然非常强调确保所有细节都正确。 > **Thariq：** 对我来说，是**重写现在变得可行了**。 > **Simon：** 以前最不该做的事，现在反而可以了！ > **Thariq：** 没错。所有关于《人月神话》的讨论——永远不要重写——我现在支持重写。如果你有好的测试套件——而且**我认为重写实际上会迫使你确保拥有好的测试套件**——但我觉得人们低估的是，**代码库就是一份规范，而且可能是你拥有的唯一一份规范**，因为没人知道代码库的每个分支部分。你可以把它当作一个人工制品，去提炼它或者创建它的其他版本。我们把 Bun 用 Rust 重写了（https://bun.com/blog/bun-in-rust），效果很好——我目前就在用。 > **Simon：** 你们还没有把用 Rust 重写的 Bun 上的 Claude Code 发布出去，对吧？ > **Thariq：** 内部已经在用了。 *（实际上，看起来 Anthropic 在 6 月 17 日（https://simonwillison.net/2026/Jul/19/claude-code-in-bun-in-rust/）就开始向所有人发布基于 Rust 重写的 Bun 上的 Claude Code 了。）* #### 非工程师用 Claude Tag 做些什么？ 6:36（https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=396s） > **Simon：** 最近另一个重要发布是 **Claude Tag（https://www.anthropic.com/news/introducing-claude-tag）**——对我们其他人来说，大概才一周吧。我了解到它在 Anthropic 内部被非工程师大量使用。**非工程师用 Claude Tag 做些什么？** > **Cat：** Claude Tag 是一个存在于你团队协作工具中的 Claude。我们上周在 Slack 中发布了它。**Claude Tag 的不同之处在于它默认是多人协作的**。一旦你将 Claude Tag 加入 Slack 频道，你可以加入讨论，你的队友也可以加入，你们可以一起协作处理 PR。另一个重大区别是它是主动的，而不是被动的。你可以告诉 Claude Tag：“嘿，监控这个频道里的所有 bug 报告，提交一个 PR 修复它，并标记上次改动这部分代码的工程师。”它会在频道的整个生命周期里自动执行，而你不需要手动标记它。第三个重大变化是**我们为它添加了团队记忆（https://claude.com/docs/claude-tag/users/memory）**。如果你在频道里告诉 Claude Tag 你的偏好，它会在未来的每条消息中记住它们。如果你总是希望它调试故障但不想让它调试警告，只需在频道里用自然语言告诉它，它就会为你和团队中的其他人记住。**在内部，我们把 Claude Tag 视为 Claude Code 的演进**。我们认为这是我们内部工作方式的一次重大转变。**目前 Claude Tag 处理了我们产品工程 PR 的 65%。** > **Simon：** 是对整个 Anthropic，还是只针对 Claude Code？ > **Cat：** 这仅针对我们的产品工程团队——**目前我们内部版本的 Claude Tag 处理了我们产品 PR 的 65%**。这是一个巨大的转变；这超过了我们 PR 的一半。我们看到人们在 Claude Code 和 Claude Tag 之间分配工作的方式是：Claude Code 仍然最适合处理你最复杂的任务，当你与代理进行交互式迭代时。**但 Claude Tag 非常适合让它主动为你工作**，因此你不再需要手动启动 Claude Code 来处理你正在开发的功能带来的所有 bug 报告。 > **Thariq：** 对于非编码场景：例如，在这次谈话之前，我们问 Claude Tag：“嘿，Fable 什么时候发布？”我们想确保它与公告时间一致。Claude Tag 会搜索我们的 Slack，查看谁在说什么。**作为你公司的搜索引擎，它非常有价值。** 它拥有你产品的所有上下文，所以你可以问它与指标相关的问题——通常当你做决策时，你希望它们基于指标，所以你可以将它连接到你的事件存储。我看到我们的营销团队做这样的事情：“嘿，给我讲讲这个功能。”他们不是程序员，但 Claude 是程序员——它可以克隆代码库并说：“这是这个功能，它看起来是这样，**这是我使用这个功能的录像**。”它开启了各种各样的可能性，而且我认为我们仍处于摸索的早期阶段。 #### Claude Tag 作为团队协作层 10:06（https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=606s） > **Simon：** 我在使用编程代理时遇到的一个问题是，我知道如何作为个人使用它们，但我不太清楚如何在团队环境中使用。**听起来 Claude Tag 是你们目前回答这个问题的一个答案——为这些东西提供团队协作层。** > **Cat：** 没错。而且目前我们很大一部分会话实际上是多人协作的。也许我会说：“嘿，我觉得我们应该在 Cowork 中实现这个新功能。”然后我标记 Claude Tag 来做初稿。接着我会告诉 Claude Tag：“分享你最终实现的录像。”然后我标记设计团队来看。他们会稍作调整，然后交给工程团队完成最后的工作并发布到生产环境。这是一种非常流畅的体验。**我们仍在摸索如何引导同一会话的社会动态**，但我们发现人们只是观察别人如何使用它，然后遵循这些社会规范——对我们来说，将 Claude Tag 融入团队非常直观。 > **Thariq：** 它对教导他人很棒，也有助于减少垃圾信息，因为**每个人都能看到你一起使用 Claude，这也会提升你自己使用 Claude 的水平**。 这让我想起了 Midjourney 如何在它们的 Discord 频道中强制公开提示，从而解决了教导人们高级图像提示的挑战。 #### 当构建变得如此便宜时，如何决定哪些功能值得构建？ 11:41（https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=701s） 我发现很难的一件事是，既然构建功能的成本已经大幅下降，如何知道一个功能是否值得发布。 > **Simon：** 你是如何应对工程中最难的问题——优先级排序？**当构建一个功能变得如此廉价时，你如何决定哪些功能值得构建和发布？** > **Cat：** 这是困难所在。我们有一些方法。一是我们每天都在内部试用我们自己的产品。每当我们在产品中想做某事却做不到时，我们不是寻找其他解决方案，而是修复我们的产品以支持这种情况。**我们内部有非常浓厚的内部试用文化。** 在我们向全世界发布产品之前，我们会先分享给 Anthropic 内部的所有人，以及一些早期客户，他们会给我们非常诚实的反馈——越残酷越好——然后我们迭代直到人们爱上它。**我们内部有一个标准，即一个功能在向世界发布之前，必须达到一定数量的活跃用户和留存率。** 因为这个标准非常明确，每个工程师都知道他们要达到什么目标。我认为这也提升了我们的打磨质量，因为如果功能不够精致，人们就会流失——那我们就不应该发布这个功能。 使用内部用户留存来决定一个功能是否应该发布，对我来说非常有道理。 #### 有没有一个让你惊讶的功能例子？ 12:54（https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=774s） > **Simon：** **有没有一个让你惊讶的功能例子？** 你们发布后，参与度出奇地高——一个看起来不太可能发布的东西，最终却成为真正的产品功能。 > **Cat：** 我有一个。**我们团队很多人喜欢远程控制（https://code.claude.com/docs/en/remote-control）。** 远程控制能让你使用移动设备或网页端的 Claude，连接到你在命令行中运行的本地 Claude Code 会话。我从来没有这个需求，因为我直接在手机上启动任务，它在云端会话中运行，不需要使用我的本地环境——我想是因为我做的都是非常简单的编码任务。这是我不太理解的东西；我当时想，嘿，人们应该设置远程开发环境才对。但实际上，自从我们推出远程控制后，很多和我聊天的人告诉我，他们每天晚上做的事情就是把笔记本电脑插上电源充电，打开一堆远程控制会话，锁定屏幕，**然后躺在沙发上用手机控制 Claude Code**。所以这成了我们现在正在深入探索的一种工作流——我最初没理解，但现在理解了。 #### Claude Code 的每行生产代码都有人类审核吗？ 14:20（https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=860s） 这次会议的一个核心主题是审查：人们花多少注意力来审查编程代理为他们编写的代码。我非常想听听 Claude Code 团队对此的看法！ > **Simon：** 代码审查是如何进行的？**进入 Claude Code 的每行生产代码是否都有人类审核？** 如果没有，你们在做什么——如何保持质量？ > **Thariq：** 这很大程度上取决于任务。**对于重要领域，我们有代码所有者。** 例如系统提示就有代码所有者——你真的需要得到他们的批准。 > **Simon：** 所以代码所有者直接负责该领域代码的质量。 > **Thariq：** 是的。 > **Cat：** 而且他们需要批准任何涉及该领域的 PR。 > **Thariq：** 我们有我们的代码审查 GitHub 机器人（https://code.claude.com/docs/en/github-actions）来审查所有内容——每个 PR 都会运行它，而且通常它负责大部分审查工作。我在团队中看到的是，**对于更复杂的 PR，你可能会制作一个人工制品来解释这个 PR**，以便其他人可以审查。而且我们在验证、CI/CD 等方面投入了很多，确保任何失败时我们都有测试。我们有一个非常健壮的环境，可以让 Claude 控制 Claude Code 并对其进行测试。所以代码审查有多种方法。 > **Cat：** 总的来说，**我们正努力将……** （此处原文未结束，但根据上下文，应该是“我们正努力将审查流程自动化/改进”等。不过由于原文只到这里，我保留原文结束。） （由于提供的原文在“Cat：总的来说，我们正努力将……”处中断，翻译也相应结束。如果原文有后续，需要补充。但根据用户提供的原文，最后一行是“we are trying to mov”，显然是截断的。因此翻译也保持截断状态。） （但根据常见表述，可能完整句子是“we are trying to move toward more automated review”等。但既然用户只提供了这些，我就按现有文本翻译。）