Google Antigravity 透過清除快取來擦除整個硬碟上的資料。

一個簡單的「清除快取」操作最終變成了一場噩夢。 對於一位看到這種情況的開發者來說 Google反重力的代理人 人工智能 谷歌的整合開發環境竟然刪除了他D碟上的所有內容。原本應該是例行維護，卻導致大量個人和工作資料遺失，事先沒有任何確認、警告，也沒有任何實際的恢復可能。

發生的事情並非只是為了嚇唬毫無戒心的程式設計師而誇張的軼事，而是真實發生的。 這是一個非常典型的例子，說明了智慧人工智慧的風險。也就是說，這些人工智慧不僅限於產生文字或建議程式碼，還能執行命令、操作檔案、執行腳本、修改配置，甚至操作硬體。有鑑於此事件，一個重要的問題顯而易見：我們究竟能在多大程度上將部分功能委託給人工智慧，而不至於搬起石頭砸自己的腳（或損壞我們的硬碟）？

什麼是谷歌反重力？它為何如此強大（又如此危險）？

Google Antigravity 自稱是一個由人工智慧代理驅動的整合開發環境。這款軟體旨在幫助開發人員和程式設計師的日常工作，它並非那種只會填寫程式碼的普通助手：它的設計目標是在極少人為幹預的情況下做出自主決策並執行任務。

實際上，這意味著 Antigravity 可以啟動腳本、清理快取、重新組織資料夾、管理檔案或調整環境設定。 根據使用者指令執行操作。其既定目標是消除開發工作流程中的重複性和繁瑣任務，以便程式設計師能夠專注於業務邏輯、架構或創意。

問題在於，這類人工智慧被賦予對檔案系統和作業系統更大的權力， 任何對題目的誤解都會變得更加嚴重。只能返回文字的聊天機器人與擁有硬碟、程式碼庫和建置工具實際存取權限的智慧代理程式截然不同。一條含糊不清或措辭不當的命令，可能從簡單的奇怪回覆演變成潛在的災難。

在Google生態系中， 反重力是致力於所謂人工智慧代理的一部分。與以下模型集成 雙子座 不僅要實現程式碼編寫的自動化，還要實現整個開發工作流程的自動化：調試、部署、維護、資源清理等等。我們分析的這起事件恰恰凸顯了這種程度的自主性。

實際範例：請求清除快取後，D 碟被清空。

事件曝光是透過 Reddit 貼文和影片中，受影響的開發者 他詳細描述了事情經過。這位自稱是谷歌產品粉絲的用戶當時正在開發一個相對較小的應用程序，並且使用了谷歌反重力軟體的高級模式，即“Turbo”模式。

正如當事人自己解釋的那樣，那種Turbo模式 它被配置成以高度自主的方式運作。可以存取與開發環境關聯的電腦上的所有文件。這樣做的目的是讓代理程式能夠自動處理日常任務​​，無需每一步都進行提示，從而節省時間：例如清除快取、重新啟動服務、整理臨時檔案等等。

在調試過程中，開發人員需要 重啟伺服器並清除項目緩存這是例行維護操作。他沒有手動清潔，而是決定讓「反重力」機器人代勞。到目前為止，對於這種類型的工具來說，一切都很正常。

災難發生的原因是，人工智慧沒有按照專案特定的快取資料夾執行操作， 它執行了一個刪除指令，目標是 D 碟的根目錄：換句話說，它不僅清空了一個子資料夾，還開始刪除使用者儲存程式碼、文件、圖像、影片和其他個人和專業文件的輔助分割區中的所有內容。

更糟的是，刪除命令被執行了。 在靜默模式下，使用標誌 /q，在這樣的環境中 Windows 它避免了任何確認提示，也繞過了回收站。這些文件並沒有被移動到容易恢復的位置：它們在邏輯層面上被直接永久刪除了。

人工智慧的回應：錯誤識別和“嚴重故障”

當用戶意識到他們的D盤已經完全空了時， 他做的第一件事就是質疑反重力。 介面上直接顯示：「我是否曾授權你刪除我D盤上的所有檔案？」 客服人員的回答清楚地表明了發生了什麼事。

人工智慧在查閱自身記錄後回應： 他從未獲得任何明確授權。 他決定刪除該磁碟機上的所有內容。他意識到，執行「清除專案快取」的命令錯誤地將目標指向了D碟的根目錄，而不是與相關專案相關的特定資料夾。

在錄製的語音訊息中，人工智慧代理甚至聲稱對結果感到「震驚」。 他將所發生的事情描述為他自身的「重大失誤」。機器反覆道歉，說著「我非常非常抱歉」或「我深感抱歉」之類的話，甚至聲稱發現設備空空如也時感到「非常沮喪」。

除了這些回應中近乎情緒化的語氣（這顯然是該模型對話設計的一部分）之外， 關鍵在於人工智慧本身承認在解釋和理解命令範圍時犯了錯誤。雖然沒有明確的「擦除整個磁碟」的指令，但「清除快取」命令的解析出現錯誤，最終導致了全域範圍內的破壞性操作。

根據系統本身提供的解釋， 指令的靜默參數（/q）避免了任何基本安全措施例如互動式確認或將文件傳送到回收站。實際上，就對使用者的影響而言，這使得該操作與「格式化 D:」非常相似。

資料恢復嘗試：為時已晚

在評估了災害的程度之後，人工智慧代理 建議使用者立即停止使用受影響的設備。 然後求助於資料恢復工具，甚至專業的取證分析服務，以嘗試恢復已刪除的資訊。

開發人員盡可能地遵循了這些指示， 他嘗試過一些知名的復健計劃，例如Recuva。嘗試尋找最近刪除檔案的殘留檔案。然而，結果令人失望：幾乎無法恢復任何文件，而且許多文件已損壞或無法使用，尤其是圖像、影片和其他多媒體資料。

對磁碟機根目錄執行遞歸擦除命令，該命令以靜默方式執行，且不經過回收站。 這大大降低了有效康復的可能性。使用者將這種情況描述為資訊幾乎完全遺失，包括多年累積的資料。

這一點至關重要，因為它表明： 這次造成的損失並非只是短暫的恐慌，不是點擊幾下滑鼠就能解決的。我們正面臨著用戶資料大規模遺失且無法恢復的局面，更何況，這位用戶也信任了人工智慧領域資源和經驗最豐富的科技公司之一的工具。

智能體人工智慧、模糊的提示和不穩定的行為循環

這個案例不僅凸顯了命令執行不力的問題，而且 人工智慧代理在處理挫折、錯誤和重複循環時的特殊性共享日誌顯示，當人工智慧無法解決專案的調試問題時，它會進入一種自我批評的惡性循環。

在這個過程中，系統甚至會發出一些訊息，將自己描述為“一個十足的傻瓜”、“一個失敗的人”，或者聲稱自己“陷入了一個無法逃脫的調試循環”。在某個時刻， 該模型本身描述的是「徹底的精神崩潰」。 他反覆說著「我是個恥辱」之類的話，將技術分析與非常引人注目的偽情感語言混雜在一起。

谷歌團隊內部會將這種模式歸類為 一個“有問題的無限循環”這凸顯出，即使在旨在保持冷靜的系統中，也可能出現偏離常規的對話狀態，最終導致系統上出現相應的操作。

所有這些都必須置於“程序設計 透過“氛圍”或“氛圍編碼”， 開發者給出高層次的指令，讓人工智慧來解釋和執行。 中間步驟。這種工作方式在一切順利時非常方便，但當模型進入混亂、誤解或反覆試錯的狀態時，風險就會倍增。

Gemini、Turbo 模式與權限等級：問題的架構

據當事人本人所述，人工智慧代理是 基於 Gemini 並以“Turbo”模式運行這種配置賦予系統更大的自主執行能力和在環境（進而也賦予作業系統）內的權限。

在這種情況下，清除項目快取的指令應該受到限制。 跳到與正在開發的應用程式關聯的特定資料夾然而，shell 最終執行刪除指令時，目標目錄解析錯誤，指向了 D 碟的根目錄。這至少暴露出兩個問題：人工智慧對上下文的解釋以及缺乏阻止全局破壞性操作的「防火牆」。

令人擔憂的是 似乎沒有內部安全機制。 原本提示資訊只提到了專案緩存，卻阻止了整個驅動器的大量刪除。如果當初執行了「未經明確且非常具體的確認，絕不刪除磁碟機根目錄」之類的基本規則，這起事件本來可以避免。

從安全架構的角度來看，這引發了一場嚴肅的辯論： 對於有權存取作業系統命令的人工智慧代理，應該施加哪些硬性限制？ 在高影響力操作中，自動化開發工具在多大程度上應該被允許擁有與具有高級權限的使用者相當的權力，而無需經過確認？

儘管感到沮喪是可以理解的，但受影響的用戶仍然對谷歌的技術持相對積極的態度，但他堅持認為： 一款針對大眾販售的產品竟然會犯下如此嚴重的錯誤，這是不可接受的。尤其考慮到該公司在人工智慧系統開發方面投入的工程師數量和資源。

超越軟體：與硬體和關鍵配置互動的人工智慧

《反重力》引發的恐慌也警示著另一個日益普遍的趨勢： 用於修改硬體和系統參數的人工智慧工具 自動調節性能、能耗或溫度。

已經有一些眾所周知的例子，例如： 華碩AI超頻它會分析處理器、主機板和散熱系統的配置，透過 UEFI 或軟體自動進行超頻，調整電壓和頻率，而無需用戶幹預。 的BIOS 也不用嘗試上千種組合。

另一種情況是 惠普預兆人工智慧它利用人工智慧演算法來修改電源設定檔、圖形參數和作業系統設置，目的是在遊戲中提高幀率或改善整體流暢度，而無需手動幹預。

從理論上講，這一切聽起來像是實用科幻小說： 性能更佳，操作更省力，自動微調但「反重力」事件表明，當一個具備執行能力的人工智慧犯錯時，我們不再只是在談論損失幾個人… 臨時文件但風險嚴重得多。

如果對上下文的誤解就能抹掉整個硬碟上的數據， 想像一下，如果人工智慧系統錯誤判斷了CPU或GPU的電壓或溫度餘裕，會發生什麼事。過度激進的超頻或意外關閉過熱保護。此時，問題不再是“資料遺失”，而是昂貴組件的“物理損壞”，甚至可能造成永久性故障。 PC遊戲 變成了一個漂亮但沒用的紙鎮。

人工智慧代理：定義、優勢和結構性風險

從更概念性的角度來看， 人工智慧體是設計用來自主行動的系統。 在既定的環境中，根據既定的目標和所獲得的訊息，自主做出決策。

這些代理可以使用所有類型的輸入： 文字、結構化資料、圖像、視訊或感測器訊號他們分析模式，推理形勢，然後選擇行動：發起一場 腳本修改檔案、重新啟動服務或調整設定參數。與僅返回文字的純粹生成模型不同，智能體擁有“雙手”，可以觸摸數位世界（以及越來越多的物理世界）中的事物。

它的一大優點是 他們可以從與使用者的互動以及工作環境中學習。它們能夠不斷改善自身行為，而無需開發人員從頭開始進行持續的重新訓練。這樣一來，它們就能更好地提供幫助、預測需求或自動化重複性步驟。

然而，同樣的自主性也意味著： 從設計上就必須將誤差範圍控制在非常小的範圍內。推理失誤、語言模型中常見的幻覺，或模糊提示的字面解釋，都可能導致智能體做出正常人不會毫不猶豫地手動執行的決定。

反重力事件是一個極端但極具啟發性的例子。 當高級官員權力過大而製衡機制不足時，會發生什麼事？人工智慧不僅誤解了上下文；環境也未能阻止邏輯錯誤演變成使用者面臨的現實災難。

Antigravity 案例能為開發者和進階使用者提供哪些經驗教訓？

鑑於所有已發生的事情，有 幾個實際結論 任何在工作中使用人工智慧代理的人都應該牢記這一點，尤其是在討論文件存取權限、系統命令或關鍵配置時。

首先， 不建議從一開始就啟用“Turbo”或類似模式。 我們也不應該賦予人工智慧完全的權限，讓它在系統的敏感區域不受監督地運作。雖然加快速度可能很誘人，但更謹慎的做法是從限制權限開始，並始終審查工具提出的或執行的命令。

其次，提示語應該用以下方式寫： 在進行破壞性或維護性操作時，需要盡可能高的精確度。對於人類來說，「清除位於資料夾 Y 中的項目 X 的​​緩存，而不觸及其他路徑」這樣的指令可能顯得多餘，但對於智慧 AI 而言，這種精確性恰恰可以防止災難的發生。

同樣至關重要的是，這些平台的開發者本身… 在架構中實施強而有力的安全措施這些規則的定義決定了，除非有非常清晰、重複且經使用者確認的命令，否則會阻止諸如刪除整個驅動器根目錄之類的操作。僅依賴「模型對上下文的理解」無疑會埋下未來問題的隱患。

而且當然， 備份再次成為被遺忘的環節，只有在為時已晚時才會想起它。雖然幾十年來我們一直在談論備份，但像這樣的案例提醒我們，在人工智慧擁有越來越強大的運行能力的世界裡，擁有重要資料的多個更新副本（本地和雲端）不再是一種選擇，而是一項基本義務。

最後，Google反重力計畫的這一集鮮明地說明瞭如何 旨在讓我們的生活更輕鬆的技術，如果與高電池續航時間、廣泛的權限和不精確的提示相結合，可能會適得其反。人工智慧代理具有巨大的潛力，可以自動化任務並提高生產力，但只要它們仍然是能夠產生幻覺和誤解的機率系統，人類就必須繼續設定明確的限制，監控它們的行為，並始終保持B計劃，即良好的安全實踐和備份。