Anthropic 员工实测 Claude Code 的 effort 档位如何影响 Fable 5.1 与 Opus 5.5 输出质量
Using Claude Code: Spending your effort
Anthropic 员工 Thariq Shihipar 深入评测了 effort 设置对 Claude Code 中 Fable 5.1 和 Opus 5.5 输出的影响。
作者结合实测和 Terminal-Bench 3.0 数据解释 effort 档位的适用场景，读者可据此调整自己用 Claude Code 的验证与迭代流程。
我们最新的 Claude 模型最棒的一点，就是它们能在不破坏 Claude Code 中提示缓存的情况下响应 effort，但我收到了很多用户关于这方面的疑问。effort 到底是什么，什么时候该用哪个 effort 级别？我们为什么需要 effort？
为了回答这个问题，我决定深入研究评估结果，并亲自对日常工作中的 effort 做了测试。
从宏观上看，我发现 effort 是一种很好的方式，用来调节 Claude 做多少验证和边缘情况测试，以及使用多少自己的判断。在验证和边缘情况测试更有用的领域，比如硬件、代码审查和安全，额外的 effort 能带来更好的结果。
对于普通的软件工程，我的循环是：让模型先采访我，然后用低 effort 实现，审查它构建的东西，再用高 effort 运行验证。
什么是 EFFORT？
从宏观上看，effort 让模型大致了解你希望它在任务上花费多少算力。这与你对任务难度的建模有一定关系。
可以这样想：如果有人让你在 12 小时内连续完成某件事，你可能会认为他们只是想让你去做，并且非常努力地去做。如果有人让你在 1 小时内完成同样的任务，你会尽力给出满足其任务的最佳版本，然后预期在此基础上迭代。
或者，你可能会反驳说这个任务至少需要 3 小时，然后工作 3 小时来交付。
你应该以同样的方式理解 effort。Claude 总是会尽量合理地完成你的任务，但更高的 effort 会让 Claude 在判断和验证方面采取更多独立行动。
EFFORT 曲线
Fable 5.1 和 Opus 5.5 的 effort 曲线是我们迄今为止最好的：在每个级别上，基准分数和消耗的 token 都有提升。
Terminal-Bench 3.0
按 effort 设置划分的通过率与 token 消耗关系
但这在实践中意味着什么？为了评估这一点，我尝试了不同 effort 级别下的几个任务，并仔细研究了基准测试。
用 EFFORT 构建
理解模型如何工作的最好方式就是做实验。我在 Opus 5.5 上以几个不同的 effort 级别尝试了相同的任务，以了解它会做哪些工作。我在各种各样的工作上做了这个测试，但这里用几个玩具示例来说明。
规格不明确的构建任务
如果我让 Claude“构建一个个人健身和锻炼追踪应用”，effort 会极大地改变应用的完善程度，但也会导致 Claude 在过程中做出更多选择。在低 effort 下，健身应用只是一个日志和一个简单的图表。在更高的 effort 级别下，应用更复杂，细节更多。在 max effort 下，还有一个热力图。
如果我想要一个简单的迭代基础，低 effort 就能搞定。Max effort 则适用于我想要 Claude 最好的一次性输出。
规格较轻的设计任务
如果我有一个已经相当明确的任务，但想和 Claude 一起做些探索呢？举个例子，我试着让它重新设计 Claude Code 中的 /config 菜单。每一次尝试都有大致相同的想法：使用子菜单和更好的搜索。
在低 effort 下（耗时 1 分钟），我得到了一个交互式草图，传达了想法，但看起来不太像 Claude Code。
在最大努力模式下（耗时 28 分钟），我得到了一个看起来非常像 Claude Code 的模型，以及一系列针对不同流程的演示。
如果我的目标是迭代并给出反馈，低努力模式会快得多。但最大努力模式从一开始就能给我更精致的东西。对于这个特定任务，我觉得我更喜欢用低努力模式来理解 Claude 的构想。
高度具体的构建任务
如果我给 Claude 很多细节会怎样？我试着让 Claude 就这个健身应用对我进行深入访谈，然后把这份规格说明交给不同模型在不同努力级别下实现。
我发现，有了这份规格说明，各模型的表现就相似得多了。我得到的设计看起来相当相似，实现也类似，但细节有所不同；在最大努力模式下，Claude 花了一些时间来简化其中几个细节。
要点总结
对于常规软件工程，尤其是新功能开发，努力级别很大程度上取决于我想在多大程度上参与其中。低努力模式让 Claude 快速给出一个起点，更高的努力级别能完成更多工作，但 Claude 也会替我做出更多假设。
我一直在使用的一个特别有成效的功能开发循环是：
- 给 Claude 一份规格说明，让它就我遗漏的任何细节对我进行访谈
- 在低努力模式下实现
- 审查以确保它抓住了要点，按需在低努力模式下迭代
- 在高努力模式下验证和测试
努力级别如何影响困难任务上的输出
但这些显然是玩具示例，Claude 完全有能力完成它们。那么当区别在于 Claude 能否完成任务时，情况又如何呢？
要找到这些困难问题，你得去看基准测试，所以我深入研究了一个我喜欢的：Terminal-Bench 3.0，一个社区来源的基准测试。
Terminal-Bench 3.0 的问题大致可以分为安全、硬件、机器学习、科学、软件、运维和媒体等类别。你可以在这里看到所有问题：https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0。它们来自社区，所以任何人都可以贡献。
值得一读，以了解这些模型面临的问题类型。我发现自己对其中许多任务的范围和雄心感到惊讶。它们比我平时面对的平均任务要复杂得多。
例如，其中一些任务包括：
- 硬件（
retro-console-soc）：用 Verilog 构建一个能装进小型 FPGA 并渲染测试 ROM 的 8 位游戏机。 - 科学（
takens-embedding-lean）：在 Lean 4 中形式化证明 Takens 嵌入定理。 - 机器学习（
mp-checkpoint-consolidation）：将混合专家检查点的 16 个分片合并为一个文件，使其能复现参考 logits。 - 运维（
intrastat-meldung）：端到端地完成一家公司的月末欧盟贸易统计申报。 - 媒体（
layout-config-recreation）：将一张海报图像重建为可编辑的布局文件。
当存在许多边缘情况时，更高的努力级别会有所帮助
我阅读 Terminal-Bench 3.0 结果的主要收获是，对于有大量隐藏边缘情况的任务，更高的努力级别效果最好。
一个清晰的例子是 html-js-filter，这是一个 Terminal-Bench 3.0 任务，要求编写一个 HTML 清理器，能剥离所有将 JavaScript 偷运进页面的方式。Fable 5.1 从低努力下的 1/5 提升到了 xhigh 下的 5/5。¹
低努力模式下的一次典型尝试大约需要 2 分钟。这些尝试中的每一次都大致一遍就写出了一个过滤器，然后针对一个手写的页面进行了测试。
一次高投入的运行大约在 33 分钟内完成。在我追踪的那次运行中，它对自己的初稿进行了对抗性审查，然后阅读了已安装解析器的源代码以检查 bug，运行了许多干净的测试用例，直到它们给出的输出与输入相同，运行了一套标准的 XSS 测试套件，最后编写了一个随机文档模糊测试器。
对于像 HTML 清理器这样充满边缘情况的工具来说，这种额外的投入非常值得。对于具有高生产要求的复杂任务（如性能优化或安全审查），为彻底性花费更多 token 也是合理的。
但你不需要为每个任务都投入这种程度的努力。
下图展示了所有 Terminal-Bench 3.0 的结果及其失败方式，涵盖不同的模型和投入水平。总体而言，增加投入往往会减少因遗漏边缘情况（紫色块）而导致的失败，但无法修复模型采用错误方法（蓝色块）的情况。
Fable 5.1 低投入：140 通过，2 在我机器上能跑，7 过拟合于示例，10 接近但不精确，40 其测试遗漏的 bug，45 误读需求，31 错误或不完整的修复，32 搞错领域规则，25 选错解读，38 其他失败，共 370 次尝试。
Fable 5.1 最高投入：214 通过，1 在我机器上能跑，3 过拟合于示例，6 接近但不精确，14 其测试遗漏的 bug，26 误读需求，10 错误或不完整的修复，24 搞错领域规则，47 选错解读，25 其他失败，共 370 次尝试。
投入有帮助的问题领域
在 Terminal-Bench 3.0 上评估这些模型时，对我来说最有意思的发现之一是，有些问题领域比其他领域更能从投入中获益。你可以在下图中看到细分：
Fable 5.1，低投入 → 最高投入的通过率：
安全 64% → 87%，硬件 34% → 75%，机器学习 54% → 73%，科学 41% → 61%，软件 43% → 56%，媒体 18% → 30%，运维 12% → 22%
.
为了说明这一点，我从 Terminal-Bench 3.0 的不同领域中挑选了几个问题，在这些问题中 Opus 5.5 在低投入时失败，但在高投入时成功——主要是因为它对边缘情况进行了测试和考虑：
mvcc-lsm-compaction：一个 Terminal-Bench 3.0 任务，要求根据崩溃报告修复存储引擎的 bug，同时不破坏压缩。Opus 5.5 从低投入时的 0/5 提升到 xhigh 时的 4/5。
在低投入时（每次尝试约一分钟），Claude 会在构建代码或运行复现程序之前就编辑代码，并且没有检查其新测试是否能捕获原始 bug。
在 xhigh 时（约 11 分钟），Claude 首先复现了崩溃，针对一个从不压缩的参考实现编写了随机测试，并检查其测试在半成品修复上会失败。
cli-2ph-simplex：一个 Terminal-Bench 3.0 任务，要求用 Python 编写一个 CLI 线性规划求解器。Opus 5.5 从低投入时的 0/5 提升到高投入时的 5/5。
低投入的尝试一次性编写了求解器，用几个小问题检查后就在约 1 万 token 时停止了。在最终消息中，Claude 警告它在大问题上可能很慢，但没有验证。
在高投入的尝试中，Claude 针对一个单独的暴力求解器在随机问题上测试其求解器，然后对更大的问题进行计时，遇到了运行时间过长或崩溃的情况，并重新设计了其搜索。
gsea-proteomics：一个 Terminal-Bench 3.0 任务，要求对蛋白质组学数据进行基因集富集分析（GSEA），以找出八种处理中哪些与目标组织相似。Opus 5.5 在低档位时从 0/5 提升到高档位时的 4/5。
在低档位下，Claude 选择了一种听起来合理的数据准备方式，按那一种方式运行了分析，并报告了结果。
在高档位下，Claude 尝试了两种数据准备方式，注意到显著处理的列表发生了变化，并在选择正确方式之前深入探究了原因。
如果用户在环路中，Claude 可能会询问用户如何设置问题，但在没有用户参与环路的情况下，高档位表现更好。
何时在 Claude Code 中使用不同的努力档位
以下是我关于何时使用哪个努力档位的经验法则：
- 低：适用于我想要快速响应且处于环路中的情况，例如头脑风暴、草图、简单更改
- 中：适用于我大多数常规软件工程工作，例如新功能实现。
- 高：适用于验证很重要或存在边缘情况的工作，例如在棕地代码库中修复 bug。
- 最高：当我希望 Claude 完全自主地解决困难问题时，例如端到端构建和验证一个应用、发现关键软件中的安全漏洞。
根据你的任务尝试为 Opus 5.5 和 Fable 5.1 调整努力档位，甚至可以在对话中途通过在 Claude Code 中使用 /effort 来调整，并告诉我这是否符合你的直觉。
¹ 关于这些数字的说明：它们来自我们自己的内部运行，每个任务尝试 5 次，Fable 5.1 关闭了我们的生产安全干预；在 Claude 产品中，Fable 5.1 的保障措施会将某些安全请求交给 Opus。这些安全任务也在没有互联网访问的情况下运行，因此这里的每任务计数不会与公开排行榜或发布文章一致。这些示例来自单次运行，有些是在中间努力档位设置下进行的。
来源：Anthropic：Claude.dev 开发者博客 · claude.dev