Claude Code 团队访谈：工具设计、安全与实践

本月早些时候，我在 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 非常看好自动模式，并将其视为 Claude Tag 的一项关键使能技术。

对于编码智能体引发的“Deep Blue”情绪，Thariq 建议通过“承担更有野心的工作”来抵消。

Fable 已经能够胜任视频剪辑，而 Thariq 还用它剪辑了它自己的发布视频。

Anthropic 在内部公开开展工作的文化是其成功的关键，Claude Tag 在公开 Slack 频道中的使用方式就体现了这一点。

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 达成共识，然后在第一行代码写下之前，先编写一份详尽的规格说明，准确描述我们将如何实现它。现在，这套流程已经完全反过来了。对于许多工程师，我想推动在场各位去做的，是更多地培养自己的商业判断力和产品判断力，思考我们究竟应该构建什么。因为从产生一个想法到把它构建出来，所需的时间已经大幅缩短——从六到十二个月，缩短到了甚至可能只有一周。这意味着，我们所有人都需要对什么值得构建、什么真正能够改变我们所服务业务的发展轨迹，形成更好的品位和判断力。因此，在大多数产品领域，产品品位和商业判断力的重要性正在上升，而执行能力的重要性则略有下降。当然，对于基础设施来说，确保所有细节都准确无误仍然是重中之重。

Thariq：对我来说，变化在于，现在重写代码反而成了一件好事。

Simon：过去你能做的最糟糕的事情，现在居然完全没问题了！

Thariq：没错。所有《人月神话》里讲的那些东西——永远不要重写——现在我是重写的支持者。如果你有一套完善的测试套件——而且我认为，重写实际上会迫使你确保自己拥有一套完善的测试套件——那么事情就可行了。不过，我认为大家普遍低估了一点：代码库本身就是一份规格说明，而且它可能是你唯一拥有的那份规格说明，因为没有人了解代码库中每一处分支逻辑。你可以把代码库当作一件制品，从中提炼信息，或者创建它的其他版本。我们用 Rust 重写了 Bun，效果非常好——我现在正在使用的就是这个版本。

Simon：但你们还没有用 Rust 版 Bun 来发布 Claude Code，对吧？

Thariq：我们内部已经这么做了。

（事实上，看起来 Anthropic 从 6 月 17 日开始，就已经面向所有人使用 Rust 版 Bun 发布 Claude Code 了。）

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 的演进方向。我们认为，它将给内部工作方式带来巨大转变。目前，我们 65% 的产品工程 PR 都是由 Claude Tag 完成并合入的。

Simon：是整个 Anthropic 的 65%，还是只有 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 是程序员——它可以克隆代码库，然后告诉他们：“这就是这个功能，这是它的外观，这是我使用该功能时录制的视频。”它让各种各样的事情成为可能，而我认为，我们现在仍处于探索这些可能性的早期阶段。

Simon：我在使用编码智能体时遇到的一个问题是，我明白如何以个人身份使用它们，但不太清楚如何在团队环境中使用它们。听起来 Claude Tag 是你们为这种团队协作层所提供的当前方案。

Cat：完全同意。事实上，我们现在有很大一部分会话是多人协作的。比如我可能会说"嘿，我认为我们应该在 Cowork 中实现这个新功能"，然后我会邀请 Claude Tag 来做初稿。接着我会告诉 Claude Tag，"分享你最终实现的录屏"，再邀请设计团队来审看。他们会微调一下，然后交给工程团队来完成并推向生产环境。整个过程一直很流畅。我们仍在探索如何在同一个会话中协调社交动态，但我们发现人们会观察他人的使用方式并遵循这些社交规范——对我们来说，将 Claude Tag 整合到团队工作中一直很直观。

Thariq：这对教导人很有帮助，也能减少草率之作，因为大家都看到你们一起使用 Claude，这也升级了大家对 Claude 的整体使用方法。

这让我想起 Midjourney 是如何通过在 Discord 频道中强制公开提示来解决教导人们高级图像提示的问题的。

对我来说真正困难的一件事是，现在构建功能的成本已经大幅下降，如何判断某个功能是否值得发布。

Simon：你们如何处理工程中最难的问题——优先级排序？当构建功能变得便宜得多时，你如何决定哪些功能值得构建和发布？

Cat：这确实是难点。我们有几种方式来应对。一是我们每天都在使用自己的产品。每当我们想在产品中做某事但目前做不到，我们不是寻求其他解决方案，而是改进产品以支持这个需求。我们内部有非常浓厚的自用文化。在将产品与全世界分享之前，我们先在 Anthropic 内部全员分享，以及与一些早期客户分享——他们给我们很坦诚的反馈，越严厉越好——我们不断迭代，直到大家喜欢为止。我们有内部基准线，规定一个功能在与世界分享之前必须达到的活跃用户数和留存率。因为这条线很清晰，每个工程师都知道目标是什么。这也提升了我们的产品打磨度，因为如果功能不够完善，用户就会流失——那我们就不应该发布这个功能。

使用内部用户留存来决定是否发布一个功能，这对我很有意义。

Simon：有没有一个功能让你们意外惊喜的例子？你们推出它，参与度爆表——某个看似不太可能被发布的东西，最后成了真正的产品？

Cat：有的。我们团队很多人喜欢远程控制功能。远程控制让你可以用移动设备或网页浏览器中的 Claude 来连接到你本地 CLI 中运行的 Claude Code 会话。我个人没有这个需求，因为我直接在手机上启动任务，它会在云会话中运行，不需要用本地环境——我想这是因为我做的都是比较简单的编码任务。这个功能我一开始不太理解；我当时的想法是，人们应该自己搭建远程开发环境。但实际使用后，很多我聊过的人都告诉我，他们每晚的做法是把笔记本电脑接上充电器，打开一堆远程控制会话，锁屏，然后从沙发上用手机来控制 Claude Code。这成了一个我们现在正在推进的工作流，而我一开始完全没想到——但现在我理解了。

会议的一个贯穿始终的主题是审查：人们花多少精力来审查编码智能体为他们写的代码。我很想听听 Claude Code 团队对这个问题的看法！

Simon：代码审查是怎么进行的？进入 Claude Code 的生产代码，是不是每一行都要人工审查？如果不是，你们在做什么——怎么保证质量？

Thariq：这要看具体任务。对于重要区域，我们有代码所有者。系统提示就是一个例子，我们有专门的代码所有者——你需要获得他们的批准。

Simon：所以代码所有者是那个区域代码质量的直接责任人。

Thariq：没错。

Cat：他们需要批准任何涉及该区域的 PR。

Thariq：我们有一个代码审查 GitHub 机器人审查所有内容——每个 PR 都会跑，通常它完成大部分审查工作。我在团队中看到的是，对于复杂的 PR，你可能会创建一份文档来解释这个 PR，这样其他人就可以审查。我们在验证、CI/CD 等方面投入很多，确保任何失败都有对应的测试覆盖。我们有一个很健壮的环境，Claude 可以控制 Claude Code 并测试它。所以我们用了多管齐下的代码审查方式。

Cat：总体而言，我们在朝着一个人类不需要参与的方向努力。对于 Claude Code 核心以及其他产品核心的最关键改动，总会有代码所有者，他们会手动审查所有改动。但对于外围层的改动，我们越来越多地让 Claude 代码审查完全承担审查工作。听起来挺吓人的，但我们花了半年多的时间才走到这一步，其中涉及很多循序渐进的步骤来建立对代码审查的信任。最初我们对所有东西都进行人工审查，然后逐渐我们会说：好，对于涉及这些文件的代码改动，代码审查能捕获 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% 覆盖，但提高覆盖率对我们来说是一个优先事项。

Simon: Claude Code 团队与 Anthropic 内部训练模型的团队之间的互动有多密切？

Cat: 在整个 Anthropic，我们都紧密合作。我们经常开会讨论我们对下一代模型能力的期待。我们的研究团队也在公开展示这一点——我们经常在博客文章中谈论如何针对越来越长的时间跨度工作，以及我们如何训练 Claude 保持诚实、无害和有帮助。我们也付出了很多努力确保 Claude 与你的意图对齐，即使你的意图表达得不太明确。当然，尽量具体说出你想要什么，这样 Claude 能获得完整的背景——但即使你不够具体，我们也会教 Claude 做出好的假设。这一直是一个富有成效的合作。

这部分有这么多有用的提示词技巧！

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% 的令牌减少——旧模型仍然用完整的系统提示词。

Simon: 你认为 Fable 和 Opus 足够聪明吗，能用更多细节来给 Haiku 写提示词？因为它们知道 Haiku 的判断力和品味不足？

Cat: 我们还没有办法评估——没有硬数据来支持。

Thariq: 在用更小模型的时候确实有个难点，有时候大模型在复杂问题上的令牌效率比小模型还高。所以这里有一些直觉需要建立——有时候你真的就是需要前沿智能，几乎一直都是。帕累托曲线在移动，很难找到最佳点。

Simon: 一年前我不会相信模型能写提示词。现在好的模型非常擅长写提示词——我的很多提示词都是模型写的，听起来荒唐但真的很有效。让我接受这点的是想到了 AI 智能体，那完全是一个 Claude 模型给另一个 Claude 模型编写提示词。

Thariq: 工作流其实是个很好的例子，因为它不只是 Claude 给单一的子智能体写提示词，而是给多个子智能体的编排写提示词，每个子智能体都获得一个非常详细的提示词。这几乎是更高层次的——不只是生成一个子智能体。我