Opus 5.2 灰度传闻怎么核验：别把路由、冷知识和 RSI 叙事当成发布证据

“Claude Code 里疑似被路由到 Opus 5.2”“回答突然更勤快”“能答出某个冷知识”，这些观察可以成为调查的起点，却不能证明模型已正式发布，更不能推出内部模型、RSI 或研究团队替代率等结论。做模型迁移的人真正需要的，是可复现的证据链：官方模型页与更新日志、可见的模型 ID、固定测试集、用量记录，以及明确的回滚条件。

这张素材反映的是公开讨论。它适合提示“需要核验什么”，不能替代模型身份、能力或价格的证据。

先把四类信息分开

“同名模型表现不同”可能来自路由、系统提示词、工具、上下文、搜索开关、采样参数或账号权限。只用一个 Tibo 式冷知识问题做指纹测试，会把这些变量混在一起；模型刚好答对或答错，都不是可靠的版本鉴定。

一小时完成一次灰度核验

0–10 分钟：建立证据卡

记录日期、账号、地区、客户端版本、模型选择器文字、官方链接和截图。没有官方发布页时，把状态写成“待核验灰度观察”，不要用“已上线”。

10–35 分钟：跑同一组任务

准备 8 到 12 个脱敏任务，至少覆盖：小型代码修复、跨文件理解、工具调用、长文摘要、失败后重试。每题固定输入、工具和验收条件。记录完成率、人工修改量、耗时和输出 token；不要只记录最惊艳的一次回答。

任务：修复 CSV 导出中的空日期错误。
输入：最小复现仓库与失败测试。
验收：新增测试通过；不修改无关文件；说明根因与回滚方式。

35–50 分钟：查成本和能力开关

核对模型 ID、上下文限制、工具支持、缓存字段和账单。模型名称相同不代表接口行为相同；即使某次请求显示新标识，也不代表所有组织、地区或 SDK 都可用。

50–60 分钟：写迁移决定

用一句话结论代替情绪：在 10 个固定任务中，候选路线的验收通过率为 X/10，平均耗时为 Y，仍有 Z 个失败类型；只在测试组灰度使用，保留旧模型回滚。 没有 X、Y、Z 就不要做“更强”结论。

三个常见误判

把路由当发布。 路由可能按账号、地区、负载或任务改变。正式迁移只以控制台和官方文档支持的模型 ID 为准。

把更长输出当更强。 长任务里更主动的迭代可能提高完成度，也可能增加不必要工具调用和成本。检查最终 diff、测试与人工返工，而不是只看过程显得多忙。

把内部路线图当产品承诺。 未证实的“Model 2”“RSI”“替代比例”不应进入预算、招聘或技术路线。它们最多是观察材料，不能成为决策输入。

给团队的发布前模板

候选模型：
官方可验证链接：
控制台模型 ID：
测试日期 / 账号范围：
固定任务数与通过数：
失败类型：
平均耗时 / 实际成本：
已确认能力：
未确认能力：
回滚模型与触发条件：
负责人：

通过 Code0 接入模型时，同样先在控制台确认目标模型、接口与实时价格；没有确认前，不要把社媒中的 Opus 5.2 名称填进生产配置。把这张模板和调用记录放在同一评测单里，团队才能知道迁移带来的是可复核收益，还是一次偶然的体感变化。

本文将公开讨论与可验证事实分开处理，不代表 Anthropic 或任何第三方的官方发布。模型名称、路由、功能、价格和可用性都可能变化，请以官方文档与实际控制台为准。