Code & Cast 這個專案我是用多 Agent 工作流程在開發的。不是那種「叫 Claude 幫我寫程式」的方式，而是真的設計了一個分階段的 pipeline，每個階段有專屬的 Agent，沒有我明確核准就不能進下一階段。
這篇記錄實際發生的事情。
Pipeline 架構
整個流程分五個階段，每個階段基本上都有一對 Agent 互相辯論：
PM (alpha + beta 辯論)
→ Architect (alpha + beta 辯論)
→ Designer
→ Engineer (alpha=domain, beta=infra, gamma=presentation)
→ QA (alpha=UX, beta=技術)每個階段結束後強制停下來。我看輸出。我說「approved」或者「這邊不對」。然後才進下一階段。
這個人工審查關卡，最後證明是整個流程裡最重要的設計。
為什麼每個階段要兩個 Agent？
這個是意外發現的。一開始我讓 pm-alpha 寫了一份 PRD，看起來沒問題，然後讓 pm-beta 獨立寫一份。結果兩個 Agent 對「核心使用者問題是什麼」這件事根本意見不同。
辯論過程迫使兩個 Agent 都要替自己的邏輯辯護。合併後的輸出明顯比任何一份草稿更嚴謹 — 邊界情況被挖出來，假設被質疑。現在凡是需要推理判斷的階段，我都跑配對 Agent。
工程師這一層的分法不太一樣。engineer-alpha 負責 domain 層，beta 負責 infra 和 queries，gamma 負責 presentation。開始之前，alpha 先做依賴分析 — 每個工程師實際上需要哪些檔案？這樣才能避免兩個 Agent 互踩或者因為缺少型別定義而卡住。
engineer-alpha: 先分析依賴關係
→ domain layer（types、entities、zod schemas）
engineer-beta: infra + queries
→ 依賴 alpha 的 domain types
engineer-gamma: pages + components
→ 依賴 beta 的 query 回傳型別沒有這個前置分析步驟的時候，我一直遇到 gamma 在 import alpha 還沒寫完的型別這種競態問題。
人工關卡不能省
早期試過把 PM 和 Architect 之間的關卡拿掉，想說加速一下。結果很慘。
兩個 Architect Agent 在一份 PRD 的一個模糊細節上，各自做了不同的假設，然後把整個 context 預算都燒在根本上不相容的兩套架構設計。那個模糊的地方是關於 session 怎麼識別的 — 我大概三十秒就能在 PRD 審查時抓到，但我跳過了那個關卡。
兩個 Agent 辯論、收斂、然後一起走錯方向，比一個 Agent 走錯方向還糟糕。因為「它們都同意了」讓問題更難被察覺。
關卡存在是有原因的：下游階段是建立在上游決策之上的。PM 錯了 10%，Architect 會放大這個錯誤，到 Engineering 的時候就在實作一個根本不是我要的東西。
QA 找到測試沒抓到的問題
Engineering 完成的判定條件是 npm run build 和 npm run test 都過。兩個都過了。然後 QA 開始跑使用者旅程，找到了真實問題 — zh-TW 路由上的頁面標題還是英文、精選文章卡片根據語系顯示了不同格式的日期。
這些都不是型別錯誤。都不會讓 build 失敗。是那種你真的用瀏覽器逛過網站才會發現的問題。
qa-alpha 負責 UX 和使用者旅程測試 — 它會像一個真實使用者一樣走過每個流程。qa-beta 負責架構合規和邏輯 bug。兩個互相審查對方的發現，再合寫最終的 QA 報告。這個組合找出了任何一個單獨測試都抓不到的東西。
會怎麼調整
這個 pipeline 比直接叫 Claude 實作慢多了。跑完一整個完整迭代 — 從 PM 到 QA — 大概要花 3-4 倍的時間。值不值得，完全取決於你有多在意第一次就做對。
對 Code & Cast 來說，我在意。我在公開寫這個專案，不想花週末修一個當初倉促決定的架構問題。
真正有差的不是 Agent 的數量，而是辯論結構加上人工關卡的組合。一個 Agent 寫完 PRD 直接開始 coding，產出的東西就是普通。兩個 Agent 辯論 PRD，我審查，再讓兩個 Agent 在上面辯論架構 — 複利效應是真實存在的。
整套設定我已經抽成了一個可重用的模板（my_ai-coding-template），下次開新專案可以直接用同樣的結構，不用從頭重建 Agent 定義。光這一步，下個專案大概就省了幾個小時。