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 轮再切到 SonnetSonnet 也要读那 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按需切 Opus7.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 的最佳实践等有稳定结论了再分享。