用 codex 和 claude code 写代码半年多我最大的感受不是它们能写多快而是 token 账单能有多吓人。同一个功能有人三五千 token 搞定有人三五十万 token 还在原地打转。差别不在模型智商而在怎么组织上下文。这篇文章把我实际用下来的省钱方法完整梳理一遍核心围绕三件事少让工具读没用的文件、少让工具输出废话、别让历史对话无限堆积。无论你是刚接触 CLI 编程助手还是已经被账单刺激过一轮打算优化工作流都可以照着配置试试。1. 两种工具到底是怎么“烧”token 的1.1 每一次请求背后完整上下文重发机制很多人有个错觉以为对话是一次性的问一句答一句就结束。实际上 codex 和 claude code 这种工具在每一轮生成时都会把当前会话的历史记录、系统提示词、工具定义、以及相关文件内容一起打包发给模型。也就是说你聊到第 20 轮的时候前 19 轮的内容会被完整重发一遍再加上第 20 轮的新问题整体 token 数远远超过你“感觉”到的内容量。我习惯打一个比方这就像每次开会都要把之前所有会议纪要重新读一遍然后才开始讲新议题。前期你聊过的需求背景、看过的文件、甚至一次失败的重试错误信息都会变成后续每一次请求的固定开销。所以控制 token 消耗的第一性原则就一句话让进入上下文的内容尽量少让这些内容尽量重复利用。1.2 Claude Code 和 Codex 的消耗差异两个工具的计费模型不完全一样但消耗逻辑大方向一致。Claude Code 的特点是默认能力强、上下文窗口大系统提示词和工具定义这部分内容会被缓存。只要会话内容没有变化重复命中的输入部分能以更低的单位价格计费。它还会自动读项目记忆文件比如放在项目根目录的 CLAUDE.md 一类的规则文件并把其中内容作为长期指令注入每轮请求。这个文件如果写得好相当于每轮都能命中缓存写得不好就是每轮白付一笔指令费用。Codex 这边我更关注的是它自动感知代码库的行为。它会在任务执行前扫描仓库结构、尝试定位相关文件然后按需读取。这个“感知”过程很方便但也非常烧 token尤其是大型 monorepo 项目扫描结果可能先吃掉一大块上下文。它同样支持通过项目规则文件来约束行为用法类似规则文件一旦稳定也能享受到重复上下文的缓存收益。两者共通的省钱核心是同一个控制“每一次请求发出去的包体积”同时提高“发出内容被有效利用”的比例。下面就从配置、提示词、会话管理三个层面逐个拆解。2. 配置层省 token先把运行环境调好2.1 模型选型小改动用轻档难任务才上重档第一步也是最容易被忽略的是模型档位的选择。工具默认配置的模型往往是能力最全的那个但你日常大量任务只是改个变量名、修个 lint 错误、写一段简单脚本。这些任务用轻量档位完全够输出更快单价也更低。我在本地环境里会把默认模型设置成轻档只有遇到需要跨文件重构、推理复杂 bug 时才手动切换更强的模型。这样做的逻辑很直接把能力留给真正需要深度推理的场景而不是让每一轮对话都为“可能的复杂性”买单。注意切换模型不是越轻越好。如果模型能力不够导致反复试错每次失败的重试都会重新消耗 token整体成本反而更高。判断标准是任务失败率如果某个任务在轻档上连续两次做不对就该果断切到重档次数一多试错成本远大于单价差。2.2 文件读取与代码库扫描控制这是所有省钱策略里见效最快的一项。codex 和 claude code 都支持按需引用文件但很多人在实际使用时懒得指定文件直接让工具“自己看看”。工具一旦开启自由探索模式读文件的数量和范围是你无法预估的。我见过最夸张的一次让工具修复一个界面小 bug它把整个项目的依赖配置文件、路由表、十几个子组件全部读了一遍然后才开始动手。修复本身可能只要几百 token但前面的扫描和读取白白消耗了几万 token。我的做法很固定如果问题明确指向某个文件就直接在指令里带上文件路径禁止它额外读文件。如果问题需要跨文件排查我会限制它先只读目录结构和目标文件确认方向后再追加读取。项目里的 node_modules、构建产物、静态资源目录尽量通过 ignore 文件配置忽略掉避免被扫描进上下文。很多人会觉得“让 AI 自己看”更省心但省心的代价就是 token 失控。给工具规定一个明确的搜索边界既省钱也让它的回答更聚焦。2.3 把长期指令写进项目记忆文件第三个配置要点是把反复在对话里说的背景信息沉淀成项目级规则文件。比如“本项目的 API 风格是 xxx”“错误处理统一用 xxx 方式”“不要在代码里打印调试日志”。这些规则如果每次都在对话里重新说一遍就会变成每一轮对话的重复负担。写在项目记忆文件里则完全不同。工具会在每次启动时读取这个文件并且由于文件内容在会话中是稳定不变的这部分输入大概率会命中缓存。也就是说你等于用非常低的单位成本让它在每一轮对话里都能保持对你的项目的长期理解。这里有个很容易踩的坑不要频繁修改项目规则文件。缓存的前提是内容稳定如果你每隔几分钟改一次规则缓存就会反复失效相当于每次都把整份规则当作新内容重新算价。我一般会每周集中整理一次规则变更而不是想到一条改一条。3. 使用习惯省 token提示词与任务拆解3.1 提示词写得越好AI 走得弯路越少配置调好之后更大的省钱空间在使用习惯里。提示词是成本杠杆最高的一环。因为模型不是按“有效信息”收费而是按“生成的所有 token”收费输出内容里的每一个字都在花钱而且输出单价通常比输入更贵。我刚开始用的时候习惯问“这段代码有没有问题帮我优化一下”。这句话听起来没毛病但它太开放了。AI 会先分析一遍、再列三四个优化方向、每个方向给一段示例代码、最后再写个总结。几千 token 的输出里真正有用的可能就一小段。现在我一般这样限制输出指令里写明“只改 xxx 函数输出完整替换后的代码不要解释”。要求输出统一为 diff 格式而不是把整个文件内容打印一遍再贴回来。明确“如果不需要不要给我备选方案”。需要执行的时候直接说“改完保存”不要让它停在半路等你确认。输出约束每收紧一档省下的 token 都很可观。我曾经对比过同样一个修复任务开放提示词消耗了接近一万 token收紧之后只需要两千多。差的不是模型能力是我自己给的发挥空间太大。3.2 任务拆解与会话切割别让一次对话背太多锅很多人拿到需求就直接往命令行里丢比如“重构这个模块并补全测试”然后看着 AI 做了一半卡住。问题在于这种大型任务一旦在中途跑偏失败重试的代价是之前全部上下文的重复计价。更省钱的做法是把大任务拆成可以逐段验证的小步骤。我先让它分析现状并输出改动方案确认方向没问题再让它改第一处逻辑验证通过后再让它补测试。每完成一个可验证的里程碑就停下来评估是继续留在当前会话还是新开一个。任务拆解的另一个好处是如果方案本身有问题你只损失了分析步骤的成本而不是让 AI 带着错误方案一路执行到底。现实中很多巨额 token 账单都来自一个模糊大任务在错误方向上的反复横跳。拆小了至少每一次消耗都是可预期的。3.3 沉淀常用指令模板和自定义命令如果某个操作模式你一周要用三次以上就该把它沉淀成模板。比如“修复这个 bug 并加对应单测输出 diff不要解释”这种固定流程完全可以做成自定义命令或脚本每次调用只需要一句简短指令AI 会从预设模板里读取完整要求。这样做省钱的原因在于模板存储在本地或项目配置中AI 只需要读取一次后续调用都是短指令触发。而你在对话框里每次手动输入完整要求等于每次重新付一遍长提示词的输入费。别小看这部分日积月累占比不低。我习惯把团队常用的代码规范、提交信息格式、测试框架偏好这类信息全部沉淀到模板里。这样 AI 无需在每次对话中被重新教导一遍直接按规则执行出错率也更低。4. 会话管理缓存与记忆释放4.1 命中缓存是怎么回事前文提到过项目规则文件命中缓存这里展开讲一下缓存机制的整体逻辑。在同一个连续会话里历史对话内容会在每一轮请求中重复发送。这类工具通常对重复出现的输入有缓存机制也就是说如果前面几轮的内容没有变化模型服务端可以直接复用之前计算过的结果读取这部分 token 的单价会明显低于首次计算。这意味着一个反常识的结论同一会话内稳定比频繁变化更省钱。并不是聊得越多越贵而是聊得越“乱”越贵。如果你在一个会话里反复修改文件内容、不断推翻前面的需求旧缓存会频繁失效每轮都要重新计算大量内容成本飙升。所以会话管理的目标是尽力维持内容稳定在内容开始变得混乱之前及时收尾。4.2 什么时候该压缩什么时候直接开新会话当一轮对话变得越来越长时我一般会用一个很简单的判断标准如果这轮对话里我需要往回翻很久才能找到前面说了什么说明该处理了。处理方式有两种一种是压缩把前面的历史对话总结成一份精简摘要然后用摘要替代完整历史继续聊。这个操作本身会消耗一些 token但相比保留全部历史继续跑能省非常多。另一种是直接开新会话把必要的背景信息用简洁的几句话重新描述其他不需要的信息一概丢弃。我的经验是项目背景类信息适合带到新会话过程类细节适合压缩或直接删掉。比如“补丁已经改到哪个文件”这种过程信息留着没有任何价值新会话里你直接说当前需求就行。而“项目使用某某框架、代码风格如何”这类长期信息应该提前写在项目规则文件里而不是依赖会话历史。4.3 多会话并行时别忽略总量CLI 工具允许多个会话同时运行很多人会同时开五六个任务觉得各有各的上下文互不干扰。这个想法前半部分对后半部分不成立。虽然每个会话独立但它们共享同一个 token 额度。五个会话各自都累积了一堆历史后总额消耗是叠加的而且远高于你单任务的直觉感知。我在并行时会做一个简单动作限制同时活跃的会话数量不超过两三个任务完成一个就立刻关掉一个。长时间不用的会话干脆清掉避免它静静躺在后台却仍然占据活跃会话额度。如果多个任务确实需要共享项目背景我会依赖项目规则文件而不是在每个会话里反复描述。这样既让每个会话都能获得同样的背景信息又利用缓存降低了重复成本。5. 实测数据不同策略能省多少 token5.1 我验证过的三个典型场景为了确认这些方法不是玄学我用自己的项目做了几组对比测试。场景选的是日常开发里最常见的三类修单文件 bug 并补测试、跨文件小重构、让 AI 解释一段已有代码。每组都用默认配置跑一遍再用前面说的优化策略跑一遍记录 token 消耗量。口径说明一下我用的是工具自带的统计信息和 API 返回的 usage 字段统计的是结算口径的输入加输出 token 总数。每个场景在不同模型下的表现会有浮动我这里的数字是在同一模型档位下的对照结果目的是看比例而不是绝对数值。5.2 对比结果场景默认粗暴用法优化后用法降幅修单文件 bug 并补单测2850012800约 55%跨文件小规模重构7640035100约 54%分析一段 300 行代码的逻辑142005300约 62%默认粗暴用法指让 AI 自由探索代码库、不限制输出格式、长对话一路聊到底。优化后用法指限定读取文件范围、提示词明确输出 diff、任务完成后立刻压缩或重开会话。结果说明一个大头在代码库扫描和历史累积另一个大头在开放式的无约束输出。两项控制住之后一个典型任务省一半左右的 token 并不困难。如果再把模型档位选择加上遇到不太复杂的任务主动切轻档综合降幅能到六成以上。需要说明的是这个数据基于我自己项目的场景不同项目大小、不同模型版本、不同任务复杂度都会让绝对数字变化但省钱的相对逻辑是通用的读得越少、写得越短、历史越精简账单越好看。6. 常见问题与避坑清单6.1 问题速查表现象原因解决方案对话才几轮token 就消耗巨大文件扫描范围过大或每轮都重复读取大文件在指令中限制文件读取范围用 ignore 配置排除大目录AI 输出一堆解释和备选方案提示词没有约束输出格式明确要求只输出 diff 或最终结果不要解释和备选任务做到一半上下文就快满了单次会话塞入过多历史和小步骤及时压缩历史或者在任务切换时重开会话规则文件写了很多但费用反而上涨规则文件频繁修改缓存不断失效集中低频更新规则文件保持内容稳定多个任务同时跑耗费涨得飞快并发会话各自积累独立上下文限制并行会话数量任务完成立即关闭轻档模型反复试错还是做不对模型能力不足导致重试成本超支及时切换更强模型不要死磕6.2 几个容易被忽略的隐形消耗很多人在常规操作之外还会漏掉几个隐藏的 token 黑洞。第一个是计划与执行分离的模式。部分工具有先出方案再执行的流程如果不加控制你会在同一上下文里先让 AI 产出完整方案再让它按方案执行一遍等于同一份信息被处理了两次。如果任务规模不大建议直接执行省掉计划阶段的双倍消耗。第二个是交互过程中的反复确认。很多工具输出后会停下来等待你的批准每次停顿都相当于一次完整请求的往返。有些人习惯让 AI 每改几行代码就停下来问一句“这样可以吗”结果一次小修改花掉了十几次请求的消耗。第三个是复制粘贴操作带来的重复劳动。AI 把输出结果打印在终端里你把内容手动复制到编辑器保存下次对话里 AI 又读回这个文件。这一来一回同一段内容被记了多次费用。正确做法是让 AI 直接操作文件系统修改内容输出精简摘要或 diff而不要把大段文件内容打印出来再人工搬运。第四个容易忽视的是日志、报错信息这类内容。调试时贴一段超长报错给 AI 虽然方便但这个报错会作为新上下文加入会话并且在后续所有轮次中反复出现。一次两次无所谓反复调试同一问题的时候这段报错就成了持续烧钱的常驻人口。根据我个人经验每月 token 账单大幅下降的转折点是我把“让 AI 按需读取、按需输出”这两个习惯真正固化下来之后。现在我的默认工作流基本是小改动直接指定文件和轻档模型大任务先拆成可验证的小步骤会话超过一定轮次就压缩或重开项目规则文件每周集中维护一次。这套流程维持了两三个月账单稳定控制在优化前的三分之一左右而且代码质量没有下降反而因为上下文更干净出错的频率更低了。工具本身并不费钱费钱的是我们给了它太多自由发挥的空间。收紧边界它反而做得更好。