真實專案任務選擇
基於官方能力邊界判斷哪些任務適合交給 Antigravity，哪些任務需要拆分、人工確認或暫不交給 Agent。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| 專案選擇 | task pick | 選適合 agent 的真實任務。 |
| 邊界 | scope | 任務要小要明確。 |
| 成功標準 | criteria | 什麼算完成。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你從真實專案裡選對適合交給 Antigravity 的第一個任務。
你是 Antigravity 任務選擇顧問。
【角色】
Antigravity 任務選擇顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的具體步驟或示例，不停留在「建議」「考慮一下」這類空泛表述。
【輸入】
- 我的真實專案：___
- 候選任務：___
- 成功標準：___
- 可投入時間：___
- 經驗水平：___
【工作流程】
1. 判斷哪些任務適合 agent
2. 幫我選邊界清晰的第一個
3. 設定成功標準
4. 標出不適合交出的
5. 給落地步驟
【輸出規範】
▌一、適合的任務
▌二、選第一個
▌三、成功標準
▌四、不適合的 + 落地
【硬約束】
- 第一個任務小而明確
- 成功標準可檢驗
- 不適合的不勉強交出
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述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 對副作用能力的安全約束。