与Claude Code团队对话：编码代理的实际应用与内部实践

2026年7月21日

本月初，我在「AI工程师世界博览会」（AI Engineer World’s Fair）上主持了一场炉边谈话，嘉宾是Anthropic公司Claude Code团队的Cat Wu和Thariq Shihipar。我们聊了Claude Code、Claude Tag、Fable模型、代码代理的安全性、评估（evals）、工具设计，以及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高度信任其自动模式（auto mode），并将其视为Claude Tag的核心支撑技术。
• Thariq建议，应对代码代理带来的"深蓝效应"（Deep Blue），方法是"设定更高的目标"，承接更具挑战性的工作。
• Fable具备视频编辑能力，Thariq曾用它编辑Fable的发布视频。
• Anthropic内部的"公开协作"文化是其成功的关键，从他们在公开Slack频道使用Claude Tag的方式可见一斑。

过去一年，你们的日常工作有何变化？

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：你们还没把Claude Code部署到Rust版Bun上吧？

Thariq：内部已经部署了。

（实际上，Anthropic从6月17日起已向全员推出基于Rust版Bun的Claude Code。）

非工程师如何使用Claude Tag？

Simon：最近另一个重要发布是Claude Tag，对我们来说大概已经推出一周了。我了解到Anthropic内部很多非工程师都在使用它，具体是用来做什么的？

Cat：Claude Tag是集成在团队协作工具中的Claude，上周刚在Slack上线。它的不同之处在于：首先，它默认支持多人协作。添加到Slack频道后，你和同事都可以参与进来，共同协作处理PR。其次，它是主动式而非被动式的。你可以告诉Claude Tag："帮我监控这个频道里的所有bug报告，提交PR修复，并标注最后修改这段代码的工程师"，之后它会一直自动执行，无需你手动召唤。第三，我们为它添加了团队记忆功能——如果你在频道里告诉Claude Tag你的偏好，它会为所有团队成员记住这些设置。比如你只想让它调试故障，不想处理警告，只需用自然语言说明，它就会一直遵循这个规则。

在内部，我们把Claude Tag视为Claude Code的进化形态，这是我们工作方式的重大转变。目前Claude Tag已完成我们产品工程团队65%的PR。

Simon：是整个Anthropic，还是仅限Claude Code团队？

Cat：仅限我们产品工程团队——内部版Claude Tag目前处理了我们超过50%的PR，这是个巨大的转变。我们团队成员会根据任务类型选择工具：Claude Code更适合处理复杂任务，需要你和代理交互式迭代；而Claude Tag擅长主动替你工作，比如无需你手动启动Claude Code，它就能自动处理你负责功能的bug报告。

Thariq：非编码场景的用法也很多。比如这次谈话前，我们问Claude Tag："Fable什么时候发布？"想确认时间是否和发布会对齐。它会搜索Slack记录，查看相关讨论。作为公司内部的搜索引擎，它非常实用。它掌握产品的所有上下文，你可以问它指标相关的问题——做决策时通常需要数据支撑，所以我们把它接入了事件存储系统。我见过营销团队用它："帮我介绍一下这个功能。"他们不是程序员，但Claude是——它可以克隆代码库，然后说明："这就是该功能，它的效果是这样的，这是我使用该功能的录屏。"它能实现的功能非常广泛，我们还在探索更多可能性。

作为团队协作层的Claude Tag

Simon：我使用代码代理时一直有个困惑：作为个人用户我知道怎么用，但不太清楚团队环境下该如何协作。听起来Claude Tag就是你们针对团队协作层给出的解决方案？

Cat：没错。现在我们有很多多人协作的场景。比如我在Slack里说："我觉得应该给Cowork加个新功能"，然后@Claude Tag让它先做个初稿。之后我会让它"分享最终实现的录屏"，再@设计团队查看。设计师提出修改意见后，再转给工程师完成最终开发并上线。整个流程非常流畅。我们还在摸索多人协作时的社交规则，但发现大家会自然观察他人的用法并遵循，把Claude Tag融入团队协作其实很直观。

Thariq：它还很适合教学，同时能减少沟通损耗——所有人一起看着Claude的操作过程，也能互相学习提升使用技巧。

这让我想起Midjourney在Discord频道强制公开提示词，以此解决了教授用户高级图像提示技巧的难题。

开发成本降低后，如何判断功能是否值得做？

我自己一直有个难题：既然开发功能的成本大幅降低，该如何判断一个功能是否值得上线？

Simon：工程领域最难的问题就是优先级排序。现在开发功能的成本低了很多，你们怎么决定哪些功能值得开发和发布？

Cat：这确实是个难题。我们主要从几个方面入手：首先，我们每天都在内部测试自己的产品。每当遇到产品无法满足的需求，我们不会找替代方案，而是直接改进产品来支持这个场景。我们内部有非常浓厚的内部测试文化。在向全球用户发布前，我们会先在Anthropic内部全员试用，同时邀请一些早期用户提供真实反馈——越尖锐越好——然后迭代到大家满意为止。我们有明确的内部标准：功能必须达到一定的活跃用户数和留存率，才会对外发布。这个标准很清晰，每个工程师都知道努力方向。这也倒逼我们提升产品打磨的精细度，因为如果功能不够完善，用户就会流失，这样的功能就不该发布。

用内部用户留存率来决定是否发布功能，这个逻辑在我看来非常合理。

有没有超出预期的功能案例？

Simon：有没有哪个功能上线后，用户参与度远超预期——原本不太可能发布，结果却成了真正的产品功能？

Cat：有一个。我们团队很多人喜欢远程控制功能——它能让你用移动设备或网页端的Claude，控制本地CLI中运行的Claude Code会话。我自己从来不需要这个功能，因为我直接在移动端启动任务，它会在云端运行，不需要用到本地环境——可能是因为我做的都是比较简单的编码任务。一开始我完全不理解这个需求，觉得大家应该直接搭建远程开发环境。但实际推出后，很多同事告诉我，他们每天晚上会把笔记本电脑插上电源，打开几个远程控制会话，锁屏后躺在沙发上用手机控制Claude Code。现在这成了我们重点优化的使用流程，我也终于理解了它的价值。

Claude Code的生产代码需要人工逐行审核吗？

本次大会的核心主题之一是审核：人们会花多少精力审核代码代理生成的代码？我非常想听听Claude Code团队的看法！

Simon：你们的代码审核流程是怎样的？Claude Code的每一行生产代码都需要人工审核吗？如果不是，你们如何保证代码质量？

Thariq：这取决于任务类型。对于重要模块，我们设有代码负责人。比如系统提示词就有专门的代码负责人，任何修改都必须经过他们批准。

Simon：也就是说代码负责人直接对该模块的质量负责？

Thariq：没错。

Cat：任何涉及该模块的PR都需要他们审批。

Thariq：我们的GitHub代码审核机器人会审核所有PR，通常承担大部分审核工作。团队里有个做法：对于复杂的PR，会生成一份说明文档，方便其他人审核。我们还在验证、CI/CD等方面投入大量资源，确保任何错误都有对应的测试覆盖。我们搭建了一个非常完善的环境，让Claude可以自行测试Claude Code。所以我们的代码审核是多管齐下的。

Cat：总体而言，我们正朝着无需人工介入的方向发展。对于Claude Code核心模块及其他产品核心部分的关键变更，始终会有代码负责人进行人工审核。但对于外围模块的变更，我们越来越多地完全依靠Claude进行代码审核。这听起来可能有点吓人，但我们花了六个月以上的时间才走到这一步，建立对自动化审核的信任是循序渐进的过程。一开始所有内容都需要人工审核，之后逐渐发现：某些文件的代码变更，自动化审核能100%发现问题，于是这些文件就不再需要人工审核。而当发生事故时，我们会复盘导致事故的PR，思考"如何更新审核系统以避免此类问题"，并将这些PR加入评估数据集，确保未来的审核系统不会出现同类倒退。让人工退出代码审核流程是一大进步，这听起来可能让人不安，也绝非一蹴而就，但通过数月的基础设施投入，我们能获得足够的信心，相信自动化审核能覆盖所有我们关注的问题。

关键似乎在于持续迭代自动化审核系统，逐步建立对它的信任。

新模型如何改变你们对其能力边界的判断？

我们深入探讨了评估（evals）——这也是整个大会的热门话题。

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非常困惑——"我有这个能力，但系统提示词不让我这么做"。所以我们尽量减少硬性约束，提供更多上下文，同时精简指令数量。这是一门严谨的学问——我们做了大量评估才得出这个结论。

Cat：一般来说，给这些模型写提示词时，你应该始终思考：我给出的指令有没有例外情况？我们回头梳理Claude Code的系统提示词时发现，有些指令90%的情况下成立，但确实存在10%的例外。我们不想限制模型，也不想让它误以为必须永远遵循这些指令。比如验证环节，大家都希望Claude验证自己的工作，我们之前在提示词里写：如果做前端变更，必须验证。但这是有局限性的。如果只是把一段文字改成另一段，用户说"快速修改并更新测试"，可能就不需要验证。所以我们把措辞从"必须验证、必须验证"调整为：大多数情况下，前端工作无法仅通过调用后端接口完全了解体验，因此当你对用户体验进行较大修改时，请在本地运行应用程序进行验证。但其实这个表述也不够准确，因为什么算是"较大修改"？可能小修改也需要测试。总的来说，给模型写提示词时，你应该思考一个本意良好的人类会如何误解这个指令，这样就能更好地预判模型的理解方式，然后软化提示词的表述，确保它100%准确——毕竟这个提示词会被模型一直使用。

Simon：这很有意思，你们依赖模型的判断力——这只有Opus/Fable级别的模型才能做到。一年前的模型还没有足够的判断力来决定是否测试某项变更。但如果要兼容各种模型，用更便宜的模型处理低成本任务，这种方法就行不通了。

Cat：我们现在针对不同模型使用不同的系统提示词，正是出于这个原因。只有最前沿的模型才会使用精简80%后的提示词，旧模型仍保留完整的系统提示词。

Simon：你们认为Fable和Opus是否足够智能，能给Haiku模型写更详细的提示词，因为它们知道Haiku的判断力和品味更弱？

Cat：我们还没做相关评估，没有确凿的数据能证明这一点。

Thariq：小模型有时会有个问题：面对复杂任务，大模型反而比小模型更节省token。这里需要一些经验判断——有时候你几乎总是需要最前沿的智能。帕累托曲线在不断变化，很难找到最优解。

Simon：一年前我根本不相信模型能写提示词。现在优秀的模型非常擅长写提示词——我的很多提示词都是模型生成的，听起来很荒谬，但效果很好。让我接受这一点的是"子代理"的概念，就是让一个Claude模型给另一个Claude模型写提示词。

Thariq：**工作流（Workflows）**就是很好的例子，因为它不仅让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：我职业生涯的巅峰就是引入了"询问用户问题"工具。这真的很难，尤其是有些工具——比如"询问用户问题"是让Claude主动问你问题——很难评估，有时更多是用户偏好问题。当时我们的评估手段较少，主要依靠内部测试（也就是我们说的"蚂蚁测试"）。但总体而言，我们正朝着减少工具数量的方向发展。最近一次引入的是任务工具，我们尽量给Claude提供更通用的工具来完成各类任务。

文件编辑工具的最新进展如何？

我一直对文件编辑工具很感兴趣——它曾是旧版Aider代码编辑排行榜的核心指标，我也一直关注着它在不同代码代理中的演变：从基于搜索替换，到基于行号，再到更复杂的模式。

Claude API文档介绍了一款文本编辑工具，推荐开发者基于它进行开发，但Claude Code似乎采用了略有不同的方式。

Simon：最有意思的工具之一是文件编辑工具——你可以用专门的文件编辑工具，也可以让它使用sed、grep等命令来操作。你们的文件编辑工具最新进展如何？

Thariq：我们仍保留着这个工具，但比如移除了grep等搜索工具和通配符工具，改用原生bash命令。就像我之前演讲中说的，模型更像生物学而非物理学，工具设计尤其困难。我不确定Cat是否同意，但我觉得工具设计更像一门艺术，或者说生物学。

Cat：我大体同意，但总的来说，我们引入新工具时会尽量控制数量，确保每个新增工具都有独特的功能，与其他工具明确区分，让Claude能轻松判断何时调用哪个工具。我们保留文件编辑工具，其实是为了渲染需求。当Claude修改文件时，我们会给用户展示一个专门的UI，上面写着：你是否批准对这个文件的修改？我们需要专门的文件编辑工具，才能确定Claude正在修改文件，从而展示这个友好的UI。很多新用户仍然很喜欢这个体验，所以我们保留了它。但对于我们这些使用自动模式的人——希望你不是用"YOLO模式"——其实有没有这个工具都无所谓，我们完全可以移除它。

Anthropic内部关于安全运行Claude Code的建议是什么？

终于到了提示词注入的问题！谁能比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非常重视安全，我们与对齐团队和安全团队密切合作，先在内部推出自动模式，构建评估体系，让它变得更完善后才对外发布。

Thariq：这也是Claude Tag如此好用的原因——Claude Tag基于自动模式运行。我常听到关于是否要自研AI Slack机器人的讨论，我的建议是：最好不要。这里面有太多攻击向量。比如你有一个用户反馈频道，机器人会读取里面的内容，就可能被利用。我们在自动模式上投入的大量工作——包括采用"瑞士奶酪模型"的多层安全防御，以及强化学习训练——才是Claude Tag成功的关键。它能无缝适配你的权限设置，没人想在Slack里遭遇提示词注入攻击。

除了自动模式，还有哪些安全相关的计划？

Simon：除了自动模式，还有哪些正在推进的安全相关功能？

Thariq：我们的安全性已经很高了。使用Claude Tag时，你可以为Claude单独配置凭证，这样它就不需要以你的身份操作——你可以让Claude拥有独立身份，这也便于审计和监控Claude的操作。

Simon：因为Claude Tag会受到所有能和它对话的人的影响，操控它的人范围更广。

Thariq：没错。当然，Fable也具备安全探测功能，这是我们安全和研究工作的成果。现在你能看到，Anthropic作为一家AI安全公司的投入开始见效：我们希望Claude能长期保持对齐运行，而自动模式必须近乎完美才能实现这一点——这一切都源于我们是一家AI安全公司。

Cat：我们还为使用远程控制功能的用户推出了"可信设备"功能。对于所有远程环境，我们支持凭证注入。如果你想让Claude Code访问Datadog，但又不想让它持有Datadog凭证，可以通过我们的身份和凭证管理系统设置，让Datadog凭证仅能被代理使用，但代理无法获取凭证——当代理尝试发起Datadog请求时，系统会自动注入凭证。

我非常喜欢这种凭证注入模式：Claude Code可以通过代理访问API，代理会审核请求并注入相应的API密钥——这样Claude就能访问需要认证的端点，同时不会接触到API凭证本身。

过去一年半如何改变了你们对自身职业的认知？

Thariq在今天上午的主题演讲中提到，Fable级别的模型让他产生了一种失落感，我们就此展开了深入讨论。我把这种现象称为"深蓝效应"（Deep Blue）。

Simon：我们来聊聊人的因素。很多人觉得，原本属于自己的软件开发工作被模型取代，产生了失落感。你们怎么看待这个问题？过去一年半，你们对自身职业的价值认知有什么变化？

Thariq：Cat和Boris一直提醒我，必须设定更高的目标。他们常说：我们发展得太快了，必须走在前沿，拿出最好的成果。这一直激励着我——每当我做事拖沓时，就会想：能不能更快一点？能不能更有野心一点？答案往往是借助Claude，因为它一直在进步——上次我做这件事时用的还是旧模型。关于失落感：我认为这是真实存在的。如果你只想做LLM出现前的那些工作，而现在只需要写个提示词就能完成，确实会有种伤感。而应对这种情绪的方法就是设定更高的目标。Jared就是个很好的例子——他在奥克兰的公寓里花了一年时间手写所有Zig代码，几乎不出门，但乐在其中。现在我看到他用Rust重写整个Bun，他依然乐在其中——因为这个目标更宏大，这就是他应对失落感的方式。总的来说，就是问自己如何做更有影响力的事、取得更大的成就——成功本身就是一种乐趣。关键是调整你的野心。

"应对这种情绪的方法就是设定更高的目标"，这句话精准概括了我对这个问题的看法。

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

Cat：我感觉产品经理的角色每个月都在变化。我们团队的所有PM都是工程师、设计师、PM的结合体——他们大多原本是全职工程师。对我们来说，这意味着哪里有缺口就补哪里。如果我们有一个想法，但没有工程师愿意去实现，那我们就自己动手做出来，写成文档，再推动其他人把它落地。如果设计稿不够理想，我们就找一个类似的页面，做个初稿，再@注重细节的同事来完善。如果发现公司内部对Claude Code、Claude Tag和Cowork的关注度越来越高，更多人想了解后续规划，那我们就自动生成完整的发布日历，自动同步状态更新，不用再去打扰别人，同时确保内部公告频道的更新内容详尽、切中要点。对我们来说，核心是理解从一个好想法到交付给用户，目前存在哪些缺口，以及如何尽可能地自动化填补这些缺口。

这反映了我观察到的一个现象：当代码生成速度大幅提升后，等待他人决策的时间就成了更明显的瓶颈。能自己做产品决策的工程师，推进速度会快很多，而且决策失误的成本也低了很多。

Claude有没有让你们感到意外的时刻？

Simon：有没有哪个时刻，Claude的表现超出了你们的预期？

Thariq：我多次提到Claude的视频编辑能力，最近一次是在ACM Agentic会议上做演讲后，我问同事："剪辑好的视频出来了吗？我想发给公关团队。"他们说："还得等很久。"于是我要了原始素材——我在台上演讲的视频、演示文稿的视频，还有音频文件，他们说："祝你好运。"我把这些素材和我的HTML演示文稿一起交给Claude，说："帮我把这些剪辑到一起。"结果它做得非常出色，完全可以直接发布。它先转录了整个视频，发现演示文稿的视频里有个自动更新弹窗，不太合适，于是决定："我不用演示文稿的视频了，我会把视频片段拆分，对应到你讲的每一页，然后用HTML源文件来展示。"它还会动态裁剪我在台上的画面——我一直在走动，它能跟踪我的位置。同时它还完成了字幕转录。

Simon：这是用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的哪些企业文化值得其他公司借鉴？

我觉得这是个很好的收尾问题：

Simon：Anthropic的哪些企业文化，帮助你们高效使用这些工具，是其他公司应该借鉴的？有哪些文化技巧值得大家采用？

Cat：我来说说Claude Tag相关的一点。Claude Tag在公开频道中使用效果最佳，而且公司的大部分频道都应该是公开的。只有能访问所有公开频道的内容，Claude Tag才能获取足够的上下文，给出最准确的答案。

Thariq：我在主题演讲中提到过，但它对我来说太重要了，我想再强调一遍。我们的联合创始人说过，不要自我设限，这一点非常关键。你可能会在脑海中设想各种权衡，然后说服自己放弃做有野心的事——但你完全可以直接尝试。我们经常问自己：如果我们直接做会怎样？这真的是必须权衡的问题吗？如果是，为什么——有没有证据证明这是真实的权衡，而不是听起来合理的假设？让权衡自己显现出来，尽可能地追求野心。

你们用Claude做过的最有意思的"无用"项目是什么？

我忍不住问了这个问题：

Simon：你们用Claude做过的最有意思的"无用"项目是什么？就是那种纯粹因为能做而做的项目。

Thariq：我正在做一个以我和朋友为角色的2D街头霸王格斗游戏。它用Claude Code调用Gemini API——说实话Seedance模型做得很不错——生成视频动画。效果非常好，它很擅长写提示词，还能验证每一帧的动画质量。它甚至能计算碰撞箱："你的拳头在这里，我来画JSON格式的碰撞箱。"太不可思议了。

Simon：是生成类似街霸2的2D sprite图吗？

Thariq：没错，就是2D sprite图。动画效果很棒。

Cat：我的项目简单多了。我很喜欢攀岩，很多朋友也攀岩，所以我们用Claude Code做了一个小应用，记录我们正在挑战的路线。我们还经常一起户外攀岩，所以用工作流（Workflows）让Claude做各种调研。工作流太好用了——我们把它定位为编码工具，但它做旅行深度调研也非常出色。我还负责团队团建策划，它能帮我找到容纳所有人的场地。我用工作流调研我们想去的攀岩目的地，以及从大家所在地出发的直飞航班。它会访问Mountain Project网站，找到适合我们水平的路线，还能找Airbnb。我不喜欢徒步，所以特别在意从停车场到岩壁的距离要非常近——它会帮我筛选出符合这个条件的地点。用现有应用我得手动在Mountain Project上一个个点，但用这个自定义应用，我只需输入所有偏好，就能得到想要的结果。

Simon：所以你相当于给攀岩做了个"氛围版Jira"？

Cat：没错。

观众提问：是否计划推出评估构建工具和代理可观测性工具？

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

观众：你们近期有没有计划推出更多工具，帮助我们构建评估数据集，以及监控代理和工作流性能的可观测性工具？

Cat：我们考虑过做评估工具，但发现限制因素通常是客户需要很长时间才能构建出高质量的评估数据集。所以工具本身不是瓶颈，关键是掌握构建优秀评估的技能。我们很乐意在这方面投入资源，也希望能对外分享一些最佳实践。

观众提问：当前的记忆功能如何设计？是否会从文件转向数据存储？

观众（Sai）：我对记忆功能和多人协作很感兴趣。**当前的记忆功能是如何设计的？**我猜是基于文件的。第二个问题，你们有没有考虑过另一个方向：用数据存储而非文件来保存这些记忆，以实现更好的扩展性？

Thariq：目前Claude Tag的记忆是按频道划分的。每个频道中的Claude共享一份记忆，会话产生的内容会补充到主记忆中。我们做了很多记忆相关的研究，发现记忆的设计方式往往违反直觉。我们一直在进行记忆相关的实验。目前Claude Tag的实现方式是每个频道对应一个markdown文件。