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 的差价到底有多大这是最关键的一张表我按官方公开的定价逻辑整理了一下具体数字以你实际使用的平台为准这里只讲比例关系模型输入价格相对值输出价格相对值适合场景Opus高基准的 5 倍左右高基准的 5 倍左右复杂架构设计、疑难 bug、多文件重构Sonnet基准基准日常编码、单文件修改、写测试、解释代码Haiku低基准的 1/5 左右低基准的 1/5 左右格式化、简单重命名、生成注释、跑脚本我第一个月的问题就是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我会开新会话处理 bug A完成后记录关键信息关掉会话开新会话处理 bug B再开新会话处理 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 行。第二步开新会话用 Sonnetclaude --model sonnet然后输入看一下 src/services/auth.py 的第 45 到 90 行登录失败次数没有触发账户锁定帮我修复。第三步验证和测试Claude 给出修改后我让它顺便写个测试给这个锁定逻辑写个单元测试放在 tests/test_auth.py。第四步收尾测试通过后关掉会话。整个过程消耗的 token 很少因为上下文很干净。如果这个 bug 涉及多个文件的交互比如锁定逻辑还要改数据库模型、改 API 返回那我会在第二步就切 Opus。但大多数情况下Sonnet 足够了。7. 常见问题与排查技巧实录7.1 账单突然变高怎么排查这是我最常被问到的问题。我的排查顺序是看模型分布是不是最近 Opus 用得多了看会话长度是不是有超长会话一个会话干了很多事看上下文大小是不是引用了太多不相关的文件看缓存命中是不是缓存没生效导致重复计费我整理了一个速查表症状可能原因解决方法单次任务成本高用了 Opus 干简单活切换到 Sonnet 或 Haiku总成本高但单次不高会话太长上下文累积一事一会话及时清理输入 token 异常大引用了整个目录或不相关文件精准引用只加相关行重复任务成本高缓存没命中检查缓存标记连续处理同类任务输出 token 多让模型写了太多解释在提示词里要求只给代码不要解释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. 不同使用场景的模型选择建议最后给几个具体场景的建议你可以直接对照使用场景推荐模型理由读代码、理解逻辑Sonnet理解能力足够成本适中写单元测试Sonnet测试逻辑相对固定Sonnet 完全够用修单文件 bugSonnet上下文小Sonnet 表现很好跨文件重构Opus需要全局推理值得花这个钱格式化、重命名Haiku规则明确不需要推理写文档、注释Haiku 或 Sonnet看复杂度简单用 Haiku架构设计讨论Opus需要深度推理和权衡数据清洗脚本Sonnet逻辑不复杂Sonnet 足够这套组合用下来我第二个月的账单稳定在 80 块左右工作量比第一个月还多了大概 30%。如果你现在账单偏高建议先从模型分级和一事一会话这两件事做起效果最立竿见影。我在实际使用中发现省钱这件事不是靠某一个技巧而是靠一套习惯。就像健身一样单次动作不重要重要的是持续做对的事。等你把这些习惯内化了就不会再为账单发愁了。