Claude Code 团队的 Thariq刚刚写了《Using Claude Code:Spending your effort》，把 effort 参数到底是什么、什么时候该用哪一档（低/中/高/Max）讲透了，effort的本质并非用来修正错误思路的，而是让模型花更多计算资源去死磕隐藏边界条件和自我验证。
在Claude Code中调节effort档位，不会破坏提示词缓存。很多开发者一直困惑这个参数到底在控制什么，以及面对不同任务时该如何设定。
Thariq拿Opus 5.5和Fable 5.1在标准测试集与日常开发中做了全面对比，给出了完整的数据复盘与实用指南。
effort的本质是计算量预算
把effort理解为告诉模型你愿意为这个任务投入多少计算资源。
如果要求一个人在一小时内交付一个功能，对方会快速给出一个可用版本，等待你提出修改意见。如果给对方十二个小时，对方就会尝试独立完成所有细节并做好全部检查。
Claude也是如此。
在低effort下，模型快速生成基础实现，把调整空间留给人类。
在高effort下，模型会花费大量时间做独立判断、边界测试、甚至源码反查。
在基准测试Terminal-Bench 3.0中，Fable 5.1和Opus 5.5展现出了明显的算力收益曲线：随着effort提升，消耗的Token中位数增加，基准测试的得分也同步大幅上扬。
三类日常任务的实际表现
为了看清不同effort在实际开发中的区别，Thariq用Opus 5.5测试了三种不同详细程度的任务。
第一种是极简需求，比如让模型开发一个个人健身记录应用。
在低effort下，Claude只给出一个简单的日志记录和图表。
在最高effort下，模型自行做出了大量产品决策，不仅界面更丰富，还直接加入了热力图。
第二种是轻度明确的设计任务，比如重新设计Claude Code内部的config菜单。
低effort耗时1分钟，给出了包含子菜单和更好搜索功能的交互草图，但风格不太贴近原产品。
最高effort耗时28分钟，输出了高度符合产品现有风格的高保真原型，还附带了完整的多流程演练。
第三种是高度明确的开发任务，先让Claude深入访谈人类梳理出详细规格说明书，再交由不同effort档位去实现。
在这种情况下，低档位和高档位的输出非常相似，架构和外观基本一致，最高档位只是对部分细节做了进一步精简。
这说明在日常功能开发中，如果人类想要紧密参与迭代，低effort是最高效的选择；如果希望模型一次性给出成熟方案，高effort更合适。
Thariq推荐的高效开发循环包含四步：
第一步，给Claude一份基础需求，让模型反向采访自己，挖出所有遗漏的细节。
第二步，在低effort模式下生成初版代码。
第三步，人类审查核心逻辑，继续在低effort下快速修改迭代。
第四步，在高effort模式下进行最终的全局验证和深度测试。
复杂任务下，高effort到底在干什么
在包含真实工程难题的Terminal-Bench 3.0测试集里，高effort展现了完全不同的解决问题方式。
测试集涵盖硬件、科学、机器学习、运维、媒体、软件与网络安全等领域。例如用Verilog写一个能在小型FPGA上运行并渲染测试ROM的8位游戏主机，或者在Lean 4中形式化证明塔肯斯嵌入定理。
测试数据显示，高effort最核心的价值是消灭隐藏边界问题。
在html-js-filter任务中，目标是编写一个能够过滤所有JS注入手段的HTML清洗器。Fable 5.1在低effort下的通过率是五分之一，在最高档位达到了五分之五。
低effort耗时2分钟，模型单次写完代码，仅用一个手写页面做了简单测试就结束。
高effort耗时33分钟，模型在写出初稿后进行了对抗性自审，随后读取了已安装解析器的底层源码排查潜在漏洞，运行了大量测试用例验证输入输出一致性，跑了标准的XSS测试套件，最后甚至自己写了一个随机文档模糊测试工具去轰炸代码。
但在错误分析中，Thariq发现了一个关键现象：增加effort能大幅减少因遗漏边界条件导致的测试失败，却无法挽救初始思路完全跑偏的问题。
在Fable 5.1的370次尝试统计中：
低effort模式下，通过140次，测试遗漏导致的Bug有40次，错误或未完成的修复有31次，搞错领域规则有32次，选错需求理解有25次。
最高effort模式下，通过飙升到214次，测试遗漏导致的Bug直接降到14次，错误修复降到10次，领域规则错误降到24次。但选错需求理解的失败反而从25次上升到了47次。
哪些领域最吃effort
不同工程领域从高算力投入中获得的收益差异巨大。
Fable 5.1从最低档位升到最高档位时，各领域的通过率变化如下：
硬件领域从34%暴涨到75%。
网络安全从64%提升到87%。
机器学习从54%提升到73%。
科学计算从41%提升到61%。
常规软件开发从43%提升到56%。
多媒体处理从18%提升到30%。
运维任务从12%提升到22%。
硬件和安全这类极度依赖多重检验、容错率极低的领域，提升最为惊人。
在具体用例上：
存储引擎崩溃修复任务mvcc-lsm-compaction中，Opus 5.5从低effort的0分提高到最高档位的4分。低档位下模型不跑复现直接改代码，高档位下模型先复现崩溃，针对无压缩参考版本编写随机测试，并主动确认未完成的补丁确实会触发测试报警。
线性规划求解器任务cli-2ph-simplex中，Opus 5.5通过率从0直接拉满到5。高effort下模型用暴力求解器做对照组，对随机生成的问题反复校验，并在发现大规模问题超时后彻底重构了搜索算法。
蛋白质组学富集分析任务gsea-proteomics中，Opus 5.5通过率从0提高到4。高effort下模型主动对比了两种数据预处理方法，发现显著治疗组列表发生变化后深入探究原因，最终选出了正确的数据处理路径。
Claude Code档位选择指南
基于以上规律，Thariq总结了日常使用Claude Code的档位选择建议：
低档位：适合需要人类高频参与的场景，比如头脑风暴、画原型草图、执行明确的小改动。
中档位：适合绝大多数常规软件开发，比如实现一个定义清晰的新功能。
高档位：适合极度看重验证、边界条件复杂的任务，比如在老旧复杂的代码库中排查疑难Bug。
满血档位：适合让Claude完全自主解决极端复杂的问题，比如端到端开发并全面验证复杂应用，或者在关键生产代码中深挖安全漏洞。
在Claude Code中，用户可以随时输入指令/effort，根据当前任务的性质在对话中途切换思考深度。
参考：
--end--
最后记得⭐️我，每天都在更新：如果觉得文章还不错的话可以点赞转发推荐评论
/...@作者：你说的完全正确（YAR师）