Claude Code省钱实战：模型分级与上下文管理优化指南

1. 账单从400到80，我到底做对了什么

先说结论：不是换了个便宜的模型就完事了，也不是靠什么野路子白嫖。核心就三件事——把模型分级用对、把上下文管住、把重复劳动缓存掉。这三件事听起来像废话，但真正落地到 Claude Code 的日常使用里，每一项都能省下真金白银。

我用 Claude Code 主要做三类活：一是读代码、改 bug、写测试；二是处理一些数据清洗和脚本生成；三是写文档、整理笔记。第一个月没经验，逮着 Opus 就往死里用，月底一看账单 400 出头。第二个月开始有意识地做优化，同样的工作量，账单压到了 80 块左右。这个降幅不是靠少干活换来的，活一点没少干，甚至因为效率提升还多做了不少。

这篇文章适合两类人看：一类是刚开始用 Claude Code、还没摸清计费逻辑的新手；另一类是已经用了一段时间、感觉账单有点肉疼但不知道怎么优化的老用户。我会把每一步的操作逻辑、参数选择、踩过的坑都讲清楚，你照着抄作业就行。

提示：本文提到的所有价格和用量都是我个人实际账单的近似值，不同地区、不同订阅方式、不同时间段可能有差异，但优化思路是通用的。

2. 先搞懂钱花在哪：Claude Code 的计费逻辑拆解

2.1 Token 是怎么被烧掉的

Claude Code 的计费本质上是按 token 算的，输入 token 和输出 token 分开计价，输出通常比输入贵好几倍。很多人只盯着"我发了多少字"，却忽略了真正的大头——上下文累积。

举个我自己的例子。刚开始用的时候，我喜欢在一个会话里连续干好几件事：先让它读一个文件，再改一个函数，再写个测试，再解释一段逻辑。看起来很方便，但每多一轮对话，之前所有的内容都会作为上下文重新发给模型。也就是说，第 10 轮对话的输入 token 里，包含了前 9 轮的全部内容。这就是为什么很多人觉得"我也没打多少字啊，怎么账单这么高"。

我实测过一组数据：一个中等规模的 Python 项目，单文件约 800 行。如果在一个会话里连续处理 5 个不同的问题，到第 5 轮时，输入 token 可能是第 1 轮的 4 到 5 倍。如果每轮都用 Opus，这个成本会非常夸张。

2.2 Opus 和 Sonnet 的差价到底有多大

这是最关键的一张表，我按官方公开的定价逻辑整理了一下（具体数字以你实际使用的平台为准，这里只讲比例关系）：

我第一个月的问题就是：90% 的活都用 Opus 干。改个变量名用 Opus，写个简单测试用 Opus，甚至让它帮我格式化 JSON 也用 Opus。这就像开卡车去楼下买瓶酱油，不是不行，是没必要。

第二个月我做了个简单规则：只有当我明确知道这个问题需要跨文件推理、或者涉及复杂逻辑重构时，才切 Opus。其他一律 Sonnet 起步，简单任务直接 Haiku。光这一项，账单就降了差不多一半。

2.3 上下文窗口不是越大越好

Claude 的上下文窗口很大，这是优点，但也是陷阱。很多人觉得"反正窗口大，我把整个项目都塞进去"，结果每次请求都在烧大量输入 token。

我的做法是：按需加载，用完就清。具体怎么操作，后面会详细讲。这里先建立一个认知：上下文窗口大是给你应急用的，不是让你日常挥霍的。

3. 模型分级策略：什么活用什么模型

3.1 我总结的三层分级法

经过一个月的反复调整，我固定下来一套三层分级法，你可以直接参考：

第一层：Haiku 处理"体力活"

• 格式化代码、调整缩进
• 生成简单的 docstring 和注释
• 重命名变量、提取常量
• 把一段 JSON 转成 YAML
• 写简单的正则表达式

这些活的特点是：规则明确、不需要推理、错了也能一眼看出来。用 Haiku 完全够用，成本只有 Sonnet 的几分之一。

第二层：Sonnet 处理"日常主力活"

• 单文件内的 bug 修复
• 写单元测试
• 解释一段代码的逻辑
• 生成一个独立的小函数
• 代码 review 和优化建议

这是我最常用的层级，大概覆盖了 70% 的工作量。Sonnet 在代码任务上的表现已经非常好了，很多时候我甚至分不清它和 Opus 的输出有什么区别。

第三层：Opus 处理"硬骨头"

• 跨多个文件的架构重构
• 复杂的性能问题排查
• 需要理解整个项目上下文的决策
• 涉及多个模块交互的 bug

这些活一个月也就遇到几次，但每次确实需要 Opus 的推理能力。用对地方，贵也值。

3.2 怎么在 Claude Code 里切换模型

在 Claude Code 里切换模型很简单，通常有几种方式：

# 方式一：启动时指定模型 claude --model sonnet # 方式二：在会话中切换（具体命令以你使用的版本为准） /model sonnet

如果你用的是 VS Code 插件或者桌面版，一般在设置里可以直接选默认模型。我的建议是：把默认模型设成 Sonnet，遇到硬骨头再手动切 Opus。这样能避免"忘了切换"导致的浪费。

注意：不同版本的 Claude Code 切换模型的命令可能略有差异，建议先看一下你所用版本的帮助文档。核心思路是一样的——默认用中间档，按需升降。

3.3 一个真实的对比案例

我拿同一个任务做过对比测试：给一个约 300 行的 Python 文件写单元测试。

• 用 Opus：输出质量很好，覆盖了边界情况，耗时约 40 秒，成本约 0.8 元
• 用 Sonnet：输出质量几乎一样，覆盖了主要分支，耗时约 25 秒，成本约 0.15 元

差了 5 倍多的成本，质量差异在我实际使用中几乎感知不到。从那以后，写测试我一律用 Sonnet。

4. 上下文管理：省钱的隐形杀手锏

4.1 为什么上下文管理比选模型还重要

选模型影响的是"单价"，上下文管理影响的是"数量"。单价降 5 倍很厉害，但如果你的 token 数量能降 10 倍，那效果更夸张。

我做过一个统计：优化前，我平均每个任务消耗的输入 token 是优化后的 6 到 8 倍。原因就是上下文累积——在一个长会话里干太多事，每一轮都在重复发送之前的内容。

4.2 我的"一事一会话"原则

这是我最核心的一条经验：一个会话只干一件事，干完就开新会话。

听起来很麻烦，但实际操作起来并不费事。比如我要改三个 bug，我会：

1. 开新会话，处理 bug A，完成后记录关键信息
2. 关掉会话，开新会话，处理 bug B
3. 再开新会话，处理 bug C

这样做的好处是，每个会话的上下文都是干净的，不会带着之前无关的内容一起发送。虽然多开几次会话，但每次的 token 量都控制在很小的范围内。

我实测过：处理三个独立 bug，如果在一个会话里连续做，总输入 token 约 45000；分成三个会话做，总输入 token 约 12000。差了将近 4 倍。

4.3 用 CLAUDE.md 做"项目记忆"

每次开新会话都要重新解释项目背景，这也很烦。解决办法是用CLAUDE.md文件。

在项目根目录放一个CLAUDE.md，写上项目的基本信息、技术栈、代码规范、常用命令等。Claude Code 会自动读取这个文件作为上下文。这样你开新会话时，不需要重新解释"这是个什么项目"，它已经知道了。

我的CLAUDE.md大概长这样：

# 项目说明 这是一个基于 FastAPI 的后端服务，使用 PostgreSQL 数据库。 ## 技术栈 - Python 3.11 - FastAPI + SQLAlchemy - PostgreSQL 15 - pytest 做测试 ## 代码规范 - 使用 black 格式化，行宽 88 - 类型注解必须写 - 测试文件放在 tests/ 目录 ## 常用命令 - 启动开发服务：make dev - 跑测试：make test - 格式化：make format

这个文件只需要写一次，之后每次开新会话都能省下大量解释成本。注意不要把这个文件写得太长，控制在 50 行以内，否则它本身也会占用不少 token。

4.4 及时清理和精准引用

在会话中，如果某个文件的内容已经不需要了，可以明确告诉 Claude "这个文件不用再看了"。另外，引用文件时尽量精准，不要整个目录往里塞。

比如：

# 不推荐：把整个 src 目录都加进去 claude "看看 src 目录下的代码有什么问题" # 推荐：只加相关文件 claude "看看 src/services/user.py 这个文件的第 45 到 80 行"

精准引用能大幅减少输入 token。我一般会先用grep或编辑器定位到具体行号，再让 Claude 看那一小段。

5. 缓存与复用：把重复的钱省下来

5.1 什么是 Prompt Caching，为什么能省钱

Claude 支持 prompt caching（提示缓存）。简单说，如果你有一段内容在多次请求中重复出现，可以把它标记为可缓存。第一次请求时正常计费，后续请求如果命中缓存，这部分内容的费用会大幅降低。

这就像你每天上班都走同一条路，第一次走要认路，之后走就轻车熟路了。缓存命中的部分，成本可能只有原来的十分之一甚至更低。

5.2 我怎么用缓存省钱的

我的用法比较朴素，但很有效：

场景一：固定的系统提示词

如果你经常用同一套系统提示词（比如"你是一个资深 Python 工程师，回答要简洁"），把这部分标记为可缓存。每次请求都能命中，省下重复计费。

场景二：大文件的反复引用

有时候我需要反复让 Claude 看同一个大文件（比如一个 2000 行的配置文件），每次问不同的问题。把这个文件的内容标记为可缓存，后续提问就便宜很多。

场景三：CLAUDE.md 的自动缓存

Claude Code 对CLAUDE.md的处理通常会自动利用缓存机制。这也是为什么我强调要把项目背景写进去——它不仅省了解释时间，还省了重复计费。

提示：缓存有有效期，通常是几分钟到几小时不等。如果你隔了很久再回来，缓存可能已经失效了。所以连续做同一类任务时，缓存效果最好。

5.3 批量处理 vs 逐条处理

如果你有一批类似的任务（比如给 20 个函数写注释），不要一条一条来。把相关的函数放在一个请求里，让 Claude 批量处理。这样上下文可以复用，缓存也能命中。

我实测过：给 20 个函数写 docstring，逐条处理总成本约 2.5 元，批量处理（分 4 批，每批 5 个）总成本约 0.6 元。差了 4 倍。

当然，批量也不能太大，否则单次请求的 token 量太高，反而可能触发一些限制。我的经验是每批控制在 5 到 10 个任务左右比较合适。

6. 实操流程：我一天的工作流长什么样

6.1 早上：规划今天的任务

我一般会在早上花 5 分钟列一下今天要做的事，然后按"模型层级"分类：

• 哪些是体力活（Haiku）
• 哪些是日常活（Sonnet）
• 哪些是硬骨头（Opus）

这样一天下来，模型切换是有计划的，不会临时抓瞎。

6.2 干活时：一事一会话 + 精准引用

每开始一个任务，开新会话。引用文件时精准到行。任务完成后，如果有关键结论，记到笔记里，然后关掉会话。

如果任务中途需要切换模型（比如 Sonnet 搞不定，需要 Opus），我会在当前会话里直接切，而不是重开会话。因为重开会话会丢失之前的上下文，反而要重新解释。

6.3 晚上：复盘当天的用量

Claude Code 一般会提供用量查看的方式（具体命令看你的版本）。我每天花 2 分钟看一下今天的 token 消耗，如果发现某个任务异常高，就想想是不是哪里可以优化。

这个习惯帮我发现了好几个"漏财点"。比如有一次我发现一个简单的格式化任务消耗了 8000 多输入 token，原因是我不小心把整个项目目录都加进了上下文。从那以后，我引用文件更加小心了。

6.4 一个完整的实操示例

假设我要修一个 bug：用户登录时，如果密码错误超过 3 次，应该锁定账户，但现在没有锁定。

第一步：定位问题

grep -n "login" src/services/auth.py

找到相关函数在第 45 到 90 行。

第二步：开新会话，用 Sonnet

claude --model sonnet

然后输入：

看一下 src/services/auth.py 的第 45 到 90 行，登录失败次数没有触发账户锁定，帮我修复。

第三步：验证和测试

Claude 给出修改后，我让它顺便写个测试：

给这个锁定逻辑写个单元测试，放在 tests/test_auth.py。

第四步：收尾

测试通过后，关掉会话。整个过程消耗的 token 很少，因为上下文很干净。

如果这个 bug 涉及多个文件的交互（比如锁定逻辑还要改数据库模型、改 API 返回），那我会在第二步就切 Opus。但大多数情况下，Sonnet 足够了。

7. 常见问题与排查技巧实录

7.1 账单突然变高，怎么排查

这是我最常被问到的问题。我的排查顺序是：

1. 看模型分布：是不是最近 Opus 用得多了？
2. 看会话长度：是不是有超长会话，一个会话干了很多事？
3. 看上下文大小：是不是引用了太多不相关的文件？
4. 看缓存命中：是不是缓存没生效，导致重复计费？

我整理了一个速查表：

7.2 模型切换后效果变差怎么办

有时候从 Opus 切到 Sonnet，发现输出质量下降。我的处理方式是：

• 先检查提示词是不是太模糊。Sonnet 对提示词的精确度要求比 Opus 高，把需求写清楚，效果会好很多。
• 如果还是不行，再切回 Opus。但这种情况一个月也就几次，不影响大局。

7.3 缓存不生效的常见原因

• 缓存内容太短，没达到最小缓存长度
• 缓存过期了（隔太久没用）
• 缓存标记的位置不对，放在了变化的内容上

我的经验是：把最稳定、最长的内容放在前面并标记缓存，比如系统提示词、项目背景、大段固定配置。变化的内容放在后面。

7.4 几个我踩过的坑

坑一：以为 Haiku 什么都能干

Haiku 很快很便宜，但复杂一点的逻辑它真的搞不定。我有一次让它改一个涉及状态机的函数，结果改出了 bug，反而花了更多时间调试。后来我定了条规矩：涉及状态、并发、边界条件的活，最低用 Sonnet。

坑二：忘了关会话

有几次我干完一个任务，直接在那个会话里开始下一个任务，结果上下文越滚越大。后来我养成了习惯：任务完成，立刻关会话。这个动作只需要一秒钟，但能省下不少钱。

坑三：CLAUDE.md 写太长

一开始我把所有能想到的都写进去了，结果这个文件本身就有 200 多行，每次请求都要带上，反而增加了成本。后来精简到 40 行左右，只留最核心的信息。

坑四：批量太大触发限制

有一次我把 30 个函数一次性丢给 Claude 写注释，结果请求太大，处理很慢，而且中间出错后要全部重来。后来改成每批 5 到 8 个，稳定多了。

8. 一些额外的省钱习惯

除了上面这些核心策略，我还有几个小习惯，积少成多也能省不少：

习惯一：先自己想，再问 Claude

不是所有问题都需要问 AI。有些问题我自己查一下文档、搜一下就能解决，没必要消耗 token。我现在会先花 30 秒想想"这个问题我真的需要问吗"，能自己解决的就自己解决。

习惯二：用便宜的模型做初筛

比如我要在一个大文件里找某个逻辑，我会先用 Haiku 或者直接用 grep 定位，而不是一上来就让 Opus 读整个文件。

习惯三：输出要求写清楚

在提示词里明确说"只给修改后的代码，不要解释"，能大幅减少输出 token。输出 token 比输入贵，省输出就是省钱。

习惯四：定期清理不用的会话和缓存

虽然缓存能省钱，但过期缓存也没用。定期清理一下，保持环境干净。

习惯五：关注用量趋势，而不是单次账单

单次账单波动很正常，重要的是看趋势。如果连续几天成本在上升，就要找原因了。

9. 不同使用场景的模型选择建议

最后给几个具体场景的建议，你可以直接对照使用：

这套组合用下来，我第二个月的账单稳定在 80 块左右，工作量比第一个月还多了大概 30%。如果你现在账单偏高，建议先从"模型分级"和"一事一会话"这两件事做起，效果最立竿见影。

我在实际使用中发现，省钱这件事不是靠某一个技巧，而是靠一套习惯。就像健身一样，单次动作不重要，重要的是持续做对的事。等你把这些习惯内化了，就不会再为账单发愁了。