最近这个月，我把日常干活的工具从 Claude Code 整体迁到了 Codex。一开始用 GPT-5.6 Sol，等 GPT-6 Astra 发布之后又换了过去。迁移之前，我也经常使用 Codex 做代码审核和部分开发任务，GPT-6 各项 benchmark 又很强，所以本来以为带着在 Claude Code 上积累的 Skills 和各种记忆迁过去，应该会很顺利。
结果完全出乎意料，各种问题接连冒出来：修改范围失控、子 Agent 失败后假装完成、模型失败不重试等等。让 Codex 帮我扫了一下最近的会话历史，结合 OpenAI 官方的指南，今天就来分享这里面的经验教训。
1. GPT-6 对最后的指令非常敏感，不限定范围就会跑偏
我让它改一份设计文档里的一句话，交回来一看，整个文档的句式全变了。一开始我以为是模型把局部反馈当成了全局指令，扫完会话历史才发现更微妙：那份文档里的祈使句本来就散落在各个章节，我让它做局部修订的时候，它把“简洁清晰”这个要求理解成了整篇的写作方向，顺手把其他段落也改了。改完之后回复里写的是“读者视角核对完成”，实际上只处理了局部的理解障碍，全文的文体一致性根本没检查。
这条对 Astra 尤其明显。如果你没有显式写清楚“只改这里、其他不动”，它就会按自己的理解扩大执行范围。
2. 子 Agent 失败后不会自动重试，也不会读取之前的进度
子 Agent 撞上 429 限流之后，父 Agent 有时候会发定向重试，但更多时候是直接跳过。更夸张的情况是：子 Agent 状态标着 completed，返回内容只有一句“我会先读取规则，再检查……”，实际审查结果一个字都没有。父 Agent 看到 completed 就以为这步做完了，接着往下走。
3. 429 失败后配置的重试根本不生效，Codex 会直接退出任务
Agentic 会话的 token 消耗跟普通聊天完全不是一个量级，特别是我的日常工作还经常需要调度多个子 Agent 完成复杂任务，所以也经常碰到限流错误。为了让 Goal 能够在我不在的时候正常执行下去，我甚至把重试次数增大到了 30，结果还是经常碰到“正在重新连接 1/30，exceeded retry limit, last status: 429 Too Many Requests”这样的错误。查了源码才发现，Codex 压根就不重试 429 错误，碰到之后直接中止任务。
能做的事情不复杂：限制并发子 Agent 的数量，不让它一下子启动过多的并行任务；日常任务把 reasoning effort 从 max 降到 high，大部分任务也都足够用了。
4. 模型变强之后，旧规则的代价反而变大了
GPT-6 之前的提示词，大部分在做一件事：补模型能力。“记得跑测试”“先想清楚再动手”“不要擅自扩大范围”，本质上都是在提醒模型做它自己想不到的事。Astra 不需要这种提醒了，这些行为它已经内建了。
反过来也有问题。之前为了防模型乱来写的硬边界，比如“未经许可不要修改其他文件”，Astra 会当真。它比 Sol 更倾向于完成初步实现就停下来等你审查，而不是一口气干到底。如果你的 AGENTS.md 里还有“每步都停下来确认”，它会比你想象的更频繁地停下来。
提示词的职责变了，从“补能力”变成“划边界、定完成标准”。所以，我们该做的不是加规则，是减规则。
5. Skill 描述越宽泛，越容易加载错误的上下文
Skill 多了之后，Codex 会压缩描述来腾空间，模型看到的信息反而更少，更容易选错 Skill。
比如 OpenAI 官方文档列了一个典型的反模式：Use when working with databases, queries, models, or persistence，这种描述太宽了，任何沾数据库的任务都会触发。正确写法是：Use when adding or changing a migration, or reviewing its rollout，只在真正需要的时候才加载。
6. AGENTS.md 应该做路由器，不是百科全书
不要写“每次编辑前先读 architecture.md、database.md 和 deployment.md”，应该改成按需索引：改 schema 的时候才读 database.md，准备部署的时候才读 deployment.md。每次都全量加载就是在烧上下文，跟当前任务无关的指导越多，就越容易干扰结果。
以前很多 Skill 写得像详细的菜谱，每一步都写死。GPT-6 Astra 对细微差别和模糊性的理解比之前好很多，过于具体的指导反而会限制它的能力。
7. Astra 偏保守，需要你明确授权安全的工作流
Sol 接到任务之后一口气干很久，Astra 不一样，它更倾向于完成初步实现就回来让你审查，哪怕后面还有活没干完。官方的建议是在任务开始之前就把“完成”的标准写清楚。如果你希望它做完之后自己跑测试、检查结果、修复问题，就在请求里把这些步骤明确写出来。
对于那些你确认安全的操作，可以在 AGENTS.md 里明确授权，比如：
The local tests use disposable fixtures and have no production access. Run them, fix failures caused by the requested change, and rerun affected tests without asking for approval at each step.
这样模型就不会每跑一次测试都停下来问你了。
8. 写作质量差不是措辞问题，是没给好样本
这是在写文档时碰到最多的问题。GPT-6 把“解释完整、结构整齐、边界周全”当成写得好，但你要的往往是准确表达一个观点，让读者知道它为什么重要。在 AGENTS.md 里加一条“不要有 AI 味”没什么用，模型不知道什么算 AI 味。
有效的做法是先给它一个你认可的样稿，让它对齐调性，确认之后再往下写。如果是长文，先让它写一小段样稿给你看，调性对了再扩展全文，省得整篇推倒。另外一个经验是，把“观点是否正确”和“表达是否自然”分开检查，不要用润色掩盖主题跑偏。
9. 不用自己逐条排查 AGENTS.md，让模型审计自己的规则
AGENTS.md 和 Skills 越积越多，哪些过时了、哪些互相冲突、哪些触发范围太宽，自己一条条排查很痛苦。直接让 GPT-6 Astra 做一次只读审计就行，重点让它检查这几类问题：相互矛盾的要求、适用范围错位的 Skill 描述、无条件加载的文档、固定多轮审查流程，以及把临时环境问题写成永久规则的情况。
让它按“保留、收窄、移到专用流程、改成脚本检查、待验证后删除”这几个级别给建议。注意一点：不要因为新模型更强就默认删除权限和安全相关的约束，这些该留还是得留。
10. 跨模型兼容性：你的 Skills 会被不同模型调用
这条容易忽略。如果你的 Skills 会被多个模型甚至多个 Agent 同时调用，比如经常在 Codex 和 Claude Code 之间切换，一定要注意验证不同模型上的行为。就像我碰到的，给 Claude Code 写的 Skills 直接挪到 GPT-6 上会过度约束模型的能力，导致质量大幅下降。
如果 Skills 中某条规则是针对特定模型的行为写的，标注清楚它的适用范围，或者拆成条件加载：只在用某个模型的时候才生效。不要假设所有模型的行为都一样。
好了，今天就聊到这儿。如果你也关注 AI 编程，欢迎来 云栈社区 一起交流这些工具的实践经验。
发表于 14 小时前
|
查看: 4|
回复: 0
