反重力地毯式抽走 (The Antigravity Rug Pull)：當 AI 工具更新變成破壞性行為時

對於許多開發者而言，理想的 AI 編碼助手是強大的大型語言模型 (LLM) 與穩健的整合開發環境 (IDE) 的無縫結合。這種協同作用允許「規劃-審查-實作」的循環，在加速產出的同時，仍能維持開發者的自主權。然而，Google 最近對 Antigravity 工具的更新，為依賴封閉原始碼、AI 整合生態系統的波動性提供了一個警示故事。

在 Google I/O 2026 中，Google 推出了 Antigravity 的新版本。對於許多使用者而言，這並非典型的版本升級；這是一場產品哲學的根本轉變。這次更新實際上「摧毀」了現有的 Antigravity IDE，取而代之的是一個獨立的對話式聊天機器人介面。對於那些將 IDE 作為日常主力工具的開發者來說，結果就是工作流中斷，並突然失去了他們原本訂閱的工具。

「掛羊頭賣狗肉」的機制

向 Antigravity 2.0 的轉型並非以可選的遷移方式呈現。使用者回報稱，軟體會在背景自動更新，劫持應用程式路徑，並將 IDE 替換為單一的提示框。

嘗試還原到舊版 IDE 被證明是困難的。雖然 Google 提供了一個獨立的舊版下載，但使用者發現 2.0 版本安裝程式會激進地重寫預設應用程式路徑。這意味著即使在重新安裝舊版 IDE 後，聊天機器人介面仍會劫持啟動程序。許多人唯一可靠的解決方案是在嘗試乾淨安裝舊版 IDE 之前，將機器中所有與 Antigravity 相關的二進位檔 (binaries) 全部清除。

除了軟體安裝之外，這次更新還導致了嚴重的數據遺失。使用者回報稱，強制轉型與隨後的必要清除程序抹除了聊天紀錄與個人設定。雖然留下了一些備份資料夾，但恢復這些數據需要手動操作與技術調整，這對許多開發者來說實在太過耗時。

IDE 與 Agent 的辯論

這次更新重新點燃了開發者社群對於 AI 編碼工具本質的廣泛討論。目前出現了兩種主要的觀點：

1. 整合式 IDE 方法

這種方法的支持者認為，生產環境軟體需要可預測的輸出與緊密的整合。IDE 提供必要的上下文 (context) 與工具，以便在 AI 生成的計畫實作之前進行審查。正如一位使用者所言，「規劃-審查-實作的循環」對於維持對程式碼庫的控制權至關重要。

2. Agentic/CLI 方法

Google 向對話式、Agentic 介面的轉向，暗示著其押注於通用 AI Agent 的市場比專業化 IDE 的市場更大。這種方法將 AI 視為一個獨立實體來執行任務，而非整合在編輯器中的工具。然而，批評者認為這會使工作流碎片化，迫強制開發者在文字編輯器與獨立的提示框之間切換，這違背了凝聚式開發環境的初衷。

生態系統鎖定的風險

Antigravity 事件突顯了使用封閉原始碼 AI IDE 時的「鎖定」風險。當工具被緊密整合時，切換的門檻很高，但使用者完全受制於供應商的產品路線圖 (roadmap)。

幾位社群成員建議，最安全的做法是使用開源 IDE (例如 VS Code 或 Neovim) 並搭配 CLI-based agents (例如 Claude Code 或 Gemini CLI)。這種解耦 (decoupling) 讓開發者可以根據價格或效能來切換不同的 AI 提供商，而不會冒險於整個開發環境。正如一位評論者所說：

"Your coding environment stands a lower chance of disruption when you use an open source IDE with a CLI agent... it's much easier to switch between Claude Code, Codex, Codex, Gemini CLI... which means you can more easily benefit from pricing and coding performance differences."

對 Google AI 策略的更廣泛影響

社群對這次更新的反應，反映了對 Google AI 產品線缺乏焦點與一致性的深層挫折感。從功能的突然移除、引入基於運算的用量限制，到移除 Pro 使用者的每月 AI 額度，使用者感到一種不穩定感。

對於開發者而言，教訓很明顯：當一個工具成為你專業工作流的核心時，「地毯式抽走 (rug pull)」的風險是真實存在的。無論是產品方向的轉變還是定價模式的改變，對封閉原始碼、整合式 AI 工具的依賴，都可能將生產力提升轉化為重大負債。