别无脑把Opus 5推理强度拉到max当冤大头。
有人拿FrontierCode编程基准把Opus 5推理档位从低到高扫了一遍。
结果扫出一条很不对劲的曲线，性能天花板根本不是拉满的顶配档位，medium才是性能顶峰。
按咱们对大模型的直觉，推理档位这个油门踩得越深应该跑得越快，可Opus 5踩到底反而熄了火…
咋回事？
01、一言不合就重构代码
这个档位油门其实是推理强度拨盘，和模型智商倒没多大关系，从low、medium、high一直到xhigh、max本质上是推理预算的闸门。
档位越高就说明你给模型思考的余量越大，它动手前就想得久、想得深。
听上去像是好事，多想想总不会错吧？
但问题恰恰出在多想这个过程里。
当一个任务本身用不了那么多思考量的时候，那笔多出来的预算一定要给自己找点活儿。
矛盾也由此产生，信息提取、分类、文档撰写这类边界清晰的简单任务，low和high输出质量几乎无差别。
但用户如果选了高档位，那多余的推理预算只会让模型反复校验、重复梳理已有结论。
并且过长推理链还会偏离原始需求。
更离谱的是代码场景，如果是只需要修复几行函数bug的时候，低档位就只会针对性输出补丁；
然而拉高强度之后，模型富余的算力会驱使它擅自重构无关函数、调整导入、重命名变量，甚至去优化无关代码。
一份小问题直接扩成了完整PR…你多给的预算反而成了负担。
而且这个痛点在Opus 5身上还极为明显，一言不合就给自己“加戏”。
Anthropic在自己的提示词指南里几乎是明着劝你把推理闸门往下拧：
只要评测能证明质量不掉，就大面积用low和medium去压成本和延迟，高档位留给真正硬核的长周期任务。
但Opus 5发布那天，A社却把Opus 5的推理默认值设在了high……
02、一句话解决
当然了，把effort从high调回medium也简单。
走API的改一下output_config.effort，用Claude Code的在配置里可以把默认档换掉。
改完立刻能感觉到模型不再满地撒欢，输出token大幅缩水，而那些结构化任务的质量非但没掉，往往还更好了。
要是想兼顾效果与成本，最舒服的做法是按任务分层。
格式化、信息提取这类不用多余思考的机械活丢给low；
日常编码、代码审查用medium或high，平衡稳定与开销；
只有那种需要长时间自主推理、连着跑几十步的长周期Agent任务，才值得把xhigh甚至max请出来。
但这里有个极易被忽略的缓存成本陷阱。
effort档位是缓存匹配标识，会话中切换档位会直接清空全部上下文缓存，强制模型重读整段对话历史。
哪怕从high切到low之后单轮单价看似下降，但缓存失效会带来重复上下文加载，整体总成本反而可能上浮。
所以较好的一种策略是建设完整的工作流，然后给这个工作流锁定单一档位，全程不中途调整，让其持续命中缓存来压缩整体开销。
Opus 5聪明是聪明，但千万别让它用力过猛了。
【本文由投资界合作伙伴微信公众号：量子位授权发布，本平台仅提供信息存储服务。】
【免责声明】：本文不构成任何投资建议。市场有风险，投资需谨慎。
如有任何疑问，请联系（editor@zero2ipo.com.cn）投资界处理。
