别再无脑拉高推理！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