Conductor 現支援 Antigravity：手把手把 spec-driven 開發跑起來

瀏覽次數: 2

你有沒有這種經驗：跟 coding agent 說「幫我加個購物車折扣功能」，它二話不說開始改十幾個檔案，跑到一半你才發現——它理解的「折扣」跟你要的根本是兩回事，於是整段打掉重來。更慘的是，你今天在 Claude Code 裡把需求講清楚了，明天想換 Antigravity 接手，那些脈絡全都跟著對話一起蒸發。

2026 年 7 月 16 日，Google Developer & Experiences 團隊（作者 Mahima Shanware、Sherzat Aitbayev 兩位資深工程師，與群組產品經理 Jay Kornder）發文宣布：他們的 spec-driven development 工具 Conductor 從 Gemini CLI extension 改成了 plugin 格式，順帶讓它能跑在 Antigravity CLI 上。這件事的意義不只是「多支援一個工具」——它讓「先寫規格、再讓 agent 動手」這套方法，第一次能用同一份檔案跨 Antigravity、Claude Code、Gemini CLI 三個 agent 共用。

這篇就手把手拆給你看：Conductor 到底怎麼運作、它產生哪些檔案、六個指令各做什麼、怎麼裝、什麼時候值得用、什麼時候是殺雞用牛刀。

本文大綱

先講清楚：spec-driven development 在解什麼問題

大部分人用 coding agent 的預設姿勢，是 Google 這篇稱之為 prompt-and-patch（丟一句話、直接打補丁）的模式：你給一段自然語言，agent 立刻開始寫 code。這在改個 typo、寫個小函式時很爽，但只要任務一複雜，三個結構性問題就會冒出來：

需求只活在對話裡。 你花五分鐘把邊界條件講清楚，關掉視窗就沒了。下次要接續，得重講一遍。
理解錯了才發現。 agent 沒有先跟你對齊「做什麼、為什麼」，直接進入實作，等你 review 到一半才發現方向歪掉，沉沒成本已經付出去。
脈絡綁死在單一工具。 換 agent、換同事接手，等於從零開始。

spec-driven development（SDD）的核心主張很簡單，Conductor 用一句話總結：「Measure twice, code once」（量兩次，切一刀）。動手寫 code 之前，先把需求與計畫寫進版本控管的 markdown 檔，讓它成為整個 repo 的 single source of truth（唯一真相），而不是散落在一堆會被清掉的聊天記錄裡。

這不是新概念——Waterfall 時代就在講「設計先行」。SDD 的差別在於：它把那套「先設計」的嚴謹，塞進了一個 AI agent 能自動維護、又保持對話式互動的迴圈裡。你不是回去寫幾百頁規格書，而是跟 agent 對話，由它動態生成並持續更新這些檔案。

運作原理：Context → Spec & Plan → Implement

Conductor 的本質，是把你的 coding agent 從「寫 code 的工具」變成「照 SOP 做事的專案經理」。它強制走一條固定生命週期：Context（脈絡）→ Spec & Plan（規格與計畫）→ Implement（實作），中間再加上 review 與 revert 兩道保險。

第一步：Context —— 建立專案的長期記憶

第一次在一個 repo 用 Conductor，你先跑 /conductor:conductor-setup。這是一次性的專案 scaffolding，它會在 repo 根目錄長出一個 conductor/ 資料夾，裡面是這個專案的「長期記憶」：

conductor/
├── product.md              # 這個產品是什麼
├── product-guidelines.md   # 產品層面的規範
├── tech-stack.md           # 技術棧
├── workflow.md             # 工作流偏好（可自訂範本）
├── tracks.md               # 所有 track 的總覽索引
└── code_styleguides/       # 程式碼風格指南

重點在於：這些檔案是進 git 的。它們不是某次對話的產物，而是團隊共享的脈絡資產。今天你設定好 tech-stack.md 與 code_styleguides/，之後每一次 agent 動手，都會拿這些當前提——不用每次都在 prompt 裡重複「我們用 TypeScript、不要用 any、測試用 Vitest」。

第二步：Spec & Plan —— 每個功能開一條 track

要做一個新功能或修一個 bug，你跑 /conductor:conductor-new-track（可以直接帶一句描述）。Conductor 會為這條 track 生成三個檔案：

conductor/tracks/<track_id>/
├── spec.md         # 詳細需求：我們要做什麼、為什麼
├── plan.md         # 可執行的待辦清單：phases → tasks → sub-tasks
└── metadata.json   # track 的中繼資料

這裡是整套方法最關鍵的一刀：spec.md 與 plan.md 是分開的。

spec.md 回答「做什麼、為什麼」——需求、邊界、約束。這是你要花力氣 review 的檔案。
plan.md 是把 spec 拆成的可執行 to-do list，結構是「階段（phase）→ 任務（task）→ 子任務（sub-task）」，每一項前面掛著 [ ] 的 checkbox。

換句話說，agent 不是聽完你一句話就衝去寫 code，而是先產出一份你看得懂、改得動的規格與計畫，等你點頭，才進實作。這一步就是把「理解錯了才發現」的成本，從實作後移到實作前。

實戰技巧： 真正決定產出品質的，是你在 spec.md 這關的把關。agent 生出的 spec 你一定要逐條讀過——特別是邊界條件（空值、權限、失敗路徑）和「不做什麼」的負向需求。spec 錯，後面 plan 跟 code 一路錯到底；spec 對，實作階段幾乎是照抄。花十分鐘改 spec.md，勝過事後花一小時 debug 一堆方向錯誤的 code。

第三步：Implement —— 照 plan 逐項打勾

規格與計畫定案後，跑 /conductor:conductor-implement。agent 會照著 plan.md 一項一項執行，完成一項就把該項的 [ ] 改成 [x]。這個看似樸素的機制其實很重要：

進度是寫在檔案裡、進 git 的，不是藏在對話某個角落。任何人打開 plan.md 就知道做到哪。
中途中斷、隔天再接、或換一台機器、換一個 agent，都能從 checkbox 狀態無縫接續。
Google 這篇特別提到，系統會「聰明地知道何時該更新你的 context、何時該在 plan 裡勾掉一個已完成的任務」——也就是這套勾選不需要你手動維護。

第四步：Review 與 Revert —— 兩道保險

實作完不是就結束。Conductor 還給了兩個很實用的收尾指令：

/conductor:conductor-review：把完成的工作對照 conductor/ 裡的 guidelines 與 plan 做審查。等於內建一道「有沒有照規範做」的自查。
/conductor:conductor-revert：分析 git 歷史，讓你按邏輯單位回滾——可以整條 track 退掉、退某個 phase、或只退單一 task。這比你自己在一堆散落的 commit 裡找「該 revert 哪幾個」安全得多，因為 Conductor 知道哪些改動屬於哪個邏輯單位。
/conductor:conductor-status：隨時看 tracks.md 的整體進度總覽。

一個容易忽略的設計：View Layer UX Adapter

Conductor 之所以能同時服務 Antigravity（視覺化 IDE）和 Claude Code（終端機）這兩種形態很不一樣的環境，靠的是它文件裡講的 View Layer UX Adapter：在 Antigravity 這類 IDE 裡，它用互動式的 GUI Modal 彈窗；在 Claude Code 這類終端環境，它自動降級成文字選單。文件強調這是「零設定、動態偵測」。對你的實際意義是：同一份 spec.md、plan.md，在不同 agent 裡體驗會自動貼合該環境，你不用改任何東西。

怎麼裝：三種 agent 各一行

這次改成 plugin 格式，最直接的好處就是安裝變簡單了。

Antigravity CLI（agy，一般使用者）：

agy plugins install https://github.com/gemini-cli-extensions/conductor

Claude Code：

/plugin marketplace add gemini-cli-extensions/conductor
/plugin install conductor

如果你是想改 Conductor 本身、做 live-sync 開發，repo 裡也提供了用 symlink 把本地目錄掛進 ~/.gemini/config/plugins/ 的作法。這個 repo 是 gemini-cli-extensions 組織維護、Apache 2.0 授權，skills/ 放各指令的協定邏輯（每個指令一份 SKILL.md），rules/ 放各平台的操作規則。想搞懂它到底怎麼驅動 agent，直接讀這兩個資料夾最快。

數據與限制：誠實地看

Google 這篇文章對效果的唯一量化說法是：「Conductor Plugin 在 TerminalBench 最複雜的那一組任務子集上，成功率高於不使用 SDD 的使用者。」

這句話要冷靜讀。從文件看，Google 並沒有公布具體數字——沒有給百分比、沒有給樣本數、也沒有說明對照組怎麼設。所以請把它當成「工具方回報的方向性結果」，而不是可複製的 benchmark。它告訴你的資訊是：SDD 的收益集中在複雜任務；反過來說，簡單任務不一定看得出差別（這其實符合直覺）。

其他要老實承認的限制：

有前期成本。 setup、寫 spec、審 plan 都要時間。任務越小，這套流程的固定成本佔比越高。
spec 品質決定一切。 這套方法把賭注壓在「先想清楚」，但如果你連自己要什麼都沒想清楚就讓 agent 生 spec、又不認真 review，那 Conductor 只是幫你把混亂寫得更工整而已，垃圾進、垃圾出。
多一層抽象要學。 六個指令、一套資料夾結構、track 的概念——對只想快速改個東西的人，是額外心智負擔。

什麼時候該用、什麼時候別用

適合用 Conductor / SDD：

跨多個檔案、有明確驗收標準的功能開發（購物車、權限系統、資料遷移這類）。
多人 / 多 agent 協作：需求要被別人（或另一個 agent）接手，spec.md 進 git 的價值就出來了。
需要可追溯、可回滾的專案：金融、合規、或任何「改壞了要能快速退回」的場景，conductor-revert 的邏輯單位回滾很值錢。
你已經被 agent「方向跑歪、整段重來」坑過好幾次。

別用、或先別用：

一次性小改動：改 typo、調個 CSS、寫個一次性腳本，直接 prompt-and-patch 更快，套 SDD 是殺雞用牛刀。
探索性、還不知道要什麼的階段：這時你需要的是快速試錯，不是先立規格。等方向收斂了再上 Conductor。
你不打算 review spec：如果你只想按 enter 讓 agent 全自動跑，那 SDD 的把關價值你根本沒吃到，徒增流程。

對工程團隊的意義：可以照著做的三件事

如果你想在團隊裡實際導入，這裡給三個具體、今天就能動手的步驟：

先挑一條「中等複雜、驗收明確」的 track 試水。 別一開始就拿最亂的模組。在一個你熟的 repo 跑 conductor-setup，把 tech-stack.md、code_styleguides/ 認真填好——這是一次性投資，後面每條 track 都吃這份紅利。
把 review 力氣集中在 spec.md，不是 code。 建立團隊習慣：spec.md 要有人 approve 才進 implement。這等於把 code review 的一部分成本前移到成本更低的規格階段。plan.md 的 checkbox 則天然是進度看板，站會直接看它。
利用「跨工具共用」這個新特性。 既然同一份 conductor/ 現在能被 Antigravity、Claude Code、Gemini CLI 共用，你可以讓偏好不同工具的成員在同一套 spec 下協作——用 Antigravity 視覺化排 plan 的人，和在 Claude Code 終端裡跑 implement 的人，看的是同一份真相。這是這次 plugin 化最實際的團隊價值。