1. 这套配置到底在解决什么问题Claude Code 用了一段时间之后很多人都会卡在同一个坎上默认模型确实聪明但账单也真的让人心跳加速。尤其是让它读大文件、跑长上下文任务的时候token 消耗速度堪比开了水龙头。我自己的体感是如果完全用默认配置做日常开发辅助一个重度使用的下午就能烧掉相当可观的额度。所以这套配置的核心目标就两件事该聪明的地方保持聪明该省钱的地方坚决省钱。听起来像废话但真正落地的时候它涉及的是模型分层、上下文窗口控制、以及不同任务路由到不同模型这三个层面的配合。不是简单换个模型名就完事了。先说清楚这套配置适合谁。如果你只是偶尔问几个问题那默认配置完全够用不用折腾。但如果你符合下面任意一条这套东西就值得花二十分钟配一下每天用 Claude Code 超过两小时做的是真实项目开发经常需要让它读整个文件甚至整个目录手头有本地模型资源比如 Ollama、LM Studio想分担一部分简单任务对成本敏感但又不想牺牲复杂任务的输出质量我自己是第三种和第四种的混合体。手上有台带独显的机器跑着 Ollama日常大量任务是改配置、写样板代码、解释报错这类不需要顶级智商的活完全没必要每次都调用最贵的模型。把这部分任务分流出去之后我的实际支出大概降到了原来的三分之一左右而复杂架构设计、疑难 bug 排查这些真正需要脑子的活依然交给最强的模型处理。这里有个关键认知要先建立起来模型配置不是选一个最好的而是给不同任务配不同的脑子。就像你不会让公司 CTO 去贴发票也不会让实习生去定技术架构。Claude Code 的配置体系恰好支持这种分层只是很多人没意识到而已。接下来我会把整套思路拆开讲从配置文件的结构到每个环境变量的实际作用再到怎么根据任务类型做路由最后是我踩过的坑和排查方法。你照着抄作业就行但更重要的是理解每一步为什么这么配。2. 配置文件与环境变量的底层逻辑2.1 settings.json 到底管什么Claude Code 的配置分好几个层级很多人搞混就是因为没理清优先级。简单说配置从低到高大致是全局默认 → 用户级 settings.json → 项目级 settings.json → 环境变量 → 命令行参数。后面的覆盖前面的。用户级的 settings.json 一般在你的用户目录下项目级的则放在项目根目录的.claude文件夹里。我的建议是通用偏好放用户级项目特有的放项目级。比如你所有项目都想用某个默认模型那就写用户级但某个项目因为技术栈特殊需要指定不同模型就写项目级。一个典型的 settings.json 结构长这样{ model: claude-sonnet-4-20250514, env: { ANTHROPIC_MODEL: claude-sonnet-4-20250514, CLAUDE_CODE_MAX_CONTEXT_TOKENS: 200000 } }注意这里model字段和ANTHROPIC_MODEL环境变量都能指定模型但它们的生效场景不太一样。model是 Claude Code 自己的配置项而ANTHROPIC_MODEL是更底层的环境变量在某些调用路径下会覆盖前者。我实测下来两个都写上、保持一致是最稳妥的做法避免出现我明明改了配置怎么没生效的情况。2.2 ANTHROPIC_MODEL 的选型逻辑ANTHROPIC_MODEL这个变量决定了默认走哪个模型。它的值可以是官方模型名也可以指向你自建的兼容服务。这里就是省钱的第一道关口。我的分层策略是这样的任务类型推荐模型档位理由架构设计、复杂重构最强模型需要深度推理省这点钱不值得日常编码、改 bug中档模型性价比最高大部分活都能干写注释、格式化、解释报错本地模型完全够用零边际成本批量文本处理本地模型量大用贵的纯属浪费具体到配置如果你有本地模型服务可以把它配成一个额外的 provider然后在需要的时候切换。比如本地跑着 Ollama暴露了兼容接口那ANTHROPIC_MODEL就可以指向那个本地模型名。这里要提醒一句不是所有任务都适合下放到本地模型。我试过让本地的小模型去改一个涉及多文件依赖的重构结果它改出来的代码看着像那么回事实际跑起来一堆问题最后返工的时间比直接用强模型还长。所以分流的判断标准是任务是否需要跨文件的全局理解。需要就用强模型只是局部操作本地模型足够。2.3 CLAUDE_CODE_MAX_CONTEXT_TOKENS 的省钱玄机这个变量是很多人忽略的省钱利器。它的作用是限制单次请求能用的最大上下文 token 数。为什么限制上下文能省钱因为 token 计费是按实际用量算的。如果你不限制Claude Code 可能会把一大堆相关文件全塞进上下文其中很多是当前任务根本用不到的。限制之后它会更克制地选择要读的内容。但这里有个平衡点。设得太小模型看不到足够信息回答质量下降你还得反复追问反而更费。设得太大又回到了烧钱的老路。我的经验值是日常任务设 100000 到 150000 之间。这个范围足够覆盖大多数单文件或少量文件的修改任务又不会让模型无节制地吞文件。遇到确实需要大上下文的任务比如理解一个大型模块的整体结构再临时调高。{ env: { CLAUDE_CODE_MAX_CONTEXT_TOKENS: 120000 } }实测下来把默认的上下文限制从满额降到 12 万日常任务的成本能降三成左右而输出质量我几乎感觉不到差别。原因很简单大部分编码任务真正需要的信息量远没有模型默认塞进去的那么多。2.4 配置优先级与覆盖关系再强调一遍优先级因为这个搞错了会浪费大量调试时间命令行参数最高环境变量项目级 settings.json用户级 settings.json内置默认值最低我踩过的坑是在项目级 settings.json 里改了模型但环境变量里还留着旧的ANTHROPIC_MODEL结果怎么改都不生效。后来才反应过来是环境变量优先级更高。所以改配置之前先检查一下当前 shell 里有没有残留的环境变量用env | grep ANTHROPIC看一眼能省很多事。3. 分层路由的实操配置3.1 本地模型服务的接入准备先说本地模型这条线。我用的方案是在本机跑一个兼容接口的模型服务然后在 Claude Code 里把它配成一个可切换的选项。这样简单任务走本地复杂任务走云端两边互不干扰。接入之前要确认几件事本地服务已经跑起来并且暴露了兼容的 API 端点记下端点地址和端口确认本地模型的上下文窗口大小别配了个超出它能力的值配置的时候核心是把服务地址和模型名填对。不同工具的配置字段名可能略有差异但逻辑是一样的告诉 Claude Code 有一个额外的模型提供方地址在这模型名叫这个。注意本地模型的上下文窗口通常比云端小很多。如果你把CLAUDE_CODE_MAX_CONTEXT_TOKENS设得比本地模型实际支持的上限还大请求会直接失败。配之前先查清楚本地模型的真实上限。3.2 按任务类型切换模型的实操配置好之后怎么在实际使用中切换有两种方式。第一种是改配置切换适合你一段时间内集中做某类任务。比如今天主要写样板代码那就把默认模型设成本地的一整天都省。明天要做架构设计再改回强模型。第二种是会话内临时切换适合任务类型频繁变化的情况。Claude Code 支持在会话里指定模型不用改配置文件。这个更灵活但需要你养成接任务前先想一下该用哪个模型的习惯。我自己的习惯是开一个新会话之前先花三秒钟判断这个任务的性质。如果是帮我看看这段代码为什么报错直接本地模型如果是帮我设计这个模块的接口切强模型。这个判断成本极低但积累下来省的钱很可观。3.3 上下文窗口的动态调整CLAUDE_CODE_MAX_CONTEXT_TOKENS不一定非要写死在配置里。你可以根据任务动态调整。我的做法是准备两套配置一套省电模式上下文限制设得比较紧模型用中档或本地一套火力全开模式上下文放开模型用最强。平时用省电模式遇到硬骨头再切火力全开。具体怎么切如果 Claude Code 支持 profile 或者多配置文件就配两套如果不支持就手动改。手动改虽然麻烦点但也就几秒钟的事比一直用满配烧钱划算多了。这里有个细节上下文限制调低之后如果任务确实需要更多信息模型会主动告诉你信息不足。这时候你再临时调高比一开始就放开要省。因为大部分任务其实不需要那么多上下文只有少数任务会触发信息不足的提示。3.4 一个完整的配置示例把上面的东西整合起来我的用户级 settings.json 大概长这样{ model: claude-sonnet-4-20250514, env: { ANTHROPIC_MODEL: claude-sonnet-4-20250514, CLAUDE_CODE_MAX_CONTEXT_TOKENS: 120000 } }项目级的则根据项目特点调整。比如一个纯前端项目任务大多是组件编写和样式调整我会把模型降一档上下文也收紧{ env: { ANTHROPIC_MODEL: claude-haiku-3-5-20241022, CLAUDE_CODE_MAX_CONTEXT_TOKENS: 80000 } }而一个涉及复杂业务逻辑的后端项目我会保持强模型但上下文依然控制在合理范围{ env: { ANTHROPIC_MODEL: claude-sonnet-4-20250514, CLAUDE_CODE_MAX_CONTEXT_TOKENS: 150000 } }这套组合用下来我的月支出比全默认配置降了大概六成而实际开发效率没有明显下降。关键就在于把聪明用在刀刃上。4. 常见问题与排查实录4.1 配置改了不生效怎么办这是最高频的问题。排查顺序如下先看环境变量env | grep -i anthropic有没有残留的旧值再看项目级 settings.json是不是覆盖了用户级检查 JSON 语法一个多余的逗号就能让整个配置失效确认 Claude Code 版本老版本可能不支持某些字段我遇到过一次配置文件语法完全正确但就是不生效。折腾半天发现是 shell 的启动脚本里 export 了一个旧的ANTHROPIC_MODEL每次开终端都会覆盖。所以排查配置问题永远从环境变量开始。4.2 本地模型响应慢或超时本地模型受硬件限制响应速度肯定不如云端。如果慢到影响使用有几个方向可以调换更小的模型牺牲一点质量换速度降低上下文限制减少模型要处理的信息量检查本地服务是不是被其他进程抢了资源我的经验是本地模型适合短平快的任务一旦任务变复杂等待时间会急剧上升。所以本地模型的使用边界要卡死只做局部、简单的操作稍微复杂一点就切回云端。4.3 上下文限制设太低导致回答质量下降这个问题的表现是模型频繁说我需要更多信息或者给出的答案明显没考虑周全。这时候别急着骂模型笨先看看是不是上下文限制卡太紧了。解决办法是按任务类型设不同的限制。简单任务用紧的复杂任务用松的。不要指望一个值打天下。4.4 模型切换后行为不一致不同模型的性格确实不一样。强模型可能更倾向于给你完整方案本地小模型可能更倾向于给个大概方向。切换之后如果感觉别扭不是你配错了是模型本身差异。应对方法是给不同模型配不同的提示词习惯。比如用本地模型时把需求描述得更具体、更局部用强模型时可以更放手让它发挥。4.5 常见问题速查表现象可能原因排查动作配置不生效环境变量覆盖env请求失败上下文超本地模型上限查本地模型规格调低限制响应慢本地硬件不足换小模型或减少上下文回答质量差上下文限制过紧临时调高限制重试模型行为突变切换了模型档位确认当前生效的模型名5. 我踩过的坑和几条硬核经验5.1 别迷信最强模型解决一切刚开始我也觉得既然要质量那就全程用最强的。结果一个月下来账单吓人而且回头一看大量请求都是帮我改个变量名这段报错什么意思这种根本不需要顶级推理的活。把简单任务下放是省钱的第一原则。5.2 上下文不是越多越好很多人有个误区觉得给模型的信息越多它答得越好。实际上信息过载反而会干扰模型判断让它抓不住重点。精准的上下文比海量的上下文更有价值。限制上下文不只是省钱有时候还能提升回答质量。5.3 配置要版本化你的 settings.json 值得放进版本控制。因为一套调好的配置是经验结晶换台机器、换个项目重新调很浪费时间。我现在把用户级配置单独存一份新环境直接拷过去省事。5.4 定期复盘用量Claude Code 一般会提供用量统计。我习惯每周看一眼看看哪些任务花了大钱。经常能发现一些没想到这么费的操作然后针对性优化。比如某次发现让它读整个目录特别费后来改成只读相关文件成本立降。5.5 本地模型和云端模型要分工明确最忌讳的是边界模糊。我的做法是写死规则涉及跨文件理解、架构决策、疑难排查的一律云端强模型单文件内的局部修改、格式化、解释一律本地。规则清晰之后不用每次纠结直接按规则走。这套配置我用了几个月最大的感受是省钱和聪明不矛盾矛盾的是一刀切。把任务分层把资源匹配到合适的任务上两边都能兼顾。你不需要成为配置专家只需要理解什么任务配什么脑子这一个核心逻辑剩下的照着抄就行。