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 和 WindowsWindows 上建议用 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 聊每句话都是一次完整的模型调用。如果你能把需求一次性说清楚让它一次规划到位能省下大量来回的调用。我现在写提示词的习惯是背景、目标、约束、验收标准四段式一次说完。这样模型一次就能理解到位不用反复澄清。这个习惯带来的成本下降比任何模型配置都明显。这套配置我用了几个月最大的体会是省钱不是靠抠而是靠把资源用对地方。强模型用在刀刃上轻量模型干脏活累活上下文该压就压提示词该写清楚就写清楚。这几件事做到位成本自然就下来了而且代码质量一点不打折。