Codex省token实战：从输入输出到上下文的10个优化技巧

如果你也在用 Codex 干实际编码任务，大概率体会过这种矛盾：它确实很能写代码，但 token 消耗也快到飞起。一个中等复杂度的任务，经常几句话过去账单就多出上万 token，更别提那些需要反复调试的长对话。省 token 不是抠门，而是让你的额度和预算能支撑更多有效尝试，同时减少上下文被垃圾冲淡导致的错误。这篇攻略我按自己的使用习惯整理了 10 个技巧，覆盖日常交互、任务拆解、上下文治理和工程化配置，适合正在用 Codex CLI 或 API 接入 Codex 的同学，也适合所有被 AI 编码工具 token 账单困扰的人。先说明，这不是让你牺牲质量，而是让你把每个 token 花在刀刃上。

1. 先搞清楚 token 都烧在了哪里

1.1 输入 token 与输出 token：钱分别花在哪

每次调用 Codex，费用主要由两部分组成：输入 token（发给模型的提示、历史、文件内容）和输出 token（模型回复给你的代码、解释）。很多同学只盯住输出，实际上输入才是大头。一次会话内，你每发一条消息，Codex 会把前面的所有消息重新发一遍，历史越长，输入 token 越贵。比如你聊到第 20 轮，单次请求可能就要处理几万甚至十几万历史 token，成本指数级上升。而输出 token 虽然单价通常更贵，但只要控制了模型“话痨”，反而好压。理解这一点是省 token 的地基。

另一个容易忽略的点是：工具调用本身也会消耗 token。Codex 在执行任务时需要读取文件、运行命令、分析错误信息，这些操作都会折算成上下文内容。换句话说，你以为的“一句话”背后可能包含一长串系统观察文本。这也是为什么很多优化技巧都在强调“少绕弯子”，因为每多一次工具调用，就多一次输入 token。

1.2 省 token 的第一性原理：三个控制杠杆

从成本和上下文质量两个角度看，所有省 token 手段最终落在三个杠杆上：

• 减少请求轮次：把一次能说清的事，不要拆成三问三答。
• 压缩输入体积：每次只给模型必要的信息，清理历史和无用文件。
• 控制输出长度：禁止解释、禁止方案对比、限制 max_tokens。

这三个杠杆互相影响。轮次减少通常意味着输入体积也减少；输出长度降低则让对话历史更短，间接降低后续请求的输入 token。所以下面十个技巧，你几乎都能归到这三个杠杆里。如果你现在还没有任何省 token 思路，就盯住这三个方向，大概率不会跑偏。

2. 交互层技巧：把“聊天式提问”改成“工单式指令”

2.1 技巧 1：用“执行指令”代替“聊天请求”

最常见的浪费场景就是像跟同事聊天一样问 Codex：“这个接口一直超时，帮我看看怎么处理？” 这种说法看似省事，但模型没有明确的成功率标准，它会先提出几个可能性，再让你确认；你补充信息后，它又给新建议；几个来回下来，Token 消耗早就翻倍了。

更好的做法是把它当成写工单，一次性给全信息：涉及文件、当前问题、期望行为、输出格式、边界条件。比如：

不推荐：“这个接口一直超时，帮我看看怎么处理？”

推荐：“src/api/order.ts的fetchOrderList在请求超时后返回了null，但调用方期望它抛出TimeoutError。请改为：请求超时时抛出TimeoutError，并在日志中记录request_id。只输出修改后的fetchOrderList函数。”

推荐式指令把目标、文件、行为、输出格式一次说清，Codex 无需追问。我试过把平时容易引发 3 到 4 轮追问的问题，统一改成这种工单式写法，对话轮次直接减少一半以上，对应的 token 自然跟着降。关键原则是：每次提问前先问自己，如果把这番话发给一个只看一眼的同事，他能直接动手吗？如果不能，就继续补信息。

2.2 技巧 2：只喂“变更相关代码”，不要整段粘贴仓库

新手很容易犯一个错：为了让 Codex “充分理解上下文”，把整个文件甚至整个项目目录结构都粘进去。输入 token 爆炸不说，无关代码还会把模型注意力带偏。一个 800 行的文件，真正要改的可能只是其中 30 行，你把 800 行全发过去，结果模型可能开始重构一个无关函数。

正确的做法是粘贴“最小复现代码块”：函数本身加上它直接依赖的数据结构或接口签名，并在代码上下边界用注释标清楚。如果你用终端工具，也可以先用 grep 定位函数位置，把相关行号区域截出来再发。举例来说，需要改动OrderService.syncStatus方法时，最好只贴这个方法以及它引用的OrderStatus枚举定义，而不是把整个 service 文件发过去。

这个技巧的收益非常直观：我手头一个小服务，单文件 700 多行，之前整文件发过去一次就要 10000+ token；改成只贴相关函数后，输入 token 降到 1000 以内，而且模型给出的修改几乎不会牵连其他逻辑。省下的 token 至少 70%，同时返工率也明显下降。

2.3 技巧 3：要求“只输出代码块”，强制关闭解释

Codex 默认比较“热情”，输出代码前喜欢先来一句“好的，我来帮你修改”，然后再说思路、给代码，最后还会提醒你“注意要记得测试”。这些解释性文字全是输出 token。更气的是，它们往往没有实际价值，等你复制代码时还要手动跳过。

解决方式是在指令末尾明确加一句：只输出修改后的完整函数/代码块，不要任何解释；如果必须说明，就写进代码注释。比如可以这样收尾：“只输出修改后的函数，不要输出分析过程。如果需要对行为作说明，请以注释形式写在代码块内。” 在 API 调用里，你还可以同时调低temperature，让模型更稳定地遵循这个格式约束。

我在常规修复任务中实测，这个动作能让输出 token 减少 60% 到 70%。原来的解释文本可能 800 字，现在变成 0；代码部分本来就该有，所以没有任何质量损失。如果你需要完整文件，也别忘了声明“只输出完整源代码文件，不输出任何解释文字”。这算是最容易上手、见效最快的省 token 技巧。

2.4 技巧 4：限定输出一个方案，不要“方案对比如下”

很多人习惯这样问：“订单状态同步失败，可能有哪些原因？分别怎么解决？” 模型会列出三五个方案，每个都写几百字，再逐个分析优缺点。等你花大把 token 看完，还得再发一条“就按方案二实现”。一来一回，输出 token 翻倍，后续上下文还多了一大堆方案描述。

正确做法是让 Codex 基于当前代码现状直接选一个改动最小的方案，并立刻实现。你可以这样写：“根据现有代码结构，选择一个改动最小且风险最低的方案并直接实现。不要对比多种方案。如果必须说明选择理由，最多用一句话。” 这等于把“决策权”交给模型，让它跳过方案罗列，直接给结果。

如果你确实需要在不同方案之间做技术选型，我建议用一个轻量会话去做调研，确认后再新开会话进入实现模式。不要让方案对比的过程污染主任务上下文。这样既不影响决策质量，又能把长上下文产生的成本控制住。从两轮对话变成一轮，输出 token 至少省一半。

3. 上下文与任务治理：别让历史消息吃掉预算

3.1 技巧 5：任务拆小，一次只验收一个改动

连续对话一长，代码生成型 AI 很容易“上头”。如果你让它“实现支付模块”，它可能会一口气生成几百行代码，里面包含大量假设性逻辑、多余接口，甚至与你现有架构冲突的设计。之后你就要花好几轮去纠正它，token 消耗反而比小步走更高。

更高效的方式是将任务拆成可验收的小块。比如你要实现一个订单状态机，不要一句话扔出去，而是拆成：

1. 定义状态枚举和转换表；
2. 实现状态转换函数；
3. 补充常规异常分支测试。

每个子任务只在上下文中放相关 schema 和接口签名，并明确要求“只做这一步，不要提前实现其他部分”。每完成一个子任务，就及时验收。一旦发现方向不对，只损失一个小任务的 token，而不是推倒一大段代码。我在一个 CRUD 功能上做过对比：一次性大任务花了 4 轮对话，消耗约 8000 token；拆成 3 个小任务后总 token 降到 5000 左右，而且每一轮输出都更简洁。请求次数变多，但总成本反而更低。

3.2 技巧 6：长对话定期重置，用精简摘要重建上下文

Codex 的上下文窗口虽然很大，但你不可能永远往下聊。可能聊到某个阶段，它会开始“忘记”前面的约束，或者回答质量明显下滑。此时历史消息不光贵，还变成了噪音。很多人舍不得重置，觉得“之前聊了那么多，重来不亏吗”。实际上，几万 token 的历史里，真正有价值的可能只有几百字，其余全是过程性内容。

我的习惯是：每完成一个里程碑，就让 Codex 输出一份精简摘要，然后用摘要作为新会话的开头。摘要需要包含四类信息：已完成功能、改动文件、未完成事项、技术约束。比如：

【任务进度】已实现订单状态转换逻辑，完成单元测试 3 个，未处理事务重试。 【关键决策】状态转换使用枚举而不是字符串。 【约束】不允许修改数据库表结构。 【下一步】实现事务重试机制。

这段摘要尽量控制在 300 到 600 字，对应几百 token，和原来动不动几万 token 的历史比起来便宜太多。新会话再把相关代码片段贴进去，Codex 对当前状态的理解往往比老对话更清楚。需要提醒的是，重置前一定要先让 Codex 生成摘要，不要直接关窗口，否则关键决策可能丢。

3.3 技巧 7：把项目背景写进固定指令文件，而不是反复口述

很多项目有一堆“潜规则”：用 TypeScript、不允许 any、缩进两空格、每个函数必须有单测、日志要按某种格式。你每次新开对话都要重新口述一遍，这些重复描述叠加起来，也是不小的输入开销。更现实的问题是，你总会漏掉几条，然后等到模型写错才想起来补。

最佳做法是把全局约定写进项目根目录的固定指令文件，比如AGENTS.md或CONTEXT.md。内容大致是：

# 项目习惯 - 语言：TypeScript - 约定：禁止 any，显式接口。 - 测试：每个函数必须有单测。 - 回复格式：只输出代码块。

如果 Codex 支持自动读取项目指令文件，那每次会话都会自动带上这些背景；如果没有，你可以在第一条消息里写“请先读 AGENTS.md 并遵守其中约束”。由于这个文件内容固定且放在对话最前面，在支持缓存的场景下还能命中输入缓存，成本进一步下降。这相当于把“人话背景”变成了“机器可复用的上下文”，也解决了多轮对话后期约束被遗忘的问题。

4. 工程化配置：从参数和缓存里再省一笔

4.1 技巧 8：限制 max_tokens 并调低思考预算

调用 Codex 时，很多人对输出长度不加限制，模型一旦自由发挥，可能写出一整个文件框架，远超你需要的函数体。正确的做法是，在 API 参数或 CLI 配置里设置输出上限。比如“修复一个函数”这种任务，max_tokens给 1500 就够了；“生成一个接口定义”给 2000；“重构整个文件”给 4000。不要让它无限制输出，这会成为很多浪费的源头。

另一个容易被忽略的参数是思考预算。不少现代编码模型都支持类似reasoning_effort的设置，从low、medium到high。常规增删改查、变量改名、简单日志处理，用low或medium足够；涉及并发、状态机、复杂算法时才切到high。调低思考预算不仅会减少内部推理 token，也会让输出更短、更直接。

我自己日常默认用medium，遇到并发锁顺序、事务边界这类问题才临时调高。注意不同版本的工具对参数命名可能不一样，具体以你当前使用的 Codex 版本说明为准。但思路是通用的：给输出设置天花板，给推理设置按需档位，别让模型在低价值任务上过度“思考”。

4.2 技巧 9：利用 prompt caching，把不变内容放最前面

很多大模型 API 都有 prompt caching 机制：相同前缀的输入会被缓存，后续请求只对新增加的 token 计费。这意味着你可以把系统提示、项目规范、常用示例放在对话最前面，并且在整个会话里保持完全一致。这样后面的每一轮，都只需要对真正变化的部分付费。

操作上有几个要点：第一，固定前缀内容不要随意改动，哪怕加一个空格都可能让缓存失效；第二，针对同一个文件的多轮修改尽量连续进行，不要一会儿改 A 文件、一会儿改 B 文件，导致前缀频繁变化；第三，如果一条消息需要附带较多背景，把背景放在前面，当前指令放后面，这样每轮背景都是相同前缀。

缓存命中后，输入 token 的成本会显著下降，长期会话的收益尤其明显。这个技巧和技巧 7 配合特别好：把AGENTS.md的内容放在最前面，既完成项目约束传递，又能让后续所有轮次共享同一个前缀。但也要提醒一句：不要为了缓存把所有东西都塞进前缀，总输入体积仍然需要控制，否则前缀本身就变成了一笔大开销。

4.3 技巧 10：用脚本控制会话轮次与文件读取范围

人工自律总有极限，尤其是批量任务或长时间集中编码时。更可靠的方式是写一个包装脚本，让 Codex 在可控范围内运行。比如：

• 限制对话轮数：超过 5 轮就自动退出，提示你先重置或摘要；
• 记录累计 token：每轮请求后解析用量，达到阈值就保存现场并退出；
• 限制可读目录：只允许扫描src/和tests/，把node_modules、dist、build等目录加入忽略列表；
• 串行执行多个小任务：每个任务单独开会话，共享固定前缀，避免历史累计。

一个简化的伪代码逻辑大概是：

#!/usr/bin/env bash # 伪代码，具体命令名以你当前环境为准 count=0 while [ $count -lt 5 ]; do codex_cli exec "$TASK" # 检查任务是否完成，完成后退出，否则继续 count=$((count+1)) done

这个技巧适合已经上手 Codex 一段时间的同学。它解决的不是单次请求成本，而是整个工作流的“失控开销”。当你发现自己经常一口气聊二十轮、改着改着就偏题时，用脚本强制收敛是最后一道保险。

5. 常见问题与避坑实录

5.1 “省了 token 但质量明显下降”怎么办？

省 token 不能以牺牲核心逻辑为代价。如果你发现调低思考预算或缩短上下文后，Codex 频繁出错，多数时候不是技巧本身有问题，而是边界条件没写清楚。比如你砍掉了历史里原本已经约定好的“锁顺序不能变”这条约束，模型自然容易犯错。

遇到这种情况，按三步排查：先看是否把必要约束也一起省掉了；再看任务等级与思考预算是否匹配，复杂任务不要强行用low；最后检查当前上下文是否过于精简，连基本接口签名都没有。如果任务本身很复杂，省 token 的重点应该放在清理无用历史和控制解释输出上，而不是压缩核心信息。

我试过一个涉及并发锁修复的任务，把它设成low后，模型没有考虑锁顺序，多花了两轮调试。后来改成medium，并保留一句“锁顺序必须与现有acquire逻辑保持一致”，一次就通过了。省 token 不是简单地删信息，而是要把无用信息删掉，把关键信息留下来。

5.2 十个技巧的速查表与优先级建议

如果刚开始实践，先把前四个技巧用起来，它们不需要额外配置，改一下提问习惯就能立刻见效。如果你经常陷入超长对话，再重点落实 6 和 7。如果你是用 API 接入且希望批量跑任务，那 8、9、10 才是真正的省钱主力。

我个人踩过几次坑之后发现，省 token 真正难的不是技术，而是改掉“像和人聊天一样用 AI”的习惯。把每个请求当作正式工单，你不仅会省钱，还会发现 Codex 的产出质量明显变高。最后再分享一个小习惯：每次会话结束前，我会主动让 Codex 输出一条 200 字以内的“变更摘要”，这也是下个会话最好的起始上下文。这个小习惯已经帮我省了至少一半的重复沟通成本。