Claude Code 团队成员 Thariq Shihipar 发布了一篇关于 effort 档位的文章。文章比较三组构建任务，并拆看 Terminal-Bench 3.0 的逐题结果，解释什么时候值得让模型多做验证。以下为全文翻译，文中的“我”指原作者。
我们最新一代 Claude 模型有个很好的特性：在 Claude Code 里调整 effort 时，提示词缓存不会因此失效。但不少用户问我，effort 到底是什么？什么时候该用哪一档？为什么需要它？
为了回答这些问题，我深入看了评测结果，也在日常工作中亲自测试了不同的 effort 设置。
概括来说，我发现 effort 很适合用来调节 Claude 做多少验证和边界情况测试，以及它会在多大程度上自行判断。
在硬件、代码审查和安全等更需要验证与边界测试的领域，增加 effort 带来了更好的结果。
但如果想迅速完成工作，并且自己持续参与过程，Low 和 Medium 就非常合适。
现在做普通软件工程任务时，我通常先让模型访谈我，再用 Low 或 Medium 实现；我审阅产物后，让它用 High 做验证。
什么是 effort？
简单说，effort 给模型一个近似的计算预算，让它知道你希望在任务上投入多少计算量。它也在一定程度上反映了你认为任务有多难。
可以这样想：如果有人让你连续花 12 小时做一件事，你可能会认为，对方希望你尽最大努力一次做好。同一件事如果只给你 1 小时，你会尽量交出满足要求的版本，然后预期再继续迭代。
你也可能提出异议：这件事至少需要 3 小时，然后用 3 小时完成它。
effort 也可以这样理解。Claude 无论在哪一档都会尽力合理完成任务；effort 越高，它就越会自行判断，并主动做更多验证。
effort 曲线
Fable 5.1 和 Opus 5.5 的 effort 曲线是我们迄今最好的：随着档位提高，基准测试分数和 token 消耗都会上升。下图是我为本文运行评测时，Terminal-Bench 3.0 分数随 effort 变化的情况。
图 1：Terminal-Bench 3.0 中，Opus 5.5、Fable 5.1 与上一代模型的通过率随 effort 和每次尝试的 token 用量变化；横轴为 token 中位数，对数尺度。
但这在实际工作中意味着什么？为了弄清楚，我用不同 effort 档位做了几项任务，也仔细研究了基准测试。
用不同 effort 构建应用
理解模型行为，最好的办法是做实验。我用 Opus 5.5 在不同 effort 档位完成相同任务，观察它实际会做多少工作。我试了多种任务，这里选几项简单例子来说明。
需求定义不足的构建任务
如果我只让 Claude“做一个个人健身和训练记录 App”，effort 会显著改变成品的完整程度，也会改变 Claude 自己做多少决定。Low 档做出的只是日志和一张简单图表；档位越高，应用越复杂、细节越多；到 Max 档，还出现了热力图。
图 2：仅给出一句需求时，健身记录 App 在 Low、Medium、High、Max 档位的样子；对应耗时为 1.5、4、11、67 分钟。
如果我只想先拿到一个方便继续迭代的基础版本，Low 就够了；如果想要 Claude 尽可能一次做出最好的版本，我会用 Max。
有一些设计要求的任务
如果任务已有一定要求，但我仍想和 Claude 一起探索呢？我让它重新设计 Claude Code 的 /config 菜单。每一档的基本想法都差不多：增加子菜单，改进搜索。
在 Low 档，它用 1 分钟给出一个可交互草图，足以表达想法，但看起来不太像 Claude Code。
在 Max 档，它用了 28 分钟做出更像 Claude Code 的模型，还演示了几种操作流程。
如果我想边看边给反馈，Low 能更快到达那一步；Max 则能直接给出完成度高得多的版本。对这项任务，我更愿意先用 Low 看清 Claude 的设计思路。
图 3：Claude Code 的 /config 菜单改版在 Low、Medium、High、Max 档位下的界面草图。
需求规定得很细的构建任务
如果我提供很多细节，结果又会怎样？我让 Claude 深入访谈我对健身 App 的要求，再把得到的规格交给不同模型和不同 effort 档位去实现。
有了这份规格后，我发现模型的行为相似得多。它们做出的设计和实现大体接近，只是细节不同；在 Max 档，Claude 还花时间简化了部分细节。
图 4：提供详细规格后，四档健身 App 的界面更接近；对应耗时为 16、22、33、79 分钟。
得到的启发
对于普通软件工程，特别是新功能开发，effort 的选择很大程度上取决于我想参与到什么程度。Low 能很快给出起点；更高档位会做更多工作，但 Claude 也会替我作出更多假设。
我在功能开发中发现，下面这个循环尤其有效：
-
给 Claude 一份规格，让它访谈我，找出遗漏的细节。 -
用 Low 档实现。 -
检查它是否抓住了主要意思；必要时继续在 Low 档迭代。 -
用 High 档验证和测试。
在困难任务中，effort 怎样影响结果
当然，前面只是 Claude 本来就能完成的简单例子。如果不同档位的差别，变成了它能不能完成任务呢？
要找这样的难题，就得看基准测试。我深入研究了一个自己喜欢的测试：由社区提供任务的 Terminal-Bench 3.0。
Terminal-Bench 3.0 的任务大致涵盖安全、硬件、机器学习、科学、软件、运营和媒体等领域。所有任务都能在文末链接的 GitHub 页面查看。它们来自社区，任何人都可以贡献。
值得看看这些任务，了解模型面对的问题究竟是什么。我读的时候，对许多任务的范围和难度感到惊讶；它们远比我平时遇到的任务复杂。
其中一些任务是：
-
硬件（ retro-console-soc）：用 Verilog 构建一台能放进小型 FPGA、并能渲染测试 ROM 的 8 位游戏机。 -
科学（ takens-embedding-lean）：用 Lean 4 形式化证明 Takens 嵌入定理。 -
机器学习（ mp-checkpoint-consolidation）：把混合专家模型的 16 个 checkpoint 分片合成一个文件，并复现参考模型的 logits。 -
运营（ intrastat-meldung）：端到端完成一家公司的月末欧盟贸易统计申报。 -
媒体（ layout-config-recreation）：把一张海报重新制作成可编辑的版式文件。
边界情况多时，更高的 effort 更有帮助
看完 Terminal-Bench 3.0 的结果，我最主要的认识是：对于藏着许多边界情况的任务，更高的 effort 最有价值。
html-js-filter 是个清楚的例子。Terminal-Bench 3.0 要求写一个 HTML 清理器，堵住各种将 JavaScript 偷渡进页面的方式。Fable 5.1 在 Low 档的 5 次尝试中成功 1 次，在 xhigh 档则是 5 次全成功。
Low 档一次典型尝试约需 2 分钟。每次基本都是一口气写出过滤器，再用一个手写页面做测试。
High 档的一次运行约需 33 分钟。我追踪的那次运行先从对抗角度审查初稿，接着阅读已安装解析器的源码找漏洞，又运行许多正常测试样例，直到输出与输入一致；然后它跑了标准 XSS 测试套件，最后还写了一个随机文档模糊测试器。
对于 HTML 清理器这种边界情况繁多的任务，额外 effort 很值得投入。如果任务有很高的生产要求，例如性能优化或安全审查，多花 token 换取更细致的检查也合理。
但不是每项任务都需要投入到这个程度。
下图展示了不同模型和 effort 档位在 Terminal-Bench 3.0 上每次尝试的结果及失败类型。整体看，提高 effort 往往能减少遗漏边界情况导致的失败（紫色方块）；如果模型一开始就选错了解题方向（蓝色方块），多投入 effort 也解决不了。
图 5：Fable 5.1 在 Low 与 Max 档各运行 370 次。通过数从 140 升至 214；遗漏边界情况的失败从 59 降至 24。颜色区分通过、遗漏情况、选错方向及其他失败。
哪些领域更受益于 effort
评估 Terminal-Bench 3.0 时，我觉得最有意思的一点，是不同领域从 effort 中获得的收益并不一样。下图按领域拆开了结果。
图 6：按任务领域比较低 effort 组与高 effort 组的通过率；安全任务由 64% 到 87%，硬件由 34% 到 75%，运营由 12% 到 22%。其余领域也列在原图中。
为了说明这一点，我挑了几个 Terminal-Bench 3.0 中 Opus 5.5 在 Low 档失败、却在 High 档成功的任务；主要原因是它在高档位做了测试，并照顾到了边界情况。
mvcc-lsm-compaction：Terminal-Bench 3.0 要求根据崩溃报告修复存储引擎的一个 bug，同时不能破坏压缩流程。Opus 5.5 从 Low 档 5 次全失败，变成 xhigh 档 5 次中成功 4 次。
在 Low 档，每次尝试约 1 分钟。Claude 还没构建程序或运行复现步骤就开始改代码，也没有检查新测试能否抓住原来的 bug。
在 xhigh 档，每次约 11 分钟。Claude 先复现崩溃，针对一个从不执行压缩的参考实现写随机测试，并确认测试会让只修了一半的版本失败。
cli-2ph-simple：Terminal-Bench 3.0 要求用 Python 写一个命令行线性规划求解器。Opus 5.5 在 Low 档 5 次全失败，在 High 档 5 次全成功。
Low 档的几次尝试都一口气写出求解器，只用几个小问题检查，然后在大约 1 万 token 时停下。Claude 在最终回复中提醒，大问题上可能会很慢，却没有实际验证。
High 档的几次尝试会把求解器放到随机问题上，与另一个暴力求解器对照；随后测试更大问题的耗时，发现有些情况慢得多甚至会崩溃，于是重新修改搜索过程。
gsea-proteomics：Terminal-Bench 3.0 要求对蛋白质组数据做基因集富集分析（GSEA），判断八种处理方式中哪些与目标组织相似。Opus 5.5 在 Low 档 5 次全失败，在 High 档 5 次中成功 4 次。
在 Low 档，Claude 选了一种听起来合理的数据预处理方式，只按这一种方式完成分析并报告结果。
在 High 档，Claude 试了两种预处理方式，注意到显著处理方式的名单发生了变化，于是追查原因，再选择正确的方法。
如果用户全程参与，Claude 也许会向用户询问该怎样设定问题；没有用户在旁时，High 档做得更好。
在 Claude Code 中怎样选择不同 effort 档位
以下是我选择档位时使用的经验法则：
-
Low：需要快速回应、自己也在持续参与时使用，例如头脑风暴、画草图和简单修改。 -
Medium：用于我大多数日常软件工程工作，例如实现新功能。 -
High：用于验证很重要或边界情况很多的任务，例如在已有代码库中修 bug。 -
Max：用于希望 Claude 完全自主地解决困难问题，例如端到端构建并验证一个应用，或找出关键软件中的安全漏洞。
图 7：作者建议的档位选择：头脑风暴与简单修改用 Low，日常功能开发用 Medium，修 bug 与查边界用 High，独立完成困难任务用 Max。
可以根据任务，甚至在同一段对话中，用 Claude Code 的 /effort 为 Opus 5.5 和 Fable 5.1 调整档位。也请告诉我，这是否符合你的直觉。
参考链接
-
原文：https://x.com/trq212/status/2103576349499855160 -
官方博客的交互图表版：https://claude.dev/blog/spending-your-effort/ -
Terminal-Bench 3.0 任务列表：https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0