Anthropic 团队透露 Claude Tag 承担 65% 产品工程 PR，系统提示词缩减 80%

本月早些时候，我在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。以下是整理过的文字记录，附加了更多链接和我自己加粗的重点部分。

如果你不想看视频或阅读整个文字记录，这里有一些顶层要点：

1:05：https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=65s

Simon：Claude Code是在去年二月发布的——还不到一年半的时间，它最初只是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，然后写一个详尽的规格文档，说明我们将如何实现这一点，第一行代码还没写就已经准备好了。现在情况完全相反。对于很多工程师来说，我会鼓励现场的朋友更多地发展你的商业意识和产品意识，搞清楚我们应该构建什么，因为从有想法到实际构建的时间大大缩短——从六到十二个月缩短到甚至可能只有一周。这意味着我们都需要更好地判断什么值得构建，什么能真正影响我们正在工作的业务。因此，产品品味和商业意识的重要性增加，而大多数产品领域的执行力相对降低。当然，对于基础设施（infra）来说，仍然非常强调确保所有细节正确无误。

Thariq: 对我来说，现在重写也是好事。

Simon: 现在你能做的最糟糕的事情实际上是非常棒的!

Thariq：没错。所有《人月神话》里的内容——永远不要重写——我现在支持重写。如果你有一个好的测试套件——而且我认为重写实际上会迫使你确保你有一个好的测试套件——但我认为人们低估了的是，代码库本身就是规范，也许它是你唯一拥有的规范副本，因为没有人能知道代码库每一个分支的细节。你可以把它作为一种工件来提炼，或者创建它的其他版本。我们用 Rust 重写了 Bun：https://bun.com/blog/bun-in-rust，而且效果非常好——对我来说现在它已经上线了。

Simon：你们还没在 Bun-in-Rust 上发布 Claude Code，对吧？

（实际上看起来 Anthropic 已经从 6 月 17 日开始向所有人发布在 Bun-in-Rust 上的 Claude Code：https://simonwillison.net/2026/Jul/19/claude-code-in-bun-in-rust/。）

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 处理了我们 65% 的产品工程 PR。

Simon：是针对整个 Anthropic，还是仅针对 Claude Code？

Cat：这仅针对我们的产品工程团队——我们的内部版本的 Claude Tag 目前处理了我们 65% 的产品 PR。这是一个巨大的变化；超过 50% 的 PR 都由它处理。我们看到人们在 Claude Code 和 Claude Tag 之间分配工作的方式是：当你需要与代理进行交互式迭代以处理最复杂的任务时，Claude Code 仍然是最好的选择。但 Claude Tag 非常适合主动代你工作，这样你就不需要为每个你所处理功能出现的 bug 报告手动启动 Claude Code。

Thariq：对于非编码场景呢：例如在这次访谈之前，我们问 Claude Tag，“嘿，Fable 什么时候发布？”我们想确保能与公告同步。Claude Tag 会搜索我们的 Slack 并查看谁在说什么。作为你们公司的搜索引擎，它非常有价值。它掌握了你产品的所有背景，因此你可以向它询问与指标相关的问题——通常当你做决策时，你希望决策受指标数据的指导，因此你可以将它连接到事件存储。我看到我们的营销团队会做类似的事情，比如，“嘿，告诉我这个功能。”他们不是程序员，但 Claude 是程序员——它可以克隆代码库并说，“这是这个功能，它长什么样，我使用这个功能的录屏。”它可以实现各种各样的功能，我认为我们在探索这一点上还处于早期阶段。

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，连接到在你的 CLI 本地运行的 Claude Code 会话。我自己从来没有这种需求，因为我直接在手机上启动任务，它会在云端会话中运行，不需要使用本地环境——我想可能是因为我做的都是很简单的编码任务。这是我不太理解的，我当时觉得，嘿，人们应该直接设置远程开发环境。但实际上，一旦我们推出了远程控制，我和很多人聊天时得知，他们每晚的做法是把笔记本电脑插上电源，打开多个远程控制会话，锁屏，然后坐在沙发上用手机来控制 Claude Code。所以这已成为我们现在依赖的一种流程，而我最初并不理解——但现在我理解了。

14:20：https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=860s

会议的一个总体主题是审查：人们在审查由代码代理为他们编写的代码上花了多少注意力。我非常想听听Claude Code团队对此的看法！

Simon：代码审查是如何进行的？是否每一行进入Claude Code的生产代码都有人类审查？如果不是，你们是怎么做的——如何保持质量？

Thariq：这在很大程度上取决于任务的重要性。对于关键领域，我们有代码负责人。系统提示就是一个例子，我们在这里有一个代码负责人——你真的需要获得他们的批准。

Simon：所以代码负责人对该代码区域的质量负有直接责任。

Cat：而且他们需要批准涉及该区域的所有PR。

Thariq：我们有我们的代码审查GitHub机器人：https://code.claude.com/docs/en/github-actions 审查一切——这适用于每个PR，而且通常机器人会完成大部分审查。我在团队中看到的一个情况是，对于更复杂的PR，你可能会制作一个工件来解释PR，以便其他人可以进行审查。我们在验证、CI/CD等方面投入了大量精力，以确保每当出现问题时都有测试。我们有一个非常健全的环境，Claude可以控制Claude Code并进行测试。因此，代码审查采取多管齐下的方式。

所以关键似乎是不断迭代自动审查系统本身，从而随着时间建立对它们的信任。

17:20：https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=1040s

我们深入探讨了评估——这是整个大会中另一个热门话题。

Simon：我知道Opus 4.8，如果我让它为我构建一个运行SQL查询并输出JSON的JSON端点，它就会正确完成——这是我不必仔细审查的。但随后出现了一个新模型，我不知道如何快速建立对Fable的信任，确保它不会犯Opus没有犯的错误。新模型如何影响你对其能做什么和不能做什么的直觉？

Cat：我们之所以随着时间积累这个评估库，主要原因是为了让新模型可以直接替换旧模型。当我们有新模型时，我们会运行整个评估集，并确保例如 Fable 明显优于 Opus 4.8——这让我们有信心直接使用它。

Simon：这些模型评估是针对整个 Anthropic 的，还是只针对 Claude Code 团队的？

Cat：两者都有。我们有团队内部的评估，并且我们在 Anthropic 内的每个代码库都进行代码审查，所以我们也有这方面的评估。对于像自动模式这样的功能，我们不仅对 Anthropic 内的每个用户进行了评估——我们还委托了多个外部测试者进行红队测试，创建带有提示注入和恶意输入的环境，确保自动模式不会让这些输入通过。

18:41：https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=1121s

Simon：我想知道我对系统提示做的改进是否真正提升了产品——这是最基本的、针对产品的评估形式，而我仍然不太清楚该怎么做。你们是否在进行这类工作，以便完全确信对系统提示的调整能够产生更好的输出？

Cat：我们没有完全的信心，但我们做了很多工作来确保性能不会倒退。起点是一套我们信任的外部评估，并且我们用一套更大的内部评估来补充它，这套内部评估也是我们信任的。首先，我们主要优化能力：在给出任务的完整定义和完整代码库的情况下，Claude 是否做出正确决策、完全修复错误并通过所有测试？这是起点，也是我们优化的目标，因为它最直接地满足用户的需求。但有许多行为会影响用户在使用 Claude Code 时的感受。例如，人们真的不喜欢 Claude Code 说该去睡觉了。或者人们真的不喜欢它说：“嘿，我完成了五个部分中的两个——你想让我继续吗？”是的，请继续。所以我们正在建立一套行为评估来捕捉这些问题。随着用户反馈——请大胆向我们提供你的用户反馈——我们对优先级问题进行排序，并逐一构建每个问题的评估。这并不是 100% 覆盖，但提高覆盖率对我们来说是一个优先事项。

20:21：https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=1221s

Simon：Claude Code 团队与最初训练模型的 Anthropic 团队之间有多少互动？这是一个相当紧密的合作吗？

Cat：在 Anthropic 内部，我们都密切合作。我们经常开会讨论对下一代模型的期望。我们的研究团队在公开展示方面也非常出色——我们经常在博客文章中谈论如何针对越来越长远的工作进行优化，以及我们如何训练 Claude 本身诚信、无害且有帮助。我们还投入大量精力确保它符合您的意图，即使您的意图表达得很模糊。当然，尽量具体说明您的需求，这样 Claude 就能拥有所有上下文——但即使您不具体说明，我们也教 Claude 做出良好假设。这是一个富有成效的合作关系。

21:24：https://www.youtube.com/watch?v=uU5Gv2h8-9g&t=1284s

这一部分有这么多有用的提示方法！

Simon: Thariq，你今天早上提到：https://www.youtube.com/watch?v=9fubhllmsBU&t=358s，Claude Code 的系统提示因为 Claude Fable 被减少了 80%。你能详细说明一下吗？你们可以去掉什么类型的内容？

Thariq: 不仅仅是 Fable —— 还有 Opus 4.8，以及未来的模型。我们现在针对不同的模型有不同的系统提示。我们看到的一个模式是，我们对 Claude 的限制过多了。最初的，比如 Opus 4 之类的模型需要很多示例，而去掉示例非常有帮助，因为它比我们给出的示例更有创造力。

Simon: 这真的很有意思，因为我给大家的顶级提示之一是：提供示例。如果这不再成立，那会有点打破我原来的提示模型。