用 Claude Code 写代码的人，大概都干过这件事：为了换个供应商，跑到用户目录里翻 settings.json，把 base_url 和 key 手改一遍，改完重启终端试试通不通，不通再改回来。用两个工具就翻两份配置，装过 MCP 的更麻烦，同一个服务要在三四份文件里各配一遍。
这活儿本身没难度，就是烦。CC Switch 就是冲着这段烦人流程来的。
是什么
CC Switch 是一个桌面端配置管理器，作者 farion1231，MIT 协议，用 Rust 加 Tauri 2 写的。仓库当前 136,449 个 Star、9,315 个 Fork，2,489 次提交，最新版本 v3.20.4 发布于 2026 年 9 月 22 日，9 月 24 日仓库还有提交。
它管的是 Claude Code、Claude Desktop、Codex、Gemini CLI、Grok Build、OpenCode、OpenClaw、Hermes、MiniMax Code 这九款工具的配置。核心动作很简单：你不再手改文件，而是在一个窗口里存好各家供应商的信息，需要哪个点一下，它去把对应工具的配置文件改好。
Windows、macOS、Linux 都有原生客户端，数据库是一个本地 SQLite 文件，位置在 ~/.cc-switch/cc-switch.db。作者在文档里特意写了「最小侵入」这条设计原则——哪怕你把应用卸了，原来的命令行工具照样能用。
CC Switch 的仓库首页。src-tauri 装 Rust 后端，src 是前端，最近一次提交在几个小时前
它到底好用在哪儿
第一是预设真的省事。它内置了 50 多个供应商预设，AWS Bedrock、NVIDIA NIM 这些正规渠道在列，各种社区中转站也在列。选中一个，把 Key 粘进去就完事了，不用你自己去查这个服务商的兼容端点长什么样。更省事的是「通用供应商」这个设计——一份配置能同时同步到 Claude Code、Codex 和 Gemini CLI，三家不用配三遍。
第二是全国一盘棋的 MCP 和技能管理。以前给三个工具配同一个 MCP 服务，你得改三份文件，改完还得记着哪份改过。它把这些收在一个面板里双向同步，还支持 Deep Link 导入——别人扔给你一个 ccswitch:// 开头的链接，点一下就把供应商或 MCP 配置导进来了。技能那边能直接从仓库或 ZIP 包装，装上默认走软链，改一处到处生效。
第三是托盘。这个功能看着小，用起来最爽：不用开主窗口，右键托盘直接切供应商。而且它给 Claude Code 做了热切换，配置改完不用重启终端——这是九款工具里唯一支持的，其余的文档里明说了还得重启。
第四是它顺手带了一个本地代理，这块比单纯改配置文件有意思。代理能做格式转换、自动故障转移、断路器，还会定期探测供应商健康度。更细的是可以按应用单独接管——比如只让 Codex 走代理，别的不管。对同时挂多个供应商、想按价格和延迟自动分流的人来说，这相当于把一层网关塞进了桌面应用。
另外还有两个容易被忽略的：用量面板会统计花费、请求数和 token 趋势，能自己给模型配单价，跑久了大概知道自己一个月烧了多少钱；会话管理器能浏览、搜索、恢复各工具的对话历史。配置写盘走原子操作，自动备份轮换保留最近 10 份，技能卸载前的备份留 20 份——手改配置文件改坏过的人会明白这两个数字的价值。
v3.20.4 的发布记录。这一版以修复为主，同时把 MiniMax Code 纳了进来，并做了数据库迁移
怎么用
装的部分没什么技术含量，去官网或者 Releases 页下对应平台的包：Windows 10 以上、macOS 12 以上、Linux 都可以。macOS 版本作者做了签名和公证，直接装就能开，不用折腾绕过 Gatekeeper。Linux 那边 Arch 用户走 AUR，AppImage 是通用选择。
启动之后第一次会让你确认导入现有的配置——这一步很重要，它会把你当前工具的配置当成默认供应商存进来，所以不会出现装完反而把原配置弄丢的情况。之后就是三步循环：新建供应商、粘贴 Key、切换。
配置文件的落点它都替你算好了。比如 Hermes 是 ~/.hermes/config.yaml，MCP 配置走 ~/.minimax/mcp.json 这类位置，你不需要知道这些路径也能用；但反过来，哪天你想手工核对，知道它在哪儿也更放心。
有一点值得提前知道：切换供应商时，插件那类「跟 Key 和端点无关」的公有配置默认不会被带过去。作者的处理方式是给了个「共享配置」面板，在编辑供应商时点「从当前供应商提取」，把公共部分存下来，新建供应商时勾上「写入共享配置」就行。第一次遇到「我的插件配置怎么没了」的人，基本都是漏了这一步——不过原始配置不会真的丢，第一次启动时导入的那个默认供应商里存着完整的。
不足也得说清楚
未关闭的 Issue 停在 2,884 个，这个数不算小。项目迭代很快、作者响应也勤，但需求确实堆着，有些边角场景得等。
Linux 上的坑比较具体。AppImage 为了绕开历史上的原生 Wayland 崩溃，强制走了 XWayland；这个选择在较新的 Wayland 加 NVIDIA 组合上会出问题——标题栏按钮能用，但网页内容区点不动，缩放窗口还会黑屏。绕法是启动时加环境变量 CC_SWITCH_GDK_BACKEND=wayland 切回原生 Wayland。文档把这个坑写得很清楚，但毕竟是要用户自己手动处理的。
还有一条设计上的取舍：当前生效的供应商不让删。因为删光了对应的命令行工具就没法用了，所以系统永远保留一个。你如果只是想「暂时不用某个工具」，正确做法是在设置里把它隐藏，而不是删配置。
另外它终究是个「配置管理器」，不是代理服务本身。默认情况下你切了供应商就是直接连，本地代理那套故障转移是可选功能，要自己开、自己配。别指望装完就自动帮你做成本优化。
跟同类怎么比
最直接的对照是各个工具自带的配置方式。Claude Code 有自己的配置文件，Codex 有 TOML，Gemini CLI 又是另一套。原生方式永远最新、最不会出错，但一次只能管一个工具，跨工具同步全靠你自己记。你要是只用一个工具、一年也不换供应商，那真没必要装。
另一个方向是各种中转网关，比如 one-api 这类自建服务。它们解决的是「统一分发」问题，能力更重，但得部署服务、维护实例，面向的是团队和批量场景。CC Switch 是单机桌面应用，管的是「我本机这九款工具怎么快速换配置」，两者不冲突，甚至可以叠着用——网关当地基，CC Switch 管客户端指向哪里。
我的判断是：它的价值随你用的工具数量增长。只用一个工具，它是锦上添花；同时用三四个命令行编程助手、还都配了 MCP 的人，它省下的是实打实的重复劳动。13.6 万 Star、超过 50 个供应商预设、提交都挤在最近几天，这个活跃度说明它踩中了相当多人的同一个麻烦。
GitHub：https://github.com/farion1231/cc-switch
官方网站：https://ccswitch.io
标签：#CCSwitch #AI编程工具 #配置管理 #MCP #供应商切换 #Rust #Tauri #开源工具
你现在同时在用几个 AI 编程工具？配 MCP 的时候是每个都手工改一遍，还是有别的办法？