“Claude Code 里疑似被路由到 Opus 5.2”“回答突然更勤快”“能答出某个冷知识”，这些观察可以成为调查的起点，却不能证明模型已正式发布，更不能推出内部模型、RSI 或研究团队替代率等结论。做模型迁移的人真正需要的，是可复现的证据链：官方模型页与更新日志、可见的模型 ID、固定测试集、用量记录，以及明确的回滚条件。
这张素材反映的是公开讨论。它适合提示“需要核验什么”，不能替代模型身份、能力或价格的证据。
先把四类信息分开
| 信息 | 能说明什么 | 不能说明什么 |
|---|---|---|
| 官方文档、控制台模型列表、变更日志 | 正式名称、可用地区、接口与价格 | 你的任务一定更好 |
| 请求返回的模型 ID 与时间戳 | 某次请求实际命中什么 | 后续所有请求都会同样路由 |
| 固定任务集的结果 | 特定条件下的质量、耗时与失败率 | 通用排行榜能力 |
| 社媒截图、冷知识问答、主观体感 | 值得继续调查的线索 | 权重版本、训练数据或内部路线图 |
“同名模型表现不同”可能来自路由、系统提示词、工具、上下文、搜索开关、采样参数或账号权限。只用一个 Tibo 式冷知识问题做指纹测试，会把这些变量混在一起；模型刚好答对或答错，都不是可靠的版本鉴定。
一小时完成一次灰度核验
0–10 分钟：建立证据卡
记录日期、账号、地区、客户端版本、模型选择器文字、官方链接和截图。没有官方发布页时，把状态写成“待核验灰度观察”，不要用“已上线”。
10–35 分钟：跑同一组任务
准备 8 到 12 个脱敏任务，至少覆盖：小型代码修复、跨文件理解、工具调用、长文摘要、失败后重试。每题固定输入、工具和验收条件。记录完成率、人工修改量、耗时和输出 token；不要只记录最惊艳的一次回答。
任务：修复 CSV 导出中的空日期错误。
输入：最小复现仓库与失败测试。
验收：新增测试通过；不修改无关文件；说明根因与回滚方式。
任务：修复 CSV 导出中的空日期错误。
输入：最小复现仓库与失败测试。
验收：新增测试通过；不修改无关文件；说明根因与回滚方式。
35–50 分钟：查成本和能力开关
核对模型 ID、上下文限制、工具支持、缓存字段和账单。模型名称相同不代表接口行为相同；即使某次请求显示新标识，也不代表所有组织、地区或 SDK 都可用。
50–60 分钟：写迁移决定
用一句话结论代替情绪：在 10 个固定任务中，候选路线的验收通过率为 X/10，平均耗时为 Y，仍有 Z 个失败类型；只在测试组灰度使用，保留旧模型回滚。 没有 X、Y、Z 就不要做“更强”结论。
三个常见误判
把路由当发布。 路由可能按账号、地区、负载或任务改变。正式迁移只以控制台和官方文档支持的模型 ID 为准。
把更长输出当更强。 长任务里更主动的迭代可能提高完成度，也可能增加不必要工具调用和成本。检查最终 diff、测试与人工返工，而不是只看过程显得多忙。
把内部路线图当产品承诺。 未证实的“Model 2”“RSI”“替代比例”不应进入预算、招聘或技术路线。它们最多是观察材料，不能成为决策输入。
给团队的发布前模板
候选模型：
官方可验证链接：
控制台模型 ID：
测试日期 / 账号范围：
固定任务数与通过数：
失败类型：
平均耗时 / 实际成本：
已确认能力：
未确认能力：
回滚模型与触发条件：
负责人：
候选模型：
官方可验证链接：
控制台模型 ID：
测试日期 / 账号范围：
固定任务数与通过数：
失败类型：
平均耗时 / 实际成本：
已确认能力：
未确认能力：
回滚模型与触发条件：
负责人：
通过 ClaudeAPI 接入模型时，同样先在控制台确认目标模型、接口与实时价格；没有确认前，不要把社媒中的 Opus 5.2 名称填进生产配置。把这张模板和调用记录放在同一评测单里，团队才能知道迁移带来的是可复核收益，还是一次偶然的体感变化。
本文将公开讨论与可验证事实分开处理，不代表 Anthropic 或任何第三方的官方发布。模型名称、路由、功能、价格和可用性都可能变化，请以官方文档与实际控制台为准。
