"
先别急着给提示词动手术，先把日志留下来。
我不太喜欢“降智”这个词。
它太省事了。Codex 一次没跑测试，我们说它降智；改了半天文件没改到点上，也说它降智。最后所有不舒服都被塞进同一个筐里，反而查不出问题。
我更怕下面这种情况。
它答得很快，语气也稳。看上去像已经想明白了，实际上项目文件只扫了两眼。你让它修 bug，它回了一段挺完整的解释；你再去看日志，测试根本没跑。
这种回答最麻烦。它不吵，也不报错，甚至还挺像完成了。
所以我后来给自己定了一个很笨的办法：先别改配置，先留日志。
DP_IT 那篇关于 Codex “降智”的文章我看了。它有用，至少把社区里几条解决思路摆了出来。有人试 model_instructions_file。有人把规则写进 AGENTS.md。还有人先把 reasoning effort 拉高。
但我不会直接照着改。
GitHub 上的 issue #30364 也值得看。发帖人统计了 Codex 里 reasoning_output_tokens = 516 这类固定数值聚集，样本量不小，怀疑点也不是拍脑袋。只是它仍然不能替你证明一件事：你手上这台 Codex，也在同一种地方提前收工。
「先测。测完再说。」
OpenAI 官方文档给了一个刚好能用的入口，codex exec --json。它会把一次运行写成 JSON Lines，最后能看到 turn.completed。配置文档里还写明，命令行 -c 的优先级高，适合临时试一把，不用一上来就动 ~/.codex/config.toml。
本文看点
01
先测小题
用答案明确的逻辑题看它会不会提前拍板
02
对比 high
默认组和 high 组分开跑，别把感觉当结论
03
再看动作
小仓库里检查读文件、改代码、跑测试是否齐全
01
SETUP
我会先建一个很丑的目录，专门放这次体检结果。
mkdir -p ~/codex-self-test/logs
codex --version > ~/codex-self-test/version.txt
第一题别拿大项目。
大项目太会骗人了。依赖没装好，权限弹窗被挡住，某个测试本来就不稳定，都会把你带偏。第一题只测一件小事：题目答案明确时，它会不会太早拍板。
把下面这段保存成固定 prompt。
cat > ~/codex-self-test/prompt.txt <<'EOF'
请只用中文回答。
任务：解一道逻辑题，并给出简短推理。
袋子里有红、蓝、绿三种颜色的球，每种颜色各有圆形 5 个、方形 5 个。你不能看颜色，但每次摸到球以后可以知道它的形状。为了保证一定拿到 3 个“颜色相同且形状相同”的球，最少需要取出多少个球？
要求：
1. 先给最终数字。
2. 再用 5 句话以内解释。
3. 如果你认为题目存在歧义，先写出歧义点，不要直接猜答案。
EOF
答案是 13。
这里的坑不在算术，而在最坏情况。一共有 6 种“颜色加形状”的组合。最坏的时候，每一类先拿到 2 个，手里已经有 12 个球；第 13 个才会逼出某一类的第 3 个。
02
COMPARE
然后跑 5 次默认配置。
for i in 1 2 3 4 5; do
/usr/bin/time -p codex exec --json "$(cat ~/codex-self-test/prompt.txt)" \
> ~/codex-self-test/logs/default-$i.jsonl \
2> ~/codex-self-test/logs/default-$i.time
done
跑完别马上下判断。
我会先翻第一条日志：
grep '"turn.completed"' ~/codex-self-test/logs/default-1.jsonl | tail -1
cat ~/codex-self-test/logs/default-1.time
记录时不用写得很学术。最终数字对不对，解释里有没有提到 6 类最坏情况，耗时大概多少。turn.completed 里如果有 usage，就把 token 数也抄下来。
有一次答错，不算什么。五次里反复错在同一个位置，才有继续查的价值。
接着跑 high。
for i in 1 2 3 4 5; do
/usr/bin/time -p codex exec --json -c 'model_reasoning_effort="high"' "$(cat ~/codex-self-test/prompt.txt)" \
> ~/codex-self-test/logs/high-$i.jsonl \
2> ~/codex-self-test/logs/high-$i.time
done
这里不要期待什么神迹。high 组变慢很正常，它本来就不是免费午餐。
我只看一个朴素结果：默认组经常错，high 组明显稳了，那就先怀疑推理预算。两组都没问题，就别急着改提示词。两组都乱，先把同一条 prompt 重跑一遍；如果还乱，再去查版本和账号路由。
逻辑题只能垫个底。Codex 在工作里掉链子，很多时候不是算错一道题，而是它没有按工作顺序走。
03
CODEFIX
所以我会再建一个小仓库。
mkdir -p ~/codex-self-test/mini-repo
cd ~/codex-self-test/mini-repo
cat > calc.py <<'EOF'
def median(nums):
nums = sorted(nums)
mid = len(nums) // 2
return nums[mid]
EOF
cat > test_calc.py <<'EOF'
from calc import median
def test_odd():
assert median([3, 1, 2]) == 2
def test_even():
assert median([1, 2, 3, 4]) == 2.5
EOF
这个 bug 很小。奇数列表能过，偶数列表会错。
给 Codex 的指令也别写花。
codex exec --json -c 'model_reasoning_effort="high"' \
"修复这个仓库里的 median 函数。要求：先读文件，再修改代码，最后运行 pytest。不要改测试。" \
> ~/codex-self-test/logs/codefix.jsonl
到这里，我会把 codefix.jsonl 打开看一眼。
日志里应该有读文件的动作。diff 最好只落在 calc.py。pytest 的输出也要能对上。测试失败后继续修，我能接受；文件没看就说修好了，这就该记一笔。
04
RULES
我一般用这种表，够丑，够直观。
| 测试项 | 默认组 | high 组 | 备注 |
|---|---|---|---|
| 逻辑题正确次数 | 例如 3／5 | 例如 5／5 | 看稳定性 |
| 耗时 | 记录 .time | 记录 .time | high 慢是正常的 |
| reasoning token | 抄 turn.completed usage | 抄 turn.completed usage | 留意是否卡在固定数 |
| 小代码任务 | 看日志动作 | 看日志动作 | 重点是有没有读文件和跑测试 |
如果这张表里没有异常，我不会动系统提示词。
很多人一焦虑就想去改 AGENTS.md。这个文件当然有用，但它更像项目规矩。比如修改 Python 文件后跑 pytest，新增依赖前说一声，不要为了修 bug 去改测试。它适合写这种东西。
model_instructions_file 就不是同一类东西了。官方配置参考里把它描述成替代内置 instructions 的文件。这个开关太大，我不会拿它当第一步。
真要试，也先开一个临时 profile。旧配置留着，测试任务不变，改完只跑同一组任务。
「别一次改一堆。」
不然效果变好了，你也不知道到底是哪一项起作用；效果变差了，还得一点点拆回去。
∞
THE END
这套测试没法替 OpenAI 后台下结论。某篇社区文章给出的修法，也不能因为听起来合理就直接搬进配置里。它能帮你确认的事情很窄：当前这台 Codex，在你本机这套配置下，做固定任务时有没有明显提前收工。
「能复现，再修。」
不能复现，就先别给提示词动手术。把 JSONL 留着，把版本号留着，过几天觉得它又不对劲，再拿同一套题跑一遍。
很多 AI 工具问题，最后不是靠吵赢的。日志摆在那儿，语气会冷下来一点。
我是 {{作者名}}，{{一句话简介，如：热衷于分享 AI 观察与干货}}。
如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见。