别再无脑开高推理！Opus 5高配可能擅自重构代码乱加戏

别再无脑把Opus 5的推理强度开到max，白白多花钱。

有人用FrontierCode编程基准，将Opus 5的推理档位由低到高完整测试了一遍。

测试得到的曲线相当反常：性能上限并未出现在完全拉满的顶配档位，真正的性能峰值是medium。

按照我们对大模型的直觉，推理档位就像油门，踩得越深理应跑得越快，然而Opus 5踩到底后反倒熄火了…

到底怎么回事？

动不动就重构代码

所谓档位油门，其实调节的是推理强度，与模型智商没有太大关系；从low、medium、high到xhigh、max，本质都是控制推理预算的闸门。

档位提高，意味着模型获得了更多思考余量，因此会在动手前想得更久、更深入。

这听起来似乎不错，多想一会儿难道还有错？

问题却正好就出在这个多想的过程中。

如果任务本身不需要那么多思考量，多出来的预算就一定会给自己另找事情做。

矛盾因此出现：对于信息提取、分类和文档撰写等边界明确的简单任务，low与high的输出质量几乎没有区别。

可一旦用户选择高档位，富余的推理预算只会促使模型重复梳理已有结论，并反复进行校验。

推理链过长，还可能逐渐偏离最初需求。

代码场景则更加夸张：如果任务只是修复几行函数bug，低档位通常仅会给出针对性补丁；

把强度调高之后，富余算力却会推动模型自行重构无关函数、修改导入、重命名变量，甚至优化毫不相关的代码。

一个小问题就这样膨胀成完整PR…额外提供的预算反而变成了负担。

而这种问题在Opus 5上尤其突出，它动不动就要给自己“加戏”。

Anthropic在自己的提示词指南里几乎是明着劝你把推理闸门往下拧：

只要评测能够证明质量不下降，就应大范围采用low与medium来降低成本和延迟，把高档位留给真正困难的长周期任务。

然而Opus 5发布当天，A社却将Opus 5的默认推理值设为了high……

一句话就能解决

当然，将effort从high调整回medium并不复杂。

通过API使用时修改output_config.effort；使用Claude Code时，则可以在配置中更换默认档位。

调整后立刻可以感受到模型不再到处撒欢，输出token明显减少，而结构化任务的质量不但没有降低，往往还会变得更好。

若想同时兼顾成本与效果，最合适的方式是按照任务分层。

格式化、信息提取等无需额外思考的机械任务，可以交给low；

日常编码与代码审查可采用medium或high，在稳定性和开销之间取得平衡；

只有需要长时间自主推理、连续执行几十步的长周期Agent任务，才有必要启用xhigh甚至max。

不过，这里还隐藏着一个极易忽视的缓存成本陷阱。

effort档位属于缓存匹配标识，只要在会话中更换档位，全部上下文缓存就会被直接清空，模型也会被迫重新读取整段对话历史。

即使从high切换至low后，单轮价格看起来降低了，缓存失效仍会造成上下文重复加载，最终总成本反而可能增加。

因此，更合理的策略是先建立完整工作流，再为该工作流固定一个档位，中途始终不作调整，以便持续命中缓存并降低总体开销。

Opus 5确实聪明，但可千万别让它使劲过头（doge）。

参考链接：

[1]https://x.com/cl571128/status/2080783750456311836?s=20

[2]https://x.com/jerhadf/status/2080806404898619791?s=20

[3]https://x.com/tenobrus/status/2080736458693079139?s=20