每天跟 Claude Code 打交道最烦的事情不是代码写不出来而是换 API 供应商的时候要亲手去改那一堆配置。今天想用官方 Anthropic 跑一下复杂任务明天想切到 DeepSeek 降低成本后天又想试一下 Ollama 本地模型保证数据不出机器——改 base_url、改 token、改模型名称这一套操作我闭着眼都能背出来但每次还是会担心改错。后来在 GitHub 上发现了 cc-switch 这个工具它解决的正是 Claude Code 配置切换这个烦心事。用了一个多月切换配置从过去两分钟的体力活变成了一秒钟的顺滑操作再也不用手抖着改 JSON 了。这篇就把我的实际配置过程和踩过的坑完整写出来给同样被配置文件折磨的朋友一个参考。1. 为什么需要 cc-switch手动切换 Claude Code 配置有多折腾1.1 Claude Code 的配置文件到底长什么样Claude Code 是基于终端交互的编程助手它启动时通过一系列配置来决定“该把请求发给谁”。官方默认走 Anthropic API但我们这群爱折腾的人通常不会只用一个供应商而是会在官方、第三方中转、本地模型之间反复横跳。这些配置主要放在用户目录下的~/.claude/settings.json文件里。第一次手动配置的时候我看了一眼这个文件当时就意识到这里面的坑比想象中多。核心配置大概长这样{ env: { ANTHROPIC_BASE_URL: https://api.anthropic.com, ANTHROPIC_AUTH_TOKEN: sk-ant-你的官方Key }, model: claude-sonnet-4-20250514, permissions: { allow: [Bash, Read, Edit], deny: [Write] } }说白了Claude Code 就是通过环境变量里的ANTHROPIC_BASE_URL来定位请求地址用ANTHROPIC_AUTH_TOKEN来认证身份用model字段来指定模型版本。很多第三方供应商之所以能被 Claude Code 调用就是因为它们兼容 Anthropic 的 API 协议你只要把ANTHROPIC_BASE_URL改成它们的地址就行。问题在于你不可能同时用两家供应商。官方、DeepSeek、Ollama、各类聚合平台之间是互斥的切到 A 就得把 B 的设置整个覆盖掉。这就让“切换”这件事变成了一个重复且容易出错的操作。1.2 多供应商场景下手动切换有多容易翻车我最早切换配置的方式就是打开 VS Code 直接编辑 settings.json。如果你只切一次这个操作还算能忍毕竟核心就改三个字段。但实际用起来根本不是改三个字段的事。第一坑字段容易记混。有些供应商要求把模型名称写成deepseek/deepseek-chat这种带前缀的格式有些又要求只写模型名不带前缀有些要求设置ANTHROPIC_MODEL这个环境变量有些则只认顶层model字段。这些差异没有任何文档会主动告诉你全靠试错。第二坑JSON 格式特别容易出错。手改 JSON 时少写一个逗号、括号没闭合Claude Code 启动时会直接报配置解析失败。有一次我赶着提交代码改配置的时候把ANTHROPIC_AUTH_TOKEN的值末尾多留了一个空格结果 API 一直返回 401我排查了快二十分钟才发现是空格的问题。第三坑配置改乱了很难还原。settings.json 里除了 env 和 model还有 permissions、hooks、statusLine 这些自定义项。切换供应商时如果只改 env 不动其他配置还好但只要有一次误删了某个权限块后面每次启动 Claude Code 都会问你“是否允许执行 Bash”那体验简直让人崩溃。所以我对这种工具的需求就很明确我要把我常用的供应商配置都保存成模板平时切换只点一下它帮我写文件、帮我保证 JSON 合法、帮我保持所有自定义配置不被破坏。cc-switch 恰好就是按这个思路做的。2. cc-switch 的工作原理与安装方式2.1 核心机制把配置管理变成“配置模板”cc-switch 这个名字取得很直白就是一个“Claude Code 配置切换器”。它做的事情本质上非常朴素帮你把不同的 API 供应商配置分门别类地存好每份配置就是一个“Profile模板”你想用哪个供应商就在界面里点一下它自动把该模板的内容写入 Claude Code 的配置文件。打个比方它就像是你手机里的输入法皮肤管理器。每种供应商配置是一种皮肤你切换输入法皮肤不会影响按键功能cc-switch 切换供应商配置也一样不会动你原有的权限设置和自定义 hooks。不过在理解它的价值之前有一点需要先说清楚cc-switch 不会帮你封装 API。它不代理请求不缓存 token也不管你的流量走哪条线路。它的职责就是替你把这行配置改对ANTHROPIC_BASE_URL: https://api.anthropic.com把它从官方地址改成https://api.deepseek.com/anthropic或者改成http://localhost:11434。2.2 为什么不用 Shell 脚本替代可能有朋友会说这种操作我写个 shell 脚本不就行了我也想过这个方案实测发现脚本方案有几个不好处理的地方。脚本确实能做到“把配置写进文件”但它很难帮你做“模板管理”。你写一个脚本它只能切两个固定供应商你要加第三个供应商就得改脚本要加第四个还得改。而且脚本执行的时候很容易出岔子如果你没写备份逻辑切换前忘了把当前配置存下来切完之后想回退到原来的供应商就傻眼了。cc-switch 这种 GUI 工具的天然优势是状态可见。哪个供应商是当前生效的一目了然每个模板的配置内容是什么可以随时查看编辑需要新增供应商时界面里点一下“新增配置”就能填不用碰代码。还有一点是它的多端管理能力。Claude Code 只是其中一个工具cc-switch 还可以管理 Codex 等其他终端编程工具的配置。这等于是在“多个 AI 编程工具”和“多个 API 供应商”之间做了一个统一控制台比单独写脚本强太多了。2.3 安装过程与版本选择cc-switch 的安装方式有两种主流路线命令行工具和桌面客户端。桌面客户端是我目前在用的方式适合大多数不太想在终端里折腾的人。直接从 GitHub Releases 页面下载对应系统的安装包macOS 下 dmg 拖进 Applications 文件夹就行。需要说明的是macOS 首次打开如果提示“已损坏”是因为没有给执行权限到“系统设置 - 隐私与安全性”里允许一下就行不是软件本身的问题。如果你喜欢命令行方式也可以用 npm 全局安装。但这里有一个需要注意的点npm 安装的是核心命令行版本功能完整但需要手动管理配置文件的路径。我第一次就是先装的命令行版后来发现 GUI 版本对模板的展示更直观就换到了桌面客户端。我的建议是不习惯看终端界面的直接用桌面版喜欢命令行效率的用 npm 版两者核心配置文件可以互通。安装完之后启动应用主界面会列出可管理的工具选择 Claude Code就会进入配置模板列表页。到这里cc-switch 的本体安装就算完成了。3. 实战用 cc-switch 管理多套供应商配置3.1 添加官方 Anthropic 配置模板安装好 cc-switch 之后第一件事是把官方配置存成一个模板作为默认基准。这一步很重要因为官方配置是你切换其他供应商之后需要回退的“安全网”。在主界面的“Claude Code”区块点击“新增配置”会看到两个核心输入框供应商名称和配置内容。供应商名称随意填我习惯填“Anthropic-Official”方便一眼认出来。配置内容这里有一个设计上的细节需要了解cc-switch 默认会以 JSON 格式保存并写入~/.claude/settings.json所以你填的内容本质上是一份 JSON。官方配置我填的是{ env: { ANTHROPIC_BASE_URL: https://api.anthropic.com, ANTHROPIC_AUTH_TOKEN: sk-ant-api03-你的密钥 }, model: claude-sonnet-4-20250514 }不同版本的 Claude Code 对模型名称的支持有细微差异新版本可能还支持更长的上下文和更强的推理模型但配置字段本身是稳定的。填完点击保存cc-switch 会把这条记录存进自己的状态文件里并在切换时写入 settings.json。这里我特意强调“状态文件”是因为有朋友问过cc-switch 会不会偷偷改我原有的配置实际不会。你不主动点“切换”它不会碰任何文件。3.2 添加 DeepSeek 兼容配置如果你关注中文圈子的 AI 编程工具大概率听过 DeepSeek 这个方案。DeepSeek 开放了 Anthropic 兼容接口意味着 Claude Code 可以直接接上 DeepSeek 的 API成本比官方低很多做日常开发甚至体验还挺好。在 cc-switch 里新增配置我命名为“DeepSeek-CN”。这里最关键的是ANTHROPIC_BASE_URL要填对{ env: { ANTHROPIC_BASE_URL: https://api.deepseek.com/anthropic, ANTHROPIC_AUTH_TOKEN: sk-你的DeepSeek密钥 }, model: deepseek-chat }这个model字段是很容易踩坑的地方。如果你填deepseek-chat走的是 DeepSeek-V3 系列如果你填deepseek-reasoner走的是 R1 推理模型。Claude Code 在处理代码任务时推理模型往往更适合复杂重构但如果只是简单的补全和问答普通模式响应更快。建议两个模型都分别建一个配置模板这样切起来连模型名都不用改。另外一个容易被忽略的点是DeepSeek 部分新模型直接在 Anthropic 兼容接口下要用ANTHROPIC_MODEL环境变量来设置。如果你在 cc-switch 的模板里只改了基础 URL但模型名不对Claude Code 会报 model not found。遇到这个情况就在 env 里加上一行ANTHROPIC_MODEL: deepseek-chat3.3 添加 Ollama 本地模型配置本地大模型是很多人关注 cc-switch 的另一个原因。用 Ollama 跑本地模型的好处很明显完全离线、数据不出本机、没有 API 费用。虽然大模型的智力水平相比云端顶级模型还有差距但对于一些敏感项目或者网络不稳定的环境本地模型是唯一靠谱的选择。Ollama 本身在本地启动后默认监听11434端口并且它提供了一个v1接口兼容 OpenAI 协议同时也提供了 Anthropic 兼容方式。在 cc-switch 里新增配置命名为“Ollama-Local”{ env: { ANTHROPIC_BASE_URL: http://localhost:11434, ANTHROPIC_AUTH_TOKEN: ollama }, model: qwen2.5-coder:32b }这里有个细节Ollama 的鉴权字段其实并不校验 token 内容但 Claude Code 要求 base URL 对应一个非空的 auth token所以随便填一个ollama占位就行。如果你不填Claude Code 启动时会报缺认证信息直接连不上。model字段要填你本地已经拉取下来的模型名称用ollama list可以查看。如果你还没拉模型先用命令ollama pull qwen2.5-coder:32b拉一个再填对应的模型名。有一些人喜欢用qwen2.5-coder:14b参数少一些对内存的占用也低但代码能力会打折。我自己的主力机器是 M 系列芯片 32GB 内存跑 32b 量化模型勉强能撑住如果你内存只有 16GB建议先用 14b 或 7b 的模型试试水。3.4 一键切换的完整流程配置模板建好之后切换就变成了一件特别无脑的事情。打开 cc-switch 主界面看到列出的模板列表官方、DeepSeek、Ollama全都整整齐齐地排在那里。想用哪个点一下对应的“切换”按钮界面上会出现一个选中标记。这时背后发生了什么cc-switch 会把你选中的那份模板内容解析成 JSON然后整体写入~/.claude/settings.json。写入前它会做一次 JSON 校验如果模板本身有语法问题它会直接提示错误而不是带着错误去覆盖配置文件。切换完成后再打开一个新的 Claude Code 会话旧会话一般不会自动读到新配置需要重启才生效输入一个简单问题测试比如“你能正常工作吗”。如果返回正常说明这次切换是成功的如果报了认证错误回到模板列表检查 token 是否填对。用熟悉之后我的切换频率变成了“一天切好几次”的状态上午和项目组讨论架构用官方模型追求最高质量下午写常规的业务 CRUD切到 DeepSeek 省点成本下班前做代码审查如果网络环境不太稳定直接切到 Ollama 本地跑。整个过程从过去的两分钟变成了五秒钟这背后省下的不只是时间还有打断心流状态的成本。4. 多 API 供应商场景下的配置策略4.1 日常开发如何搭配使用官方与第三方从我实际使用的体感来说官方 Anthropic 的模型在代码理解和重构上的表现依然是最稳的但价格也确实是最高的。第三方兼容服务比如 DeepSeek在普通代码补全、测试用例生成这类高频操作上体验已经非常接近官方而成本却低一个量级。如果你和我一样是个人开发者我建议这样搭配把官方配置作为“高配档”把 DeepSeek 作为“经济档”。日常写代码、快速验证想法直接经济档遇到特别复杂的架构设计、大面积重构时切到高配档跑一轮。以前这种切换方式几乎不可能因为每一次切换都要去改文件人是有惰性的一旦切过去麻烦就宁可硬着头皮用当前的配置。现在切换成本降下来了选择反而变得更加理性。4.2 本地模型在断网场景下的兜底价值我自己遇到过不止一次在外出差时网络状况极差的情况。公共 Wi-Fi 不稳定云端 API 时不时超时那时候本地模型的价值就体现出来了。只要机器上装了 Ollama 并且拉好了模型不管网络通不通都能继续用 Claude Code 干一些结构化的编码任务。不过本地模型的写代码能力确实和云端模型存在代差。我的经验是本地模型适合做格式整理、简单脚本生成、正则编写、代码注释补全这类结构明确的任务让本地模型去理解一个复杂的业务系统设计结果往往不太靠谱。所以使用本地模型时我会把任务拆得更小、问得更细避免一次性让它处理太多上下文。cc-switch 在本地模型与云端模型之间切换没有任何额外负担这一点很重要。有时候我早上在办公室用的是云端模型下午带着电脑去没网的会议室切到 Ollama 就能无缝继续工作这个体验在以前手动改配置的时候是根本不可能有的。4.3 多项目场景下模板命名的技巧如果你的项目不止一个模板命名的思路可以更灵活。比如我除了按供应商命名还会按项目场景命名有一个项目专门用官方 Claude 做系统架构有一个项目因为客户要求所有数据不能出境专门配了 Ollama 本地模板。在这些模板里除了 env 和 model还可以携带 permissions 配置。比如某个项目我明确不允许 Claude Code 自动改文件就在模板里设置permissions: {defaultMode: plan}这样切换到该模板时自动进入只读规划模式避免误操作。cc-switch 本身并不限制你填什么只要 JSON 合法它都会忠实地帮你写入。这个小技巧的核心价值是模板不只是“API 供应商的切换”更是“使用场景的切换”。同一套 Claude Code在不同的项目里应该有不同的模型选择、权限策略、甚至 hooks 配置。用 cc-switch 统一管理之后项目之间的切换就像换了一套工作环境。5. 使用 cc-switch 的常见问题与避坑指南5.1 切换之后配置不生效这是我被问得最多的一个问题也是我自己一开始就踩过的坑。在 cc-switch 里点了切换再看设置文件内容确实变了但 Claude Code 里还是旧的供应商。原因通常是两个第一个是 Claude Code 已经在运行而你直接在这个会话里继续提问。Claude Code 的配置加载发生在启动阶段运行时改配置不会热加载。所以每次切换完一定要退出当前会话重新进入一次。第二个原因是某些环境变量覆盖问题。比如你在.zshrc或.bashrc里已经 export 了ANTHROPIC_BASE_URL这个环境变量的优先级高于 settings.json 里的 envClaude Code 启动时会优先读环境变量导致模板配置“看起来没生效”。排查方法是在终端里跑env | grep ANTHROPIC如果发现有输出说明环境里已有残留配置去 shell 配置里清理掉再试。5.2 切换后 Codex 历史对话打不开这个问题在 cc-switch 用户群里讨论得比较多使用 cc-switch 切换供应商时如果它也帮你管理 Codex 配置它会同步改写~/.codex/config.toml。如果你之前的 Codex 会话是用某个特定的model_provider启动的切换后原来的 provider 名称变得不可用历史对话就会尝试用新配置去拉取结果拉不到对应的 provider直接报错。具体报错信息大致是config.toml: model provider custom not found这类。如果你遇到这个问题不要慌。解决办法是去~/.codex/config.toml里检查model_provider字段。你要做两件事第一确认当前配置里写的 provider 名称跟历史会话创建时用的名称一致第二如果你用了 cc-switch 的 Codex 管理功能但平时不怎么用建议在 cc-switch 里取消对 Codex 的托管只让它管理 Claude Code。这样 cc-switch 每次切换时就不会再去动 Codex 的配置历史会话自然就不会被破坏。这类问题属于工具联动的副作用不算 cc-switch 的致命 bug但确实需要使用者心里有数。我的习惯是Claude Code 的配置交给 cc-switch 管Codex 的配置还是手动改各管各的互不干扰。5.3 Ollama 模板切换之后模型不工作Ollama 配置成功但切换后 Claude Code 仍然报错这个问题我也遇到过。有一次我填了model: qwen2.5-coder:32b切换后 Claude Code 能连接上但一调用就报错。后来排查发现Ollama 的 API 对模型名的大小写、后缀很敏感qwen2.5-coder:32b和qwen2.5-coder:32b-instruct-q4_K_M是完全不同的两个名字。所以如果你在 Ollama 里拉模型时用了带参数的文件名切换模板里的模型名必须一字不差地对应上。用ollama list看实际名字把看到的完整 name 填到模板里而不是凭印象填写。另一个可能性是 Ollama 服务没有启动。cc-switch 只管写配置文件不会帮你拉起 Ollama 进程。切换之前先确认ollama serve在跑或者在终端里执行curl http://localhost:11434/api/tags能返回模型列表才说明本地服务正常。5.4 权限配置被覆盖的问题cc-switch 的设计逻辑是每次切换都会把模板内容整体写入 settings.json也就是说如果你的模板里没写 permissions切换后 permissions 配置就会被清掉回到 Claude Code 出厂默认值。这对我来说是一个需要适应的点。最开始我建模板时只关注 env 和 model切了几次之后发现Claude Code 每次执行命令都要弹窗问我权限就是因为模板里没有带 permissions。解决思路很简单在 cc-switch 里维护一套“标准权限配置”建模板时直接复用。我常用的权限块是这样的permissions: { allow: [Bash(npm run lint), Read, Edit], deny: [], defaultMode: acceptEdits }你可以根据自己的工作流调整 allow 列表。关键是每个模板都要带上和当前工作方式匹配的权限块否则切换供应商会连带着把操作习惯也切成默认状态。6. 一些关于工作流的额外建议使用 cc-switch 一个月之后我最大的感受是工具解决的不只是“改配置”这个动作本身更是解除了我心理上的“切换成本”。以前我不想切换供应商不是懒得动手而是害怕改完配置之后出现各种不可预期的问题。改坏了怎么办、回退怎么退、模型名记不住这些问题叠加在一起导致我哪怕知道某个场景适合用另一个模型也会放弃切换。cc-switch 把切换变成了类似遥控器换台的动作点一下就行出问题的概率大幅降低这才是它对我来说最大的价值。最后再分享一个我个人特别受用的组合拳cc-switch 加 Ollama 再加一个模型管理脚本。我用一个简单的快捷指令在当前项目目录下快速启动 Claude Code同时自动把 cc-switch 切到本地模型模板这样每次进入非敏感环境开发时默认就走在本地模型上不用反复思考该用哪个配置。我个人在实际操作中的体会是配置管理这种看起来不起眼的小事反而最能影响日常开发的幸福感。把重复劳动交给工具把精力留给真正重要的编码工作这件事永远值得投入时间去做。如果你现在还在手动改 Claude Code 配置不妨试一下 cc-switch顺手花十分钟把常用的几个供应商模板建好之后的体验完全不一样。