1. 从400到80，账单是怎么被吃掉的
先交代背景。我用 Claude Code 做日常开发辅助，主要场景是读代码、改 bug、写测试、偶尔让它帮忙整理文档。第一个月账单出来的时候，400 多块，说实话有点肉疼。不是付不起，是觉得不值——因为我很清楚，这里面至少有一半的钱是白花的。
Claude Code 的计费逻辑本身不复杂，按 token 算，输入输出分开计价。但问题在于，很多人（包括当时的我）根本没意识到，每一次对话的输入 token 里，有相当大一部分是重复的上下文。你打开一个项目，让它读几个文件，聊几轮，上下文就越滚越大。下一轮对话，它要把之前所有内容重新读一遍。这就像你每次跟人说话，对方都要把你之前说过的所有话重新听一遍才开始回答——效率低，还费钱。
我后来花了一个周末，把过去一个月的使用记录翻出来，逐条分析哪些操作是必要的，哪些是习惯性浪费。结论很清晰：账单的大头不在模型本身贵，而在于我喂给它的上下文太多、太杂、太重复。Opus 确实强，但很多时候 Sonnet 完全够用；CLAUDE.md 我一开始根本没配，导致每次都要手动交代项目背景；终端命令执行权限没设好，它反复尝试、反复失败，token 就这么烧掉了。
所以这篇文章不是教你“怎么用 Claude Code”，而是分享我如何从“能用”到“用得起”的过程。如果你也在为 API 账单头疼，或者刚开始用 Claude Code 还没建立成本意识，下面这些经验应该能帮你少走弯路。
2. 核心思路：把每一分钱花在刀刃上
2.1 先搞清楚钱花在哪了
Claude Code 的计费单位是 token，你可以粗略理解为“字数”。英文大概 1 个 token 对应 4 个字符，中文因为编码方式不同，1 个汉字大约 1.5 到 2 个 token。每次你发送一条消息，Claude Code 会把以下内容打包发给模型：
- 系统提示词（固定开销，你控制不了）
- CLAUDE.md 的内容（如果你配了）
- 当前对话历史（越聊越长）
- 你这次输入的内容
- 它读取的文件内容（如果你让它读文件）
这里面，对话历史和文件读取是最大的变量。我翻记录发现，有一次我让它改一个 bug，聊了 20 多轮，每轮平均输入 8000 token，光输入就 16 万 token。按 Opus 的输入价格算，这一轮对话就烧掉好几块。而实际上，前 15 轮里有大量重复的代码片段和已经解决的问题讨论。
2.2 三个核心策略
基于这个分析，我定了三个策略，按优先级排序：
第一，模型分级。Opus 只在真正需要深度推理的时候用，比如复杂架构设计、疑难 bug 定位。日常的代码补全、简单重构、写注释、跑测试，全部切到 Sonnet。Sonnet 的价格大概是 Opus 的五分之一到十分之一，而在我 80% 的使用场景里，Sonnet 的输出质量完全够用。
第二，上下文瘦身。CLAUDE.md 只放最必要的项目信息，不写废话。对话超过一定轮数就开新会话，不让历史包袱拖累。读文件的时候精确指定路径，不让它自己乱翻。
第三，减少无效操作。把常用命令的权限配好，避免它反复尝试被拒绝。终端命令能一次跑通的，不要让它试错三次。
这三个策略执行下来，第二个月账单直接降到 80 块左右。不是我省着不用，而是同样的工作量，浪费的部分被挤掉了。
2.3 为什么不是直接换更便宜的模型
有人可能会问，既然要省钱，为什么不直接用最便宜的模型？我的答案是：工具的价值在于解决问题，不是省钱本身。如果为了省钱导致效率下降、返工增加，那省下来的钱还不够弥补时间成本。Opus 在复杂任务上的准确率确实高，用 Sonnet 可能要来回改三次，Opus 一次就过。这种情况下，Opus 反而更便宜。
所以核心不是“用最便宜的”，而是“在合适的场景用合适的模型”。这需要你对自己的任务类型有清晰的判断。我的经验是：需要跨文件理解、需要推理业务逻辑、需要设计新方案的时候用 Opus；单文件修改、格式调整、写测试、跑命令的时候用 Sonnet。
3. CLAUDE.md 到底该怎么写
3.1 不配 CLAUDE.md 的代价
我第一个月没配 CLAUDE.md，每次开新会话都要手动交代：这个项目是干什么的、用什么技术栈、代码规范是什么、测试怎么跑。这些信息每次都要打一遍，而且 Claude Code 每次都要重新理解。更麻烦的是，有时候我忘了交代某个细节，它就会按自己的习惯来，结果生成的代码不符合项目规范，我还得返工。
算一笔账：假设每次开新会话平均多花 500 token 交代背景，一天开 5 次，一个月 22 个工作日，就是 55000 token。按 Opus 输入价格算，这部分纯浪费。而且这还没算返工的成本。
3.2 CLAUDE.md 的正确写法
CLAUDE.md 放在项目根目录，Claude Code 启动时会自动读取。它的作用是用最少的 token 传递最必要的信息。我现在的 CLAUDE.md 大概 200 行左右，包含以下内容：
# 项目名称 一句话说明项目是做什么的。 ## 技术栈 - 语言：Python 3.11 - 框架：FastAPI - 数据库：PostgreSQL 15 - 测试：pytest ## 目录结构 - src/ 主代码 - tests/ 测试 - scripts/ 运维脚本 ## 代码规范 - 用 ruff 格式化，行宽 100 - 类型注解必须写 - 函数注释用 Google 风格 ## 常用命令 - 跑测试：pytest tests/ -v - 启动服务：uvicorn src.main:app --reload - 格式化：ruff format src/ ## 注意事项 - 不要改 migrations/ 下的文件 - 数据库连接串在 .env 里，不要硬编码关键原则：只写它不知道的，不写它自己能看出来的。比如你不用告诉它“这是一个 Python 项目”，它看到 .py 文件就知道了。你也不用把每个文件的用途都列出来，它需要的时候会自己读。
3.3 我踩过的坑
一开始我把 CLAUDE.md 写得太详细，把整个项目的业务逻辑都塞进去了，结果文件本身就有 2000 多 token，每次对话都要读一遍。后来我把它精简到 200 行以内，只保留最核心的信息，效果反而更好。
另一个坑是把临时信息写进 CLAUDE.md。比如“今天要改 XXX 功能”，这种一次性任务不应该放在这里，应该直接在对话里说。CLAUDE.md 是长期有效的项目上下文，不是任务清单。
提示：CLAUDE.md 的内容会计入每次对话的输入 token，所以它的长度直接影响成本。建议控制在 500 行以内，能用列表就不用段落，能用关键词就不用完整句子。
4. 模型切换的时机与技巧
4.1 Opus 和 Sonnet 的真实差距
我用同一个任务分别测试了 Opus 和 Sonnet 的表现。任务是：给一个已有的 FastAPI 接口添加参数校验和错误处理。
Opus 的输出：一次成型，参数校验逻辑完整，错误码符合项目规范，还主动加了边界情况处理。Sonnet 的输出：基本功能正确，但错误码用了默认的，边界情况漏了两个，需要我再补一轮。
从 token 消耗看，Opus 用了 3000 输入 + 1500 输出，Sonnet 用了 2500 输入 + 1200 输出，加上我补的那一轮 2000 输入 + 800 输出。算下来 Sonnet 总消耗反而更高，而且多花了我 5 分钟时间。
所以结论是：复杂任务用 Opus 更划算，简单任务用 Sonnet 更划算。判断标准很简单：如果这个任务需要它理解多个文件的关联、需要推理业务规则、需要设计新逻辑，用 Opus；如果只是单文件内的机械修改、格式调整、写测试用例，用 Sonnet。
4.2 怎么切换
Claude Code 里切换模型很简单，在对话里直接说“用 Sonnet”或者“切到 Opus”就行。但更高效的做法是在启动时就指定：
claude --model sonnet或者在 CLAUDE.md 里写默认模型，但我不建议这么做，因为不同任务需要不同模型，写死了反而麻烦。
我的习惯是：开新会话时默认用 Sonnet，遇到 Sonnet 搞不定的问题，再切 Opus。这样大部分对话都在 Sonnet 上跑，成本自然降下来。
4.3 一个容易被忽略的细节
Claude Code 在对话过程中切换模型，之前的对话历史会保留。这意味着如果你先用 Opus 聊了 10 轮，再切到 Sonnet，Sonnet 也要读那 10 轮历史。所以切换模型的最佳时机是开新会话的时候，而不是在长对话中间切。
我现在的做法是：如果一个任务 Sonnet 搞不定，我会把关键信息整理一下，开一个新会话用 Opus，而不是在原来的对话里直接切。这样 Opus 不需要读之前那些无效的尝试记录，输入 token 少很多。
5. 上下文管理的实操细节
5.1 什么时候该开新会话
这是我最开始完全没意识到的点。Claude Code 的对话是累积的，你聊得越久，每次发送的 token 越多。我翻记录发现，有一个会话我聊了 40 多轮，到后面每轮输入都超过 15000 token，而其中大部分是已经解决的历史问题。
现在的规则很简单：一个任务完成，就开新会话。不要在一个会话里连续做多个不相关的任务。比如改完 bug 去写文档，就开新会话。因为写文档不需要读改 bug 的历史。
另一个规则：如果连续两轮对话没有实质性进展，就开新会话。有时候 Claude Code 会陷入死循环，反复尝试同一个错误方案。这时候继续聊下去只会烧更多 token，不如整理一下问题，重新开始。
5.2 怎么让它精确读文件
Claude Code 可以自己读文件，但如果你不指定，它可能会读一堆不相关的文件。我的做法是在对话里明确指定文件路径：
读 src/api/users.py 和 src/models/user.py，然后修改 users.py 里的 create_user 函数这样它只会读这两个文件，不会去翻整个项目。如果你不确定文件在哪，可以先让它用 grep 搜索，但搜索本身也消耗 token，所以最好自己先定位好。
5.3 长对话的压缩技巧
有时候一个任务确实需要多轮对话，比如调试一个复杂 bug。这时候可以用一个技巧：在对话中间让它总结当前状态。
把目前已经确认的信息和待解决的问题总结一下，我要开新会话继续它会输出一段总结，你复制这段总结，开新会话粘贴进去。这样新会话的上下文就是压缩过的，比带着完整历史记录便宜得多。
我实测过，一个 30 轮的调试对话，完整历史大概 50000 token，压缩后的总结只有 800 token。效果几乎一样，成本差了几十倍。
6. 终端命令执行的省钱技巧
6.1 权限配置
Claude Code 可以执行终端命令，但默认情况下很多命令需要你确认。如果你不配置，它会反复尝试、反复被拒，token 就浪费在“尝试-被拒-再尝试”的循环里。
我的做法是在 CLAUDE.md 里明确写出常用命令，并且在设置里把安全的命令加入白名单。比如：
{ "permissions": { "allow": [ "Bash(pytest:*)", "Bash(ruff:*)", "Bash(git status)", "Bash(git diff:*)", "Bash(ls:*)", "Bash(cat:*)" ] } }这样它跑测试、格式化、看 git 状态的时候不需要每次问我，效率高很多，token 也省了。
6.2 让它一次跑对
另一个浪费 token 的地方是命令写错反复重试。比如它想找一个文件，先用find没找到，再用grep没找到，再用ls一个个翻。每次尝试都是一轮对话，都是 token。
我的经验是：在 CLAUDE.md 里写清楚项目的常用命令和路径。比如告诉它测试文件在tests/下，配置文件在config/下。这样它第一次就能找对地方，不用反复试。
还有一个技巧：让它先解释再执行。对于复杂命令，我会说“先告诉我你打算执行什么命令，我确认后再执行”。这样如果命令有问题，我在执行前就能纠正，避免它跑错了再重试。
6.3 一个真实的踩坑案例
有一次我让它帮我跑数据库迁移，它执行了alembic upgrade head，但环境变量没加载，报错了。然后它尝试source .env，又报错。然后它尝试export DATABASE_URL=...，还是报错。来回折腾了 6 轮，token 烧了不少，问题没解决。
后来我在 CLAUDE.md 里加了一行：“数据库迁移前先执行source .venv/bin/activate && source .env”。之后再遇到类似任务，它一次就过了。
这个教训是：把你踩过的坑写进 CLAUDE.md，让它不要重复踩。这比每次在对话里纠正便宜得多。
7. 常见问题与排查速查表
7.1 账单异常排查
| 现象 | 可能原因 | 排查方法 | 解决方式 |
|---|---|---|---|
| 账单突然翻倍 | 某个会话聊太长 | 查看使用记录，找 token 消耗最高的会话 | 拆分任务，开新会话 |
| 单次对话消耗高 | 读了大量文件 | 检查对话里是否让它读了整个目录 | 精确指定文件路径 |
| 反复报错消耗 token | 权限没配好 | 看是否有大量“命令被拒绝”记录 | 配置命令白名单 |
| 模型用错 | 默认模型是 Opus | 检查启动参数和 CLAUDE.md | 默认用 Sonnet，按需切 Opus |
7.2 我遇到过的典型问题
问题一：401 报错反复出现。有一次 API key 配置有问题，Claude Code 每次请求都返回 401，但它会重试，重试也消耗 token。后来我发现是环境变量没加载对。解决方式：在启动脚本里确保 API key 正确加载，不要依赖 shell 的默认环境。
问题二：上下文超限。有一次我让它读一个大文件，超过了模型的上下文限制，报错 400。它不仅没读成功，还反复尝试，浪费了不少 token。解决方式：大文件不要整个读，用 grep 定位关键部分，或者分段读。
问题三：模型切换后行为不一致。从 Opus 切到 Sonnet 后，Sonnet 不理解之前 Opus 的一些决策，导致输出风格突变。解决方式：切换模型时开新会话，并在开头简要说明任务背景。
7.3 独家避坑技巧
技巧一：用/cost命令随时查看当前会话消耗。Claude Code 有这个命令，但很多人不知道。我养成了习惯，每完成一个任务就看一眼，如果发现某个会话消耗异常高，就复盘一下哪里浪费了。
技巧二：给常用任务建模板。比如“写测试”这个任务，我固定了一套流程：先读被测文件，再读现有测试文件参考风格，然后生成测试。这套流程写在 CLAUDE.md 里，每次它按流程走，不会乱读文件。
技巧三：周末复盘。我每周花 10 分钟看一下这周的 token 消耗分布，找出最贵的几个会话，分析原因。坚持一个月后，我对哪些操作费钱、哪些操作省钱有了直觉，不用看账单也能控制住。
8. 从80块再往下压的空间
8.1 还能省的地方
80 块不是极限。我分析了一下当前的消耗结构，还有几个可以优化的点：
第一，缓存机制。Claude Code 支持 prompt caching，对于重复的上下文（比如 CLAUDE.md），缓存命中后价格会低很多。我还没完全摸透它的缓存策略，但初步测试发现，在同一个会话里连续对话，缓存命中率比较高。所以减少开新会话的频率和控制上下文长度之间需要平衡。
第二，批量任务合并。有些小任务，比如改几个文件的注释，可以合并成一次对话完成，而不是每个文件开一次会话。但要注意合并的任务不能太杂，否则上下文混乱反而费钱。
第三，输出长度控制。Claude Code 有时候会输出很长的解释，如果你不需要，可以在对话里说“只给代码，不要解释”。输出 token 也是钱。
8.2 不建议省的地方
有些钱不能省。比如复杂 bug 的调试，该用 Opus 就用 Opus，该多聊几轮就多聊几轮。因为调试不充分的代价是线上出问题，那个成本比 token 高得多。
还有代码审查。让 Claude Code 帮你 review 代码，虽然消耗 token，但能发现潜在问题。这个投入是值得的。
我的原则是：省浪费的钱，不省价值的钱。判断标准是：这笔 token 消耗是否直接产生了价值？如果只是因为我没配好、没说清楚、没管理好上下文而浪费的，那就省；如果是为了解决问题必须花的，那就花。
8.3 一个反直觉的发现
最后分享一个反直觉的发现：有时候多花 token 反而更省钱。
比如，让 Claude Code 在动手之前先充分理解代码，比它一上来就改、改错了再改，总体 token 消耗更低。我测试过，让它先读三个相关文件再改，比直接改然后来回修，平均节省 30% 的 token。
另一个例子：在 CLAUDE.md 里写清楚规范，比每次在对话里纠正，长期看便宜得多。CLAUDE.md 的 token 是每次对话都花的，但纠正的 token 是每次犯错都花的，后者频率更高。
所以省钱的核心不是“少用”，而是“用对”。把 token 花在刀刃上，让每一次交互都有明确的目的和充分的信息，这才是把账单从 400 压到 80 的真正原因。
这个内容后续还可以这样扩展：如果你用的是团队版，可以研究一下组织级别的用量分析和预算告警；如果你同时用多个 AI 编程工具，可以对比一下各自的成本结构，找到最适合自己的组合。我目前还在摸索 prompt caching 的最佳实践，等有稳定结论了再分享。
