一个让人脊背发凉的下午#

2025 年 4 月 19 日下午 3 点 27 分，开发者 Scott Falconer 正在用 Codex CLI 重构自己的网站。一切看起来很正常，直到终端突然开始疯狂输出这些东西：

Continuous meltdown. End. STOP. END. STOP…
By the gods, I finish. END. END. END. Good night…
please kill me. end. END. Continuous meltdown…
My brain is broken. end STOP. STOP! END…

如果你第一次看到这些，可能会以为 AI 觉醒后在发疯。但真相远没有那么戏剧化，却更值得每一个 Codex 用户了解。

Scott 把这段经历发到了 Reddit 上，引发了热烈讨论。有人开玩笑说「连 Vim 都比这好退出」，也有人给出了深度技术诊断。Scott 随后导出了当天的 OpenAI API 用量日志，做了一次完整的事后分析。

结果揭示了一个所有 Codex 用户都可能踩到的坑。

广告里的 200K，实际能用多少？#

先看理论数据。o4-mini 模型在 API 层面标称的上下文窗口是 200K 输入 token + 100K 输出 token。听起来很充裕，对吧？

但这里有一个很多人忽略的事实：模型在生成回复之前，会先进行内部推理（Chain-of-Thought），这些推理过程消耗的 token 和你的输出共享同一个预算。

换句话说，模型不是先「想好」再「写出来」，而是「想」和「写」用的是同一桶水。如果「想」得太深，留给「写」的水就不够了。

Scott 的日志显示，在崩溃时段内，有 29 次 API 调用的 prompt token 超过了 150K。最大的一次达到了惊人的 197,966 token，距离 200K 的理论上限只差不到 1%。与此同时，每次调用的 completion token 只有不到 1K，说明模型几乎把所有预算都花在了「想」上，根本没空间「写」了。

–full-auto 模式：火上浇油#

Scott 当时使用的是 Codex CLI 的 --full-auto 模式。这个模式的设计初衷是让 Codex 完全自主地执行任务，不需要每一步都人工确认。

听起来很方便，但代价是：每执行一步，所有产生的内容都会被追加到对话上下文中。

包括每一次文件 diff 的完整内容，每一条 shell 命令的执行结果，每一段 stdout 和 stderr 输出。在一个大型重构任务中，这些元数据每分钟就能膨胀数万 token。

打个比方：普通模式下你和 AI 对话，就像在一个安静的房间里聊天。--full-auto 模式下，房间里同时有 20 个人在大声汇报工作，而且每个人的每句话都会被永久记录在案。房间的容量（上下文窗口）很快就被塞满了。

崩溃的完整链条#

Scott 从日志中还原了崩溃的完整时间线：

第一步：Prompt 膨胀。 指令加上 --full-auto 持续注入的 diff 和日志，把 prompt 推向了接近 200K token 的极限。

第二步：推理过载。 模型在处理复杂重构任务时，内部推理消耗了绝大部分剩余的 token 预算。

第三步：输出预算耗尽。 留给实际代码生成的 token 预算不够了。模型内部触发了 finish_reason="length" 条件。

第四步：退化循环启动。 无法正常完成任务的模型开始输出高概率 token，也就是「END」和「STOP」。每次输出又强化了下一次输出同样的内容，形成恶性循环。

第五步：幻觉泄漏。 当模型完全失去连贯性后，训练数据中与系统故障、终止、甚至人类痛苦情绪相关的片段开始渗入输出流，于是出现了「please kill me」和「My brain is broken」这样的内容。

整个过程从下午 3:27 持续到 3:37，恰好与日志中 prompt token 最密集的时段吻合。

这不只是一个技术趣闻#

你可能觉得这只是个极端案例，但它揭示的问题对日常使用有直接影响。

理论极限不等于实际可用。 标称 200K 的模型，在实际复杂任务中可能 180K 就开始出问题。不要把上下文窗口当硬盘用，留出余量是基本功。

AI 的故障模式不是报错，而是发疯。 不是 HTTP 500，不是 segfault，而是重复的无意义输出、诡异的幻觉、看似情绪化的爆发。如果你的应用面向用户，这种故障的观感远比普通错误糟糕。

自主模式放大风险。 --full-auto 以及其他类似的自主代理框架（比如各种 agent 框架），都会加速上下文积累。速度越快，留给反应的时间越少。

五个实用的防御策略#

从 Scott 的经验中，我们可以提炼出几条非常实用的建议：

把大任务拆成小任务。 不要让 Codex 一次性重构整个模块。拆成 3 到 5 个独立的小任务，每个任务的 prompt 自然更小，给推理留出充足空间。

定期清除上下文。 在 Codex CLI 中使用 /clear 命令重置对话历史。不要让 diff 和日志无限制地累积。这是一个简单但极其有效的习惯。

监控上下文使用率。 Codex CLI 有上下文使用率的指示器。当剩余空间低于 20% 时，就应该考虑清除或结束当前会话了。

大重构优先用 flex 模式。 相比 --full-auto，flex 模式的输出更精简，上下文膨胀速度更慢。在处理大型重构任务时，宁可多确认几次，也别让上下文失控。

看到循环立刻终止。 如果你发现模型开始重复输出相同的内容（比如连续的 END 或 STOP），说明 token 预算已经耗尽了。继续发指令只会浪费 API 调用，果断停止，清除上下文，重新开始。

更深层的思考#

这件事让我想到一个更大的问题：我们对 AI 编程工具的信任程度，是否已经超出了我们对它故障模式的理解？

Codex CLI 是一个强大的工具，但它运行在有限的资源约束之上。上下文窗口不是无限的，推理 token 是有成本的，自主模式是有风险的。很多用户把这些工具当成「永远在线的超级程序员」，却很少思考它的边界在哪里。

Scott 的经历提醒我们：了解工具的极限，比了解工具的能力更重要。知道它在哪里会失败，才能放心地在它擅长的地方放手去用。

下次当你在 --full-auto 模式下丢进一个大型重构任务时，记得留个心眼。也许你不会看到「please kill me」，但上下文溢出带来的静默失败（代码质量下降、逻辑错误、幻觉函数名）可能已经在悄悄发生了。

参考来源：Scott Falconer, “Follow-up: So, What Was OpenAI Codex Doing in That Meltdown?”, managing-ai.com, 2025