我自己用codex和claude code写代码有一段时间了，坦白说这两款AI编码工具确实好用，但token消耗的速度也很真实。尤其是当你在一个稍微大点的项目里跑一个跨文件重构，可能一个上午就能把几天额度烧掉大半。我身边就有朋友遇到这种情况——原本觉得“AI写代码又不贵”，看了账单才知道不是那么回事。其实节省token这件事，核心不是去抠一个个tokens，而是搞清楚token到底消耗在哪几个环节，然后从策略层面避开那些浪费大户。这篇文章我按自己踩坑的顺序来写：先算清楚账，再讲具体怎么省，最后附上我实测过的一些配置和排查经验。内容以codex和claude code为主，但思路对其他基于大模型的编码代理工具一样适用。1. token消耗的三笔大头：先搞清楚钱花在哪1.1 固定开销：每轮请求都会走一遍的系统提示与工具定义很多人的直觉是：发给AI的指令越少，token消耗就越少。这话对了一半。实际上，在使用codex或claude code这类“代理式（agentic）编码工具”时，每一轮请求都带有一大块“固定开销”，跟你这个请求本身说了什么基本无关。这块固定开销由几部分组成：系统提示（system prompt）、工具定义（tool schema）、当前环境信息（平台信息、编辑器状态等），以及项目的记忆文件内容。以claude code为例，它每轮请求都会把系统提示、可用工具列表以及当前项目的CLAUDE.md内容一起发给模型。这些内容加起来，轻则几千token，重则上万token。也就是说，哪怕你只是让AI帮你把某个文件里的一行注释改一下，背后也会产生好几千token的请求量。codex的情况类似，它的CLI客户端同样维护着工具调用协议，每次请求都要带上一整套工具定义。这块开销在单次请求里你感受不到，但如果你一天发起几百次请求，累积起来就是一个相当大的数字。所以这里有个反直觉的结论：减少请求轮次，比减少单次输入的文本量更有效。一次把需求讲清楚，让AI少做几次“确认-修改-再确认”的循环，省下的token远比你字斟句酌那一两句话多得多。1.2 浮动开销：让AI自由探索文件，是最烧钱的行为如果说系统提示是固定开销，那文件读取就是最不可控的“浮动开销”。代理式编码工具的一个重要特征是它会自己去读文件、跑命令、看输出，再根据结果决定下一步动作。这个能力非常强，也非常烧token。举个我实际遇到的例子。有一次让claude code帮忙改一个后端服务的日志模块，它为了理解日志配置是在哪里加载的，先后读取了配置文件、初始化入口、几个util文件，还跑了一次grep去定位logger的调用点。单看每一步都合理，但累计下来，一次小改动消耗了两万多个token。如果我自己先把相关文件路径告诉它，让它只读那两三个关键文件，这个开销至少能压缩一半。我把“文件读取”列为所有token消耗来源里的第一名。聊天文本、工具调用定义都是小头，AI替你翻文件才是大头。你的项目越大、文件越多，这个现象越明显。尤其在monorepo架构的项目里，如果AI没有方向地搜索，它可能一口气扫十几个目录，这波探索完，任务还没正式开始，账单已经先涨起来了。1.3 输出开销：模型写给你的解释和自省，也在按token计费最后一个被普遍低估的消耗来源是模型输出。两个工具的计费方式都是输入输出双向计费，输出token的单价通常比输入还高。当一个模型被设定为“默认做详细解释”的模式时，它会在给出代码之前先写上一大段分析，这些内容全部按输出token计费。我观察过自己多次会话的记录，模型输出里的“思考过程”和“额外解释”占了相当比例。尤其是当系统提示没有明确约束输出风格时，模型倾向于把它的推理过程、备选方案、注意事项全部吐出来。这些信息不是完全没用，但对于只想快速拿到改动结果的人来说，属于可以砍掉的成本。从机制上说，AI编码工具在给你最终回答之前，往往还要经历多轮“内部思考”或“ReAct循环”，每一轮内部循环都会产生新的token消耗。这也是为什么你感觉“它明明没干什么，怎么用了这么多token”的另一个原因。所以，在配置上限制思考深度和输出长度，是省token的一个有效手段，后面我会详细展开。2. 上下文瘦身三板斧：从对话机制上省2.1 用记忆文件承载项目约束，别每轮都解释在codex和claude code这类工具里，项目级别的“记忆文件”是一个非常重要的机制。claude code认的是CLAUDE.md，codex也支持类似的项目说明文件（比如AGENTS.md）。你放在这个文件里的内容，会在每轮请求中被自动注入上下文，相当于给AI配了一本“项目操作手册”。很多人用不好这个文件，最常见的错误是写得过于啰嗦。我见过有人把CLAUDE.md当成项目文档库，里面放了完整的模块说明、接口文档甚至有代码示例，整个文件几百行。这个文件每行都会变成token消耗，等于给项目永久挂了一个高额账单。正确做法是只保留“模型每次调用时都需要知道”的精炼信息。我自己的习惯是控制在60到100行以内，内容分三类：项目的构建与测试命令：比如构建用哪个命令、测试怎么跑、lint规则有什么特殊之处。目录结构的简要说明：关键代码在哪个目录，配置文件在哪，避免模型自己漫无目的地去翻。必须遵守的约束条件：比如某些文件禁止修改、某种模式不允许用、某个第三方库的版本有坑。我自己的CLAUDE.md大致长这样：# 项目操作手册 ## 构建与测试 - 安装依赖：npm install - 运行测试：npm test -- --runInBand - 代码检查：npm run lint ## 目录说明 - src/services：业务服务层，支付相关逻辑在此 - src/utils：通用工具函数 - config/：运行时配置 ## 约束 - 不要修改 src/utils/date.js，内部格式化的历史逻辑不可变动 - 所有新代码必须使用 async/await，禁止 .then 链式调用 - 配置文件统一走 config/index.js 导出的常量，不新增散落配置这样做的收益在于，模型拿到的是经过提炼的项目“操作手册”，而不是原始代码库全貌。它不用每次询问基础信息，也不用自己到处探索，自然省下大量文件读取和来回确认的token。2.2 精确锁定文件，让“探索模式”失效第二个策略说起来简单，做起来需要一点习惯上的调整：尽量在最初的提示里就把相关文件和要修改的范围写清楚。原则上，不要对AI说“帮我看一下这个项目”或者“找到所有相关的代码”。这种开放式指令会让工具进入探索模式，而这个模式的背后就是海量的目录扫描、文件读取、grep搜索，每一步都是token。更好的方式是类似这样：修改 src/services/payment.js，让支付超时时间从30秒改成60秒。相关配置在同目录的config.js里，处理超时的函数是processPaymentTimeout()。改完后运行npm test验证。这条提示里给了明确的文件路径、函数名、验证方式，模型基本不需要额外探索，两三个请求就能完成整个任务。反观如果只说“把支付超时改长一点”，AI会先去找支付逻辑写在哪，再读配置文件，再确认超时参数名，一个循环下来很可能已经耗掉几千token。有人可能会说，我有时候自己也不知道该改哪个文件。这种情况很正常，我的处理方式是分步进行：第一步用对话模式，只问“支付超时的逻辑在哪个文件里”，这一步开销很小。拿到文件路径后，再在真正的工作会话里给出明确路径。不要让自己找文件和改文件的任务混在同一个长对话里——找文件的过程会产生大量无用的中间上下文，拖累后面每一次请求。2.3 大任务拆成检查点，一个会话只办一件事这是一个我用了很久才养成的习惯：每个会话只做一个任务。如果那个任务足够大，就把它拆成几个连续的步骤，每个步骤单独开一个会话。这样做的主要原因在于上下文长度的累积效应。对话越长，模型能参考的历史就越多，但代价是每一轮请求都要把整个历史重新发送一遍。举个例子，一个会话经历了30轮对话，假设平均每轮历史增长500 token，那么第30轮请求的输入里光是历史就有大约15000 token，加上系统提示和文件内容，一轮就是两万多token。如果你把这个任务拆成三个各10轮的小会话，总消耗可能只有之前的一半。具体操作上，我比较推荐“检查点”式的写法。比如一个重构任务，我先新开会话说“完成第一步：提取payment模块中的策略接口”，等AI做完了，我用一个简短会话确认结果，然后让AI把所有变更总结到一个CHECKPOINT.md文件里。接下来第二个会话开始时不提任何历史，只说“根据CHECKPOINT.md里的当前状态，继续完成第二步”。这个文件的token开销很小，但能让AI在新会话里快速进入状态，避免重读大量代码或重复之前的工作。3. 配置调优：模型、输出、压缩的设置经验3.1 模型选型：简单任务用轻量模型，复杂任务才上旗舰codex和claude code都提供了多个模型选项，而模型之间在价格上差距悬殊。以我的实际体验，简单任务和复杂任务分开选模型，能省下一大笔费用。对于解释代码、写单元测试、改配置、补注释这类的低复杂度任务，我用较轻量的模型就足够了。这类模型的单价可能只有旗舰模型的十分之一甚至更低。只有跨文件重构、调试复杂并发问题、设计系统方案这类高难度任务，才值得用最强的旗舰模型。很多人的误区是一味追求“最强模型最准”，但从实际效果看，简单任务用轻量模型和用旗舰模型差距没那么大，可价格差了几倍到十倍。我自己的习惯是按照任务类型在会话启动时就指定模型，而不是一路用最贵的顶到底。还有一个细节：如果你使用的是按量计费的API，模型切换的成本是实打实的；如果你走的是订阅制，虽然每个请求不单独计费，但订阅额度会被更贵的模型更快耗尽。无论哪种计费方式，按任务难度选模型都是划算的。3.2 限制思考与输出，把模型从“话痨”调成“干脆”先说明一点，这个层面和具体工具版本有直接关系，但大方向是一致的：现代编码代理模型越来越多支持“思考token上限”和“输出token上限”的配置，这两个参数对token消耗影响很大。思考token是模型在给出正式回答之前，内部推理过程中产生的token。它的作用是让模型把问题想清楚，但对简单任务来说，不必要的长思考会白白增加消耗。比如让AI改一行配置，它可能仍然花上几千token去“推理”。在支持该参数的工具里，我会把默认思考上限控制在中等档位，仅当遇到复杂调试时才临时调高。输出token上限（max output tokens）也是同理。默认情况下，工具给AI留了很大的回答空间，AI也会倾向于把回答写得很长。我把输出上限设置到一个“够用”的范围，同时通过提示词要求AI“直接给出修改后的代码，不要长篇解释”，能在很长一段时间里把单轮输出控制在很低的水平。以codex的配置文件为例，大致可以这样调：# ~/.codex/config.toml 中按项目或全局调整 model = "gpt-5-mini-codex" max_output_tokens = 2000claude code这边我一般用环境变量或启动参数控制：export CLAUDE_CODE_MAX_OUTPUT_TOKENS=2000 export MAX_THINKING_TOKENS=4000有人在操作时会担心限制太多会让AI答不完整。我的实际经验是，只要任务本身不大，输出限制大部分时候不会触发。真正触发截断的情况往往是任务本身太大——这本身就说明你该拆任务了，而不是怪输出限制。3.3 compact的正确使用姿势：什么时候压缩，什么时候重启当对话变长以后，两个工具都提供了上下文压缩或清理的机制。claude code里有/compact命令，codex也有会话清理和平移的机制。这个功能理解起来简单：它把前面的对话历史做一个精炼摘要，用这个摘要替换掉原始历史，让后续请求的上下文大幅缩小。但这里有一个很多人没注意到的点：与其等对话变得很长再手动compact，不如主动在关键节点做“轻量压缩”。我的节奏是：每完成一个子任务，就执行一次compact，把中间产出的探索过程、试错记录都收进去。这样一来，新的一轮工作开始时上下文里只有足够的摘要，而不是一大坨原始操作日志。这里还要注意，compact本身也是有成本的——生成摘要的那次模型调用同样消耗token，而且摘要越长越贵。所以我自己的判断标准很简单：如果旧对话里还有需要保留的信息，就compact；如果接下来要做的事跟前半段对话基本无关，直接新开会话，别在旧会话里修修补补。4. 一次完整实操复盘：重构支付模块花了多少token4.1 开工前准备：人工定位关键文件，价值被低估的一步为了让大家有更直观的感受，我用最近一次实际的维护任务来复盘完整过程。某项目的支付模块需要从旧的回调处理方式迁移到新的异步事件驱动架构，涉及大概6个文件，其中核心逻辑在payService.js和eventBus.js两个文件里。按照我前面说的方法，我第一步没有让工具直接动手，而是先自己用编辑器简单定位了回调注册的关键代码位置，大概花了几分钟。这几分钟看起来是“浪费”，但省下的token远比这几分钟值钱——如果让AI自己去找，它大概率会把config、controller、repository这几个目录扫一遍，然后还要再读好几个文件才能确定改动范围。在大的代码库里，这种探索的token成本非常高。定位完成后，我把关键信息写进了提示词：要改的文件列表、核心函数名、新架构的约束条件（比如不能在回调里执行异步任务）。这个准备工作让模型的第一次请求就直接命中目标，而不是从猜测开始。4.2 会话内执行纪律：只读指定文件、改一步停一步接下来我新开会话，提示里写清了要改的文件列表、核心函数名、以及新架构的约束条件。整个会话我只让它做了四件事：迁移核心回调逻辑、调整事件发布部分的调用、更新单元测试、跑测试验证。每一步之间我都明确下一个动作，不需要它自己猜测。关键的执行纪律有两条。第一条是“不探索、只执行”，我在提示里直接写了“不要搜索项目中其他位置的代码，除非测试失败，否则不额外读取文件”。这个指令把AI的行为边界框住了，省掉了大量无意义的文件读取。第二条是“改一步、停一步”。我没有让AI一口气把6个文件全部改完再验证，而是让它先改核心两个文件，跑测试，成功后再扩展。这样做每轮上下文都能保持精简，避免出现“改了A文件但B文件报错，AI又回去重读A文件”的重复开销。全程下来大约13轮对话，token消耗大约四万，其中文件读取占了大头，但因为范围明确，没有出现失控的暴涨。4.3 对比账：省token操作与非省token操作差了三倍任务完成后，我按同样的逻辑估算了一下如果不做控制会发生什么：让AI自由探索、自由决定改动顺序、全程不拆会话、不限制输出风格。我估算同样的任务可能要烧掉12万到15万token，是实际消耗的三倍以上。这个差距在经济账上非常可观。这个对比不是严格的对照实验，但方向上足够说明问题。token消耗的大头从来不是“你和AI说了什么”，而是“AI为了完成任务自己做了什么”。只要把这个变量控制住，消耗就能显著降下来。我在复盘里最深的体会是：花几分钟自己定位文件，可能是整个过程中性价比最高的动作。5. 常见问题与排查技巧实录5.1 没干多少活，token却烧很快？先查这五个环节如果你经常遇到这个情况，先别急着怀疑工具是不是出了问题，大概率是下面几个原因之一：任务提示过于开放，导致AI大量探索性读取文件。一个会话里积累了太多历史，每轮请求的输入都在膨胀。模型输出长篇解释，甚至反复自问自答。用了最贵的模型，但任务难度其实用轻量模型就能完成。记忆文件或系统配置里放了大量非必要指令。排查方法很简单，查看工具自带的用量统计或token计数，重点看输入token里“系统提示”、“工具调用”、“历史消息”和“文件内容”各自占比。哪一项高，就针对哪一项调整。我自己第一次做这个分析时也吓了一跳，有几次会话“文件内容”一项居然占了70%以上，那明显就是探索行为过多的信号。5.2 对话变长了，压缩还是重启？我用的判断标准这个问题我回答过至少三次：如果用完一个会话后发现上下文已经很长，下一步该做的是判断“接下来的任务是否需要依赖这段历史”。如果还需要依赖历史，比如“继续把刚才那个模块的测试补完”，那就进行压缩而不是重启。如果接下来的任务和前面只是同一个大项目的不同子任务，果断重启新会话，必要时把上一个会话的关键产出写成摘要文件，新会话里去读那个文件。有一点要提醒：压缩并不是完全无损的。模型生成的摘要可能会丢掉细粒度的重要信息，如果你的后续任务高度依赖某些具体细节，最好在压缩前把那部分内容再强调一遍，或者直接放在新提示里。5.3 怎么让AI闭嘴干活：三条实测有效的提示词写法最后分享几个我实测有效的提示词写法，都是针对输出控制的。“对改动过的每个文件，只输出diff级别的修改说明，不要输出完整文件内容。”这一句非常管用，能避免AI为了“确保上下文完整”把整个文件搬进回答里。“如果任务已完成，直接说完成，不要给优化建议。”这句话能有效截断AI在结尾处的“贴心建议”环节。别小看这个环节，模型经常会额外输出几百上千token的优化建议，而这些建议你多半不会立即采纳。“不要总结你的思考过程。”在编码任务中，关闭模型对思考过程的复述，能显著降低输出token。需要注意的是，这里的“思考过程复述”和模型内置的思考token是两回事，前者是明面上的输出，后者是内部推理，前者优先级更高，改动效果也最直接。这里也顺带提醒一句，三条提示词要配合任务实际情况使用。如果任务本身很复杂，适当的解释是有价值的，强行让它闭嘴反而会增加返工风险。省token的目的是高效，不是为了省而省。我觉得最核心的一条经验，是把“省token”当作一个设计问题而不是抠字问题来对待。你不需要在每句话里删减字词，你需要做的是减少AI的无谓探索、减少长对话中的历史膨胀、减少高成本模型的低价值任务。这三个方向抓稳了，token消耗自然能降下来一大截。我自己从最开始的一个月被token账单吓了一跳，到现在基本能控制在合理区间，靠的就是这套组合拳：任务拆细、上下文剪薄、模型按需选择、输出严格约束。这些方法用在codex和claude code上都行得通，换到其他类似的AI编码工具上思路也一样。如果你正在被token账单困扰，不妨先从“问自己一个问题”开始：这次会话里，有多少token是花在了探索上？找出那些探索，把它们变成明确的指令，省下来的就是实打实的成本。
我自己用codex和claude code写代码有一段时间了，坦白说这两款AI编码工具确实好用，但token消耗的速度也很真实。尤其是当你在一个稍微大点的项目里跑一个跨文件重构，可能一个上午就能把几天额度烧掉大半。我身边就有朋友遇到这种情况——原本觉得“AI写代码又不贵”，看了账单才知道不是那么回事。其实节省token这件事，核心不是去抠一个个tokens，而是搞清楚token到底消耗在哪几个环节，然后从策略层面避开那些浪费大户。这篇文章我按自己踩坑的顺序来写：先算清楚账，再讲具体怎么省，最后附上我实测过的一些配置和排查经验。内容以codex和claude code为主，但思路对其他基于大模型的编码代理工具一样适用。1. token消耗的三笔大头：先搞清楚钱花在哪1.1 固定开销：每轮请求都会走一遍的系统提示与工具定义很多人的直觉是：发给AI的指令越少，token消耗就越少。这话对了一半。实际上，在使用codex或claude code这类“代理式（agentic）编码工具”时，每一轮请求都带有一大块“固定开销”，跟你这个请求本身说了什么基本无关。这块固定开销由几部分组成：系统提示（system prompt）、工具定义（tool schema）、当前环境信息（平台信息、编辑器状态等），以及项目的记忆文件内容。以claude code为例，它每轮请求都会把系统提示、可用工具列表以及当前项目的CLAUDE.md内容一起发给模型。这些内容加起来，轻则几千token，重则上万token。也就是说，哪怕你只是让AI帮你把某个文件里的一行注释改一下，背后也会产生好几千token的请求量。codex的情况类似，它的CLI客户端同样维护着工具调用协议，每次请求都要带上一整套工具定义。这块开销在单次请求里你感受不到，但如果你一天发起几百次请求，累积起来就是一个相当大的数字。所以这里有个反直觉的结论：减少请求轮次，比减少单次输入的文本量更有效。一次把需求讲清楚，让AI少做几次“确认-修改-再确认”的循环，省下的token远比你字斟句酌那一两句话多得多。1.2 浮动开销：让AI自由探索文件，是最烧钱的行为如果说系统提示是固定开销，那文件读取就是最不可控的“浮动开销”。代理式编码工具的一个重要特征是它会自己去读文件、跑命令、看输出，再根据结果决定下一步动作。这个能力非常强，也非常烧token。举个我实际遇到的例子。有一次让claude code帮忙改一个后端服务的日志模块，它为了理解日志配置是在哪里加载的，先后读取了配置文件、初始化入口、几个util文件，还跑了一次grep去定位logger的调用点。单看每一步都合理，但累计下来，一次小改动消耗了两万多个token。如果我自己先把相关文件路径告诉它，让它只读那两三个关键文件，这个开销至少能压缩一半。我把“文件读取”列为所有token消耗来源里的第一名。聊天文本、工具调用定义都是小头，AI替你翻文件才是大头。你的项目越大、文件越多，这个现象越明显。尤其在monorepo架构的项目里，如果AI没有方向地搜索，它可能一口气扫十几个目录，这波探索完，任务还没正式开始，账单已经先涨起来了。1.3 输出开销：模型写给你的解释和自省，也在按token计费最后一个被普遍低估的消耗来源是模型输出。两个工具的计费方式都是输入输出双向计费，输出token的单价通常比输入还高。当一个模型被设定为“默认做详细解释”的模式时，它会在给出代码之前先写上一大段分析，这些内容全部按输出token计费。我观察过自己多次会话的记录，模型输出里的“思考过程”和“额外解释”占了相当比例。尤其是当系统提示没有明确约束输出风格时，模型倾向于把它的推理过程、备选方案、注意事项全部吐出来。这些信息不是完全没用，但对于只想快速拿到改动结果的人来说，属于可以砍掉的成本。从机制上说，AI编码工具在给你最终回答之前，往往还要经历多轮“内部思考”或“ReAct循环”，每一轮内部循环都会产生新的token消耗。这也是为什么你感觉“它明明没干什么，怎么用了这么多token”的另一个原因。所以，在配置上限制思考深度和输出长度，是省token的一个有效手段，后面我会详细展开。2. 上下文瘦身三板斧：从对话机制上省2.1 用记忆文件承载项目约束，别每轮都解释在codex和claude code这类工具里，项目级别的“记忆文件”是一个非常重要的机制。claude code认的是CLAUDE.md，codex也支持类似的项目说明文件（比如AGENTS.md）。你放在这个文件里的内容，会在每轮请求中被自动注入上下文，相当于给AI配了一本“项目操作手册”。很多人用不好这个文件，最常见的错误是写得过于啰嗦。我见过有人把CLAUDE.md当成项目文档库，里面放了完整的模块说明、接口文档甚至有代码示例，整个文件几百行。这个文件每行都会变成token消耗，等于给项目永久挂了一个高额账单。正确做法是只保留“模型每次调用时都需要知道”的精炼信息。我自己的习惯是控制在60到100行以内，内容分三类：项目的构建与测试命令：比如构建用哪个命令、测试怎么跑、lint规则有什么特殊之处。目录结构的简要说明：关键代码在哪个目录，配置文件在哪，避免模型自己漫无目的地去翻。必须遵守的约束条件：比如某些文件禁止修改、某种模式不允许用、某个第三方库的版本有坑。我自己的CLAUDE.md大致长这样：# 项目操作手册 ## 构建与测试 - 安装依赖：npm install - 运行测试：npm test -- --runInBand - 代码检查：npm run lint ## 目录说明 - src/services：业务服务层，支付相关逻辑在此 - src/utils：通用工具函数 - config/：运行时配置 ## 约束 - 不要修改 src/utils/date.js，内部格式化的历史逻辑不可变动 - 所有新代码必须使用 async/await，禁止 .then 链式调用 - 配置文件统一走 config/index.js 导出的常量，不新增散落配置这样做的收益在于，模型拿到的是经过提炼的项目“操作手册”，而不是原始代码库全貌。它不用每次询问基础信息，也不用自己到处探索，自然省下大量文件读取和来回确认的token。2.2 精确锁定文件，让“探索模式”失效第二个策略说起来简单，做起来需要一点习惯上的调整：尽量在最初的提示里就把相关文件和要修改的范围写清楚。原则上，不要对AI说“帮我看一下这个项目”或者“找到所有相关的代码”。这种开放式指令会让工具进入探索模式，而这个模式的背后就是海量的目录扫描、文件读取、grep搜索，每一步都是token。更好的方式是类似这样：修改 src/services/payment.js，让支付超时时间从30秒改成60秒。相关配置在同目录的config.js里，处理超时的函数是processPaymentTimeout()。改完后运行npm test验证。这条提示里给了明确的文件路径、函数名、验证方式，模型基本不需要额外探索，两三个请求就能完成整个任务。反观如果只说“把支付超时改长一点”，AI会先去找支付逻辑写在哪，再读配置文件，再确认超时参数名，一个循环下来很可能已经耗掉几千token。有人可能会说，我有时候自己也不知道该改哪个文件。这种情况很正常，我的处理方式是分步进行：第一步用对话模式，只问“支付超时的逻辑在哪个文件里”，这一步开销很小。拿到文件路径后，再在真正的工作会话里给出明确路径。不要让自己找文件和改文件的任务混在同一个长对话里——找文件的过程会产生大量无用的中间上下文，拖累后面每一次请求。2.3 大任务拆成检查点，一个会话只办一件事这是一个我用了很久才养成的习惯：每个会话只做一个任务。如果那个任务足够大，就把它拆成几个连续的步骤，每个步骤单独开一个会话。这样做的主要原因在于上下文长度的累积效应。对话越长，模型能参考的历史就越多，但代价是每一轮请求都要把整个历史重新发送一遍。举个例子，一个会话经历了30轮对话，假设平均每轮历史增长500 token，那么第30轮请求的输入里光是历史就有大约15000 token，加上系统提示和文件内容，一轮就是两万多token。如果你把这个任务拆成三个各10轮的小会话，总消耗可能只有之前的一半。具体操作上，我比较推荐“检查点”式的写法。比如一个重构任务，我先新开会话说“完成第一步：提取payment模块中的策略接口”，等AI做完了，我用一个简短会话确认结果，然后让AI把所有变更总结到一个CHECKPOINT.md文件里。接下来第二个会话开始时不提任何历史，只说“根据CHECKPOINT.md里的当前状态，继续完成第二步”。这个文件的token开销很小，但能让AI在新会话里快速进入状态，避免重读大量代码或重复之前的工作。3. 配置调优：模型、输出、压缩的设置经验3.1 模型选型：简单任务用轻量模型，复杂任务才上旗舰codex和claude code都提供了多个模型选项，而模型之间在价格上差距悬殊。以我的实际体验，简单任务和复杂任务分开选模型，能省下一大笔费用。对于解释代码、写单元测试、改配置、补注释这类的低复杂度任务，我用较轻量的模型就足够了。这类模型的单价可能只有旗舰模型的十分之一甚至更低。只有跨文件重构、调试复杂并发问题、设计系统方案这类高难度任务，才值得用最强的旗舰模型。很多人的误区是一味追求“最强模型最准”，但从实际效果看，简单任务用轻量模型和用旗舰模型差距没那么大，可价格差了几倍到十倍。我自己的习惯是按照任务类型在会话启动时就指定模型，而不是一路用最贵的顶到底。还有一个细节：如果你使用的是按量计费的API，模型切换的成本是实打实的；如果你走的是订阅制，虽然每个请求不单独计费，但订阅额度会被更贵的模型更快耗尽。无论哪种计费方式，按任务难度选模型都是划算的。3.2 限制思考与输出，把模型从“话痨”调成“干脆”先说明一点，这个层面和具体工具版本有直接关系，但大方向是一致的：现代编码代理模型越来越多支持“思考token上限”和“输出token上限”的配置，这两个参数对token消耗影响很大。思考token是模型在给出正式回答之前，内部推理过程中产生的token。它的作用是让模型把问题想清楚，但对简单任务来说，不必要的长思考会白白增加消耗。比如让AI改一行配置，它可能仍然花上几千token去“推理”。在支持该参数的工具里，我会把默认思考上限控制在中等档位，仅当遇到复杂调试时才临时调高。输出token上限（max output tokens）也是同理。默认情况下，工具给AI留了很大的回答空间，AI也会倾向于把回答写得很长。我把输出上限设置到一个“够用”的范围，同时通过提示词要求AI“直接给出修改后的代码，不要长篇解释”，能在很长一段时间里把单轮输出控制在很低的水平。以codex的配置文件为例，大致可以这样调：# ~/.codex/config.toml 中按项目或全局调整 model = "gpt-5-mini-codex" max_output_tokens = 2000claude code这边我一般用环境变量或启动参数控制：export CLAUDE_CODE_MAX_OUTPUT_TOKENS=2000 export MAX_THINKING_TOKENS=4000有人在操作时会担心限制太多会让AI答不完整。我的实际经验是，只要任务本身不大，输出限制大部分时候不会触发。真正触发截断的情况往往是任务本身太大——这本身就说明你该拆任务了，而不是怪输出限制。3.3 compact的正确使用姿势：什么时候压缩，什么时候重启当对话变长以后，两个工具都提供了上下文压缩或清理的机制。claude code里有/compact命令，codex也有会话清理和平移的机制。这个功能理解起来简单：它把前面的对话历史做一个精炼摘要，用这个摘要替换掉原始历史，让后续请求的上下文大幅缩小。但这里有一个很多人没注意到的点：与其等对话变得很长再手动compact，不如主动在关键节点做“轻量压缩”。我的节奏是：每完成一个子任务，就执行一次compact，把中间产出的探索过程、试错记录都收进去。这样一来，新的一轮工作开始时上下文里只有足够的摘要，而不是一大坨原始操作日志。这里还要注意，compact本身也是有成本的——生成摘要的那次模型调用同样消耗token，而且摘要越长越贵。所以我自己的判断标准很简单：如果旧对话里还有需要保留的信息，就compact；如果接下来要做的事跟前半段对话基本无关，直接新开会话，别在旧会话里修修补补。4. 一次完整实操复盘：重构支付模块花了多少token4.1 开工前准备：人工定位关键文件，价值被低估的一步为了让大家有更直观的感受，我用最近一次实际的维护任务来复盘完整过程。某项目的支付模块需要从旧的回调处理方式迁移到新的异步事件驱动架构，涉及大概6个文件，其中核心逻辑在payService.js和eventBus.js两个文件里。按照我前面说的方法，我第一步没有让工具直接动手，而是先自己用编辑器简单定位了回调注册的关键代码位置，大概花了几分钟。这几分钟看起来是“浪费”，但省下的token远比这几分钟值钱——如果让AI自己去找，它大概率会把config、controller、repository这几个目录扫一遍，然后还要再读好几个文件才能确定改动范围。在大的代码库里，这种探索的token成本非常高。定位完成后，我把关键信息写进了提示词：要改的文件列表、核心函数名、新架构的约束条件（比如不能在回调里执行异步任务）。这个准备工作让模型的第一次请求就直接命中目标，而不是从猜测开始。4.2 会话内执行纪律：只读指定文件、改一步停一步接下来我新开会话，提示里写清了要改的文件列表、核心函数名、以及新架构的约束条件。整个会话我只让它做了四件事：迁移核心回调逻辑、调整事件发布部分的调用、更新单元测试、跑测试验证。每一步之间我都明确下一个动作，不需要它自己猜测。关键的执行纪律有两条。第一条是“不探索、只执行”，我在提示里直接写了“不要搜索项目中其他位置的代码，除非测试失败，否则不额外读取文件”。这个指令把AI的行为边界框住了，省掉了大量无意义的文件读取。第二条是“改一步、停一步”。我没有让AI一口气把6个文件全部改完再验证，而是让它先改核心两个文件，跑测试，成功后再扩展。这样做每轮上下文都能保持精简，避免出现“改了A文件但B文件报错，AI又回去重读A文件”的重复开销。全程下来大约13轮对话，token消耗大约四万，其中文件读取占了大头，但因为范围明确，没有出现失控的暴涨。4.3 对比账：省token操作与非省token操作差了三倍任务完成后，我按同样的逻辑估算了一下如果不做控制会发生什么：让AI自由探索、自由决定改动顺序、全程不拆会话、不限制输出风格。我估算同样的任务可能要烧掉12万到15万token，是实际消耗的三倍以上。这个差距在经济账上非常可观。这个对比不是严格的对照实验，但方向上足够说明问题。token消耗的大头从来不是“你和AI说了什么”，而是“AI为了完成任务自己做了什么”。只要把这个变量控制住，消耗就能显著降下来。我在复盘里最深的体会是：花几分钟自己定位文件，可能是整个过程中性价比最高的动作。5. 常见问题与排查技巧实录5.1 没干多少活，token却烧很快？先查这五个环节如果你经常遇到这个情况，先别急着怀疑工具是不是出了问题，大概率是下面几个原因之一：任务提示过于开放，导致AI大量探索性读取文件。一个会话里积累了太多历史，每轮请求的输入都在膨胀。模型输出长篇解释，甚至反复自问自答。用了最贵的模型，但任务难度其实用轻量模型就能完成。记忆文件或系统配置里放了大量非必要指令。排查方法很简单，查看工具自带的用量统计或token计数，重点看输入token里“系统提示”、“工具调用”、“历史消息”和“文件内容”各自占比。哪一项高，就针对哪一项调整。我自己第一次做这个分析时也吓了一跳，有几次会话“文件内容”一项居然占了70%以上，那明显就是探索行为过多的信号。5.2 对话变长了，压缩还是重启？我用的判断标准这个问题我回答过至少三次：如果用完一个会话后发现上下文已经很长，下一步该做的是判断“接下来的任务是否需要依赖这段历史”。如果还需要依赖历史，比如“继续把刚才那个模块的测试补完”，那就进行压缩而不是重启。如果接下来的任务和前面只是同一个大项目的不同子任务，果断重启新会话，必要时把上一个会话的关键产出写成摘要文件，新会话里去读那个文件。有一点要提醒：压缩并不是完全无损的。模型生成的摘要可能会丢掉细粒度的重要信息，如果你的后续任务高度依赖某些具体细节，最好在压缩前把那部分内容再强调一遍，或者直接放在新提示里。5.3 怎么让AI闭嘴干活：三条实测有效的提示词写法最后分享几个我实测有效的提示词写法，都是针对输出控制的。“对改动过的每个文件，只输出diff级别的修改说明，不要输出完整文件内容。”这一句非常管用，能避免AI为了“确保上下文完整”把整个文件搬进回答里。“如果任务已完成，直接说完成，不要给优化建议。”这句话能有效截断AI在结尾处的“贴心建议”环节。别小看这个环节，模型经常会额外输出几百上千token的优化建议，而这些建议你多半不会立即采纳。“不要总结你的思考过程。”在编码任务中，关闭模型对思考过程的复述，能显著降低输出token。需要注意的是，这里的“思考过程复述”和模型内置的思考token是两回事，前者是明面上的输出，后者是内部推理，前者优先级更高，改动效果也最直接。这里也顺带提醒一句，三条提示词要配合任务实际情况使用。如果任务本身很复杂，适当的解释是有价值的，强行让它闭嘴反而会增加返工风险。省token的目的是高效，不是为了省而省。我觉得最核心的一条经验，是把“省token”当作一个设计问题而不是抠字问题来对待。你不需要在每句话里删减字词，你需要做的是减少AI的无谓探索、减少长对话中的历史膨胀、减少高成本模型的低价值任务。这三个方向抓稳了，token消耗自然能降下来一大截。我自己从最开始的一个月被token账单吓了一跳，到现在基本能控制在合理区间，靠的就是这套组合拳：任务拆细、上下文剪薄、模型按需选择、输出严格约束。这些方法用在codex和claude code上都行得通，换到其他类似的AI编码工具上思路也一样。如果你正在被token账单困扰，不妨先从“问自己一个问题”开始：这次会话里，有多少token是花在了探索上？找出那些探索，把它们变成明确的指令，省下来的就是实打实的成本。