先说核心要点：
- 在项目的
AGENTS.md文件中加入指令DO NOT send optional commentary（全局或项目级均可），这能显著降低模型“降智”情况的发生频率。 - AI 模型与人相似，存在不稳定性，但同样富有创造力。它能完成纯机器逻辑无法处理的复杂任务。我们需要做的，是在确定性与不确定性之间找到最佳平衡点。
- 遇到难题时，不妨多思考一层细节，答案往往就隐藏在这些细节之中。
许多用户感知到的所谓“降智”，其实未必是厂商主动调低了模型参数。更可能的原因是：在特定时刻、特定版本、特定上下文语境中，模型出错的概率有所上升。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 有任何问题，也欢迎留言讨论。