VM0 開發工作流程：像管理團隊一樣管理智能體

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

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

因此，VM0 開發工作流程的設計理念，正是借鏡經典的軟體工程團隊管理實踐。

我們用 GitHub Issues 追蹤工作、用 Pull Requests 進行程式碼審查與合併，並用 GitHub Actions 處理自動化。在兩個月期間，這套流程幫助我們交付了 404 個版本，撰寫了超過 230,000 行程式碼。

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

實際運作的 AI 驅動開發流程

當你同時協調多個智能體時，瓶頸不是模型能不能寫程式，而是人類的認知負荷。

這個工作流程包含 14 個斜線指令，分為三層：深度探索、議題管理、PR 管理。

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

需求對齊

人類開啟一個 Claude 對話，從 /deep-research 開始。Claude 從程式碼庫、文件和相關脈絡中收集事實。我們討論發現，並對齊實際要解決的問題。
方案探索

使用 /deep-innovate，Claude 提出多種可能方向及其權衡。我們討論、篩選並選定方向。
建立議題

我們用 /issue-create 在 GitHub 建立議題。人類審查議題，確保需求被明確記錄。
規劃與核准

用 /issue-plan 讓 Claude 繼續工作。Claude 會自動執行完整的深度探索流程，並將結果貼到議題，包括：
1. 來自 /deep-research 的發現
2. 來自 /deep-innovate 的比較
3. 來自 /deep-plan 的具體實作計畫
實作

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

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

人類會在三個檢查點介入：需求、方向與驗收。其他步驟皆自動執行。

心態轉變：你正在帶領一支 AI 開發團隊

我意識到需要結構化工作流程的那一刻，是當我增加更多 Claude 對話時，事情反而變得更混亂。我同時執行越多實例，就越難追蹤每個實例在做什麼、工作進度到哪裡、哪些決策已經做出。

沒有外部工具，我根本無法同時管理那麼多 Claude 實例。這時我才明白：這不是 AI 問題，而是管理問題。

GitHub 本來就是軟體開發協作的自然工具，所以我沒有發明新東西，而是把 Claude 當作人類隊友來對待。這麼做後，我的管理能力突然就擴展起來了。

十年的專案與團隊管理經驗，終於在這個新情境下派上用場。把 Claude 當作團隊成員，把 GitHub 當作我們的溝通與管理空間，整個系統又變得可控。

一個好的團隊領導知道何時介入、何時放手：

檢查點	我做什麼	AI 做什麼
需求	對齊問題、釐清範圍	研究程式碼庫、收集脈絡
方向	審查發現、核准方法	提出 2-3 方案、評估權衡
驗收	審查 PR、確認品質	實作、測試、修正 CI

這正是高效軟體團隊的運作方式。我不會微觀管理開發者，而是設定明確需求、審查關鍵決策、驗證最終成果。管理智能體也是同樣原則。

深度探索流程強制結構化、慢思考

深度探索工作流程強制在實作前進行深思熟慮。有時 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 issue 解決了這個問題。每個議題都會顯示：

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

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

當工作完成時，我不需要記得對話內容，只要打開議題，就能看到完整、結構化的紀錄。

智能體間的交接

因為所有脈絡都存在 GitHub，工作可以在智能體間無縫轉移：

一個智能體建立議題或 PR
另一個智能體稍後用 /deep-research issue 123、/issue-plan 123 或 /deep-research PR 124 繼續

對於長討論，/issue-compact 會把所有內容整合成乾淨的議題內容。這讓人類與 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-create`	根據對話脈絡建立議題
`/issue-bug`	建立含重現步驟的錯誤回報
`/issue-feature`	建立聚焦於需求的功能請求
`/issue-plan`	執行完整深度探索流程，將結果貼到議題
`/issue-action`	人類核准後繼續實作
`/issue-compact`	整合議題內容與留言以利交接

PR 指令

指令	目的
`/pr-check`	監控 CI 流程，自動修正並重試最多 3 次
`/pr-review`	逐筆審查 PR，檢查是否符合專案標準
`/pr-comment`	將對話摘要寫入 PR 留言

開始使用

從簡單開始：你的第一個任務可用 /issue-create → /issue-plan → /issue-action
複雜任務加上深度探索：需求不明或技術複雜時，從 /deep-research 開始
逐步擴展：隨著你熟悉審查節奏，逐步增加 Claude 實例
信任流程：讓 Claude 在檢查點間自動執行

這個流程設計為可漸進採用。你不需要一開始就用上全部 14 個指令。先從基本議題流程開始，隨著信心提升再加入深度探索與平行作業。

擴展考量：當你有更多智能體時該怎麼做

這個流程已在 10+ 個 Claude 實例同時運作下測試過。我們的建議：

最多 10 個智能體：每個都能深入協作
超過 10：不建議

限制因素不是流程，而是人類的注意力與決策品質。當你管理超過 10 個智能體時，自己會成為審查瓶頸，決策品質也會下降。

經典的「兩個披薩團隊」原則在這裡同樣適用。限制人類團隊規模的因素，也同樣限制一個人能有效管理的智能體數量。

我目前正在嘗試 8×8 的雙層團隊結構，以擴展到超過 10 個智能體，但尚未發展出有效實踐。等有具體成果會再分享…

VM0 開發工作流程改變了我們對 AI 參與團隊時軟體開發的思維。

當你把智能體當作團隊成員而非工具時，一切就會順暢。GitHub 成為團隊的共享記憶體，Issue 變成工作項目，PR 變成交付物。而你則成為團隊領導，專注於架構、方向與品質，讓 AI 團隊負責實作。

這就是我們在 2 個月內交付 404 個版本的方法。你也可以用這種方式，讓 AI 幫你擴展開發規模。