Codex降智不是玄学：减少出错与重开对话时机

先说重点：

1. 在 AGENTS.md 文件中加入 DO NOT send optional commentary（全局或项目级均可），可有效降低 AI 降智的发生概率。
2. AI 与人相似，存在不稳定因素，但同时也具备创造力。它能完成纯机器无法实现的任务，关键在于找到两者之间的平衡点。
3. 遇到问题时，多思考一步，答案往往就隐藏在细节之中。

---

许多人感受到的所谓“降智”，未必是厂商真正调低了模型能力。更可能的原因是：在特定时刻、特定版本或特定上下文中，模型出错的概率有所提升。AI 不像传统软件那样稳定——同一段逻辑执行一百次，结果始终相同。但模型不同，它每一步都是在给定上下文中随机生成。状态良好时，就像与富有创意的同事协作；一旦状态不佳，错误便会连锁放大：前一次的错误解释、一次伪工具调用、一个未经验证的假设，都会被带入后续上下文，持续干扰后续判断。 因此，当 AI 偶尔出错时，最大的问题并非单次回应有误，而是错误内容会成为后续推理的“素材”。继续追问时，它会将之前的错误当作事实进行推导；要求修复时，它会围绕错误前提反复打补丁；提供更多上下文，反而给了它更多机会将噪音编织进新的解释中。这种现象，正是人们真实感受到的“降智”——或者用更形象的说法：鬼打墙。

DO NOT send optional commentary

今天在推上看到一个帖子，称只要在 AGENTS.md 中加入 DO NOT send optional commentary，就能显著改善 Codex 5.5 的降智表现。顺着线索查找，找到了 Linux.do 上的原始讨论。作者在自己的测试环境中确实看到正确率明显提升，但也反复强调：这只能缓解，无法根治。 这个发现与我的猜测不谋而合。这句话并非神奇咒语，它之所以有效，核心在于减少了模型的可选输出。Codex 在工作时，除了真正执行任务，还经常附带中间解释、进度描述、推测和总结。正常情况下，这些内容有助于沟通；但当模型状态不佳时，这些“可有可无的话”就可能成为污染源：它可能提前下结论，可能描述并未发生的步骤，也可能将工具调用与自然语言混在一起。 少说一句话，不会让模型变得更聪明；但减少无关上下文，确实能降低被自己误导的风险。

这并非 Codex 独有的问题

使用 Claude 时也遇到过类似的“变笨”问题：模型输出了类似工具调用的文本，而非正常执行预览流程；随后在这段对话中，同样的问题反复出现；直到另开一个新对话，问题才突然消失。这类现象说明，问题不仅出在模型推理环节，也可能存在于整个 agent 工具链中：模型、系统提示词、工具调用协议、上下文窗口、当前服务状态……任何一环稍有波动，都可能导致输出不稳定。 一旦出现这种信号，继续在同一个对话中追问或要求修改，往往不是在修复，而是在扩大污染。因为模型已将“刚才发生了什么”写入上下文，而那段记录本身可能就是错误的。

两个方向：预防与止损

第一类方法是降低出错概率。将项目规则写入 AGENTS.md，要求它先读代码再动手；减少不必要的 commentary；将大任务拆解为小目标；要求它运行测试并提供验证结果；对关键假设要求先确认。这些做法并非追求绝对可靠，而是减少模型在不确定情况下自由发挥的空间。 第二类方法是及时止损。当发现它反复修复同一个 bug、解释越来越长但代码毫无改进、输出格式开始异常、工具调用变为文本、或开始无视刚刚给出的约束时，就不要再强行补救。最有效的做法通常是重开对话，将目标、当前错误、关键文件、已验证的事实压缩为一段干净说明，再让新的上下文接手。 这也是 Agent 的优势所在：将产物落盘保存，通过多个对话完成任务。 将其视为工程卫生问题更为准确：上下文脏了，就清理上下文；任务太大，就拆小；输出开始自我污染，就切断污染链。

结论

Codex 降智并非玄学，也不是一句提示词就能彻底解决的问题。它更像一个概率问题叠加了上下文问题：某些时候模型更容易出错，而错误的输出又让后续更容易继续出错。 DO NOT send optional commentary 这种方法值得尝试，成本低，副作用也明确：中间说明会少一些。但真正关键的是工作流习惯。能够减少噪音时就减少噪音，能够验证时就验证；一旦开始鬼打墙，就不要恋战，换一个干净对话重新开始。 如果各位有更好的经验，欢迎分享。对 AI Agent 使用、Vibe Coding 有任何问题，也欢迎留言讨论。