Fable 的两大短板 | Claude Code 负责人最新对话实录

近日，Claude Code 负责人 Boris Cherny 与 Meta Dev Infra 团队产品总监进行了一场炉边对谈，本次对话围绕 AI 编程工具的现状与演进、ROI 评估框架、Loops 自动化范式、Cowork 的非编码场景应用、模型选择策略，以及 AI 时代工程师的角色转型等话题展开。

Boris Cherny表示，现在他的100% 代码由 Claude 生成，并且大部分代码都是在手机上写的，仅从今年 3 月份算起，已经消耗了 80 亿个 Token。他指出，Anthropic 内部今年每位工程师的代码产出量增长了8倍，当代码100%由 AI 生成后，真正的瓶颈转移至好点子的生成速度，继而延伸至产品经理、市场推广等上下游环节。

关于 Loops，他表示，Loops 是 AI Agent 提示 AI Agent 持续循环运行的自动化范式，他认为，当前 Loops所处阶段与一年半前的 AI Agent 领域相当，目前他约30%的代码通过 Loops 生成，代码审查、用户反馈处理、架构优化、测试清理等维护任务已全部纳入 Loop持续执行，他仅在事后审查。

关于测试时计算，他指出，Transformer 以及大语言模型的能力扩展方式，本质上是数据量、神经网络规模以及用于训练网络的计算量的函数。除数据量、神经网络规模、训练计算量三个传统扩展因子外，测试时计算是近年引入的第四个关键因子。他表示，测试时计算用来描述模型在推理阶段生成了多少个 Token，可以通过一些机制，让模型高效地生成更多的 Token，从而实现更优的输出结果。目前有两种实现路径：一是算力投入设置，通过配置模型输出 Token 数量调节推理深度；二是动态工作流，由 Claude 编写在虚拟机中运行的编排程序，动态调度数十至数千个子 AI Agent 协同解决问题，两者在机制与适用场景上存在本质差异。

此外他表示，Fable 编写的代码与前端设计已超过他本人水平，但在产品感以及分布式系统设计方面仍有较大提升空间，预计年底前 AI 在这一领域将变得相当出色。

01

80 亿 Token以及一部手机

今年你写了多少行代码，这些代码是你自己写的还是 Claude Code 写的？现在写代码主要用手机还是笔记本电脑？

Boris Cherny：为了准备这次访谈我特意查了数据。我大概提交了 1700 个 PR，增加了 40 万行代码，删除了 25 万行代码。去年我删掉的代码比增加的还要多，今年增加的略多一些。我也试着统计了 Token 消耗量，遗憾的是由于数据保留期限等原因部分数据已被清理，但仅从今年 3 月份算起，我已经消耗了 80 亿个 Token。

自从 Opus 4.5 模型发布以来，我 100% 的代码都是由 Claude Code 编写的。

至于在哪里写代码，如果是半年前你问我，我绝对想不到现在的答案。现在我大部分代码都是在手机上写的。半年前要是有人这么跟我说，我肯定觉得他疯了，但现在事实确实如此。

公司应该如何在性能更强但成本更高的模型与必须证明 Token 效率之间取得平衡？

Boris Cherny：我每天都能和许多作为我们客户和潜在客户的公司交流。总的来说大家的关注点分为两类，有些公司看重成本，有些则看重 ROI。从 ROI 的角度思考绝对是正确的框架，因为不能只盯着成本看，所有的投入最终都是为了获得回报。在考虑 ROI 和整体部署 Claude Code 时，思考如何进行高质量部署非常有价值。

我认为最成功的公司会向所有人发放 Token，不仅仅是工程师，还包括产品经理、设计师和数据科学家。他们让所有人都有机会使用并鼓励全公司进行探索，因为好主意往往来自你意想不到的人。很多时候改进流程或开发新产品的绝佳创意可能来自于公司某个角落的会计，或是 CEO 从未听说过的营销人员。这就是很多创新想法的源泉，它不一定总是出自最资深的工程师之手。

因此需要鼓励公司和团队大胆尝试。最好的方法就是给大家发放 Token 并提供一个安全的试错环境，让他们可以放心大胆去尝试，不用担心因为试错受到惩罚。一旦发现了行之有效的内部应用场景，再去考虑如何控制成本，而这种控制应该在后端进行而不是前端。如果某个应用场景大受欢迎且消耗了大量 Token，你就可以考虑如何进行优化。其实有很多方法可以做到这一点，在 Claude Code 中我们提供了基于席位的成本控制，你还可以使用顾问模型，或者为整个公司更换模型，控制整体的工作量上限，甚至可以根据部门或基于角色的访问控制来设定预算。控制成本的方法非常多。

第二种思考方式是在部署初期如何将工具推广开来。当公司使用 Claude Code 一段时间后就必须开始认真考虑 ROI 了。ROI 包含投入和回报两部分。在过去投入很容易衡量，就是 Token 的消耗量。而对于回报，我们以前通常看 AI 编写代码的比例或是代码行数的增长百分比等。但刚才我们看到很多人举手表示他们 100% 的代码都是 AI 写的。当这个比例达到 100% 时你又该如何衡量回报呢？

这就是难题所在。以前做 Dev Infra 时如果一年的生产力能提升 2% 到 3% 就已经非常了不起了。但现在我们看到的是成百上千倍的生产力提升。在 Anthropic，从今年年初开始我们看到每位工程师的代码产出量增长了 8 倍。在这种情况下我们该如何看待回报？我认为首先要实现 100% 的代码由 Claude 编写，然后观察人均代码量的提升幅度，最后要思考的是还有哪些瓶颈阻碍了发展。因为当工程师能够快速产出大量代码时，瓶颈就会变成好点子。所以如何打破这些瓶颈让公司能更快地孕育出好想法？这可能意味着需要引入更多的产品经理或用户研究员。紧接着还需要思考如何将这些想法更快地推向市场。这需要在市场推广和营销端打破瓶颈。这就是我思考这些问题的基本顺序。当我观察客户时发现每家公司都处于这条采用曲线的不同阶段。

02

Loops是否是炒作

Loops 是下一个炒作周期，还是真实存在的趋势？能先解释一下什么是 Loops，以及你自己平时是如何使用它的？

Boris Cherny：对于在座的工程师来说，两年前我们还是手动编写源代码。后来我们开始向 AI Agent 写代码过渡，而现在我们正朝着 AI Agent 提示 AI Agent 来编写代码的阶段迈进。从更技术的角度来看，如果源代码是最基础的层面，相当于编程中的一个语句，那么编写代码的 AI Agent 就像是编程中的一个函数，而 Loops 就是高阶函数。这就是抽象层级的不断提升，它又向上迈进了一步。就像从源代码到 AI Agent 是一次巨大的飞跃一样，从 AI Agent 到 Loops 的演进也是同等重要且规模相当的一大步。

对我来说现在的 Loops 领域就像是一年半以前的 AI Agent 领域一样。虽然尚处于早期阶段，但我们已经初步看到了它的成效。举个例子，假设作为一名工程师，我的很大一部分工作是进行代码审查。我可以选择手动审查，也可以设置一个 AI Agent 通过提示让它帮我审查。而 Loops 版本的做法是，我让一个 AI Agent 在循环中持续运行，包揽所有的代码审查工作。再举个例子，我会阅读 Threads 上的用户反馈。我可以自己手动看，也可以让 AI Agent 帮我看，或者我可以设置一个不断循环的 AI Agent，每隔五到十分钟读取一次反馈并自动提交修复问题的 PR。一年半以前我们还在第一阶段。现在我们已经迈入了第三阶段。当你思考工程师的日常工作以及设计师、数据科学家、营销人员等非技术人员的工作时，我觉得很多任务都可以被拆解成这样的 Loops。我认为目前的行业趋势是，越来越多的代码和工作将被转化为 Loops 的形式。就我个人而言，在普通的工作日里我大概有 30% 的代码是通过 Loops 生成的。如果我刻意尝试，某些天甚至能达到 100%，但这还需要一个适应过程。

03

Cowork 定位是与 Claude Code 同一底层架构的产品

Anthropic 最近在 Cowork 上投入了大量精力，能否告诉大家为什么应该尝试使用 Cowork？你最兴奋的一些应用场景有哪些，特别是在非编码领域？

Boris Cherny：试用 Cowork 的方法很简单，只需要下载 Claude 桌面应用即可。也就是包含了聊天功能和 Claude Code 的同一个应用，它里面也集成了 Cowork。你只需下载就能直接使用，支持 macOS 和 Windows 系统。简单来说，Cowork 就是为非工程师准备的 Claude Code。它的底层逻辑依然是 Claude Code，并且同样使用了构建 Claude Code 的 Claude AI Agent SDK。基础架构是一样的，你甚至可以自己在这个 SDK 上进行构建。它们完全是同一套东西。

我们之所以说它是为非工程师准备的，是因为里面内置了更多的安全护栏。Cowork 拥有一个完整的虚拟机，具备相当复杂的隔离机制。我们接入了操作系统以防你误删重要文件。它还在防范提示词注入方面做了大量保护，并通过种种设计最大限度地避免用户误操作带来的损失。

说到我自己怎么用 Cowork，其实除了写代码，我把它用在了所有非技术工作上。举个项目管理的例子。以前我们每天早上都要开站会，大家挨个汇报各自的工作进展。现在我利用 Cowork 在浏览器里打开一个电子表格，里面记录了本周所有的工作流。它会自动帮我在 Slack 上给每一位工程师发消息询问最新进展。有趣的是通常是工程师们的 Claude 代替他们回复。这就变成了 Claude 之间在对话。有时工程师也会亲自回复，Cowork 读取这些信息后会自动更新到表格的进度栏里。这一切都是 Cowork 完成的，完全不需要你进行繁杂的设置。你只需要拥有 Cowork 和 Claude 的 Google Chrome 浏览器插件，它们就会自动协同工作。这就是组合工具带来的奇妙化学反应。我认为当人们使用 Cowork 时，最能让他们感到惊艳的神奇时刻就在于此，这东西居然能用我的工具，还能像我一样把所有工具组合起来协同工作！这种感觉太不可思议了，就像第一次使用 AI 聊天应用一样，绝对是一种启示。

还有一种更高级的用法。我以前会让 Cowork 帮我预订所有的行程。我会对它说这是我的行程安排，我需要哪天到这里哪天到那里，你能帮我把机票定了吗？同样它会打开浏览器进入我们在 Anthropic 用来预订行程的旅游网站，自动填写信息并预订机票。现在我把这个流程进一步自动化了。现在的 Cowork 包含一个定时任务，它每天都会查看我的邮件，并检查我在 Google 日历上接受的所有活动邀请。如果活动地点不在旧金山，它就会去自动帮我预订机票。预订好后会把信息发送给我。不仅是机票，它还知道预订酒店，甚至掌握了我对航班和酒店的所有偏好设置，然后自动完成所有操作。我前段时间参加了多个跨城市的活动，所有的多段往返机票和酒店住宿全是它自动帮我订好的，我全程根本不需要操心，完全没有干预，它直接从我的邮件里提取信息并在我确认后完成了预订。

04

Fable、模型选择

你是如何根据不同的软件工程应用场景来选择不同模型的？Fable 在编程方面的表现如何？

Boris Cherny：关于 Fable 在编程方面的表现，可以回溯到去年 11 月，当时所有人都在感叹模型在编程方面变得多么强大，那正是 Opus 4.5 发布的时刻。从上一代模型到 Opus 4.5 的能力跨度极大，很多人第一次开始完全依赖 Claude 来编写所有的代码。对我个人而言，那是我决定卸载 IDE 的时刻，因为我不再需要它了。那是 Claude 开始接管所有编码工作的转折点。

从 Opus 4.8 到 Fable 的技术跨越给我感觉至少与那次同样震撼，这可能是模型能力上一次更为巨大的飞跃。Fable 具备对细节的洞察力和多维度的思考方式，这种思维模式与我身边最聪明的同事非常相似。它不再像以前的模型那样只是一个不懂变通的生硬工具，它真正具备了深入剖析和解决问题的能力。这种能力在数据分析等诸多场景中都极具价值，数据背后隐藏着许多微妙之处，你必须连续追问多次为什么才能触及问题的本质，Fable 自然而然就能做到这一点。它在代码调试中也大显身手，调试需要你先建立假设，然后顺藤摸瓜寻找证据，Fable 能够出色地完成这些任务。至于编程，我感觉自己已经把所有的难题都抛给它了，实在想不出更难的问题。我交给它的每一个挑战，它基本上都能做到单样本解决，或者只需要提供少量提示词就能通过少样本的方式搞定。我已经没有难题可以难倒它了，我们团队里很多人也有同感，这确实是一次巨大的跨越。

不仅是 Claude Code，Cowork 也是如此，Anthropic 越来越多的产品都是这样。放眼整个 Anthropic，平均有 80% 到 90% 的代码是由 Claude Code 编写的，对于越来越多的内部团队来说这个比例已经达到了 100%。

关于模型选择，我用 Fable 处理所有事情。

是因为 Anthropic 没有预算限制吗？

Boris Cherny：在 Anthropic 我们确实会考虑 Token 的使用量。虽然我们本身就是 Token 的生产者，但它们对我们来说也不是免费的，因为我们每消耗一个 Token 就意味着无法将这个 Token 提供给客户，这其中存在机会成本。当我考虑这个问题时核心其实还是投资回报率。考虑到 Fable 带来的投资回报率，你可以通过结合顾问模型来使用 Fable，或者默认使用 Opus 并在需要时再调用 Fable，这样也许能减少 50% 的投入。我们有各种方法来优化资源的使用率，随着新模型的推出你需要持续调整这些优化策略。要跟上这种节奏实际上需要做大量的工作。你必须运行评估来确保系统运作良好，尽管你可以使用顾问模型，这也是我们推荐的开箱即用的方法。

实际上我认为从投资回报率的角度来看，虽然你可能有 50% 的机会降低投入，但你同时也面临着一千倍、一万倍甚至十万倍提升回报的机会。因此我的思路是直接使用最昂贵的模型，然后专注于思考如何从中挖掘更大的价值以最大化收益。不要把眼光局限在削减成本上，这项技术的普及还处于非常早期的阶段，现在过多纠结成本为时尚早。你可以花些精力优化成本，也必须确保预算可控且治理完善，但我建议将绝大部分精力投入到提升产出回报上。当前技术带来的上升潜力远远超过了削减成本所能省下的那点空间。

05

团队协作瓶颈、工程师角色转型

Claude Code 在优化团队协作方面采取了哪些举措？目前它给人感觉像是一款单机工作产品，只能依赖 GitHub 这类工具与他人合作。既然 AI Agent 现在已经能包揽大部分的编码工作，工程师应该把精力集中在哪里？

Boris Cherny：关于团队协作，我们目前正在紧锣密鼓地研发一系列新功能，希望很快能带来好消息。在此期间我的建议是利用模型上下文协议 MCP 将 Claude Code 接入到 Slack、Teams、Google Chat 或正在使用的任何协作平台中。

关于工程师的精力方向，我们可以审视一下工程师的日常工作，写代码只是其中一部分，还要处理大量非编码任务。比如与客户沟通、构思创意、与设计师和产品经理碰撞想法、进行数据分析、规划产品方向以及与其他部门协调对齐，工程师要做的事情不胜枚举。随着时间的推移，AI 未来能比我们更出色地完成所有这些任务，但目前还没到那个阶段。现阶段 AI 负责编写代码，人类负责向 AI 下达指令。如何下达准确的提示指令大有学问，你需要明确下一步要做什么，进行市场调研并与团队深入沟通。你必须完成所有外围工作，焦点在于这些编码之外的任务。

写代码占用的时间比例其实一直都是少数。有时亲手敲代码确实乐在其中，但有时却像是艰难跋涉让人不想手动去做。在我看来 Claude Code 就像是一个喷气背包，随着 AI 的不断进化，我的背包里好像装配了越来越多的推进器让我飞得越来越快。到了现阶段我唯一的瓶颈就是给出提示指令的速度，现在大部分指令下达都是通过语音直接跟 Claude 交流完成的。真正的瓶颈在于能否想出好点子，写代码本身已经不再是瓶颈了。

06

代码审查、安全审查

随着 AI 生成代码的大爆发，代码审查环节面临巨大压力，传统的人工审查模式可能正在崩溃。Anthropic 是如何应对这些下游影响的？对你和团队来说下一件具有颠覆意义的大事是什么，Claude Code 未来一年的发展蓝图是怎样的？

Boris Cherny：编写代码的最终目的是将其部署到生产环境中，期望推动营收或活跃度等商业指标。回顾整个流程会发现存在各种瓶颈，过去最大的瓶颈无疑是写代码。如今我们已经跨过了这道坎，许多使用 Claude Code 的客户也正迈入这个新阶段，我们需要将目光投向下一个瓶颈。

下一个阻碍就是代码审查，代码产出海量增加总得有人审阅。我们的解法是打造一款专门应对此问题的产品，于是 Claude Code Review 应运而生。它对所有人开放，与 Anthropic 内部审查每一个代码合并请求所使用的工具完全相同。它与市面上其他产品不同，因为它要昂贵得多，高昂的原因在于消耗了海量的 Token 来实现代码审查的完全自动化。当我作为工程师打开一个合并请求时，基本可以确信所有的 Bug 已被排除。虽然无法做到 100% 完美，但它确实能拦截 98% 到 99% 的错误。当我审视代码时不再充当找 Bug 的角色，因为 Claude 已经捕捉并修复了它们。我只需要关注核心问题，即这个合并请求有存在的必要吗？这是一个好的设计方案吗？

紧随其后的瓶颈则是安全审查。大量代码的合入必须以安全为前提，AI Agent 与人类一样也会在无意间引入安全漏洞。确保代码绝对安全的答案是 Claude Security，这同样是我们为突破自身内部瓶颈而研发的利器。它的工作机制是每周定期运行，全面扫描所有的代码库，自主发现并修复安全隐患。我们每次发布重大新功能前都会进行红蓝对抗测试和渗透测试来确保系统安全。我们已经达到了这样一个阶段，Claude Security 甚至能捕捉到专业渗透测试人员漏掉的隐患。这款产品我们已经使用了一段时间，正是得益于 Opus 4.8 等模型能力的提升它才开始达到如此强悍的水平。这就是我们遭遇并攻克的又一个瓶颈。我们将这一能力开放给客户，让大家受益于同款安全产品，这就是 Claude Security。

如今我们在思考下一个瓶颈会出现在哪里，可能演变成如何高效地产出创意，也可能是如何进一步优化持续集成系统以实现更好的扩展性。举个例子，我发现我们的持续集成跑得有些慢，于是启动 Claude Code 并给出指令，要求使用工作流分析数据集，查看真实持续集成的耗时情况并进行提速优化。这就是我给它的完整提示词，就这么多。它采用了一种动态工作流，这是我们几周前刚发布的新特性，核心原理是让 AI 动态协调和指挥几十甚至几千个子 AI Agent。这属于一种全新形式的测试时计算技术。它大约消耗了几百万个 Token 并在后台运行了几个小时，直接生成了四个代码合并请求，成功将持续集成时间缩短了一半。我随后将这些代码合并。放在过去要完成这些分析和优化恐怕得耗费几周甚至几个月的时间。这就是下一个需要突破的瓶颈，我们同样可以用 Claude 来解决。

关于未来规划，需要说明的是我们的规划周期是以周或月为单位，根本没有所谓的年度计划。这个领域呈指数级发展的速度非常惊人，只能努力跟上节奏，每次只规划眼前的一小步。从宏观方向看我们未来的道路与过去一两年相比并没有偏离。目标始终是打造最强大的 AI Agent。我们希望打通所有工作场景边界，无论团队在什么平台上工作 Claude 都能无缝融入。你不需要为了使用它而被迫迁移到我们的全栈生态中。此外我们致力于提供独一无二的体验，让用户能以其他产品无法实现的方式深度感受新 AI 带来的能力。

我们几年前就意识到 Sonnet 3.5 在代码生成领域迈出了一大步，但市面上没有太多产品能让用户淋漓尽致地体验这种跨越。因此 Claude Code 应运而生，抛弃传统的源代码交互方式，只需直接使唤一个 AI Agent 即可，这就是感受其强大能力的最佳途径。展望未来几个月甚至一年的发展，它在处理长时间运行的复杂任务方面将变得更加得心应手。目前 Claude 在处理长时任务领域已具备极大优势，这种领先还会继续扩大。它生成的代码将更加安全可靠、质量更高，同时在目标对齐方面也会做得更完美。无论作为使用者、工程师、产品经理还是设计师，无论意图是什么，AI 都会更精准地替你表达和实现这些想法。我们将继续深耕核心能力，不断探索并打造优秀的产品，让每个人都能轻松享受到技术跃迁带来的红利。

07

用 Loops 做代码维护，算力投入设置、动态工作流

在大型项目中，编写代码并不是最大的难题，维护才是。代码在长期内应该如何进行维护？工作流和 Loops 之间有什么区别？

Boris Cherny：我最近一直在尝试的一个方法，实际上是利用 Loops 来进行代码维护。举个例子，你可以让 Claude Code 在一个 Loop 中持续运行，让它去审视代码库并优化架构，或者让它在代码库中找出测试套件不稳定的部分并加以改进，以消除这些不稳定因素。你也可以让它寻找出无用的测试用例并直接删除，再或者让它审视代码库，寻找重复的抽象逻辑并将它们统一为单一的抽象。实际上这些都是我目前正在运行的 Loop 任务。流程上我只需直接审查 PR，在 AI 做出更改后才去检查结果。对于这类提示词，Claude 其实很容易理解这类结构性的问题。只要使用的是最新模型，效果通常会非常好。如果生成结果不够理想，只需要对它说寻找机会来提升代码库的质量，然后再补上一句指令：使用工作流。

我以为核心指令会是"绝对不能犯错"。

Boris Cherny：我之前也以为那才是核心指令。或许那句也有用，但基本上只要说"使用工作流"，模型就会分配更多的测试时计算资源，从而提供一个显著提升的结果。

关于工作流和 Loops 的区别，两者区别相当大。AI 领域存在传统的 Scaling Law，之前有一篇关于 Scaling Law 的论文提出了一个观点，即 Transformer 以及大语言模型的能力扩展方式，本质上是数据量、神经网络规模以及用于训练网络的计算量的函数。这是模型能力呈指数级增长的内在属性。正是由于这三个扩展因子的存在，AI 的智能水平才得以持续呈指数级爆发。

在过去几年中，我们引入了第四个关键因子，即测试时计算。从本质上讲，测试时计算只是一种学术说法，用来描述模型在推理阶段生成了多少个 Token。我们可以通过一些机制，让模型高效地生成更多的 Token，从而实现更优的输出结果。目前有几种方法可以做到这一点。第一种是算力投入设置。在 Claude 模型中，包含低投入、中等、高投入、超高投入以及最大投入等选项。这本质上是一种配置方式，用于设定希望模型输出的 Token 数量，以此来调节测试时计算的行为，Token 越多，结果越好。我们刚刚引入的第二种方法则是动态工作流。它主要是利用 Claude 编写一个在虚拟机中实际运行的小程序，并由它来编排其他 Claude 模型协同解决问题。这是我们目前仍在探索的一种测试时计算的新形式，本质上是让 Claude 启动数十、数百甚至上千个 AI Agent 来完成工作。

08

Fable 的两块短板

Fable 目前有哪些难以解决的难题？

Boris Cherny：我们的模型并非完美无缺，在很多方面仍需改进。其中之一就是产品感。目前我能构思出的产品创意依然优于 Fable，在创意生成方面它还没达到理想的高度。

另一个领域是分布式系统设计。尽管 Fable 现在编写的代码已经比我写的更好，前端设计也比我的设计出色，但在分布式系统设计方面我仍然远胜于 Fable。比如梳理需要哪些服务、如何组织架构、数据如何流动、如何考量负载因素等。在这一领域 Fable 还有很大的提升空间。我不太喜欢做具体的预测，但估计大概到今年年底，AI 在这方面就会变得相当出色。

09

人工审批反而降低安全性

如何防止工程师变得懒惰并全盘接受 Claude 输出的所有内容？

Boris Cherny：这个问题包含两个层面。

第一部分是如何确保模型输出的质量足够高，并且工程师都在进行正确的操作。我们的思路是如何让 Claude 替工程师做正确的事，从而让人无需亲自去操心。举个例子，从一开始我们就为 Claude Code 设定了权限提示词。任何时候只要 Claude 想要在电脑上执行命令，它都会询问是否允许。比如询问是否可以运行特定的 bash 命令，是否可以使用 MCP，或者是否可以在浏览器中抓取特定 URL。工程师必须坐在那里进行批准或拒绝。

但我们发现随着时间推移，人会变得越来越懒。就我而言，后来只是在机械地点击同意，根本没有认真阅读那些命令。我们的安全团队注意到了这个现象，他们指出，虽然在流程中引入人工干预的初衷是为了提高安全性，但实际上却在损害安全性。因为人们出现了提示词疲劳，不看细节就直接通过。这一痛点促使我们开发了自动模式，这是 Claude Code 中的一种全新权限模式。Anthropic 内部正在使用它，目前绝大多数用户也都在使用。它的工作原理是将每一个权限请求路由给一个专属模型，由该模型根据对话上下文中的交流内容，自动判断是批准还是拒绝。

这不仅大幅提升了安全性，数据表明，由于消除了提示词疲劳，自动模式的安全性不仅优于危险模式，也优于默认的人工权限模式，更重要的是它切实为工程师减负了。它成功解锁了让 AI Agent 长时间运行的能力，因为工程师再也不用盯着屏幕进行人工审批。这意味着现在可以让 Claude 连续运行几个小时甚至几天。各项基准测试也证明，Claude 在处理这类长时间运行的任务方面是业界顶尖的。自动模式的成功落地背后是多年的研究支撑。仔细研究 Claude 模型会发现，它们基本上已经不再容易受到提示词注入的攻击。如果查阅系统卡片，模型在 100 次攻击尝试中的成功率仅约为 1%，这绝对是业内最优水平。将这一优势与目前大规模部署的提示词注入分类器结合使用时，模型本质上已经对这类攻击免疫了。这正是我们能够自信推出自动模式的底气，意味着作为工程师，无需再守在电脑前审批权限。这就是对问题第一部分的解答，放手让 Claude 去做更多的事情，研究如何安全地为 Claude 解绑，而不是试图通过人工去微观控制它。

关于第二部分，当工程师不再亲自编写代码时，日常的感受是怎样的？该如何保持学习并让自己不脱节？我发现 Claude Code 中的输出风格功能对此非常有效。每当有新工程师加入团队，我们都会让他们使用探索式输出风格。只需在 Claude Code 中配置此项，或者直接让 Claude 协助设置。它的作用是，每当 Claude 做出更改时，都会主动向工程师解释当前的架构是如何运作的，如果以前没用过这种语言，它会讲解该语言的机制，还会拆解代码库各部分的原理。它通过详尽的解释来辅助学习。此外还有一种教学式输出风格，这主要是为非程序员准备的。它会在非常基础的层面讲解某种语言的运作方式，不会直接替用户修改代码，而是手把手教导如何去实现。比如它会解释在 JavaScript 中某个功能的原理，并引导用户一步步操作，从打开文件修改，到运行命令，再到执行后续操作。因此合理利用输出风格并高频度地使用 Claude，是一个极其强大的学习工具。它能帮助有经验的工程师在技术栈和基础设施发生迭代时，尤其是在接触全新编程语言时，依然能清晰地掌控全局。

| 文章来源：数字开物

【AI技术与应用交流群｜仅限受邀加入】

AI算力领域TOP级从业者专属圈层

√ 与头部算力企业深度对话

√ 与AI上下游企业深度对话

√ 获取一手全球AI与算力产业信息

√ 获取AI热点及前沿产业独家信息

√ 随时了解全球AI领域高管最新观点及实录全文

√ 有机会参与AI主题产业交流活动

扫码验证身份（需备注姓名/公司/职务

不止有 DeepSeek，更有 AI产业的未来！

• END •

【专栏】精品再读