1. 先别急着骂模型Claude Code 响应异常的典型症状与定位思路最近不少用 Claude Code CLI 的朋友都在吐槽同一件事明明settings.json里锁的是 Opus跑起来却像换了个脑子。具体表现很有辨识度——不读文件就直接改代码、信誓旦旦地编造一个根本不存在的 npm 包、一个中等任务烧掉几十上百美元的 API 费用、你反复强调别动那个文件它偏要动。这些不是玄学背后大概率指向同一个东西adaptive thinking 行为变化。先把概念说清楚。Claude Code 是 Anthropic 官方的命令行编程代理它能在终端里读写文件、执行命令、跑测试、提交代码。Opus 是它可调用的高能力模型档位适合复杂重构和多步推理。而 adaptive thinking自适应思考是让模型自己决定这一轮要想多久的机制——听起来很聪明问题在于它经常决定不想了。零 token 思考直接进入输出于是就有了上面那些变蠢的表现。这篇适合谁日常在终端里用 Claude Code CLI 干活、最近感觉 Opus 表现不对劲、想自己动手定位而不是干等的开发者。我会把排查拆成可跟做的步骤先确认症状归属再检查settings.json配置然后逐项验证请求是否真的走到了 Opus最后对照真实报错排障。整个过程围绕一个核心检索词展开——Claude Code adaptive thinking 导致的 Opus 响应异常怎么修。定位思路其实很朴素把模型变笨拆成三个可独立验证的层。第一层是模型选择层CLI 到底有没有按你指定的 Opus 发请求第二层是思考预算层adaptive thinking 有没有把某些轮次的思考压到零第三层是版本行为层新版 CLI 内部有没有强化某些被削弱的默认行为。三层里任何一层出问题体感都是它变蠢了但修法完全不同。所以别一上来就改配置先按下面的顺序确认能省掉大量瞎试的时间。我自己的习惯是先跑一个最小复现任务让它读一个已知文件再回答里面某个具体值。如果它不读文件就答基本锁定思考预算或模型选择问题如果读了但答错可能是模型档位被降级。这个动作花不了一分钟却能快速把问题范围缩小一半。2. 前置准备TaoToken 接入 Claude Code 的 Base URL 与 Key 获取在动settings.json之前得先保证你的请求链路是通的、可控的。很多响应异常其实是接入层没配对请求根本没到你以为的模型。这里用 TaoToken 作为统一接入入口它提供兼容 Anthropic 的 API 端点方便你在 CLI 里锁定模型和参数。先拿访问凭证。打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并登录进入控制台。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 在里面可以创建和管理你的 API Key。创建完记得立刻复制保存页面刷新后通常不再完整显示。拿到 Key 之后去 API Keys 页面确认它的状态和额度https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。这一步别跳过Key 被禁用或额度耗尽时CLI 报的错往往很含糊容易被误判成模型问题。接入端点用 https://taotoken.net/api 注意这个地址不带任何查询参数直接作为 Base URL 填进配置。如果你用的是 Claude Code 的 Anthropic 兼容模式Base URL 就指向它模型 ID 按你实际要用的档位填比如claude-opus-4-6。这里有个关键点TaoToken 是合规的 API 接入服务不是让你绕过什么而是把模型调用统一到一个可观测的入口。你可以在控制台看到每次请求的模型、token 消耗和耗时这对排查到底走没走 Opus极其有用。很多人排查半天最后发现是 Key 配错或 Base URL 写成了别的地址请求压根没发出去。准备阶段还要确认 CLI 版本。用claude --version看当前版本记下来。如果你最近升级过而问题正好在升级后出现那版本行为层就是重点怀疑对象。把版本号、Key、Base URL 三样东西先备齐再进入配置环节。顺便说一句如果你需要更细的接入说明官方文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各客户端的配置示例遇到字段不确定时对着看比猜快得多。3. 可复制配置settings.json 逐字段拆解与 adaptive thinking 关闭方法现在进入核心环节。Claude Code 的配置分两层全局的~/.claude/settings.json和项目级的.claude/settings.json。排查模型行为问题时建议先改项目级影响范围可控验证通过再考虑是否上提全局。打开你的.claude/settings.json加入或合并下面这段配置。注意 JSON 不允许尾逗号合并时别把原有字段弄坏{ model: claude-opus-4-6, effortLevel: high, alwaysThinkingEnabled: true, env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的_TaoToken_Key, CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING: 1, MAX_THINKING_TOKENS: 31999 } }逐字段说清楚每个是干什么的别照抄完不知道为什么。model锁定使用 Opus 档位防止 CLI 在某些条件下自动切换到更便宜的模型。你选了 Opus 结果执行的是别的档位很多时候就是这里没锁死。effortLevel设成high是关键。默认 effort 被调低后模型会在省力模式下工作思考深度不够。设成 high 把思考预算拉回来。这个字段单独用效果有限但配合下面两项就是必要拼图。alwaysThinkingEnabled强制每一轮都启用扩展思考不跳过。它单独用确实像给坏掉的喇叭调大音量——因为如果 adaptive thinking 还在把预算压到零你调多大音量都没用。所以它必须和关闭开关一起上。CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING设成1是最核心的一项。这就是关掉自适应思考的开关让模型回到固定思考预算模式每轮都认真想而不是自己决定这轮不想了。这个环境变量在常规文档里不一定显眼但它是解决零 token 思考的直接手段。MAX_THINKING_TOKENS设成31999给每轮思考设上限防止思考过程被意外截断。同样它单独用是噪音配合关闭 adaptive thinking 后才给固定预算兜住底。如果你用的是 Codex 风格的auth.json或者通过 Cline MCP、CC Switch 这类工具管理多套配置记住三件套必须齐全Base URL、Key、Model ID。缺任何一个请求要么发不出去要么走到默认档位。以auth.json为例结构大致是这样{ baseUrl: https://taotoken.net/api, apiKey: 你的_TaoToken_Key, model: claude-opus-4-6 }改完配置后CLI 需要重启才能读到新的环境变量。别改完就在原会话里测那样测的是旧配置。关掉终端重开或者退出当前claude会话再进。还有一个版本层面的动作值得考虑如果问题在升级后集中出现退回一个稳定版本是干净的起点。用 npm 操作npm uninstall -g anthropic-ai/claude-code npm install -g anthropic-ai/claude-code2.1.98退版本去掉新版 CLI 里可能强化异常行为的内部改动加配置关掉 adaptive thinking 并恢复高 effort两者组合才是完整方案。只做一样往往感觉好了一点但没根治。4. 验证请求确认真的走到了 Opus 且思考预算生效配置改完不等于生效必须验证。这一步很多人跳过结果在错误的前提上继续排查越排越乱。第一个验证动作确认模型档位。在 CLI 里发一个简单请求然后去 TaoToken 控制台的请求日志看这次调用实际用的模型 ID。如果显示的不是你配的 Opus 档位说明model字段没生效或者被更高优先级的配置覆盖了。项目级和全局级配置同时存在时注意优先级关系。第二个验证动作确认思考预算。跑一个需要读文件的任务比如读一下 package.json告诉我 dependencies 里有哪些包。观察它是否先读文件再回答。如果直接开答说明思考预算还是被压着回去检查CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING是否真的被 CLI 读到了。可以在会话里用命令查看环境变量或者临时在 shell 里export后再启动 CLI 对比。第三个验证动作看 token 消耗曲线。在控制台里对比修复前后的单次请求 token 数。修复后复杂任务的思考 token 应该明显上升且稳定而不是忽高忽低甚至出现零思考的轮次。这个曲线是最直观的证据。第四个验证动作跑一个之前失败的具体案例。把你印象最深的那次它编造不存在的包或它乱改文件的任务重跑一遍看行为是否恢复。用真实失败案例验证比跑玩具示例有说服力得多。如果你想单独验证模型对话是否正常可以用模型对话入口快速测一条https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。在这里发一条需要多步推理的问题观察响应质量和思考过程能帮你把CLI 配置问题和模型本身问题区分开。验证通过的标准很明确模型 ID 正确、读文件行为恢复、token 曲线稳定、旧失败案例通过。四条都满足才算真正修好。只满足一两条说明还有层没处理干净。5. 常见报错排查401、local proxy failed、reading choices、OAuth 对照表排查过程中你会撞上各种报错很多看起来吓人其实指向很明确。下面按真实报错逐条对照。401 Unauthorized最常见。原因通常是 Key 无效、过期、复制时带了空格或者ANTHROPIC_API_KEY没被 CLI 读到。先去 API Keys 页面确认 Key 状态和额度再检查配置文件里的值有没有多余字符。环境变量和配置文件同时设置时注意哪个优先。local proxy failed或连接类错误多半是 Base URL 写错或网络层问题。确认ANTHROPIC_BASE_URL是https://taotoken.net/api注意结尾不要多加斜杠或路径。如果你本地有其它工具占用了端口或改了代理设置也可能触发这类错误逐一排除。reading choices相关报错通常出现在响应解析阶段往往和返回体格式、模型档位不匹配有关。检查你请求的模型 ID 是否真实存在且当前可用拼错的模型名会导致返回结构异常。对照文档里的模型列表确认拼写。OAuth相关报错说明你在用账号授权模式而不是 API Key 模式两种模式的配置字段不同。如果你要走 API Key 接入确保没有残留的 OAuth 配置干扰。清理掉冲突字段再重启 CLI。还有一类没有明确报错但行为异常的情况请求成功返回但模型明显没思考。这种最容易被忽略因为它不报错。判断方法是看控制台的思考 token 是否为 0 或异常低。如果是回到第 3 节检查 adaptive thinking 关闭项。排查时养成一个习惯每次只改一个变量改完立刻验证。同时改三四个字段出问题你根本不知道是哪个引起的。我踩过的坑就是一次性把版本、配置、Key 全换了结果好了也不知道为什么好下次再出问题还是不会修。如果排障卡住接入文档里有更细的字段说明和示例https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。对着文档核对比在群里问快。6. 长期使用建议把配置固化成可复用的排查清单修好一次不算完Claude Code 和模型侧还会持续更新类似的行为变化可能再来。与其每次重新排查不如把这次的经验固化成清单。第一把关键配置纳入版本管理。项目级.claude/settings.json提交到仓库团队里每个人用同一套参数避免我这里好好的你那里不行的扯皮。注意别把 Key 明文提交用环境变量注入。第二给模型档位和思考预算设一个基线。记录下修复后正常状态下的 token 消耗区间和典型任务表现下次感觉不对劲时先对比基线快速判断是真退化还是错觉。第三关注 CLI 版本变更。升级前先看变更说明升级后跑一遍你的验证任务。如果新版本又引入类似行为你有现成的回退版本和配置可以立刻用。第四把请求日志当日常工具。TaoToken 控制台能看到每次调用的模型、token、耗时定期扫一眼异常早发现。这比等任务跑砸了再回头查高效得多。如果你长期做编码类任务、经常跑 Agent 流程可以考虑用 Coding Plan 把额度固定下来避免按量计费时因为异常重试烧掉预算https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。对高频使用者来说成本可预期本身就是一种稳定。最后回到那个核心判断Claude Code 变蠢绝大多数时候不是模型能力退化而是思考预算被 adaptive thinking 压到了零或者模型档位没锁死。你要做的不是加一堆配置项而是搞清楚它改坏了什么然后精确还原回去。关掉 adaptive thinking、恢复高 effort、保证每轮都思考、锁死 Opus 档位——这四件事做到位Opus 该有的表现就回来了。 
长河君 · 2026/10/8 6:08:44 · 阅读 1.2k 最近你是不是也觉得 Claude Code 不对劲：从 settings.json 到 Opus 的排查清单
1. 先别急着骂模型Claude Code 响应异常的典型症状与定位思路最近不少用 Claude Code CLI 的朋友都在吐槽同一件事明明settings.json里锁的是 Opus跑起来却像换了个脑子。具体表现很有辨识度——不读文件就直接改代码、信誓旦旦地编造一个根本不存在的 npm 包、一个中等任务烧掉几十上百美元的 API 费用、你反复强调别动那个文件它偏要动。这些不是玄学背后大概率指向同一个东西adaptive thinking 行为变化。先把概念说清楚。Claude Code 是 Anthropic 官方的命令行编程代理它能在终端里读写文件、执行命令、跑测试、提交代码。Opus 是它可调用的高能力模型档位适合复杂重构和多步推理。而 adaptive thinking自适应思考是让模型自己决定这一轮要想多久的机制——听起来很聪明问题在于它经常决定不想了。零 token 思考直接进入输出于是就有了上面那些变蠢的表现。这篇适合谁日常在终端里用 Claude Code CLI 干活、最近感觉 Opus 表现不对劲、想自己动手定位而不是干等的开发者。我会把排查拆成可跟做的步骤先确认症状归属再检查settings.json配置然后逐项验证请求是否真的走到了 Opus最后对照真实报错排障。整个过程围绕一个核心检索词展开——Claude Code adaptive thinking 导致的 Opus 响应异常怎么修。定位思路其实很朴素把模型变笨拆成三个可独立验证的层。第一层是模型选择层CLI 到底有没有按你指定的 Opus 发请求第二层是思考预算层adaptive thinking 有没有把某些轮次的思考压到零第三层是版本行为层新版 CLI 内部有没有强化某些被削弱的默认行为。三层里任何一层出问题体感都是它变蠢了但修法完全不同。所以别一上来就改配置先按下面的顺序确认能省掉大量瞎试的时间。我自己的习惯是先跑一个最小复现任务让它读一个已知文件再回答里面某个具体值。如果它不读文件就答基本锁定思考预算或模型选择问题如果读了但答错可能是模型档位被降级。这个动作花不了一分钟却能快速把问题范围缩小一半。2. 前置准备TaoToken 接入 Claude Code 的 Base URL 与 Key 获取在动settings.json之前得先保证你的请求链路是通的、可控的。很多响应异常其实是接入层没配对请求根本没到你以为的模型。这里用 TaoToken 作为统一接入入口它提供兼容 Anthropic 的 API 端点方便你在 CLI 里锁定模型和参数。先拿访问凭证。打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并登录进入控制台。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 在里面可以创建和管理你的 API Key。创建完记得立刻复制保存页面刷新后通常不再完整显示。拿到 Key 之后去 API Keys 页面确认它的状态和额度https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。这一步别跳过Key 被禁用或额度耗尽时CLI 报的错往往很含糊容易被误判成模型问题。接入端点用 https://taotoken.net/api 注意这个地址不带任何查询参数直接作为 Base URL 填进配置。如果你用的是 Claude Code 的 Anthropic 兼容模式Base URL 就指向它模型 ID 按你实际要用的档位填比如claude-opus-4-6。这里有个关键点TaoToken 是合规的 API 接入服务不是让你绕过什么而是把模型调用统一到一个可观测的入口。你可以在控制台看到每次请求的模型、token 消耗和耗时这对排查到底走没走 Opus极其有用。很多人排查半天最后发现是 Key 配错或 Base URL 写成了别的地址请求压根没发出去。准备阶段还要确认 CLI 版本。用claude --version看当前版本记下来。如果你最近升级过而问题正好在升级后出现那版本行为层就是重点怀疑对象。把版本号、Key、Base URL 三样东西先备齐再进入配置环节。顺便说一句如果你需要更细的接入说明官方文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各客户端的配置示例遇到字段不确定时对着看比猜快得多。3. 可复制配置settings.json 逐字段拆解与 adaptive thinking 关闭方法现在进入核心环节。Claude Code 的配置分两层全局的~/.claude/settings.json和项目级的.claude/settings.json。排查模型行为问题时建议先改项目级影响范围可控验证通过再考虑是否上提全局。打开你的.claude/settings.json加入或合并下面这段配置。注意 JSON 不允许尾逗号合并时别把原有字段弄坏{ model: claude-opus-4-6, effortLevel: high, alwaysThinkingEnabled: true, env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的_TaoToken_Key, CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING: 1, MAX_THINKING_TOKENS: 31999 } }逐字段说清楚每个是干什么的别照抄完不知道为什么。model锁定使用 Opus 档位防止 CLI 在某些条件下自动切换到更便宜的模型。你选了 Opus 结果执行的是别的档位很多时候就是这里没锁死。effortLevel设成high是关键。默认 effort 被调低后模型会在省力模式下工作思考深度不够。设成 high 把思考预算拉回来。这个字段单独用效果有限但配合下面两项就是必要拼图。alwaysThinkingEnabled强制每一轮都启用扩展思考不跳过。它单独用确实像给坏掉的喇叭调大音量——因为如果 adaptive thinking 还在把预算压到零你调多大音量都没用。所以它必须和关闭开关一起上。CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING设成1是最核心的一项。这就是关掉自适应思考的开关让模型回到固定思考预算模式每轮都认真想而不是自己决定这轮不想了。这个环境变量在常规文档里不一定显眼但它是解决零 token 思考的直接手段。MAX_THINKING_TOKENS设成31999给每轮思考设上限防止思考过程被意外截断。同样它单独用是噪音配合关闭 adaptive thinking 后才给固定预算兜住底。如果你用的是 Codex 风格的auth.json或者通过 Cline MCP、CC Switch 这类工具管理多套配置记住三件套必须齐全Base URL、Key、Model ID。缺任何一个请求要么发不出去要么走到默认档位。以auth.json为例结构大致是这样{ baseUrl: https://taotoken.net/api, apiKey: 你的_TaoToken_Key, model: claude-opus-4-6 }改完配置后CLI 需要重启才能读到新的环境变量。别改完就在原会话里测那样测的是旧配置。关掉终端重开或者退出当前claude会话再进。还有一个版本层面的动作值得考虑如果问题在升级后集中出现退回一个稳定版本是干净的起点。用 npm 操作npm uninstall -g anthropic-ai/claude-code npm install -g anthropic-ai/claude-code2.1.98退版本去掉新版 CLI 里可能强化异常行为的内部改动加配置关掉 adaptive thinking 并恢复高 effort两者组合才是完整方案。只做一样往往感觉好了一点但没根治。4. 验证请求确认真的走到了 Opus 且思考预算生效配置改完不等于生效必须验证。这一步很多人跳过结果在错误的前提上继续排查越排越乱。第一个验证动作确认模型档位。在 CLI 里发一个简单请求然后去 TaoToken 控制台的请求日志看这次调用实际用的模型 ID。如果显示的不是你配的 Opus 档位说明model字段没生效或者被更高优先级的配置覆盖了。项目级和全局级配置同时存在时注意优先级关系。第二个验证动作确认思考预算。跑一个需要读文件的任务比如读一下 package.json告诉我 dependencies 里有哪些包。观察它是否先读文件再回答。如果直接开答说明思考预算还是被压着回去检查CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING是否真的被 CLI 读到了。可以在会话里用命令查看环境变量或者临时在 shell 里export后再启动 CLI 对比。第三个验证动作看 token 消耗曲线。在控制台里对比修复前后的单次请求 token 数。修复后复杂任务的思考 token 应该明显上升且稳定而不是忽高忽低甚至出现零思考的轮次。这个曲线是最直观的证据。第四个验证动作跑一个之前失败的具体案例。把你印象最深的那次它编造不存在的包或它乱改文件的任务重跑一遍看行为是否恢复。用真实失败案例验证比跑玩具示例有说服力得多。如果你想单独验证模型对话是否正常可以用模型对话入口快速测一条https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。在这里发一条需要多步推理的问题观察响应质量和思考过程能帮你把CLI 配置问题和模型本身问题区分开。验证通过的标准很明确模型 ID 正确、读文件行为恢复、token 曲线稳定、旧失败案例通过。四条都满足才算真正修好。只满足一两条说明还有层没处理干净。5. 常见报错排查401、local proxy failed、reading choices、OAuth 对照表排查过程中你会撞上各种报错很多看起来吓人其实指向很明确。下面按真实报错逐条对照。401 Unauthorized最常见。原因通常是 Key 无效、过期、复制时带了空格或者ANTHROPIC_API_KEY没被 CLI 读到。先去 API Keys 页面确认 Key 状态和额度再检查配置文件里的值有没有多余字符。环境变量和配置文件同时设置时注意哪个优先。local proxy failed或连接类错误多半是 Base URL 写错或网络层问题。确认ANTHROPIC_BASE_URL是https://taotoken.net/api注意结尾不要多加斜杠或路径。如果你本地有其它工具占用了端口或改了代理设置也可能触发这类错误逐一排除。reading choices相关报错通常出现在响应解析阶段往往和返回体格式、模型档位不匹配有关。检查你请求的模型 ID 是否真实存在且当前可用拼错的模型名会导致返回结构异常。对照文档里的模型列表确认拼写。OAuth相关报错说明你在用账号授权模式而不是 API Key 模式两种模式的配置字段不同。如果你要走 API Key 接入确保没有残留的 OAuth 配置干扰。清理掉冲突字段再重启 CLI。还有一类没有明确报错但行为异常的情况请求成功返回但模型明显没思考。这种最容易被忽略因为它不报错。判断方法是看控制台的思考 token 是否为 0 或异常低。如果是回到第 3 节检查 adaptive thinking 关闭项。排查时养成一个习惯每次只改一个变量改完立刻验证。同时改三四个字段出问题你根本不知道是哪个引起的。我踩过的坑就是一次性把版本、配置、Key 全换了结果好了也不知道为什么好下次再出问题还是不会修。如果排障卡住接入文档里有更细的字段说明和示例https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。对着文档核对比在群里问快。6. 长期使用建议把配置固化成可复用的排查清单修好一次不算完Claude Code 和模型侧还会持续更新类似的行为变化可能再来。与其每次重新排查不如把这次的经验固化成清单。第一把关键配置纳入版本管理。项目级.claude/settings.json提交到仓库团队里每个人用同一套参数避免我这里好好的你那里不行的扯皮。注意别把 Key 明文提交用环境变量注入。第二给模型档位和思考预算设一个基线。记录下修复后正常状态下的 token 消耗区间和典型任务表现下次感觉不对劲时先对比基线快速判断是真退化还是错觉。第三关注 CLI 版本变更。升级前先看变更说明升级后跑一遍你的验证任务。如果新版本又引入类似行为你有现成的回退版本和配置可以立刻用。第四把请求日志当日常工具。TaoToken 控制台能看到每次调用的模型、token、耗时定期扫一眼异常早发现。这比等任务跑砸了再回头查高效得多。如果你长期做编码类任务、经常跑 Agent 流程可以考虑用 Coding Plan 把额度固定下来避免按量计费时因为异常重试烧掉预算https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。对高频使用者来说成本可预期本身就是一种稳定。最后回到那个核心判断Claude Code 变蠢绝大多数时候不是模型能力退化而是思考预算被 adaptive thinking 压到了零或者模型档位没锁死。你要做的不是加一堆配置项而是搞清楚它改坏了什么然后精确还原回去。关掉 adaptive thinking、恢复高 effort、保证每轮都思考、锁死 Opus 档位——这四件事做到位Opus 该有的表现就回来了。