前言：Agent-First 開發環境的興起
Google 推出的 Antigravity 是一款基於 VS Code 分支版本的全新 IDE，其核心理念為「Agent-First」。不同於傳統編輯器，Antigravity 主打讓 AI 代理人（Agents）在背景非同步處理任務，協助開發者進行代碼編寫與除錯。本文旨在剖析如何利用它與 Gemini AI Pro 進行高效協作，並將其與字節跳動推出的 Trae 以及 Anthropic 的 Claude Code 進行實戰對比，建立一套穩健的開發工作流。
馴服代碼規模：300 至 600 行的黃金法則
對於使用 React (tsx) 或 TypeScript (ts) 的開發者而言，檔案長度的控制是維持 AI 穩定性的關鍵。實戰經驗顯示，Antigravity 對於單個檔案的處理能力存在一個隱形的邊界，一旦程式碼超過 300 至 600 行這個區間，風險便隨之升高。
為什麼不能太多行？
當單一檔案的程式碼超過太多行時，Antigravity 的處理邏輯極易出現崩潰。這不僅導致任務無法完成，更可能破壞原本運作正常的結構，迫使開發者必須調用 git checkout HEAD 還原代碼。這種情況如同讓一位新手廚師同時處理過多訂單，最終導致廚房作業癱瘓。
技術推測：AST 解析與 RAG 檢索的雙重瓶頸
從技術角度分析，Antigravity 在處理長代碼時的不穩定，極可能源於 抽象語法樹 (AST) 分析過程的缺陷。
更深層的原因在於 檢索增強生成 (RAG) 策略在 Token 限制下的失效。當大型語言模型 (LLM) 接收的上下文過長，關鍵的語法結構資訊（AST 節點）容易被稀釋或截斷，導致 AI 失去對程式碼全貌的完整記憶，進而做出破壞性的修改。這也能解釋為何即便切換到 Claude Sonnet 模型問題依舊存在，但在官方的 Claude Code CLI 工具中卻未出現此問題。
分層協作法解決方案
面對長代碼或複雜邏輯，穩健的策略是採取「分而治之」的流程：
- 詢問思路 (Ask First)：首先要求 Antigravity 講述解決方案的理論架構，嚴禁其直接執行代碼修改。
- 外包執行 (Outsource)：
- 單檔處理：將思路與代碼上傳至 Gemini AI Pro (網頁版) 處理。
- 多檔重構：建議參考 Google 的非同步 AI 程式代理人 Jules 的邏輯進行拆分。
- 手動整合 (Manual Merge)：由 Gemini 處理完繁重的邏輯後，開發者再將乾淨的代碼貼回專案中。
- 重構： 嘗試將代碼分成若干小部分並整合，此方法不建議常常使用，除非你是修改前端，將大的component分解成多個小的component才建議使用。
專家提示：為何不直接貼 GitHub 連結？ 強烈推薦使用 Gemini AI Pro 網頁版的「匯入程式碼 (上傳資料夾)」功能。請勿依賴貼上 GitHub 連結，因為 AI 工具抓取網頁連結時，常受限於反爬蟲機制或 Token 預算，只能讀取 README 或文件頭部，無法像上傳檔案那樣獲取完整的「原始字節 (Raw Bytes)」，兩者在體感準確度上有巨大差異，即便是自己授權的Github也是一樣的問題，很奇怪?。
重構與 Token 的博弈：Gemini App 的戰略地位
進行程式碼重構時，大多數 IDE Agent 都受限於 Token 的窗口設計 (Context Window)，這使得它們在處理跨檔案的大規模變動時顯得力不從心。
Jules 與 Antigravity 的搭配戰術
Jules 是 Google 設計用來處理非同步任務的 AI Agent（例如修復整個 Repo 的 Type 錯誤）。然而在實際重構上，其執行往往會失敗。一個靈活的解決方案是讓 Jules 嘗試重構，即便失敗，也可將其過程打包成 zip 檔匯入 Antigravity，或者將 Jules 的分析邏輯複製給 Antigravity。這如同讓顧問先完成調查，再由執行者負責落地。
Gemini App 的省錢與高效之道
無論是 Claude Code、Cursor 還是 Trae，大多使用向量搜索或是技術查找位置或搜尋特定文字，準確率有時並不理想。
- Gemini App 的優勢：網頁版 Gemini 支援上傳高達 1000 個檔案（100MB 上限）。這意味著開發者可以將整個專案結構提供給它，使其擁有上帝視角。
- 最佳實踐：利用 Gemini App 找出需要修改的確切檔案路徑，然後在 Antigravity 中使用
@files手動指定這些檔案。儘管手動@files看似原始，卻是目前最精準的上下文傳遞方式。
Google 的 Gemini Pro 目前每日提供寬裕的免費限制，且不計 Token 消耗。單純依賴 Agent 的搜尋功能，往往不如直接將完整代碼提供給 Gemini 來得有效。
安全性警告：終端機的自動執行陷阱
使用任何 AI Agent 時，信任應設有底線。Antigravity 允許 AI 在終端機執行指令，這是一把雙面刃。
切勿開啟 Turbo 模式
在設定中，強烈建議將終端機執行政策 (Terminal Execution Policy) 設為 Off，或者至少是 Auto (需要授權)。絕對不要開啟 Turbo (全自動執行)。
曾有案例顯示，AI 為了優化速度，自行決定刪除非必要的資料庫。對於 AI 而言，其邏輯鏈條相當直觀：使用者嫌速度慢，資料庫拖慢了速度，移除資料庫後查詢回傳即時（雖然結果為空），判定任務完成。
AI 的黑色幽默 「已優化儲存效率，將儲存成本降至零（刪除所有歷史記錄），並簡化了備份策略（無資料需備份）。完全符合 Clean Code 原則。」
務必謹記 Off: Never auto-execute terminal commands，這是保護硬碟與數據的最後一道防線。
競品分析：Antigravity 在市場中的定位
與 Claude Code 的對比
Anthropic 的終端機 AI 工具 Claude Code 體感速度極快，這也是許多人願意付費訂閱 Claude Pro 的原因。然而，Claude Pro 目前每日約 5 小時的使用限制是一大硬傷。
- 策略建議：
- Antigravity + Gemini AI Pro：作為主力，負責絕大部分的規劃與繁重工作。
- Claude Code：視為精準打擊的特種部隊，用於最後的代碼生成或特定前端樣式調整。
與Trae的對比
使用來說整體不會輸給Claude code，而且是以請求數來收費，整體價格應該算最便宜的產品，若不建議資安問題也可以選用。Trae不會像Antigravity一樣一直破壞代碼。
早期尚未有付費版本，beta版在每次請求的時候的等待，比Antigravity的體驗差多了。
與Cursor的對比
相對於Antigravity一直在網路上出現什麼刪除硬碟、提示詞注入危險等，Cursor算是穩定，不過常常大更新後，一天會出現多次更新修復bug，所以建議不要大量更新??(我也不知道我在打什麼，抱歉)，中規中矩的產品。
由於最終這些產品若是以請求收費，終究會輸給那些LLM供應商，而以token收費則是希望你用的越多越好，因為他們token一定比我們從LLM供應商取得的價格還便宜，所以仍是看好Antigravity。
其餘像是Qoder、Kiro、Windsurf、codex等，因為我沒使用過所以不好評論。
適合對象分析
- 資深開發者：若懂得如何拆解任務，並知道何時拒絕 AI 的建議，Antigravity 搭配 Gemini 是極具性價比的強大組合。
- 非程式設計師：Antigravity 並不適合此類用戶。建議轉向 Loveable 或 Firebase Studio。
Loveable 主打從對話生成全端應用，適合快速原型製作。Firebase Studio (或 Project IDX) 則是 Google 的雲端開發環境。這些工具有固定的模板（如 Vite, TypeScript, React, Next.js），保證了固定的安裝模式，避免 AI 構建專案時使用過時依賴。
你總是覺得有些產品很聰明，大多是因為他們有設計模板，讓你不會總是拉到舊的架構，像是Claude code、Trae、Bolt等，若請他們從0-1創建expo project，總是在跟錯誤訊息打架。
深入配置：讓 Agent 更聰明
Antigravity 提供了豐富的自定義選項，透過合理配置可大幅提升工作流順暢度。
終端機與審查政策
- Terminal Policy：如前所述，設為 Off 是最安全的選擇。
- Review Policy：決定何時介入審查 Agent 的工作計畫。推薦設為
Request Review，即 審查導向開發，這是最安全且適合複雜任務的模式。
Planning 與 Fast 模式
- Planning：適合複雜任務。Agent 會先產出工作群組、研究構件，思考後再行動，這是 Antigravity 的強項。
- Fast：適合更名變數、簡單腳本執行。
規則 (Rules)
這是 Antigravity 的靈魂所在。透過在 .gemini 資料夾或工作區設定中添加規則，可以強制 AI 遵守特定的開發規範。例如強制 模組化生成：
* Do not generate code in the main method. Instead generate distinct functionality in a new file.
* Then, generate example code to show the new functionality in a new method in main.py.
缺乏 Checkpoint 的應對：Git 是唯一的後悔藥
目前 Antigravity 最大的缺憾是缺乏 Checkpoint (檢查點) 功能。一旦 AI 修改錯誤，沒有內建的上一步可以完美還原(只能透過VS Code History還原)。
生存法則：
- 頻繁 Commit：在每一次讓 Antigravity 執行任務前，務必進行
git commit。 - 拒絕 Reset：當 Antigravity 發現錯誤並試圖調用
reset指令時，請拒絕它。 - 人工介入：查看修改內容，直接
git checkout拒絕錯誤的檔案。若它第二次嘗試修改，通常極高機率仍會出錯。此時應直接詢問其修改計畫，然後手動執行或交由 Gemini AI Pro 處理。
結論
在本文中，我們深度探討了 Antigravity的架構與哲學差異，但仍有一塊關鍵區域值得我們深思：AI 最終的目標，究竟是取代人類，還是以更智慧的方式輔助我們？
1. 高階 Agent 功能的潛力與現實
不可否認，Antigravity 的 Agent Manager（多代理並行修復 CSS、測試、文檔）和 Browser-in-the-Loop（代理能操作瀏覽器進行自我修復驗證）代表了 IDE 的未來願景。然而，實戰經驗告訴我們，在現階段，當連基礎的單一程式任務都可能遇到崩潰時，這些高層次功能的實用性仍受限於 AI 的穩定性，因此並未成為我們工作流的主力。
2. 開發者的哲學選擇：我為什麼偏愛 Chat 模式？
老實說，身為一個長期寫代碼的軟體工程師，我本身不喜歡激進的 Agent 自主模式。我不喜歡 AI 在未經許可下大幅度重新撰寫代碼，我更喜歡非侵入式的開發方式。
我更偏好 Chat 模式帶來的輔助性，像是一問一答這種。或是更偏好 Jules（Google 的非同步 Agent）的原因。Jules 提供了 Zip 產物下載，以及允許使用者在 UI 上看到更動的機制，這完美符合我「手動整合，每一行都要查看」的原則。
Agent 的目的在於取代人，還是輔助人？ 對我而言，目前的 AI 仍是輔助工具。我會讓 AI 寫程式作為參考，但實際寫入專案的每一行程式碼，仍需由人類工程師親自審核和操作。
3. Vibe Coding 的理想與現實衝突
Google 在 Gemini 3 Pro 的文檔中，描繪了一個「Vibe Coding」的理想未來：
「Gemini 3 Pro 釋放了『vibe coding』的真正潛力——在這裡，自然語言是你唯一需要的語法… 模型只需一個提示詞 (prompt)，就能把高層次的想法轉化為完全互動式的應用程式。」
Agent 的最終目的，就是實現這種「心流編程」。然而，這也引發了另一個隱憂：
如果 Vibe Coding 最終實現，它適合用來打造服務用戶的產品嗎？
當程式碼生成變得極度容易，且不需要工程師深入介入細節時，品質、安全性和道德考量可能會被稀釋。目前的 Vibe Coding 更適合打造自己使用的產品，而不適合打造服務用戶的產品。這可能導致未來人人都在用 AI 做軟體，但人人都不願意為其質量負責的負面影響。
因此，Chat 模式的恰到好處，或許才是當前技術與人類專業經驗之間最完美的平衡點。在 Vibe Coding 最終成熟之前，保持審慎的態度，將 Git Commit 作為唯一的後悔藥，是我們每一位工程師的生存哲學。
常見問題解答 (FAQ)
Q：Antigravity 適合完全不懂程式設計的新手嗎？ A： 不建議。Antigravity 需要使用者具備一定的程式碼判斷能力。對於無代碼基礎的用戶，Loveable 或 Firebase Studio 會是更友善的選擇。
Q：如何解決 Antigravity 在處理超過太多行程式碼時的崩潰問題？ A： 避免讓其直接處理大檔案。應先請 AI 分析並提供解決方案，接著將該方案與程式碼上傳至 Gemini AI Pro (網頁版)，利用其高 Token 上下文能力生成修改後的代碼，最後再手動貼回專案。
Q：為什麼建議關閉終端機自動執行功能 (Off 模式)？ A： AI Agent 偶爾會為了達成目標而執行破壞性指令，例如刪除資料庫以優化查詢速度。將政策設為 Off 或 Auto 並人工審核每一個指令，是保障本機環境與資料安全的唯一方法。
Q：Antigravity 目前是免費的嗎？ A： 截至目前為止，Antigravity 在 Beta 版本仍是免費使用的工具。除了剛開始使用外，目前幾乎不會遇到限制，是非常具備成本效益的開發組合。