Claude 旧模型退休后，接口迁移不要只改一个 model 字段

Claude Platform release notes 在 2026 年 6 月 15 日记录了一个明确变化：Claude Sonnet 4（claude-sonnet-4-20250514）和 Claude Opus 4（claude-opus-4-20250514）已经退休，请求这些模型会返回错误，官方建议分别迁移到 Claude Sonnet 4.6 和 Claude Opus 4.8。 对开发团队来说，这不是普通版本公告。真正容易出问题的，往往不是替换字符串，而是日志、回放样本、错误归因和灰度策略没有同步改。

先把错误路径当成正式流程处理

如果线上仍有请求打到旧模型，6 月 15 日之后就不该再期待正常内容。迁移脚本要把这类错误单独打标签，不能混进普通 4xx 或 5xx。否则值班同学看到的只是失败率升高，很难判断是供应商变更、鉴权问题，还是应用自己的参数错误。

我会把检查分成三层：配置中心里是否还有旧模型名，调用日志里是否还有旧模型请求，失败样本里是否能还原 prompt、temperature、max tokens 和工具配置。只有三层都过一遍，迁移才不是“改完发版”。

新模型不等于旧行为无损替换

官方推荐 Sonnet 4 迁到 Sonnet 4.6，Opus 4 迁到 Opus 4.8，但推荐目标不代表每个业务场景都能直接替换。长文生成、代码修复、分类提取、工具调用都会受模型行为变化影响。老模型退休当天才做回归测试，风险会集中到同一批用户身上。

比较稳的做法是挑一组高频样本和高风险样本。高频样本看成本、延迟和格式稳定性；高风险样本看拒答、工具调用、敏感内容和人工审核结论。接入层如果用 147AI 做多模型观察，可以把旧模型最后一批样本和新模型灰度样本放到同一张复盘表里，但判断仍要以业务验收结果为准。

迁移清单要写到运维能接手

这次退休提醒的是一个工程习惯：模型名不要散落在代码、prompt 模板、离线任务、评测脚本和客户配置里。最好把模型标识、推荐替代模型、下线日期、错误处理、回滚路径放进一张迁移清单。

Claude 原生 Messages API、云平台托管入口、企业内部网关、OpenAI 兼容客户端，这几类链路的参数形状不一定相同。迁移文档里要写清楚在哪一层改 model，在哪一层只改路由，哪些测试必须重新跑。少写一句，后面就可能多一次线上排查。