真實專案任務選擇
基於官方能力邊界判斷哪些任務適合交給 Antigravity，哪些任務需要拆分、人工確認或暫不交給 Agent。
Antigravity 適合的不是“讓 AI 隨便寫點程式碼”，而是目標明確、邊界清楚、能用 artifacts 和測試驗證的開發任務。Google Developers Blog 對 Antigravity 的定位是：讓 agents autonomously plan、execute、verify complex tasks，並透過 Editor、Terminal、Browser 和 Artifacts 溝通進展。
所以選擇任務時，先問一個問題：這個任務能不能用 plan、diff、test、screenshot、recording、walkthrough 證明完成？
閱讀目標：讀完本章，你應該能把真實專案任務分成“適合直接交給 Antigravity”“需要拆分後交給 Antigravity”“必須人工控制”的三類。
1. 適合直接交給 Antigravity 的任務
這些任務通常目標清晰、風險可控、證據鏈完整。
| 任務 | 為什麼適合 | 要求的證據 |
|---|---|---|
| 修復明確 UI bug | 可改程式碼、開啟瀏覽器、截圖驗證 | diff + screenshot + console |
| 給已有邏輯補測試 | 可讀程式碼、生成測試、跑命令 | diff + test output |
| 文件重組 | 檔案範圍清楚，容易審查 | task list + diff + walkthrough |
| 小範圍重構 | 可以先 plan，再分組修改 | implementation plan + tests |
| 本地頁面斷點檢查 | browser subagent 能看不同 viewport | screenshots + recording |
| 終端報錯排查 | 可以保留日誌並最小修復 | terminal output + diff |
示例 prompt：
请使用 Planning 模式修复当前页面 mobile 断点下的按钮换行问题。
范围只限这个组件和样式文件。
先给 implementation plan，不要立即修改。
确认后运行本地页面，并提供 390px、768px、1440px 截图。2. 需要拆分後再交給 Antigravity 的任務
這些任務可以用 Antigravity 做，但不能一次全交。
| 任務 | 拆分方式 |
|---|---|
| 跨模組重構 | 先只讀分析，再按模組分批改 |
| 依賴升級 | 先列影響範圍，再升級一個包，再跑測試 |
| 多頁面 UI 改版 | 先建立視覺基線，再按頁面批次驗收 |
| MCP 接入 | 先審 server / tools，再只讀連線，最後放開寫操作 |
| Firebase 遷移 | 先保留原始匯出，再遷移，再本地預覽，再發布 |
| 團隊規範沉澱 | 先跑一次人工流程，再寫 Rules / Workflows / Skills |
flowchart TD
Big["大任務"] --> Readonly["只讀分析"]
Readonly --> Plan["Implementation Plan"]
Plan --> Batch["拆成批次"]
Batch --> Execute["執行第一批"]
Execute --> Verify["驗證和截圖"]
Verify --> Next{"是否繼續下一批"}
Next -->|是| Batch
Next -->|否| Stop["彙總 walkthrough"]3. 不應該直接交給 Agent 的任務
這些任務不是 Antigravity 完全不能參與，而是不能讓 agent 直接執行副作用動作。
| 任務 | 風險 | 更穩做法 |
|---|---|---|
| 生產資料庫改動 | 不可逆，影響真實使用者 | agent 寫計劃，人工執行 |
| 金鑰輪換 | 憑據洩露風險 | 人工按內部 SOP 操作 |
| 付款、訂閱、廣告投放 | 金錢和合規風險 | agent 只讀分析，人工確認 |
| 真實賬號後臺點選 | 登入態和許可權風險 | 先只讀，必要時螢幕人工操作 |
| 大範圍刪除或遷移檔案 | 回退成本高 | 先 inventory 和 dry run |
| 未審計 MCP 寫操作 | 外部系統副作用 | disabledTools + Request Review |
“Agent 可以操作”不等於“應該讓它自動操作”。真實專案先看副作用，再決定許可權。
4. 用證據鏈判斷任務質量
一個合格的 Antigravity 任務至少要有下面幾類證據中的一部分：
| 證據 | 適用任務 |
|---|---|
| Task List | 長任務、並行任務 |
| Implementation Plan | 跨檔案、複雜修改 |
| Code Diff | 所有寫檔案任務 |
| Terminal Output | build、test、lint、排障 |
| Screenshot | UI、佈局、斷點、主題 |
| Browser Recording | 使用者路徑、互動流程 |
| Walkthrough | 任務完成後彙總 |
深讀：為什麼“複雜任務”不是越大越適合 Agent
官方產品定位強調 autonomously plan、execute、verify complex tasks，但這裡的 complex 不是“無限大、無邊界”。複雜任務適合 agent 的前提是能拆成可審查單元，能透過 artifacts 溝通進展，也能用測試或瀏覽器證據驗證。
如果任務範圍大到 diff 無法審、測試無法跑、瀏覽器路徑無法復現，那麼它就不再是 agentic development 的優勢區，而是風險區。正確做法是先用 Antigravity 做分析和計劃，再把實現拆成小批次。
5. 一個真實專案啟動模板
请先只读分析当前任务，不要修改文件。
请输出：
1. 任务是否适合 Antigravity 直接执行。
2. 建议使用 Editor、Agent Manager 还是 Browser Subagent。
3. 需要哪些权限和工具。
4. 最小可执行批次。
5. 验收证据：diff / test / screenshot / recording / walkthrough。
6. 哪些动作必须等我确认。本章自檢
完成本章後，用這 3 個問題檢查自己是否真正理解：
- 哪類任務可以直接交給 Antigravity，哪類必須拆分？
- 為什麼生產資料庫、金鑰、付款和真實後臺操作不能自動放權？
- 一個前端 UI 任務至少應該交付哪些證據？
透過標準：你能拿到一個真實任務後，先判斷任務型別、拆分方式、許可權邊界和驗收證據，而不是直接讓 agent 開始改。
官方來源
- Build with Google Antigravity —— 官方釋出文說明 Antigravity 面向 agentic development，結合 Editor、Manager Surface、Terminal、Browser 和 Artifacts。
- Google Antigravity Artifacts —— 官方說明 artifacts 作為非同步溝通和反饋機制。
- Google Antigravity Browser —— 官方說明瀏覽器可用於測試開發網站、讀取資料來源和自動化瀏覽器任務。
- Google Antigravity Strict Mode —— 官方說明 strict mode 對副作用能力的安全約束。