Claude 网页端疑似上新模型：怎么判断是真换模型还是只改了提示词
有用户发现 Claude 网页端的模型标识像是新版本，怀疑官方悄悄换了模型，也有人认为只是改了 system prompt，因为只有一张没有来源的截图，讨论很快陷入各说各话。本文整理几条可复现的验证思路：从官方文档与 API 模型列表、响应体里的 model 字段、CLI 可选模型，到固定 prompt 的行为对比，并说明哪些“证据”其实不可靠。
一张截图引出的疑问
有人在 Claude 网页端使用时，发现界面里显示的模型标识看起来像是一个新版本（形如 claude-opus-4-7），于是截图发出来求证：是不是官方悄悄把模型换了？也有人泼冷水——说不定只是把 system prompt 改了一版，或者对部分账号做了灰度，回答风格变了而已。
争论之所以没有结论，是因为双方手里的材料不对等：一边是“我这边看到的就是这样”，另一边是“没有来源、没有复现步骤，无法判断”。这类问题其实有一套相对可靠的验证路径，下面就按可信度从高到低梳理一遍。
先分清三种“更新”
模型层面的变化至少有三种完全不同的形态，外观上却很像：
- 真的换了权重：底层模型更新，能力、风格、token 用量都可能变。
- 只换了系统提示或采样策略：模型没变，但回答更长、更啰嗦或更谨慎。
- 小流量灰度：只对部分账号、地区或套餐开放，别人看不到属于正常现象。
结论不同，处理方式也不同。如果只是提示词调整，那没必要为“新模型”改变工作流；如果是真更新，做行为对比和回归测试才有意义。
为什么“它自己说是新模型”不算证据
最常被当成证据的一条，恰恰最不可靠：直接问模型“你是什么版本”。
模型对自身版本的描述来自系统提示、训练数据和当前上下文，不是身份查询接口。同一个底层模型，在网页端、API、CLI 三个入口可以给出三种不同的自述；产品内部用别名映射到具体模型时，别名不变而底层变化，界面上的文字往往还会滞后一段时间。此外，让模型自报版本本身就容易被引导，问法不同答案就不同。
同理，“我这边有、你那边没有”也不是反例——灰度发布下，不同账号、地区、套餐看到的东西本来就可以不一样。
可靠度较高的验证方式
1. 先看官方渠道
这是唯一能给出确定结论的来源，其它都只是旁证：
- 官方文档里的模型列表与版本说明，看有没有对应标识。
- 更新日志 / release notes，正式发布通常会写。
- 服务状态页，看是否有相关变更记录。
- 官方账号的发布说明。
如果官方文档里还没有这个标识，那它更可能是内部别名、前端文案或误读，而不是已发布的模型。具体页面路径和字段名以官方最新文档为准。
2. 从 API 侧核对模型标识
网页端看不出来的东西，API 往往更直接。列出可用模型的接口大致如下（参数与路径请以官方文档为准）：
curl https://api.anthropic.com/v1/models \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01"
另一个更容易被忽略的点：调用返回体里通常带 model 字段，回显的是本次请求实际解析到的模型标识。把它和请求时传的名字对比，就能看出别名后面到底是谁在干活。
{
"model": "<实际使用的模型标识>",
"content": [ ... ]
}
如果网页端和 API 是同一套路由，两者返回的标识应该能对上；对不上，说明网页端可能用了另一套别名或仍指向旧版本。
3. 在 CLI 里确认可选模型
命令行工具通常能直接列出或切换模型：
- 启动时用
--model指定，看是否被接受。 - 会话内用
/model查看当前可选项和当前生效值。 claude --version确认工具本身是不是旧版本。- 检查环境变量（如
ANTHROPIC_MODEL）里有没有被写死一个旧别名。
注意：CLI 接受某个名字，只说明这个名字被识别，不说明它背后是新模型。
4. 做一套可复现的行为对比
这是判断“能力是否真的变了”的实证方法，也是最花时间的部分。关键是固定变量：
- 准备 20～50 条固定 prompt，覆盖长上下文、指令跟随、拒答边界、结构化输出（JSON）、工具调用参数格式、多语言。
- 固定
temperature（尽量取 0）、max_tokens和系统提示，只改模型标识。 - 每条跑 3 次，看同一模型自身的波动有多大——如果新旧差异小于自身波动，就不能下结论。
- 记录可比指标：输出长度分布、输入/输出 token 用量、JSON 解析成功率、工具调用参数是否合法。
- 结果落盘成文件，做成表格对比，而不是靠感觉。
| 观察维度 | 能说明什么 |
|---|---|
| 输出长度、啰嗦程度 | 提示词或采样策略变了也会导致 |
| 结构化输出合规率 | 更接近底层能力变化 |
| 工具调用参数格式 | 更接近底层能力变化 |
| 长上下文召回 | 更接近底层能力变化 |
| 拒答边界位置 | 多半由系统提示决定 |
5. 用量与计费面板
如果控制台提供按模型拆分的用量视图，那里的模型名通常比界面文案更接近真实路由。这一点值得优先看一眼。
6. 有自建网关就查日志
走代理或自建网关的话，把请求体里的 model 和响应体里的 model 都记下来，按天统计分布。灰度往往表现为“同一个别名，回显的标识开始出现新值”。
常见误判对照表
| 看到的现象 | 更可能的原因 |
|---|---|
| 回答风格明显变了 | 系统提示、采样参数或灰度，未必换了权重 |
| 界面出现新名字 | 前端文案或内部别名更新，流量未必切过去 |
| 模型自述是新版本 | 提示词或幻觉，不能作为证据 |
| 别人说“已经上了” | 账号、地区、套餐差异，或只是转述传闻 |
| 预测市场赔率变化 | 反映群体预期，不是官方发布 |
顺带说一句：有人会把这类猜测拿到预测市场上下注。赔率是群体预期的汇总，不是信息源，用它当“已发布”的证据，逻辑上是倒过来的。
该不该急着“抢先体验”
围绕新模型总会出现各类“内部渠道”“共享账号”“改地区提前用”的说法。这些做法的风险很实在：账号可能被封、付款信息与对话内容有泄露风险、服务随时中断，而且往往拿不到任何可验证的模型标识。稳妥的做法是等官方文档和更新日志明确，再按自己的套餐正常使用；想提前做能力评估，用自己账号的 API 跑对比测试就够了。
另外要提醒的是，任何行为对比的结论都有边界：它只对你当时的入口、时间、参数和账号成立。灰度期里今天测出来“没有”，不代表明天还没有；反过来也一样。
小结
判断网页端是不是真的换了模型，顺序应该是：先查官方文档与更新日志，再用 API 的模型列表和响应体 model 字段核对实际标识，然后才用固定 prompt 的行为对比去验证能力差异。截图、界面文案、模型自述、别人的“我这儿有了”，都只能算线索，不能算结论。
如果要做跨天、多轮次的对比测试，本地机器的休眠、性能波动和网络抖动会污染结果。一种可选做法是准备一台长期在线的远程 Mac（例如整机放在新加坡机房、按月租用的 Mac mini），远程连上去跑固定脚本，环境一致、不用守着机器，比起反复在本地复现会省事一些。当然，先用 API 跑一轮小规模测试，往往就能回答大部分疑问。
