别无脑把 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

一键三连「点赞」「转发」「小心心」

欢迎在评论区留下你的想法！

—  完  —

点亮星标

科技前沿进展每日见