如果你用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 還推薦了兩個類似的優秀項目：New API 和 Claude 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 。
那道雙重彩虹，不是運氣，是選擇。