先搞清楚额度是怎么被烧掉的
很多人以为 Codex 像聊天机器人：发一句、答一句、结束。实际不是。
Codex 跑的是 Agent 循环——一个任务里它会反复读文件、改文件、跑命令，每一轮都把前面的对话历史和执行结果重新塞回上下文。所以上下文是滚雪球式增长的：
| 迭代轮次 | 单次输入 Token（示意） |
|---|---|
| 第 1 轮 | 约 5,000 |
| 第 2 轮 | 约 7,000 |
| 第 3 轮 | 约 9,500 |
| 第 4 轮 | 约 14,000 |
| 合计 | 约 35,500 |
一个跑了 4 轮的任务，成本不是单轮的 4 倍，而是接近 7～8 倍。
这就解释了两个常见现象：项目越大越卡、同样的活儿今天比上周更费额度。根因不是限流，是你喂进去的文件太多了。
第一招：加 .codexignore，从源头砍扫描量
Codex 默认会遵守 .gitignore，但代码库里有一大堆 .gitignore 管不到的东西照样会被读进去：类型声明文件、构建产物、测试快照、种子数据、生成的 CSS 和 SVG、图片字体资源。
在项目根目录新建 .codexignore，语法和 .gitignore 完全一样：
# 构建产物（通常体积最大）
node_modules/
.next/
dist/
build/
coverage/
*.min.js
*.min.css
# 自动生成文件
prisma/migrations/
package-lock.json
yarn.lock
pnpm-lock.yaml
*.d.ts
# 资源文件（Codex 不需要读图片和字体）
public/images/
public/fonts/
assets/
# 测试夹具与快照（频繁变化，纯噪音）
test/fixtures/
**/snapshots/
实测参考：一个中型 Next.js 项目，排除 node_modules 和 .next 之后，需要扫描的文件从 5 万多降到几百个，上下文消耗下降九成以上。中等规模项目单次会话 Token 普遍能砍掉 30%～60%。
提示：这是零成本、见效最快的一步。装完 Codex 第一件事就该做，不配的话第一次执行能卡到你怀疑工具坏了。
第二招：从子目录启动，而不是仓库根目录
Codex 是从当前工作目录往下读文件的。任务如果只涉及某一个模块，就没必要让它站在 monorepo 根目录看全景。
# 不推荐：站在根目录，第一轮就读进整个仓库
cd ~/projects/my-monorepo && codex
# 推荐：只关心 auth 包，就进去再启动
cd ~/projects/my-monorepo/packages/auth && codex
一个多包项目做过对比：从子包目录启动，首轮单任务上下文从约 18,000 Token 降到约 5,000。而且这个差距会在后续每一轮里持续放大。
第三招：一次只做一件事
上下文爆掉最常见的原因，其实不是项目大，而是一条指令塞了三个任务。
反面写法：
帮我把整个项目的 axios 调用统一封装成 fetchClient，
顺便把所有组件的 TypeScript 类型补全，
再把单测覆盖率提升到 80%
这条指令会逼 Codex 读遍整个项目，三类任务互相干扰，上下文很快见底，结果往往三件事都做了一半。
正确写法是按目录边界拆成独立任务，每个开新对话：
任务 1（新对话）：
只修改 src/lib/api/ 目录下的文件，
把所有 axios 直接调用封装成 fetchClient，
不要动调用方（组件文件）。
任务 2（新对话）：
只在 src/components/ 下补全缺失的 TypeScript 类型，
不新增依赖，不改动业务逻辑。
任务 3（新对话）：
只为 src/lib/api/ 下已封装好的方法补单元测试，
测试框架用现有的 Jest 配置。
拆开之后每个任务读的文件都很少，跑得快、改得准、也好 review。
第四招：给每个模块配一份说明，缩小 AI 的搜索半径
据公开报道，OpenAI 内部一个 7 人团队在 5 个月内用 Codex 写了约 100 万行代码、合并 1500 个 PR，人工 review 比例接近零。他们的关键差异不是模型，而是写了 88 个 AGENTS.md——每个模块一份，精确限定 Codex 在各个上下文里能看到什么、能做什么。
模块级说明不用长，几行就够：
# AGENTS.md（src/components/）
- 修改组件时不要引入新依赖
- 不要改动 API 调用逻辑
- 样式只用 Tailwind，不写 CSS-in-JS
- 每个组件必须有 Props 类型定义
关于 AGENTS.md 的完整写法，本站另有专文，这里不展开。核心思路一句话：说明写得越具体，Codex 需要翻的文件越少。
一份可直接照抄的排查顺序
发现 Codex 变慢或额度异常时，按这个顺序查：
- 有没有
.codexignore？ 没有就先加，只这一步通常就够。 - 是不是站在仓库根目录启动的？ 换成任务相关的子目录。
- 这条指令是不是塞了多个任务？ 拆开，每个开新对话。
- 模型选对了吗？ 简单的改注释、修 lint 用轻量模型，别一律上最强的。
- 对话是不是拖太长了？ 一个任务做完就开新会话，别在同一个对话里连做五件事。
建立信任的正确节奏
最后一条不是省额度，是省心：别一上来就让 Codex 动核心业务模块。
先让它写测试、修 lint、补注释。观察几次它的代码风格是否和你的项目契合，再逐步放权到重构和业务逻辑。--approve 这类能自动 commit 的模式，个人项目可以开，团队项目建议逐条确认改动。
来源：AI 编程社区《Codex 上下文优化实战：.codexignore、任务拆分与模块级说明》，经本教程改写整理。
资料最后核对日期：2026-08-04 · 内容整理自 CodexGuide 社区公开教程