1. 从 400 到 80账单是怎么被吃掉的先把结论摆在前面Claude Code 这个工具本身不贵贵的是你用它的时候脑子里没有成本这根弦。我第一个月账单 400 块出头第二个月压到 80 块左右中间没有换模型、没有降智、没有牺牲产出质量纯粹是把几个烧钱的习惯改掉了。很多人第一次用 Claude Code心态跟第一次开自助餐一样——反正按量付费能多问就多问能多跑就多跑。结果月底一看账单懵了。我当时的账单构成大概是这样的真正产生价值的对话可能只占三成剩下七成全是重复读取、无效探索、上下文膨胀和模型选错带来的浪费。这里要先讲清楚 Claude Code 的计费逻辑不然你根本不知道钱花在哪。它跟你在网页上聊天不一样它是一个跑在终端里的 agent会自己读文件、跑命令、改代码、再读回来验证。每一次它看一眼文件都是一次输入 token 的消耗。一个中等规模的项目光是把相关文件读进上下文就可能吃掉几万 token。如果你让它反复读、反复试token 就像水龙头没关一样流。我第一个月最典型的浪费场景是这样的让它改一个函数它先把整个目录扫一遍读了十几个不相关的文件然后开始改改完发现有个引用没更新又回去读一遍再改再读。一个本来五分钟能搞定的活它读了八万 token。按 Opus 的价格算这一趟就是好几块钱。所以压账单的核心不是少用而是让每一次调用都精准。下面我把自己踩过的坑和对应的改法一条一条拆开讲。1.1 先搞清楚你的钱到底花在哪个模型上Claude Code 支持切换模型不同模型的价格差得非常离谱。Opus 是最贵的Sonnet 便宜不少Haiku 更便宜。我第一个月几乎全程 Opus因为感觉它最聪明。但实测下来很多任务根本不需要 Opus。我的做法是按任务类型分模型任务类型推荐模型理由复杂架构设计、疑难 bug 定位Opus需要强推理值得花钱日常功能开发、重构、写测试Sonnet性价比最高绝大多数活它能干格式化、改配置、简单问答Haiku便宜到可以忽略别浪费 Sonnet光是把日常任务从 Opus 切到 Sonnet我的账单就降了将近一半。这不是降智是把钱花在刀刃上。Opus 留给真正需要它的场景比如一个绕了三圈都没定位到的并发 bug或者需要跨多个模块重新设计接口的时候。1.2 上下文膨胀才是隐形杀手比模型选错更隐蔽的是上下文膨胀。Claude Code 每一轮对话都会把之前的上下文带上你聊得越久每一轮的成本越高。我第一个月有个习惯一个会话从早开到晚中间干了七八件不相关的事。结果到后面每问一句话它都要把前面所有历史重新过一遍单次成本翻了好几倍。正确的做法是一件事一个会话干完就清。Claude Code 里有/clear命令我现在的习惯是每完成一个独立任务就清一次上下文。这个动作看起来小但它直接决定了你后面每一轮对话的基线成本。还有一个更狠的长会话里如果它读了一堆大文件这些文件内容会一直挂在上下文里。哪怕你后面问的问题跟这些文件无关它们照样计费。所以我现在会主动控制它读什么不让它顺手把整个目录扫一遍。2. CLAUDE.md把重复解释的成本一次性付清如果说有一个改动带来的收益最大那一定是写好CLAUDE.md。这个文件是 Claude Code 的项目级说明书它会在每次会话开始时自动读取。你把它写好了就等于把每次都要重新解释一遍项目背景的成本一次性付清了。我第一个月没写这个文件结果每次开新会话都要花好几轮对话让它理解项目结构、技术栈、代码规范。这些对话全是 token全是钱。更气的是每次解释的内容都差不多纯纯的重复劳动。2.1 CLAUDE.md 里到底该写什么我的CLAUDE.md现在包含这几块内容你可以直接参考项目一句话定位这个项目是干什么的用什么技术栈跑在什么环境。目录结构说明哪些目录是核心代码哪些是生成物不用看哪些是第三方库别动。代码规范命名习惯、缩进、注释语言、提交信息格式。常用命令怎么跑测试、怎么构建、怎么启动本地服务。禁区哪些文件不要改哪些操作不要做。写这个文件的时候有个原则只写它猜不到的东西。比如用 TypeScript这种它看一眼package.json就知道的不用写。但我们的业务错误码统一在src/constants/errorCode.ts里定义新增错误必须先去那里加这种约定它猜不到必须写。2.2 写好之后的效果有多明显我写完CLAUDE.md之后最直观的变化是新会话的第一轮对话它就能直接干活不需要我再铺垫。以前要花三四轮解释的东西现在零成本。按我当时的用量估算光这一项每个月省下的 token 就值一百多块。而且它还有个附加好处减少返工。以前它不知道规范写出来的代码风格不对我得让它改改又是一轮 token。现在它一开始就按规范写一次过。提示CLAUDE.md不是写完就完事项目结构变了、规范变了要同步更新。我现在的习惯是每次做完一个较大的重构顺手看一眼这个文件要不要改。2.3 别把 CLAUDE.md 写成百科全书这里有个反直觉的点CLAUDE.md不是越长越好。它每次会话都会被读进去写得太长本身就是一笔固定开销。我见过有人写了上千行把整个项目的业务逻辑都塞进去这就本末倒置了。我的经验是控制在两百行以内只放高频需要、它猜不到、影响正确性的信息。具体的业务细节让它需要的时候自己去读对应文件而不是一股脑塞进上下文。3. plan 模式先想清楚再动手省的是真金白银Claude Code 有个 plan 模式我第一个月基本没用觉得多一步麻烦。后来发现这一步恰恰是最省钱的。原因很简单让它在动手前把方案想清楚比让它边做边试要便宜得多。3.1 边做边试为什么烧钱不开 plan 模式的时候它的工作方式是读文件 → 改 → 跑测试 → 发现错了 → 再读 → 再改 → 再跑。每一轮发现错了都是一次完整的上下文往返成本很高。尤其是涉及多个文件的改动它可能改到第三个文件才发现第一个文件的假设是错的然后全部推倒重来。我有个真实的例子让它给一个模块加缓存。它没规划直接上手改改完发现缓存失效逻辑跟现有的状态管理冲突又回去改状态管理改完发现测试挂了再改测试。整个过程读了十几万 token。后来我用 plan 模式重做了一遍它先列出改动点、依赖关系、风险点我确认后再执行一次过token 消耗不到之前的三分之一。3.2 plan 模式的正确用法我的用法是凡是涉及三个以上文件、或者改动逻辑有分支的活一律先 plan。具体操作是让它先输出一个改动计划包含要改哪些文件每个文件改什么。改动之间的依赖顺序。可能影响到的其他模块。验证方式。我看完这个计划如果方向对就让它执行如果不对直接在这个阶段纠正成本极低。因为计划本身只是文字没有实际读写文件token 消耗很小。注意plan 阶段不要让它读太多文件。如果它为了做计划把整个项目读一遍那计划本身就贵了。我会在让它做计划前先告诉它只需要看这几个文件。3.3 计划确认后让它一口气执行完plan 模式还有个好处计划确认后它可以连续执行多个步骤中间不需要你反复确认。这比改一步问一次要省因为每次你介入都是一次新的上下文往返。当然前提是计划本身靠谱。4. 那些让我白花钱的具体操作习惯前面讲的是策略层面的这一节讲具体操作层面的坑。这些都是我实打实踩过、并且改掉之后账单明显下降的习惯。4.1 别让它顺手读整个目录Claude Code 有个倾向你让它改一个文件它可能先把整个目录扫一遍了解上下文。这个行为在它看来是谨慎在你看来是烧钱。我的做法是在指令里明确告诉它读哪些文件。比如不要说帮我优化一下用户模块而要说读src/user/service.ts和src/user/types.ts优化getUserProfile这个函数的错误处理。后者它只读两个文件前者它可能读二十个。4.2 大文件不要整个读进来有些文件几千行整个读进来就是几万 token。如果只需要改其中一小段我会先告诉它行号范围或者让它用搜索定位。Claude Code 支持按需读取你得主动用它这个能力而不是让它默认全读。4.3 会话该清就清别舍不得我第一个月有个心理障碍觉得清掉上下文它就忘了之前的事还得重新解释。但实际上只要你CLAUDE.md写得好清掉之后它照样能快速进入状态。而长会话带来的成本膨胀远比重新解释要贵。我现在的节奏是一个功能开发完/clear切换到不相关的任务/clear感觉对话超过二十轮了/clear。清完之后第一句话把当前任务说清楚就够了。4.4 别用 Opus 干体力活这条前面提过但值得再强调。格式化代码、改配置文件、写简单的单元测试这些活 Sonnet 甚至 Haiku 完全够用。用 Opus 干这些就是拿高射炮打蚊子。我现在默认用 Sonnet只有遇到真正烧脑的问题才手动切 Opus。4.5 让它自己验证但别让它反复验证Claude Code 改完代码会自己跑测试验证这是好事。但有时候测试挂了它会陷入改一点、跑一次、再改一点、再跑一次的循环。这种循环特别烧钱。我的做法是如果它连续两次没修好我就打断它让它停下来分析根因而不是继续试。盲目试错是最贵的。5. 一套可复制的省钱工作流把上面这些串起来我现在的日常工作流大概是这样你可以直接抄开新会话前确认CLAUDE.md是最新的。接到任务先判断复杂度。简单任务直接 Sonnet 上手复杂任务先切 Opus 做 plan。做 plan 时明确告诉它看哪几个文件让它输出改动计划。确认计划后让它连续执行中间不打断。执行完让它跑一次测试验证通过就结束。任务完成/clear清上下文准备下一个任务。遇到它反复试错果断打断让它分析根因再动手。这套流程跑下来我的账单从 400 降到 80产出反而更稳定了。因为省掉的都是无效探索和重复劳动真正干活的部分一点没少。5.1 关于模型切换的一个细节Claude Code 里切换模型是有命令的我把它设成了快捷方式随时切。这里有个经验不要在一个会话里频繁切模型因为切换本身可能触发上下文重新处理。我的做法是一个任务开始前就定好模型中途不换。5.2 监控用量别等账单出来才后悔Claude Code 有查看用量的方式我现在的习惯是每天扫一眼当天消耗。如果某天突然比平时高很多就回头看看是哪个任务烧的下次避免。这种即时反馈比月底看账单有用得多因为月底你已经忘了当时干了什么。6. 几个容易被忽略的成本细节最后补充几个细节都是那种不注意就悄悄花钱的地方。第一网络搜索也是成本。Claude Code 可以联网搜索每次搜索的结果都会进上下文。如果它为了一个你本地就能查到答案的问题去联网那就是白花钱。我会在CLAUDE.md里写明优先查本地代码不要联网。第二图片和长文本输入很贵。如果你贴一张大截图或者一段超长日志进去token 消耗会飙升。日志我会先自己过滤只贴关键部分截图能转成文字就转文字。第三失败的调用也计费。有时候它调用工具失败了比如命令跑错、文件路径不对这些失败的往返照样消耗 token。所以指令要尽量精确减少它试错的次数。第四别让它写超长注释和文档。有些任务它会顺手生成一大堆注释和文档这些输出也是 token。如果不需要明确告诉它只改代码不要加注释。6.1 一个反直觉的省钱技巧把话说清楚听起来像废话但真的有用。你给它的指令越模糊它需要探索的空间越大烧的钱越多。你给它的指令越精确——改哪个文件、哪个函数、达到什么效果、不要动什么——它越能直奔目标。我现在的指令基本都包含改哪里、改成什么样、不要动什么这三要素。6.2 关于第三方 API 和本地模型的取舍热词里有人提到用第三方 API 或者接本地模型来降成本。我的看法是如果你的任务对模型能力要求不高本地模型确实能省不少但如果是复杂开发任务本地模型的能力差距会导致更多返工算总账未必划算。这个要按你的实际任务类型来权衡不能一刀切。我自己试过把一些简单的格式化、文本处理任务分流到更便宜的渠道复杂开发还是留在 Claude Code 里。这种混合方案适合用量大、任务类型分明的场景。6.3 定期复盘你的用量结构我每个月会花十分钟看一下用量分布哪些任务类型消耗最多哪些是必要的哪些是可以优化的。这个复盘习惯帮我发现了不少浪费点。比如我一度在让它解释代码上花了很多钱后来发现这些解释我自己看代码更快就砍掉了。说到底压账单的本质是让每一分钱都花在产生价值的地方。Claude Code 是个很强的工具但强工具用不好烧钱速度也强。把CLAUDE.md写好、把 plan 模式用起来、把模型选对、把上下文管住这四件事做到位账单自然就下来了。我从 400 到 80 的过程没有哪一步是靠少干活实现的全是靠少浪费。