VM0 開發工作流程：像管理團隊一樣管理 AI 代理

在 VM0 開發團隊中，每位開發者會同時使用多個 Claude Code 實例，通常超過八個。

我們把 Claude Code 當作真正的開發者來對待。（沒錯，我們公司半開玩笑地叫做 AI Colleagues Co！）

正因如此，VM0 開發工作流程背後的設計理念，完全呼應了軟體工程中經典的團隊管理實踐。

我們使用 GitHub Issues 追蹤工作、Pull Requests 進行程式碼審查與合併，並透過 GitHub Actions 處理自動化。 兩個月內，這套架構幫助我們發布了 404 個版本，撰寫了超過 230,000 行程式碼。

這篇文章說明我們如何讓這一切運作，以及為什麼關鍵問題從來不是 AI 的能力，而是人的協調。

AI 驅動的開發工作流程實踐

當你同時協調多個 AI 代理時，瓶頸不在於模型能不能寫程式碼。真正的瓶頸是人的認知負荷。

這套工作流程包含 14 個斜線指令，分為三個層次：深度探索（Deep Dive）、Issue 管理，以及 PR 管理。

先來看看我的工作流程長什麼樣子，以及一個功能通常是如何被開發出來的。

1. 需求對齊

   由人開啟一個 Claude 對話，並以 /deep-research 開始。Claude 從程式碼庫、文件及相關情境中蒐集資訊。我們討論發現的內容，並對齊我們實際上要解決的問題。

2. 方案探索

   使用 /deep-innovate，Claude 提出幾個可能的方向，並附上各自的取捨分析。我們討論、縮小範圍，然後選定一個方向。

3. 建立 Issue

   使用 /issue-create 建立一個 GitHub issue。由人審查這個 issue，確認需求已被清楚記錄。

4. 規劃與核准

   使用 /issue-plan 讓 Claude 繼續工作。Claude 會自動執行完整的深度探索流程，並將結果發布到 issue，包括：

   1. 來自 /deep-research 的研究發現
   2. 來自 /deep-innovate 的方案比較
   3. 來自 /deep-plan 的具體實作計畫

5. 實作

   核准後，/issue-action 讓 Claude 執行計畫、撰寫測試、開啟 PR，並確保 CI 通過。

6. 審查與合併

   我們使用 /pr-review 進行結構化審查，然後由人進行最終審查後合併。

   人在三個檢查點介入：需求、方向，以及驗收。其餘一切皆自動執行。

思維轉變：你正在領導一支 AI 開發者團隊

我意識到需要結構化工作流程的那一刻，是當增加更多 Claude 對話反而讓事情變得更糟的時候。同時執行的實例越多，就越難追蹤每個實例在做什麼、工作處於什麼狀態，以及哪些事情已經決定了。

沒有外部工具，我根本無法同時管理那麼多 Claude 實例。就在那時我恍然大悟：這不是 AI 的問題，而是管理的問題。

GitHub 本來就是軟體開發中協作的自然工具，所以我沒有另起爐灶，而是開始把 Claude 當作人類隊友來對待。一旦這樣做，我的管理頻寬就突然擴展了。

十年的專案與團隊管理經驗，在這個新情境下終於有了意義。把 Claude 當作團隊成員，把 GitHub 當作我們共同的溝通與管理空間，整個系統就再次變得可以掌控。

一位好的團隊領導者知道何時介入、何時退後：

檢查點	我做什麼	AI 做什麼
需求	對齊問題，釐清範圍	研究程式碼庫，蒐集情境
方向	審查發現，核准方向	提出 2-3 個方向，評估取捨
驗收	審查 PR，驗證品質	實作、測試、修復 CI

這與高效軟體團隊的運作方式如出一轍。我不會對開發者微觀管理，而是設定清晰的需求、審查關鍵決策，並驗證最終產出。管理 AI 代理時，同樣的原則同樣適用。

深度探索流程強制執行結構化的慢思考

深度探索工作流程在實作之前強制進行深思熟慮。有時 Claude 會陷入死胡同。當這種情況發生時，我們強制 Claude 停下來思考，然後一起討論。它分為三個階段：

階段	指令	目的	產出
研究	/deep-research	蒐集事實，理解情境	research.md
創新	/deep-innovation	探索多種方向	innovate.md
規劃	/deep-plan	定義具體步驟	plan.md

每個階段都有嚴格的邊界。

• 研究：不提建議
• 創新：不涉及細節
• 規劃：不進行實作

這些限制迫使 Claude 進行緩慢、深思熟慮的推理，而不是直接跳到寫程式碼。沒有這些限制，邊緣案例和架構問題往往會被忽略！

使用範例

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

對於簡單的任務，你可以跳過深度探索，直接使用 /issue-create。

對於有技術不確定性的複雜任務，深度探索階段有助於確保你和 Claude 在實作開始前達成一致。

使用 GitHub 作為共享記憶體

大多數 AI 工具將情境視為暫時的。對話結束後，記憶就消失了。

VM0 使用 GitHub 作為持久記憶體：

GitHub 功能	儲存的內容
Issue 內文	需求與決策
Issue 留言	研究、選項、計畫
PR 留言	審查與摘要
標籤	工作流程狀態

這也解決了一個人的問題：情境恢復。

當我管理 8 個以上的 Claude 實例時，我會收到工作完成的通知。但我無法從 Claude 的對話中重建它在做什麼、做了哪些決策，或目前的狀態是什麼。

GitHub issues 解決了這個問題。每個 issue 都顯示：

• 原始需求
• 研究發現（發現了什麼）
• 創新階段（考慮了哪些選項）
• 核准的計畫（將要實作什麼）

這種結構化格式讓審查變得高效。我可以快速瀏覽各個階段、理解方向，然後核准或要求修改，完全不需要記得原始對話的內容。

工作完成後，我不需要記住聊天視窗裡發生了什麼。我可以打開 issue，看到完整的故事，結構清晰、白紙黑字。

代理之間的交接

由於所有情境都存放在 GitHub，工作可以在代理之間無縫流轉：

• 一個代理建立 issue 或 PR
• 另一個代理稍後使用 /deep-research issue 123、/issue-plan 123 或 /deep-research PR 124 繼續工作

對於冗長的討論，/issue-compact 會將所有內容整合成一個乾淨的 issue 內文。這讓人和 AI 的交接都變得輕鬆。

工作流程模式總結

說了這麼多，讓我總結幾個實用的建議。

簡單任務

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

當需求明確且工作直接時使用這個流程。

複雜任務

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

這能防止在錯誤的方向上浪費心力。

平行工作

多個代理可以同時工作，而人則審查已完成的檢查點。這是工作流程擴展效果最好的地方。

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

指令參考

深度探索指令

指令	目的
/deep-research	蒐集資訊，理解程式碼庫。不允許提出建議。
/deep-innovate	探索 2-3 個方向，評估取捨。不允許寫程式碼。
/deep-plan	建立具體的實作步驟。不允許進行實作。

Issue 指令

指令	目的
/issue-create	從對話情境建立 issue
/issue-bug	建立附有重現步驟的錯誤回報
/issue-feature	建立以需求為重點的功能請求
/issue-plan	執行完整的深度探索流程，將結果發布到 issue
/issue-action	在人核准後繼續實作
/issue-compact	整合 issue 內文與留言以便交接

PR 指令

指令	目的
/pr-check	監控 CI 流水線，自動修復，最多重試 3 次
/pr-review	依照專案標準逐一審查 PR 的每個 commit
/pr-comment	將對話討論摘要發布為 PR 留言

開始使用

1. 從簡單開始：第一個任務使用 /issue-create → /issue-plan → /issue-action
2. 為複雜任務加入深度探索：當需求不明確或技術上較複雜時，從 /deep-research 開始
3. 逐步擴展：隨著你對審查節奏越來越熟悉，再增加更多 Claude 實例
4. 信任流程：讓 Claude 在檢查點之間自主工作

這套工作流程設計為可以漸進式採用。你不需要從第一天就使用全部 14 個指令。先從基本的 issue 流程開始，隨著信心增加，再加入深度探索階段和平行工作。

擴展考量：當你有更多代理時該怎麼做

這套工作流程已在 10 個以上的 Claude 實例同時運行的情況下測試過。我們的建議：

• 最多 10 個代理：可以與每個代理進行深度協作
• 超過 10 個：不建議

限制因素不是工作流程，而是人的注意力和決策品質。管理超過 10 個代理時，你有可能在審查檢查點成為瓶頸，決策品質也會開始下降。

經典的「兩個披薩團隊」原則在這裡同樣適用。限制人類團隊規模的那些限制，同樣限制了一個人能有效管理的 AI 代理數量。

我目前正在探索 8×8 的兩層團隊結構，以便在超過 10 個代理的情況下擴展，但尚未發展出有效的實踐方法。有具體成果時我會再分享……

當 AI 成為團隊的一部分，VM0 開發工作流程改變了我們對軟體開發的思考方式。

當你把 AI 代理當作團隊成員而非工具來對待時，一切都會水到渠成。GitHub 成為你團隊的共享記憶體。Issues 成為工作項目。PRs 成為可交付成果。而你成為團隊領導者，專注於架構、方向和品質，讓你的 AI 團隊負責實作。

這就是我們在 2 個月內發布 404 個版本的方式。也是你如何用 AI 擴展自己的開發能力的方法。