我们最新一代 Claude 模型有一个很出色的特点：在 Claude Code 中调整 effort 时，模型会相应改变工作方式，同时保持提示词缓存有效。不过，我也收到了很多用户的疑问：effort 究竟是什么？什么时候该用哪个档位？为什么需要这个设置？
为了回答这些问题，我深入查看了评测结果，也在日常工作中亲自测试了不同的 effort 档位。
注：本文还有更多交互图表和解释，可在配套博客查看。
整体来看，我发现 effort 很适合用来调节三件事：Claude 会做多少验证、会测试多少边界条件，以及会在多大程度上自主作出判断。
在硬件、代码审查和安全等更依赖验证与边界条件测试的领域，增加 effort 往往能带来更好的结果。
而 low 和 medium 则很适合快速推进工作，并让你持续参与与 Claude 的协作。
对于常规软件工程任务，我现在采用的流程是：先让模型深入询问我的需求，再用 low 或 medium 完成实现，审阅结果，最后用 high 进行验证。
effort 是什么？
概括地说，effort 向模型传达了一个大致信号：你希望它在当前任务上投入多少计算资源。这个设置与你对任务难度的判断有一定关系。
可以这样理解：如果有人让你连续花 12 个小时完成一项工作，你可能会认为，对方希望你全力以赴，把事情尽量做好。如果同一项工作只给你 1 个小时，你就会尝试在这段时间内交付最符合要求的版本，并准备在此基础上继续迭代。
当然，你也可能提出异议，说明这项工作至少需要 3 个小时，然后花 3 个小时把它完成。
理解 effort 时，也可以沿用这个思路。Claude 始终会尝试合理地完成任务；提高 effort，会让它在自主判断和验证上采取更多行动。
effort 与评测表现的关系
Fable 5.1 和 Opus 5.5 的 effort 曲线，是我们迄今表现最好的一组：随着档位提高，基准测试得分和 token 消耗都会上升。下图展示了我为本文开展评测时，不同 effort 档位下的 Terminal-Bench 3.0 得分。
这在实际工作中意味着什么？为了弄清楚，我用不同档位尝试了多项任务，并仔细研究了基准测试结果。
用不同 effort 档位完成开发
理解模型工作方式最有效的方法，就是做实验。我让 Opus 5.5 在多个 effort 档位下完成相同任务，以观察它具体会做哪些工作。我测试了多种工作类型，这里用几个简化示例来说明。
需求不够明确的开发任务
如果我让 Claude“构建一个个人健身与训练记录应用”，effort 会显著影响应用的完善程度，也会影响 Claude 在过程中自行作出多少选择。low 档位下，应用只有训练日志和一个简单图表。更高档位下，应用会更复杂，细节也更多。到了 max，甚至会出现热力图。
如果我想要一个方便后续迭代的简单起点，low 就能满足需求。如果我希望 Claude 一次性给出它能做到的最佳结果，就会选择 max。
已有一定要求、仍需探索的设计任务
如果任务已经有了相当明确的要求，但我仍希望与 Claude 一起探索方案，会怎样？我尝试让它重新设计 Claude Code 的 /config 菜单。每次尝试的总体方向都差不多：引入子菜单，改进搜索。
在 low 档位下，任务耗时 1 分钟，我得到了一份能传达设计思路的交互草图，但它在视觉上不太像 Claude Code。
在 max 档位下，任务耗时 28 分钟，我得到了一份外观非常接近 Claude Code 的设计稿，还附带了多个操作流程的演示。
如果我的目标是尽快给出反馈、继续迭代，low 能更快达到目的。max 则能在第一轮就提供完成度更高的结果。对于这个具体任务，我更倾向于用 low 来理解 Claude 的设计思路。
需求高度明确的开发任务
如果我向 Claude 提供大量细节呢？我先让它围绕健身应用深入访谈我的需求，再把由此形成的规格说明交给不同模型，以不同 effort 档位实现。
我发现，有了这份规格说明，模型的行为就接近多了。产出的设计和实现都比较相似，差别主要体现在具体细节上；在 max 档位下，Claude 还花了一些时间简化其中的部分细节。
开发实践中的收获
对于常规软件工程，尤其是新功能开发，effort 的选择很大程度上取决于我希望参与到什么程度。low 能让 Claude 快速给出一个起点；更高档位能完成更多工作，也会让 Claude 代替我作出更多假设。
我最近在功能开发中使用的一套流程很有效：
- 给 Claude 一份规格说明，让它就遗漏的细节进一步询问我。
- 用 low 档位实现功能。
- 审阅结果，确认它正确理解了核心需求；如有必要，继续用 low 迭代。
- 用 high 档位进行验证和测试。
effort 如何影响困难任务的结果
前面的任务都是简化示例，Claude 本来就有能力完成。那么，当 effort 的差异直接决定任务能否完成时，情况会怎样？
为了寻找这类难题，需要看看基准测试。我深入研究了自己很喜欢的一项社区共建评测：Terminal-Bench 3。
Terminal-Bench 3.0 的题目大致涵盖安全、硬件、机器学习、科学、软件、运营与运维，以及媒体制作等类别。所有题目都可以在发布页面查看；它们来自社区，任何人都可以贡献。
这些题目值得一读，可以帮助你了解模型面对的问题类型。许多任务的规模和目标都让我惊讶，其复杂度远超我日常遇到的普通任务。
例如：
- 硬件（retro-console-soc）：用 Verilog 构建一台 8 位游戏机，要求能放入小型 FPGA，并运行测试 ROM、输出画面。
- 科学（takens-embedding-lean）：在 Lean 4 中形式化证明 Takens 嵌入定理。
- 机器学习（mp-checkpoint-consolidation）：把混合专家模型的一份检查点所包含的 16 个分片合并为单个文件，要求能复现参考 logits。
- 运营（intrastat-meldung）：端到端完成一家公司的月末欧盟贸易统计申报。
- 媒体（layout-config-recreation）：将一张海报图片重建为可编辑的版式文件。
隐藏边界条件越多，提高 effort 越有帮助
阅读 Terminal-Bench 3 的结果后，我最主要的收获是：较高的 effort 最适合包含大量隐藏边界条件的任务。
一个很直观的例子是 html-js-filter。这道 Terminal-Bench 3.0 题目要求实现一个 HTML 安全净化器，清除所有能够向页面夹带 JavaScript 的途径。Fable 5.1 的通过次数从 low 下的 1/5，提高到了 xhigh 下的 5/5。
low 档位的一次典型尝试耗时约 2 分钟。每次尝试基本都是一遍写好过滤器，再用一个手写页面进行测试。
一次高 effort 运行耗时约 33 分钟。在我追踪的那次运行中，模型先从攻击者的角度审查初稿，再阅读已安装解析器的源代码以排查缺陷；随后运行大量不含恶意内容的测试用例，直到输出与输入保持一致；接着运行标准 XSS 测试套件，最后还编写了一个随机文档模糊测试器。
对于 HTML 安全净化器这样充满边界情况的组件，额外投入这些计算资源很值得。性能优化、安全审查等复杂且生产要求较高的任务，同样适合用更多 token 换取更充分的检查。
当然，每项任务需要的投入程度各不相同。
下图展示了不同模型、不同 effort 档位下，Terminal-Bench 3.0 各项任务的结果及失败原因。总体而言，提高 effort 往往能减少遗漏边界条件导致的失败（紫色方块），但无法解决模型采用了错误解题思路的问题（蓝色方块）。
哪些问题领域更受益于 effort
在 Terminal-Bench 上评估这些模型时，一个很有意思的发现是：不同问题领域从额外 effort 中获得的收益并不相同。下面的图表给出了分类结果。
为了说明这一点，我选了几道来自不同领域的 Terminal-Bench 3.0 题目。Opus 5.5 在 low 下失败，在更高 effort 下成功，主要原因是它进行了更多测试，并考虑到了边界条件。
mvcc-lsm-compaction：存储引擎缺陷修复。 任务要求依据崩溃报告修复存储引擎中的一个缺陷，同时保证压实（compaction）功能正常。Opus 5.5 的通过次数从 low 下的 0/5，提高到了 xhigh 下的 4/5。
在 low 下，每次尝试约 1 分钟。Claude 尚未构建程序或运行复现用例，就直接修改代码；它也没有检查新写的测试能否捕获原始缺陷。
在 xhigh 下，一次尝试约 11 分钟。Claude 先复现崩溃，再编写随机化测试，将结果与一个从不执行压实的参考实现进行比较；它还检查了这些测试能否让修复不完整的版本暴露失败。
cli-2ph-simple：命令行线性规划求解器。 任务要求用 Python 编写一个命令行线性规划求解器。Opus 5.5 的通过次数从 low 下的 0/5，提高到了 high 下的 5/5。
low 下的尝试都是一遍写出求解器，用几个小问题做检查，然后在消耗约 10k tokens 时结束。最终回复中，Claude 提醒说，大规模问题可能运行较慢，但没有实际验证。
在 high 下，Claude 使用随机生成的问题，将自己的求解器与另一个独立的暴力求解器进行对照；随后对更大的问题计时，发现一些用例运行时间过长或直接崩溃，于是重新调整了搜索方法。
gsea-proteomics：蛋白质组学数据分析。 任务要求对蛋白质组学数据进行基因集富集分析（GSEA），判断八种处理条件中，哪些与目标组织相似。Opus 5.5 的通过次数从 low 下的 0/5，提高到了 high 下的 4/5。
在 low 下，Claude 选择了一种听起来合理的数据预处理方法，沿着这一种方法完成分析，然后报告结果。
在 high 下，Claude 尝试了两种数据预处理方法，注意到被判定为显著的处理条件列表发生变化，于是深入追查原因，最终选出了正确的方法。
如果用户持续参与过程，Claude 也许会向用户询问该如何设定这个问题；当没有用户参与时，高 effort 的表现更好。
在 Claude Code 中，何时使用哪个档位？
以下是我选择 effort 档位时的经验法则：
- Low：希望获得快速响应，并持续参与过程时使用，例如头脑风暴、草图探索和简单修改。
- Medium：用于大多数常规软件工程任务，例如新功能实现。
- High：用于验证很重要、或存在较多边界条件的任务，例如修复已有代码库中的缺陷。
- Max：希望 Claude 完全自主地解决困难问题时使用，例如端到端构建并验证一个应用，或在关键软件中寻找安全漏洞。
你可以根据任务为 Opus 5.5 和 Fable 5.1 选择不同的 effort，甚至在对话过程中通过 Claude Code 的 /effort 命令调整档位。试试看，并告诉我这些体验是否符合你的直觉。
译者补充：如何专业地理解这些结论
以下为编译补充，与上方原文译文分开。
effort 调节的是计算投入与工作深度
本文将 effort 理解为“计算投入强度”，在编程场景中也可以简称“推理强度”。它影响模型愿意投入多少探索、判断和验证工作。文中的小时数是帮助理解行为差异的类比；实际运行时间和 token 消耗还会随任务、工具与环境变化，无法把某个档位直接换算成固定时长。
原文提到，相关模型在 Claude Code 中调整 effort 时可以保持提示词缓存（prompt cache）有效。提示词缓存用于复用此前处理过的提示词内容，降低重复输入的处理开销。缓存有效与总任务成本是两个维度：追加的探索、工具调用和输出仍然会消耗资源。原文未展开缓存机制，也未给出固定节省比例。
这些测试术语分别在做什么？
| 术语 | 含义及其在案例中的作用 |
|---|---|
| Edge cases，边界情况 | 常规示例难以覆盖的输入或运行条件，例如异常 HTML、极端问题规模和特殊数据分布。 |
| HTML sanitizer，HTML 安全净化器 | 清除或改写不安全的 HTML 内容，减少脚本注入风险，同时尽量保留合法内容。文中的原样输出检查用于避免误伤安全输入。 |
| XSS，跨站脚本攻击 | 通过注入脚本使页面执行攻击者的代码。XSS 测试套件用于检查净化器能否阻止已知攻击形式。 |
| Fuzzer，模糊测试器 | 自动生成大量变化的输入，寻找手写用例难以发现的缺陷；本文案例使用随机文档进行测试。 |
| Reference implementation，参考实现 | 用作结果对照的独立实现。存储引擎案例借助不执行压实的参考实现，检查压实前后的可见结果是否一致。 |
| Compaction，压实 | 在 LSM 类存储引擎中合并、重写数据文件并清理冗余版本的过程，需要保持数据可见性等语义正确。 |
| Logits | 模型归一化为概率之前的输出分数。检查点合并任务要求合并后的模型复现参考输出，以验证合并正确性。 |
| GSEA，基因集富集分析 | 判断预先定义的基因集合是否在排序数据中呈现集中变化的统计方法；数据预处理选择会影响分析结论。 |
| Brownfield codebase，已有代码库 | 已经存在代码、依赖和历史约束的项目。修复局部缺陷时，需要同时检查对既有行为的影响。 |
如何读懂通过次数和档位名称？
文中的 1/5、4/5、5/5 表示作者该组评测中五次尝试的通过次数。它们展示了具体任务上的观察结果，不能直接当作所有项目的通用成功率。耗时同样来自文中实验，不能视为服务时延承诺。
原文在评测中使用了 xhigh，而日常使用建议列出了 low、medium、high、max。这里保留两组原始写法；原文没有给出 xhigh 与 max 的对应关系。具体可用档位应以所用模型和 Claude Code 版本的界面为准。
将预算优先投入验证环节
这篇文章最有操作价值的建议是按阶段分配 effort：需求访谈先减少歧义，low 或 medium 帮助你快速审阅实现，high 再用于复现问题、回归测试、随机化对照和边界条件检查。
当模型沿错误方向反复尝试时，应回到问题定义、复现证据和方案选择，重新校准路径。文中的实验说明，额外算力对查漏补缺尤其有价值，对错误解题思路的纠正则有明显局限。