聊到 AI 编程工具Codex 和 Claude Code 这两兄弟应该没人陌生。身边不少朋友试过一次后反馈出奇一致好用但费 token看着控制台的用量统计唰唰往上跳心里真的会咯噔一下。其实我用了大半年账单一直压在比较舒服的水平核心不是少用而是搞清楚 token 到底烧在哪里然后用对的方法去管住它。这篇文章就把我自己验证过的一套节省思路完整摊开讲包含配置层面、会话习惯层面、提示词技巧层面还有一次完整的实操对比希望能帮你把每百万 token 都花在刀刃上。1. 先搞懂你手里的 token 是怎么烧掉的1.1 一次请求背后隐藏的账单结构很多人有个误解觉得我往对话框里输入 100 个字AI 回答 200 个字那就只消耗 300 个 token 左右。真实情况复杂得多因为这类工具不是简单的“一问一答”而是一个完整的上下文累加过程。在一轮会话中每发起一次请求实际上会把当前这个会话里的全部消息历史、系统提示、你刚才引用过的文件内容、工具执行后的输出结果都重新“喂”给模型。这意味着你让 AI 读了一个 800 行的文件那这 800 行代码的 token 并不会在这次回答结束后消失而会一直待在上下文里每一轮新请求都会重复计算一遍直到你 start 新会话或者手动压缩历史。我举个例子假设一个文件大概 600 行换算下来约 5000 个 token。你让 AI 读了这个文件后又连续对话了 8 轮那这 5000 token 可能在 9 次请求里反复出现粗算就是 45000 token 的输入消耗。再叠加每次模型的输出、系统声明、工具结果一次看起来“没聊几句”的会话背后可能已经烧掉几万甚至十几万 token。这不是工具黑心而是基于上下文窗口的实现机制模型每次都需要完整的背景才能保持一致性。1.2 输入侧比输出侧更容易失控看过 API 定价的朋友都知道很多模型输入 token 比输出 token 便宜不少但为什么编程场景下感觉反而是输入侧更烧钱因为输出是你可以控制的模型最多顶多写几千行代码、几百行解释但输入侧只要“你让它读文件”“你让它自动执行命令”这些行为出现几万 token 很容易就在一两轮内爆掉。一个很典型的场景AI 在修改代码时你把整个项目目录下的十几个相关文件都拖进上下文然后让它排查一个只涉及两个函数的问题。模型确实会忠实地读完所有文件但绝大部分内容与当前问题无关这些工作不会让答案更精准反而可能引入上下文噪声导致它误判。这种操作等于每次请求都在为无关内容买单。更要命的是工具自动执行产生的输出。有些工具允许 AI 自行运行 grep、find、查看日志、跑测试这些命令本身消耗不大但命令结果会完整塞进上下文。一个测试套件输出几百行堆栈信息一次就吃掉了大量 token。如果你的项目配置里允许 AI 无限制地运行命令那 token 消耗速度会非常惊人。1.3 两类工具的计费差异与共同痛点Codex 和 Claude Code 在计费方式上有些差异。Codex 通常和账号额度、订阅模式挂钩而 Claude Code 在 API 模式下按 token 计费订阅模式也有总量限制。但无论哪种模式从省钱角度看共同的痛点是上下文累积方式非常接近都是“会话越久、历史越多、单轮成本越高”。因此所有节流手段的本质都可以归结为一句话减少无意义的输入 token提高有效输出占比。接下来整套方法体系全是围绕这个原理展开的。2. 会话管理把上下文当成稀有资源经营2.1 长会话有收益但别让它野蛮生长不少人习惯一个会话里连续处理十几个任务先让 AI 生成一个函数然后让它改样式接着让它看日志再让它帮忙写提交信息——整天下来会话历史长得吓人早先的代码片段一遍遍重复计费。我的原则是一个会话只处理一个明确任务。任务完成了立刻开新会话。这不只是为了省 token更是为了质量。AI 在长上下文里容易被早前细节带偏尤其是当你中间改过需求后后面的话可能还在参考已经被推翻的旧逻辑。单任务会话能让上下文保持精简模型注意力更集中回复质量更高也更容易预测最终的 token 开销。当然也有例外比如重构一个跨模块功能时前面的设计决策会直接影响后面的实现这种情况下强行拆分会丢失有效信息反而不划算。我会给这类“必须长会话”的任务设置一个心理预算如果预计超过十轮交互我会采用 2.2 里的压缩手段中途“瘦身”。2.2 用压缩和总结主动给历史“瘦身”我在使用 Claude Code 时最常用的命令之一就是压缩历史。当感觉到会话已经聊了五六轮历史里塞满了打印结果、中间反馈、测试日志时我不会硬着头皮继续往下问而是主动触发压缩操作。压缩本质上是把之前的对话提炼成一份摘要替代掉全部原始消息。Codex 里也有类似的清理方式例如通过新建会话配合项目内文档来保持连续性或者在工具配置里手动清除无用对话片段。核心思路都是只保留对后续任务真正有约束力的结论把冗长的原过程扔掉。这里有个很关键的实操心得压缩后的摘要损失细节所以我会在压缩前把需要精确保留的信息写进项目说明文件比如端口配置、常量命名、依赖版本。等压缩完成后再让 AI 重新读这些信息既保证了连续性又不用为大量中间过程买单。2.3 主动给开放任务收尾防止“话痨模式”你肯定遇过这种情况明明只是让 AI 修一个 CSS 对齐问题它却开始帮你优化整个组件的 HTML 结构顺带还重构了一遍样式表输出一大堆不在需求范围内的代码。表面上看起来像赚到了实际上每一行都是输出 token重构后的代码你还得花时间 review等于双重成本。所以我在每次提问都会明确边界。像“只需要修改按钮的 margin 值不要改其他地方改完直接输出 diff”这类指令不仅能防止 AI 跑题还能让它少写不必要的解释。如果 AI 开始进行超出范围的改动我会立刻打断回复“停撤回那个改动只保留我要求的修改”及时止损。3. 配置文件把高频指令写成项目常量3.1 CLAUDE.md 不是摆设是省 token 的核心武器Claude Code 会读取项目中的 CLAUDE.md 文件作为系统级提示。很多人的这个文件要么空着要么是一段几百字的自然语言描述。我从实际使用中总结出一个观点这个文件应当被当成“项目常量的缓存”把那些反复在会话里强调的信息全部固化进去。举个例子我维护一个前端项目CLAUDE.md 里大致会写这些内容项目运行命令是 npm run dev单元测试统一用 vitest样式方案用 CSS Modules 而不是 tailwind不要在无需求时修改 tsconfig所有新函数必须附带 JSDoc。原来这些信息我每次开新会话都要重新跟 AI 说一遍每次几十到上百 token一天开二十个会话就是几千 token。现在一次性写入配置模型每次启动都会自动读到省掉的不仅是 token还有大量的重复输入时间和纠正成本。3.2 代码搜索引擎越精简反而越精确Codex 的使用逻辑和 Claude Code 不完全一致但同样支持通过项目上下文文件类似 AGENTS.md来固化规则。在配置这类文件时我建议把它当成“命令清单”而不是“说明文档”。用短句、关键词、规则条目每条独立且明确避免模棱两可或者长篇大论。我见过有人把 CLAUDE.md 写成一篇两千字的项目介绍夹杂了不少客套话和背景感慨。这些冗余内容会在每次请求中反复出现成了变相的“常驻消费”却对模型行为没有任何正向约束。配置文件每句话最好都能直接引导模型做出决策如果删掉某句话不会影响任何行为那这句话就是纯消耗。3.3 用权限规则管住自动执行避免日志轰炸这类 AI 编程工具通常允许配置命令白名单或权限策略这是很容易被忽略的一个省钱入口。默认情况下AI 可能会在分析问题时主动运行一串命令其中一些命令输出巨大。我建议在权限配置里做三件事。第一不允许 AI 自行运行耗时的测试命令凡是会输出超过几十行的命令一律先询问。第二限制读文件的行数比如要求默认只读前 200 行若要看全文件必须明确指定。第三凡是执行修改类操作写入文件、批量替换、安装依赖前必须经过确认。这能避免模型一股脑地替你跑完测试、打印出上千行报告后才发现测试本身跑错了环境白白烧掉大量 token。4. 提示词技巧让每一次输入都有高性价比产出4.1 用结构化输出指令减少废话编程工具里的模型很容易犯一个毛病解释太多。你问一个报错原因它洋洋洒洒写五百字分析再给三套解决方案最后附上推荐理由实际上你只需要第一套方案。这时候不是模型的锅是我们没有给出足够优秀的格式约束。我自己的常用指令模板很简单大概这样“只输出修改后的完整代码块不要解释原因不要提供备选方案”或者“先定位问题行用一句话说明原因然后直接给出修复命令”。越是精确的格式约束输出 token 越少AI 生成速度也越快因为模型不用在多个方案里纠结直接走最优路径。当然格式约束也不是越短越好。有些时候让 AI 提供一个测试用例的完整代码是值得的但你可以限定“只写一个用例不要生成测试套件”。核心思路是把输出的颗粒度控制在自己需要的那一层而不是让它自己决定。4.2 大任务切成小任务单线程推进一个大需求直接丢给 AI它会在上下文里无限发散。比如“帮我把这个后端服务的错误处理全面优化一下”这事涉及日志中间件、数据库错误、路由错误、第三方异常、统一响应结构。AI 可能会一次性给你输出十几个文件的改动即便内容都合理真正的 token 成本也高得离谱。更现实的问题是改动范围这么大你 review 成本也极大后续很容易返工。我现在的做法是拆解成三个会话来推进第一个会话专门设计统一错误码和响应规范只输出设计文档第二个会话负责实现中间件和基础异常类限定只改两个文件第三个会话再迁移现有路由错误处理逻辑逐个文件替换。每个会话的上下文都很干净模型不需要同时背着一堆中间状态token 开销反而是最低的因为几乎没有无效重复输入。4.3 引用文件时先定位再引用别把整个项目塞进去很多人图省事直接把整个文件夹拖进对话然后用自然语言描述“你看看哪个地方有问题”。这种方式几乎必然导致 token 浪费因为 AI 需要把整个目录结构解析进上下文然后挨个文件读取内容。哪怕是一百个文件的小项目一次全量读取可能就吃掉几万 token。正确姿势是先让 AI 用工具定位。比如用 find 或 grep 找到相关符号再用 sed 或 head 查看具体行范围。我唯一使用全文件引用的场景是当这个文件本身就是任务目标且行数较少时。如果你想让 AI 改一个 1500 行的大文件建议先让它输出行号索引再分段引用或者直接告诉它“只需要关注第 300-500 行”。5. 实操链路对比同一个 bug两种完全不同的账单5.1 浪费型做法全量喂文件来回试探为了更直观说明问题我模拟一个真实场景某个网页项目里点击按钮没有触发弹窗控制台报了一个引用错误。一个典型的浪费型排查过程是这样的第一步用户直接把整个 index.js 和 index.html 拖进对话共约 1200 行代码AI 为了理解全貌先把两个文件全部读取到上下文。随后 AI 开始分析输出了一大段可能性列表包括事件绑定问题、脚本加载顺序、语法错误、API 路径错误。用户看到没有命中要害又把相关 CSS 文件也发给 AIAI 继续加载更多内容。经过三轮来回AI 最终定位到是脚本加载顺序导致的事件绑定失败但它已经消耗了巨大的输入 token 来反复处理重复出现的完整文件内容。在这个过程里真正有价值的信息其实只有“事件绑定在脚本加载之前执行”这一句结论但为了得出这个结论模型处理了多次完整的页面源码而且用户的每一条追加消息都带着前面的全部历史重新发送。我用一个大致估算形容一下这个会话大概消耗了五、六万 token而其中至少四万 token 属于反复传输的冗余上下文。5.2 省钱型做法用精准工具定位再改同一个问题上我实际偏好的做法完全不一样。第一步让 AI 执行一条查询命令定位按钮点击绑定所在的位置只输出文件路径和行号。命令像这样grep -rn button --include*.js --include*.html .AI 输出几个匹配位置后我让它只读取关键文件里命中行附近的 30 行代码sed -n 80,110p index.js这样模型看到的上下文非常小却刚好包含事件绑定的关键逻辑。同时我再配合一句指令“检查这个脚本标签是否在 button 渲染之前加载如果加载顺序有问题给出修改后的一行 diff。”AI 几乎瞬间锁定了问题index.js 在 body 底部加载而按钮的事件绑定入口在 DOM 结构就绪前就执行了。最终输出只有一行修复建议再加上对应的代码改动。整个会话全程消耗不到一万 token前者的花费可能是后者的六倍以上但两者的最终结果完全一致。这就是“让模型少看无用的东西”带来的威力。5.3 在长任务中分段压缩的真实对比再分享一个稍大规模的案例。有一次我需要让 AI 帮我批量重构一个模块里的所有 API 调用统一从 fetch 替换为自定义请求封装。涉及九个文件改动明确但重复度高。如果直接在一个长会话里做到第四五个文件时上下文已经塞满了大量替换前后的 diff模型每处理一个文件都会把之前的全部替换记录再算一遍费用增长非常明显。我采取的做法是先把规则和封装方法的用法写好放进文档然后用一个新会话处理前三个文件完成后立刻在新会话开始前压缩上下文只保留一份“已完成的文件清单和统一替换规则摘要”。接着再开新会话处理下三个文件重复操作。最后校验时只让 AI 读取改动后的文件 diff 做一次总检查。整体 token 消耗大概只有一口气做完方案的三分之一而且每个阶段的 AI 响应速度明显更快因为它的上下文里没有堆积如山的旧 diff。6. 常见问题排查与避坑技巧6.1 为什么明明没聊两句计费却那么高这是新手最容易困惑的问题。实际上一次耗时较长的工具调用比如 AI 自动跑了测试、安装了依赖、读了一堆配置文件这在后台已经产生了大量输入 token。你不会在交互界面上直接看到中文描述但那笔消耗真实存在。排查思路是打开用量统计面板看看哪些请求的输入 token 特别大再回溯那段时间工具做了什么操作。通常罪魁祸首就是“自动读取文件自动执行命令”的组合行为。6.2 压缩历史后 AI 不记得关键信息怎么办压缩本质是有损的尤其对于精确的数字、端口、变量名这种没有逻辑连贯性的信息摘要很可能丢掉。我的方案是在压缩前的最后一条消息里把后续必须保留的关键信息以清单形式放在显眼处或者直接写入 CLAUDE.md 和 AGENTS.md。压缩后如果发现它忘了某个参数不要重新解释全流程只要把那个参数以单独信息直接喂给它就可以。6.3 长输出被中断之前消耗的 token 还能挽回吗很多人觉得 AI 还在生成时手动按停止就会把已生成的内容也省掉。其实如果接口是按流式逐 token 计费生成多少就算多少中断只能阻止后续更多输出。所以“中断”这个动作的价值不是挽回已生成的成本而是避免它继续往无关方向输出。我遇到 AI 开始跑偏时会立刻中断并给它一个明确的方向收束这比等它全部说完再纠正要省很多。6.4 常见省钱行为误区速查操作看起来像省钱实际效果整份文件直接粘贴进对话省了定位时间大量无关 token 进入上下文并反复计费一个大需求让 AI 一次性实现省了拆解时间模型多文件输出、多轮修正代价极高频繁按中断键乱敲感觉在控制输出只在 AI 跑偏时有意义正常输出中断反而浪费完全不使用任何工具调用感觉少触发执行费用会导致模型靠猜低效对话反而更多压缩历史后不补充关键信息省了几句话后续模型可能失忆返工成本更高7. 最后再分享一点个人体会工具用了这么久我最大的心得是节省 token 并不是让自己少用 AI而是减少无意义的重复信息流。判断效率的标准很简单——如果模型每次请求都能获得恰好解决问题的那部分信息它就是省钱的如果你在对话里反复粘贴大块代码、让它重复读取相同文件那就算提示词写得再漂亮也省不下来。现在我自己已经养成了一个肌肉记忆开新会话前先想清楚目标明确边界进入会话后先让工具定位再读文件会话长了就果断压跨任务就果断拆。这一套流程跑下来实际效率可能比一开始“大方投喂”的方式反而更高因为 AI 在干净上下文下的正确率更高返工频次明显降低。如果你也在为 token 账单发愁建议先从“少贴文件、多用定位、单任务单会话”这三个习惯开始应该很快就能看到变化。