Codex节省Token办法

前言：为什么你的 Token 总是不够用？

Codex 上线后，“额度不够用”几乎成了开发者社区里出现频率最高的抱怨。尤其是 OpenAI 取消了 5 小时硬性限额、改为按周滚动配额后，不少人前一两天就把一周的额度烧了个精光。

问题的根源在于 Codex 的 Token 消耗结构：总费用 = 输入 Token × 输入单价 + 输出 Token × 输出单价，其中输入 Token 往往占了大头。每轮对话，Codex 都会把之前的完整上下文（系统提示、AGENTS.md、历史对话、读取的代码文件）重新发送一遍，对话越长，单次消耗越高，形成”雪球效应”。

好消息是，经过合理优化，Token 消耗可以降低 50%~90%。本文将目前所有经过实战验证的省 Token 方案做一次系统梳理，覆盖 Web 端和 CLI 端，每条都有可操作步骤和示例。

一、Token 消耗全景图：钱都花在哪了？

在动手优化之前，先搞清楚 Codex 的 Token 到底消耗在哪些环节：

从图中可以看到，你新输入的那句话本身占的 Token 极少，真正的大头是 AGENTS.md、历史对话和读取的代码文件。所以优化的核心思路就是：精简输入上下文、控制输出量、选对模型档位。

用 /usage 命令可以随时查看当前会话的 Token 消耗明细（CLI 端支持），定位到底哪个环节在”烧钱”。

二、AGENTS.md：一次配置，长期省 Token

什么是 AGENTS.md？

AGENTS.md 是 Codex 的项目级”说明书”。每次对话开始时，Codex 会自动读取这个文件来了解项目背景、技术栈、代码规范和禁区，不需要在每次对话中反复解释，也不需要大量读取源码来”猜”项目结构。

一个好的 AGENTS.md 能让 Codex 首次对话就精准定位目标文件，避免全局扫描，Token 占用可直接减少 30%~50%。

如何生成？

CLI 端：在项目根目录执行 /init，Codex 会自动分析项目并生成一份初始 AGENTS.md。

Web 端：手动在项目根目录创建 AGENTS.md 文件。

AGENTS.md 应该写什么？

核心原则是精简、高密度、不废话。以下是推荐的 AGENTS.md 结构：

# 项目概述
这是一个基于 Next.js 14 的电商平台，使用 TypeScript + Prisma + PostgreSQL。

# 目录结构
- src/app/ — App Router 页面和 API 路由
- src/components/ — 可复用 UI 组件（使用 shadcn/ui）
- src/lib/ — 工具函数和第三方服务封装
- prisma/ — 数据库 Schema 和迁移文件

# 常用命令
- `pnpm dev` — 启动开发服务器
- `pnpm build` — 生产构建
- `pnpm test` — 运行 Vitest 测试
- `pnpm db:migrate` — 执行数据库迁移

# 代码约定
- 组件使用函数式组件 + TypeScript， Props 定义 interface
- 样式使用 Tailwind CSS，不写自定义 CSS
- API 路由统一返回 { data, error, message } 格式
- 错误处理使用 src/lib/error-handler.ts 中的统一方法

# 禁区（不要动这些文件）
- src/legacy/ — 旧版代码，暂不重构
- prisma/migrations/ — 不要修改已有迁移文件
- .env.* — 环境变量文件，不要读取或修改

分层级管理

AGENTS.md 支持多层级放置，Codex 会按层级加载：

~/.codex/AGENTS.md              ← 全局级：所有项目通用的规则
项目根目录/AGENTS.md             ← 项目级：本项目特有信息
项目根目录/src/components/AGENTS.md ← 子目录级：模块级细节

子目录级的 AGENTS.md 只在 Codex 访问该目录下的文件时才会被加载，不会一上来就全部塞进上下文，这是控制 Token 的关键设计。

注意事项

AGENTS.md 默认上限为 32KiB。不要把它写成项目文档的复制粘贴，只放 Codex 做决策时最需要的信息。冗余内容本身就会浪费 Token。

三、.codexignore：屏蔽无关文件的扫描

为什么需要它？

Codex 在分析项目时会扫描目录结构。如果你的项目包含 node_modules、dist、build、.git 等目录，每次交互都会产生大量不必要的文件索引 Token 消耗。以一个中等规模的 Node.js 项目为例，node_modules 下通常有数万个文件，不排除的话单次交互可能多出 30% 以上的无效 Token。

如何配置？

在项目根目录创建 .codexignore 文件，语法与 .gitignore 完全一致：

# 依赖目录
node_modules/
.pnpm-store/

# 构建产物
dist/
build/
.next/
out/

# 版本控制
.git/

# 锁文件（体积大但无需 AI 理解）
package-lock.json
pnpm-lock.yaml
yarn.lock

# 系统文件
.DS_Store
Thumbs.db

# 测试覆盖率报告
coverage/

# 日志文件
*.log
logs/

# 大型静态资源
public/assets/fonts/
public/assets/videos/

效果对比

优化前：每次交互额外索引 ~50,000 个文件 ≈ 浪费数千 Token
优化后：只索引项目源码文件 ≈ 上下文干净清爽

以某中型前端项目为例：
  排除前：单次交互上下文 ~180,000 tokens
  排除后：单次交互上下文 ~120,000 tokens
  节省幅度：约 33%

四、模型选择：杀鸡别用牛刀

Codex 可用模型一览

Codex 提供了多个模型档位，不同模型的 Token 单价和配额消耗差异巨大。截至 2026 年 8 月，可用模型如下：

GPT-5.6 三兄弟怎么选？ Sol 是旗舰，面向复杂工程任务和长时间 Agent 推理；Terra 是均衡款，日常开发的主力；Luna 最轻量、速度最快，适合简单任务。Free 和 Go 用户默认使用 Terra，Plus/Pro 用户可以选用全部三档。

gpt-5.6-luna 的额度消耗约为 gpt-5.6-sol 的 1/8 到 1/4。根据经验，80% 的日常任务用 Luna 或 Terra 就能很好地完成，只有约 20% 的复杂场景才需要 Sol 出马。

切换方法

CLI 端：使用 /model 斜杠命令切换。

/model gpt-5.6-luna      ← 切到轻量模型
/model gpt-5.6-terra     ← 切到均衡模型
/model gpt-5.4           ← 切到主力模型
/model gpt-5.6-sol       ← 切到旗舰模型

Web 端：在输入框右下角的模型下拉菜单中切换。

操作习惯建议

养成”默认 Luna，按需升级”的习惯。开始一个任务时用轻量模型，如果发现模型理解力不够（比如无法正确跨文件引用、推理链路断裂），再临时切到 Terra 或 Sol。用完之后立刻切回 Luna，避免后续简单任务继续消耗高价额度。

五、推理等级（Reasoning Effort）：按需调节”思考深度”

什么是推理等级？

Codex 的推理等级决定了模型在输出前”思考”多深。等级越高，推理链越长，输出的代码质量可能更好，但 Token 消耗也成倍增长。

三个等级对比：

设置方法

CLI 端：

/model gpt-5.4 --reasoning-effort medium

也可以在 ~/.codex/config.toml 中设置默认推理等级（见下文”配置文件优化”章节）。

Web 端：在对话设置中选择推理等级，或在 Standard 模式和 Fast 模式之间切换（Fast 模式推理更低）。

建议

日常开发统一使用 medium，只在遇到真正复杂的推理任务时临时切到 high。很多开发者默认就是 high，这相当于每次提问都让模型”深度思考”，简单任务白白浪费了大量推理 Token。

六、上下文管理：/compact、/reset 与新会话策略

6.1 用 /compact 压缩上下文

这是省 Token 最直接的命令之一。/compact 会对当前会话的历史对话进行一次智能摘要压缩，只保留核心信息，丢弃细枝末节。

操作前：历史 20 轮对话，累计 ~350,000 tokens
执行 /compact 后：压缩为摘要，~80,000 tokens
节省幅度：约 77%

CLI 端：直接输入 /compact 即可。

何时使用？

• 一个任务已经讨论了 10 轮以上，但还在继续
• 感觉 Codex 响应变慢了（上下文太长导致处理变慢）
• 准备在同一会话中开始一个相关但略有不同的子任务

6.2 用 /reset 或 /new 开启新会话

如果你已经完全切换到了一个新任务，不要继续在旧会话里对话。旧会话积累的所有历史都会作为上下文发送，白白消耗 Token。

/reset    ← 清空当前会话，从零开始
/new      ← 新建一个会话

判断标准：如果新任务和当前任务的上下文重叠不超过 30%，就应该开新会话。

6.3 控制单会话对话轮数

Codex 默认会保留过去约 20 轮对话作为上下文。在实际使用中，较早的对话内容对当前任务的参考价值往往有限。建议将有效对话控制在 8~10 轮以内，超过后主动执行 /compact 或开新会话。

上下文管理策略总结

七、任务拆解：精准指令是省 Token 的第一原则

这可能是所有优化技巧中最重要的一条。

反面案例

❌ "帮我重构整个认证模块"
❌ "优化项目性能"
❌ "把项目从 JavaScript 迁移到 TypeScript"

这类指令对人来说是方向，对 Codex 来说是灾难。它不得不先读一大堆文件来理解全局，再试图制定计划，再开始动手。整个过程的 Token 消耗呈几何级数增长，而且出错概率极高，一旦出错又要花更多 Token 来修复。

正确做法

将大任务拆解为具体的小任务，明确指定操作范围和目标：

✅ "只修改 src/auth/jwt.ts 中的 token 刷新逻辑，
    将过期时间从 1 小时改为 24 小时，不改其他文件"

✅ "在 src/components/UserList.tsx 中为列表渲染
    添加 React.memo 和虚拟滚动（使用 react-window）"

✅ "给 src/api/orders.ts 的 GET /orders 接口
    添加分页参数 page 和 pageSize，默认 page=1, pageSize=20"

拆解原则

八、计划模式（Plan Mode）：先出方案，再动手

为什么有效？

Codex 默认模式下会直接开始读文件、改代码。如果理解有偏差，就会走弯路——读了大量文件、生成了大量代码，最后发现方向错了，这些 Token 全部浪费。

计划模式让 Codex 先输出一个执行方案（只消耗少量 Token），你确认方向正确后再执行，避免了无效的探索和试错，可减少 20%+ 的无效 Token。

使用方法

CLI 端：按 Shift + Tab 切换到计划模式（Plan Mode），在输入框左侧会显示模式标识。

操作示例：

1. 按 Shift+Tab 进入计划模式
2. 输入任务："重构 src/services/payment.ts 的支付流程，
   添加支付宝渠道支持"
3. Codex 输出执行计划（不修改任何文件）：
   - 读取 src/services/payment.ts 了解现有结构
   - 新建 src/services/payment/alipay.ts
   - 修改 payment.ts 添加路由分发
   - 添加对应的单元测试
4. 确认方案合理后，切回正常模式执行

提示词方式（通用）：在指令前加上”先不要修改代码，先告诉我你打算怎么做”，也能达到类似效果。

九、精准上下文投喂：@文件 和限定范围

用 @ 精确指定文件

与其让 Codex 自己去扫描项目找相关文件，不如直接用 @ 指定要读取的文件：

✅ "参考 @src/types/order.ts 中的 Order 类型定义，
    在 @src/api/orders.ts 中添加校验逻辑"

❌ "帮我给订单接口添加类型校验"
   （Codex 需要自己搜索类型定义文件和接口文件）

每次精确指定文件，Codex 就不需要花时间（和 Token）去遍历目录，可以省下不少上下文 Token。

在提示词中限定范围

✅ "只关注 src/utils/date.ts 这个文件，
    将 formatDate 函数改为支持相对时间格式"

✅ "阅读以下两个文件后修改：
    - src/components/Header.tsx
    - src/styles/header.module.css
    不要动其他文件"

十、配置文件优化（CLI 端）

config.toml 关键配置

Codex CLI 的配置文件位于 ~/.codex/config.toml，通过合理设置默认参数，可以从根源上控制 Token 消耗：

# ~/.codex/config.toml

# 模型选择：日常使用轻量模型
model = "gpt-5.6-luna"

# 默认推理等级：中等，避免简单任务过度推理
reasoning_effort = "medium"

# 沙箱模式：按需选择
# "read-only" — 只读，最安全，适合代码审查
# "full-auto" — 全自动，适合信任度高的项目
sandbox_mode = "read-only"

别名快捷方式

在 shell 配置文件（~/.zshrc 或 ~/.bashrc）中设置别名，快速切换不同档位：

# 日常轻量模式
alias cx='codex --model gpt-5.6-luna --reasoning-effort low'

# 标准开发模式
alias cxdev='codex --model gpt-5.6-terra --reasoning-effort medium'

# 重度推理模式（复杂任务专用）
alias cxpro='codex --model gpt-5.6-sol --reasoning-effort high'

# 带 Token 日志的模式（用于分析消耗）
alias cxlog='codex --log-tokens'

这样在终端里输入 cx 就是轻量模式，cxdev 就是均衡模式，不用每次手动切换。

十一、Subagent 协作模式：大任务的终极省 Token 方案

什么是 Subagent 模式？

对于大型任务（如”重构整个支付模块”），与其让一个 Codex 会话读取所有文件、消耗巨量上下文，不如拆成多个独立的 Subagent，每个 Subagent 只负责一个子任务，各自只拿到自己需要的上下文。

操作方式

在提示词中明确要求 Codex 启动 Subagent：

"你作为协调者，启动 3 个 subagent：
 Agent1：读取 src/services/payment.ts 和 src/types/payment.d.ts，
         输出当前支付接口的完整定义
 Agent2：根据 Agent1 的输出，新建 src/services/payment/alipay.ts
 Agent3：为新增的支付宝渠道编写单元测试"

每个 Subagent 只拿到自己该看的上下文，做完后把结果摘要传给下一个。省下的不只是 Token，还有上下文窗口被撑爆的风险。

十二、输出控制：减少生成量

明确限制输出范围

✅ "只输出需要修改的代码差异部分，不要输出完整文件"
✅ "只修改第 42~58 行的 formatDate 函数，其他代码不要动"
✅ "用 3 句话解释这个 Bug 的原因，然后给出修复代码"

避免 Codex 过度解释

在 AGENTS.md 或提示词中加一条：

回复风格要求：
- 代码修改直接动手，不需要解释为什么这样改
- 如果需要解释，控制在 3 句以内
- 不要输出完整的修改前后对比，除非我要求

这可以减少输出 Token 30% 以上，尤其在频繁交互的场景下效果显著。

十三、其他实用技巧

13.1 用 /usage 监控消耗

CLI 端输入 /usage 可以查看当前会话的 Token 消耗明细，定位到底是哪个环节在大量消耗。定期查看，找到你的”Token 黑洞”。

13.2 避免在长会话中切换话题

在一个会话里先讨论”重构订单模块”，又讨论”修复登录 Bug”，再讨论”添加新功能”——每次切换话题，之前话题的上下文就变成了纯粹的浪费。一个会话只做一件事。

13.3 善用 codex resume 的取舍

codex resume 可以恢复历史会话，但恢复的会话会带上之前的全部上下文。如果只是想参考之前的某个方案，不如手动复制关键信息到新会话，而不是完整恢复。

13.4 Web 端善用 Fast 模式

Web 端的 Fast 模式使用更轻量的推理，适合简单任务。在界面中切换模式即可，速度更快、消耗更低。

13.5 常用上下文模板化

如果你有反复执行的任务类型（比如”给 API 接口添加参数校验”），可以把提示词模板存成文件，每次只替换具体参数，避免每次都重新描述需求：

<!-- templates/add-validation.md -->
请为以下 API 接口添加参数校验：
- 接口文件：{{file_path}}
- 需要校验的参数：{{params}}
- 校验规则：{{rules}}
- 校验失败时返回 400，格式为 { error: "message" }
- 不要修改其他文件

十四、省 Token 方案速查表

最后，将所有方案汇总为一张速查表，方便日常查阅：

总结

省 Token 不是一个单一技巧，而是一套工作习惯的组合。如果只记住三件事：

第一，写好 AGENTS.md + 配好 .codexignore，让 Codex 不再盲目扫描项目，这是投入产出比最高的优化。

第二，默认用 Luna/Terra + 中等推理，只在真正需要时升级到 Sol。80% 的任务不需要旗舰模型。

第三，一个会话一件事，做完就 /reset，上下文雪球是 Token 消耗的最大元凶。

养成这三个习惯，你的 Codex 额度至少能多用 2~3 倍。再配合计划模式、任务拆解、精确投喂等进阶技巧，省 80%~90% 并非夸张。

希望这份指南能帮你告别”额度焦虑”，更高效地使用 Codex。如果你有更好的省 Token 技巧，欢迎交流分享。