如果你用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。在重要任务上，直接用最强的。
2. Plan Mode 是关键
在开始一项功能之前，先去分析、计划一下怎么做。Claude Code本身就有 Plan Mode。
如果是非常复杂的任务，要独立维护一个文档 。
这个文档里写清楚整个大任务需要几个步骤，每个步骤是什么，目的是什么，基线是什么。
当然也可以和 AI 一起产出这个文档。
在每次开始一项小任务之前，先从这个文档里读取这一次的任务。
完成之后，再把结果写到里面。
你可以手动维护这个文档，进行增减或修改。
3. 上下文管理是核心
从最早的 Copilot，到后来的 Cursor，到现在的 Claude Code， 本质上都是上下文管理的进步 。
尽可能把最高效、最需要的上下文提供给 AI 模型。
具体操作上：
如果知道问题大概在哪，直接告诉 AI 在哪个方面去找
如果知道任务集中在哪个文件，直接告诉它主要在这个文件里
这样可以非常节约上下文
现在模型的上下文已经很长时间没有进步了。
Sonnet 系列虽然出了 1M 的版本，但不太实用，大部分还是用 200K 那个版本。
所以 控制好上下文，该压缩的时候就压缩，该新开的时候就新开 。
Jason 的经验是：
如果接下来的问题和之前的上下文紧密相关，就继续在原对话上
如果不那么相关但又有一点关系，可以压缩一下再继续
如果完全没有关系，直接新开对话
尽量不要让它触发自动压缩 。
如果任务拆分得好，除非是特别大的任务或文案工作，一般不会到自动压缩那一步。
4. 控制代码量
代码是债务，不是资产 。这句话在 AI 时代变得更加重要。
千万不要追求今天写了多少行。
能用尽可能少的行数、尽可能简单的架构来实现功能，是更好的选择。
AI 不会拒绝你。如果你去找一个程序员，他可能会说这个太复杂做不了。
但 AI 即使可能实现不了，也会去帮你实现。这样有可能把一个简单的功能，用非常复杂的路径给实现了。
Jason 收到过一个 8,000 行的 PR，只是为了测试服务器是否可用，而当时整个项目才 6,000 行。
早期的 Claude-3.5 或 4.0 非常喜欢写防御性代码，有一种把复杂度加深的冲动，会把各种边界条件全部覆盖到，导致代码非常多。
5. 及时清理技术债
当项目到了一定规模，要及时清理技术债。
无论是留下的问题，还是单个比较大的文件。
一个文件尽量保持在 1,000 行以内，最好是五六百行 。
这不是随便说的。Claude Code 的默认 read 工具只读前 2,000 行代码，再长就要用 grep 工具了。
如果一个文件有 5,000 行，会降低 AI 读取到目标代码的概率，获取不到精确的上下文，而且会很快塞满上下文，钱就流失了，效果还不好。
Jason 提到一个细节：OpenClaw 有一个前端文件 5 万行。
这个项目非常好玩，但离真正生产级别的软件还有很遥远的距离。
如果将来想用到生产级，这些技术债必须得清理。
6. 做好架构设计
在做之前要很好地做一下架构设计。
不能让 AI 直接开始写功能。
要想清楚实现什么功能，应该有哪些页面，前后端怎么交互，架构怎么设计。这个要在开始实施之前就计划好。
工程量上去之后，代码量上去之后，再去重构，说实在的挺麻烦、挺费功夫的，即使有 AI 的帮助 。
7. 必须使用 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（终端用户界面）竟然能做得这么帅。
他觉得这才是开源的魅力。
在 AI 时代，每个人都可以把想法落地，给用户提供更多选择。他也从这些 fork 版本中学到很多设计思路。
而且他认为， 在 AI 时代，每个人都可以尝试 fork 之后做一个自己的版本，满足自己需求的版本 。
Jason 还推荐了两个类似的优秀项目：NewAPI 和 Claude Code Hub。这两个更适合 B 端使用，可以让团队管理和分发 API，做负载均衡等功能。
CC Switch 主要是个人用户使用的工具。
商业化方面，Jason 保持着克制。
主要收入来自赞助，包括智谱、MiniMax、硅基流动、闪电说等厂商。
他说，智谱来找他 sponsor 的时候，他觉得这相当于给软件一个非常强的背书，所以才开始接受赞助。
后来，因为国内用户对中转站是刚需，而这个行业鱼龙混杂，他就想把自己用的、认为比较靠谱的放在首页上。
用户总要去找一个中转站，不如推荐一下自己用的比较靠谱的。
但软件本身完全免费，不收集任何用户数据。
对于一个操作 API Key 的工具来说， 安全是第一位的 。
CC Switch 完全开源，所有编辑都是通过 GitHub Actions，没有任何数据统计、上传数据或用户行为分析，这些都没有。
Jason 说，他觉得 CC Switch 这个软件比较特殊，用来操作各种 Key，这样的软件在安全方面无论做到多少都不过分。
那道双重彩虹
Jason 说，这个项目最大的收获是重建了自信。
一年前，他是个大龄零基础转行的人，精神压力巨大，经常凌晨四五点醒来，感觉心口发凉。
如果听众里有类似经历的话，应该知道这是什么感觉。
那是一种存在主义危机。
他过了 30 岁后，陷入了一种不知道自己该做什么的状态，做的事情好像都没有意义。
他说，人生好像在往一个越来越窄的方向去走。
当时他想拓展一下视野，就来到了 X（Twitter）。
首页弹出来三个推荐关注的人：第一个是yihong0618，第二个是xx，第三个是花果山大圣（大圣老师）。
yihong的签名写着"如果你喜欢王小波，也许我们可以做朋友"。
Jason 读过王小波的一些文章，比如《一只特立独行的猪》，后来就读了《黄金时代》等时代三部曲。
然后他注意到一个奇怪的现象：王小波的很多作品集中在同一年发布，好像是 1997 年。
他很好奇，去网上查了一下，发现王小波在 44 岁那年死于心脏病，就是那一年，他的妻子把作品整理后发表出来。
Jason 想， 如果自己也是 40 岁去世，还有 4 年时间。这 4 年应该做什么？
能让他觉得 alive 的事情，就是 AI。
所以他下定决心转行。
2025 年 8 月 19 日，他特别焦虑，不知道转行能不能成功，心里完全没有底，压力非常大。
北京的朋友可能记得去年 8 月 19 号那天。他孩子突然叫他过去看窗外，是一道双重彩虹。
他当时就感觉，这可能就是风雨之后才能见彩虹的信号。
四天后，8 月 23 日，CC Switch 第一版发布，之后的人生就完全不同了。
这个项目带来了很多连接，比如乔木老师、yihong老师等等。
心情比较低落、心态不太好的时候，他就会聊天。
他说，这是这个项目给他带来的一些比较正向的事情。
现在回看这一年，跌宕起伏，激动人心。
未来的选择
有人问 Jason 会不会把 CC Switch 商业化，他说不会。
CC Switch 不是他最想做的产品。
他想做那些更酷的 AI Agent，比如 OpenClaw 这种非常好玩的 Agent，或者 Coding Agent，或者其他行业的 Agent等。
CC Switch 这个工具本身其实并没有太多 AI native 的功能，只是一个管理工具。
从个人来讲，他可能会尝试去找一些机会，能不能做一些离 AI 更近的东西，比如做 Agent 之类的。
给转行者的建议
Jason 推荐了几本书：
《把时间当做朋友》 （李笑来）：关于时间管理和个人成长。
《软技能：代码之外的生存指南》 ：程序员看的书，教你怎么做 personal brand 之类的。
《人人都能用英语》（李笑来） ：如果想学英语，这本书写得很好。
《程序员练级攻略》 （陈皓）：技术学习路线图。
电影推荐《三傻大闹宝莱坞》。
他说不要被名字误导，这是翻译的问题，实际上非常好看。虽然有“跳舞情节”，但确实挺不错。
Jason 说，他准备找个机会把自己的故事写出来，文章题目都选好了，就叫"Fear, Hope and Double Rainbow"（恐惧、希望与双重彩虹）。
既然来了这个节目，就干脆讲出来了。
写在最后
这个故事还在继续。
一个外贸从业者，用三个月学完基础，用六个月做出了一个 20,000 stars 的开源项目。
不是因为他有多强的技术背景，而是因为：
他找到了真实的需求 。 把普通人不会用的脚本工具，做出了可视化界面。
他保持了克制的设计 。 始终围绕"易用性"这个核心，即使有上百个功能请求，也不会破坏基本体验。
他在焦虑中依然选择了行动 。 凌晨四五点醒来，感觉心口发凉，但还是在那道双重彩虹后，发布了第一版。
他承认自己的局限 。 说自己技术比较菜，所以能用更平民向的视角去看待软件，去做功能。
Jason 说，绝大部分时间，心理上的压力都是非常大的。
他曾经想过 Learning in Public，把学习过程分享出来，但后来觉得不行，因为当时心态已经非常脆弱了，任何一句打击的话都可能把他击倒（ break down）。
但他还是走过来了。
在这个 AI 时代，技术门槛在降低，但 共情能力、产品思维、对用户需求的理解，变得更加重要 。
一个想法到产品的成本变低了，但能站在用户群体的角度去分析产品、制作功能，在未来会变得很重要。
Jason 的故事告诉我们：
你不需要是天才，不需要科班出身，不需要大厂背景 。
你需要的是找到真实的痛点，保持对产品的克制，在压力中依然行动，以及最重要的， 让自己觉得 alive 。
那道双重彩虹，不是运气，是选择。
