用例、排障與參考

Antigravity 最適合的不是“隨便幫我寫點程式碼”，而是有明確目標、有可驗收路徑、需要跨 editor、terminal 和 browser 的開發任務。官方釋出文給出的典型方向包括複雜多工具任務、UI 迭代和後臺長任務維護。

判斷標準：如果任務可以用 plan、diff、test、screenshot、browser recording 和 walkthrough 證明完成，它就更適合 Antigravity。

1. 適合的任務

任務	為什麼適合
修復 UI bug	可以改程式碼、啟動服務、開啟瀏覽器、截圖/錄屏驗證
給已有功能補測試	可以讀程式碼、生成測試、跑命令、交付結果
小到中等範圍重構	可以先 plan，再逐步 diff review
文件重組	可以生成 task list、批次改檔案、交付 walkthrough
依賴升級排障	可以查 terminal 輸出、改配置、跑測試
多頁面互動驗證	Browser Subagent 可以點選、輸入、觀察頁面

2. 不適合直接交給 agent 的任務

任務	風險	更好的方式
生產資料庫改動	不可逆、影響真實使用者	先寫遷移計劃，人工執行
賬號後臺操作	登入態和許可權風險	人工操作，agent 只做只讀指導
金鑰輪換	可能洩露憑據	用內部 SOP，不讓 agent 接觸明文
大範圍無邊界重構	diff 無法審完	拆成模組級任務
涉及付款/廣告投放	金錢和合規風險	人工審批和操作

3. 排障順序

flowchart TD
    Symptom["出現問題"] --> Layer{"先定位層級"}
    Layer --> Install["安裝 / 登入"]
    Layer --> Workspace["Workspace / file access"]
    Layer --> Permission["Permissions / sandbox"]
    Layer --> Browser["Browser extension / URL allowlist"]
    Layer --> Model["模型 / quota / pricing"]
    Layer --> Project["專案依賴 / 測試命令"]
    Project --> Evidence["保留日誌、diff、artifact"]
    Evidence --> Feedback["必要時透過應用內反饋入口報告"]

不要一上來重灌。先判斷是安裝、登入、許可權、瀏覽器、模型額度，還是專案本身的問題。

4. 常見症狀

症狀	優先檢查
agent 不跑命令	Terminal Execution policy、Allow/Deny/Ask、sandbox
agent 看不到檔案	workspace 是否正確、file access 是否限制
瀏覽器任務卡住	瀏覽器擴充套件、URL allowlist、JavaScript policy
沒有 screenshot 或 recording	prompt 是否要求 browser 驗收，任務是否進入 Browser Subagent
修改範圍太大	prompt 邊界、Planning plan、workspace 是否過寬
模型不可用	官方 pricing / quota / model selector