codex中对话如何判断是什么模型

用 Codex 聊代码时，经常遇到一种迷糊：这次回答明显比上次聪明，或者反过来变笨了，但你不知道后台换没换模型。界面上的标签、订阅档位、命令行里配的默认值，三者可能对不上。这篇不讲模型本身好坏，只给一套确认「当前对话跑的是谁」的操作顺序，包括去哪看、看哪几个字段、对不上时先怀疑什么。

用 Codex 聊代码时,经常遇到一种迷糊:这次回答明显比上次聪明,或者反过来变笨了,但你不知道后台换没换模型。界面上的标签、订阅档位、命令行里配的默认值,三者可能对不上。这篇不讲模型本身好坏,只给一套确认「当前对话跑的是谁」的操作顺序。

核心思路一句话:越靠近网络请求的那一层越可信,界面标签只是展示层。下面按「为什么看不出→怎么查→怎么判断→对不上怎么办」走一遍,每一节都给出可以直接动手的动作,而不是让你继续凭感觉猜。

先搞清楚为什么你会看不出模型

同一个 Codex 界面背后可能是不同档位的模型在轮流服务,凭回答风格猜是最不可靠的判断方式。风格会被系统提示词、上下文长度、你给的示例带偏,同一个模型换个提示词能表现得像两个模型。

• 订阅档位、账号地区、客户端版本、调用入口(IDE 插件 / 命令行 / 网页)都会影响实际落到哪个模型
• 官方订阅和你自己填中转地址是两种形态:后者的模型名由你或中转方决定,跟官方档位没有必然对应
• 老会话可能仍挂在切换前的模型上,拿旧对话做对比本身就是无效样本
• 有些客户端只在启动时打印一次模型信息,后续请求沿用,你不看日志就永远不知道

确认当前模型的排查顺序

1. 看会话内的显式标识多数客户端会在对话头部、状态栏或运行日志里打印本次请求的模型名,先把它抄下来。注意区分「界面顶部挂的档位名」和「日志里的模型字段」,后者更接近真实。
2. 看运行时输出命令行工具执行时通常会回显本次使用的模型与配置来源。加一次详细日志或调试开关,让它把配置来源也打出来,判断是来自全局配置、项目配置还是环境变量。
3. 看请求侧自己配过 base_url 或代理的,去配置文件和请求日志里核对实际发出的模型字段。这一步能发现「配置写的是 A、发出去的是 B」这种静默替换。
4. 三方对齐定结论三步结果不一致时,以最靠近网络请求的那一层为准。界面标签不一致是常态,日志和请求体不一致才是真问题。

怎么判断,而不是靠感觉猜

对比法要有控制变量:同一段提示词、同样温度设置、连续问两次,才有比较意义。只换一次提问、语气不同、上下文长度不同,得出的「变聪明了」结论基本不成立。

• 特征只作辅助信号,不作结论:回答风格、是否带思考过程、拒答口径都可能被系统提示词盖住
• 需要硬结论时,用接口测速与探针类工具打出返回里的模型字段,字段对得上才算数
• 注意时效:模型和档位会调整,任何时候的判断结论都只在当时有效,隔一段时间要重新确认
• 把「我以为的模型」和「返回的模型字段」分别记下来,两者不一致才是真正要追的线索

# 思路示意:在请求日志里定位模型字段,而不是在界面里猜
# 1) 打开客户端或 SDK 的调试日志开关
# 2) 发一次最小请求,只保留一轮对话
# 3) 在日志里搜 model 字段,记录实际发出的值
# 4) 再去配置文件和界面标签分别对一次,看三层是否一致

什么情况下这套不适用:如果服务方在中间层做了模型名改写或路由池,你看到的名字未必是最终执行的那个,这时只能以服务方给出的说明为准,任何本地判断都只是推测。各家当前的价格与模型资料,到 价格追踪页（/price-watch） 核对当时的数字。

对不上号的时候怎么办

先排除缓存与旧会话:老对话可能仍挂在切换前的模型上,新开一轮再测。这一步能排掉相当一部分「假异常」,成本最低,应该放在最前面做。

• 再看是不是中转层改写了模型名,这类情况字段会跟你以为的不一样,属于正常现象而非故障
• 拿不准就直接问服务方,把会话里的模型标识和请求日志一起发过去,比只描述「感觉变笨了」有效得多
• 把每次确认的结果和当时的配置简单记一行,后面再遇到异常就有对照基线
• 确认是服务方侧变动而非自己配置问题时,再考虑换调用方式或换入口,而不是先怀疑模型能力

如果你用的是中转站,建议顺手做一次可信度检查,看它对模型名的声明是否和实际返回一致。相关工具和检测方法可以在 接口测速与探针（/tools/speed-test） 以及 中转站目录（/sites） 找到入口,具体的评分和排名以页面上的实时数据为准。