概要
Claude Code 团队的 Thariq（@trq212）前两天发了一篇长文，专门讲 effort 这个参数到底是什么、什么时候该调高，以及为什么不干脆一直开 max。
他的结论是，effort 调的其实是 Claude 会花多少力气去做验证、测边界情况，以及会替你拿多少主意。
在硬件、代码审查、安全这类边界情况特别多的任务上，高 effort 的收益非常明显。而日常开发的话，low 和 medium 其实已经够用了，还能让你一直留在回路里，随时纠偏。
同一道 HTML 过滤器的题，Fable 5.1 开 low 的时候 5 次只过了 1 次，开到 xhigh 则是 5 次全过，只不过耗时也从 2 分钟涨到了 33 分钟。
在 Terminal-Bench 3.0 上，Opus 5.5 开 high 的分数和 Fable 5.1 开 max 差不多，token 却只用了一半。
但他也提到，effort 能补上漏掉的边界情况，却救不了一开始就想错了的思路。
他自己现在的开发流程，是先让 Claude 反过来采访自己，把需求问清楚，再用 low 或 medium 去实现，看一遍方向对不对，最后切到 high 做验证和测试。
至于 max，他基本只留给两种情况，一是完全不想插手，二是要找安全漏洞……
以下是全文翻译。
问题
“Using Claude Code: Spending your effort
我们最新一代 Claude 模型有一点特别好，就是它们对 effort 的变化响应得很好，而且在 Claude Code 里切换 effort 也不会破坏 prompt cache。
不过关于这个，我收到了不少用户的提问。effort 到底是什么？什么时候该用哪一档？我们为什么需要 effort 这个东西呢？
为了回答这些问题，我决定把评测数据好好翻一遍，再在日常工作里亲自测一测不同的 effort。
（这篇文章还有更多交互式图表和讲解，可以去 claude.dev 的博客上看，链接见文末。）
总的来说，我发现 effort 很适合用来调节 Claude 做多少验证、测多少边界情况，以及它会在多大程度上自己拿主意。
在硬件、代码审查和安全这类验证和边界测试更有用的领域，加大 effort 能带来更好的结果。
而如果想快速把事情做完，同时自己也一直参与其中，那 low 和 medium 就非常合适了。
对于常规的软件工程，我现在的流程是先让模型采访我，然后用 low 或 medium 实现，检查一遍它做出来的东西，最后再用 high 跑验证。
什么是 effort
简单来说，effort 就是在告诉模型，你大概希望它在这个任务上花多少算力。这和你对任务难度的判断也有一定的关系。
可以这么理解，如果有人让你花整整 12 个小时去做一件事，你大概会觉得对方就是想让你全力以赴。
而如果同一件事只给你 1 个小时，你会尽量交出一个满足需求的最好版本，然后预期之后还要再迭代。
又或者，你可能会跟对方说这件事至少得 3 个小时，然后花上 3 个小时把它做完。
effort 也是同样的道理。
无论开哪一档，Claude 都会尽量合理地完成你的任务。只是 effort 越高，Claude 就会越多地自主行动，自己做判断、自己做验证。
effort 曲线
Fable 5.1 和 Opus 5.5 的 effort 曲线，是我们迄今为止最好的，每往上调一档，基准分数和 token 消耗都会跟着上升。
下面这张图，是我为这篇文章跑评测时测得的各档 effort 下的 Terminal-Bench 3.0 分数。
图里有个细节，Opus 5.5 开 high，和 Fable 5.1 开 max 分数相当，token 却只用了一半。（用 Opus 5.5 的 token 消耗是有点慢）
但这在实际使用中意味着什么呢？
为了弄清楚这一点，我用不同的 effort 跑了好几个任务，也把基准测试的结果仔细翻了一遍。
同一个任务跑四档
要理解模型是怎么工作的，最好的办法就是做实验。
我在 Opus 5.5 上用几档不同的 effort 做同样的任务，看它分别会干些什么。我测了各种各样的工作，这里就挑几个简单的例子来说明。
需求模糊的健身 App
如果我让 Claude「做一个个人健身和训练记录 App」，effort 会极大地影响这个 App 的完整程度，也会让 Claude 一路上替我做更多的选择。
开 low 的时候，这个健身 App 只有一个日志和一张简单的图表。effort 越高，App 就越复杂、细节越多，到了 max 甚至还多出了一张热力图。
四档的耗时依次是 low 1.5 分钟、medium 4 分钟、high 11 分钟，max 则干了 67 分钟。
如果我只想要一个简单的底子往上迭代，low 就够了。而如果我想要 Claude 一次出手的最好成果，那就用 max。
重新设计 /config 菜单
那如果任务本身已经比较明确，但我还是想和 Claude 一起做些探索呢？
我拿来举例的，是让它重新设计 Claude Code 里的 /config 菜单。每一轮给出的思路都大同小异，用子菜单，再加上更好的搜索。
开 low 只用了 1 分钟，我拿到的是一个能把想法传达出来的交互草图，只是看起来不怎么像 Claude Code。
开 max 则用了 28 分钟，我拿到的原型看起来已经非常像 Claude Code 了，还附带了一堆不同流程的演示。
如果我的目标是边迭代边给反馈，low 能快得多地到达目的地。但 max 一上来就能给我一个精致得多的东西。
就这个任务而言，我还是更喜欢用 low 来了解 Claude 的构想。
需求很详细的时候
那如果我给 Claude 大量的细节呢？
我先让 Claude 就这个健身 App 深入地采访了我一遍，再把得到的需求文档交给不同模型，用不同的 effort 去实现。
我发现有了这份需求文档之后，各个模型的表现就接近多了。设计看起来差不多，实现也类似，只在细节上有些不同。开 max 的时候，Claude 会多花些时间把一些细节简化掉。
我的开发流程
对于常规的软件工程，尤其是开发新功能，选哪一档 effort，很大程度上取决于我想在多大程度上参与其中。
low 能让 Claude 很快给出一个起点。更高的 effort 能完成更多的工作，但 Claude 也会替我做更多的假设。
我最近开发新功能时，用得特别顺的是这么一套流程：
• 给 Claude 一份需求，让它就我漏掉的细节来采访我
• 用 low 实现
• 检查一遍，确认它把大方向做对了，需要的话继续用 low 迭代
• 用 high 做验证和测试
Terminal-Bench 里的难题
当然，上面这些都只是些简单的例子，Claude 完全有能力做完。
那如果差别在于 Claude 到底能不能把任务做完呢？
要找到这类难题，就得去看基准测试了。于是我深挖了一个自己很喜欢的基准，也就是由社区贡献题目的 Terminal-Bench 3。
Terminal-Bench 3.0 的题目大致可以分为安全、硬件、机器学习、科学、软件、运维和媒体几类。题目都来自社区，任何人都可以贡献，完整的题目列表可以在 GitHub 上看到（链接见文末）。
这些题很值得读一读，能让你感受到这些模型面对的究竟是什么样的问题。很多题目的范围和野心都让我挺惊讶的，比我平时遇到的一般任务要复杂得多。
比如其中就有这么几道题：
• 硬件题 retro-console-soc，要求用 Verilog 做一台 8 位游戏机，能装进一块小 FPGA，并渲染出一个测试 ROM
• 科学题 takens-embedding-lean，要求用 Lean 4 形式化证明 Takens 嵌入定理
• 机器学习题 mp-checkpoint-consolidation，要求把一个混合专家模型的 16 个 checkpoint 分片合并成一个文件，并能复现参考 logits
• 运维题 intrastat-meldung，要求端到端地走完一家公司的月末欧盟贸易统计申报
• 媒体题 layout-config-recreation，要求把一张海报图还原成一个可编辑的排版文件
边界情况越多越该调高
读完 Terminal-Bench 3 的结果，我最大的收获是，高 effort 最适合那些藏着大量边界情况的任务。
一个很典型的例子是 html-js-filter。这道题要求写一个 HTML 过滤器，把所有能往页面里偷偷塞 JavaScript 的路子都堵上。Fable 5.1 开 low 的时候 5 次只过了 1 次，开到 xhigh 则是 5 次全过。
开 low 的一次典型尝试，大约只要 2 分钟。这些尝试基本都是一遍把过滤器写完，然后拿一个手写的页面测一下，就结束了。
开 high 跑完一次，大约要 33 分钟。
在我追踪的那一次里，它先是站在对手的角度审查了一遍自己的初稿，接着去读已安装的解析器源码找 bug，然后跑了大量干净的测试用例，直到输出和输入完全一致，又跑了一套标准的 XSS 测试集，最后还写了一个随机文档 fuzzer。
对于 HTML 过滤器这种边界情况极多的东西，多花这些力气是非常值得的。而对于那些生产要求很高的复杂任务，比如性能优化或安全审查，多花点 token 换来周全，也同样说得通。
但并不是每个任务都需要下这么大的功夫。
下面这张图列出了 Terminal-Bench 3.0 的每一个结果，以及它们在不同模型和 effort 下是怎么失败的。
总体来看，提高 effort 往往能减少因为漏掉边界情况而导致的失败（紫色方块），却治不了模型思路本身就错了的问题（蓝色方块）。
（图里是 Fable 5.1 在 low 和 max 下各跑的 370 次尝试，通过数从 140 涨到了 214，漏掉边界情况的失败从 59 次降到了 24 次，判断失误类的失败则只从 133 次降到 107 次，其中「选错了对题目的理解」甚至还从 25 次涨到了 47 次……）
哪些领域最吃 effort
用 Terminal-Bench 评测这些模型时，让我挺意外的一点是，有些问题领域从 effort 中得到的好处，要比别的领域多得多。
（安全类从 64% 涨到了 87%，硬件类从 34% 涨到了 75%，而运维这种照章办事的工作，就算开到最高也只有 22%。）
为了说明这一点，我从 Terminal-Bench 3.0 的不同领域里挑了几道题。Opus 5.5 开 low 的时候没做出来，开 high 就做出来了，主要原因都是它去测试并处理了那些边界情况。
mvcc-lsm-compaction 这道题，要求根据一份崩溃报告修复存储引擎里的一个 bug，同时还不能把 compaction 搞坏。Opus 5.5 开 low 的时候 5 次全挂，开到 xhigh 过了 4 次。
开 low 的时候每次大约 1 分钟，Claude 会在还没编译、也没跑复现程序之前就动手改代码，而且也没有检查它新写的测试，到底能不能抓到原来那个 bug。
开 xhigh 的时候大约要 11 分钟，Claude 会先把崩溃复现出来，再对照一个从不做 compaction 的参考实现写随机化测试，还专门检查了自己的测试在修到一半的代码上会不会失败。
cli-2ph-simple 这道题，要求用 Python 写一个命令行的线性规划求解器。Opus 5.5 开 low 的时候 5 次全挂，开到 high 则 5 次全过。
开 low 的几次尝试，都是一遍写完求解器，拿几个小问题检查一下，大约用了 1 万 token 就停了。Claude 在最后的回复里也提醒了，遇到大问题可能会很慢，但它并没有去验证。
开 high 的时候，Claude 会拿随机问题，把自己的求解器和另一个暴力求解器做对比，然后再给更大的问题计时，结果撞上了跑太久甚至崩溃的情况，于是把搜索部分重写了一遍。
gsea-proteomics 这道题，要求对蛋白质组学数据做基因集富集分析（GSEA），找出八种处理里哪些和目标组织相似。Opus 5.5 开 low 的时候 5 次全挂，开到 high 过了 4 次。
开 low 的时候，Claude 选了一种听起来挺合理的数据预处理方式，就按这一种方式跑完分析，报告了结果。
开 high 的时候，Claude 试了两种数据预处理方式，发现显著的处理列表变了，便先去深挖了原因，再选出正确的那一种。
如果有用户在回路里，Claude 也许会去问用户这个问题该怎么设定。但在没有用户参与的情况下，还是 high 的表现更好。
Claude Code 里怎么选
下面是我自己选 effort 的一些经验：
• low 适合想要快速响应、自己一直在回路里的时候，比如头脑风暴、画草图、简单的改动
• medium 适合我大部分日常的软件工程工作，比如实现新功能
• high 适合验证很重要，或者边界情况很多的工作，比如在老代码库里修 bug
• max 适合想让 Claude 完全自主地去解决难题的时候，比如端到端地构建并验证一个 App，或者在关键软件里找安全漏洞
大家可以根据手头的任务，给 Opus 5.5 和 Fable 5.1 换换不同的 effort，甚至在对话中途用 Claude Code 里的 /effort 命令来切换，然后告诉我这和你的直觉是不是一致。
随后，Thariq 又在 thread 里补充说，想留在回路里的时候他用 low 用得多得多，而 max 基本只在完全不想插手，或者要找安全漏洞的时候才开。
◇ ◆ ◇
