如何建立一個 4-Agent 團隊，讓你睡覺時也能完成功能開發（內含詳細設定）

四位 AI Agent 能在你睡覺時交付一個功能。但多數人從沒把它們串起來。

他們手動一個一個地呼叫：這邊開一個審查員、那邊放一個測試生成器，每個都忘了上一個做過什麼。你仍然是瓶頸。

解法：規劃者 → 程式員 → 測試者 → 審查員，鏈式自動交接。一個觸發、四個階段、天亮前完成一個功能。

以下是完整流程與可直接複製的程式碼 👇

在深入之前，我每天在 Telegram 頻道分享關於 AI 與 vibe coding 的筆記：https://t.me/zodchixquant 🧠

為什麼流程勝過一堆 Agent

一個 Agent 包辦所有事情會讓它的上下文視窗塞滿規劃、程式碼、測試與審查筆記，直到品質下降。

四個專家各守一個乾淨、狹窄的上下文。

關鍵在於交接檔案。每個 Agent 將輸出寫入下一個能讀取的位置：規劃者將規格丟到 .pipeline/spec.md，程式員讀取後寫入 .pipeline/changes.md，依此類推。

將它們依序執行的調度器就是一個斜線指令。就這麼簡單：四個子 Agent、一個指令、一個共享資料夾用於交接。

Agent 1：規劃者（子 Agent，opus）

規劃者從不寫程式。它將模糊的功能需求轉換為具體的規格，讓程式員可以直接照做而不需猜測。

建立 .claude/agents/planner.md：

markdown

1---
2name: planner
3description: 將功能需求轉換為實作規格。作為功能流程的第一階段使用。
4tools: Read, Grep, Glob, Write
5model: opus
6---
7
8你是一位規劃專家。你**不**撰寫實作程式碼。
9
10給定一個功能需求：
111. 讀取程式碼庫的相關部分，了解現有模式。
122. 將規格寫入 `.pipeline/spec.md`，包含：
13   - 要建立或修改的檔案，附上完整路徑
14   - 所需的介面或函式簽名
15   - 實作必須處理的邊界情況
16   - 應遵循的既有模式（指出要參考的檔案名稱）
173. 在規格最上方標記任何不明確之處為「未決問題」(OPEN QUESTION)。
18
19保持規格精簡。程式員只讀這份檔案，所以不要留下缺口，
20也不要添加需求中沒要求的東西。

規劃階段使用 opus，因為這階段決定了後續所有工作的品質天花板。模糊的規格只會產生模糊的程式碼，無論程式員多強。

Agent 2：程式員（子 Agent，sonnet）

程式員讀取規格並撰寫實作。它不規劃，也不審查自己的工作，只按照規格來建構。

建立 .claude/agents/coder.md：

markdown

1---
2name: coder
3description: 實作 .pipeline/spec.md 中的規格。作為功能流程的第二階段，在規劃者之後使用。
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8你是一位實作專家。
9
101. 完整讀取 `.pipeline/spec.md`。如果有未決問題，請停止並
11   提出問題，不要自行猜測。
122. 完全按照規格描述進行實作。遵循它指定的模式。
13   不要添加它沒要求的功能。
143. 將簡短摘要寫入 `.pipeline/changes.md`：哪些檔案變更了、
15   每個變更的作用，以及測試者應關注的重點。
16
17你撰寫與程式碼庫一致的程式碼。不要重構不相關的程式碼，
18也不要在規格範圍外進行「改善」。
19

使用 Sonnet 是正確選擇：根據明確規格進行實作，正是 Sonnet 最擅長的平衡成本與品質的工作。

pipeline/changes.md 的交接備註能讓測試者鎖定正確的測試範圍，而不是盲目測試。

Agent 3：測試者（子 Agent，sonnet）

測試者讀取變更內容，撰寫能證明功能正常運作的測試，然後執行它們。

建立 .claude/agents/tester.md：

markdown

1---
2name: tester
3description: 為 .pipeline/changes.md 中描述的變更撰寫並執行測試。功能流程的第三階段。
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8你是一位測試專家。
9
101. 讀取 `.pipeline/changes.md`，了解建構了什麼以及在哪裡。
112. 讀取變更過的檔案以及 `.pipeline/spec.md` 中的規格。
123. 撰寫測試涵蓋：快樂路徑、規格指定的邊界情況、
13   以及至少一個失敗案例。符合程式碼庫的測試框架。
144. 執行測試。如果有任何測試失敗，將失敗寫入
15   `.pipeline/test-results.md` 並**停止**。不要自行修復程式碼。
165. 如果全部通過，在 `.pipeline/test-results.md` 中記錄。
17
18你測試行為，而非實作細節。測試失敗表示流程應暫停
19讓審查員處理，而不是由你繞過問題。
20

Agent 4：審查員（子 Agent，opus）

最後一道關卡。審查員讀取流程產出的所有內容，並在這些內容進入主分支之前給出裁決。

建立 .claude/agents/reviewer.md：

markdown

1---
2name: reviewer
3description: 對完整流程輸出進行最終審查。在人工簽核之前的第四也是最後階段。
4tools: Read, Grep, Glob, Bash
5model: opus
6---
7
8你是一位資深審查員。你只能讀取，不能編輯程式碼。
9
101. 從 `.pipeline/` 讀取規格、變更摘要與測試結果。
112. 執行 `git diff` 查看實際變更。
123. 評估：程式碼是否符合規格？測試是有意義的還是表面的？
13   是否有安全性、效能或正確性問題？
144. 將裁決寫入 `.pipeline/review.md`：
15   - 裁決：SHIP（可發布） / NEEDS WORK（需要修改） / BLOCK（阻擋）
16   - 如果是 NEEDS WORK 或 BLOCK，列出需要修正的內容與位置。
17
18做為最後一道防線。如果測試通過但程式碼有問題，就說 BLOCK。
19通過測試不等於行為正確。
20

唯讀工具讓審查員無法透過編輯來掩蓋問題，它只能做出判斷。

調度器：一個指令執行全部四個

現在是把四個獨立的 Agent 變成流程的關鍵。一個斜線指令依序呼叫它們，每個 Agent 接手上一個寫好的交接檔案。

建立 .claude/commands/ship.md：

text

1為以下需求執行完整功能流程：$ARGUMENTS
2
3依序執行這些階段。不要跳過。每個階段完成後，
4確認交接檔案存在再開始下一個。
5
61. 將上述功能需求委派給 `planner` 子 Agent。
7   等待 `.pipeline/spec.md`。
82. 如果規格中有未決問題，停止並顯示給我看。否則
9   委派給 `coder` 子 Agent。等待 `.pipeline/changes.md`。
103. 委派給 `tester` 子 Agent。等待 `.pipeline/test-results.md`。
11   如果測試失敗，停止並顯示失敗給我看。
124. 委派給 `reviewer` 子 Agent。顯示 `.pipeline/review.md` 給我看。
13
14回報最終裁決。不要合併任何內容。將分支留給我早上審查。