如果你也在用 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 消耗反而比小步走更高。更高效的方式是将任务拆成可验收的小块。比如你要实现一个订单状态机不要一句话扔出去而是拆成定义状态枚举和转换表实现状态转换函数补充常规异常分支测试。每个子任务只在上下文中放相关 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 # 伪代码具体命令名以你当前环境为准 count0 while [ $count -lt 5 ]; do codex_cli exec $TASK # 检查任务是否完成完成后退出否则继续 count$((count1)) done这个技巧适合已经上手 Codex 一段时间的同学。它解决的不是单次请求成本而是整个工作流的“失控开销”。当你发现自己经常一口气聊二十轮、改着改着就偏题时用脚本强制收敛是最后一道保险。5. 常见问题与避坑实录5.1 “省了 token 但质量明显下降”怎么办省 token 不能以牺牲核心逻辑为代价。如果你发现调低思考预算或缩短上下文后Codex 频繁出错多数时候不是技巧本身有问题而是边界条件没写清楚。比如你砍掉了历史里原本已经约定好的“锁顺序不能变”这条约束模型自然容易犯错。遇到这种情况按三步排查先看是否把必要约束也一起省掉了再看任务等级与思考预算是否匹配复杂任务不要强行用low最后检查当前上下文是否过于精简连基本接口签名都没有。如果任务本身很复杂省 token 的重点应该放在清理无用历史和控制解释输出上而不是压缩核心信息。我试过一个涉及并发锁修复的任务把它设成low后模型没有考虑锁顺序多花了两轮调试。后来改成medium并保留一句“锁顺序必须与现有acquire逻辑保持一致”一次就通过了。省 token 不是简单地删信息而是要把无用信息删掉把关键信息留下来。5.2 十个技巧的速查表与优先级建议技巧核心动作主要省的是难度1. 工单式指令一次说清目标、文件、边界、输出格式请求轮次低2. 只贴相关代码粘贴最小函数/片段不贴整个文件输入 token低3. 只输出代码块强制关闭解释输出 token低4. 限定一个方案禁止方案对比直接实现输出 token低5. 任务拆小一次只验收一个改动整体返工成本中6. 定期重置与摘要用精简摘要重建上下文历史输入 token中7. 固定指令文件项目规范写成AGENTS.md重复输入 token中8. 限制输出与思考预算设置 max_tokens 和 reasoning effort输出 token中9. prompt caching把不变内容放最前面后续输入 token中高10. 脚本控制会话限制轮次、控制文件读取范围整条工作流开销高如果刚开始实践先把前四个技巧用起来它们不需要额外配置改一下提问习惯就能立刻见效。如果你经常陷入超长对话再重点落实 6 和 7。如果你是用 API 接入且希望批量跑任务那 8、9、10 才是真正的省钱主力。我个人踩过几次坑之后发现省 token 真正难的不是技术而是改掉“像和人聊天一样用 AI”的习惯。把每个请求当作正式工单你不仅会省钱还会发现 Codex 的产出质量明显变高。最后再分享一个小习惯每次会话结束前我会主动让 Codex 输出一条 200 字以内的“变更摘要”这也是下个会话最好的起始上下文。这个小习惯已经帮我省了至少一半的重复沟通成本。
