*此推论仅适用于 Chat 模式，不适用于 Work 模式以及 Codex。 先交代一下背景。 网页版 ChatGPT 对话的事件流和响应中会带有一些跟模型相关的信息。 比如说在事件流中， 可以看到有一些字段，例如： server_ste_metadata 下面的 model_slug， resolved_model_slug， v.message.metadata 下面的 model_slug， default_model_slug， 以及响应中也有相似的字段： 这些字段值都指向某一个具体的模型名称。 虽然这些信息属于内部字段，OpenAI 对它们 没有正式公开的官方定义 ， 但根据命名和经验推断，我们大概能得出一些信息： 比如 default_model_slug 大概率是 默认模型的标识 ， 比如 resolved_model_slug 大概率是 系统最终解析后实际采用的模型标识 ， 比如 server_ste_metadata.model_slug 大概率是 某个服务端子模块记录下来的模型标识 ， 比如 assistant.metadata.model_slug （也就是 v.message.metadata.model_slug）大概率是 助手消息被标记的模型标识 。 又但是由于官方没有公开它们的含义，所以没有人能 100% 说明它们代表什么。 正常使用的情况下，这些字段的值应当一致。 那么问题来了，有的时候它就会出现不一致的情况。 于是基于 7 月份对社区案例的观察，以及我自己账号的一些实测，我个人对这些模型标识的置信度做了一下排序。 第一层级，显示路由层： resolved_model_slug 、 server_ste_metadata.model_slug。 这两个光看名字就感觉更靠谱一些，一个是解析到的模型，一个是服务端返回的模型。 server_ste_metadata.model_slug 相对特殊一些，这个字段只有在实时的事件流里面能够找得到，而在响应中是没有的。也就意味着，只有当前跟模型对话时，才能看到这个字段。事后回去再看已经完成的对话，是找不到这个字段的。 第二层级，模型标签层： assistant.metadata.model_slug 以及一些在网页元素中能看到的标记。 这个感觉上就是最终助手被声明的，或者说写在助手脸上的模型。 存在着一点我说我是什么的意味，所以虽然有明确的标识返回，但优先级不如上一层级。 第三层级，默认模型层： 也就是 default_model_slug。 这个个人观察下来，定义为不可信，因为总是出现在最前面，选择什么模型它就是什么模型。 看起来好像是表示着用户请求的模型是什么。 于是按照这个逻辑，8 月份的时候，我做了一个浏览器扩展，也就是这个： 做了个检测GPT Pro账号降智5.5 Mini的Chrome扩展 & 分享下我自己的降智恢复经验 开发调优 本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 最近怒充 … 实际这个扩展背后的判断逻辑就是上面说的置信度， 捕获到第一层级优先，第二层级兜底，第三层级不参与判断。 但是 9 月中旬发现一些反馈的案例，开始出现一种现象。 有的人，比如我自己，表现一直还挺正常的，跟之前没什么变化， 实时请求的响应来源能正常捕获到 resolved_model_slug + server_ste_metadata.model_slug，而且表现一致。 但有的人，resolved_model_slug 这个响应字段消失了，同时反馈模型降智，并且还不止一起。 起初还以为是接口调整，正在灰度。但时间过去挺久了，我自己的依旧没有改变。 于是 有理由推测，这个东西是降智的表现之一。 所以上周在 X 上做了个投票，有 91 个人参与，最近出来了调研的结果。 四选项对比的差异看起来不明显，转换一下，分成有这个字段和没有这个字段两组： 结论就是： 存在 resolved_model_slug 字段的朋友，80% 的比例没有发生降智。 而 resolved_model_slug 字段消失的朋友，77.8% 的比例发生了降智。 由此推断， resolved_model_slug 字段是否消失跟模型是否发生降智存在比较强的相关性 。 并且在上一篇帖子的评论区，也有很多佬友的跟帖支持了这一说法。 所以，把这个结论分享给大家。 给各位做一个判断参考，也期待有大佬能在这个基础上得出更准确的结论。 考虑到上面调研结果虽然倾向表现很明显，但是毕竟不是 100%，依旧有 20% 朋友的 resolved_model_slug 字段虽然消失，却并没有发生降智，但又没有办法保证每个人对于降智的判断是准确的，所以扩展插件上新增了一个标签，叫做”疑似降级“。 出现这个黄色的信号就表示有比较高的可能性是发生降智了。 另外还有一点需要注意一下， 单纯的图片生成本来就是没有 resolved_model_slug 字段 的，但为了保持扩展的稳定性，没有单独针对生图的情况进行识别并排除。 所以如果你使用这个扩展的话，在通过网页聊天生成图片的时候遇到这个黄色警示，可以自行判断一下，如果 GPT-image-2.5 图片生成结果表现正常，那就没有问题。 再补充下说 Work 模式。 Work 模式无法通过以上的方法进行辨别。 因为 Work 模式根本就没有 resolved_model_slug 、server_ste_metadata.model_slug 这些字段。 Work 模式除了开始的请求默认模型标识之外，只有 metadata.model_slug 。 所以 不要使用上述浏览器扩展去分析网页端的 Work 模式。 上一篇帖子我也有分析，实际上降级的逻辑大多是先命中账号，然后基于账号进行风控。 所以单独判断网页版的 Work 模式是否发生降智这件事本身意义不大，因为它基本上跟 Codex 是一致的，如果要排查，直接按照 Codex 的排查方案去排查就可以了。 扩展上也添加了提示， 如果识别到 -wm（work mode）后缀的模型会显示为白色的”无法判断“提示 。 另外，原则上大部分网页版和 Codex 的降智命中的应该都是”疑似账号共享“这一个问题，解决方案就是表现出这个账号只有你一个人在使用。同时依旧是建议 先把活跃会话的设备全部踢掉，然后重登。 踢设备这个方案就类似于”遇事不决先重启“，是个万应锭。一些其他的莫名其妙的 bug，官方文档也是推荐先做这个自助操作。 Pro 账号突然寄了，backend-api 认证异常，分享经历给后来的佬友 搞七捻三 寄了但又没有完全寄。 总之就是正常使用 Codex 的时候，突然任务中断。 [image] 更换设备以后，依旧是同样的问题。 [image] 继而又发现所有设备网页版都挂了。 [image] 排查了一下代理节点发现没问题，同一个节点的北美豆包能正常访问。 然后又刷了 OpenAI Status 和社交网络，发现风平浪静。 退出账号重登，发现还是老样子。退出账号，切换了一个免… 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：开源项目与落地
  • 分类依据：内容涉及项目实践、创业、副业或变现
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/27 06:41:54