开始之前先问一句你是不是也经历过这种场面——手里的 Claude Code 项目昨天还在用一个模型服务今天想换成另一家结果得翻出配置文件改 apiKey、改 baseURL、改 model 名改完还要小心翼翼检查是不是漏了逗号再惨一点如果你同时维护两三个项目每个项目的自定义指令还不一样那一套手动操作下来光是想心情就累了。所以说“别再手改配置了”真不是矫情。这个项目标题里的 CC Switch解决的就是这个痛点。它本质上是一个 Claude Code 的配置切换管理工具让你把不同的模型服务、不同的密钥、不同的项目指令全部做成配置模板然后在需要的时候一条命令切过去。简单说它就是给 Claude Code 装了一个“多配置文件遥控器”。这篇博文我会从实际使用的角度把这个工具的定位、核心设计思路、完整实操流程、以及我在真实项目中折腾出来的经验一次讲完。如果你正在用 Claude Code或者打算尝试把它接入自定义模型这篇内容应该能帮你少走不少弯路。1. 项目背景与痛点拆解1.1 手动配置到底痛在哪里先说一个很典型的场景。我手上有两个项目一个是日常业务开发需要快速响应、上下文要精简另一个是做深度的代码审查和架构梳理需要模型更“沉得住气”输出的推理过程要完整。这两个需求用同一个模型配置显然不合适。于是问题就来了每次切换模型服务我都要打开 Claude Code 的配置文件找到 environment 那一堆变量把 ANTHROPIC_BASE_URL 换掉、把 ANTHROPIC_AUTH_TOKEN 换成新密钥、把 model 改成对应型号。更麻烦的是项目里还有自定义指令文件不同项目的 CLAUDE.md 内容也不一样。要是忘了改轻则模型行为不符合预期重则密钥配错直接鉴权失败。这些操作的痛点可以归纳成三个操作繁琐且容易出错配置文件是 JSON 格式一个逗号放错地方整个配置就废了。手动改多了早晚会踩坑。密钥管理混乱配置里直接写死密钥很容易随代码仓库泄漏。而不同服务商的密钥本质上是敏感资产散落在各个配置文件里既不安全也不方便轮换。切换成本高人在不同任务之间切换时如果每次都要花三五分钟改配置心情和状态都会被打断。1.2 CC Switch 能解决什么问题CC Switch 的思路很直接把“配置过程”从“手动编辑文件”变成“选择预设方案”。你可以先为每个使用场景建立一份配置模板模板里包含了模型服务端点、密钥引用、模型名称、以及该场景下需要的 CLAUDE.md 内容。切换场景时只需执行一条命令工具会自动帮你更新 Claude Code 实际读取的配置文件和项目指令文件。这个设计解决了上面三个痛点配置文件不用再手改了工具会生成合法的、结构完整的配置内容。密钥不直接写在配置里而是存到单独的安全存储区模板里只放引用。切换从“改多个文件”变成“跑一条命令”几秒钟搞定。对于同时使用多个模型服务、或者团队里多人共用一套开发环境的场景这个工具的价值会非常明显。它不是给 Claude Code 增加新功能而是把“配置管理”这件原本散乱的事情变成了一套有章法的流程。2. 核心设计思路解析2.1 配置模板化把配置文件当作“可复用资产”CC Switch 的核心抽象是“配置模板”。你可以把一份模板理解成一个完整的、描述“某一种使用方式”的包它通常包含四部分内容组成作用示例端点配置指定模型服务的接入地址ANTHROPIC_BASE_URL鉴权配置指定认证方式与密钥引用ANTHROPIC_AUTH_TOKEN模型参数指定默认模型与相关参数model、max_turns项目指令指定该场景下的自定义指令内容CLAUDE.md这样的设计最大的好处是“配置即代码”。配置模板可以纳入版本管理可以 review可以回溯。你不再需要记住上一次改了哪几个字段只要看模板文件的历史记录就行了。这里说一下我自己的理解模板化本质上是把“隐性的操作知识”显性化。以前你需要知道改哪几个位置、改成什么值这些都是藏在脑子里的经验。而有了模板之后这些经验就沉淀成了文件。哪怕隔了三个月回来或者换个新人接手看一眼模板就明白了。2.2 密钥与配置分离安全性的关键设计很多人在做配置管理时最容易犯的一个错误就是“图省事密钥直接写在模板里”。CC Switch 在设计上刻意避开了这一步。它的做法是模板文件里只保留密钥的“引用标识”例如$SECRET_PROD_ANTHROPIC_KEY。真实的密钥存放在独立的安全存储中比如系统密钥环、~/.ccswitch/secrets.json并使用本地权限锁保护。激活某个模板时工具会把密钥从安全存储中取出动态注入到 Claude Code 可读取的配置中但这个配置里的密钥在非运行状态下会被清理或脱敏。为什么要这么设计因为模板文件通常是会进 Git 仓库的如果你把密钥直接写在模板里等于把密钥放进了版本历史。一旦仓库泄漏所有历史版本里的密钥都会暴露轮换的成本极高。而采用“配置与密钥分离”即使模板公开别人也拿不到你的真实密钥。实际操作中这一点给我带来的好处非常直接我可以放心地把配置模板推到团队仓库里让同事直接 clone 下来用而密钥只需要各自在自己的机器上执行一次导入命令即可。2.3 环境变量注入与生效机制Claude Code 读取配置时主要依赖当前 Shell 环境中的环境变量和特定目录下的配置文件。CC Switch 的干预方式就是把两件事做好写环境变量文件生成一个只包含当前激活模板所需变量的文件并让 Claude Code 启动时自动加载。更新配置文件把激活模板中的参数同步写入 Claude Code 实际读取的配置同时处理好和已有配置的合并逻辑。这里有一个容易踩坑的点Claude Code 的配置优先级环境变量通常高于配置文件。所以如果你既设置了环境变量又在配置文件里写入了相同的键实际生效的是环境变量。CC Switch 在激活模板时会统一写入环境变量和配置文件两处并且保证它们一致不会出现“配置文件和环境变量打架”的情况。在你手动操作时这种细节最容易被忽略。你可能兴高采烈地改完了配置文件发现程序根本不吃这一套花很久排查才发现原来是某个环境变量在作怪。CC Switch 把这种一致性作为工具的默认行为省去了这类心智负担。3. 从零到一安装与初始化实操3.1 安装方式CC Switch 的安装并不复杂。如果你是 Node 生态的常用者可以直接通过 npm 或 bun 这类包管理器全局安装如果你更习惯使用单文件二进制也可以从仓库的发布页直接下载对应平台的二进制文件。以 npm 安装为例npm install -g cc-switch安装完成后执行cc-switch --version确认安装是否成功。如果输出正常说明工具已经进入你的 PATH。这里有一点建议如果你在团队里推广这个工具最好把安装命令写进团队的开发者文档里免得每个人各装各的、版本不一。版本不一致带来的配置格式兼容问题真的会让人头大。3.2 初始化项目目录安装好后第一步是初始化 CC Switch 的配置目录。执行cc-switch init这个命令会在你的用户目录下创建一个.ccswitch文件夹里面包含三个子目录~/.ccswitch/ ├── profiles/ # 存放所有配置模板 ├── secrets/ # 存放加密后的密钥信息 └── active/ # 存放当前激活状态的链接与记录初始化完成后可以用cc-switch status查看当前状态。这个时候它一般会提示你还没有激活任何模板。为什么需要单独的 active 目录因为切换配置本质上是“引用关系的变化”工具通过这个目录记录当前哪个模板被激活避免在多个配置文件中留下大量半脏不脏的痕迹。3.3 创建第一个配置模板创建一个模板命令很简单cc-switch profile create daily这条命令会在 profiles 目录下生成一个名为daily的模板为了让你后续能直接编辑它还会在~/.ccswitch/profiles/daily/下生成以下文件config.json存放端点、模型名等基础配置。CLAUDE.md存放该场景的项目指令。secrets.required声明这个模板需要哪些密钥引用。初始的config.json大概是这个样子{ name: daily, environment: { ANTHROPIC_BASE_URL: $SECRET_DAILY_BASE_URL, ANTHROPIC_AUTH_TOKEN: $SECRET_DAILY_API_KEY }, model: deepseek-chat, settings: { includeCoT: false } }注意看这里环境变量的值写的是$SECRET_DAILY_BASE_URL和$SECRET_DAILY_API_KEY这就是前面提到的“密钥引用”。真正要填的密钥存在 secrets 里稍后我会讲。创建模板之后你还需要编辑CLAUDE.md把在这个场景下希望 Claude Code 遵循的指令写进去。比如# 日常开发指令 - 优先输出简洁有效的代码避免过度设计。 - 涉及修改时先简要说明改动思路再给出完整代码。 - 回答尽量使用中文。这样一个最小可用的配置模板就建好了。4. 核心实操把自定义模型接进 Claude Code4.1 准备接入参数在写模板之前你手头需要准备好接入某个模型服务需要的基础参数。一般就三样接入地址Base URL、模型名称、以及鉴权密钥。以接入一个兼容 Anthropic API 协议的模型服务为例你大概需要拿到如下信息Base URL: https://your-model-endpoint.example.com/v1 Model Name: your-model-name API Key: sk-xxx这里要说明一下不同的服务商给出的接入信息格式可能不太一样有些提供的是完整的 Base URL有些则是需要拼接路径的。我的建议是在动手配置之前先去对应服务商的文档里确认一下接口兼容性以及正确的路径格式免得在配置步骤里反复试错。4.2 导入密钥到安全存储先别急着编辑模板我们应该把密钥导入 CC Switch 的安全存储cc-switch secret set daily_base_url https://your-model-endpoint.example.com/v1 cc-switch secret set daily_api_key sk-xxx设置完成后可以执行cc-switch secret list查看已存在的密钥引用名。你会发现密钥列表里只是告诉你“哪些引用名已存在”而不会把真实值打印出来。这一点在录屏演示或者团队分享时特别有用不会出现“密钥当场社死”的尴尬。需要注意的是secret 一旦设置它就成了你本机上的私有资产。如果你换了电脑需要在新机器上重新导入而配置模板文件可以直接复用。这也再次体现了“配置与密钥分离”的优势。4.3 编写并激活自定义模型配置模板现在我们把config.json里的密钥引用替换成刚设置好的真实引用。比如{ name: daily, environment: { ANTHROPIC_BASE_URL: $SECRET_DAILY_BASE_URL, ANTHROPIC_AUTH_TOKEN: $SECRET_DAILY_API_KEY }, model: your-model-name, settings: { includeCoT: false } }然后执行激活命令cc-switch use daily这条命令会做这么几件事读取daily模板的配置。从安全存储中取出对应的真实密钥值。生成 Claude Code 可识别的环境变量文件与配置文件。将CLAUDE.md复制到当前项目的指令目录或建立软链接。激活成功后执行cc-switch status你应该能看到类似这样的输出当前激活模板: daily 模型: your-model-name 端点: https://your-model-endpoint.example.com/v1 (已启用) 指令文件: 已链接4.4 验证模型是否真的生效配置完毕后在项目目录下运行claude命令随便问一句“你是通过哪个模型端点运行的”如果一切正常Claude Code 会按照新指令文件的要求回答并且你可以通过它返回时的响应特征间接判断接入是否成功。更稳妥的验证方式是查看 Claude Code 启动时的日志。如果你用的是 debug 模式通常会在日志里看到当前加载的 Base URL 和模型名。比如claude --debug看日志里打印的api_base、model字段是否与你的预期一致。这一步看似简单但能过滤掉九成以上的“以为自己接好了结果没生效”的情况。我个人在实际操作中还习惯在验证阶段找一个该模型服务特有的接口能力来测试。比如如果这个模型服务支持特殊的 reasoning 能力我会故意问一个需要推理的问题看返回内容是否包含对应的思考标记。这一招能帮你快速确认“模型真的通了不只是环境变量通了”。5. 实战场景多项目多模型的无缝切换5.1 场景 A日常开发与深度分析切换回到开头那个两个项目的例子。我为它们分别建了两个模板daily和reviewer。daily模板模型选速度快的轻量模型includeCoT关闭CLAUDE.md 里要求输出精简。reviewer模板模型选推理能力更强的模型includeCoT打开CLAUDE.md 里要求逐步分析、输出完整理由。平时在业务项目里写代码时执行cc-switch use daily。等到晚上要做代码审查、梳理架构时切到项目目录执行cc-switch use reviewer整个会话就被带到“深度模式”。这个过程不需要重启电脑也不需要手动去翻配置文件基本一两秒就能完成。切换之后我通常会把当前 Claude Code 会话关掉重新开一个。原因很简单Claude Code 在启动时读取环境和配置已经打开的会话里可能还缓存着旧的配置状态。这里分享一个我自己摸索出来的小习惯在切换模板之前先用cc-switch use daily --dry-run看一遍将要写入的配置预览确认模型名、端点这些关键信息是对的然后再真正执行切换。预览模式在关键操作前能帮你兜底。5.2 场景 B团队共享配置模板团队协作时CC Switch 的模板共享功能会特别顺手。做法是把~/.ccswitch/profiles/下的模板文件不含 secrets 目录提交到一个团队仓库然后在团队文档里写明安装和导入密钥的步骤。新同事加入后只需三步npm install -g cc-switch cc-switch init git clone 团队配置仓库 ~/.ccswitch/profiles cc-switch secret set prod_base_url 生产环境地址 cc-switch secret set prod_api_key 自己的访问密钥 cc-switch use prod这个流程把“新环境配置”从小时级压缩到分钟级。而且由于密钥是各人各设就算某个同事的密钥泄漏了也只需要轮换他一个人的不影响团队其他人。团队场景下还有一个容易被忽略的点模板里最好使用相对稳定的模型名称不要频繁更换。因为模板一旦被共享改模型名会影响所有使用该模板的人。如果确实要升级模型建议先在个人模板里验证再合并到共享模板。5.3 场景 C版本回滚与审计配置管理还有一个隐藏价值追溯历史状态。CC Switch 的模板本质上就是普通文件你可以用 Git 或者其他版本工具管理它们。某次切换后模型表现不如预期你想回到上一版配置这时候直接git checkout旧版的模板文件然后重新cc-switch use即可。如果还想做更精细的审计可以在模板的config.json里加一个自定义字段比如{ name: prod, meta: { owner: backend-team, since: 2025-03-10, reason: 迁移到新版模型以便支持更长上下文 } }这种元信息字段是允许被保留的CC Switch 不会去重写模板。这给后续维护提供了“为什么这么配”的线索。我自己一般会在每次模板变更时顺手更新meta.reason等过几个月再回头看会省下很多脑力。6. 常见问题与排查心得6.1 激活成功但 Claude Code 没走自定义端点现象cc-switch status显示切换成功但 Claude Code 启动后仍然访问默认端点。这个问题的根源通常有两个Shell 环境变量没有重新加载。激活命令写入的环境变量文件只对“新开启的进程”有效当前 Shell 或已经打开的 Claude Code 会话拿不到新值。解决方式重新开一个终端窗口或者执行source让环境变量重新加载。优先级冲突。如果当前 Shell 里已经导出了同名环境变量旧值会一直存在覆盖掉 CC Switch 的设置。你需要检查.bashrc、.zshrc里有没有历史遗留的ANTHROPIC_BASE_URL等导出语句。排查时用这一招最快在终端里执行echo $ANTHROPIC_BASE_URL看看输出的是不是模板里配置的端点地址。如果不是说明当前 Shell 的环境变量没有更新到。6.2 TypeScript 配置文件报错或无法解析有些开发者在手动配置时会遇到 TS 配置文件无法加载的情况。这个问题的原因比较复杂可能是缺少依赖、路径错误、或者是多个配置文件互相引用导致循环。我的建议是能用 JSON 就别用 TS。CC Switch 默认生成的config.json就是最保险的格式简洁且不会引入编译问题。如果你确实需要动态逻辑再考虑 TS但务必在切模板前先跑一遍类型检查。这里要特别说一句像这类“配置解析失败”的问题报错信息往往不够直观有时只给一个很笼统的提示。排查的最高效方式其实是“排除法”先把模板内容精简到最小如只包含 model 和环境变量确认能跑通之后再逐步加回其他配置项定位是哪一项出了问题。6.3 密钥写入配置文件之后不可见有人会发现激活模板后去查看 Claude Code 的配置文件里面看不到真实的 API Key只有模板变量名。这是刻意的设计。CC Switch 在激活时虽然会把真实密钥注入运行环境但并不会把它明文写入持久化的配置文件中。这样做有两个考虑避免密钥残留在磁盘上降低被扫描或误传的风险。保证模板文件可以安全地提交到仓库不会变成泄露源头。所以如果你在激活后发现配置文件里只有$SECRET_DAILY_API_KEY这样的占位符不要以为配置错了这是正常行为。真要验证密钥是否生效用 4.4 小节里说的运行日志检查法而不是看配置文件。6.4 常见问题速查表问题可能原因解决建议激活后新会话仍连默认端点Shell 环境变量未重载重新打开终端或source环境文件模型名无效或 404模板中 model 写错去服务商文档核对准确的模型标识符认证 401/403密钥过期或引用名错误重新secret set核对引用名大小写CLAUDE.md 未生效指令文件链接未更新检查 active 目录下的软链接状态并重建切模板后旧会话仍走旧模型会话缓存了旧配置关闭该会话新开一个 Claude Code 会话模板文件被团队合并覆盖拉取远端覆盖了本地模板涉及共享模板的修改先提交后拉取避免冲突一点个人经验总结用了 CC Switch 一段时间之后我最深的感受是配置管理的价值往往要等项目数量变多、团队成员变多之后才真正呈现出来。前两个项目你可能还能靠手动改撑一下等到第四个、第五个项目挤进来你一定会感谢当初花几分钟把这个流程立起来的自己。最后分享一个我个人很受用的技巧可以在项目的.gitignore里顺手加一行~/.ccswitch/secrets/和.active避免它们在误操作下被提交到仓库。虽然 CC Switch 默认就会过滤这些敏感内容但多一层保护总不是坏事。如果你也在用 Claude Code 并且一直在手动改配置真心建议试一下这类配置切换工具。把繁琐的配置工作交给工具把自己的精力留给真正有价值的代码和设计。
开始之前先问一句你是不是也经历过这种场面——手里的 Claude Code 项目昨天还在用一个模型服务今天想换成另一家结果得翻出配置文件改 apiKey、改 baseURL、改 model 名改完还要小心翼翼检查是不是漏了逗号再惨一点如果你同时维护两三个项目每个项目的自定义指令还不一样那一套手动操作下来光是想心情就累了。所以说“别再手改配置了”真不是矫情。这个项目标题里的 CC Switch解决的就是这个痛点。它本质上是一个 Claude Code 的配置切换管理工具让你把不同的模型服务、不同的密钥、不同的项目指令全部做成配置模板然后在需要的时候一条命令切过去。简单说它就是给 Claude Code 装了一个“多配置文件遥控器”。这篇博文我会从实际使用的角度把这个工具的定位、核心设计思路、完整实操流程、以及我在真实项目中折腾出来的经验一次讲完。如果你正在用 Claude Code或者打算尝试把它接入自定义模型这篇内容应该能帮你少走不少弯路。1. 项目背景与痛点拆解1.1 手动配置到底痛在哪里先说一个很典型的场景。我手上有两个项目一个是日常业务开发需要快速响应、上下文要精简另一个是做深度的代码审查和架构梳理需要模型更“沉得住气”输出的推理过程要完整。这两个需求用同一个模型配置显然不合适。于是问题就来了每次切换模型服务我都要打开 Claude Code 的配置文件找到 environment 那一堆变量把 ANTHROPIC_BASE_URL 换掉、把 ANTHROPIC_AUTH_TOKEN 换成新密钥、把 model 改成对应型号。更麻烦的是项目里还有自定义指令文件不同项目的 CLAUDE.md 内容也不一样。要是忘了改轻则模型行为不符合预期重则密钥配错直接鉴权失败。这些操作的痛点可以归纳成三个操作繁琐且容易出错配置文件是 JSON 格式一个逗号放错地方整个配置就废了。手动改多了早晚会踩坑。密钥管理混乱配置里直接写死密钥很容易随代码仓库泄漏。而不同服务商的密钥本质上是敏感资产散落在各个配置文件里既不安全也不方便轮换。切换成本高人在不同任务之间切换时如果每次都要花三五分钟改配置心情和状态都会被打断。1.2 CC Switch 能解决什么问题CC Switch 的思路很直接把“配置过程”从“手动编辑文件”变成“选择预设方案”。你可以先为每个使用场景建立一份配置模板模板里包含了模型服务端点、密钥引用、模型名称、以及该场景下需要的 CLAUDE.md 内容。切换场景时只需执行一条命令工具会自动帮你更新 Claude Code 实际读取的配置文件和项目指令文件。这个设计解决了上面三个痛点配置文件不用再手改了工具会生成合法的、结构完整的配置内容。密钥不直接写在配置里而是存到单独的安全存储区模板里只放引用。切换从“改多个文件”变成“跑一条命令”几秒钟搞定。对于同时使用多个模型服务、或者团队里多人共用一套开发环境的场景这个工具的价值会非常明显。它不是给 Claude Code 增加新功能而是把“配置管理”这件原本散乱的事情变成了一套有章法的流程。2. 核心设计思路解析2.1 配置模板化把配置文件当作“可复用资产”CC Switch 的核心抽象是“配置模板”。你可以把一份模板理解成一个完整的、描述“某一种使用方式”的包它通常包含四部分内容组成作用示例端点配置指定模型服务的接入地址ANTHROPIC_BASE_URL鉴权配置指定认证方式与密钥引用ANTHROPIC_AUTH_TOKEN模型参数指定默认模型与相关参数model、max_turns项目指令指定该场景下的自定义指令内容CLAUDE.md这样的设计最大的好处是“配置即代码”。配置模板可以纳入版本管理可以 review可以回溯。你不再需要记住上一次改了哪几个字段只要看模板文件的历史记录就行了。这里说一下我自己的理解模板化本质上是把“隐性的操作知识”显性化。以前你需要知道改哪几个位置、改成什么值这些都是藏在脑子里的经验。而有了模板之后这些经验就沉淀成了文件。哪怕隔了三个月回来或者换个新人接手看一眼模板就明白了。2.2 密钥与配置分离安全性的关键设计很多人在做配置管理时最容易犯的一个错误就是“图省事密钥直接写在模板里”。CC Switch 在设计上刻意避开了这一步。它的做法是模板文件里只保留密钥的“引用标识”例如$SECRET_PROD_ANTHROPIC_KEY。真实的密钥存放在独立的安全存储中比如系统密钥环、~/.ccswitch/secrets.json并使用本地权限锁保护。激活某个模板时工具会把密钥从安全存储中取出动态注入到 Claude Code 可读取的配置中但这个配置里的密钥在非运行状态下会被清理或脱敏。为什么要这么设计因为模板文件通常是会进 Git 仓库的如果你把密钥直接写在模板里等于把密钥放进了版本历史。一旦仓库泄漏所有历史版本里的密钥都会暴露轮换的成本极高。而采用“配置与密钥分离”即使模板公开别人也拿不到你的真实密钥。实际操作中这一点给我带来的好处非常直接我可以放心地把配置模板推到团队仓库里让同事直接 clone 下来用而密钥只需要各自在自己的机器上执行一次导入命令即可。2.3 环境变量注入与生效机制Claude Code 读取配置时主要依赖当前 Shell 环境中的环境变量和特定目录下的配置文件。CC Switch 的干预方式就是把两件事做好写环境变量文件生成一个只包含当前激活模板所需变量的文件并让 Claude Code 启动时自动加载。更新配置文件把激活模板中的参数同步写入 Claude Code 实际读取的配置同时处理好和已有配置的合并逻辑。这里有一个容易踩坑的点Claude Code 的配置优先级环境变量通常高于配置文件。所以如果你既设置了环境变量又在配置文件里写入了相同的键实际生效的是环境变量。CC Switch 在激活模板时会统一写入环境变量和配置文件两处并且保证它们一致不会出现“配置文件和环境变量打架”的情况。在你手动操作时这种细节最容易被忽略。你可能兴高采烈地改完了配置文件发现程序根本不吃这一套花很久排查才发现原来是某个环境变量在作怪。CC Switch 把这种一致性作为工具的默认行为省去了这类心智负担。3. 从零到一安装与初始化实操3.1 安装方式CC Switch 的安装并不复杂。如果你是 Node 生态的常用者可以直接通过 npm 或 bun 这类包管理器全局安装如果你更习惯使用单文件二进制也可以从仓库的发布页直接下载对应平台的二进制文件。以 npm 安装为例npm install -g cc-switch安装完成后执行cc-switch --version确认安装是否成功。如果输出正常说明工具已经进入你的 PATH。这里有一点建议如果你在团队里推广这个工具最好把安装命令写进团队的开发者文档里免得每个人各装各的、版本不一。版本不一致带来的配置格式兼容问题真的会让人头大。3.2 初始化项目目录安装好后第一步是初始化 CC Switch 的配置目录。执行cc-switch init这个命令会在你的用户目录下创建一个.ccswitch文件夹里面包含三个子目录~/.ccswitch/ ├── profiles/ # 存放所有配置模板 ├── secrets/ # 存放加密后的密钥信息 └── active/ # 存放当前激活状态的链接与记录初始化完成后可以用cc-switch status查看当前状态。这个时候它一般会提示你还没有激活任何模板。为什么需要单独的 active 目录因为切换配置本质上是“引用关系的变化”工具通过这个目录记录当前哪个模板被激活避免在多个配置文件中留下大量半脏不脏的痕迹。3.3 创建第一个配置模板创建一个模板命令很简单cc-switch profile create daily这条命令会在 profiles 目录下生成一个名为daily的模板为了让你后续能直接编辑它还会在~/.ccswitch/profiles/daily/下生成以下文件config.json存放端点、模型名等基础配置。CLAUDE.md存放该场景的项目指令。secrets.required声明这个模板需要哪些密钥引用。初始的config.json大概是这个样子{ name: daily, environment: { ANTHROPIC_BASE_URL: $SECRET_DAILY_BASE_URL, ANTHROPIC_AUTH_TOKEN: $SECRET_DAILY_API_KEY }, model: deepseek-chat, settings: { includeCoT: false } }注意看这里环境变量的值写的是$SECRET_DAILY_BASE_URL和$SECRET_DAILY_API_KEY这就是前面提到的“密钥引用”。真正要填的密钥存在 secrets 里稍后我会讲。创建模板之后你还需要编辑CLAUDE.md把在这个场景下希望 Claude Code 遵循的指令写进去。比如# 日常开发指令 - 优先输出简洁有效的代码避免过度设计。 - 涉及修改时先简要说明改动思路再给出完整代码。 - 回答尽量使用中文。这样一个最小可用的配置模板就建好了。4. 核心实操把自定义模型接进 Claude Code4.1 准备接入参数在写模板之前你手头需要准备好接入某个模型服务需要的基础参数。一般就三样接入地址Base URL、模型名称、以及鉴权密钥。以接入一个兼容 Anthropic API 协议的模型服务为例你大概需要拿到如下信息Base URL: https://your-model-endpoint.example.com/v1 Model Name: your-model-name API Key: sk-xxx这里要说明一下不同的服务商给出的接入信息格式可能不太一样有些提供的是完整的 Base URL有些则是需要拼接路径的。我的建议是在动手配置之前先去对应服务商的文档里确认一下接口兼容性以及正确的路径格式免得在配置步骤里反复试错。4.2 导入密钥到安全存储先别急着编辑模板我们应该把密钥导入 CC Switch 的安全存储cc-switch secret set daily_base_url https://your-model-endpoint.example.com/v1 cc-switch secret set daily_api_key sk-xxx设置完成后可以执行cc-switch secret list查看已存在的密钥引用名。你会发现密钥列表里只是告诉你“哪些引用名已存在”而不会把真实值打印出来。这一点在录屏演示或者团队分享时特别有用不会出现“密钥当场社死”的尴尬。需要注意的是secret 一旦设置它就成了你本机上的私有资产。如果你换了电脑需要在新机器上重新导入而配置模板文件可以直接复用。这也再次体现了“配置与密钥分离”的优势。4.3 编写并激活自定义模型配置模板现在我们把config.json里的密钥引用替换成刚设置好的真实引用。比如{ name: daily, environment: { ANTHROPIC_BASE_URL: $SECRET_DAILY_BASE_URL, ANTHROPIC_AUTH_TOKEN: $SECRET_DAILY_API_KEY }, model: your-model-name, settings: { includeCoT: false } }然后执行激活命令cc-switch use daily这条命令会做这么几件事读取daily模板的配置。从安全存储中取出对应的真实密钥值。生成 Claude Code 可识别的环境变量文件与配置文件。将CLAUDE.md复制到当前项目的指令目录或建立软链接。激活成功后执行cc-switch status你应该能看到类似这样的输出当前激活模板: daily 模型: your-model-name 端点: https://your-model-endpoint.example.com/v1 (已启用) 指令文件: 已链接4.4 验证模型是否真的生效配置完毕后在项目目录下运行claude命令随便问一句“你是通过哪个模型端点运行的”如果一切正常Claude Code 会按照新指令文件的要求回答并且你可以通过它返回时的响应特征间接判断接入是否成功。更稳妥的验证方式是查看 Claude Code 启动时的日志。如果你用的是 debug 模式通常会在日志里看到当前加载的 Base URL 和模型名。比如claude --debug看日志里打印的api_base、model字段是否与你的预期一致。这一步看似简单但能过滤掉九成以上的“以为自己接好了结果没生效”的情况。我个人在实际操作中还习惯在验证阶段找一个该模型服务特有的接口能力来测试。比如如果这个模型服务支持特殊的 reasoning 能力我会故意问一个需要推理的问题看返回内容是否包含对应的思考标记。这一招能帮你快速确认“模型真的通了不只是环境变量通了”。5. 实战场景多项目多模型的无缝切换5.1 场景 A日常开发与深度分析切换回到开头那个两个项目的例子。我为它们分别建了两个模板daily和reviewer。daily模板模型选速度快的轻量模型includeCoT关闭CLAUDE.md 里要求输出精简。reviewer模板模型选推理能力更强的模型includeCoT打开CLAUDE.md 里要求逐步分析、输出完整理由。平时在业务项目里写代码时执行cc-switch use daily。等到晚上要做代码审查、梳理架构时切到项目目录执行cc-switch use reviewer整个会话就被带到“深度模式”。这个过程不需要重启电脑也不需要手动去翻配置文件基本一两秒就能完成。切换之后我通常会把当前 Claude Code 会话关掉重新开一个。原因很简单Claude Code 在启动时读取环境和配置已经打开的会话里可能还缓存着旧的配置状态。这里分享一个我自己摸索出来的小习惯在切换模板之前先用cc-switch use daily --dry-run看一遍将要写入的配置预览确认模型名、端点这些关键信息是对的然后再真正执行切换。预览模式在关键操作前能帮你兜底。5.2 场景 B团队共享配置模板团队协作时CC Switch 的模板共享功能会特别顺手。做法是把~/.ccswitch/profiles/下的模板文件不含 secrets 目录提交到一个团队仓库然后在团队文档里写明安装和导入密钥的步骤。新同事加入后只需三步npm install -g cc-switch cc-switch init git clone 团队配置仓库 ~/.ccswitch/profiles cc-switch secret set prod_base_url 生产环境地址 cc-switch secret set prod_api_key 自己的访问密钥 cc-switch use prod这个流程把“新环境配置”从小时级压缩到分钟级。而且由于密钥是各人各设就算某个同事的密钥泄漏了也只需要轮换他一个人的不影响团队其他人。团队场景下还有一个容易被忽略的点模板里最好使用相对稳定的模型名称不要频繁更换。因为模板一旦被共享改模型名会影响所有使用该模板的人。如果确实要升级模型建议先在个人模板里验证再合并到共享模板。5.3 场景 C版本回滚与审计配置管理还有一个隐藏价值追溯历史状态。CC Switch 的模板本质上就是普通文件你可以用 Git 或者其他版本工具管理它们。某次切换后模型表现不如预期你想回到上一版配置这时候直接git checkout旧版的模板文件然后重新cc-switch use即可。如果还想做更精细的审计可以在模板的config.json里加一个自定义字段比如{ name: prod, meta: { owner: backend-team, since: 2025-03-10, reason: 迁移到新版模型以便支持更长上下文 } }这种元信息字段是允许被保留的CC Switch 不会去重写模板。这给后续维护提供了“为什么这么配”的线索。我自己一般会在每次模板变更时顺手更新meta.reason等过几个月再回头看会省下很多脑力。6. 常见问题与排查心得6.1 激活成功但 Claude Code 没走自定义端点现象cc-switch status显示切换成功但 Claude Code 启动后仍然访问默认端点。这个问题的根源通常有两个Shell 环境变量没有重新加载。激活命令写入的环境变量文件只对“新开启的进程”有效当前 Shell 或已经打开的 Claude Code 会话拿不到新值。解决方式重新开一个终端窗口或者执行source让环境变量重新加载。优先级冲突。如果当前 Shell 里已经导出了同名环境变量旧值会一直存在覆盖掉 CC Switch 的设置。你需要检查.bashrc、.zshrc里有没有历史遗留的ANTHROPIC_BASE_URL等导出语句。排查时用这一招最快在终端里执行echo $ANTHROPIC_BASE_URL看看输出的是不是模板里配置的端点地址。如果不是说明当前 Shell 的环境变量没有更新到。6.2 TypeScript 配置文件报错或无法解析有些开发者在手动配置时会遇到 TS 配置文件无法加载的情况。这个问题的原因比较复杂可能是缺少依赖、路径错误、或者是多个配置文件互相引用导致循环。我的建议是能用 JSON 就别用 TS。CC Switch 默认生成的config.json就是最保险的格式简洁且不会引入编译问题。如果你确实需要动态逻辑再考虑 TS但务必在切模板前先跑一遍类型检查。这里要特别说一句像这类“配置解析失败”的问题报错信息往往不够直观有时只给一个很笼统的提示。排查的最高效方式其实是“排除法”先把模板内容精简到最小如只包含 model 和环境变量确认能跑通之后再逐步加回其他配置项定位是哪一项出了问题。6.3 密钥写入配置文件之后不可见有人会发现激活模板后去查看 Claude Code 的配置文件里面看不到真实的 API Key只有模板变量名。这是刻意的设计。CC Switch 在激活时虽然会把真实密钥注入运行环境但并不会把它明文写入持久化的配置文件中。这样做有两个考虑避免密钥残留在磁盘上降低被扫描或误传的风险。保证模板文件可以安全地提交到仓库不会变成泄露源头。所以如果你在激活后发现配置文件里只有$SECRET_DAILY_API_KEY这样的占位符不要以为配置错了这是正常行为。真要验证密钥是否生效用 4.4 小节里说的运行日志检查法而不是看配置文件。6.4 常见问题速查表问题可能原因解决建议激活后新会话仍连默认端点Shell 环境变量未重载重新打开终端或source环境文件模型名无效或 404模板中 model 写错去服务商文档核对准确的模型标识符认证 401/403密钥过期或引用名错误重新secret set核对引用名大小写CLAUDE.md 未生效指令文件链接未更新检查 active 目录下的软链接状态并重建切模板后旧会话仍走旧模型会话缓存了旧配置关闭该会话新开一个 Claude Code 会话模板文件被团队合并覆盖拉取远端覆盖了本地模板涉及共享模板的修改先提交后拉取避免冲突一点个人经验总结用了 CC Switch 一段时间之后我最深的感受是配置管理的价值往往要等项目数量变多、团队成员变多之后才真正呈现出来。前两个项目你可能还能靠手动改撑一下等到第四个、第五个项目挤进来你一定会感谢当初花几分钟把这个流程立起来的自己。最后分享一个我个人很受用的技巧可以在项目的.gitignore里顺手加一行~/.ccswitch/secrets/和.active避免它们在误操作下被提交到仓库。虽然 CC Switch 默认就会过滤这些敏感内容但多一层保护总不是坏事。如果你也在用 Claude Code 并且一直在手动改配置真心建议试一下这类配置切换工具。把繁琐的配置工作交给工具把自己的精力留给真正有价值的代码和设计。
