1. 从 400 到 80账单砍掉八成到底砍在了哪里先把结论摆在前面一个月从 400 块压到 80 块靠的不是换更便宜的模型这么简单而是把无脑全量喂上下文这件事彻底改掉了。我刚开始用 Claude Code 的时候习惯性地把它当成一个高级补全工具每次对话都让它读整个项目、读整个文件、读一堆无关的依赖结果就是 token 消耗像开了水龙头。第一个月账单出来 400 块我盯着那个数字愣了半天——这还只是个人开发者的用量。后来我花了一个周末做复盘把每一笔消耗拆开看发现问题集中在三个地方上下文冗余、模型选型一刀切、重复读取同一批文件。这三件事单独看都不起眼叠在一起就是账单爆炸的元凶。调整之后第二个月直接掉到 80 块左右功能体验几乎没有下降甚至因为上下文更干净回答质量还更稳了。这篇文章适合两类人看一类是刚上手 Claude Code、还没摸清 token 消耗规律的开发者另一类是已经用了一段时间、账单开始肉疼但不知道从哪下手的人。我会把每一个优化动作背后的原理、具体怎么配、实测效果都讲清楚你照着抄作业就行。核心关键词就几个Claude Code、API 账单、CLAUDE.md、Opus、Sonnet这几个词贯穿全文理解了它们之间的关系省钱这件事就成功了一半。需要说明的是下面所有数字都是我自己的实测区间不同项目规模、不同使用频率会有差异但优化方向和比例是可以参考的。另外本文讨论的是正常开发场景下的 API 调用成本优化不涉及任何特殊网络手段纯粹是使用习惯和配置层面的调整。2. 先搞懂 Claude Code 的 token 到底烧在哪2.1 一次对话背后其实发生了好几次 API 调用很多人以为我问一句、它答一句就是一次 API 调用其实远不止。Claude Code 在响应你的请求之前会做一系列准备工作读取当前工作目录结构、加载 CLAUDE.md 配置文件、检索相关文件内容、判断是否需要调用工具比如执行终端命令、读写文件。这些动作每一步都可能触发独立的 API 请求而每一次请求都要把上下文重新发一遍。这就是为什么你感觉我只问了一个小问题但账单上却多了一大截。举个直观的例子假设你的项目有 200 个文件Claude Code 在理解你的意图时扫描了目录结构又读取了其中 15 个相关文件每个文件平均 300 行。光是这些文件内容按每行约 10 个 token 估算就是 15 × 300 × 10 45000 个 token 的输入。如果这轮对话来回三轮输入 token 就要乘以三。提示token 消耗的大头永远是输入不是输出。很多人优化时盯着让它少说点其实方向反了真正该控制的是让它少读点。2.2 输入 token 和输出 token 的价格差了好几倍以主流的模型定价结构来看输出 token 的单价通常是输入 token 的 3 到 5 倍。这意味着什么呢意味着如果你把上下文控制好输入从 45000 降到 15000省下来的钱远比让它回答简短一点要多得多。而且输入 token 是每一轮都要重新计费的对话轮次越多冗余上下文的代价就被放大得越厉害。我做过一个粗略的对比测试同一个重构任务在全量上下文模式下消耗了约 12 万输入 token在精准上下文模式下只用了约 3.5 万输入 token输出 token 两者差不多。按当时的单价折算单次任务成本差了将近 3 倍。这就是为什么我说省钱的核心战场在输入端。2.3 Opus 和 Sonnet 的定位差异决定了你不能一刀切Opus 是能力最强的档位适合处理复杂推理、架构设计、疑难 bug 定位这类想不清楚就做不对的任务。Sonnet 则是性价比档位处理日常的代码补全、格式调整、简单重构、写测试用例绰绰有余。我第一个月的错误就是所有任务都用 Opus包括帮我把这个变量名改一下这种 Sonnet 闭着眼睛都能干的事。这里有个反直觉的点不是所有复杂任务都必须用 Opus。很多看起来复杂的任务拆解之后每一步其实都不难用 Sonnet 分步做总成本可能比 Opus 一次性做完还低而且中间过程你还能干预纠偏。我现在的策略是默认 Sonnet遇到它连续两次答偏或者明显理解不了的问题再手动切 Opus。这个切换动作看起来麻烦但一个月下来省的钱非常可观。3. CLAUDE.md 写得好等于给账单装了个阀门3.1 CLAUDE.md 不是项目说明书是给模型的工作守则很多人把 CLAUDE.md 当成 README 的复制粘贴写一堆项目背景、技术栈介绍。这其实浪费了它的核心价值。CLAUDE.md 的真正作用是约束模型的行为边界告诉它在这个项目里你应该怎么干活、不要碰什么、优先看哪里。写得好模型就不会到处乱翻文件写得差它每次都要重新摸索token 就哗哗地流。我的 CLAUDE.md 里有一条很关键的规则明确列出核心目录和忽略目录。比如src/core/是核心逻辑node_modules/、dist/、coverage/一律不要读。就这一条让模型每次扫描的文件数量直接砍掉一大半。因为默认情况下它可能会去翻构建产物或者依赖包那些内容又长又没用纯属烧钱。3.2 用任务路由规则减少无效探索我在 CLAUDE.md 里加了一段任务路由说明大意是改 UI 相关的问题优先看src/components/改接口逻辑优先看src/api/改数据模型优先看src/models/。这样模型拿到任务后能快速定位到相关目录而不是把整个项目从头到尾捋一遍。这个思路的本质是把人的领域知识提前注入给模型。你比模型更清楚代码的组织结构把这个信息写进 CLAUDE.md它就不用靠猜和试来定位了。实测下来同样的任务加了路由规则之后模型读取的文件数量平均减少了 40% 左右对应的输入 token 也差不多降了这么多。3.3 把常用命令和约定固化下来避免反复解释还有一个容易被忽略的点每次对话你都要重复告诉它我们用 pnpm 不用 npm测试用 vitest 不用 jest提交信息用中文这类约定。这些重复的说明本身就是 token 消耗。把它们全部写进 CLAUDE.md模型每次启动就自动加载你就不用再啰嗦了。我整理了一份自己的 CLAUDE.md 模板结构大致是这样的# 项目工作守则 ## 核心目录 - src/core/ 核心业务逻辑优先阅读 - src/api/ 接口层 - src/components/ UI 组件 ## 忽略目录 - node_modules/ dist/ coverage/ .next/ - 任何 lock 文件不要读取 ## 任务路由 - UI 问题 - src/components/ - 接口问题 - src/api/ - 数据问题 - src/models/ ## 技术约定 - 包管理器pnpm - 测试框架vitest - 代码风格见 .eslintrc - 提交信息中文 ## 行为约束 - 修改文件前先说明改动范围 - 不要主动重构未提及的代码 - 单次读取文件不超过 5 个最后那条单次读取文件不超过 5 个是我自己加的硬约束效果出奇地好。它逼着模型先思考我到底需要哪几个文件而不是一股脑全读进来。4. 上下文管理省钱的主战场在少读而不是少说4.1 主动清理对话历史别让上下文无限膨胀Claude Code 的对话是有记忆的你前面聊过的内容会一直带着。这在连续处理同一个任务时是好事但如果你已经切换到新任务了旧上下文就是纯粹的负担。我的习惯是一个任务结束就开新对话不要在一个会话里从早聊到晚。有人会担心开新对话它就不记得项目了。不会的因为 CLAUDE.md 会自动加载项目的基本约定还在。真正需要延续的只是当前任务的细节而任务都结束了那些细节也没必要留着。我算过一笔账一个持续 20 轮的会话如果中间切换了 3 个不相关的任务光是旧任务的上下文残留就可能多消耗 30% 以上的 token。4.2 用精准的文件引用代替读整个目录当你需要模型看某个文件时直接给出文件路径而不是说看看 src 目录下的代码。前者它只读一个文件后者它可能把整个目录都扫一遍。这个差别在小项目里不明显在几百个文件的项目里就是天壤之别。我现在的习惯是提问时尽量带上具体路径比如帮我优化src/api/user.ts里的fetchUserProfile函数而不是帮我优化用户相关的接口。前者模型目标明确读取范围可控后者它得先自己找用户相关是哪些文件这个寻找过程就是消耗。4.3 长文件先摘要再处理别整篇塞进去有些文件就是很长比如一个 2000 行的工具库。这种情况下直接让模型读全文非常浪费。我的做法是先用 Sonnet 让它生成一个结构摘要然后基于摘要讨论要改哪部分最后只把需要改的那一段拿出来精读。这样把一个 2000 行的文件拆成摘要 局部token 消耗能降到原来的三分之一甚至更低。这个思路可以类比成查字典你不会为了查一个词把整本字典背下来而是先看目录、再翻到具体那一页。模型处理长文件也应该这样先看结构、再定位细节。注意摘要这一步本身也要花 token所以只对确实很长、且需要反复引用的文件做。短文件直接读反而更划算。4.4 善用只读必要行的技巧Claude Code 支持读取文件的指定行范围。当你明确知道问题出在某个函数的某几行时直接指定行号范围比读整个文件省得多。比如看utils.ts的第 120 到 180 行而不是看utils.ts。这个技巧在处理大型配置文件、日志文件时特别有用。我处理一个 3000 行的配置文件时就是先让它看前 50 行了解结构然后直接跳到出问题的那一段。整个过程读取的行数不到 200 行如果整篇读就是 15 倍的差距。5. 模型选型策略什么活派给 Sonnet什么活留给 Opus5.1 一张表说清楚任务和模型的匹配关系我把日常任务做了个分类对应到模型选择上实测下来这套匹配基本不会出错任务类型推荐模型理由变量重命名、格式调整Sonnet规则明确无需深度推理写单元测试Sonnet模式化强Sonnet 足够简单 bug 修复Sonnet定位清晰时直接改代码解释、写注释Sonnet理解性任务成本敏感复杂 bug 定位Opus需要跨文件推理架构设计、方案评审Opus需要全局判断性能优化分析Opus需要深度推理大型重构规划Opus一步错步步错值得花这张表的核心逻辑是能用规则解决的事不给 Sonnet 之外的模型需要判断和推理的事才上 Opus。我第一個月所有任务都走 Opus相当于用高射炮打蚊子钱就是这么没的。5.2 分步拆解把 Opus 的活拆成 Sonnet 能干的活有些任务看起来必须 Opus但拆开之后每一步 Sonnet 都能胜任。比如重构这个模块直接丢给 Opus 它要一次性想清楚所有依赖关系消耗巨大。但如果拆成先分析依赖关系Sonnet→ 再设计新结构Opus只处理设计这一小步→ 再逐步实施Sonnet总成本反而更低。因为 Opus 只在设计这一步出场输入上下文可以控制得很小输出也就是一个设计方案。而实施阶段虽然步骤多但每步都简单Sonnet 完全够用。我做过对比同样一个中等规模的重构全 Opus 方案花了约 8 万 token 的 Opus 用量拆解方案只花了约 1.5 万 token 的 Opus 用量加 4 万 token 的 Sonnet 用量折算下来便宜了一半多。5.3 遇到 Sonnet 答不好先别急着切 OpusSonnet 偶尔会答偏这时候很多人的第一反应是切 Opus。但更省钱的做法是先看看是不是你的提问方式有问题。Sonnet 对模糊指令的容忍度比 Opus 低你把问题描述得更具体、把相关代码贴得更精准它往往就能答对了。切 Opus 是最后手段不是第一反应。我的经验是Sonnet 连续两次答偏才考虑切 Opus。而且切换时把前面 Sonnet 的尝试结果作为背景告诉 Opus让它在已有基础上修正比让它从零开始更省。因为从零开始意味着它要重新理解一遍问题又是一笔输入开销。6. 那些让我多花冤枉钱的操作习惯6.1 让模型先看看整个项目是最贵的坏习惯新手最容易犯的错就是上来就说你先看看我的项目结构。这一句话可能触发几十次文件读取token 瞬间飙升。正确的做法是你自己先想清楚要它看什么直接给路径。项目结构这种事你自己心里有数就行不需要让模型也从头摸一遍。我第一个月就干过这事一个下午让模型熟悉项目就烧掉了差不多 50 块钱。后来想想那 50 块钱买到的信息我自己花十分钟就能整理出来写进 CLAUDE.md而且写进去之后还能反复用。6.2 反复粘贴同一段代码有些人习惯把代码复制粘贴到对话里而不是让模型去读文件。如果这段代码要反复用到粘贴一次就是一次输入消耗粘贴十次就是十次。而如果它在文件里模型读一次之后后续对话可以引用不用重复读。当然如果只是临时贴一小段粘贴反而比让模型读整个文件省。关键看这段代码是不是反复出现。反复出现的放进文件让模型读一次性的直接粘贴。6.3 在错误的时机开新对话开新对话的时机也有讲究。任务切换时该开新对话但同一个任务的连续追问不该开。有些人一遇到模型答得不好就开新对话重来结果每次都要重新加载上下文反而更贵。正确做法是同一个任务内用追问的方式引导模型修正只有任务彻底变了才开新对话。6.4 忽略缓存机制的存在Claude 的 API 有 prompt caching 机制对于重复出现的上下文比如 CLAUDE.md、固定的系统提示缓存命中后的计费会便宜很多。这意味着保持 CLAUDE.md 稳定本身就能省钱。如果你频繁改动 CLAUDE.md缓存就失效了每次都要按全价计费。所以我的建议是CLAUDE.md 的内容尽量稳定把不常变的部分技术约定、目录结构和常变的部分当前任务备注分开。常变的部分不要写进 CLAUDE.md放在对话里说就行。7. 我的完整配置和一个月实测数据7.1 最终落地的配置清单经过一个月的调整我现在的配置大致是这样的默认模型Sonnet覆盖 80% 的日常任务Opus 触发条件复杂 bug 定位、架构设计、Sonnet 连续两次答偏CLAUDE.md包含核心目录、忽略目录、任务路由、技术约定、行为约束五部分保持稳定对话管理一个任务一个会话任务结束立即开新会话文件读取优先指定路径和行范围长文件先摘要上下文清理切换任务时主动清理不依赖自动记忆7.2 一个月前后的账单对比项目优化前优化后变化月账单约 400 元约 80 元下降 80%Opus 用量占比约 90%约 20%大幅下降平均单任务输入 token约 10 万约 2.5 万下降 75%平均单任务输出 token约 8000约 7000基本持平任务完成质量良好良好无明显下降从数据能看出来省钱的贡献几乎全部来自输入端和模型选型输出端没什么变化。这也印证了前面的判断控制输入才是省钱的核心。7.3 几个容易被忽略的细节第一个细节是时段的利用。如果你的任务不紧急可以安排在非高峰时段处理部分平台在低峰期有更优惠的计费。这个不是所有平台都有但值得留意。第二个细节是批量处理。如果你有一批类似的小任务比如给十个文件加注释不要一个一个来而是合并成一次请求让模型批量处理。这样上下文只加载一次比十次单独请求省得多。第三个细节是定期复盘账单。我现在的习惯是每周看一眼用量明细看看哪类任务消耗最多有没有异常。有一次我发现某个任务消耗特别高一查是模型误读了一个巨大的日志文件及时调整了忽略规则。8. 关于省钱这件事我踩过的几个认知误区8.1 用便宜模型就是省钱是错的省钱不等于用最便宜的模型。如果一个任务 Sonnet 做三次都做不对最后还得 Opus 来收场那前面三次 Sonnet 的钱就白花了总成本反而更高。正确的思路是用刚好够用的模型而不是最便宜的模型。判断标准很简单这个任务 Sonnet 一次能做对的概率有多高高就用 Sonnet低就直接上 Opus。8.2 上下文给得越多回答越准也是错的很多人觉得给模型的信息越多它理解得越全面回答越好。实际上无关信息会稀释关键信息反而让模型抓不住重点。我实测过把无关文件去掉之后模型定位问题的准确率反而提升了。这就像你跟人解释一件事说一堆背景反而让人抓不住重点直接说核心问题对方秒懂。8.3 省钱会牺牲体验这个前提本身就不成立我一开始也担心控制上下文、切换模型会不会让体验变差。实测一个月下来体验不但没变差反而更好了。因为上下文干净了模型不容易被干扰任务拆解了每一步都可控模型选对了回答质量更稳定。省钱和好用在这件事上并不矛盾矛盾的是懒和省——懒得整理上下文、懒得切换模型才是账单高的真正原因。8.4 别把 CLAUDE.md 当成一次性工作CLAUDE.md 是需要持续迭代的。每次你发现模型在某个地方反复出错或者反复问你要同样的信息就应该把对应的规则补进 CLAUDE.md。我现在的 CLAUDE.md 已经迭代了十几版每一条规则背后都是一次真实的踩坑。它越完善你后续的每一次对话就越省。9. 写在最后的一点个人体会这套方法我用了两个月账单稳定在 80 块上下偶尔任务多的时候到 100 出头但再也没回到过 400。更重要的是我养成了先想清楚再问的习惯这个习惯本身对写代码也有帮助——很多问题在整理上下文的过程中就自己想明白了。如果你现在账单还高别急着换工具或者找什么省钱秘籍先把 CLAUDE.md 写好把模型选型策略定下来把对话管理习惯改掉。这三件事做到位账单自然就下来了。至于具体能省多少取决于你的项目规模和使用频率但方向是确定的省钱的本质是减少无效信息而不是降低工作质量。最后分享一个小技巧我会在 CLAUDE.md 里放一行当前项目阶段的备注比如正在做用户模块重构这样模型每次启动就知道当前重点不用我反复解释。这个备注我会定期更新但更新频率很低基本不影响缓存。这个习惯帮我省下了不少重复解释的口舌也省下了对应的 token。