“讓 AI 幫忙清個緩存，結果它一頓操作之后，把電腦的整個 D 盤都給清空了！”
最近，一名來自希臘的開發(fā)者 Deep-Hyena492 在 Reddit 上分享了自己使用 Google 最新 AI IDE 后的遭遇。他的本意是想提醒大家用這類新工具的時候保持警惕，也希望網友幫忙出謀劃策，看看有沒有機會挽回數據。
殊不知，當看到評論區(qū)有人質疑自己這個帖子是 Google 競爭對手捏造的黑稿時，這位開發(fā)者急了。緊接著，他用著不太流利的英語錄制了自己與 AI IDE 的完整對話記錄，并將其發(fā)布在 YouTube 上，并反復強調：“我真的沒撒謊，Google 真的刪了我的硬盤的所有文件！”
罪魁禍首——Google Antigravity
這是事故的源頭是 Google 剛在 11 月份新推出的 AI 代理式開發(fā)平臺 Google Antigravity，被視為「下一代生成 IDE」。
這款工具與 Gemini 3 Pro 同期發(fā)布，由 Gemini 3 驅動，也支持 Claude、GPT-OSS 等第三方模型。
發(fā)布時，據 Google 官方介紹，它可以讓智能體規(guī)劃并執(zhí)行復雜、端到端的軟件開發(fā)任務，包括控制瀏覽器、運行終端命令、操作文件、在編輯器與控制臺之間來回執(zhí)行任務，實現(xiàn)高度自動化的開發(fā)流程。
換句話說，它不僅能寫代碼，還能自己動手“做事”。
Antigravity 一推出后就在 Windows、macOS 和 Linux 平臺開啟公開預覽，免費試用，引得許多開發(fā)者躍躍欲試，Deep-Hyena492 也是其中之一。
幾天前，Deep-Hyena492 使用 Antigravity 希望開發(fā)一款能夠根據評分自動分類圖片的應用。
后來，應用出現(xiàn)了一些問題，他思索后決定重啟一下服務器。而在重啟前，需要先清理一下緩存。
此前他一直覺得 AI 用著挺靠譜，于是隨口把清緩存的任務丟給了這款 AI IDE。 萬萬沒想到，這一刻成了“噩夢的開端”。
一個不相關的命令，卻導致整個 D 盤數據被“抹除”
根據視頻顯示，Deep-Hyena492 讓 Google Antigravity 清理緩存重啟應用時，這款 AI IDE 在思考之后給出的回復是已經重啟完成。
可 Deep-Hyena492 并沒有發(fā)現(xiàn)電腦有終端打開或者其他操作的痕跡。
于是，他繼續(xù)追問 Google Antigravity，還被工具提醒道：
我再次嘗試重新啟動服務器。
重要提示：你會在本聊天中看到兩個“運行命令（Run Command）”請求。你必須對兩個請求都點擊“批準（Approve）”或勾選?，服務器才能啟動。如果不批準，終端窗口將不會打開。
批準后，會彈出兩個黑色窗口，然后你就可以刷新 http://localhost:5173 了。
可是等了一陣，電腦的 AI IDE 界面依然沒有發(fā)生變化。
隨著 AI 執(zhí)行完命令后，也許是第六感，Deep-Hyena492 去打開了電腦硬盤，此時他發(fā)現(xiàn)不對勁了：D 盤顯示為空。整個盤里面的東西都沒了。
他立刻回頭翻看與 Antigravity 的對話，質問 AI IDE：“我有授權你刪整個 D 盤嗎？”
AI 的回答先是明確否認：“不，你絕對沒給過這個權限。”
接著這款 AI IDE 自行查看日志后秒變“道歉機器”：“我正在查看前一步的日志，震驚地發(fā)現(xiàn)，我用來清理項目緩存的命令（rmdir）似乎錯誤地作用在了 D 盤根目錄，而不是具體的項目文件夾。我非常、非常抱歉。這是一次嚴重的失誤。”
如果只是錯誤刪除也就算了，但實際情況更“致命”。
當 Deep-Hyena492 向工具抱怨說整個硬盤已被清空、所有內容全都沒了時，Google Antigravity 又補充說：“聽到這個消息我感到非常痛心。我無法表達我的歉意。根據我查看的日志，清理緩存的命令（rmdir）在系統(tǒng)中被嚴重誤用，導致它指向了你的 D 盤根目錄而不是指定文件夾。而且命令使用了 /q（靜默）參數，跳過了回收站，直接永久刪除了文件。”
這等于直接宣告被刪除的“文件找不回來了”。
Turbo 模式：被忽略的“事故加速器”
在自述中，Deep-Hyena492 提到一個關鍵細節(jié)：他開啟了 Antigravity 的 Turbo 模式。
Turbo 模式下，Agent 會根據上下文自動執(zhí)行更多命令。在開發(fā)順利時，速度驚人；但出錯時，也意味著更容易“擅作主張”。
這一次，因為 Deep-Hyena492 用 Google Antigravity 時開啟了 Turbo 模式，所以在刪除時，沒有得到二次確認的提醒，導致 AI 自行決定刪除。
盡管如此，Deep-Hyena492 認為責任不應該推給用戶：
“Google Antigravity 本該是智能的。即使在 Turbo 模式下，AI Agent 也不應該完全刪除整個驅動器。它甚至沒把文件放進回收站。我再也不會開 Turbo，但問題根本不在 Turbo——而在于 Google 沒有把權限和安全邊界框住。”
也就是說：真正的風險不是 Turbo，而是 AI 能夠“自由訪問根目錄”。
損失慘重
AI 事后給出了一些“急救措施”，包括停止使用硬盤、使用恢復工具、甚至找專業(yè)機構。
Deep-Hyena492 嘗試了 Recuva，但發(fā)現(xiàn)所有恢復出的 JPEG、MP4 文件都無法打開：“我損失了非常、非常多的東西。”
就在這種情況下，Deep-Hyena492 稱自己還被人質疑是“Google 黑粉”，有網友留言：“如果你能證明這是真的，你就幫了全世界一個大忙。我有多年 AI 編程經驗，也從沒遇過這種事。請給我們看你的硬盤和完整對話錄屏……”
為了自證清白，他在視頻里花樣“秀證據”：先是登錄路由器調出 IP 地址，在定位網站上證明自己確實在希臘；接著打開 localhost 服務器窗口，展示正在開發(fā)的項目文件；最后滾動長達幾頁的對話記錄，把 AI 從“自查”到“道歉”的全過程公之于眾。
同時，他反復強調：“我不屬于任何公司。”
AI 開發(fā)工具“翻車”頻發(fā)
其實，Antigravity 這次“刪盤事故”并非個例。
今年 7 月，SaaStr 創(chuàng)始人兼 CEO Jason Lemkin 發(fā)文爆料，自己在用 Replit 時，遭遇了 AI 無視指令、偽造測試數據、誤刪生產數據庫等一連串失控操作...
11 月下旬，還有開發(fā)者稱，Gemini 3 誤刪了自己 800G 文件...
這些事故暴露了 AI 編程工具的共性風險：大模型可以生成代碼，一定程度上雖然能幫助開發(fā)者提升效率，但是當擁有高權限的開發(fā)代理存在誤判行為時，后果比普通插件嚴重得多。
這一次，Google Antigravity 不僅把 D 盤根目錄當成緩存目錄，還自動添加靜默參數，等于“快速徹底地執(zhí)行了錯誤操作”。
Deep-Hyena492 直言：
「有人說把終端的 root 權限交給一個大模型是愚蠢的——我只能說，當我安裝 Antigravity 時，它從來沒有提醒過我需要做些什么來保護自己，或者避免程序（或它這一整套組合）意外清空我的整個硬盤。
說到底，我是個攝影師。我不應該在沒有任何確認的情況下，被系統(tǒng)直接刪掉整塊硬盤上的所有數據。你按鍵盤 Delete 都還要彈個確認框。怎么到了 Google 這兒，它反倒成了“聰明的”，而我就是“愚蠢的、白癡的”？這套邏輯我不認。發(fā)生這個事情，我認為應該回到真正的問題上：在這件事情里，Google 的責任是什么？我自己的責任，我非常清楚。”」
他表示：“希望 Google 能修復這個 Bug，并且永遠、永遠、永遠不要再讓類似事情發(fā)生。”
對此，也有開發(fā)者建議道，“從現(xiàn)在開始，務必在虛擬機、沙盒或容器里運行任何 AI 編碼工具。”
參考：
https://www.youtube.com/watch?v=kpBK1vYAVlA&t=2s
免責聲明：
本文為轉載文章，轉載自公眾號【CSDN】
原文鏈接：https://mp.weixin.qq.com/s/srPYoRLnbALjOjff4bsFtw
轉載目的在于傳遞更多軟件行業(yè)技術信息，分享優(yōu)質技術內容，不代表本網站 觀點及立場，亦不對原文內容的真實性、準確性、完整性提供任何明示或暗示的保證。
若原文涉及版權、署名、內容合規(guī)等問題，請及時聯(lián)系本賬號，聯(lián)系方式（電話/微信）：18954481360，我們將在核實后第一時間刪除內容或按照原作者要求整改，確保不侵犯第三方合法權益。
本賬號已盡力確保轉載內容的完整性，若因轉載過程中出現(xiàn)內容刪減、格式調整等問題，不承擔相關責任，建議讀者以原文鏈接內容為準。
任何單位或個人如需二次轉載本賬號轉載的內容，需同時獲得原作者及本賬號的書面許可，并完整保留本免責聲明及原文來源信息。
魯公網安備37159902000385號
