1. 这套配置到底在解决什么问题1.1 从一个真实痛点说起用 Claude Code 写代码的人大概率都经历过这种纠结开着 Opus 跑一个重构任务效果确实好但看着 token 消耗心里发慌换成 Haiku 省钱了结果它连项目结构都没读明白就开始瞎改。更别提那些需要反复来回对话的调试场景一轮下来账单数字跳得比心率还快。我自己的情况是手头同时维护着三个项目一个 TypeScript 的全栈应用、一个 Python 的数据处理脚本集、还有一个 Rust 写的 CLI 工具。每天用 Claude Code 的时间大概在四到六小时主要做代码审查、重构、写测试和排查 bug。最开始我全用默认配置一个月下来发现成本远超预期但换成最便宜的模型又明显感觉“智商不够用”。后来我花了两周时间反复调整模型配置策略最终稳定在一套“分层调度”的方案上。核心思路很简单不同任务用不同模型该聪明的地方不省钱该省钱的地方不浪费。实测下来成本降了大约六成而代码质量几乎没有下降。这套配置适合谁如果你每天用 Claude Code 超过一小时或者手头有多个项目需要频繁切换又或者你对成本比较敏感但不想牺牲效果那这套思路应该能帮到你。如果你只是偶尔用一下写个脚本那默认配置其实也够用不必折腾。1.2 为什么“一刀切”的模型配置必然低效很多人配置 Claude Code 的方式很粗暴要么全用最强的模型要么全用最便宜的。这两种做法都有问题。全用最强模型的问题在于你大量的 token 其实花在了“不需要那么聪明”的任务上。比如让模型帮你格式化一段 JSON、重命名一个变量、写一个简单的正则表达式这些任务用轻量模型完全能胜任用最强模型就是杀鸡用牛刀。我统计过自己一周的对话记录大约 65% 的请求属于“简单任务”——定义清晰、上下文需求少、不需要深度推理。这部分如果用轻量模型处理成本可以压到原来的十分之一甚至更低。全用最便宜模型的问题则相反。当你需要模型理解一个复杂的代码库结构、做跨文件的依赖分析、或者设计一个模块的接口时轻量模型往往抓不住重点。它可能会忽略掉关键的上下文给出看似合理但实际有问题的建议。这种“省了小钱赔了大钱”的情况在调试复杂 bug 时尤其明显——模型给了一个错误的修复方向你跟着试了半天最后发现还不如一开始就用强模型。所以关键不在于“用哪个模型”而在于“什么任务用什么模型”。这就是分层调度的核心。1.3 分层调度的基本框架我把日常使用 Claude Code 的任务分成三个层级第一层轻量任务。包括代码格式化、简单的重命名、生成注释、写正则、转换数据格式、回答语法问题等。这类任务的特点是输入输出都很明确不需要理解整个项目单次对话就能完成。适合用 Haiku 级别的模型。第二层常规任务。包括写单元测试、实现一个独立的函数、修复简单的 bug、代码审查、写文档等。这类任务需要一定的上下文理解但不需要跨多个文件的深度推理。适合用 Sonnet 级别的模型。第三层重任务。包括跨文件重构、架构设计、复杂 bug 排查、性能优化、理解陌生代码库等。这类任务需要模型有很强的推理能力和长上下文理解能力。适合用 Opus 级别的模型。这套分层不是拍脑袋定的而是基于我两周的实际使用数据。我记录了每次对话的任务类型、使用的模型、以及最终效果然后不断调整边界。后面我会详细讲怎么根据自己的情况来划分。2. 核心配置细节与实操要点2.1 配置文件的位置与基本结构Claude Code 的配置主要通过几个途径管理全局配置文件、项目级配置文件、以及环境变量。不同操作系统下路径略有差异但逻辑是一样的。在 macOS 和 Linux 下全局配置通常在~/.claude/目录下。Windows 下则在%USERPROFILE%\.claude\目录下。这个目录里会有settings.json或类似的配置文件具体取决于你安装的版本。我建议的做法是全局配置放默认策略项目级配置放针对性调整。比如你全局默认用 Sonnet但某个项目特别复杂可以在项目根目录下放一个.claude/settings.json把这个项目的默认模型调成 Opus。一个典型的全局配置结构大概长这样{ model: claude-sonnet-4-20250514, maxTokens: 8192, temperature: 0.3, taskRouting: { light: claude-haiku-3-5-20241022, standard: claude-sonnet-4-20250514, heavy: claude-opus-4-20250514 } }这里需要说明的是taskRouting这个字段并不是所有版本都原生支持有些版本需要你通过别名或者脚本来实现类似效果。如果你的版本不支持可以用 shell 别名或者包装脚本来做路由。后面我会给出具体方案。注意模型名称会随版本更新而变化配置时请以你实际可用的模型标识为准。不要直接复制粘贴上面的名称先确认你的账号下有哪些模型可用。2.2 模型选择的关键参数解读选模型不能只看名字有几个参数直接决定了使用体验和成本。上下文窗口。这是模型一次能“看到”的 token 数量。Opus 和 Sonnet 通常有更大的上下文窗口能一次读入更多代码。Haiku 的上下文窗口相对小一些。如果你经常需要模型理解大文件或者多个文件上下文窗口就是硬指标。我的经验是处理超过 500 行的文件时Haiku 就开始力不从心了而 Sonnet 和 Opus 还能保持不错的理解力。输出质量。这个很难量化但可以通过实际测试来感受。我的做法是准备一组标准任务——比如“给这个函数写测试”、“找出这段代码的 bug”、“重构这个模块”——然后分别用三个模型跑一遍对比结果。你会发现 Haiku 在简单任务上表现很好但一旦涉及多步推理就容易出错Sonnet 在大多数任务上都能给出可用的结果Opus 则在复杂任务上有明显优势。响应速度。Haiku 最快Sonnet 次之Opus 最慢。如果你在交互式调试速度很重要。我的做法是调试阶段用 Sonnet因为速度和质量平衡得最好最终确认方案时如果需要再切到 Opus。成本。这是最直接的指标。以我自己的使用情况为例同样一个“写单元测试”的任务Haiku 的成本大约是 Sonnet 的十分之一Opus 的几十分之一。但 Haiku 写的测试往往需要我手动补充边界情况而 Sonnet 写的测试基本可以直接用。所以算总账的时候要把“返工成本”也算进去。2.3 任务分层的具体判断标准怎么判断一个任务属于哪一层我总结了一个简单的判断流程先问自己三个问题这个任务需要模型理解整个项目结构吗如果需要至少是第二层。这个任务需要模型做多步推理吗比如“先分析 A再根据 A 的结果处理 B”。如果需要至少是第二层。这个任务的输出如果错了后果严重吗如果严重比如涉及核心逻辑直接用第三层。如果三个问题的答案都是“否”那就是第一层用 Haiku。举几个具体例子“把这个 JSON 转成 YAML” → 第一层Haiku。“给这个函数写单元测试” → 第二层Sonnet。因为模型需要理解函数的输入输出和边界情况。“这个模块的接口设计合理吗有没有更好的方案” → 第三层Opus。因为需要架构层面的判断。“帮我重命名这个变量” → 第一层Haiku。“为什么这个测试在 CI 上失败但在本地通过” → 第三层Opus。因为需要跨环境推理。这套判断标准不是绝对的你可以根据自己的项目特点调整。关键是养成“先判断再选模型”的习惯而不是无脑用默认。2.4 在 VS Code 和 IDEA 中的配置差异如果你用 VS Code 的 Claude Code 扩展配置主要通过扩展设置面板或者settings.json来管理。VS Code 的好处是可以在工作区级别设置不同项目用不同配置。在 VS Code 的settings.json里你可以这样写{ claude-code.model: claude-sonnet-4-20250514, claude-code.lightModel: claude-haiku-3-5-20241022, claude-code.heavyModel: claude-opus-4-20250514 }IDEA 系列的配置类似但入口在 Settings → Tools → Claude Code 里。IDEA 的一个好处是可以通过运行配置Run Configuration来切换不同的模型策略适合需要频繁切换场景的情况。如果你在 Ubuntu 或者 Windows 上用命令行版本配置主要通过环境变量export CLAUDE_MODELclaude-sonnet-4-20250514 export CLAUDE_LIGHT_MODELclaude-haiku-3-5-20241022 export CLAUDE_HEAVY_MODELclaude-opus-4-20250514然后配合 shell 函数来做路由claude-light() { CLAUDE_MODEL$CLAUDE_LIGHT_MODEL claude $ } claude-heavy() { CLAUDE_MODEL$CLAUDE_HEAVY_MODEL claude $ }这样你在终端里就可以用claude-light和claude-heavy来快速切换。提示环境变量的方式最灵活但需要你手动管理。如果你经常忘记切换可以在 shell 提示符里显示当前模型避免用错。3. 完整实操流程与配置方案3.1 从零开始搭建分层配置假设你刚安装好 Claude Code还没有任何配置。下面是我建议的完整步骤。第一步确认可用模型。先跑一个简单命令看看你的账号下有哪些模型可用。不同账号的权限不同有些人可能没有 Opus 的访问权限。确认之后再开始配置避免配了半天发现用不了。第二步建立全局默认配置。我建议全局默认用 Sonnet因为它在大多数场景下表现均衡。Haiku 作为轻量任务的备选Opus 作为重任务的备选。这样即使你忘记切换也不会出现“用 Haiku 做复杂任务”的灾难。第三步创建项目级覆盖。在你最复杂的那个项目根目录下创建一个.claude/settings.json把默认模型改成 Opus。这样你在这个项目里工作时默认就是最强模型不需要每次手动切换。第四步设置 shell 别名或函数。如果你用命令行版本这一步能大幅提升效率。我自己的.bashrc里有这么几个函数# 轻量任务 cl() { CLAUDE_MODELclaude-haiku-3-5-20241022 claude $ } # 常规任务默认 cs() { CLAUDE_MODELclaude-sonnet-4-20250514 claude $ } # 重任务 co() { CLAUDE_MODELclaude-opus-4-20250514 claude $ }这样我只需要敲cl、cs、co就能快速切换模型比每次改配置文件快得多。第五步验证配置生效。跑一个简单任务看看模型是否正确。你可以在对话里问“你是什么模型”虽然模型不一定能准确回答但可以通过响应速度和输出质量来间接判断。3.2 成本控制的参数调优除了选模型还有几个参数直接影响成本。maxTokens。这个参数控制单次响应的最大 token 数。设得太高模型可能会生成很多你不需要的内容浪费 token设得太低模型可能还没说完就被截断了。我的经验是轻量任务设 2048常规任务设 4096重任务设 8192。这样既能满足大多数需求又不会浪费。temperature。这个参数控制输出的随机性。写代码时我建议设低一点0.2 到 0.3 之间这样输出更稳定、更可预测。如果你需要模型做一些创意性的任务比如起名字、写文档可以适当调高到 0.5 到 0.7。对话轮数控制。Claude Code 的每次对话都会带上之前的上下文这意味着对话轮数越多每次请求的 token 消耗越大。我的做法是完成一个独立任务后主动开启新对话而不是在一个对话里连续做很多不相关的事。这样可以避免上下文膨胀带来的额外成本。我做过一个对比同样完成“写测试 修复 bug 重构”三个任务在一个对话里连续做总 token 消耗大约是分开做的一点八倍。因为每次请求都带上了之前所有对话的历史。所以养成“任务完成就开新对话”的习惯能省下不少。3.3 本地模型与远程模型的混合方案有些场景下你可能会考虑用本地模型来进一步降低成本。比如通过 Ollama 或者 LM Studio 在本地跑一个轻量模型处理那些对隐私要求高或者特别简单的任务。这个方案可行但有几个前提需要说清楚。首先本地模型的能力和远程模型差距还比较大。即使是目前最好的本地模型在代码理解方面也远不如 Sonnet 或 Opus。所以本地模型只适合处理最简单的任务比如格式化、重命名、写简单注释。其次本地模型需要你有足够的硬件资源。跑一个 7B 参数的模型至少需要 8GB 显存13B 需要 16GB更大的模型需求更高。如果你的机器配置一般跑本地模型可能会很慢反而影响效率。如果你确实想尝试混合方案我的建议是本地模型只处理第一层任务中最简单的那些比如“把这段代码的缩进改成两个空格”、“给这个变量起个名字”。稍微复杂一点的任务还是交给远程模型。配置方式上你可以在 Claude Code 里设置一个自定义的模型服务地址指向本地的 Ollama 或 LM Studio 实例。具体配置取决于你使用的版本一般需要在配置文件里指定baseUrl和model字段。注意本地模型的输出质量和远程模型差距明显不要对本地模型期望过高。我自己的体验是本地模型处理简单任务还行但一旦涉及逻辑推理就容易出错需要人工检查。3.4 一个完整的配置示例下面是我目前正在使用的一套配置供你参考。这套配置在我日常使用中表现稳定成本可控。全局配置~/.claude/settings.json{ model: claude-sonnet-4-20250514, maxTokens: 4096, temperature: 0.3, models: { light: claude-haiku-3-5-20241022, standard: claude-sonnet-4-20250514, heavy: claude-opus-4-20250514 } }项目级配置复杂项目的.claude/settings.json{ model: claude-opus-4-20250514, maxTokens: 8192, temperature: 0.2 }Shell 函数.bashrc或.zshrcclaude-light() { CLAUDE_MODELclaude-haiku-3-5-20241022 claude $ } claude-standard() { CLAUDE_MODELclaude-sonnet-4-20250514 claude $ } claude-heavy() { CLAUDE_MODELclaude-opus-4-20250514 claude $ }这套配置的核心逻辑是全局默认用 Sonnet 保底复杂项目自动升级到 Opus简单任务通过 shell 函数手动降级到 Haiku。实际使用中我大约 60% 的时间用 Sonnet25% 用 Haiku15% 用 Opus。这个比例下成本和质量达到了比较好的平衡。4. 常见问题与排查技巧实录4.1 模型切换不生效怎么办这是最常见的问题。你改了配置但感觉模型还是原来的。排查思路如下。先确认配置文件的位置是否正确。不同版本的 Claude Code 可能读取不同的配置文件。你可以通过查看日志或者运行一个诊断命令来确认当前加载的是哪个配置。然后检查配置的优先级。一般来说项目级配置会覆盖全局配置环境变量会覆盖配置文件。如果你在项目里设置了 Opus但环境变量里还是 Sonnet那最终生效的是环境变量。所以排查的时候要从高优先级往低优先级查。还有一个容易忽略的点有些配置需要重启 Claude Code 才能生效。如果你是在对话中途改的配置可能不会立即生效。建议改完配置后开一个新对话测试。4.2 成本突然飙升的排查方法如果你发现某天成本突然比平时高很多可以从这几个方向排查。先看是不是某个任务用了 Opus 但你没注意到。Opus 的成本远高于 Sonnet 和 Haiku一次重任务的消耗可能顶得上几十次轻量任务。检查一下当天的对话记录看看有没有用错模型的情况。然后看是不是对话轮数过多。前面说过每次请求都会带上之前的上下文对话越长单次请求的 token 消耗越大。如果你在一个对话里连续做了很多任务成本自然会高。还有一个可能是上下文窗口被填满了。当你处理的文件很大或者对话历史很长时模型需要处理的 token 数会大幅增加。这种情况下即使你用 Haiku成本也可能不低。解决办法是及时开新对话避免上下文膨胀。我自己的做法是每天结束工作时花两分钟看一下当天的使用统计如果发现异常第二天就调整策略。养成这个习惯后我几乎没有出现过“月底看到账单吓一跳”的情况。4.3 模型输出质量不稳定的应对有时候同一个模型同样的任务输出质量却忽高忽低。这通常和几个因素有关。上下文质量。如果你给模型的上下文里包含了大量无关代码或者过时的注释模型可能会被误导。我的做法是在让模型处理某个文件之前先确保这个文件是干净的没有多余的注释和死代码。任务描述的清晰度。模型不是读心术如果你的指令模糊输出自然不稳定。我习惯在指令里明确说明输入是什么、期望输出是什么、有什么约束条件。比如不说“优化这段代码”而是说“把这个函数的圈复杂度从 15 降到 10 以下保持功能不变”。temperature 设置。如果你把 temperature 设得比较高输出就会更随机。写代码时建议设低一点0.2 到 0.3 之间比较合适。模型本身的限制。每个模型都有自己擅长的领域和不擅长的领域。Haiku 在处理简单任务时很稳定但复杂任务就容易出错。如果你发现某个模型在某个任务上反复出错可能不是配置问题而是这个任务超出了它的能力范围该升级模型了。4.4 常见问题速查表问题现象可能原因排查方法解决方案模型切换不生效配置优先级冲突检查环境变量和项目配置从高优先级往低优先级排查成本突然飙升误用 Opus 或对话过长查看当天使用统计调整模型选择及时开新对话输出质量不稳定上下文质量差或指令模糊检查输入内容和指令清理上下文明确任务描述响应速度慢用了 Opus 或上下文过大确认当前模型和对话长度切换到 Sonnet 或开新对话本地模型效果差模型能力不足对比远程模型输出本地模型只处理简单任务配置不生效需要重启或版本不支持查看日志和版本文档重启应用或升级版本4.5 几个我踩过的坑第一个坑是过度依赖 Opus。刚开始用的时候觉得 Opus 效果好什么都用它结果月底一看账单傻眼了。后来才慢慢学会分层把简单任务交给 Haiku。第二个坑是忘记切换模型。有次用 Haiku 处理一个复杂的重构任务模型给了一个看似合理但实际有问题的方案我跟着改了半天才发现方向错了。从那以后我养成了习惯开始任务前先判断复杂度再选模型。第三个坑是对话开得太长。有次在一个对话里连续做了五六个任务最后发现单次请求的 token 消耗是平时的三倍。后来我强制自己每个任务完成后就开新对话成本立刻降下来了。第四个坑是配置写错但没发现。有次把模型名称拼错了结果 Claude Code 回退到了默认模型我用了好几天才发现。后来我养成了习惯改完配置后跑一个测试任务确认模型确实切换了。这些坑其实都不难避免关键是要养成“先判断、再配置、后验证”的习惯。花几分钟确认一下比事后返工划算得多。4.6 进阶技巧根据项目自动切换配置如果你手头有多个项目每个项目的复杂度不同可以给每个项目单独配置。在项目根目录下放一个.claude/settings.jsonClaude Code 会自动读取这个配置。我的做法是简单项目比如个人小工具默认用 Haiku中等项目用 Sonnet复杂项目用 Opus。这样我切换到不同项目时不需要手动改配置Claude Code 会自动用合适的模型。如果你用 VS Code还可以通过工作区设置来实现类似效果。每个工作区有自己的settings.json互不干扰。这个技巧的好处是省心。你不需要每次开始工作前想“今天该用什么模型”配置会自动帮你决定。当然前提是你对每个项目的复杂度有清晰的判断。提示项目级配置的优先级高于全局配置但低于环境变量。如果你发现项目配置没生效检查一下是不是环境变量覆盖了它。5. 不同场景下的配置策略5.1 个人开发者与小团队的差异个人开发者和小团队的配置策略应该有所不同。个人开发者通常对成本更敏感而且项目类型相对固定可以更激进地使用轻量模型。小团队则需要考虑协作和一致性配置应该更保守一些。个人开发者的策略大胆用 Haiku 处理简单任务只在真正需要的时候才用 Opus。我自己的比例是 60% Sonnet、25% Haiku、15% Opus个人开发者可以调整到 50% Haiku、40% Sonnet、10% Opus进一步压缩成本。小团队的策略统一默认用 Sonnet避免因为某个成员用了 Haiku 导致输出质量参差不齐。Opus 的使用需要有一定的规范比如只在代码审查和架构设计时使用。团队可以共享一套配置文件确保大家用的是同一套策略。5.2 不同编程语言的配置微调不同编程语言对模型的要求也不一样。根据我的经验TypeScript 和 Python 这类语言代码结构比较规范Sonnet 完全能胜任大多数任务。Haiku 在处理简单的类型定义和函数实现时也表现不错。Rust 和 C 这类语言因为涉及内存管理和生命周期等复杂概念建议至少用 Sonnet复杂场景用 Opus。Haiku 在处理这类语言时容易忽略一些关键细节。SQL 和 Shell 脚本任务通常比较独立Haiku 就能处理得很好。除非涉及复杂的查询优化那可能需要 Sonnet。HTML 和 CSSHaiku 足够。这类任务通常是格式调整和样式修改不需要深度推理。5.3 调试场景下的特殊配置调试是 Claude Code 使用中最耗 token 的场景之一因为往往需要反复对话。我的调试配置策略是开始调试时用 Sonnet把问题和相关代码贴进去让模型给出可能的原因和排查方向。如果 Sonnet 给出的方向不对再升级到 Opus。如果 Opus 也搞不定那可能不是模型的问题而是问题本身需要更多信息。调试过程中每尝试一个方向后如果没解决问题开一个新对话把最新的发现和代码贴进去而不是在原来的对话里继续。这样可以避免上下文膨胀也能让模型不受之前错误方向的影响。如果 bug 比较简单比如拼写错误、类型不匹配直接用 Haiku 就行。Haiku 在这类任务上速度很快成本也低。5.4 代码审查的配置建议代码审查是 Claude Code 的一个高频使用场景。我的建议是日常审查用 Sonnet重要模块的审查用 Opus。Sonnet 能发现大多数明显的问题比如未处理的边界情况、潜在的 null 引用、不一致的命名风格等。Opus 则能发现更深层次的问题比如设计模式使用不当、潜在的并发问题、架构层面的隐患。审查时我习惯把整个文件或者整个模块贴进去让模型从整体上分析。这时候上下文窗口就很重要了。Sonnet 和 Opus 的上下文窗口足够大能一次处理几百行的代码。Haiku 就不太适合这种场景因为它可能看不全。审查完成后我会让模型把发现的问题按严重程度排序然后我逐条确认。这样比让模型直接改代码更可靠因为有些问题模型可能误报需要人工判断。6. 长期使用的经验与建议6.1 建立自己的任务分类习惯这套配置的核心不是技术而是习惯。你需要养成“先判断任务类型再选择模型”的习惯。刚开始可能会觉得麻烦但用了一两周之后就会变成条件反射。我的做法是在脑子里过一遍这个任务需要理解整个项目吗需要多步推理吗输出错了后果严重吗三个问题一过基本就能确定用哪个模型了。如果你觉得每次判断太累可以准备一个简单的清单贴在显示器旁边前两周照着清单判断后面就自然记住了。6.2 定期回顾和调整配置模型在更新你的项目也在变化所以配置不是一成不变的。我建议每个月花半小时回顾一下上个月的使用情况哪些任务用错了模型哪些模型的表现超出了预期成本分布是否合理根据回顾结果调整配置。比如你发现某个项目最近变得复杂了可以把默认模型从 Sonnet 升级到 Opus。或者你发现某个任务其实 Haiku 就能做好那就把它从 Sonnet 降级到 Haiku。这个回顾不需要很正式就是看看使用统计想想有没有可以优化的地方。花的时间不多但效果很明显。6.3 关于成本和质量平衡的个人体会用了这么久我最大的体会是成本和质量不是非此即彼的关系而是可以通过合理配置同时优化的。关键在于你愿不愿意花一点时间理解自己的使用模式然后针对性地调整。我见过很多人要么完全不关心成本要么为了省钱牺牲质量。这两种做法都不理想。真正有效的做法是先了解自己的使用模式然后找到那个“刚好够用”的配置点。这个点因人而异需要你自己去试。但只要你开始有意识地管理模型配置就已经比大多数人强了。剩下的就是不断微调找到最适合自己的那套方案。最后分享一个小技巧如果你不确定某个任务该用哪个模型先用 Haiku 试一下。如果 Haiku 的输出你能接受那就用 Haiku如果不能接受再升级到 Sonnet如果 Sonnet 也不行再用 Opus。这样从低到高试能确保你不会在不必要的任务上花冤枉钱。当然前提是这个任务的试错成本不高如果任务本身很关键那就直接从 Sonnet 或 Opus 开始不要冒险。 Claude Code 分层调度配置：Haiku/Sonnet/Opus 模型选择与成本优化实战
1. 这套配置到底在解决什么问题1.1 从一个真实痛点说起用 Claude Code 写代码的人大概率都经历过这种纠结开着 Opus 跑一个重构任务效果确实好但看着 token 消耗心里发慌换成 Haiku 省钱了结果它连项目结构都没读明白就开始瞎改。更别提那些需要反复来回对话的调试场景一轮下来账单数字跳得比心率还快。我自己的情况是手头同时维护着三个项目一个 TypeScript 的全栈应用、一个 Python 的数据处理脚本集、还有一个 Rust 写的 CLI 工具。每天用 Claude Code 的时间大概在四到六小时主要做代码审查、重构、写测试和排查 bug。最开始我全用默认配置一个月下来发现成本远超预期但换成最便宜的模型又明显感觉“智商不够用”。后来我花了两周时间反复调整模型配置策略最终稳定在一套“分层调度”的方案上。核心思路很简单不同任务用不同模型该聪明的地方不省钱该省钱的地方不浪费。实测下来成本降了大约六成而代码质量几乎没有下降。这套配置适合谁如果你每天用 Claude Code 超过一小时或者手头有多个项目需要频繁切换又或者你对成本比较敏感但不想牺牲效果那这套思路应该能帮到你。如果你只是偶尔用一下写个脚本那默认配置其实也够用不必折腾。1.2 为什么“一刀切”的模型配置必然低效很多人配置 Claude Code 的方式很粗暴要么全用最强的模型要么全用最便宜的。这两种做法都有问题。全用最强模型的问题在于你大量的 token 其实花在了“不需要那么聪明”的任务上。比如让模型帮你格式化一段 JSON、重命名一个变量、写一个简单的正则表达式这些任务用轻量模型完全能胜任用最强模型就是杀鸡用牛刀。我统计过自己一周的对话记录大约 65% 的请求属于“简单任务”——定义清晰、上下文需求少、不需要深度推理。这部分如果用轻量模型处理成本可以压到原来的十分之一甚至更低。全用最便宜模型的问题则相反。当你需要模型理解一个复杂的代码库结构、做跨文件的依赖分析、或者设计一个模块的接口时轻量模型往往抓不住重点。它可能会忽略掉关键的上下文给出看似合理但实际有问题的建议。这种“省了小钱赔了大钱”的情况在调试复杂 bug 时尤其明显——模型给了一个错误的修复方向你跟着试了半天最后发现还不如一开始就用强模型。所以关键不在于“用哪个模型”而在于“什么任务用什么模型”。这就是分层调度的核心。1.3 分层调度的基本框架我把日常使用 Claude Code 的任务分成三个层级第一层轻量任务。包括代码格式化、简单的重命名、生成注释、写正则、转换数据格式、回答语法问题等。这类任务的特点是输入输出都很明确不需要理解整个项目单次对话就能完成。适合用 Haiku 级别的模型。第二层常规任务。包括写单元测试、实现一个独立的函数、修复简单的 bug、代码审查、写文档等。这类任务需要一定的上下文理解但不需要跨多个文件的深度推理。适合用 Sonnet 级别的模型。第三层重任务。包括跨文件重构、架构设计、复杂 bug 排查、性能优化、理解陌生代码库等。这类任务需要模型有很强的推理能力和长上下文理解能力。适合用 Opus 级别的模型。这套分层不是拍脑袋定的而是基于我两周的实际使用数据。我记录了每次对话的任务类型、使用的模型、以及最终效果然后不断调整边界。后面我会详细讲怎么根据自己的情况来划分。2. 核心配置细节与实操要点2.1 配置文件的位置与基本结构Claude Code 的配置主要通过几个途径管理全局配置文件、项目级配置文件、以及环境变量。不同操作系统下路径略有差异但逻辑是一样的。在 macOS 和 Linux 下全局配置通常在~/.claude/目录下。Windows 下则在%USERPROFILE%\.claude\目录下。这个目录里会有settings.json或类似的配置文件具体取决于你安装的版本。我建议的做法是全局配置放默认策略项目级配置放针对性调整。比如你全局默认用 Sonnet但某个项目特别复杂可以在项目根目录下放一个.claude/settings.json把这个项目的默认模型调成 Opus。一个典型的全局配置结构大概长这样{ model: claude-sonnet-4-20250514, maxTokens: 8192, temperature: 0.3, taskRouting: { light: claude-haiku-3-5-20241022, standard: claude-sonnet-4-20250514, heavy: claude-opus-4-20250514 } }这里需要说明的是taskRouting这个字段并不是所有版本都原生支持有些版本需要你通过别名或者脚本来实现类似效果。如果你的版本不支持可以用 shell 别名或者包装脚本来做路由。后面我会给出具体方案。注意模型名称会随版本更新而变化配置时请以你实际可用的模型标识为准。不要直接复制粘贴上面的名称先确认你的账号下有哪些模型可用。2.2 模型选择的关键参数解读选模型不能只看名字有几个参数直接决定了使用体验和成本。上下文窗口。这是模型一次能“看到”的 token 数量。Opus 和 Sonnet 通常有更大的上下文窗口能一次读入更多代码。Haiku 的上下文窗口相对小一些。如果你经常需要模型理解大文件或者多个文件上下文窗口就是硬指标。我的经验是处理超过 500 行的文件时Haiku 就开始力不从心了而 Sonnet 和 Opus 还能保持不错的理解力。输出质量。这个很难量化但可以通过实际测试来感受。我的做法是准备一组标准任务——比如“给这个函数写测试”、“找出这段代码的 bug”、“重构这个模块”——然后分别用三个模型跑一遍对比结果。你会发现 Haiku 在简单任务上表现很好但一旦涉及多步推理就容易出错Sonnet 在大多数任务上都能给出可用的结果Opus 则在复杂任务上有明显优势。响应速度。Haiku 最快Sonnet 次之Opus 最慢。如果你在交互式调试速度很重要。我的做法是调试阶段用 Sonnet因为速度和质量平衡得最好最终确认方案时如果需要再切到 Opus。成本。这是最直接的指标。以我自己的使用情况为例同样一个“写单元测试”的任务Haiku 的成本大约是 Sonnet 的十分之一Opus 的几十分之一。但 Haiku 写的测试往往需要我手动补充边界情况而 Sonnet 写的测试基本可以直接用。所以算总账的时候要把“返工成本”也算进去。2.3 任务分层的具体判断标准怎么判断一个任务属于哪一层我总结了一个简单的判断流程先问自己三个问题这个任务需要模型理解整个项目结构吗如果需要至少是第二层。这个任务需要模型做多步推理吗比如“先分析 A再根据 A 的结果处理 B”。如果需要至少是第二层。这个任务的输出如果错了后果严重吗如果严重比如涉及核心逻辑直接用第三层。如果三个问题的答案都是“否”那就是第一层用 Haiku。举几个具体例子“把这个 JSON 转成 YAML” → 第一层Haiku。“给这个函数写单元测试” → 第二层Sonnet。因为模型需要理解函数的输入输出和边界情况。“这个模块的接口设计合理吗有没有更好的方案” → 第三层Opus。因为需要架构层面的判断。“帮我重命名这个变量” → 第一层Haiku。“为什么这个测试在 CI 上失败但在本地通过” → 第三层Opus。因为需要跨环境推理。这套判断标准不是绝对的你可以根据自己的项目特点调整。关键是养成“先判断再选模型”的习惯而不是无脑用默认。2.4 在 VS Code 和 IDEA 中的配置差异如果你用 VS Code 的 Claude Code 扩展配置主要通过扩展设置面板或者settings.json来管理。VS Code 的好处是可以在工作区级别设置不同项目用不同配置。在 VS Code 的settings.json里你可以这样写{ claude-code.model: claude-sonnet-4-20250514, claude-code.lightModel: claude-haiku-3-5-20241022, claude-code.heavyModel: claude-opus-4-20250514 }IDEA 系列的配置类似但入口在 Settings → Tools → Claude Code 里。IDEA 的一个好处是可以通过运行配置Run Configuration来切换不同的模型策略适合需要频繁切换场景的情况。如果你在 Ubuntu 或者 Windows 上用命令行版本配置主要通过环境变量export CLAUDE_MODELclaude-sonnet-4-20250514 export CLAUDE_LIGHT_MODELclaude-haiku-3-5-20241022 export CLAUDE_HEAVY_MODELclaude-opus-4-20250514然后配合 shell 函数来做路由claude-light() { CLAUDE_MODEL$CLAUDE_LIGHT_MODEL claude $ } claude-heavy() { CLAUDE_MODEL$CLAUDE_HEAVY_MODEL claude $ }这样你在终端里就可以用claude-light和claude-heavy来快速切换。提示环境变量的方式最灵活但需要你手动管理。如果你经常忘记切换可以在 shell 提示符里显示当前模型避免用错。3. 完整实操流程与配置方案3.1 从零开始搭建分层配置假设你刚安装好 Claude Code还没有任何配置。下面是我建议的完整步骤。第一步确认可用模型。先跑一个简单命令看看你的账号下有哪些模型可用。不同账号的权限不同有些人可能没有 Opus 的访问权限。确认之后再开始配置避免配了半天发现用不了。第二步建立全局默认配置。我建议全局默认用 Sonnet因为它在大多数场景下表现均衡。Haiku 作为轻量任务的备选Opus 作为重任务的备选。这样即使你忘记切换也不会出现“用 Haiku 做复杂任务”的灾难。第三步创建项目级覆盖。在你最复杂的那个项目根目录下创建一个.claude/settings.json把默认模型改成 Opus。这样你在这个项目里工作时默认就是最强模型不需要每次手动切换。第四步设置 shell 别名或函数。如果你用命令行版本这一步能大幅提升效率。我自己的.bashrc里有这么几个函数# 轻量任务 cl() { CLAUDE_MODELclaude-haiku-3-5-20241022 claude $ } # 常规任务默认 cs() { CLAUDE_MODELclaude-sonnet-4-20250514 claude $ } # 重任务 co() { CLAUDE_MODELclaude-opus-4-20250514 claude $ }这样我只需要敲cl、cs、co就能快速切换模型比每次改配置文件快得多。第五步验证配置生效。跑一个简单任务看看模型是否正确。你可以在对话里问“你是什么模型”虽然模型不一定能准确回答但可以通过响应速度和输出质量来间接判断。3.2 成本控制的参数调优除了选模型还有几个参数直接影响成本。maxTokens。这个参数控制单次响应的最大 token 数。设得太高模型可能会生成很多你不需要的内容浪费 token设得太低模型可能还没说完就被截断了。我的经验是轻量任务设 2048常规任务设 4096重任务设 8192。这样既能满足大多数需求又不会浪费。temperature。这个参数控制输出的随机性。写代码时我建议设低一点0.2 到 0.3 之间这样输出更稳定、更可预测。如果你需要模型做一些创意性的任务比如起名字、写文档可以适当调高到 0.5 到 0.7。对话轮数控制。Claude Code 的每次对话都会带上之前的上下文这意味着对话轮数越多每次请求的 token 消耗越大。我的做法是完成一个独立任务后主动开启新对话而不是在一个对话里连续做很多不相关的事。这样可以避免上下文膨胀带来的额外成本。我做过一个对比同样完成“写测试 修复 bug 重构”三个任务在一个对话里连续做总 token 消耗大约是分开做的一点八倍。因为每次请求都带上了之前所有对话的历史。所以养成“任务完成就开新对话”的习惯能省下不少。3.3 本地模型与远程模型的混合方案有些场景下你可能会考虑用本地模型来进一步降低成本。比如通过 Ollama 或者 LM Studio 在本地跑一个轻量模型处理那些对隐私要求高或者特别简单的任务。这个方案可行但有几个前提需要说清楚。首先本地模型的能力和远程模型差距还比较大。即使是目前最好的本地模型在代码理解方面也远不如 Sonnet 或 Opus。所以本地模型只适合处理最简单的任务比如格式化、重命名、写简单注释。其次本地模型需要你有足够的硬件资源。跑一个 7B 参数的模型至少需要 8GB 显存13B 需要 16GB更大的模型需求更高。如果你的机器配置一般跑本地模型可能会很慢反而影响效率。如果你确实想尝试混合方案我的建议是本地模型只处理第一层任务中最简单的那些比如“把这段代码的缩进改成两个空格”、“给这个变量起个名字”。稍微复杂一点的任务还是交给远程模型。配置方式上你可以在 Claude Code 里设置一个自定义的模型服务地址指向本地的 Ollama 或 LM Studio 实例。具体配置取决于你使用的版本一般需要在配置文件里指定baseUrl和model字段。注意本地模型的输出质量和远程模型差距明显不要对本地模型期望过高。我自己的体验是本地模型处理简单任务还行但一旦涉及逻辑推理就容易出错需要人工检查。3.4 一个完整的配置示例下面是我目前正在使用的一套配置供你参考。这套配置在我日常使用中表现稳定成本可控。全局配置~/.claude/settings.json{ model: claude-sonnet-4-20250514, maxTokens: 4096, temperature: 0.3, models: { light: claude-haiku-3-5-20241022, standard: claude-sonnet-4-20250514, heavy: claude-opus-4-20250514 } }项目级配置复杂项目的.claude/settings.json{ model: claude-opus-4-20250514, maxTokens: 8192, temperature: 0.2 }Shell 函数.bashrc或.zshrcclaude-light() { CLAUDE_MODELclaude-haiku-3-5-20241022 claude $ } claude-standard() { CLAUDE_MODELclaude-sonnet-4-20250514 claude $ } claude-heavy() { CLAUDE_MODELclaude-opus-4-20250514 claude $ }这套配置的核心逻辑是全局默认用 Sonnet 保底复杂项目自动升级到 Opus简单任务通过 shell 函数手动降级到 Haiku。实际使用中我大约 60% 的时间用 Sonnet25% 用 Haiku15% 用 Opus。这个比例下成本和质量达到了比较好的平衡。4. 常见问题与排查技巧实录4.1 模型切换不生效怎么办这是最常见的问题。你改了配置但感觉模型还是原来的。排查思路如下。先确认配置文件的位置是否正确。不同版本的 Claude Code 可能读取不同的配置文件。你可以通过查看日志或者运行一个诊断命令来确认当前加载的是哪个配置。然后检查配置的优先级。一般来说项目级配置会覆盖全局配置环境变量会覆盖配置文件。如果你在项目里设置了 Opus但环境变量里还是 Sonnet那最终生效的是环境变量。所以排查的时候要从高优先级往低优先级查。还有一个容易忽略的点有些配置需要重启 Claude Code 才能生效。如果你是在对话中途改的配置可能不会立即生效。建议改完配置后开一个新对话测试。4.2 成本突然飙升的排查方法如果你发现某天成本突然比平时高很多可以从这几个方向排查。先看是不是某个任务用了 Opus 但你没注意到。Opus 的成本远高于 Sonnet 和 Haiku一次重任务的消耗可能顶得上几十次轻量任务。检查一下当天的对话记录看看有没有用错模型的情况。然后看是不是对话轮数过多。前面说过每次请求都会带上之前的上下文对话越长单次请求的 token 消耗越大。如果你在一个对话里连续做了很多任务成本自然会高。还有一个可能是上下文窗口被填满了。当你处理的文件很大或者对话历史很长时模型需要处理的 token 数会大幅增加。这种情况下即使你用 Haiku成本也可能不低。解决办法是及时开新对话避免上下文膨胀。我自己的做法是每天结束工作时花两分钟看一下当天的使用统计如果发现异常第二天就调整策略。养成这个习惯后我几乎没有出现过“月底看到账单吓一跳”的情况。4.3 模型输出质量不稳定的应对有时候同一个模型同样的任务输出质量却忽高忽低。这通常和几个因素有关。上下文质量。如果你给模型的上下文里包含了大量无关代码或者过时的注释模型可能会被误导。我的做法是在让模型处理某个文件之前先确保这个文件是干净的没有多余的注释和死代码。任务描述的清晰度。模型不是读心术如果你的指令模糊输出自然不稳定。我习惯在指令里明确说明输入是什么、期望输出是什么、有什么约束条件。比如不说“优化这段代码”而是说“把这个函数的圈复杂度从 15 降到 10 以下保持功能不变”。temperature 设置。如果你把 temperature 设得比较高输出就会更随机。写代码时建议设低一点0.2 到 0.3 之间比较合适。模型本身的限制。每个模型都有自己擅长的领域和不擅长的领域。Haiku 在处理简单任务时很稳定但复杂任务就容易出错。如果你发现某个模型在某个任务上反复出错可能不是配置问题而是这个任务超出了它的能力范围该升级模型了。4.4 常见问题速查表问题现象可能原因排查方法解决方案模型切换不生效配置优先级冲突检查环境变量和项目配置从高优先级往低优先级排查成本突然飙升误用 Opus 或对话过长查看当天使用统计调整模型选择及时开新对话输出质量不稳定上下文质量差或指令模糊检查输入内容和指令清理上下文明确任务描述响应速度慢用了 Opus 或上下文过大确认当前模型和对话长度切换到 Sonnet 或开新对话本地模型效果差模型能力不足对比远程模型输出本地模型只处理简单任务配置不生效需要重启或版本不支持查看日志和版本文档重启应用或升级版本4.5 几个我踩过的坑第一个坑是过度依赖 Opus。刚开始用的时候觉得 Opus 效果好什么都用它结果月底一看账单傻眼了。后来才慢慢学会分层把简单任务交给 Haiku。第二个坑是忘记切换模型。有次用 Haiku 处理一个复杂的重构任务模型给了一个看似合理但实际有问题的方案我跟着改了半天才发现方向错了。从那以后我养成了习惯开始任务前先判断复杂度再选模型。第三个坑是对话开得太长。有次在一个对话里连续做了五六个任务最后发现单次请求的 token 消耗是平时的三倍。后来我强制自己每个任务完成后就开新对话成本立刻降下来了。第四个坑是配置写错但没发现。有次把模型名称拼错了结果 Claude Code 回退到了默认模型我用了好几天才发现。后来我养成了习惯改完配置后跑一个测试任务确认模型确实切换了。这些坑其实都不难避免关键是要养成“先判断、再配置、后验证”的习惯。花几分钟确认一下比事后返工划算得多。4.6 进阶技巧根据项目自动切换配置如果你手头有多个项目每个项目的复杂度不同可以给每个项目单独配置。在项目根目录下放一个.claude/settings.jsonClaude Code 会自动读取这个配置。我的做法是简单项目比如个人小工具默认用 Haiku中等项目用 Sonnet复杂项目用 Opus。这样我切换到不同项目时不需要手动改配置Claude Code 会自动用合适的模型。如果你用 VS Code还可以通过工作区设置来实现类似效果。每个工作区有自己的settings.json互不干扰。这个技巧的好处是省心。你不需要每次开始工作前想“今天该用什么模型”配置会自动帮你决定。当然前提是你对每个项目的复杂度有清晰的判断。提示项目级配置的优先级高于全局配置但低于环境变量。如果你发现项目配置没生效检查一下是不是环境变量覆盖了它。5. 不同场景下的配置策略5.1 个人开发者与小团队的差异个人开发者和小团队的配置策略应该有所不同。个人开发者通常对成本更敏感而且项目类型相对固定可以更激进地使用轻量模型。小团队则需要考虑协作和一致性配置应该更保守一些。个人开发者的策略大胆用 Haiku 处理简单任务只在真正需要的时候才用 Opus。我自己的比例是 60% Sonnet、25% Haiku、15% Opus个人开发者可以调整到 50% Haiku、40% Sonnet、10% Opus进一步压缩成本。小团队的策略统一默认用 Sonnet避免因为某个成员用了 Haiku 导致输出质量参差不齐。Opus 的使用需要有一定的规范比如只在代码审查和架构设计时使用。团队可以共享一套配置文件确保大家用的是同一套策略。5.2 不同编程语言的配置微调不同编程语言对模型的要求也不一样。根据我的经验TypeScript 和 Python 这类语言代码结构比较规范Sonnet 完全能胜任大多数任务。Haiku 在处理简单的类型定义和函数实现时也表现不错。Rust 和 C 这类语言因为涉及内存管理和生命周期等复杂概念建议至少用 Sonnet复杂场景用 Opus。Haiku 在处理这类语言时容易忽略一些关键细节。SQL 和 Shell 脚本任务通常比较独立Haiku 就能处理得很好。除非涉及复杂的查询优化那可能需要 Sonnet。HTML 和 CSSHaiku 足够。这类任务通常是格式调整和样式修改不需要深度推理。5.3 调试场景下的特殊配置调试是 Claude Code 使用中最耗 token 的场景之一因为往往需要反复对话。我的调试配置策略是开始调试时用 Sonnet把问题和相关代码贴进去让模型给出可能的原因和排查方向。如果 Sonnet 给出的方向不对再升级到 Opus。如果 Opus 也搞不定那可能不是模型的问题而是问题本身需要更多信息。调试过程中每尝试一个方向后如果没解决问题开一个新对话把最新的发现和代码贴进去而不是在原来的对话里继续。这样可以避免上下文膨胀也能让模型不受之前错误方向的影响。如果 bug 比较简单比如拼写错误、类型不匹配直接用 Haiku 就行。Haiku 在这类任务上速度很快成本也低。5.4 代码审查的配置建议代码审查是 Claude Code 的一个高频使用场景。我的建议是日常审查用 Sonnet重要模块的审查用 Opus。Sonnet 能发现大多数明显的问题比如未处理的边界情况、潜在的 null 引用、不一致的命名风格等。Opus 则能发现更深层次的问题比如设计模式使用不当、潜在的并发问题、架构层面的隐患。审查时我习惯把整个文件或者整个模块贴进去让模型从整体上分析。这时候上下文窗口就很重要了。Sonnet 和 Opus 的上下文窗口足够大能一次处理几百行的代码。Haiku 就不太适合这种场景因为它可能看不全。审查完成后我会让模型把发现的问题按严重程度排序然后我逐条确认。这样比让模型直接改代码更可靠因为有些问题模型可能误报需要人工判断。6. 长期使用的经验与建议6.1 建立自己的任务分类习惯这套配置的核心不是技术而是习惯。你需要养成“先判断任务类型再选择模型”的习惯。刚开始可能会觉得麻烦但用了一两周之后就会变成条件反射。我的做法是在脑子里过一遍这个任务需要理解整个项目吗需要多步推理吗输出错了后果严重吗三个问题一过基本就能确定用哪个模型了。如果你觉得每次判断太累可以准备一个简单的清单贴在显示器旁边前两周照着清单判断后面就自然记住了。6.2 定期回顾和调整配置模型在更新你的项目也在变化所以配置不是一成不变的。我建议每个月花半小时回顾一下上个月的使用情况哪些任务用错了模型哪些模型的表现超出了预期成本分布是否合理根据回顾结果调整配置。比如你发现某个项目最近变得复杂了可以把默认模型从 Sonnet 升级到 Opus。或者你发现某个任务其实 Haiku 就能做好那就把它从 Sonnet 降级到 Haiku。这个回顾不需要很正式就是看看使用统计想想有没有可以优化的地方。花的时间不多但效果很明显。6.3 关于成本和质量平衡的个人体会用了这么久我最大的体会是成本和质量不是非此即彼的关系而是可以通过合理配置同时优化的。关键在于你愿不愿意花一点时间理解自己的使用模式然后针对性地调整。我见过很多人要么完全不关心成本要么为了省钱牺牲质量。这两种做法都不理想。真正有效的做法是先了解自己的使用模式然后找到那个“刚好够用”的配置点。这个点因人而异需要你自己去试。但只要你开始有意识地管理模型配置就已经比大多数人强了。剩下的就是不断微调找到最适合自己的那套方案。最后分享一个小技巧如果你不确定某个任务该用哪个模型先用 Haiku 试一下。如果 Haiku 的输出你能接受那就用 Haiku如果不能接受再升级到 Sonnet如果 Sonnet 也不行再用 Opus。这样从低到高试能确保你不会在不必要的任务上花冤枉钱。当然前提是这个任务的试错成本不高如果任务本身很关键那就直接从 Sonnet 或 Opus 开始不要冒险。