Google Antigravity

為什麼選擇 Google Antigravity？

當開發流程正在從單次 prompts 轉向協調式 agent work 時，Google Antigravity 最有吸引力。它的核心想法是，AI coding tool 不應只是坐在聊天側邊欄裡，而應該有專門的操作介面，讓 agents 能規劃、建置、測試、驗證並回報進度，同時由開發者監督結果。

這讓 Antigravity 與傳統 AI IDE 不同。Editor 只是產品的一部分。獨立 desktop app、Manager surface、artifacts、browser control、terminal access、CLI、SDK，以及 Google 生態系整合，都圍繞同一種模式設計：委派任務級工作、觀察進度、審查證據，並在需要時介入。

核心工作流程

實用的 Antigravity 工作流程，應該從可驗證的任務開始。不要要求模糊的改善，而是定義想要的行為、目標檔案或 app 區域、acceptance criteria、test command，以及 agent 是否可以使用 browser 或 terminal。接著 agent 可以建立計畫、修改 codebase、執行 commands、測試結果，並產生 artifacts 來摘要發生了什麼。

對長時間工作來說，Manager surface 是關鍵差異。開發者可以把 agents 分派到不同 workspaces，讓它們平行執行，並透過 deliverables 而不是 raw logs 來審查每個任務。這很有用，但也會改變開發者的角色。開發者更像 reviewer、task designer 和 safety gatekeeper，而不只是手動輸入每個修改的人。

使用場景

Antigravity 適合 code、terminal 與 browser verification 都很重要的多步驟軟體任務。例如新增功能、修復 UI bug、重現 issue、產生 test case、測試 web flow、整合 Firebase、從 Google AI Studio 匯出到本機開發，或從 prompt 建立 Android prototype。

它也適合 background maintenance。Scheduled Tasks 與 parallel agents 可以協助週期性 cleanup、dependency work、triage、documentation updates 與 issue reproduction。不過，這些工作流程應逐步導入，因為自主工具存取套用在重要 repositories 或本機檔案上時，可能帶來實際風險。

與替代工具比較

與 Cursor 和 Windsurf 相比，Antigravity 更明確地偏向 agent-first。Cursor 與 Windsurf 是適合互動式 coding、inline changes 與 codebase chat 的強大 AI editors。Antigravity 則更重視 orchestration：multiple agents、Manager surface、artifacts、browser recordings，以及 Google-native agent harness。

與 Claude Code、Codex CLI、OpenCode 或 Aider 相比，Antigravity 不是 terminal-minimal，而是更 platform-oriented。CLI agents 適合希望本機、直接、provider-flexible 控制的開發者。當工作流程受益於圖形化 command center、verification artifacts、browser control 與 Google 生態系整合時，Antigravity 會更有吸引力。

與 Replit AI、Bolt.new 或 Lovable 相比，Antigravity 不只是簡單的 prompt-to-app builder，而更像 agentic development environment。它能幫助把想法變成 app，但更強的定位是監督在既有開發流程中工作的 agents。

最佳設定

最安全的設定從 project isolation 開始。使用獨立 workspaces、乾淨的 Git branches、backups，以及範圍狹窄的 file access settings。對敏感專案啟用更嚴格的 security controls，謹慎設定 outside-folder access，並在 agents 需要 web access 時使用 browser allowlists 或 denylists。

模型選擇方面，iteration 與 debugging 可使用較快的 Gemini models；當 quota 與 plan access 允許時，把更強或 third-party models 保留給較難的 reasoning tasks。團隊應標準化 agents 何時可以執行 terminal commands、何時可以碰 project 外的 files、什麼算 acceptable evidence，以及在 merge 或 deploy changes 之前由誰審查 artifacts。

遷移注意事項

從 Gemini CLI 遷移的開發者應先評估 Antigravity CLI，再判斷 desktop Manager surface 是否帶來足夠價值。從 Cursor 或 Windsurf 遷移的開發者，應在需要 browser verification 與 parallel background tasks 的工作流程上測試 Antigravity，而不只是測 inline edits。那才是產品最有差異化的地方。

團隊導入方面，最佳路徑是 controlled pilot。使用一個非關鍵 repository，定義安全任務，要求人為審查 diffs 與 artifacts，並記錄 agent 成功與過度行動的情況。在 production usage 之前，團隊應先確認 backup practices、permission rules、sandbox defaults、project isolation、rate-limit expectations，以及 Google Cloud 或 enterprise account terms。