转载 · X向阳乔木｜130万次下载，2万Star开源项目CC Switch，36岁转行程序员Jason的第一个作品

如果你用Claude Code，大概率用过CC Switch这个软件。

今天邀请作者直播，了解工具背后的故事（以下内容由AI生成）

2026年1月，一个叫 CC Switch 的开源项目在 GitHub 上突破了 20,000 stars。

这个数字背后，是一个大龄转行者用六个月时间写就的故事。

项目作者 Jason 之前做进出口贸易，去年才开始自学编程。

他花三个月学完了从 TypeScript 到 React 、Nodejs、Rust的基础知识，然后做出了第一个正式项目。

没有计算机专业背景，没有大厂履历，只有一个简单的出发点：

做出个满意的项目，证明自己，转行之路没有失败。

痛点即产品

国内使用 Claude Code 的用户都知道，官方订阅门槛高，大家更多依赖中转站或国产模型。

但在不同供应商之间切换，需要手动改环境变量或配置文件，操作繁琐且容易出错。

当时市面上已经有一些脚本工具，但都是命令行操作，对普通用户不够友好。

Jason 正好在给开源项目 Cherry Studio 贡献代码，学习了 Electron 框架，于是萌生了一个想法：

做一个可视化界面，让切换变得简单直观 。

第一版只用了不到一周就完成了。

功能非常基础，就是通过修改配置文件后缀名来实现切换，而且只支持 Claude Code。

但这个简单的工具解决了一个真实的需求。

Jason 的设计理念很明确： 侵入性最小 。

即使卸载 CC Switch，也不会影响用户的正常使用。

你的应用总会有一个正在启用的供应商，这样即便删掉工具，配置依然有效。

这种对用户体验的细致考虑，从第一版就贯穿始终。

从玩具到产品的艰难进化

真正的考验在后面。

随着用户增多，Jason 开始收到各种反馈和功能请求。

GitHub 的 Issue 区很快积累了上百条建议。

他需要在这些需求中做选择，既要保持产品的核心优势，又要满足不同用户的实际需要。

产品的核心始终是易用性 ，Jason 反复强调这一点。

无论添加什么功能，都不能破坏"填写一个 API Key 就能导入，一次点击就能切换"的体验。

这种克制并不容易。

有段时间，他在主界面上增加了本地代理和故障转移的快捷开关。

这个功能本来是为中转站用户设计的，尤其是公益站用户，他们的服务非常不稳定，需要频繁切换。

但很多不需要这些功能的用户看到按钮就顺手打开了，结果产生了一系列问题，最后 Jason 不得不把这些开关移到设置里，默认隐藏。

他说这是一个"非常苦涩的教训"，违背了易用性的核心原则，增加了额外的复杂度。

更大的挑战来自技术层面。

为了让软件更轻量，启动速度更快，Jason 决定把整个项目从 Electron 重构为 Tauri。

Electron 的问题是把整个 Chrome 运行时封装在里面，即使只写了一个页面，基础大小也得 80MB 左右，而且内存占用大。

对于一个仅仅实现供应商管理和切换的工具来说，太重了。

但重构意味着从 TypeScript 转向 Rust。

编程语言变了，AI 领域那些现成的 TypeScript 和 Python 库都用不了了。

重构过程中最痛苦的是本地代理功能。

这个功能本来是为了支持热切换和故障转移，因为 Claude Code 在 2.49 版本之前没有热切换，改了供应商必须重启终端才能生效。

对于需要频繁切换的中转站用户来说，这是刚需。

结果还没开发完，Claude Code官方就自己支持了热切换。

但代理功能已经做到一半，只能硬着头皮继续。

因为换了语言，很多现成库都用不了，只能用 Rust 从头写起。

重构完成后，软件体积从 80MB 降到了 Mac 上的 6-7MB，内存占用几乎可以忽略不计，点击后零点几秒就能打开。

Jason 说，总体来看，这个重构还是有必要的。

选择 Electron 还是 Tauri，取决于你的项目定位 。

如果是 Cherry Studio 那种大而全的项目，Electron 是明智选择，但如果是小工具，Tauri 足够轻量。

配置管理的血泪教训

CC Switch 经历过三次大的重构。

第一次是从配置文件切换改为写入和读取 JSON。

第二次是从 Electron 到 Tauri。

第三次纯粹是为了清理技术债，把大文件拆分，统一组件使用方式。

但最痛苦的教训来自配置管理策略的反复。

最初，Jason 采用的是全量替换策略：切换供应商时，覆盖整个配置文件，而不是只替换 API Key 和请求地址。

这样做是因为当时 Claude Code的配置字段几乎每个小版本都要变，软件更新速度跟不上。

而且有些供应商有独特的字段，比如限制最大请求 token，这个限制对另一个供应商可能反而会限制性能。

所以他设计了一个"通用配置"功能：把不同供应商的公用字段（比如插件配置、禁用签名、禁用自动更新等）提取出来，在新建供应商时可以选择是否写入这些通用字段。

问题是，很多用户没看到这个选项，或者不理解是什么意思，新建供应商后发现配置全丢了，就开始骂人。

有段时间这个问题被问了很多次，甚至让 Jason 心态崩溃。

他开始怀疑，是不是关键字段替换更好？于是在今年春节期间，把整个逻辑重构为关键字段替换。

结果刚发布一天就翻车了。

因为有些用户需要用到自定义字段，关键字段替换无法传递这些字段。

更要命的是，Claude Code 的配置文件格式非常特殊，是 TOML 格式而不是 JSON，有些字段根本没法写入。

Jason 昨天加班，今天又折腾了两天，反复分析后发现， 还是全量替换加通用配置，是更稳妥的方案 。

下午的版本又把逻辑回滚了。

万幸的是，他在重构时没有改变数据结构，所以两个版本之间完全兼容，不会丢数据。

AI 时代的学习方法论

Jason 的转行经历给很多人带来启发。

他的方法并不神秘： 先过一遍基础概念，然后做实际项目，在正反馈中学习 。

他强调，虽然 AI 时代 AI 能做大部分事情，但基础概念不能跳过。

你得知道这个东西存在，才能让 AI 去做，而且学习过程不会花太多时间，很快的。

学 TypeScript 的时候，他写了个扫描《魔兽世界》拍卖行的脚本，能赚游戏币那种。

学 React 和 Next.js 的时候，做了个游戏目录网站，每个阶段都有能用的东西产出，这种成就感支撑着他继续往下走。

他说，所有学习都是这样，单纯的输入比较枯燥， 得尝试做一些东西，得到正反馈 。

在 AI 的辅助下，这非常简单。

但他也有一个重要原则： 不要提交你看不懂的代码 。

AI 生成完代码后，不说把每个细节都看懂，最起码得看懂这些代码是在干什么。

这是在 AI 时代，对新手来讲挺重要的底线。

很多人担心工程师断层问题，传统的从新手到资深的中间过程好像被 AI 替代了。

Jason 觉得， 新手更应该观察 AI 的工作过程 。

他看到很多高手同时开好几个窗口、多个 WorkTree 并行进行，但他建议新手还是集中在一个任务上，观察 AI 的思考过程，能学到很多东西。

而且 AI 中间思维出问题的时候，你也可以及时打断纠正。

AI 编程的实战技巧

关于 AI 编程，Jason 分享了一套完整的方法论：

1. 用对的模型

如果你不是资深程序员，直接用最好的模型 。

因为你可能没有足够强的判断代码质量的能力，用最好的模型能降低出错概率。

比如 Plan 或者执行就用 Opus 4.6（现在是 4.5），如果是 debug 或者 read 代码就用 Codex 5.3 或者 GPT 5.2。在重要任务上，直接用最强的。

1. Plan Mode 是关键

在开始一项功能之前，先去分析、计划一下怎么做。Claude Code本身就有 Plan Mode。

如果是非常复杂的任务，要独立维护一个文档 。

这个文档里写清楚整个大任务需要几个步骤，每个步骤是什么，目的是什么，基线是什么。

当然也可以和 AI 一起产出这个文档。

在每次开始一项小任务之前，先从这个文档里读取这一次的任务。

完成之后，再把结果写到里面。

你可以手动维护这个文档，进行增减或修改。

1. 上下文管理是核心

从最早的 Copilot，到后来的 Cursor，到现在的 Claude Code， 本质上都是上下文管理的进步 。

尽可能把最高效、最需要的上下文提供给 AI 模型。

具体操作上：

• 如果知道问题大概在哪，直接告诉 AI 在哪个方面去找
• 如果知道任务集中在哪个文件，直接告诉它主要在这个文件里
• 这样可以非常节约上下文

现在模型的上下文已经很长时间没有进步了。

Sonnet 系列虽然出了 1M 的版本，但不太实用，大部分还是用 200K 那个版本。

所以 控制好上下文，该压缩的时候就压缩，该新开的时候就新开 。

Jason 的经验是：

• 如果接下来的问题和之前的上下文紧密相关，就继续在原对话上
• 如果不那么相关但又有一点关系，可以压缩一下再继续
• 如果完全没有关系，直接新开对话

尽量不要让它触发自动压缩 。

如果任务拆分得好，除非是特别大的任务或文案工作，一般不会到自动压缩那一步。

1. 控制代码量

代码是债务，不是资产 。这句话在 AI 时代变得更加重要。

千万不要追求今天写了多少行。

能用尽可能少的行数、尽可能简单的架构来实现功能，是更好的选择。

AI 不会拒绝你。如果你去找一个程序员，他可能会说这个太复杂做不了。

但 AI 即使可能实现不了，也会去帮你实现。这样有可能把一个简单的功能，用非常复杂的路径给实现了。

Jason 收到过一个 8,000 行的 PR，只是为了测试服务器是否可用，而当时整个项目才 6,000 行。

早期的 Claude-3.5 或 4.0 非常喜欢写防御性代码，有一种把复杂度加深的冲动，会把各种边界条件全部覆盖到，导致代码非常多。

1. 及时清理技术债

当项目到了一定规模，要及时清理技术债。

无论是留下的问题，还是单个比较大的文件。

一个文件尽量保持在 1,000 行以内，最好是五六百行 。

这不是随便说的。Claude Code 的默认 read 工具只读前 2,000 行代码，再长就要用 grep 工具了。

如果一个文件有 5,000 行，会降低 AI 读取到目标代码的概率，获取不到精确的上下文，而且会很快塞满上下文，钱就流失了，效果还不好。

Jason 提到一个细节：OpenClaw 有一个前端文件 5 万行。

这个项目非常好玩，但离真正生产级别的软件还有很遥远的距离。

如果将来想用到生产级，这些技术债必须得清理。

1. 做好架构设计

在做之前要很好地做一下架构设计。

不能让 AI 直接开始写功能。

要想清楚实现什么功能，应该有哪些页面，前后端怎么交互，架构怎么设计。这个要在开始实施之前就计划好。

工程量上去之后，代码量上去之后，再去重构，说实在的挺麻烦、挺费功夫的，即使有 AI 的帮助 。

1. 必须使用 Git

新手可以不学其他技术， 一定要学 Git 。否则搞坏了真的找不回来。

语言的力量

Jason 有一个很有意思的观点：他不太喜欢"Vibe Coding"这个词。

他说，语言是有力量的，它不只是影响听到你说话的人，反而会影响你自己。

如果你说"这个项目是我Vibe Coding的"，容易让自己放松对产品代码质量的要求。

所以他一般不会参与那种"Vibe Coding"之类的话题讨论。

这种自我约束只用来要求自己，不会要求别人。

但这个提醒很重要。

元子补充到，维特根斯坦说"语言即地狱"，我们使用的语言已经给自己带上了一些暗示。

在 AI 时代，保持对代码质量的敬畏，比什么都重要 。

增长的秘密

CC Switch 的增长曲线很有意思。

从 2026 年 1 月开始出现明显增长，单月增加了近 7,000 stars。

这和 Claude Code 在国内的热度直接相关。

Jason 观察到，从去年年底开始，好像有很大一波 AI 编程突然普及开了一样。

再加上今年 ClaudeCode 和 OpenClaw 的热度变得很高，CC Switch 也跟着水涨船高。

而且国内的开源模型几乎全部都天生原生支持 Anthropic 的 Messages API格式，可以直接接入到 Claude Code 里。

这个卡点特别好。

Jason 在前期也做过一些推广。

比如国产厂商发新模型时，他就去蹭热度，说"使用我的工具，只需要填写一个 Key 就可以把它导入到 Claude 里面使用"。

他说， 如果你是自己做产品，尤其是现在 AI 时代产品井喷式发展，做营销或者蹭热度还是很有必要的 。

如果你是技术出身，没有必要觉得做营销或者蹭热度有点不好意思，一定要勇敢去蹭。

你的软件有什么优势，能解决什么问题，要把它说出来，让大家都知道。

现在 CC Switch 的下载量大概是 130 万次。

这是从 GitHub 上点击下载统计的，实际用户数不知道，因为软件不收集任何数据。

关于 API 的冷知识

Jason 科普了一个很多人不知道的知识：Claude 的官方 API 分为三种。

第一种是最正经的官方 API ，从官网、亚马逊云或微软云出来的。

这种 API 价格非常高，7 人民币等于 1 美元。但可以用在任何地方，Cursor SDK、OpenClaw、各种 Chatbot 都可以。

第二种是从 Claude Max 订阅反代出来的 API 。

这种只能用在 Claude Code里，其他任何地方都不能用。

因为官方检测到你在非 Claude 的地方用，就会封号。

所以中转商也会限制，这种 API 只能用在 Claude 里。

第三种是逆向出来的反代 API ，比如从 Cursor 、kiro等工具里逆向出来。

这个可以用在任何地方，和第一种一样。

但性能会差一些，因为逆向后会带一些默认提示词，而且第三方应用为了节约成本，可能提供的不是完整上下文的。

不过第三种非常便宜，便宜到不可思议。

一天一亿 token 都可以，如果用第一种，一天得烧几千块钱。

这也解释了为什么有些中转站的 API 质量会差一些，主要看是这三种里的哪一种。

开源的力量

CC Switch 采用 MIT 协议，任何人都可以 fork 后自己改。

现在已经有了终端版（CLI 版）、外挂版，甚至有人做了智能预测功能，能自动判断任务需要用哪个模型。

Jason 说，网友Fork做的 CLI 版做得非常帅，他都不知道 TUI（终端用户界面）竟然能做得这么帅。