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