使用 Claude Code：把精力花在刀刃上
什么是真正的精力，以及在 Claude Code 中何时使用哪个级别——基于我对三个版本的亲身测试，以及对 Opus 5.5 和 Fable 5.1 上 Terminal-Bench 3.0 的深入研究。
我们最新的 Claude 模型最棒的部分之一，是它们如何响应 effort 而不在 Claude Code 中破坏提示缓存，但我收到了很多用户关于这方面的疑问。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
通过率与所花费 token 的关系，按 effort 设置划分
仅限 Terminal-Bench 3.0：尝试通过的比例与每次尝试的中位 token 数的关系，对数刻度，涵盖 Opus 5.5、Fable 5.1、Opus 5 和 Fable 5，每个 effort 设置从 low 到 max 各有一个点。Opus 5.5 在每个设置上得分最高，从 low 的 36.6% 到 max 的 65.7%，而 Fable 5.1 在每个设置上都高于 Opus 5 和 Fable 5。Opus 5.5 在 high 等级的表现与 Fable 5.1 在 max 等级相当（58.9% 对 58.0%），但只用了一半的 token。Fable 5 从 xhigh 到 max 稳定在 43.4%。
但这在实践中意味着什么？为了评估这一点，我在不同的 effort 等级下尝试了几个任务，并深入研究了基准测试。
用 EFFORT 构建
理解模型工作方式的最佳方法是进行实验。我在 Opus 5.5 上尝试在几个不同的 effort 等级下完成相同的任务，以了解它所做的工作。我在各种各样的工作中进行了这项测试，但这里用几个简单的例子来说明。
需求不明确的构建任务
如果我让 Claude “构建一个个人健身和锻炼追踪应用”，effort 会极大地改变应用的完善程度，但也会导致 Claude 在过程中做出更多选择。在低 effort 下，健身应用只是一个日志和一个简单的图表。在更高的 effort 等级下，应用更复杂，有更多细节。在 max effort 下，会有一个热力图。
如果我想要一个可以迭代的简单基础，低努力程度就能搞定。最高努力程度则是当我想要 Claude 一次性给出最佳方案时。
轻度指定的设计任务
如果我有一个已经相当明确的任务，但我想和 Claude 一起探索呢？举个例子，我曾尝试让它重新设计 Claude Code 中的 /config 菜单。每一轮的思路大致相同，都是使用子菜单和更好的搜索功能。
在低努力程度下（耗时 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 测试套件，最后编写了一个随机文档的 fuzzer。
对于像 HTML 清理器这样边缘情况繁多的任务，这种额外的努力非常值得。为了彻底性花费更多 token对于性能优化或安全审查等生产要求高的复杂任务也是合理的。
但你并不需要对每个任务都投入这种程度的努力。
下图展示了不同模型和努力等级下的所有 Terminal-Bench 3.0 结果及其失败原因。总体而言，增加努力往往会减少因遗漏边缘情况（紫色方块）导致的失败，但无法修复模型方法错误（蓝色方块）的情况。
Fable 5.1 低努力：370 次尝试中，140 通过，2 只在我的机器上能用，7 过拟合到示例，10 接近但不完全正确，40 存在其测试未发现的 bug，45 误读了需求，31 修复错误或不完整，32 弄错了领域规则，25 选错了理解方式，38 其他失败。
Fable 5.1 最高努力：370 次尝试中，214 通过，1 只在我的机器上能用，3 过拟合到示例，6 接近但不完全正确，14 存在其测试未发现的 bug，26 误读了需求，10 修复错误或不完整，24 弄错了领域规则，47 选错了理解方式，25 其他失败。
努力有帮助的问题领域
在 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，同时不破坏 compaction。Opus 5.5 从低努力时的 0/5 提升到 xhigh 时的 4/5。
在低努力下（每次尝试约一分钟），Claude 会在构建或运行复现程序之前就编辑代码，并且没有检查其新测试是否能捕获原始 bug。
在 xhigh 下（约 11 分钟），Claude 首先复现了崩溃，针对一个从不进行 compaction 的参考实现编写了随机化测试，并检查其测试在半成品修复上会失败。
cli-2ph-simplex：一个 Terminal-Bench 3.0 任务，要求用 Python 编写一个 CLI 线性规划求解器。Opus 5.5 从低档的 0/5 提升到高档的 5/5。
低档尝试一次性写完求解器，用几个小问题测试后就停在约 10k token 左右。在最后一条消息中，Claude 警告说在大问题上可能会很慢，但没有去验证。
在高档尝试中，Claude 将其求解器在随机问题上与一个独立的暴力求解器进行对比测试，然后对更大的问题计时，遇到运行时间过长或崩溃的情况，并改进了搜索策略。
gsea-proteomics：一个 Terminal-Bench 3.0 任务，要求对蛋白质组学数据进行基因集富集分析（GSEA），以找出八种处理中哪些与目标组织相似。Opus 5.5 从低档的 0/5 提升到高档的 4/5。
在低档，Claude 选择了一种听起来合理的数据准备方式，只用这种方式运行分析，然后报告结果。
在高档，Claude 尝试了两种数据准备方式，注意到显著处理的列表发生了变化，并深入探究原因，然后才选择正确的那一种。
如果用户在交互回路中，Claude 可能会就问题的设置方式询问用户，但没有用户在回路中时，高档表现更好。
何时在 Claude Code 中使用不同的努力程度
以下是我关于何时使用哪种努力程度的经验法则：
- 低档：当我需要快速且在交互回路中的响应时，例如头脑风暴、勾勒草图、简单修改
- 中档：用于我大部分常规软件工程工作，例如新功能实现。
- 高档：用于验证很重要或存在边缘情况的工作，例如在遗留代码库中修复 bug。
- 最高档：当我想让 Claude 完全自主地解决难题时，例如端到端地构建和验证一个应用、在关键软件中寻找安全漏洞。
可以尝试根据任务甚至在对话中途使用 /effort 来为 Opus 5.5 和 Fable 5.1 调整努力程度，并告诉我这是否符合你的直觉。
¹ 关于这些数字的说明：它们来自我们自己的内部运行，每个任务 5 次尝试，Fable 5.1 关闭了我们的生产安全干预；在 Claude 产品中，Fable 5.1 的安全机制会将部分安全请求转交给 Opus。安全任务也是在无互联网访问的情况下运行的，因此这里的每任务计数不会与公开排行榜或发布文章一致。这些实例来自单次运行，其中一些处于中间努力设置。