大家好，我是 Ai 学习的老章
这两天 Codex 社区有个 issue 吵得挺凶
核心就一个问题：明明选了 gpt-5.5 + xhigh，为什么有些复杂任务只想了一小会儿，就直接给答案了
更刺激的是，很多本地日志里都出现了同一个数字：516
发生了什么
GitHub 上有人开了一个很硬核的 issue，标题大意是：gpt-5.5 在 Codex 里出现了 516 / 1034 / 1552 这类固定推理长度聚集，可能和复杂任务表现下降有关
这个 issue 到我写稿时还开着，作者扫了 2026 年 2 月 1 日到 6 月 27 日之间的 Codex 本地记录，一共分析了 390,195 条响应级别的 token 记录，覆盖 865 个 session
最扎眼的几组数字是：
指标
数值
总响应记录
390,195
session 数
865
正好等于 516 的事件
3,363
gpt-5.5在所有响应里的占比
19.3%
gpt-5.5 在 516 事件里的占比
82.0%
gpt-5.5 的 516 / 大于等于 516 比例
44.0%
非 gpt-5.5 的 516 / 大于等于 516 比例
1.3%
这组数据看完，第一反应就是：这不像自然波动
因为复杂任务的推理长度，正常应该跟任务难度、上下文、工具调用、输出结构一起变化
如果某个模型大量卡在同一个点，尤其还集中在 516、1034、1552 这种固定位置，就值得认真查
516 为什么刺眼
作者的说法：Codex telemetry 里出现了一个 gpt-5.5 特有的固定 token 聚集异常，看起来像某种阈值化的推理预算行为
这个表更能说明问题：
模型
响应记录
516 / 大于等于 516
gpt-5.5
75,401
44.0%
gpt-5.4
25,214
19.8%
gpt-5.2
247,575
0.34%
gpt-5.3-codex
13,333
0.0%
gpt-5.3-codex-spark
26,179
0.0%
更麻烦的是，516 聚集变强的同时，整体推理强度还在下降
2026 年 5 月，516 聚集比例冲到 53.30%，但平均推理 token 只有 106.9，P90 只有 344
如果只看体感，用户会觉得“模型变快了”
但如果复杂任务也这么快，那就很危险
快，有时候是聪明
有时候是提前收工
最有意思的糖果题
这个 issue 还关联了另一个更早的复现实验
测试题大概是这样：袋子里有苹果、桃子、西瓜三种糖，每种糖有圆形和五角星两种形状，形状可以靠摸出来，味道不能靠摸出来
问题是：至少摸多少颗，才能保证同时拿到不同形状的苹果和桃子
正确答案是 21
可怕的地方来了
在 gpt-5.5 + xhigh 的几次 fresh conversation 里，有些运行直接进入最终回答，没有中间进展提示，十几秒就结束，最终答成了 29
而这些错误运行，本地日志里都是：
reasoning_output_tokens: 516
phases: ["final_answer"]
成功运行则明显不同
它会先发出短暂进展提示，继续想更久，推理 token 上千甚至几千，最后答出 21
这个对照很有杀伤力
因为它把抽象的 token 异常，落到了一个具体任务上：短路径更容易错，长路径更容易对
评论区已经变成复现实验场
这条 issue 现在有 100 多条评论，很多人都在贴本地复现结果
有人用 codex-cli 0.142.5 跑糖果题，9 次可见结果里只有 3 次正确，错误运行全部落在 516 或 1034
也有人贴出两台机器的本地日志：gpt-5.5 的 516 / 大于等于 516 比例分别接近 50.1% 和 47.9%
还有人补充了一个很关键的观察：这些数字像一把梳子
516 只是第一档
还会出现：
516
1034
1552
2070
2588
3106
它们之间的步长是 518
所以有人把这个模式叫做 518n - 2
评论里也有人贴了本地统计图，整体看起来确实不像一个孤立偶发问题：
当然，这里必须加一句冷水
看到 516，不等于这次回答一定错
评论里也有人提醒，516 可能只是某个量化后的正常停止点，只有 OpenAI 内部才能确认真实原因
但问题在于：当它频繁出现在复杂任务里，并且和错误答案、快速结束、无中间进展同时出现时，用户就很难安心
临时绕法靠谱吗
评论区给了不少临时办法
第一类是提示词绕法
比如让模型“慢慢想”“至少思考 60 秒”“复杂任务要充分验证”
有人反馈有缓解，也有人说效果有限
这类办法我会当成止痛片
能用，但不要当根治
第二类是改 Codex 的基础指令
有人认为问题和 Intermediary updates 相关，也就是 Codex 要求工作中定期发进展提示的那段指令
有用户把这段删掉后，糖果题 20 次全对，且没有再出现 516、1034、1552
但也有人说，在真实工作里这个办法只能缓解，后面仍然能看到 516
所以我的判断是：这个绕法对某些测试有效，但目前还不能证明它能覆盖真实编码任务
第三类是本地代理或插件
有用户做了本地代理，检测到 518n - 2 这类可疑停止点时，让模型继续想一轮，再把结果合并给 Codex
也有人做了 hook 插件，在高风险回合结束时提醒用户，避免把可疑回答直接用于复杂重构
这类方案思路更工程化，但也更折腾
普通用户短期可以先不碰
我建议怎么用 Codex
如果你现在重度用 Codex，我建议先做几件事
下面这张图，把我的处理顺序简单画出来：
第一，复杂任务不要盲信第一次答案
尤其是架构设计、数据库迁移、权限改造、支付流程、安全修复这种任务
如果它十几秒就结束，还没有明显的探索、检查、运行测试过程，要多留个心眼
第二，关键任务要求它实际验证
不要只让它“解释一下”
直接要求它跑测试、读日志、复现错误、对比输出
只要能落到真实文件、真实命令、真实结果，幻觉空间就会小很多
第三，能用 5.4 或 Codex 专用模型做交叉检查时，就交叉一下
这个 issue 里的数据看，gpt-5.3-codex 和 gpt-5.3-codex-spark 没有出现同样的 516 聚集
gpt-5.4 也有一定比例，但低很多
如果你手上有多个模型可选，复杂任务可以让另一个模型复核关键结论
第四，别把“xhigh”当成保险箱
这次最尴尬的地方就在这里
用户以为自己选了最高思考档位，结果本地记录却显示一些回合非常短
在官方给出解释前，我会把 xhigh 当成倾向设置，别把它当绝对保证
这事真正值得关注的地方
我觉得这个 issue 最有价值的地方，不只是吐槽某次回答错了
它把 AI 产品一个很隐蔽的问题暴露出来了：用户看见的是“模型名”和“思考档位”，实际发生的是一整套运行时策略
里面可能有路由、预算、缓存、调度、前端流式处理、工具协议、基础指令
任何一层变化，都可能影响最终质量
对于用户来说，最难受的是不可解释
你明明付费选了更高档位，却不知道这次到底有没有真正多想
你明明让它做复杂任务，却不知道它是认真检查完才给答案，还是在某个固定位置提前结束
所以我更希望 OpenAI 做两件事
第一，确认 516 / 1034 / 1552 / 2070 这些固定值到底意味着什么
第二，给复杂任务一个更透明的质量信号
哪怕不暴露内部推理，也至少应该让用户知道：这次回答有没有完整走完预期的高强度路径
热门跟贴