1. 从400到80账单里到底藏着哪些“隐形漏斗”先把结论摆在前面一个月把 API 账单从 400 块压到 80 块靠的不是换更便宜的模型也不是薅什么羊毛而是把“钱花在哪”这件事彻底摸清楚了。我刚开始用 Claude Code 的时候心态跟大多数人一样——装上、登录、开干觉得按量计费能贵到哪去。结果第一个月账单出来 400 出头我盯着后台的用量明细看了半天发现真正烧钱的不是写代码本身而是几个我压根没意识到的行为习惯。Claude Code 的计费逻辑跟普通聊天窗口不太一样。它每执行一次任务背后可能触发多轮模型调用读文件、分析目录结构、生成修改方案、执行命令、验证结果、再根据报错回滚重试。你在终端里看到的是“它帮我改了一个函数”但实际消耗的 token 可能是这个函数本身的好几倍。尤其是当项目目录里有大量无关文件时它每次扫描上下文都会把这些内容一并读进去token 就像开了水龙头一样往外流。我后来做了个粗略的统计400 块的账单里大概有这么几个去向上下文重复读取占了将近四成模型选型不当占了三成无效重试和报错循环占了两成剩下的是正常的代码生成和命令执行。这个比例不一定适用于每个人但方向是通用的——大部分人的钱不是花在“干活”上而是花在“找活干”和“干错了重干”上。所以这篇文章不讲虚的我会把这一个月里实际做过的优化动作拆开来讲包括 CLAUDE.md 怎么写才能真正省 token、什么任务该用 Opus 什么任务用 Sonnet 就够了、怎么避免它反复读同一批文件、以及那些看起来不起眼但累积起来很吓人的小习惯。适合已经上手 Claude Code 但账单开始让你肉疼的人也适合还没开始用、想一开始就把成本控制住的人。提示下面提到的所有优化手段都不涉及任何违规操作纯粹是从使用习惯和配置层面做调整。账单数字因项目规模和使用频率而异但优化思路是通用的。2. CLAUDE.md 不是说明书是给模型画的“省电路线图”很多人第一次听说 CLAUDE.md 的时候以为它就是个项目说明文件随便写两句“这是一个 React 项目用 TypeScript”就完事了。我一开始也这么想后来发现这个文件写得好不好直接决定了 Claude Code 每次启动时要读多少东西、要问多少问题、要走多少弯路。2.1 为什么一个 Markdown 文件能影响账单Claude Code 在每次会话开始时会优先读取项目根目录下的 CLAUDE.md把它作为理解项目的“第一手资料”。如果你没写或者写得很模糊它就会自己去探索——列目录、读 package.json、翻配置文件、猜项目结构。这些动作每一步都是 token 消耗。你省了写文档的十分钟换来的是每次会话多花几毛到几块钱的探索成本。我做过一个对比测试同一个项目第一次没有 CLAUDE.md让它“帮我给用户列表加一个分页功能”它花了大概 12 轮交互才定位到正确的文件和组件第二次我补了一份详细的 CLAUDE.md同样的需求只用了 5 轮就完成了。token 消耗差了将近一倍。2.2 一份“省钱型”CLAUDE.md 应该包含什么关键原则是让模型少问、少找、少猜。具体来说这几类信息必须写进去项目结构地图不用列出每个文件但要把核心目录的职责说清楚。比如“src/components 放通用组件src/pages 放页面级组件src/api 放请求封装src/utils 放工具函数”。这样它就不会在需要改页面的时候跑去翻 utils。技术栈和版本明确写清楚框架、语言、构建工具、包管理器的具体版本。版本信息很重要因为不同版本的 API 写法不一样写错了它就会反复试错。代码规范约定比如“组件一律用函数式写法”“样式用 Tailwind 不用 CSS Module”“请求统一走 src/api/request.ts 里的封装”。这些约定能避免它生成不符合项目风格的代码减少返工。常用命令启动开发服务器、跑测试、构建、lint 的命令都列出来。它需要验证改动的时候会直接执行不用每次问你。禁区清单哪些目录不要动、哪些文件是自动生成的、哪些配置改了会出事。这个能避免它“好心办坏事”之后你还要花时间回滚。我自己的 CLAUDE.md 大概控制在 80 到 120 行之间。太短了信息不够太长了每次读取也费 token。这个长度是个比较舒服的平衡点。2.3 一个实际在用的 CLAUDE.md 骨架下面是我目前项目里在用的结构你可以直接参考这个框架往里填内容# 项目名称 ## 技术栈 - 框架Next.js 14 (App Router) - 语言TypeScript 5.3 - 样式Tailwind CSS 3.4 - 状态管理Zustand - 请求SWR 自定义 fetch 封装 ## 目录职责 - src/app页面路由每个目录对应一个路由 - src/components通用组件按功能分子目录 - src/lib工具函数和第三方库封装 - src/hooks自定义 hooks - src/types全局类型定义 ## 代码约定 - 组件一律使用函数式 named export - 样式只用 Tailwind class不写 CSS 文件 - 所有请求走 src/lib/request.ts - 类型定义放在 src/types不内联 ## 常用命令 - 开发pnpm dev - 构建pnpm build - 测试pnpm test - 类型检查pnpm typecheck ## 禁区 - 不要修改 src/generated 下的任何文件 - 不要动 next.config.js 里的 rewrites 配置 - 不要安装新依赖先问我这份文件写完之后我最直观的感受是Claude Code 变“安静”了。以前它动不动就问“你的请求封装在哪个文件”“样式是用什么方案”现在这些问题基本消失了直接干活。2.4 维护 CLAUDE.md 的节奏有一点要注意CLAUDE.md 不是写完就一劳永逸的。项目结构变了、换了依赖、加了新的约定都要同步更新。我一般是在每次做完一个功能模块之后顺手花两分钟检查一下有没有需要补充的内容。这个投入产出比非常高——两分钟的维护可能省下后面几十次的无效探索。另外一个小技巧如果你有多个项目可以把通用的约定抽出来放在全局配置里项目级的 CLAUDE.md 只写这个项目特有的内容。这样既避免了重复也让每个文件更精简。3. Opus 和 Sonnet 的选用边界不是所有活都值得请“老师傅”模型选型是我账单下降的第二大贡献项。刚开始用的时候我觉得既然花了钱那就用最强的模型什么问题都丢给 Opus。后来发现很多任务用 Sonnet 完成得一样好但成本差了好几倍。3.1 两个模型的实际能力差距在哪先说结论Opus 在复杂推理、多步骤规划、模糊需求理解上确实明显更强Sonnet 在明确的、模式化的、单文件范围内的任务上表现和 Opus 差距很小。这个差距在简单任务上几乎感知不到但在复杂任务上会被放大。我自己的体感是如果一个任务你能用一句话说清楚“改哪个文件的哪个函数、改成什么样”那 Sonnet 基本都能搞定。如果任务需要它先理解一段业务逻辑、再跨多个文件做协调修改、还要考虑边界情况那 Opus 的稳定性会明显更好。3.2 我实际使用的任务分配表用了一个月之后我大概形成了这么一套分配习惯任务类型推荐模型理由单文件函数修改Sonnet范围明确不需要复杂推理添加类型定义Sonnet模式化工作Sonnet 足够写单元测试Sonnet测试用例结构固定样式调整Sonnet改动局部逻辑简单跨文件重构Opus需要理解依赖关系新功能模块设计Opus需要规划和架构判断复杂 bug 排查Opus需要多步推理和假设验证性能优化分析Opus需要理解运行时行为代码审查Opus需要发现潜在问题这个表不是绝对的但作为一个默认起点很好用。我现在的习惯是默认用 Sonnet 起手如果发现它连续两轮都没理解对再切到 Opus。这样大部分任务都在 Sonnet 上完成了只有真正需要“老师傅”的时候才请 Opus 出场。3.3 切换模型的实操方式在 Claude Code 里切换模型很简单直接在会话里输入对应的命令就行。但有一个细节值得注意切换模型不会重置上下文。也就是说如果你先用 Sonnet 聊了十轮再切到 OpusOpus 会带着前面十轮的上下文继续工作。这既是好事也是坏事——好处是它知道之前发生了什么坏处是前面那些 token 在 Opus 的计费标准下会被重新计算。所以我的做法是如果一个任务确定要用 Opus就一开始就用 Opus不要在 Sonnet 上聊了半天再切过去。反过来如果一个任务用 Sonnet 就能完成那就全程 Sonnet不要中途切到 Opus 去“确认一下”。3.4 一个容易被忽略的成本细节还有一个很多人没注意到的点Opus 的输出 token 单价比 Sonnet 高不少。这意味着即使两个模型完成同一个任务需要的交互轮数一样Opus 的账单也会明显更高。所以对于那些“它话很多”的任务——比如让它解释一段代码、写一段文档——用 Sonnet 的性价比会高很多。我现在的原则是需要它“想”的用 Opus需要它“做”的用 Sonnet。想清楚这个边界之后账单结构会健康很多。4. 上下文管理别让模型每次都把整个项目“背一遍”如果说 CLAUDE.md 和模型选型是“开源”那上下文管理就是“节流”。我账单里最大的一块浪费就来自上下文被反复读取。4.1 上下文是怎么被悄悄吃掉的Claude Code 的工作方式决定了它需要“看到”相关文件才能做修改。问题在于它对“相关”的判断有时候过于宽泛。比如你让它改一个组件它可能会把整个 components 目录都扫一遍甚至把 pages 目录也读进来“参考一下”。每次读取都是 token 消耗而且这些内容会留在上下文里后续每一轮交互都会带着它们一起计费。更隐蔽的是会话累积。你在一个会话里连续做了五件事第一件事读的文件会一直留在上下文里到第五件事的时候虽然那些文件已经跟当前任务无关了但它们仍然在消耗 token。这就像你每次跟人说话都要把之前聊过的所有内容重新念一遍。4.2 我的三个应对策略策略一任务隔离一事一会话。这是最有效的一招。做完一个任务就开新会话不要让上下文无限累积。我现在的习惯是一个功能模块的修改用一个会话改完就关下一个任务重新开。虽然每次开新会话要重新建立上下文但这个成本远低于让旧上下文一直挂着。策略二明确指定文件范围。在提需求的时候直接把相关文件路径写出来。比如不说“帮我改一下用户列表”而是说“帮我改 src/components/UserList.tsx 里的分页逻辑”。这样它就不会去翻别的文件了。这个习惯养成之后token 消耗下降非常明显。策略三定期清理和重置。Claude Code 提供了清理上下文的命令我一般在一个大任务完成之后会手动清一次。另外如果发现它开始“跑偏”——比如反复读一些不相关的文件——那就果断开新会话不要在旧会话里挣扎。4.3 一个实际案例的对比我拿同一个需求做过对比给一个表格组件加排序功能。第一次我没有指定文件只说“给用户表格加个排序”。它先列了目录读了三个可能相关的组件文件又读了类型定义文件最后才定位到正确的文件。整个过程消耗的 token 大概是 8000 左右。第二次我直接说“改 src/components/UserTable.tsx给表头加点击排序排序状态用 useState 管理”。它直接打开这个文件读完就改token 消耗大概 2500。同样的结果成本差了三分之二。这个差距累积一个月就是几百块的区别。4.4 关于“让它自己找”的误区有人可能会说那我怎么知道该指定哪个文件这不是还得我自己先找一遍吗这个问题问得好。我的回答是你自己找一遍的成本远低于让它找一遍的成本。你花三十秒在编辑器里搜一下文件名省下的是它花几分钟翻目录的 token。而且你对项目的熟悉程度会随着这个过程提升长期来看是双赢。当然如果你确实不知道文件在哪那让它找也无可厚非。但至少可以在它找到之后把文件路径记下来下次直接指定。5. 那些看起来不起眼但很烧钱的习惯除了上面三大块还有一些零散的习惯也在悄悄推高账单。这些单次看起来不多但一个月累积下来很可观。5.1 让它“解释一下”比让它“改一下”更贵我有一段时间养成了一个坏习惯改完代码之后顺手让它“解释一下这段逻辑”。这个动作看起来无害但它需要模型把相关代码重新读一遍然后生成一段完整的解释文本。输出 token 加上输入 token一次解释可能就花掉几毛钱。后来我改成如果我真的需要理解某段代码我自己读。如果确实需要它解释我会把范围缩到最小——只贴那一个函数而不是让它去读整个文件。5.2 报错循环是最大的隐形杀手当代码跑不起来的时候很多人会习惯性地把报错贴给它让它修。它修完再跑还报错再贴再修。这个循环如果超过三轮成本就会飙升。因为每一轮它都要重新读文件、重新分析、重新生成修改方案。我的做法是报错超过两轮还没解决就停下来自己看。往往你自己看一眼报错信息比它试三轮还快。而且你在它试错的过程中消耗的 token可能比你自己排查花的时间更值钱。5.3 大文件是 token 黑洞如果一个文件超过 500 行每次读取它都是一笔不小的开销。我现在的做法是在让 Claude Code 处理大文件之前先自己把相关部分拆出来或者先做一次文件拆分。这不仅省 token也让它的修改更精准。5.4 别让它做“确认性”操作“你确认一下这个改对了吗”“你看看还有没有别的问题”——这类请求看起来很合理但它需要模型重新审视已经看过的内容产生额外的推理和输出。如果我对改动有疑问我会自己跑一下测试或者看一眼 diff。只有在真正需要第二双眼睛的时候才会让它做审查。5.5 批量操作要谨慎有时候我会想“既然它已经打开了这个文件不如顺便把旁边几个小问题也改了”。这个“顺便”往往会导致它扩大读取范围把不相关的文件也拉进来。我现在的原则是一个会话只做一件事。想改别的开新会话。6. 从400到80我实际执行的调整清单说了这么多原理和习惯最后把我实际做过的调整按优先级列一下。如果你现在账单偏高可以按这个顺序逐条检查。6.1 第一优先级立刻能见效的写一份完整的 CLAUDE.md这是投入产出比最高的一件事。花半小时写后面每次会话都在省钱。默认用 Sonnet按需切 Opus把模型选型从“无脑最强”改成“按任务匹配”。提需求时指定文件路径养成这个习惯token 消耗立竿见影地下降。一事一会话做完就关不要让上下文累积。这四条做完账单大概能降一半。我自己是从 400 降到了 200 左右。6.2 第二优先级需要一点适应期的控制报错循环不超过两轮逼自己在中途介入排查。减少“解释一下”类请求需要理解就自己读或者缩小范围。大文件先拆分再处理不要让模型直接啃几百行的文件。不做确认性操作信任自己的判断或者自己验证。这几条需要改变一些使用习惯适应期大概一周左右。做完之后账单能从 200 降到 120 上下。6.3 第三优先级精细打磨定期清理上下文大任务完成后手动清一次。维护 CLAUDE.md 的时效性项目变了就更新。记录高频操作的文件路径形成自己的“快捷方式”。审视每一次“顺便”克制扩大范围的冲动。这些是细活单次效果不明显但长期坚持下来账单能稳定在 80 左右。6.4 一个需要说明的点80 块这个数字是基于我自己的使用频率和项目规模得出的。如果你的项目更大、使用更频繁绝对值可能会更高但优化比例是类似的。核心逻辑始终是让模型少做无用功让每一分钱都花在真正的代码生成上。另外这些优化手段之间是有协同效应的。CLAUDE.md 写好了上下文管理就更容易模型选型对了报错循环就更少。所以不要只做其中一条整套配合起来效果最好。7. 用了三个月之后我对这套方法的新认识这套方法我后来又持续用了两个月账单基本稳定在 70 到 90 之间波动。在这个过程中有几个新的体会值得补充。第一个体会是省钱的尽头是省注意力。刚开始我还会刻意去算每次会话花了多少 token后来发现没必要。当习惯养成之后成本控制是自动发生的。你不需要时刻盯着账单只需要在几个关键节点上做对选择。第二个体会是CLAUDE.md 的质量比长度重要。我见过有人写了几百行的 CLAUDE.md结果里面一半是废话。真正有用的信息是那些能帮模型做决策的内容——目录职责、代码约定、禁区清单。至于项目背景介绍、业务逻辑说明那些写给人看的内容对模型来说价值有限。第三个体会是不要为了省钱而牺牲效果。我有一段时间过于激进地压缩上下文结果导致它经常理解错需求反而要花更多轮次来纠正。后来我找到了一个平衡点该给的信息给足不该给的坚决不给。省钱的目的是让工具更好用而不是让自己更累。最后一个体会是关于心态的。刚开始用 Claude Code 的时候我总觉得“既然花了钱就要多用”结果反而因为滥用而浪费。后来想明白了它是工具不是玩具。需要的时候用不需要的时候不用这才是最省钱的用法。账单从 400 降到 80降的不只是数字也是我对这个工具的理解深度。