1. 三个工具摆在面前到底该选哪个1.1 先搞清楚这三个东西分别是什么ClaudeCode、Codex、OpenCode 这三个名字最近在开发者圈子里出现的频率越来越高但很多人其实分不太清它们之间的区别。我刚开始接触的时候也是一头雾水踩了不少坑才慢慢摸清楚。简单来说这三个都是基于大语言模型的代码辅助工具但定位和使用方式有本质差异。ClaudeCode 是 Anthropic 推出的终端侧编程助手它直接跑在你的命令行里能读写本地文件、执行命令、理解整个项目结构。Codex 是 OpenAI 体系的代码生成能力早期以补全为主后来逐步扩展到对话式编程。OpenCode 则是一个开源社区驱动的方案支持多种模型后端灵活性最高但配置也最复杂。这三个工具的核心成本都集中在 Token 消耗上。你每让模型读一次代码、生成一次回复、执行一次推理背后都是 Token 在燃烧。我实测过一个中等规模的 TypeScript 项目如果用法不当一天下来光 Token 费用就能顶上一顿不错的午饭。所以“节省 80% Token”这个目标不是锦上添花而是决定你能不能长期用下去的关键。1.2 为什么 Token 会不知不觉被烧掉很多人以为 Token 消耗主要来自自己的提问其实真正的大头在上下文携带上。每次你让工具执行一个任务它默认会把大量项目文件、历史对话、系统提示词一起打包发给模型。一个复杂任务跑下来输入 Token 可能是输出 Token 的几十倍。我做过一个粗略统计在一个包含约 200 个源文件的前端项目里如果不做任何优化单次任务的平均输入 Token 在 4 万到 8 万之间。按主流模型的定价一天跑 20 个任务成本相当可观。更麻烦的是很多工具默认会把整个对话历史都带上越聊越长Token 消耗呈指数级增长。所以省 Token 的核心思路就两条一是减少不必要的上下文携带二是把重复性的工作缓存起来避免重复计算。下面我会围绕这两条主线把三个工具各自的优化手段拆开讲。1.3 本文适合谁看如果你已经在用或者打算用这三个工具中的任意一个并且发现账单涨得比预期快那这篇内容就是写给你的。不管你是刚装好 ClaudeCode 还在摸索阶段还是已经用 Codex 跑了一段时间项目又或者正在折腾 OpenCode 的多模型配置下面的实操细节都能直接拿去用。我不打算只讲理论每个优化点都会配上具体的配置方法、参数说明和我自己踩过的坑。有些技巧是通用的三个工具都能用有些是针对特定工具的我会标注清楚。你不需要全部照搬挑适合自己工作流的就行。2. 上下文管理省 Token 的第一大刀2.1 理解上下文窗口的运作机制要省 Token首先得明白工具是怎么把代码发给模型的。绝大多数代码辅助工具的工作流程是这样的你发出一个指令工具根据指令去扫描相关文件把文件内容拼成一个巨大的提示词然后发给模型。模型看完之后返回结果工具再把结果应用到你的项目里。问题就出在“扫描相关文件”这一步。默认情况下工具的判断往往过于宽泛。你只是想改一个按钮的样式它可能把整个组件库的文件都读一遍。你只是想修一个 API 的返回值它可能把整个后端目录都塞进上下文。我见过最夸张的一次一个朋友让 ClaudeCode 帮忙改一行配置结果工具读取了 60 多个文件输入 Token 直接飙到 12 万。改完之后他看了一眼用量心疼得不行。这种情况完全可以通过配置来避免。2.2 用项目级配置文件圈定范围ClaudeCode 支持在项目根目录放一个配置文件用来告诉它哪些文件该读、哪些不该读。这个文件通常叫.claudeignore或者写在项目配置里。我的习惯是把以下几类东西全部排除构建产物目录比如dist、build、.next依赖目录比如node_modules、vendor静态资源比如图片、字体、视频文件日志和缓存文件自动生成的代码比如 protobuf 生成物、ORM 迁移文件排除这些之后工具扫描的文件数量通常能减少 60% 以上。我实测过一个 Next.js 项目排除前单次任务平均读取 180 个文件排除后降到 40 个左右输入 Token 直接砍掉七成。Codex 和 OpenCode 也有类似的机制。Codex 通过项目配置里的忽略规则来控制OpenCode 则是在配置文件里指定include和exclude模式。原理都一样让工具只看到真正相关的代码。2.3 手动指定文件比自动扫描更省自动扫描虽然方便但它是 Token 消耗的最大来源。我的做法是养成手动指定文件的习惯。比如我要改用户登录的逻辑我不会直接说“帮我优化登录”而是说“帮我优化src/auth/login.ts里的登录逻辑”。这样工具就只需要读这一个文件加上必要的依赖文件Token 消耗可能只有自动扫描的十分之一。刚开始可能会觉得麻烦但用久了你会发现明确指定文件反而让模型的输出更精准因为它不会被无关代码干扰。OpenCode 在这方面做得比较灵活它支持在对话里用符号引用具体文件。ClaudeCode 也支持类似的文件引用语法。Codex 在 IDE 插件里可以直接选中代码块再提问这种方式最省 Token因为上下文范围完全由你控制。2.4 控制对话历史的携带量对话历史是另一个隐形杀手。很多工具默认会把整个会话的历史都带上你聊了 50 轮第 51 轮就要把前面 50 轮全部重新发一遍。这不仅费 Token还会让模型注意力分散输出质量下降。我的做法是一个任务一个会话。任务完成就开新会话不要把不相关的事情混在一起聊。如果确实需要保留一些上下文我会手动把关键信息总结成一段话贴到新会话的开头而不是让工具自动携带全部历史。ClaudeCode 有一个/clear命令可以清空当前会话上下文我几乎每个任务结束后都会敲一下。Codex 在 IDE 里可以新建对话线程OpenCode 则是通过会话管理命令来切换。养成这个习惯之后我的平均单次任务 Token 消耗下降了大约 40%。注意清空上下文之前确保你已经把需要保留的信息记录下来了。我有一次清空之后才发现忘了保存模型给的一个关键建议只能重新问一遍反而多花了 Token。3. 缓存与复用让重复劳动不再重复花钱3.1 提示词缓存的工作原理主流模型服务商都提供了提示词缓存功能。简单说如果你连续多次请求的前面部分内容完全一样服务商可以把这部分缓存起来后续请求只对新增部分计费。缓存命中的部分费用通常只有正常价格的十分之一甚至更低。这个机制对代码辅助工具特别有用因为系统提示词、项目说明、常用工具定义这些内容在每次请求里都是重复的。如果工具支持缓存并且你保持这些内容不变就能省下大量 Token。ClaudeCode 对缓存的支持比较好它会自动把系统提示词和项目配置部分标记为可缓存。但前提是你不要频繁修改项目配置否则缓存会失效。我一般会在项目稳定之后才开启缓存优化开发初期配置变动频繁的时候反而不划算。3.2 把常用指令固化成模板另一个省 Token 的思路是减少重复提问。很多开发者每天都在问类似的问题“帮我写个单元测试”、“帮我 review 这段代码”、“帮我改个 bug”。这些问题每次都要重新描述一遍需求既费时间又费 Token。我的做法是建一个指令模板库把常用任务的提示词写好用的时候直接调用。比如我有一份“单元测试生成模板”里面包含了测试框架、断言风格、覆盖率要求等固定信息。每次需要写测试我只需要把目标文件路径填进去就行。这样做的另一个好处是输出质量稳定。因为模板里的提示词是经过反复打磨的比临时组织语言效果好得多。OpenCode 支持自定义命令可以把这些模板注册成快捷指令。ClaudeCode 可以通过项目配置文件预设常用提示词。Codex 则可以在 IDE 里保存代码片段模板。3.3 利用本地缓存减少重复读取除了服务商侧的缓存本地也可以做文章。有些工具会把读取过的文件内容缓存在本地下次需要时直接读缓存而不是重新扫描。这个功能在大型项目里效果特别明显。OpenCode 的本地缓存机制比较完善它会把文件索引和内容摘要存下来后续任务优先查缓存。ClaudeCode 也有类似机制但需要确保项目目录没有被频繁改动。我的经验是如果一个项目你连续几天都在开发本地缓存带来的 Token 节省能达到 30% 到 50%。不过要注意缓存失效的问题。如果你用 Git 切换了分支或者批量修改了大量文件记得让工具刷新缓存否则它可能基于旧内容做判断导致输出错误。我踩过一次坑切换分支后没刷新缓存工具基于旧分支的代码给建议结果完全对不上。3.4 批量任务合并处理如果你有一批类似的任务比如给 10 个文件分别加日志不要一个一个问。把需求合并成一次请求让工具批量处理。这样系统提示词和项目上下文只需要携带一次而不是十次。我试过给一个项目里的 15 个 API 路由文件统一添加错误处理。如果逐个提问每次都要带上项目配置和路由规范Token 消耗很大。合并成一次请求后总 Token 消耗只有逐个处理的四分之一左右。当然批量处理也有风险。如果任务太复杂模型可能顾此失彼输出质量下降。我的建议是简单重复性任务适合批量复杂逻辑任务还是单独处理更稳妥。4. 模型选择与参数调优把钱花在刀刃上4.1 不同任务用不同模型这是最容易被忽视的省 Token 手段。很多人不管什么任务都用最强的模型其实很多简单任务用轻量模型完全够用成本可能只有十分之一。我的分工策略是这样的代码补全、格式调整、简单重构用轻量模型复杂逻辑设计、架构评审、疑难 bug 排查用强模型。OpenCode 在这方面最灵活它支持在配置里为不同任务类型指定不同模型。ClaudeCode 和 Codex 虽然选择少一些但也支持在会话中切换模型。我实测过一个对比同一个重构任务用强模型消耗约 3 万 Token用轻量模型消耗约 8 千 Token而输出质量差距在可接受范围内。对于日常大量的简单任务这个差距累积起来非常可观。4.2 调整输出长度限制模型的输出 Token 通常比输入 Token 贵。如果你不限制输出长度模型可能会洋洋洒洒写一大堆你不需要的内容。我习惯在提示词里明确要求“只输出代码不要解释”或者“用不超过 50 字说明”。ClaudeCode 和 Codex 都支持在配置里设置最大输出 Token 数。OpenCode 则可以在每次请求时指定。把输出限制在合理范围内既能省钱又能让你更快找到关键信息。不过要注意限制太死可能导致模型输出被截断反而要重新问一次。我的经验是代码生成任务给 2000 到 4000 Token 的输出空间解释说明类任务给 500 到 1000 Token 就够了。4.3 温度参数与 Token 消耗的关系温度参数控制模型输出的随机性。温度越高输出越多样但也越容易跑偏导致你需要重新提问反而多花 Token。温度越低输出越确定通常一次就能得到可用结果。对于代码任务我一般把温度设在 0.1 到 0.3 之间。这个范围既能保证一定的灵活性又不会让模型太发散。OpenCode 允许在配置文件里为不同任务类型设置不同温度。ClaudeCode 和 Codex 的温度设置相对固定但可以通过提示词来间接影响。我做过一个实验同一个代码生成任务温度 0.7 时平均需要 2.3 次尝试才能得到满意结果温度 0.2 时平均 1.4 次。算上重试消耗的 Token低温设置反而更省。4.4 关闭不必要的功能开关很多工具默认开启了一些辅助功能比如自动补全、实时建议、后台索引等。这些功能在后台持续消耗 Token但你未必都需要。我的做法是只保留当前任务需要的功能。写代码的时候开补全读代码的时候关掉。OpenCode 的功能开关最细可以精确控制每个模块的启停。ClaudeCode 和 Codex 的开关少一些但也能通过配置关闭部分后台行为。有一个容易被忽略的点是自动保存和自动格式化。这些功能触发时可能会调用模型如果你手动保存的频率很高累积消耗也不小。我一般会关掉自动触发改成手动执行。5. 实操配置三个工具的具体优化步骤5.1 ClaudeCode 的省 Token 配置清单ClaudeCode 的配置主要集中在项目根目录的配置文件和用户级配置里。下面是我自己用的一套配置实测能省 60% 到 80% 的 Token。第一步是创建忽略文件。在项目根目录新建.claudeignore内容如下node_modules/ dist/ build/ .next/ coverage/ *.log *.lock *.min.js *.min.css public/assets/第二步是配置项目说明文件。在项目根目录创建CLAUDE.md简要说明项目结构、技术栈和常用命令。这个文件会被缓存所以内容要稳定不要频繁修改。第三步是调整会话设置。在用户配置里把默认模型设为轻量模型只在需要时手动切换到强模型。同时开启提示词缓存关闭自动索引。第四步是养成手动指定文件的习惯。每次提问都带上具体文件路径避免工具自动扫描整个项目。我用这套配置跑了一个月对比之前的用量Token 消耗下降了约 72%。最明显的改善来自忽略文件和手动指定文件这两项。5.2 Codex 的 Token 优化实操Codex 的优化重点在 IDE 插件的使用方式上。很多人习惯直接选中一段代码就提问这其实很费 Token因为插件会把整个文件甚至相关文件都带上。我的做法是尽量用行内补全而不是对话提问。行内补全的上下文范围小Token 消耗低。如果必须对话先把无关代码折叠起来只保留相关部分。Codex 的配置文件里可以设置上下文范围。我一般把自动上下文限制在 50 行以内超过的部分手动指定。另外Codex 的对话历史默认保留时间较长我建议在设置里改成任务结束后自动清理。还有一个技巧是利用 Codex 的代码片段功能。把常用的代码模式存成片段需要时直接插入而不是让模型重新生成。这样既省 Token 又保证风格一致。5.3 OpenCode 的多模型与缓存配置OpenCode 的灵活性最高配置空间也最大。下面是我推荐的一套配置思路。首先是模型路由配置。在配置文件里为不同任务类型指定不同模型models: completion: lightweight-model refactor: standard-model architecture: powerful-model debug: standard-model其次是缓存配置。开启本地文件缓存和提示词缓存设置合理的过期时间。我一般把文件缓存设为 24 小时提示词缓存设为 7 天。然后是会话管理。OpenCode 支持会话模板可以把常用任务的配置固化成模板。比如“代码审查模板”里预设好审查规则、输出格式、模型选择等参数。最后是输出控制。在配置里设置默认最大输出 Token 数避免模型输出过长。我一般设为 3000特殊任务再手动调高。5.4 三个工具的通用省 Token 习惯不管用哪个工具有些习惯是通用的。我总结了下面几条坚持下来效果很明显。任务开始前先想清楚要什么一次性把需求描述完整避免来回追问一个任务一个会话任务结束就清理上下文优先用文件引用而不是让工具自动扫描简单任务用轻量模型复杂任务才用强模型定期检查 Token 用量找出消耗最大的任务类型并针对性优化把重复性任务模板化减少每次重新描述的开销这些习惯看起来简单但真正坚持下来的人不多。我见过很多开发者一边抱怨 Token 贵一边继续用最费的方式提问。改变习惯需要一点时间但省下来的成本是实打实的。6. 常见问题与排查技巧实录6.1 Token 用量突然暴涨怎么排查Token 用量突然增加通常有几个原因。第一个是项目里新增了大量文件工具扫描范围扩大了。第二个是对话历史积累太多没有及时清理。第三个是某个任务触发了工具的自动索引或后台分析功能。排查方法很简单先看用量曲线找到暴涨的时间点然后回想那个时间点在做什么任务。如果是文件扫描问题检查忽略规则是否覆盖了新增目录。如果是对话历史问题清空会话重新开始。如果是后台功能问题去配置里关掉相关开关。我遇到过一次用量暴涨排查后发现是项目里新增了一个自动生成的 API 文档目录里面有上千个 Markdown 文件。工具每次任务都会扫描这个目录导致输入 Token 翻了好几倍。把该目录加入忽略列表后用量立刻恢复正常。6.2 缓存不生效的几种情况缓存不生效是最让人头疼的问题之一。明明配置了缓存用量却没降下来。常见原因有这几个项目配置文件被频繁修改导致缓存键变化文件内容变动太频繁缓存刚建立就失效缓存配置没有正确加载可能是路径写错了服务商侧的缓存策略调整需要重新适配排查的时候先确认配置文件路径和格式是否正确。然后检查最近有没有修改过项目说明文件。如果都没问题可以尝试手动清除缓存再重建。OpenCode 有缓存状态查看命令ClaudeCode 和 Codex 则需要看日志。6.3 模型切换后输出质量下降怎么办从强模型切到轻量模型后输出质量下降是正常的。关键是要判断下降程度是否可接受。我的做法是先用轻量模型跑一遍如果结果基本可用就手动微调如果完全不能用再切回强模型。为了提高轻量模型的输出质量可以在提示词里加更多约束。比如明确指定代码风格、给出示例、要求分步骤输出等。这些约束会增加一些输入 Token但相比直接用强模型还是划算的。另外不是所有任务都适合降级。涉及复杂业务逻辑、安全相关代码、架构设计这些任务我建议还是用强模型省下的 Token 不值得冒质量风险。6.4 多工具混用的 Token 管理有些开发者同时用多个工具比如 ClaudeCode 写代码、Codex 做补全、OpenCode 跑批量任务。这种情况下 Token 管理更复杂因为用量分散在不同平台。我的建议是统一在一个地方记录用量。可以建一个简单的表格每天记录各工具的消耗情况。这样能清楚看到哪个工具是消耗大户针对性优化。另外多工具混用时要注意上下文重复问题。同一个项目如果两个工具都做了索引等于同样的内容被读取了两次。我的做法是让一个工具做主索引其他工具通过文件引用共享避免重复扫描。问题类型典型表现排查方向解决方法用量暴涨单日消耗翻倍新增文件、对话历史、后台功能检查忽略规则、清理会话、关闭后台缓存失效配置了缓存但没效果配置路径、文件变动频率修正路径、稳定项目配置质量下降轻量模型输出不可用任务复杂度、提示词质量增加约束、必要时切回强模型多工具重复同一内容被多次读取索引配置、文件引用方式统一主索引、共享文件引用6.5 几个我踩过的坑和对应技巧第一个坑是忽略规则写得太宽泛把一些必要的配置文件也排除了导致工具理解不了项目结构。后来我改成精确排除只排除确定不需要的目录。第二个坑是缓存过期时间设得太短缓存刚建立就失效了等于白配。后来改成按项目活跃度动态调整活跃项目设短一些稳定项目设长一些。第三个坑是批量任务合并太多模型处理不过来输出质量很差反而要重新做。后来我控制批量规模一次不超过 5 个文件。第四个坑是忘了清理旧会话导致新任务带着一堆无关历史既费 Token 又影响输出。现在养成了任务结束就清理的习惯。这些经验看起来都是小事但累积起来对 Token 消耗的影响很大。省 Token 不是什么高深技术就是把每一个细节做到位积少成多。7. 把省 Token 变成肌肉记忆7.1 建立自己的用量监控习惯省 Token 不是一次性配置就完事而是需要持续关注和调整。我现在的习惯是每周看一次用量报告分析哪些任务消耗最大有没有优化空间。监控的重点不是绝对数字而是趋势。如果用量在上升就要找原因。是项目变大了是任务变复杂了还是用法退步了找到原因才能对症下药。我还会记录一些基准数据比如“改一个简单 bug 的平均 Token 消耗”、“生成一个单元测试的平均消耗”。有了基准就能快速判断某次用量是否异常。7.2 根据项目阶段调整策略项目不同阶段Token 优化策略也应该不同。开发初期项目结构变动频繁缓存效果差这时候重点应该放在减少扫描范围上。稳定期项目结构固定缓存效果好可以加大缓存利用。维护期任务以修 bug 为主重点是用轻量模型处理简单问题。我现在手上有三个项目分别处于不同阶段用的配置也不一样。初期项目忽略规则最严格稳定项目缓存配置最激进维护项目模型选择最保守。这样针对性调整之后整体用量比统一配置时低了约 35%。7.3 团队协作时的 Token 管理如果是团队使用Token 管理就更重要了。我建议团队统一配置规范把忽略文件、项目说明、常用模板都纳入版本控制。这样每个人用的都是优化过的配置不会因为个人习惯差异导致浪费。另外团队里可以指定一个人负责监控用量定期分享优化技巧。我见过一些团队因为没人关注 Token 消耗一个月下来费用高得离谱后来做了统一管理成本直接降了一半多。团队协作还有一个好处是可以共享缓存。如果多个成员用同样的项目配置服务商侧的缓存命中率会更高整体成本更低。7.4 持续关注工具更新带来的优化这三个工具都在快速迭代新版本经常会带来 Token 优化相关的新功能。我一般会关注官方更新日志看到有用的功能就及时升级配置。比如 ClaudeCode 最近几个版本在缓存机制上有明显改进升级后同样的任务用量下降了约 20%。OpenCode 的模型路由功能也是后来加的加上之后简单任务的成本大幅降低。不过升级也要谨慎新版本有时候会改变默认行为导致之前的优化失效。我的做法是先在测试项目上试确认没问题再推到正式项目。7.5 最后的几个实用建议如果你刚开始优化不要想着一步到位。先把忽略文件配好这是见效最快的。然后养成手动指定文件的习惯这个需要一点时间适应但效果显著。再之后是配置缓存和模型路由这些需要根据项目特点调整。如果你已经在用一段时间了建议做一次全面审计。把最近一个月的用量拉出来按任务类型分类看看哪些类型消耗最大。通常会发现一两个消耗大户针对性优化就能省下不少。还有一点很重要不要为了省 Token 牺牲开发效率。省 Token 的目的是让工具能长期用下去而不是让你花更多时间在配置上。找到一个平衡点让优化成为习惯而不是负担这才是可持续的做法。我在实际使用中发现真正省 Token 的高手不是配置最复杂的而是习惯最好的。他们知道什么时候该用强模型什么时候该用轻量模型什么时候该手动指定文件什么时候该清理上下文。这些判断已经变成了肌肉记忆不需要刻意去想。希望上面的内容能帮你走到这一步。
ClaudeCode、Codex、OpenCode 省 Token 实战：上下文管理与缓存优化指南
1. 三个工具摆在面前到底该选哪个1.1 先搞清楚这三个东西分别是什么ClaudeCode、Codex、OpenCode 这三个名字最近在开发者圈子里出现的频率越来越高但很多人其实分不太清它们之间的区别。我刚开始接触的时候也是一头雾水踩了不少坑才慢慢摸清楚。简单来说这三个都是基于大语言模型的代码辅助工具但定位和使用方式有本质差异。ClaudeCode 是 Anthropic 推出的终端侧编程助手它直接跑在你的命令行里能读写本地文件、执行命令、理解整个项目结构。Codex 是 OpenAI 体系的代码生成能力早期以补全为主后来逐步扩展到对话式编程。OpenCode 则是一个开源社区驱动的方案支持多种模型后端灵活性最高但配置也最复杂。这三个工具的核心成本都集中在 Token 消耗上。你每让模型读一次代码、生成一次回复、执行一次推理背后都是 Token 在燃烧。我实测过一个中等规模的 TypeScript 项目如果用法不当一天下来光 Token 费用就能顶上一顿不错的午饭。所以“节省 80% Token”这个目标不是锦上添花而是决定你能不能长期用下去的关键。1.2 为什么 Token 会不知不觉被烧掉很多人以为 Token 消耗主要来自自己的提问其实真正的大头在上下文携带上。每次你让工具执行一个任务它默认会把大量项目文件、历史对话、系统提示词一起打包发给模型。一个复杂任务跑下来输入 Token 可能是输出 Token 的几十倍。我做过一个粗略统计在一个包含约 200 个源文件的前端项目里如果不做任何优化单次任务的平均输入 Token 在 4 万到 8 万之间。按主流模型的定价一天跑 20 个任务成本相当可观。更麻烦的是很多工具默认会把整个对话历史都带上越聊越长Token 消耗呈指数级增长。所以省 Token 的核心思路就两条一是减少不必要的上下文携带二是把重复性的工作缓存起来避免重复计算。下面我会围绕这两条主线把三个工具各自的优化手段拆开讲。1.3 本文适合谁看如果你已经在用或者打算用这三个工具中的任意一个并且发现账单涨得比预期快那这篇内容就是写给你的。不管你是刚装好 ClaudeCode 还在摸索阶段还是已经用 Codex 跑了一段时间项目又或者正在折腾 OpenCode 的多模型配置下面的实操细节都能直接拿去用。我不打算只讲理论每个优化点都会配上具体的配置方法、参数说明和我自己踩过的坑。有些技巧是通用的三个工具都能用有些是针对特定工具的我会标注清楚。你不需要全部照搬挑适合自己工作流的就行。2. 上下文管理省 Token 的第一大刀2.1 理解上下文窗口的运作机制要省 Token首先得明白工具是怎么把代码发给模型的。绝大多数代码辅助工具的工作流程是这样的你发出一个指令工具根据指令去扫描相关文件把文件内容拼成一个巨大的提示词然后发给模型。模型看完之后返回结果工具再把结果应用到你的项目里。问题就出在“扫描相关文件”这一步。默认情况下工具的判断往往过于宽泛。你只是想改一个按钮的样式它可能把整个组件库的文件都读一遍。你只是想修一个 API 的返回值它可能把整个后端目录都塞进上下文。我见过最夸张的一次一个朋友让 ClaudeCode 帮忙改一行配置结果工具读取了 60 多个文件输入 Token 直接飙到 12 万。改完之后他看了一眼用量心疼得不行。这种情况完全可以通过配置来避免。2.2 用项目级配置文件圈定范围ClaudeCode 支持在项目根目录放一个配置文件用来告诉它哪些文件该读、哪些不该读。这个文件通常叫.claudeignore或者写在项目配置里。我的习惯是把以下几类东西全部排除构建产物目录比如dist、build、.next依赖目录比如node_modules、vendor静态资源比如图片、字体、视频文件日志和缓存文件自动生成的代码比如 protobuf 生成物、ORM 迁移文件排除这些之后工具扫描的文件数量通常能减少 60% 以上。我实测过一个 Next.js 项目排除前单次任务平均读取 180 个文件排除后降到 40 个左右输入 Token 直接砍掉七成。Codex 和 OpenCode 也有类似的机制。Codex 通过项目配置里的忽略规则来控制OpenCode 则是在配置文件里指定include和exclude模式。原理都一样让工具只看到真正相关的代码。2.3 手动指定文件比自动扫描更省自动扫描虽然方便但它是 Token 消耗的最大来源。我的做法是养成手动指定文件的习惯。比如我要改用户登录的逻辑我不会直接说“帮我优化登录”而是说“帮我优化src/auth/login.ts里的登录逻辑”。这样工具就只需要读这一个文件加上必要的依赖文件Token 消耗可能只有自动扫描的十分之一。刚开始可能会觉得麻烦但用久了你会发现明确指定文件反而让模型的输出更精准因为它不会被无关代码干扰。OpenCode 在这方面做得比较灵活它支持在对话里用符号引用具体文件。ClaudeCode 也支持类似的文件引用语法。Codex 在 IDE 插件里可以直接选中代码块再提问这种方式最省 Token因为上下文范围完全由你控制。2.4 控制对话历史的携带量对话历史是另一个隐形杀手。很多工具默认会把整个会话的历史都带上你聊了 50 轮第 51 轮就要把前面 50 轮全部重新发一遍。这不仅费 Token还会让模型注意力分散输出质量下降。我的做法是一个任务一个会话。任务完成就开新会话不要把不相关的事情混在一起聊。如果确实需要保留一些上下文我会手动把关键信息总结成一段话贴到新会话的开头而不是让工具自动携带全部历史。ClaudeCode 有一个/clear命令可以清空当前会话上下文我几乎每个任务结束后都会敲一下。Codex 在 IDE 里可以新建对话线程OpenCode 则是通过会话管理命令来切换。养成这个习惯之后我的平均单次任务 Token 消耗下降了大约 40%。注意清空上下文之前确保你已经把需要保留的信息记录下来了。我有一次清空之后才发现忘了保存模型给的一个关键建议只能重新问一遍反而多花了 Token。3. 缓存与复用让重复劳动不再重复花钱3.1 提示词缓存的工作原理主流模型服务商都提供了提示词缓存功能。简单说如果你连续多次请求的前面部分内容完全一样服务商可以把这部分缓存起来后续请求只对新增部分计费。缓存命中的部分费用通常只有正常价格的十分之一甚至更低。这个机制对代码辅助工具特别有用因为系统提示词、项目说明、常用工具定义这些内容在每次请求里都是重复的。如果工具支持缓存并且你保持这些内容不变就能省下大量 Token。ClaudeCode 对缓存的支持比较好它会自动把系统提示词和项目配置部分标记为可缓存。但前提是你不要频繁修改项目配置否则缓存会失效。我一般会在项目稳定之后才开启缓存优化开发初期配置变动频繁的时候反而不划算。3.2 把常用指令固化成模板另一个省 Token 的思路是减少重复提问。很多开发者每天都在问类似的问题“帮我写个单元测试”、“帮我 review 这段代码”、“帮我改个 bug”。这些问题每次都要重新描述一遍需求既费时间又费 Token。我的做法是建一个指令模板库把常用任务的提示词写好用的时候直接调用。比如我有一份“单元测试生成模板”里面包含了测试框架、断言风格、覆盖率要求等固定信息。每次需要写测试我只需要把目标文件路径填进去就行。这样做的另一个好处是输出质量稳定。因为模板里的提示词是经过反复打磨的比临时组织语言效果好得多。OpenCode 支持自定义命令可以把这些模板注册成快捷指令。ClaudeCode 可以通过项目配置文件预设常用提示词。Codex 则可以在 IDE 里保存代码片段模板。3.3 利用本地缓存减少重复读取除了服务商侧的缓存本地也可以做文章。有些工具会把读取过的文件内容缓存在本地下次需要时直接读缓存而不是重新扫描。这个功能在大型项目里效果特别明显。OpenCode 的本地缓存机制比较完善它会把文件索引和内容摘要存下来后续任务优先查缓存。ClaudeCode 也有类似机制但需要确保项目目录没有被频繁改动。我的经验是如果一个项目你连续几天都在开发本地缓存带来的 Token 节省能达到 30% 到 50%。不过要注意缓存失效的问题。如果你用 Git 切换了分支或者批量修改了大量文件记得让工具刷新缓存否则它可能基于旧内容做判断导致输出错误。我踩过一次坑切换分支后没刷新缓存工具基于旧分支的代码给建议结果完全对不上。3.4 批量任务合并处理如果你有一批类似的任务比如给 10 个文件分别加日志不要一个一个问。把需求合并成一次请求让工具批量处理。这样系统提示词和项目上下文只需要携带一次而不是十次。我试过给一个项目里的 15 个 API 路由文件统一添加错误处理。如果逐个提问每次都要带上项目配置和路由规范Token 消耗很大。合并成一次请求后总 Token 消耗只有逐个处理的四分之一左右。当然批量处理也有风险。如果任务太复杂模型可能顾此失彼输出质量下降。我的建议是简单重复性任务适合批量复杂逻辑任务还是单独处理更稳妥。4. 模型选择与参数调优把钱花在刀刃上4.1 不同任务用不同模型这是最容易被忽视的省 Token 手段。很多人不管什么任务都用最强的模型其实很多简单任务用轻量模型完全够用成本可能只有十分之一。我的分工策略是这样的代码补全、格式调整、简单重构用轻量模型复杂逻辑设计、架构评审、疑难 bug 排查用强模型。OpenCode 在这方面最灵活它支持在配置里为不同任务类型指定不同模型。ClaudeCode 和 Codex 虽然选择少一些但也支持在会话中切换模型。我实测过一个对比同一个重构任务用强模型消耗约 3 万 Token用轻量模型消耗约 8 千 Token而输出质量差距在可接受范围内。对于日常大量的简单任务这个差距累积起来非常可观。4.2 调整输出长度限制模型的输出 Token 通常比输入 Token 贵。如果你不限制输出长度模型可能会洋洋洒洒写一大堆你不需要的内容。我习惯在提示词里明确要求“只输出代码不要解释”或者“用不超过 50 字说明”。ClaudeCode 和 Codex 都支持在配置里设置最大输出 Token 数。OpenCode 则可以在每次请求时指定。把输出限制在合理范围内既能省钱又能让你更快找到关键信息。不过要注意限制太死可能导致模型输出被截断反而要重新问一次。我的经验是代码生成任务给 2000 到 4000 Token 的输出空间解释说明类任务给 500 到 1000 Token 就够了。4.3 温度参数与 Token 消耗的关系温度参数控制模型输出的随机性。温度越高输出越多样但也越容易跑偏导致你需要重新提问反而多花 Token。温度越低输出越确定通常一次就能得到可用结果。对于代码任务我一般把温度设在 0.1 到 0.3 之间。这个范围既能保证一定的灵活性又不会让模型太发散。OpenCode 允许在配置文件里为不同任务类型设置不同温度。ClaudeCode 和 Codex 的温度设置相对固定但可以通过提示词来间接影响。我做过一个实验同一个代码生成任务温度 0.7 时平均需要 2.3 次尝试才能得到满意结果温度 0.2 时平均 1.4 次。算上重试消耗的 Token低温设置反而更省。4.4 关闭不必要的功能开关很多工具默认开启了一些辅助功能比如自动补全、实时建议、后台索引等。这些功能在后台持续消耗 Token但你未必都需要。我的做法是只保留当前任务需要的功能。写代码的时候开补全读代码的时候关掉。OpenCode 的功能开关最细可以精确控制每个模块的启停。ClaudeCode 和 Codex 的开关少一些但也能通过配置关闭部分后台行为。有一个容易被忽略的点是自动保存和自动格式化。这些功能触发时可能会调用模型如果你手动保存的频率很高累积消耗也不小。我一般会关掉自动触发改成手动执行。5. 实操配置三个工具的具体优化步骤5.1 ClaudeCode 的省 Token 配置清单ClaudeCode 的配置主要集中在项目根目录的配置文件和用户级配置里。下面是我自己用的一套配置实测能省 60% 到 80% 的 Token。第一步是创建忽略文件。在项目根目录新建.claudeignore内容如下node_modules/ dist/ build/ .next/ coverage/ *.log *.lock *.min.js *.min.css public/assets/第二步是配置项目说明文件。在项目根目录创建CLAUDE.md简要说明项目结构、技术栈和常用命令。这个文件会被缓存所以内容要稳定不要频繁修改。第三步是调整会话设置。在用户配置里把默认模型设为轻量模型只在需要时手动切换到强模型。同时开启提示词缓存关闭自动索引。第四步是养成手动指定文件的习惯。每次提问都带上具体文件路径避免工具自动扫描整个项目。我用这套配置跑了一个月对比之前的用量Token 消耗下降了约 72%。最明显的改善来自忽略文件和手动指定文件这两项。5.2 Codex 的 Token 优化实操Codex 的优化重点在 IDE 插件的使用方式上。很多人习惯直接选中一段代码就提问这其实很费 Token因为插件会把整个文件甚至相关文件都带上。我的做法是尽量用行内补全而不是对话提问。行内补全的上下文范围小Token 消耗低。如果必须对话先把无关代码折叠起来只保留相关部分。Codex 的配置文件里可以设置上下文范围。我一般把自动上下文限制在 50 行以内超过的部分手动指定。另外Codex 的对话历史默认保留时间较长我建议在设置里改成任务结束后自动清理。还有一个技巧是利用 Codex 的代码片段功能。把常用的代码模式存成片段需要时直接插入而不是让模型重新生成。这样既省 Token 又保证风格一致。5.3 OpenCode 的多模型与缓存配置OpenCode 的灵活性最高配置空间也最大。下面是我推荐的一套配置思路。首先是模型路由配置。在配置文件里为不同任务类型指定不同模型models: completion: lightweight-model refactor: standard-model architecture: powerful-model debug: standard-model其次是缓存配置。开启本地文件缓存和提示词缓存设置合理的过期时间。我一般把文件缓存设为 24 小时提示词缓存设为 7 天。然后是会话管理。OpenCode 支持会话模板可以把常用任务的配置固化成模板。比如“代码审查模板”里预设好审查规则、输出格式、模型选择等参数。最后是输出控制。在配置里设置默认最大输出 Token 数避免模型输出过长。我一般设为 3000特殊任务再手动调高。5.4 三个工具的通用省 Token 习惯不管用哪个工具有些习惯是通用的。我总结了下面几条坚持下来效果很明显。任务开始前先想清楚要什么一次性把需求描述完整避免来回追问一个任务一个会话任务结束就清理上下文优先用文件引用而不是让工具自动扫描简单任务用轻量模型复杂任务才用强模型定期检查 Token 用量找出消耗最大的任务类型并针对性优化把重复性任务模板化减少每次重新描述的开销这些习惯看起来简单但真正坚持下来的人不多。我见过很多开发者一边抱怨 Token 贵一边继续用最费的方式提问。改变习惯需要一点时间但省下来的成本是实打实的。6. 常见问题与排查技巧实录6.1 Token 用量突然暴涨怎么排查Token 用量突然增加通常有几个原因。第一个是项目里新增了大量文件工具扫描范围扩大了。第二个是对话历史积累太多没有及时清理。第三个是某个任务触发了工具的自动索引或后台分析功能。排查方法很简单先看用量曲线找到暴涨的时间点然后回想那个时间点在做什么任务。如果是文件扫描问题检查忽略规则是否覆盖了新增目录。如果是对话历史问题清空会话重新开始。如果是后台功能问题去配置里关掉相关开关。我遇到过一次用量暴涨排查后发现是项目里新增了一个自动生成的 API 文档目录里面有上千个 Markdown 文件。工具每次任务都会扫描这个目录导致输入 Token 翻了好几倍。把该目录加入忽略列表后用量立刻恢复正常。6.2 缓存不生效的几种情况缓存不生效是最让人头疼的问题之一。明明配置了缓存用量却没降下来。常见原因有这几个项目配置文件被频繁修改导致缓存键变化文件内容变动太频繁缓存刚建立就失效缓存配置没有正确加载可能是路径写错了服务商侧的缓存策略调整需要重新适配排查的时候先确认配置文件路径和格式是否正确。然后检查最近有没有修改过项目说明文件。如果都没问题可以尝试手动清除缓存再重建。OpenCode 有缓存状态查看命令ClaudeCode 和 Codex 则需要看日志。6.3 模型切换后输出质量下降怎么办从强模型切到轻量模型后输出质量下降是正常的。关键是要判断下降程度是否可接受。我的做法是先用轻量模型跑一遍如果结果基本可用就手动微调如果完全不能用再切回强模型。为了提高轻量模型的输出质量可以在提示词里加更多约束。比如明确指定代码风格、给出示例、要求分步骤输出等。这些约束会增加一些输入 Token但相比直接用强模型还是划算的。另外不是所有任务都适合降级。涉及复杂业务逻辑、安全相关代码、架构设计这些任务我建议还是用强模型省下的 Token 不值得冒质量风险。6.4 多工具混用的 Token 管理有些开发者同时用多个工具比如 ClaudeCode 写代码、Codex 做补全、OpenCode 跑批量任务。这种情况下 Token 管理更复杂因为用量分散在不同平台。我的建议是统一在一个地方记录用量。可以建一个简单的表格每天记录各工具的消耗情况。这样能清楚看到哪个工具是消耗大户针对性优化。另外多工具混用时要注意上下文重复问题。同一个项目如果两个工具都做了索引等于同样的内容被读取了两次。我的做法是让一个工具做主索引其他工具通过文件引用共享避免重复扫描。问题类型典型表现排查方向解决方法用量暴涨单日消耗翻倍新增文件、对话历史、后台功能检查忽略规则、清理会话、关闭后台缓存失效配置了缓存但没效果配置路径、文件变动频率修正路径、稳定项目配置质量下降轻量模型输出不可用任务复杂度、提示词质量增加约束、必要时切回强模型多工具重复同一内容被多次读取索引配置、文件引用方式统一主索引、共享文件引用6.5 几个我踩过的坑和对应技巧第一个坑是忽略规则写得太宽泛把一些必要的配置文件也排除了导致工具理解不了项目结构。后来我改成精确排除只排除确定不需要的目录。第二个坑是缓存过期时间设得太短缓存刚建立就失效了等于白配。后来改成按项目活跃度动态调整活跃项目设短一些稳定项目设长一些。第三个坑是批量任务合并太多模型处理不过来输出质量很差反而要重新做。后来我控制批量规模一次不超过 5 个文件。第四个坑是忘了清理旧会话导致新任务带着一堆无关历史既费 Token 又影响输出。现在养成了任务结束就清理的习惯。这些经验看起来都是小事但累积起来对 Token 消耗的影响很大。省 Token 不是什么高深技术就是把每一个细节做到位积少成多。7. 把省 Token 变成肌肉记忆7.1 建立自己的用量监控习惯省 Token 不是一次性配置就完事而是需要持续关注和调整。我现在的习惯是每周看一次用量报告分析哪些任务消耗最大有没有优化空间。监控的重点不是绝对数字而是趋势。如果用量在上升就要找原因。是项目变大了是任务变复杂了还是用法退步了找到原因才能对症下药。我还会记录一些基准数据比如“改一个简单 bug 的平均 Token 消耗”、“生成一个单元测试的平均消耗”。有了基准就能快速判断某次用量是否异常。7.2 根据项目阶段调整策略项目不同阶段Token 优化策略也应该不同。开发初期项目结构变动频繁缓存效果差这时候重点应该放在减少扫描范围上。稳定期项目结构固定缓存效果好可以加大缓存利用。维护期任务以修 bug 为主重点是用轻量模型处理简单问题。我现在手上有三个项目分别处于不同阶段用的配置也不一样。初期项目忽略规则最严格稳定项目缓存配置最激进维护项目模型选择最保守。这样针对性调整之后整体用量比统一配置时低了约 35%。7.3 团队协作时的 Token 管理如果是团队使用Token 管理就更重要了。我建议团队统一配置规范把忽略文件、项目说明、常用模板都纳入版本控制。这样每个人用的都是优化过的配置不会因为个人习惯差异导致浪费。另外团队里可以指定一个人负责监控用量定期分享优化技巧。我见过一些团队因为没人关注 Token 消耗一个月下来费用高得离谱后来做了统一管理成本直接降了一半多。团队协作还有一个好处是可以共享缓存。如果多个成员用同样的项目配置服务商侧的缓存命中率会更高整体成本更低。7.4 持续关注工具更新带来的优化这三个工具都在快速迭代新版本经常会带来 Token 优化相关的新功能。我一般会关注官方更新日志看到有用的功能就及时升级配置。比如 ClaudeCode 最近几个版本在缓存机制上有明显改进升级后同样的任务用量下降了约 20%。OpenCode 的模型路由功能也是后来加的加上之后简单任务的成本大幅降低。不过升级也要谨慎新版本有时候会改变默认行为导致之前的优化失效。我的做法是先在测试项目上试确认没问题再推到正式项目。7.5 最后的几个实用建议如果你刚开始优化不要想着一步到位。先把忽略文件配好这是见效最快的。然后养成手动指定文件的习惯这个需要一点时间适应但效果显著。再之后是配置缓存和模型路由这些需要根据项目特点调整。如果你已经在用一段时间了建议做一次全面审计。把最近一个月的用量拉出来按任务类型分类看看哪些类型消耗最大。通常会发现一两个消耗大户针对性优化就能省下不少。还有一点很重要不要为了省 Token 牺牲开发效率。省 Token 的目的是让工具能长期用下去而不是让你花更多时间在配置上。找到一个平衡点让优化成为习惯而不是负担这才是可持续的做法。我在实际使用中发现真正省 Token 的高手不是配置最复杂的而是习惯最好的。他们知道什么时候该用强模型什么时候该用轻量模型什么时候该手动指定文件什么时候该清理上下文。这些判断已经变成了肌肉记忆不需要刻意去想。希望上面的内容能帮你走到这一步。
