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 的高手不是配置最复杂的，而是习惯最好的。他们知道什么时候该用强模型，什么时候该用轻量模型，什么时候该手动指定文件，什么时候该清理上下文。这些判断已经变成了肌肉记忆，不需要刻意去想。希望上面的内容能帮你走到这一步。