四位一體：我如何用多個 AI 模型組成一人開發團隊

我每天的開發環境長這樣：十個 terminal 同時開著，每一個終端機裡 Claude 在主線拆任務寫 code、Codex 在旁邊做 code review 和寫測試、Gemini 負責技術調查和風險分析、我在中間做最終決策。這不是實驗，是我過去幾個月每天在用的工作流。

這篇文章記錄我如何把多個 AI 模型組成一個有結構的協作團隊，以及為什麼我認為「多 LLM 協作」不是噱頭，而是一人團隊能做到十人團隊產出的關鍵。

為什麼不只用一個 AI？

大多數人用 AI 的方式是：開一個 ChatGPT 視窗，什麼都問它。這就像你的團隊只有一個人，他既要寫 code、又要 review 自己的 code、又要做技術調查、又要做架構決策。

問題很明顯：自己 review 自己，看不到盲點。

在真實的軟體團隊裡，我們有明確的角色分工：PM 拆需求、工程師寫 code、另一個工程師 review、QA 寫測試。每個角色帶著不同的視角看同一件事，這才能確保品質。

我把同樣的邏輯套到 AI 協作上。

四位一體：角色與分工

我的協作模型叫做「四位一體」，四個角色各有明確的職責和權限邊界：

人類（我）— 最終決策者

擁有 veto 權。任何 AI 都不能越權做最終決策。我決定做什麼、不做什麼、先做什麼。AI 提供選項和建議，我拍板。

Claude — 總指揮 / Orchestrator

負責任務拆解、架構設計、跨檔案整合。收到需求後先拆解再動手，判斷何時需要呼叫 Gemini 做調查、何時該讓 Codex 來寫 code 或 review。就像團隊裡的 Tech Lead，看全局、分任務。

Codex — 實作與 Review 專家

高品質的程式碼產出與第二意見。Claude 寫的 code，Codex review；Codex 寫的 code，Claude review。互相看，不自己看自己。測試案例預設由 Codex 寫，commit 前必須經過 Codex pre-commit review。

Gemini — 技術調查員

定位是技術顧問，不是實作者。當遇到架構選型、風險評估、技術疑難時，交給 Gemini 做深度分析。所有 Gemini 的輸出都視為「未驗證意見」——它提供線索，不做決定。

一個真實的工作流範例

昨天晚上，朋友們在壓測我的程式學習平台，幾個小時內回報了一連串問題：shell 引擎的 prototype pollution 漏洞、Markdown 沒渲染、安全性漏洞。

以下是四位一體怎麼處理的：

第一步：Claude 拆解問題

收到多個 bug report 後，Claude 先分類、排優先級：P0 安全漏洞（分數偽造、路徑穿越）、P1 功能 bug（prototype pollution、Markdown 渲染）、P2 測試覆蓋不足。

第二步：Codex 做安全審查

把安全修復的 code 丟給 Codex review，它抓出三個問題：分數驗證沒綁答案（客戶端根本沒送答案內容）、courseId 沒擋路徑穿越（../ 可以逃出目錄）、admin middleware 太窄（只擋 /admin 不擋 /admin/users）。

第三步：Claude 修復 + Codex 寫測試

Claude 根據 Codex 的 review 修復程式碼，然後 Codex 寫了 105 個 shell 引擎單元測試，覆蓋所有指令、管線操作、重導向、prototype pollution 防護。測試跑完，從 15 個測試變成 120 個。

第四步：Gemini 評估架構風險

在整個修復過程中，遇到技術選型問題時（例如：server-side 分數驗證該驗到什麼程度？），交給 Gemini 分析利弊，再由我做最終決定。

整個過程不到三個小時，一個人完成了通常需要 2-3 個工程師一天的工作量。

關鍵設計原則

1. 權限邊界比 prompt 重要

我不靠「請你不要亂改 code」這種 prompt 來控制 AI。我設計明確的權限邊界：Claude 可以寫 code 但不能自行 commit、Gemini 只做調查不做實作、Codex 負責 review 但最終是否採納由我決定。

就像軟體系統的權限設計：不信任 prompt，信任權限邊界。

2. 交叉驗證是品質保證

Claude 寫的 code，Codex review。Codex 寫的 code，Claude review。Gemini 提供的技術建議，Claude 和 Codex 各自驗證。多個 AI 結論矛盾時，標註衝突點再由我裁決。

這跟軟體團隊的 code review 文化一樣——重點不是找 bug，是帶入不同視角。

3. 失控防護機制

三個觸發條件會讓我立即暫停 AI 協作：

• AI 之間的結論衝突無法歸因
• Codex 跨層修改（改了不該改的東西）
• Gemini 提供的資訊無法驗證

暫停後由我重新定義問題。寧可慢一步，不要讓 AI 帶著錯誤的假設往前衝。

4. 同一個錯誤不試第三次

同一技術問題連續嘗試兩次無進展，必須停下來問：「現在真正的驗證目標是什麼？」同類 shell command 失敗兩次，禁止盲目重試，改查文件或呼叫 Gemini 調查。

這條規則省下了大量的 token 和時間。AI 最浪費資源的行為就是在錯誤的方向上重複嘗試。

這跟 Agentic Workflow 有什麼關係？

四位一體本質上就是一個 agentic workflow：多個 agent 各有角色、各有工具、透過 orchestrator 協調，人類在 loop 中做關鍵決策。

差別在於，市面上大多數 agentic framework 是「寫 code 讓 agent 自動跑」，而我的做法是「人在迴圈中，即時調度」。這在現階段更實用——因為 AI 還不夠可靠到可以全自動，但已經夠強到可以大幅放大一個人的產出。

我把這個工作流用在：

• 2ch.tw：從零建構的匿名討論平台，全端架構 + 內容審核 + SEO
• GEO Checker：AI 時代的 SEO 分析工具
• Learn with Cypher：互動式程式學習平台，含瀏覽器端執行環境
• 公司內部的 AI PoC 專案

每一個都是一人團隊的產出，每一個都在 production 上跑。

給想嘗試的人的建議

不要一開始就追求自動化。先手動跑幾週，感受每個 AI 的強項和弱點，建立判斷力。自動化是最後一步，不是第一步。

角色定義比工具選擇重要。不管你用 Claude、GPT、Gemini 還是其他模型，關鍵是你有沒有想清楚「誰負責什麼、誰 review 誰、什麼時候該停」。

人類的判斷力是整個系統的瓶頸，也是護城河。AI 可以寫 code、可以調查、可以 review，但「這個功能該不該做」、「這個風險可不可以接受」、「現在該往哪個方向走」——這些決策沒辦法外包。

四位一體不是終點。隨著 AI 能力進步，角色分工會持續演進。但核心原則不會變：明確分工、交叉驗證、人類在 loop 中。

我是江中喬（Cypher），AI / Agentic PM + Tech Lead。更多 AI 協作實戰紀錄在這個 blog，也歡迎到 card.chiba.tw 看我的其他作品。