Codex 降智不是玄学：如何减少出错，以及何时该重开对话

先说重点：

1. 在你的 AGENTS.md 里加入 DO NOT send optional commentary，无论是全局还是项目级均可，可以减少“降智”的几率。
2. AI 跟人一样，不稳定，但是有创意。能解决纯机器无法解决的问题，我们要做的事情是在两者间找到平衡。
3. 面对问题，深入想一想，说不定能找到解决方案。

---

我认为，很多人感受到的「降智」，并不是厂家真的调低了模型的能力，而是某个时刻、某个版本、某个上下文里，模型出错的概率变高了。AI 不像传统程序那样稳定，执行同一段逻辑就是同一个结果；它每一步都是在某个上下文上随机生成。正常时这很像协作，出错时就会变成放大器：前面一次错误解释、一次伪工具调用、一次没验证的假设，都会进入后面的上下文，继续影响下一次判断。

所以当 AI 偶尔犯错，最大的麻烦不是这一条回应有问题，而是错的内容会成为后续回答的材料。你继续追问，它可能会拿刚才的错误当成事实继续推理；你让它修复，它可能会围绕错误前提反复打补丁；你给它更多上下文，它反而有更多机会把噪音织进新的解释里。这就是很多人感受到的“降智”，或我喜欢说「鬼打墙」。

DO NOT send optional commentary

今天我在推上看到一个帖子，说只要把 DO NOT send optional commentary 添加到 AGENTS.md 就能极大改善 Codex 5.5 的降智表现。

我顺藤摸瓜，找到 Linux.do 上的原始讨论。作者在自己的测试环境里看到正确率有明显提升，但也反复强调这只能缓解，不能根治。

我认为这个现象和判断跟我的猜测不谋而合：这句话的并非什么神奇咒语，它能起作用，是因为它减少了模型的可选输出。Codex 工作时，除了真正执行任务，还常常会补充中间解释、进度描述、推测和总结。正常情况下这些话有助于沟通；但当模型状态不好时，这些「可有可无的话」也可能变成污染源：它可能提前下结论，可能描述并没有真正发生的步骤，也可能把工具调用和自然语言混在一起。

少说一点，不会变得更聪明；但少一点无关上下文，确实可能少一点被自己带偏的机会。

这不是 Codex 独有的问题

我用 Claude 时也遭遇过变笨问题：模型吐出了类似工具调用的文本，而不是正常继续执行预览流程；然后在这个对话中，同样的问题反复出现；直到我换到另一个对话，问题突然就消失了。这类现象说明问题不只在某个模型思考时，也可能发生在 agent 工具链里：模型、系统提示词、工具调用协议、上下文窗口和当前服务状态，任何一环抖一下，都可能让输出开始不稳。

一旦出现这种信号，继续在同一个对话里追问、要求修改，常常不是修复，而是在扩大污染。因为模型已经把「刚才发生了什么」写进了上下文，即使那段记录本身就是错的。

两个方向：预防，和止损

第一类方法是降低出错概率。把项目规则写进 AGENTS.md，让它先读代码再动手；减少不必要 commentary；把大任务拆成小目标；要求它跑测试、给出验证结果；对关键假设要求先确认。这些做法都不是为了让 AI 绝对可靠，而是减少它在不确定处自由发挥的空间。

第二类方法是及时止损。看到它反复修同一个 bug、解释越来越长但代码没有变好、输出格式开始坏掉、工具调用变成文本、或者开始无视你刚刚给的约束，就不要继续硬救。最有效的做法通常是重开对话，把目标、当前错误、关键文件、已经验证过的事实压缩成一段干净说明，再让新的上下文接手。

这也是 Agent 的优势：把产物落盘保存，使用多个对话来完成任务。

把这当成工程卫生会更准确：上下文脏了，就清理上下文；任务太大，就拆小；输出开始自我污染，就切断污染链。

结论

Codex 降智不是玄学，也不是一句提示词能彻底解决的问题。它更像一个概率问题叠加上下文问题：某些时候更容易错，而错的输出又会让后面更容易继续错。

DO NOT send optional commentary 这种做法值得试，因为成本低，副作用也清楚：中间说明会少一些。但真正重要的是工作流习惯。能减少噪音时就减少噪音，能验证时就验证；一旦开始鬼打墙，不要恋战，换一个干净对话重新开始。

如果各位读者有更好的经验，欢迎分享。如果你对 AI Agent 使用、Vibe Coding 有什么问题，欢迎留言讨论。