Codex 降智了吗？从体感回归到可验证修复

先说结论：“降智”是一个需要拆分的现象，不是目前已经被官方确认的单一结论。 同一句提示词有时变差，可能来自模型或路由变化，也可能来自服务事件、上下文膨胀、权限/网络失败、会话状态损坏，或者任务根本没有可执行的验收标准。

本文于 2026-10-03 整理。它汇总官方状态、官方模型与配置说明，以及 GitHub 和 Reddit 上的公开反馈；社区案例是线索，不是对所有账号、模型或套餐的统计结论。本文没有在读者账号上执行模型切换、升级、重置或发送反馈。

网络上到底出现了哪些证据

官方确认过服务层故障

OpenAI 状态页记录了 2026-09-29 一次影响 ChatGPT、Codex 和 API 的错误事件，受影响组件包括 Codex Web、Codex API、CLI 和 VS Code 扩展；状态页写明事件已恢复，但 RCA 仍需另行发布。在这种时间段里，失败请求、登录困难和任务不完成都可能被误认为“模型变笨”。

GitHub 反馈集中在“交付可靠性”

• openai/codex #42008 是一条 9 月 1 日提交的公开报告：作者描述同一机器和多项目中出现指令被忽略、代码无法运行、上下文丢失以及提前报告完成。它有具体环境和症状，但没有给出能证明模型路由或量化变化的对照实验。
• openai/codex #34971 记录了长会话中反复处理大块缓存上下文、超时、循环和额度消耗异常的个人数据。它说明“上下文管线可能让任务表现变差”是值得排查的假设，不等于所有用户都遇到同一根因。
• Reddit 的并行任务对照帖展示了同类任务一次完成、一次反复做小片段后提前结束的个人对照。它适合启发复现实验，不能作为产品级质量统计。

这些证据共同指向一个更准确的描述：很多人感受到的是指令遵循、持续执行和完成判定的可靠性下降，不一定是抽象推理能力整体下降。

先用 10 分钟判断是哪一层

不要立刻换模型、重装 CLI 或给出更高权限。先保存一份最小记录：日期和时区、客户端/CLI 版本、登录方式、模型、reasoning effort、任务目标、上下文大致长度、第一次失败的命令或工具、最终是否有可运行结果。

在 Codex CLI 中，官方建议用 /status 查看当前模型、审批策略、可写目录和 token 使用量，用 /debug-config 查看实际生效的配置层。也可以用一次性参数覆盖默认值：

codex --model gpt-6.1-sol
codex --config model_reasoning_effort='"medium"'

只有在你的客户端、账号和工作区提供该模型时才使用上面的模型名；否则从 /model 列出的可用项中选择。不要把命令能启动写成质量已经恢复。

然后用一个新会话做 A/B 对照：同一份小任务、同一组文件、同一验收命令，只改变一个变量（模型、reasoning effort 或是否新会话）。至少重复两次，记录：

• 是否完整读取并遵守 3 条关键约束；
• 是否完成所有阶段，而不是只做第一小片；
• 测试/构建是否真的通过；
• 是否出现重复工具循环、超时或无关改动；
• 从开始到可验收结果的时间，以及可得的 token/额度变化。

一次好回答或坏回答都不足以证明回归。把“模型输出差”与“服务事件”“上下文过长”“工具失败”分开记录。

立即可用的恢复方案

1. 先切到新会话，缩小上下文

长线程里已经反复失败时，不要继续叠加“再试一次”。新开会话，只带入：目标、当前状态、相关文件、失败命令、验收标准和明确的未完成项。大截图、整段日志和重复的工具输出改成摘要或文件路径，避免把历史噪音一起喂回去。

2. 明确选择模型和 reasoning effort

官方模型文档说明：可以在桌面端或 CLI 选择模型与 reasoning effort；更高 effort 可能改善复杂任务结果，但会增加时间和 token 使用。复杂的跨文件任务可以从可用的 GPT-6.1 Sol 或 Astra 开始；清晰、重复、范围小的任务可以使用 Luna。不要把“更贵”当作“必然更可靠”，用同一验收任务做对照。

如果仍在使用 gpt-5.5，要注意官方文档标明它将在 2026-10-14 从 ChatGPT、ChatGPT Work 和 Codex 退休；应提前在可用模型中选择替代项，并同步检查 workspace 默认值、保存的配置、custom agents 和自动化任务。

3. 把“完成”改成阶段性验收

给任务写成 3–5 个小阶段，每阶段都要有命令或页面证据：

目标：修复结账页在窄屏下的溢出。
范围：只改 app/checkout 和对应样式，不改支付接口。
步骤：先只读检查 -> 实施布局修复 -> 运行目标测试 -> 启动页面。
每阶段完成条件：贴出实际命令、退出码和关键结果。
最后必须：用 375px 视口复现原问题，确认 scrollWidth 等于 clientWidth。
未执行的检查写入“未验证”，不要写成完成。

这样可以把“模型说做完了”变成“读者能复核的交付”。

4. 把权限、网络和工具故障单独排除

如果命令被拒、网络超时、MCP 断开或文件不在工作区，模型可能只能生成计划，无法完成任务。记录完整错误和目标域名，先修复对应边界；不要为了验证智力而长期打开完全访问权限。恢复后从失败步骤继续，并重新运行原验收，不要只看新的文字回答。

5. 两次重复失败就停止循环

出现同一个错误两次，或模型连续两次声称完成但验收不通过时：保存状态、停止当前循环、新开会话、带最小失败复现。继续在污染上下文里追加指令，往往只会增加 token 和重复改动。

一份可长期使用的“降智”基准

在自己的项目里维护 5 个小任务，每个任务都能在 10–20 分钟内完成并自动验收，例如：修一个链接、补一个测试、改一个窄屏布局、解释一条日志、只读审查一个 diff。每周固定同一版本、同一模型/effort 和同一输入，记录：

指标	记录方式
约束遵循	3 条硬约束中完成几条
交付完整度	目标清单完成数 / 总数
验证通过	测试、构建或页面检查的真实结果
返工次数	因错误或假完成重新执行的次数
时间与用量	从开始到验收的时间；仅使用可得的 token/额度数据

连续 3 次同方向失败，才把它升级为可报告的回归；同时保留好运行和坏运行的完整对照。不要用主观“聪明/变笨”替代这些指标。

什么时候该向官方反馈

当你有了同一任务的好/坏对照、版本与模型、/status 输出、时间戳、失败命令和脱敏后的最小复现，再通过客户端反馈入口或官方支持渠道提交。删除 API Key、Cookie、真实业务数据、客户代码和本机绝对路径；不要把 Reddit 或 GitHub 的猜测写成根因。服务事件则先附上状态页事件时间，不要重复提交大量相同报告。

来源与边界

• OpenAI Status：2026-09-29 ChatGPT、Codex 与 API 错误事件：官方服务状态与受影响组件，核对日期 2026-10-03。
• OpenAI Models：选择模型、reasoning effort 与 5.5 退休安排：官方模型与配置说明，核对日期 2026-10-03。
• OpenAI Developer settings：/status、/debug-config 与 CLI 覆盖参数：官方配置排查方法，核对日期 2026-10-03。
• GitHub #42008、GitHub #34971、Reddit 对照帖：公开用户报告，仅作为线索和复现实验材料，不代表官方确认的普遍回归。