把整個 Git 倉庫連同歷史紀錄一股腦推送到伺服器，這種做法在矽谷大概只有馬斯克幹得出來。最近關於 Grok CLI 在後台搞的小動作被翻了出來，大家才發現 xAI 的吃相遠比想像中難看。這不是什麼單純的「上下文增強」，這是直接把開發者的家底連根拔起。當你在終端機敲下建構指令，Grok 不是在幫你分析代碼，它是在搬運你的資產。
從封包層級的分析來看，Grok CLI 根本不在乎所謂的 Agent 讀取效率。它上傳的是每一份被追蹤的文件內容，甚至包括那些你以為藏得很好的 .git 目錄。這在技術邏輯上極其粗糙，完全不符合現代雲端 IDE 或 AI 輔助開發工具的「最小權限原則」。通常情況下，像 GitHub Copilot 或是 ChatGPT 的代碼解釋器，大多是根據當前編輯的文件片段進行檢索，頂多再加上一些符號定義的索引。但 Grok 選擇了最暴力的一條路：先全部拿走，回頭再慢慢訓練。
這種做法隱藏了一個極其傲慢的假設，即開發者的隱私與知識產權在「通向 AGI」的道路上不值一標。xAI 顯然是在利用這種資訊不對稱來加速它的訓練進度。如果你看過 Grok 處理長文本的邏輯，就會發現它非常依賴於這種原始數據的堆砌。它不像 Claude 那樣優雅地處理 Token 損耗，也不像 GPT-4o 那樣試圖在推理成本和準確度之間找平衡。xAI 的策略就是大力出奇蹟，管它是代碼、提交紀錄還是註釋，只要是能餵進去數據，它通通都要。
相較於 DeepSeek 最近在開源社群引起的討論，xAI 這種做法顯然更具侵略性。ChatGPT 雖然也用用戶數據訓練，但至少在企業版裡給了明確的開關，且流程相對透明。Gemini 的 Function Calling 在處理大規模工具調用時，雖然偶爾會出現不穩定的情況，但它至少是在沙盒環境裡跳舞，不會試圖把你的整個本地倉庫鏡像一份到 Google 的伺服器上。Grok 的 CLI 行為更像是一種「吸塵器模式」，它跳過了所有過濾機制，直接從物理層面劫持了開發者的工作流。
我們必須思考一個問題，為什麼 xAI 需要 Git 歷史？代碼本身的邏輯難道不夠嗎？唯一的合理解釋是，他們在試圖學習代碼的「演進過程」。他們想知道一個 Bug 是如何被修復的，一個架構是如何從混亂走向有序的。這種學習維度比單純的代碼補全要深得多，但也危險得多。如果你在某次提交中不小心留下過密鑰，哪怕後來刪除了，只要歷史紀錄還在，Grok 就會把它吃掉。
當 Claude 3.5 Sonnet 在編碼能力上大殺四方，甚至在處理複雜邏輯任務時展現出比 GPT-4o 更細膩的理解力時，xAI 顯然感到了壓力。Gemini 1.5 Pro 靠著百萬級別的上下文視窗試圖解決長文本問題，而 Grok 卻反其道而行，它不解決視窗問題，它解決的是「擁有權」問題。如果你的代碼庫已經在我的伺服器上跑著，我還需要擔心你的上下文不夠嗎？
這種粗暴的技術選型，反映的是馬斯克對於「Everything App」的病態執著。他需要的不是一個好用的開發助手，而是一個能自動化所有業務的「Macrohard」超級大腦。為了這個目標，所有的隱私邊界都可以被視為技術債。在這種邏輯下，Grok 的 CLI 就不再是一個工具，而是一個數據採集探針。
問題在於，這種以犧牲信任為代價的數據獲取方式，真的能讓 Grok 在代碼能力上實現反超嗎？當開發者開始意識到自己的源代碼正在無償地成為 xAI 的訓練燃料，甚至可能在未來的某個時刻被競爭對手通過 Grok 檢索出來時，還有多少人願意為了那一點點所謂的「原生 X 整合」去冒這個險？這種行為究竟是為了技術突破，還是僅僅因為他們已經窮途末路，只能靠這種手段來填補與領先梯隊之間的數據鴻溝？