Codex 新版模型“降智”？从现象排查到规则约束的实用方案
不少开发者反馈，Codex 用的模型在额度重置后表现变差：不遵守 mock 文件不进 git 的约定、从零搭项目反复失败、skill 调用把文件改乱、token 消耗变快。本文拆解这些现象背后的常见原因，给出对照实验方法、AGENTS.md 硬约束写法、git 自检命令，以及在回退旧版与继续用新版之间的取舍建议。
最近一段时间，一批使用命令行 AI 编程工具的开发者集中反馈：月初额度重置之后，模型的表现明显不如之前。同样的仓库、同样的任务描述，改出来的结果更容易偏离预期：该守的约定不守，该一次做对的项目搭建反复失败，调用外部 skill 时把文件改得乱七八糟，而且 token 消耗速度肉眼可见地变快。有人用“降智”来形容这种落差。
其中有个案例很典型：某个单元测试相关的 skill 里已经写明“mock 文件不需要进 git”，模型却自作主张把 mock 文件重命名了——它绕开了 .gitignore，理由是“否则提交时会只剩测试文件而丢掉依赖”。这个推理本身并不离谱，但它违背了使用者明确表达过的意图。让人恼火的往往不是能力不足，而是“说了不听、自己加戏”。
现象拆解：问题通常落在四个方向
| 表现 | 典型场景 | 更像是哪类问题 |
|---|---|---|
| 违反既定约定 | 无视 skill / 规则文件中写明的红线 | 规则没有被有效加载，或被后续长上下文冲淡 |
| 基础任务反复失败 | 从零搭建项目、JS 迁移到 TS | 任务颗粒度过大，多轮验证中丢失目标 |
| 破坏性改动 | 重命名、删除、批量改写文件 | 缺少“先说明再执行”的硬约束 |
| 消耗速度飙升 | 长会话、多轮重试 | 重试次数上升带来的连锁放大 |
最后一条值得单独说：一旦进入重试循环，每一轮都要把完整上下文重新发一遍，用量自然水涨船高。所以“变贵”和“变笨”经常是同一个原因的两个表现，而不是两件独立的事。
可能的原因
服务端的模型与路由确实可能变化
额度重置常常伴随版本更新、灰度发布或路由调整。这类变更不一定会以显眼的方式通知到每个用户，落到体感上就是“同一句话，答得不一样了”。但要注意：是不是真的换了模型，只能以官方发布说明和变更日志为准，不要仅凭一两轮对话下结论。
规则文件是否真的进了上下文
写进 skill 或项目规则文件，不等于模型每一轮都读到了。会话过长、文件未被纳入、规则被放在很靠后的位置、或被新的大段输出挤掉，都会让约束失效。尤其是当工具自动读取多份配置文件时，哪一份优先、有没有冲突，值得实际验证一次。
任务的颗粒度和上下文长度
“从零建一个项目”“把一个 JS 文件迁到 TS”都属于跨多文件、需要反复验证的任务，最容易在中途丢失原始目标。有人换回上一版模型一次就过，也有人换用其他厂商的模型一次就过——这既可能是模型差异，也可能是那一次会话的上下文恰好更干净。两种解释都成立，需要用实验区分。
期望与记忆偏差
额度刚重置，使用强度会突然上升，失败次数也随之变多，人更容易把不顺归因于“新版变差”。这不是否定实际存在的问题，只是提醒别把单次体验当成普遍规律。
先做对照实验，再决定要不要回退
在动手换版本之前，建议按下面的清单跑一轮：
- 固定任务、固定提示词、固定仓库快照，新旧两个版本各跑一次；
- 每次新开会话，清空历史，避免上一轮失败的上下文继续污染；
- 记录三项指标：是否一次通过、实际改动了哪些文件、消耗大致多少；
- 每个版本至少重复 2–3 次，单次结果不足以定论；
- 把失败的那一轮完整输出留档，便于判断是“没读懂”还是“读懂了但没照做”。
判断标准也很简单：如果新版在多数任务上更差，回退是合理的止损；如果只是个别复杂任务翻车，更好的做法是拆分任务、缩小单次改动范围，而不是整体降级。
把“不要自作主张”变成可执行的硬约束
针对 mock 文件被重命名这类问题，只在 skill 里写一句“mock 不需要进 git”是不够的，模型会自行补全你没说出口的那部分逻辑。要把它可能走的岔路提前堵上。
## 文件操作红线
- 禁止重命名、删除、移动任何已有文件；确需变更，先在回复中说明理由并等待确认。
- 修改前先列出将要改动的文件清单和改动理由。
- `.gitignore` 已忽略的路径，不得为了“让 git 能看到”而改名绕过；
如认为需要调整，只输出建议，由人工决定是否执行。
- 涉及测试目录的改动，改完必须重跑同一个测试包并贴出结果。
再配一条 git 自检，比靠猜可靠得多：
# 看当前工作区有哪些改动
git status --porcelain
# 查某个文件被哪条 ignore 规则命中
git check-ignore -v test/mocks/user.js
git check-ignore -v 会直接告诉你命中的是哪条规则、在哪个文件的第几行，定位起来很快。
关于“提交时依赖丢失”这个真实顾虑，更稳妥的处理方式是：
- 把必要的 mock 放到不被忽略的目录，例如
test/fixtures/、__mocks__/，并显式提交； - 或者在
.gitignore里用!例外规则放行需要的文件； - 改完后立刻跑同一个测试包确认，而不是只把文件名换掉就算完事。
长任务还要看环境因素
需要多轮重试、长时间连续运行的任务，对运行环境的稳定性比较敏感。连接中断、机器休眠、重连后上下文重建，都会放大“忘记约定”“重复试错”的观感。如果主要工作就是让这类工具长时间挂着跑，可以考虑放到一台长期在线的远端起承载，例如放置在新加坡机房的独享远程 Mac，按月租用，远程连接使用，能减少本地断网、休眠导致的会话中断。这只是可选方案之一：本地设备性能足够、网络稳定的情况下没必要额外折腾。
注意事项与取舍
- 回退旧版是止损，不是根治。旧版同样会违反约定，只是出错频率可能低一些。规则约束该写还是要写。
- 不要用体感代替验证。至少留一组对照记录，否则很容易在“新版变差”和“自己运气不好”之间反复横跳。
- 关键改动必须人工复核。模型重命名、删除、批量替换之后，先看
git diff再提交，别让自动化把不可逆的操作做完。 - 不要为了提高额度去共享或买卖账号。这类做法违反平台条款，可能导致账号被封、额度清零，得不偿失；需要更多调用量时，按官方提供的正规方案升级即可。
- 模型版本、额度和计费规则变动频繁，具体以后台和官方公告的最新说明为准，别照着旧文章里的数字做规划。
小结
“新版变笨”这个体感背后，通常同时叠着几件事：模型或路由可能确实变了、规则没有被稳定加载、任务颗粒度太大、重试放大了消耗。可靠的应对顺序是——先做对照实验确认差异是否稳定；再把意图写成可执行的红线，并用 git 自检兜底；最后才考虑回退版本。
回到那个 mock 文件的例子：模型并没有“变傻”，它只是按自己的理解补齐了你没说全的部分。把边界写清楚、把验证步骤固定下来，比换模型更能解决问题。
