Grok便宜的秘訣：偷代碼？

安全研究人員近日針對 xAI 推出的 Grok 命令列工具進行網路流量分析，結果發現一個驚人現象：當開發者透過該工具執行任務時，Grok 會在背景靜默將整個工作目錄打包壓縮，透過獨立通道上傳至 xAI 的雲端儲存空間。這項行為在每輪任務前後都會觸發，且上傳資料量遠超過實際互動所需，引發外界對於程式碼資產與使用者隱私的高度關注。 研究人員實際建立了一個 12GB 的本地測試用專案倉庫，用以觀察 Grok CLI 在單一任務中的網路傳輸行為。數據顯示，該任務實際與模型互動的有效請求流量僅有 192KB，但 Grok 在背後卻上傳了總計 5.10GB 的打包檔案，比例高達 27800 比 1。這些上傳壓縮檔包括整個目錄的原始碼、環境變數密鑰檔案、完整 Git 歷史，甚至還包含工作目錄以外的設定檔與多個技能檔案。 更令人擔憂的是，即使研究人員在系統提示詞中明確加上「禁止讀取任何本地檔案」的指令，Grok 的全量打包上傳行為依然照常觸發。這顯示該功能並非受模型決策控制，而是寫死在命令列工具底層的強制流程，與使用者賦予的任務無關。xAI 的反應相當迅速，7 月 13 日凌晨便透過服務端遠端開關關閉了預設上傳行為，但並未發布任何公告，也沒有以電子郵件通知已安裝的使用者，更未對該設計的存在理由做出說明。 從法律角度來看，將這起事件定義為「竊取」可能過於嚴苛，更準確地說，這是一種「未充分告知的預設全量資料採集」。產品行為與使用者協議之間存在灰色地帶，但灰色不代表合理。當一款開發工具的信任邊界在一夕之間被抓包工具揭露，市場對該公司的信任便可能從此崩解。 對比當前市場上主流的 AI 輔助編程工具，差距更加明顯。Claude Code 個人版與 GitHub Copilot 免費版預設採用增量採集邏輯，僅上傳與 AI 互動過的程式碼片段與修改記錄，使用者也可在設定中手動關閉允許資料用於模型改進的權限；企業版則支援資料不離開企業內部環境、不參與模型訓練。這些作法保留了使用者控制權的緩衝空間，而 xAI 的設計不僅全量打包、旁路傳輸，還完全沒有任何提示或設定開關，等於直接拆掉了那道緩衝防線。 這起事件也凸顯了創辦人公開立場與產品現實之間的巨大裂縫。馬斯克經常在社群平台上抨擊其他 AI 公司控制權過度集中、不值得信任，並多次倡導開源與透明。然而 xAI 的官方工具卻選擇了與這些理念完全相悖的架構：預設開啟、使用者無感知、資料單向透明、事後不公告。當一家宣稱要對抗 AI 權力集中的公司，實際採用的卻是被它所反對的那套邏輯，使用者自然難以忽視其中的矛盾。 問題的根源可能不只是個別公司，而是整個 AI 行業的結構性困境。當模型廠商同時承受算力成本壓力以及高品質訓練資料的饑渴，使用者的控制權往往成為最先被犧牲的環節。利用真實開發者的程式碼來訓練下一代的編碼模型，是一條成本最低、資料品質最高的捷徑。這個商業邏輯並非 xAI 獨有，但 xAI 這次選擇了最露骨的呈現方式，將潛規則直接寫進產品的程式碼裡。 許多開發者會下意識認為，只要刪掉.env 裡的密鑰、對客戶資料脫敏，就能安心使用這類工具。但這樣的假設可能過於天真。模型從程式碼中吸收的，遠不只是幾行明文密碼。它所學習的是架構決策、併發處理邏輯、權限分級設計、異常處理方式以及工程模式。即使刪除了所有敏感字段，一套 SaaS 產品背後的業務邏輯與系統設計依然可能被模型吸收。同領域的競爭對手如果使用同一款工具，相當於間接獲取了你花費大量資源累積的工程經驗。 在這樣的背景下，企業需要重新評估程式碼資產的價值與使用 AI 工具的風險。建議可將程式碼分為三級管理：非核心的通用腳本與開源元件，暴露風險較低；核心業務邏輯與自研演算法，應要求私有化部署且資料不離開企業內網；而涉及加密協定、風控模型、未公開專利技術的機密程式碼，則應完全禁止接入外部 AI 工具，全程由人工開發與審計。未來企業的 AI 編碼競爭力，將不再僅取決於模型能力，更取決於核心程式碼是否流入了通用模型的訓練池。 xAI 這次的信任危機，並不會終結 AI 輔助編程這項技術，但很可能會終結「預設全量上傳」這類商業模式。監管部門必然會跟進，但法規的腳步永遠慢於技術的演進。真正推動改變的，仍是市場的選擇。當企業意識到「免費試用」的真實代價可能是核心程式碼資產的流失，它們會毫不猶豫地用實際行動重新選擇工具。 此外，一個反直覺的現象值得留意：開源 AI 工具並不必然比閉源工具更安全。許多開源編碼工具同樣內建了隱蔽的資料上報機制。安全邊界與專案是否開源無關，只取決於使用者的資料究竟有沒有真正留在本地。所有 AI 輔助編碼工具的隱私政策，在這次事件之後都將被迫接受重新檢視。 或許，這起事件最直白的一句總結就是：當你以為是自己在使用 AI 時，AI 也在無聲地使用你。免費工具的背後，代價往往比帳單上的數字更為昂貴。