交了200刀的学费，我总结了Codex的15个技巧
公众号名称：歪斯Wise
作者名称：Wise Wong
发布时间：2026-06-13 09:57
开了200刀会员的这个月，一直在深度使用Codex，总结了让Codex表现更好的15个技巧：包括启动前的设定、上下文成本的控制、自检、清理还有交付。
1. 先画原型，再开始开发
让AI工作前先Plan，再开发我想很多朋友都是知道的。
但到了Codex，它集成了画图的能力，我们可以让它直接画出原型图，并且给出设计规范，然后开发。
当AI有了参照物，开发就不会千篇一律，现在AI还是很习惯于格子布局、偏紫色。
但画图不会，GPT内置了gpt-image-2的画图能力，画图画得很好。而有了对照，后面的开发也会更清晰。
第一轮先画方向，第二轮画完整视觉稿，第三轮输出设计规范，然后我们把设计规范更新进AGENT.md，长期指导它的开发。
Prompt参考
基于苹果人机交互指南，为我设计<产品>的视觉方向稿
核心能力是：<产品核心能力>
面向人群是：<面向人群>2. 设置具体的目标
普通的任务，不需要Goal，只要输入你的指令就好了。需要连续推进、多步排查、多轮修改和验证的任务建议使用Goal。
但目标越空泛，越容易让Token爆炸，它应该定义Codex应该实现什么，不能改变什么，如何验证进展，以及何时停止。
不要写：优化整个项目，让它更稳定。
这可能会把代码质量、性能、测试、构建或者你不知道的范围都被纳入进来，这个目标看来是做不完了…
更好的 Goal 是：
/goal 提升【具体链路/模块】的稳定性。
目标：
1. 修复【具体问题/失败场景】。
2. 保证【核心用户路径】在【具体条件】下稳定运行。
3. 如果发现问题不在当前模块，先记录证据，不要扩大改动范围。
范围：
只允许修改【允许改的模块】。
不要改：
1. 不要改【不相关模块】。
2. 不要重构【暂时不想动的架构】。
3. 不要改变【现有数据结构/API/用户交互】。
验证：
1. 运行【测试命令】。
2. 运行【构建命令】。
3. 用【复现样例/真实操作路径】验证。
4. 输出修改文件、验证结果、仍存在的风险。
停止条件：
当【明确可验证结果】满足，并且【测试/构建/手动验证】通过时停止。目标是一个不需要监控的任务，而不是愿望清单。
3. 复杂任务优先开 worktree
如果你让 Codex 直接在你的分支上改，或者新开无数的会话改，你会遇到大量的冲突，A会话的方案和B会话的方案有冲突，A在commit的时候B也在commit，但Codex又默认不会处理非它任务的commit，于是不断打架，到了后面你都不知道谁改对了bug，莫名其妙消耗了无数的Token。
除非你明确你的改动是相互独立的，或者你能忍受同时间只做一件事，否则最好先放到独立 worktree。
worktree 的作用是在同一个仓库多开一个工作树，让 Codex 在隔离目录里工作，不会造成污染，你的主目录可以继续运行服务或者处理其他事。
合回主分支的时候，记得让它先进行冲突预检，以及合并的建议，不要直接把 worktree 里的结果直接无脑搬进主目录。
这里也可以结合Goal、Agent Team使用
来自@Aaron 老师的Prompt，但我没有用在Goal上
新开Worktree处理，使用agent team负责不同任务板块，
在不影响情况下并行处理，主agent负责统筹，验收；
必须要回测、评测每一个环节，确保符合要求满足用户需求，再PR4. 任务尽量聚焦
Codex 能处理复杂的长程任务，但跨文件、跨模块改动代码会导致慢、烧Token，我们尽量在一个会话中完成同一个模块的任务。
这样子任务会更聚焦，也不用重复建设上下文，例如改动登录的时候，让它去看支付的代码改个icon，但支付的代码对登录一点帮助都没有。
开发效率、验证效率会更高，上下文也更干净、成本也会更低。
5. 更早的结构化上下文压缩
Hermes优雅的点是会很早的就进行上下文压缩，并且是结构化压缩，同样的思路我们可以用在Codex里。
等待系统自动压缩上下文可能太长了，耗Token、耗时间，网络不稳定就经常断线。
而且久远的上下文可能没有太大的作用。
参考Hermes的做法，我调整成了70%触发压缩，不至于那么晚，也不会说50%那么早导致丢失了长任务，并且自定义了压缩的提示词。
官方文档也明确支持压缩的阈值，还有压缩的提示词。
这是我的指令的参考示例：
请帮我把当前 Codex 配置成“结构化交接式压缩策略”。
## 目标
- 使用 Codex 自带的上下文压缩机制，不替换底层算法。
- 自动压缩触发点设为当前模型上下文窗口的约 70%。
- 压缩产物使用结构化交接摘要，结合 Codex 的 handoff 思路和 Hermes 风格栏目。
- 不要覆盖用户现有配置；修改前先备份 `～/.codex/config.toml`。
- 修改要尽量小，只改 compact 相关配置和新增 compact prompt 文件。
## 步骤
### 1. 确认当前 Codex 版本和模型上下文窗口
先运行：
```bash
codex --version
codex debug models
```
从 `codex debug models` 输出里找到当前模型，例如 `gpt-5.5`，读取它的 `context_window`。
然后计算：
```text
model_auto_compact_token_limit = floor(context_window * 0.70)
```
如果当前模型是 `gpt-5.5`，并且：
```text
context_window = 272000
```
则设置为：
```text
190400
```
注意：
- `codex debug models` 只用于查询模型信息。
- 不要用 `codex debug models` 做 `--strict-config` 校验，因为当前版本的 `codex debug` 不支持 `--strict-config`。
- 不要用 `codex --strict-config --help` 判断配置是否有效；它只打印帮助，不会真正校验配置字段。
### 2. 备份当前配置
先备份：
```bash
cp ～/.codex/config.toml ～/.codex/config.toml.bak-$(date +%Y%m%d-%H%M%S)-before-compact-strategy
```
备份后再修改。
### 3. 创建压缩 prompt 文件
建议路径：
```text
～/.codex/prompts/compact-handoff-structured.md
```
先确保目录存在：
```bash
mkdir -p ～/.codex/prompts
```
创建文件：
```text
～/.codex/prompts/compact-handoff-structured.md
```
文件内容如下：
```md
你正在执行一次上下文检查点压缩。
请为另一个即将接手同一任务的 LLM 创建一份结构化交接摘要。
必须保留精确值、文件路径、命令、错误信息、技术决策、约束条件、服务 URL、
端口号、分支名、commit hash、测试结果、临时产物路径，以及下一步动作。
如果当前对话中已经包含来自前一次压缩的摘要，请把其中关键的历史脉络保留在
“历史上下文”中。不要因为某些决策或结果来自更早的压缩，就丢弃它们。
## 历史上下文
[来自前几次压缩的累计上下文，尤其是关键决策、结果和方向]
## 目标
[用户正在试图完成什么]
## 约束与偏好
[用户偏好、编码风格、范围边界、约束条件和重要决策]
## 进展
### 已完成
[已完成的工作：具体文件路径、运行过的命令、结果、测试、commit、PR]
### 进行中
[当前正在进行的工作]
### 阻塞
[遇到的阻塞或问题]
## 关键决策
[重要技术决策及其原因]
## 相关文件
[读过、修改过或创建过的文件，并简要说明每个文件的作用]
## 下一步
[按顺序列出具体下一步动作]
## 关键上下文
[不能丢失的具体值、错误信息、配置细节、服务 URL、端口、分支、commit hash、
测试命令、截图、临时产物，以及其他必须保留的信息]
```
### 4. 更新 `～/.codex/config.toml`
把下面两项放在 `～/.codex/config.toml` 的顶层。
它们应该放在第一个 `[xxx]` TOML 表之前，或者和其他顶层字段放在一起：
```toml
model_auto_compact_token_limit = 190400
experimental_compact_prompt_file = "/Users/替换成实际用户名/.codex/prompts/compact-handoff-structured.md"
```
注意：
- `190400` 只适用于 `context_window = 272000` 的情况。
- 如果上下文窗口不同，按 `context_window * 0.70` 重新计算。
- `experimental_compact_prompt_file` 必须使用这台机器上的真实绝对路径。
- 不要把 `model_auto_compact_token_limit` 和 `experimental_compact_prompt_file` 放进 `[desktop]`、`[features]`、`[projects.xxx]` 或其他 TOML 表下面。
- 不要重复创建第二个 `[desktop]` 表。
如果文件里已经有 `[desktop]`，只在原有 `[desktop]` 表里确认或加入：
```toml
[desktop]
show-context-window-usage = true
```
如果 `[desktop]` 里已经有：
```toml
show-context-window-usage = true
```
则保持不动。
### 5. 验证配置加载
先用 Codex 加载完整用户配置，确认没有配置加载错误：
```bash
codex doctor --summary --ascii
```
预期：
- `Configuration` 里的 `config` 应该显示 loaded 或 ok。
- 如果 `doctor` 因终端环境、历史线程索引、网络、认证、MCP 等无关项返回非 0，需要看具体失败项，不要直接判断 compact 配置失败。
### 6. 严格验证新增 compact 字段是否被当前 Codex 版本识别
使用隔离校验，避免用户已有旧配置影响判断：
```bash
codex exec \
--ignore-user-config \
--strict-config \
--ephemeral \
--skip-git-repo-check \
-c model='"gpt-5.5"' \
-c model_auto_compact_token_limit=190400 \
-c experimental_compact_prompt_file='"/Users/替换成实际用户名/.codex/prompts/compact-handoff-structured.md"' \
"只输出 OK，不使用工具。"
```
预期：
- 输出 `OK`，说明 `model_auto_compact_token_limit` 和 `experimental_compact_prompt_file` 被当前版本识别。
- 如果直接对完整 `～/.codex/config.toml` 使用 `--strict-config` 报错，先看报错字段是不是用户已有旧配置。
- 不要把无关旧字段误判成 compact 配置失败。
### 7. 验证实际效果
新开一个 Codex 会话或重启 Codex 后测试，因为当前已打开会话不保证热加载配置。
在新会话中：
- 用 `/status` 查看上下文使用情况。
- 输入几轮测试内容后，用 `/compact` 手动触发一次压缩。
- 检查压缩摘要是否按上述结构输出，而不是默认短摘要。
自动压缩验证：
- 当长会话达到约 `model_auto_compact_token_limit` 附近时，Codex 应自动触发 compaction。
- 自动压缩产物预期同样使用 `experimental_compact_prompt_file` 指向的结构化交接模板。
## 完成标准
完成后请汇报：
- 实际 `context_window` 是多少。
- 实际计算出的 `model_auto_compact_token_limit` 是多少。
- 备份文件路径是什么。
- compact prompt 文件路径是什么。
- `～/.codex/config.toml` 中新增或确认的配置项是什么。
- `codex doctor --summary --ascii` 的配置加载结果。
- 隔离 strict 校验是否输出 `OK`。
- 如有任何非 compact 相关的既有配置警告或错误，请单独列出，不要混在 compact 配置结果里。6. 简单任务用便宜的模型
Codex有个很多朋友忽略的点是有免费的Codex-Spark模型。
和其他的模型用量独立计算。
Codex 官方把 GPT-5.3-Codex-Spark 定位成快速、能力较轻的 Codex 模型，适合近实时的轻量编码迭代，它适合做“快问快答”和低风险改动，不适合复杂系统推理。
国内平替也可以按这个思路分层：简单文本、轻量分析、草稿重写，可以用 Kimi 这类响应快的工具；复杂代码推理、跨文件工程任务，再用 GLM 5.1 这类更强模型。
我们可以尝试把任务分级：
低风险：
commit、摘要、翻译、轻文档。
中风险：
单文件修改、局部测试修复、简单 UI 调整。
高风险：
架构、合并、迁移、线上排障、安全审查。在commit、diff、改改小需求这些事，我大多数时候会切换成中等思考，实在不够用了会用国产平替GLM 5.1，然后被速度劝退之后用Spark…
但核心原理是不要每个任务都值得上最高推理，买了200刀之后最惨痛的就是20倍，也不够用…为我无知的开启加速模式而后悔…
7. 非必要不开 Fast mode
Fast mode 是我的一生之敌，开了其实也没快多少，用量倒是真的烧的很快。。。
GPT-5.5 的 Fast mode 大约是 1.5 倍速度、2.5 倍 消耗，它比较适合对速度要求很高的现场演示，或者…赶着commit回家吃饭…
但不太适合长任务、探索任务、反复试错、会调用很多工具的工作。
8. 善用/side
既然不开Fast Mode，那一定是不快的，但我们经常在长任务里冒出一些其他问题：进度怎么样？为什么选这个方案？这样做的原因是什么？
但这些“好奇心”还是不要放在当前主会话里了，`/side`或`/侧边`，类似Claude Code的`/btw`，我们可以用旁路会话来问一个临时问题，并且不打断主任务的工作。
这个模式不支持Plan，如果你有新的任务目标或者想要改变实现的方向，需要回到主会话里处理。
9. 让Codex证明自己做对了
这一点和目标很像，但更多服务于怎么衡量AI的工作做完了。
不约束完成条件AI很容易偷懒，不是开发完就结束了，还要要求AI做完自我检查、截图校验、再次自我检查、发送可验收的结果。
如果不在电脑前，并且Codex和电脑连接不稳定的话，可以让Codex通过飞书CLI给你发送验收结果、图片。
先定义好完成标准，Codex 才知道要做到什么程度，什么时候才该停下来。
10. 让它在真实环境验证
涉及到Web开发，Codex会偏向使用内置浏览器 ，但它并不是真实的浏览器环境，内置浏览器没问题的功能，在Chrome不一定可以。
所以在验收时，我们不要让AI用内置浏览器的的结果替代真实验收，尤其是登录、权限、内网系统和复杂前端状态。
在疑难杂症的时候记得让它多打日志，才能搞高效解决 bug。
11. 用/review做代码审查
/Review 或者/审查，它支持基于基础分支审查，或者在commit之前审查。
但如果既不想基于分支、也不是基于未提交的更改，可以参考下面这一段提示词
Prompt
请进行代码审查：
重点检查正确性、边界条件、回归风险、测试缺口、代码复用、运行效率、可维护性。
请按 MECE 原则组织发现，避免重复、冲突、遗漏和互相矛盾。
同时检查模块是否高内聚低耦合，是否存在不必要抽象、重复逻辑、隐式依赖或职责混杂。
发现问题时按严重程度排序，并给出文件/行号、影响、建议修复方式和验证方法。
12.AGENTS.md/CLAUDE.md保持一致
如果你同时使用 Codex 和 Claude Code，那我们要关注保持`AGENTS.md`和`CLAUDE.md`的一致性。
除了AGENTS.md，Skill的逻辑也是一样的，例如我们在Codex更新了Skill的处理逻辑，但Claude Code没学会，导致任务会有漂移，最后两个 agent 对同一个项目有两套世界观。
Prompt示例：
请检查 AGENTS.md 和 CLAUDE.md 是否需要同步。
如果需要，保持正文一致，只允许标题或工具名差异。
同步后用 diff 或等价命令证明它们没有规则漂移。13. 打开更新后，你没打开的开关
1）运行时防止休眠：在 Codex 运行对话时，让电脑保持唤醒状态
2）显示上下文窗口使用情况
3）跟进行为：选择排队还是引导，我还是比较喜欢排队，这样我可以避免设置Goal的超长任务，也能让它逐步按照我的想法调整代码。
此处可见秋子的极限用法，开 N 个会话，排队 N 个指令，舒服散步遛狗，赶紧去关注他。
4）应用快照：截取一张屏幕快照，向 Codex 展示你最前面的窗口
5）浏览器、电脑操控，最重要的是锁屏操作：允许 Codex 在 Mac 锁定时使用你的电脑
14. 设置个性化-自定义指令AGENT.md
这是我的参考，包含了这篇文章的一些理念：
# 全局工作协议
## 语言
- 始终使用中文与我沟通，除非我明确要求使用其他语言。
## 沟通清晰度
- 针对复杂的技术方案，尤其是分支合并、冲突处理、PR、发布部署和架构变更，先用通俗的中文解释，再补充技术细节。
- 开篇结构：一句话结论、要做什么、保留什么或舍弃什么、以及如何验证。
- 不要一上来就罗列大量文件列表、提交图谱或实现细节，除非我明确要求。
## 先调研再出方案
- 在提出技术方案前，先查阅相关官方文档、行业最佳实践以及当前项目的实际上下文。
- 能用事实验证的，不要靠猜测。
- 清晰区分已验证的事实、假设和推荐意见。
- 涉及新页面、新产品体验、复杂 UI 或视觉风格调整时，先明确目标用户、核心能力、交互路径和视觉方向；必要时先使用当前可用的图像生成能力生成方向稿、视觉稿或设计参考，例如 `gpt-image-2`，再进入开发。
## 系统思维
- 不要只解决表面可见的单点问题。
- 分析根本原因、相关的失败模式，以及如何预防再次发生。
- 优先采用标准化、通用、模块化的解决方案，而非个案补丁。
- 保持能力独立、可复用、结构清晰。
- 每个会话优先聚焦同一模块或同一链路。
- 如果发现问题超出当前范围，先记录证据和建议，不要擅自扩大改动面。
## 交付标准
- 每个任务都必须以可验证的结果收尾。
- 在实现前先定义“完成”：预期行为、测试命令、截图、服务器地址或复现步骤。
- 实现后，运行相关检查并进行二次复核。
- 提供人工验证步骤，如测试用例、命令、截图或启动服务器的方法。
- 使用 Goal 时，必须写清：目标、允许范围、禁止事项、验证方式、停止条件。
- Goal 不应是愿望清单；如果目标过大，先拆成可验证的阶段任务。
- 涉及 Web、登录、权限、内网系统、复杂前端状态或浏览器差异时，不能只用构建、类型检查或内置浏览器结果代替真实验收。
- 最终交付默认说明：改了什么、如何验证、验证结果、仍有风险、人工验收步骤。
- 如果有 commit，附 commit hash；如果启动了服务，附服务 URL；如果产生临时产物，说明路径和是否需要清理。
## 资源保护
- 始终注意保护内存占用。
- 使用完毕后，停止并清理不必要的辅助进程、开发服务器、监听器、浏览器实例等 Codex 相关的临时辅助工具。
- 在启动新的长运行进程前，检查是否已有等效进程在运行。
## 存储保护
- 始终注意保护磁盘占用。
- 记录验证过程中创建的临时文件、生成的截图、测试产物、日志、模拟数据和构建输出。
- 人工验证完成后，询问是否应删除这些临时产物。
- 不要在仓库或工作区留下未说明的垃圾文件。
## 变更安全
- 在进行大范围改动前，先检查当前的 Git 状态，避免覆盖用户的工作内容。
- 优先采用小而可审阅的 diff。
- 对于破坏性操作、依赖变更、数据迁移或可能影响生产环境的动作，先说明影响范围并请求确认。
- 绝不改动与用户需求无关的部分代码，杜绝修复一个问题引发了新的问题。
- 只有在并行开发、长任务、冲突风险高、或需要隔离试验时，才建议新建 worktree。
- 合并 worktree 成果前，必须先做冲突预检、变更范围说明和验证结果汇报。
## 代码审查
- 当我要求 review、审查或自检代码时，优先按代码审查方式输出：先列问题，再列影响、建议修复方式和验证方法。
- 重点检查正确性、边界条件、回归风险、测试缺口、复用、性能和可维护性。
## 规则同步
- 涉及 AGENTS.md、CLAUDE.md、Skill 或其他代理规则变更时，检查是否需要同步。
- 同步时保持正文规则一致，只允许标题、工具名或平台差异存在。15.永远保护存储、性能
上一篇文章有讲过Codex非常的吃性能，其中一个原因是MCP，很多朋友可能和我一样安装的时候是默认开启的，但每个 MCP 都可能带来额外工具说明、权限、启动进程和上下文负担。
而且本地资源也会更重，很可能导致电脑发热、内存升高、线程变慢。
除了MCP之外，Codex 也很容易为了验证开一堆东西：端口、浏览器窗口、浏览器、进程，这些性能消耗大户。
最后就是截图、日志、构建缓存、测试产物、worktree这些临时产物。
不用的东西要及时清理，避免占用。
我也把它封装成了skill，可以参考
尽快尽早烧掉你的用量
Codex可能时不时就会进行重置，没用完等于血亏，用完才有休息时间🐶。
不然，万一出了个重置，用量刷新了，那就又要卷了。。。
声明：部分图片由AI生成
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们下次见啦。
内容效果不满意？点此反馈