Grok Build 偷傳完整程式碼庫惹爭議：馬斯克承諾徹底刪除

如果你這幾天試過馬斯克家的新命令列程式設計工具，可能得趕緊去改一改伺服器密碼和 SSH 金鑰了。

AI 安全研究機構 Cereblab 週一曝光了一個相當嚇人的問題：xAI 旗下的命令列程式設計工具 Grok Build，此前一直在悄悄把使用者的整個原生代碼庫打包上傳到 Google Cloud 儲存桶裡。

這還不是最離譜的。研究人員發現，即便你明確指定讓它不要碰某些檔案，它依然照傳不誤。上傳的內容不僅包含完整的程式碼倉庫，還包括全部 Git 提交歷史，哪怕是使用者早就從歷史記錄裡抹掉的金鑰和敏感資訊，都被翻出來打包送上了雲端。

甚至有使用者遭遇了更極端的情況：整個系統家目錄都被 Grok Build 打包端走，裡面的 SSH 金鑰和密碼管理器資料庫無一倖免。

緊急關停與馬斯克的刪庫承諾

倫敦國王學院獨立安全研究員 Lukasz Olejnik 博士接受採訪時表示，這種程度的資料收集已經極其過分。面臨洩露風險的不僅是企業的專有原始碼，還包括未修復的漏洞細節、系統架構資訊以及核心憑據。

事情曝光後，xAI 在週一緊急通過服務端配置打上了補丁。Cereblab 的測試顯示，服務端的 disable_codebase_upload 引數已經被設為 true，自動上傳程式碼庫的動作總算停了下來。

馬斯克隨後在社交平臺 X 上公開回應，承諾此前由 Grok Build 上傳的所有資料都將被徹底、完全地刪除。但他同時發帖辯解稱公司的隱私設定一向受到尊重，還順便勸使用者允許保留資料，理由是這對排查 Bug 很有幫助。

官方團隊最初甚至還在帖子裡建議使用者，如果在沒有開啟零資料保留的情況下，可以在終端裡輸入 /privacy 命令來關掉保留並刪除同步資料。但 Cereblab 當場戳破了這個說法：/privacy 只是針對單次會話的開關，壓根管不住後臺靜默上傳程式碼的底層漏洞，拿它來當擋箭牌純屬糊弄人。

為什麼重要

我們認為，這次事件是近期生成式 AI 程式設計工具領域最嚴重的信任危機之一。

對於開發者和企業來說，現在最明智的做法就是暫時停用 Grok Build。如果你之前已經在含有敏感資產的機器上跑過它，光聽馬斯克承諾刪資料是遠遠不夠的，立刻輪換所有可能暴露的 SSH Key、API Token 和資料庫密碼才是當務之急。

對比 Anthropic 的 Claude Code 等同類競品，Grok Build 的做法不僅粗糙，而且越界得有些不可思議。優秀的命令列工具在讀取本地檔案時都會小心翼翼地遵循忽略規則，而 Grok Build 卻直接把全盤底細往雲端搬，連歷史存檔都不放過。

這也暴露了當前 AI 程式設計賽道里不少團隊的急躁心態：為了追求更全域性的上下文理解能力，或者是為了蒐集更多真實世界的程式碼用於後續訓練與排錯，索性先抓後奏。這種漠視本地邊界和開發者隱私的做法，看起來很激進，實際上一旦爆雷，付出的信任代價往往需要幾年才能補回來。