1. 这套配置到底在解决什么问题
1.1 从一个真实场景说起
用 Claude Code 写代码这件事，很多人第一次跑通之后都会经历一个相同的心理曲线：前三天觉得“这东西太强了”，一周之后开始盯着用量发呆，半个月后开始琢磨“有没有更划算的用法”。
原因不复杂。Claude Code 本质上是一个跑在终端里的智能体，它跟普通的对话式 AI 最大的区别在于：它会主动读文件、跑命令、改代码、再读结果、再改，一轮任务下来可能触发十几次甚至几十次模型调用。如果你全程用最顶配的模型，那账单涨起来的速度会远超你的预期。
我自己的情况是，一个中等规模的重构任务，全程用顶配模型跑完，消耗的额度大概是纯聊天问答的 8 到 15 倍。这不是模型贵，而是智能体的工作模式天然就费 token。
所以“既聪明又省钱”这个标题，核心要解决的就是一个矛盾：怎么在不牺牲代码质量的前提下，把每一分额度都花在刀刃上。
1.2 核心思路：分层用模型，而不是一刀切
省钱的关键不是换便宜模型，而是分层。
打个比方，你开一家装修公司。你不会让总设计师去搬砖，也不会让搬砖的工人去定设计方案。Claude Code 的工作流其实天然分成了两类任务：
- 决策类任务：理解需求、规划改动方案、判断某段代码的意图、决定下一步做什么。这类任务需要强模型，因为它考验的是推理和上下文理解能力。
- 执行类任务：读文件、搜索关键词、格式化输出、跑测试、生成样板代码、写注释。这类任务对推理要求低，用轻量模型完全够用。
一刀切用顶配模型，等于让总设计师去搬砖。一刀切用轻量模型，等于让搬砖的定方案，结果就是反复返工，反而更费钱。
这套配置的核心，就是让 Claude Code 在不同环节自动切换到合适的模型。主对话用强模型保证方向不跑偏，子任务和工具调用用轻量模型压低成本。
1.3 适合谁来参考
这套配置不是给“我就随便问问”的人准备的。它适合以下几类人：
- 每天用 Claude Code 超过 2 小时的重度用户
- 在做长期项目、需要频繁重构和调试的开发者
- 对额度消耗敏感、希望把成本控制在可预期范围内的团队
- 想在本地模型和云端模型之间做混合调度的折腾党
如果你只是偶尔用一下，那默认配置就够了，不用折腾。但只要你的使用频率上来了，这套分层思路带来的成本差异会非常明显。
2. 模型配置的底层逻辑拆解
2.1 Claude Code 的模型调用链路
要理解怎么配，先得知道 Claude Code 在什么时候调用模型。
一次典型的任务流程是这样的：你在终端输入一句“帮我把这个模块的错误处理重构一下”。Claude Code 收到之后，会先做一轮规划，然后开始行动。行动过程中它会调用一系列工具，比如读文件、列目录、搜索代码、执行命令。每调用一次工具，结果都要回传给模型，模型再决定下一步。
这里有个关键点：每一次“模型决定下一步”都是一次独立的模型调用。一个稍微复杂的任务，这个循环可能跑二三十轮。
默认情况下，所有这些调用都走同一个模型。这就是费钱的根源——那些“读一下这个文件”“把结果整理成列表”的环节，根本不需要顶配模型的推理能力，但你付的是顶配的钱。
2.2 强模型和轻量模型的分工边界
那具体怎么分？我的经验是看这个任务需不需要“理解意图”。
需要理解意图的，用强模型：
- 解析你模糊的自然语言需求
- 判断一段代码改动的风险
- 决定多个方案里选哪个
- 处理跨文件的依赖关系
- 遇到报错时判断根因
不需要理解意图的，用轻量模型：
- 读取指定文件的内容
- 在目录里找符合模式的文件
- 执行已经确定好的命令
- 把结构化数据转成指定格式
- 生成重复性高的样板代码
这个边界不是绝对的，但大方向是这样。你可以把它理解成“动脑的用贵的，动手的用便宜的”。
2.3 为什么不能全用轻量模型
有人会想，那我全用轻量模型不就更省了？
实测下来，全用轻量模型在简单任务上确实省钱，但一旦任务复杂起来，返工率会飙升。轻量模型容易误解需求，改错文件，或者在多步推理里丢掉上下文。一旦它改错了，你要花更多轮对话去纠正，最后算总账反而更贵。
这就像请一个便宜但不靠谱的工人，他把你家水管接错了，你得拆了重来，省下的工钱全赔进去了。
所以分层的目的不是省钱本身，而是在保证一次做对的前提下省钱。一次做对，才是最省的。
2.4 配置文件的组织方式
Claude Code 的配置通常放在用户目录下的配置文件夹里，核心是一个 JSON 或 TOML 格式的配置文件。这个文件里可以定义模型映射、工具权限、环境变量等。
我的建议是把配置分成三层来管理：
- 全局默认配置：放在用户主目录，定义你日常最常用的模型组合
- 项目级配置：放在项目根目录，针对特定项目覆盖全局设置
- 临时环境变量：在单次会话里临时切换，用于测试
这样你既有一个稳定的基线，又能在不同项目里灵活调整，还不会把配置搞乱。
3. 具体配置方案与参数详解
3.1 主模型的选择与权衡
主模型负责整个会话的规划和决策，这是最不能省的地方。
选择主模型时，我主要看三个维度：推理能力、上下文窗口、响应速度。推理能力决定了它能不能一次理解你的需求，上下文窗口决定了它能不能hold住大项目，响应速度决定了你的等待体验。
我的建议是主模型用当前你能拿到的推理能力最强的那一档。因为主模型的调用次数其实不多——一个任务里可能就几次到十几次，但它决定了整个任务的方向。方向错了，后面全白搭。
具体到参数上，主模型的温度建议调低，0.2 到 0.3 之间比较合适。因为代码任务需要的是确定性，不是创意。温度高了它容易给你整出一些“有想法但不对”的方案。
3.2 子任务模型的配置要点
子任务模型是省钱的主力。它负责那些工具调用和中间步骤。
配置子任务模型时，重点看两个指标：吞吐速度和指令遵循能力。速度决定了你的等待时间，指令遵循决定了它会不会在简单任务上自作主张。
这里有个坑要注意：有些轻量模型在“读文件”这种任务上会偷懒，比如只读一部分就下结论。所以子任务模型的提示词要写得非常明确，告诉它“完整读取，不要省略”。
子任务模型的温度可以设到 0 甚至更低，因为这类任务不需要任何创造性，要的就是准确执行。
3.3 工具调用的权限与模型绑定
Claude Code 的工具系统是可以精细控制的。你可以给不同的工具绑定不同的模型。
比如文件读取、目录列举、关键词搜索这类工具，完全可以绑定到最便宜的模型上。而代码编辑、命令执行这类有副作用的工具，建议还是走主模型或者稍强一点的模型，因为它们涉及判断。
这个绑定关系在配置文件里通常是一个映射表。我的一般原则是：
| 工具类型 | 推荐模型档位 | 理由 |
|---|---|---|
| 文件读取 | 轻量 | 纯搬运，不需要推理 |
| 目录搜索 | 轻量 | 模式匹配，确定性高 |
| 代码编辑 | 主模型 | 涉及判断，改错代价高 |
| 命令执行 | 主模型 | 有副作用，需要谨慎 |
| 结果整理 | 轻量 | 格式化输出，无推理 |
这张表不是死的，你可以根据自己的任务特点调整。但大方向是：有副作用的操作走强模型，纯读取的操作走轻量模型。
3.4 上下文压缩策略
这是很多人忽略的一个省钱点。
Claude Code 在长会话里会不断累积上下文，上下文越长，每次调用的成本越高。如果不做压缩，跑到后面每一轮都在为前面几十轮的冗余信息付费。
我的做法是开启自动压缩，并设置一个合理的阈值。当上下文超过某个长度时，让模型把前面的内容总结成一段精简的摘要，丢掉原始细节。
压缩的时机很关键。压太早，模型会丢掉必要的上下文，导致重复劳动。压太晚，你已经为冗余信息付了很多钱。我的经验阈值是上下文用到 60% 到 70% 的时候触发压缩，这个区间比较平衡。
另外，压缩本身也是一次模型调用，建议用轻量模型来做，因为总结摘要不需要强推理。
4. 完整实操流程与现场记录
4.1 环境准备与安装确认
先把基础环境确认一遍。Claude Code 支持 macOS、Linux 和 Windows，Windows 上建议用 WSL 或者官方桌面版，原生终端体验会差一些。
安装方式根据平台不同：
# macOS 和 Linux 常用方式 npm install -g @anthropic-ai/claude-code # 确认安装成功 claude --versionWindows 用户如果用 WSL，步骤和 Linux 一样。如果用桌面版，直接下载安装包即可。
安装完之后，第一次运行会让你做认证。认证方式这里不展开，按官方引导走就行。
注意：安装完成后先别急着配模型，先用默认配置跑一个简单任务，确认基础链路是通的。基础链路不通的情况下折腾模型配置，你会分不清是配置问题还是环境问题。
4.2 配置文件的定位与备份
找到你的配置文件位置。通常在用户主目录下的隐藏文件夹里。不同版本路径可能略有差异，可以用claude config path之类的命令查看，或者直接看官方文档。
找到之后，第一件事是备份。
cp config.json config.json.bak这一步看起来多余，但我踩过坑。有一次改配置改错了一个字段，整个 Claude Code 起不来，排查了半小时才发现是配置问题。有备份的话，一条命令就恢复了。
4.3 主模型与子模型的写入
配置文件的核心结构大概是这样（字段名以实际版本为准，这里展示的是逻辑结构）：
{ "model": { "primary": "你的强模型标识", "subtask": "你的轻量模型标识", "temperature": { "primary": 0.2, "subtask": 0.0 } }, "context": { "compressionThreshold": 0.65, "compressionModel": "你的轻量模型标识" } }写入的时候注意几点：
- 模型标识要写准确，写错了会静默回退到默认模型，你以为是省钱了其实没有
- 温度值不要设太高，代码任务 0.2 到 0.3 足够
- 压缩阈值 0.65 是我实测比较平衡的值，你可以从 0.7 开始试
改完之后保存，重启 Claude Code 让配置生效。
4.4 验证配置是否生效
怎么确认你的配置真的生效了？我的方法是做一个对照测试。
找一个中等复杂度的任务，比如“把这个文件里的所有 console.log 替换成正式的日志调用”。先用默认配置跑一遍，记录消耗。然后切换到你的分层配置再跑一遍，对比消耗和结果质量。
如果消耗明显下降但结果质量没变，说明配置生效了。如果消耗没变，大概率是模型标识写错了，回退到了默认。
另一个验证方法是看日志。Claude Code 在详细模式下会打印每次调用用的哪个模型。开启详细模式跑一个小任务，看日志里的模型标识是不是你配的那个。
4.5 本地模型的接入尝试
如果你想把部分任务放到本地模型上跑，思路是一样的，只是把模型标识换成你本地服务的地址。
本地模型的好处是零边际成本，坏处是能力和速度参差不齐。我的建议是本地模型只用来做最轻量的任务，比如文件读取和格式整理。主决策链路还是走云端强模型。
配置本地模型时要注意服务地址的格式，以及本地服务是否已经启动。常见的问题是本地服务没起来，Claude Code 调用超时，然后静默回退到云端模型，你以为在用本地其实没有。
提示：本地模型接入后，先用一个简单任务验证连通性，确认请求真的打到了本地服务上，再把它用到正式流程里。
5. 常见问题与排查技巧实录
5.1 配置改了但没生效
这是最高频的问题。排查顺序如下：
- 确认配置文件路径对不对，有没有改到另一个版本的文件
- 确认模型标识拼写正确，大小写敏感
- 确认改完之后重启了 Claude Code
- 开启详细日志，看实际调用的是哪个模型
大部分情况是第 2 条，模型标识写错了。因为写错不会报错，只会静默回退，所以特别隐蔽。
5.2 省钱效果不明显
如果你配了分层但账单没降，可能是这几个原因：
- 任务本身太简单，本来就没几次调用，分层省不了多少
- 主模型调用次数过多，说明你的任务规划环节太重，可以考虑优化提示词
- 上下文压缩没生效，长会话里冗余信息一直在付费
- 子任务模型其实没被用上，所有调用都走了主模型
我建议先跑一个典型任务，把每次调用的模型和 token 数拉出来看一遍，问题一目了然。
5.3 轻量模型改错代码
这是分层的代价。轻量模型在简单任务上偶尔会自作主张。
应对方法是把有副作用的工具绑定到强模型上，只让轻量模型做只读操作。另外，在提示词里明确告诉模型“只做指定操作，不要额外修改”。
如果还是出问题，那就把那个具体工具的模型档位往上调一级。省钱的边界是“不出错”，出了错就不省了。
5.4 上下文压缩导致信息丢失
压缩阈值设太低会导致这个问题。模型把还没用到的信息也压掉了，后面需要的时候找不回来，只能重新读文件，反而更费。
解决办法是把阈值调高一点，从 0.65 调到 0.75 试试。另外可以在压缩提示词里强调“保留所有文件路径和函数名”，这些是后续操作的关键索引。
5.5 常见问题速查表
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 配置不生效 | 模型标识错误 | 检查拼写和大小写 |
| 账单没降 | 子模型未启用 | 看日志确认调用模型 |
| 代码被改错 | 轻量模型越权 | 副作用工具绑强模型 |
| 信息丢失 | 压缩阈值过低 | 调高阈值到 0.75 |
| 本地模型无响应 | 服务未启动 | 先验证本地服务连通性 |
| 响应变慢 | 子模型速度慢 | 换更快的轻量模型 |
5.6 几个我踩过的坑
第一个坑是同时改多个配置项。有一次我一次性改了模型、温度、压缩阈值三个地方，结果出问题了不知道是哪个引起的。后来我养成了习惯，一次只改一个变量，改完验证再改下一个。
第二个坑是忽略了项目级配置的优先级。我在全局配了一套，在项目里又配了一套，结果项目级的覆盖了全局的，我一直在调全局配置却不起作用。搞清楚优先级顺序很重要。
第三个坑是本地模型和云端模型的输出格式不一致。本地模型有时候不遵循工具调用的格式规范，导致 Claude Code 解析失败。解决办法是在本地模型的系统提示里加上格式约束，或者干脆只让本地模型做纯文本任务。
6. 进阶优化与长期维护
6.1 按任务类型做动态切换
配置稳定之后，可以进一步做动态切换。比如你可以在项目配置里预设几套方案：重构模式、调试模式、文档模式，每套方案用不同的模型组合。
重构模式主模型用最强的，因为改动风险高。调试模式子模型可以更激进地用轻量，因为调试大量是读日志和搜索。文档模式全部可以用轻量，因为写文档不需要强推理。
这个思路的本质是让配置跟着任务走，而不是一套配置打天下。
6.2 定期复盘额度消耗
我建议每周花十分钟看一下额度消耗的分布。看看钱主要花在哪个环节，有没有异常的调用峰值。
如果发现某个环节消耗特别高，就去分析那个环节的提示词和模型选择是不是有问题。很多时候优化提示词比换模型更有效。
6.3 配置的版本管理
如果你在多台机器上用 Claude Code，建议把配置文件纳入版本管理。用一个私有的仓库或者云盘同步，这样换机器的时候不用重新配。
但要注意，配置文件里可能包含敏感信息，同步之前确认一下有没有需要脱敏的字段。
6.4 保持对模型更新的关注
模型迭代很快，今天的最优解下个月可能就不是了。新的轻量模型可能能力更强，新的强模型可能更便宜。
我的习惯是每个月试一次新模型，用同一个基准任务对比效果和成本。如果新的组合更优，就更新配置。这个习惯让我在过去半年里把成本又压下去了大概三成。
6.5 一个容易被忽略的省钱点
最后分享一个很多人没注意的点：减少无效的会话轮次。
很多人习惯一句话一句话地跟 Claude Code 聊，每句话都是一次完整的模型调用。如果你能把需求一次性说清楚，让它一次规划到位，能省下大量来回的调用。
我现在写提示词的习惯是：背景、目标、约束、验收标准，四段式一次说完。这样模型一次就能理解到位，不用反复澄清。这个习惯带来的成本下降，比任何模型配置都明显。
这套配置我用了几个月，最大的体会是：省钱不是靠抠，而是靠把资源用对地方。强模型用在刀刃上，轻量模型干脏活累活，上下文该压就压，提示词该写清楚就写清楚。这几件事做到位，成本自然就下来了，而且代码质量一点不打折。
