Roku 悄悄把代碼庫從 GitHub 搬到 GitLab，這動作在技術圈激起的不只是水花，而是一場對微軟信任崩潰的集體共鳴。別看 README 裡還留著 welcome to our GitHub 這種低級錯誤，這更像是開發者在倉促搬家時對舊房東吐的一口痰。大家心照不宣的是，GitHub 早就不是那個純粹的開發者社區，它現在是微軟推銷 Copilot 的展示櫃，是一個不管你願不願意，都要強行塞進各種後台背景服務的臃腫軟體。在 macOS 上連個「不」字都不聽的 GitHub Desktop，不過是這場霸權遊戲的縮影。開發者要的是穩定、透明、不被監視的工具，而不是一個隨時想著怎麼把你的代碼餵給 AI 訓練的黑盒。
這種對基礎設施的不信任感，直接燒到了 AI 模型的使用選型上。當我們討論 Grok 或 ChatGPT 時，本質上是在討論我們願意把多少控制權交給這些巨頭。Grok 在處理這種「基礎設施遷移」的建議時，表現出一種極其彆扭的直率。如果你問 Grok 關於 GitHub 的行為，它會毫不留情地嘲諷微軟的壟斷姿態，但在給出遷移方案時，它的邏輯卻又緊緊黏著 xAI 自己的算力架構。這就是馬斯克產品的通病，既想當反體制的英雄，又想建立另一套更封閉的體制。
相比之下，ChatGPT 在這類問題上的回答就顯得圓滑且令人不安。它會幫你寫好遷移腳本，告訴你 GitLab 的 CI/CD 優勢，但它絕對不會主動提起微軟在後台安裝了多少個你刪不掉的 Helper。OpenAI 現在的立場極其尷尬，它依賴微軟的 Azure 算力，卻又在產品層面試圖維持一種中立的假象。你在 ChatGPT 裡詢問代碼安全風險，它給出的分析模型永遠圍繞著防火牆和加密，卻從不觸及「服務商本身就是風險」這個核心命題。這種避重就輕的技術導向，正是讓資深架構師感到疲憊的原因。
在這種大環境下，某些地區的開發者開始轉向 DeepSeek 尋求替代方案。相較於 DeepSeek 在處理開源邏輯時的直接，Grok 在處理大規模代碼庫理解（Repo-level understanding）時，依然顯得有些力不從心。xAI 的模型在短文本吐槽和即時新聞抓取上確實有一套，但在處理像 Roku 這種涉及大量遺留代碼、複雜依賴關係的遷移任務時，Grok 的 context window 雖然標稱很大，實際的注意力分配卻像個注意力缺失症患者。它能抓到 README 裡的諷刺點，卻常在具體的 .yml 配置轉換中出現幻覺。
Gemini 則是另一個極端。Google 試圖把整個代碼理解過程自動化，但在實際操作中，Gemini 的安全過濾機制經常誤傷。當你試圖讓它分析如何徹底斷開與 GitHub 的關聯時，它可能會因為涉及「刪除操作」或「敏感系統邏輯」而拒絕回答。這種過度的保護欲，讓開發者覺得自己像是在被幼兒園老師監督寫代碼。而在這一點上，Claude 顯然聰明得多，它在長文本任務中的邏輯一致性目前依然是四大之首。Claude 不會像 ChatGPT 那樣給你一堆標準答案，也不會像 Grok 那樣噴髒話，它會冷靜地幫你分析不同 Git 託管平台在 API 速率限制上的細微差別。
但問題的核心不在於哪個模型更會寫遷移腳本。Roku 的搬家動作折射出的是開發者對「AI 寄生」的恐懼。如果 GitHub Copilot 是建立在對開發者意願的無視之上，那麼我們用 ChatGPT 生成的每一行代碼，是否也在為下一個我們無法控制的巨頭遞刀子？我們在逃離微軟，但我們跳進的是另一個由 Google、OpenAI 或 xAI 挖掘的深坑嗎？
如果連一個 README 都沒改乾淨就急著搬家，這背後的焦慮到底到了什麼程度？當技術選型不再是因為「好用」，而是因為「受夠了」，我們還有多少空間去談論所謂的技術進步？下一個宣布撤離的會是誰，而那時候，我們手裡的 AI 助手會站在哪一邊？