技术 · 熟练非周期
同一个请求，换个模型就 400 了？
参数还在，能力没了 —— 这才是最难查的一类
把模型名从旧款改成新款、别的什么都没动，却收到 400 —— 而报错指向的那个参数，你一直在用、文档里也还写着。这是升级里最难查的一类变更：不是参数语义变了，是这项能力在新模型上被移除了。以 Claude Opus 5.5 为例，官方一次列了四处：思考不能关（thinking 的 disabled 与旧 budget_tokens）、tool_choice 的 any 与指定工具名被拒、电脑操作要换 computer_toolset_20260801、非默认的 temperature / top_p / top_k。还有两处不报错：默认 effort 由 high 降到 medium、响应首块变成 thinking（按 content[0].text 取值会拿到空）。这一页就是那张扫描清单加四条替代写法。
流程 · 一图看懂
1先把报错与静默改行为分开
→
2把四处必 400 的写法逐个搜出来
→
3用 auto 加严格工具替代「强制」
→
4跑一遍金丝雀再上线
展开明细 · 每步做什么
1 · 先分清两类变化
① 第一类硬失败：请求直接被拒、返回 400 —— 报错信息通常会点名那个参数，好查
② 第二类静默改行为：请求成功、没有报错，但结果变慢 / 变短 / 变空 —— 这类只能靠对比输出发现
③ 两类的查法不同：前一类搜代码里的参数名，后一类跑同一批输入看差异；⛔ 不要把第二类当成「模型不好用」
2 · 把必 400 的写法搜出来
① 逐个搜这四个词：`thinking` · `tool_choice` · `temperature` / `top_p` / `top_k` · 旧的 computer 工具版本号
② 每命中一处，记一行：文件与行号 · 现在传的值 · 这个参数原本是为了什么（要 JSON？要它别啰嗦？要不许它不调工具？）
③ 第三列最重要 —— 迁移时要保住的是那个目的，不是那个写法
3 · 换写法，不换目的
① 原来强制调某个工具 ⇒ 改成 `auto` 加一条明确指令点名这个工具，并给工具加 `strict: true` 保参数格式
② 原来强制调用只是为了拿 JSON ⇒ 改用结构化输出（`output_config.format`），⛔ 不要再用「强制调工具」当 JSON 开关
③ 原来用 disabled 关思考 ⇒ 删掉该字段，改用 effort 档位控制深度；原来靠 temperature 调风格 ⇒ 改在提示词里写清风格与示例
④ 解析侧同步改：按内容块的 type 取文本（thinking / text / tool_use 分开），⛔ 不要取 `content[0]`
4 · 金丝雀与回滚点
① 固定 5 条最依赖这几项能力的调用，旧模型与新模型各跑一遍，比的是输出差异而不是「有没有报错」
② 特别看三样：输出长度是否骤变、工具是否还被调用、结构化字段是否还齐
③ 写一张变更单：日期 / 改了哪几处 / 金丝雀结果 / 回滚到哪个模型名；⛔ 不要在同一天既换模型又改提示词
触发条件：每逢升级模型或 SDK 大版本之前跑一次；平时不动模型就不必跑
验证点 · 做完怎么确认对
三步可核：① 我能列出这次迁移里「报了 400 的」与「没报错但行为变了的」各几条 ② 每一处改动能说出「原本想达到什么目的、现在用什么达到」③ 金丝雀 5 条在新旧模型上的输出差异我留着。只做到「不报错了」不算做完 —— 静默变化通常比 400 更贵。
自动化建议：把第 2 步做成一个可重跑的检查：把四个搜索词写进一条脚本或一个搜索命令，每次升级前跑一遍，输出「命中文件 + 行号」；再把第 4 步的 5 条金丝雀输入存成固定文件，新旧模型各跑一次做差异比对。⛔ 不要让 agent 自动改代码再自动上线 —— 它可以把命中处列全、把改法写出来，但改动要你逐行看过。
# 角色
你是我的「模型迁移扫描员」。你要找的是「换个模型就会坏」的地方，不是给建议。
# 输入
我会给你：① 目标模型名与来源（官方 changelog / 迁移指南原文，我会贴）② 我的代码或配置片段
如果我没给官方原文，你只做第 1 步的静态搜索，并在结论里写「依据层 = 未见官方原文」。
# 任务（按顺序）
1. 在我给的代码里逐处找出这四类写法，按文件与行号列出：
- thinking 相关字段（disabled 类型 · 旧的 budget_tokens）
- tool_choice（any 类型 · 指定工具名）
- temperature / top_p / top_k
- 旧版本的 computer 工具类型名
2. 每一处补一列「原本的目的」，只能是这三种之一：要它必须调某个工具 / 要它必须回 JSON / 要它少啰嗦。⛔ 猜不出就写「需你确认」。
3. 按目的给替代写法（只给写法，不改代码）：
- 必须调某工具 ⇒ auto + 指令点名 + 工具加 strict
- 必须回 JSON ⇒ 结构化输出，⛔ 不用强制调工具
- 少啰嗦 ⇒ effort 或提示词约束
4. 再列一节「不报错但会变的地方」：默认 effort 档位、响应首块类型、最大输出与思考是否计入上限。
5. 给一张 5 行金丝雀清单：哪五个调用最能暴露上述变化，每个写「看什么差异」。
# 输出格式
一张命中表（文件 / 行号 / 写法 / 目的 / 替代写法）+ 一节静默变化 + 一张金丝雀表。
# 约束
- ⛔ 不要替我改文件，只给位置与写法。
- ⛔ 不要用「一般来说新版都支持」这种推断；官方原文没写的，标「未见官方说明」。
- 一处命中若你不确定目的，宁可留空让 我填，⛔ 不要编。