我们最新一代 Claude 模型最棒的一点，就是它们能在不破坏 Claude Code 中 prompt cache 的前提下响应 effort（投入程度）设置，但我收到了很多用户关于这方面的提问。effort 到底是什么？什么时候该用哪个级别？我们为什么需要 effort？
为了回答这些问题，我决定深入研究一下评测数据，并在日常工作中亲自测试不同 effort 级别的表现。
注：你可以在 https://claude.dev/blog/spending-your-effort/ 查看本文的更多交互式图表和讲解。
总的来说，我发现 effort 是一个很好的调节手段，可以控制 Claude 做多少验证和边界情况测试，以及它在多大程度上自主判断。
在硬件、代码审查和安全等更依赖验证与边界测试的领域，更高的 effort 能带来更好的结果。
但低和中 effort 非常适合快速完成任务，并让你始终掌控进度、与 Claude 保持同步。
对于常规软件工程，我现在的工作流是：先让模型向我提问需求，然后用低/中 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 变化的图表。
但这在实际使用中意味着什么？为了评估这一点，我用不同的 effort 级别尝试了多个任务，并仔细研究了各项基准测试。
使用 effort 进行开发
要理解模型的工作原理，最好的办法就是动手实验。我在 Opus 5.5 上用不同的 effort 级别做了相同的任务，看看它分别会怎么干活。我测试了各种各样的工作，这里用几个简单的示例来说明。
需求模糊的开发任务
如果我让 Claude “做一个个人健身与锻炼记录 App”，effort 会极大地影响这个 App 的完善程度，同时也会让 Claude 在过程中做出更多决策。在低 effort 下，这个健身 App 只是一个日志加一张简单的图表；effort 越高，App 就越复杂、细节越多；而在最高 effort 下，甚至会出现热力图。
如果我只想要一个简单的底座来迭代，低 effort 就能搞定。而最高 effort 适合我想让 Claude 一次性拿出最好版本的场景。
轻度明确的设计任务
如果任务本身已经比较清晰，但我想和 Claude 一起探索一下呢？举个例子，我让它重新设计 Claude Code 里的 /config 菜单。每一轮输出的思路都差不多：使用子菜单和更好的搜索功能。
在低 effort 下（耗时 1 分钟），我得到了一个能传达想法的交互草图，但看起来不太像 Claude Code。
在最高 effort 下（耗时 28 分钟），我拿到了一个非常贴近 Claude Code 真实样貌的 mockup，还附带了一堆不同操作流程的演示说明。
如果我的目标是不断迭代和反馈，低 effort 能快得多地达到目的。但最高 effort 一上来就能给我一个打磨得更精细的版本。就这个具体任务而言，我觉得自己更倾向于用低 effort 来理解 Claude 的设计思路。
高度明确的开发任务
如果我给 Claude 提供大量细节呢？我试着让 Claude 针对那个健身 App 对我进行深入访谈，然后把整理出来的需求规格交给不同模型、在不同 effort 级别下去实现。
我发现，有了这份详细规格后，各个模型的表现变得非常接近。我得到的设计方案看起来大同小异，实现方式也类似，只是细节有所不同；在最高 effort 下，Claude 会多花点时间去简化其中一些细节。
核心结论
对于常规软件工程，尤其是新功能开发，选哪个 effort 级别很大程度上取决于你想在多大程度上参与把控。低 effort 让 Claude 快速给出一个起点；更高的 effort 能干更多活，但 Claude 也会替你做更多假设。
我在功能开发中常用的一套高效循环是：
- 给 Claude 一份需求规格，让它针对我遗漏的细节向我提问
- 用低 effort 实现
- 检查它是否抓住了核心要点，必要时在低 effort 下迭代
- 用高 effort 进行验证和测试
Effort 级别如何影响困难任务的输出
当然，上面这些都是比较简单的例子，Claude 完全能胜任。那当差别在于“能不能完成任务”时，情况又如何呢？
要找这类难题，就得去看基准测试，于是我研究了一个我很喜欢的：Terminal Bench 3，这是一个社区众包的基准测试。
Terminal-Bench 3.0 的题目大致可以分为安全、硬件、ML、科学、软件、运维和媒体等类别。你可以在这里查看所有题目：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 嵌入定理。
- ML（mp-checkpoint-consolidation）：将 mixture-of-experts checkpoint 的 16 个分片合并成一个文件，并能复现参考 logits。
- 运维（intrastat-meldung）：端到端完成一家公司的月末欧盟贸易统计申报。
- 媒体（layout-config-recreation）：把一张海报图片重建为可编辑的排版文件。
边界情况多时，更高的 effort 更有帮助
看完 Terminal Bench 3 的结果，我最大的体会是：对于隐藏边界情况很多的任务，更高的 effort 效果最好。
一个很典型的例子是 html-js-filter，这是 Terminal-Bench 3.0 中的一个任务，要求写一个 HTML 净化器，拦截所有向页面注入 JavaScript 的方式。Fable 5.1 在低 effort 下只能拿到 1/5，而在 xhigh 下达到了 5/5。
低 effort 下的典型尝试大约耗时 2 分钟。每次尝试基本都是一遍写完过滤器，然后只用一个手写的页面对其进行测试。
而高 effort 的一次运行大约需要 33 分钟。在我追踪的那次运行中，它先以对抗视角审查了自己的初稿，接着阅读已安装解析器的源码排查 bug，然后跑了大量干净的测试用例直到输出与输入一致，又跑了一套标准 XSS 测试集，最后还写了一个随机文档 fuzzer。
对于 HTML 净化器这种充满边界情况的场景，多投入这些 effort 绝对值得。在性能优化或安全审查这类生产要求高的复杂任务中，多花 token 换取严谨性同样合理。
但你并不需要每个任务都上这么高的 effort。
下图展示了不同模型和 effort 级别下所有 Terminal-Bench 3.0 的结果及失败原因。总体来看，提高 effort 往往能减少因遗漏边界情况导致的失败（紫色方块），但无法修复模型思路本身就错了的情况（蓝色方块）。
Effort 真正帮得上忙的问题领域
在 TerminalBench 上评测这些模型时，我发现一个很有意思的点：某些问题领域从 effort 提升中获益明显更大。具体分布可以看下面这张图：
为了说明这一点，我从 Terminal Bench 3.0 的不同领域中挑了几个 Opus 5.5 在低 effort 下失败、但在高 effort 下成功的题目——主要原因就是它会去测试并处理边界情况：
mvcc-lsm-compaction： Terminal-Bench 3.0 的一个任务，要求根据崩溃报告修复存储引擎的 bug，且不能破坏 compaction。Opus 5.5 在低 effort 下是 0/5，在 xhigh 下达到了 4/5。
在低 effort 下（每次尝试约 1 分钟），Claude 还没构建代码或跑复现脚本就直接改代码，也没有验证新写的测试能否捕获原始 bug。
在 xhigh 下（约 11 分钟），Claude 先复现了崩溃，然后针对一个从不执行 compaction 的参考实现写了随机测试，并确认自己的测试在半吊子修复方案上会失败。
cli-2ph-simple： Terminal-Bench 3.0 的一个任务，要求用 Python 写一个命令行线性规划求解器。Opus 5.5 在低 effort 下是 0/5，在高 effort 下达到了 5/5。
低 effort 的尝试一遍写完求解器，用几个小问题测了一下，到 1 万 token 左右就停了。在最后一条消息里，Claude 提醒说在大规模问题上可能会很慢，但并没有实际去测。
而在高 effort 的尝试中，Claude 用一个独立的暴力求解器作为参照，在随机问题上测试了自己的求解器，接着对更大规模的问题计时，发现了运行时间过长或崩溃的情况，然后重写了搜索逻辑。
gsea-proteomics：Terminal-Bench 3.0 的一个任务，要求对蛋白质组学数据做基因集富集分析（GSEA），找出八种处理方案中哪些与目标组织相似。Opus 5.5 在低 effort 下是 0/5，在高 effort 下达到了 4/5。
在低 effort 下，Claude 挑了一种听起来合理的数据预处理方式，按这一种方法跑完分析，然后直接报告结果。
在高 effort 下，Claude 尝试了两种数据预处理方式，发现显著处理方案的列表发生了变化，于是深入探究原因，最后才选出正确的那种。
如果用户在流程中参与把关，Claude 可能会询问用户该如何设定问题；但在没有用户介入的情况下，高 effort 的表现更好。
在 Claude Code 中何时使用不同的 effort 级别
关于什么时候该用哪个 effort 级别，我的经验法则是：
- Low：当我想要快速响应并保持全程参与时，例如头脑风暴、画草图、简单修改。
- Medium：用于我大部分常规软件工程工作，例如新功能实现。
- High：用于验证很重要或存在边界情况的工作，例如在遗留代码库中修 bug。
- Max：当我想让 Claude 完全自主解决难题时，例如端到端构建并验证一个 App，或在关键软件中寻找安全漏洞。
你可以在 Claude Code 中使用 /effort，根据任务需要甚至在对话中途随时切换 Opus 5.5 和 Fable 5.1 的 effort 级别，试试看这是否符合你的直觉。
