鋼彈駕駛員上線！我如何用 SDD 規格驅動 Antigravity 實戰開發

Aiezn • 2026-01-06 • 8 min read

昨天聊完 Antigravity 比較重要的架構層面以及相關功能後，今天我想稍微聊聊「操作感」——也就是我當前如何使用 SDD (Specification-Driven Development，規格驅動開發) 來駕駛 Antigravity 這台鋼彈機器人。

先打個預防針，這中間包含許多個人經驗改編，或許不見得符合教科書上的正規定義，但這是我目前實作起來最舒服、效率最高的方式，目前也還在持續調整優化中。

1. Rules (Gemini.md)：鋼彈的最高行動準則

在昨天的討論中，我把 Rules & Workflows 比喻成家規與 SOP，但實際上它們的角色可能更加關鍵，特別是 Rules (Gemini.md)。

我們可以將 Rules 視為全域的最高準則，是 Agent 共同遵守的系統指令。每一份 Project 都必須在 Rules 的規範下運作，否則這台鋼彈就會亂開、甚至失控。

1.1 我在 Rules 中定義的六大核心：

核心身份：明確定義「你是誰？」以及「我們的目標是什麼？」。
專案 (Project) 結構標準：定案專案的長相，通常包含 PROJECT_SPEC 與 PROJECT_Logs。
跨專案溝通與協作準則：定義專案間的溝通方式。我會透過一個共有檔案 MASTER_PLAN 讓專案之間互讀，功能類似於各專案的「社群群組」。
技術偏好：包含相關框架的使用習慣、技術概念與特定偏好。
自動化協議：規範每一次 SDD 必須執行的動作，例如 SPEC 文檔產生前的訪談、運行後的紀錄與統整。
安全規範：定義資安原則（例如 Zero Trust，堅持先掃描再部署）。

分析與洞察：
Rules 是 Agent 的「靈魂」，它決定了 AI 在面對模糊指令時的判斷基準。比起單純的 SOP，Rules 更像是一種「價值觀」，確保多個專案在並行時能維持高度的一致性。

2. 架構視覺化：最核心的專案結構

如果從架構的角度來看，一個能讓 SDD 順暢運行的 Workspace 結構大致如下：

Workspace
- Project1
    - Global Rule
        - PROJECT1_SPEC
        - PROJECT1_Logs
    - Project1-Workflow
- Project2
    - Global Rule
        - PROJECT2_SPEC
        - PROJECT2_Logs

透過這種結構，每個專案都有獨立的規格書與日誌，但同時受控於全域的規則之下。

3. 驅動核心：PROJECT_SPEC 與「本次變更需求」

接下來進入「驅使鋼彈」的實作層面，這就必須提到我定義中最重要規格檔案：PROJECT_SPEC。

3.1 駕駛艙視角

我的做法是透過 Editor View 同時開啟好幾個專案的 PROJECT_SPEC 去執行。此時的畫面看起來極具「鋼彈駕駛艙」的既視感，螢幕上排滿了各個系統的運作指南。

3.2 任務定義

PROJECT_SPEC 除了記錄專案的大致介紹外，最重要的就是定義每一次的執行任務。格式如下：

🎯 本次變更需求 (Current Sprint)

task 1: [具體描述]
task 2: [具體描述]
task 3: [具體描述]

3.3 運作邏輯

原則上，每一次執行 SDD 時，Agent 只需要讀取此「變更需求區塊」，接著便會根據自動化協議開始運行任務。我們可以想像成同時調用了多個 SDD 指令，讓 Agent 各自去操作不同專案的變更需求。

4. 實戰操作：Agent Manager 的 Multi-Agent 協作

在 Antigravity 中，雖然可以透過切換 Agent 歷史專案來執行 SDD，但我個人更偏好透過 Agent Manager 運行。

4.1 為什麼選擇 Agent Manager？

這個視窗能夠清楚切割不同的 Project 與各自的 Agent 調動，非常適合 Multi-Agent 協作。

操作感：開發者的任務就是「出張嘴」，下令讓 Agent 各自去運行旗下專案的「本次變更需求」。
清晰度：任務進度與專案切割一目瞭然，減少混淆。

4.2 駕駛員的生存警告

雖然同時運行多個 Agent 效率極高，但有一點要特別提醒：同時運行多個 Agent 時，盡量確保專案的相似性要高。如果專案跨度太大（例如一個寫 Web，一個搞底層驅動），駕駛員的人腦真的會爆炸，Context Switch 的成本會變得極高。

5. 結語：駕駛員的最後提醒

這套「鋼彈駕駛流程」的核心在於將複雜的開發工作轉化為「規格定義」與「指令下達」。當你的 Rules 定義得夠清楚，SDD 就能像自動導航一樣幫你完成大部分的髒活。

我也把我的 Gemini.md 必要部分濃縮整理了一份範本，算是給大家的小禮物。如果你也想體驗這種「出張嘴」的開發快感，歡迎參考看看！

希望這次的分享對你有幫助，也歡迎在留言區跟我討論你的 SDD 實作心得！😊