我用 AI 多代理蓋軟體：一個指揮官、四個廉價工人

這篇在講什麼

一個人不可能分身去當 PM、工程師、QA、客服——但一套 AI 多代理工作流可以。這篇講我怎麼用「一個指揮官 + 一群廉價執行者」的架構，一個人把 Learning Hub、客訴自動化這些系統蓋出來，而且品質有把關。

核心架構：貴的負責想，便宜的負責做

AI 模型不是只有一種。貴的（例如 Claude、Codex）很會判斷跟設計，但貴；便宜的（例如 Gemini 免費額度）跑量很划算，但容易出錯。

我的做法是——不要讓便宜的代理去做貴代理該做的事，反之亦然：

              ┌───────────────┐
              │  指揮官 (貴)   │ ← 架構決策、拆工單、審核、仲裁
              └──────┬────────┘
      ┌──────────────┼──────────────┐
      ▼              ▼              ▼
 執行者 A (廉)   執行者 B (廉)   執行者 C (廉)
 寫程式         寫測試         查文檔/研究

指揮官負責把任務拆成夠小的工單，派下去，然後驗收。執行者拿到的是「不超過一次能做完」的明確任務，做完回報，指揮官檢查——不對就打回。

三種執行者，三種用法

廉價執行者：量大、機械、可並行——寫測試、抓資料、跑單元測試。
無頭代理：只管「盡量做」，做完就回報，不等人。適合長任務、後台批次。
全權代理：只有當我清楚知道「做了就是對的」時才下放——例如「把這個 README 轉成繁體中文版」。

最關鍵的設計：驗證不自驗

這是我從第一個專案就死守的鐵則，也是整個工作流品質的來源：

自己寫的碼，不能自己驗。

聽起來很違反直覺——「我自己寫的，我不驗誰驗？」但重點是：寫的人會對自己的錯誤免疫。寫的人會不自覺地重跑「他以為在驗」的測試，但測的其實是同一條他早就確定沒問題的路徑。

所以我規定：寫程式的人 永遠不能驗自己寫的那塊。要嘛交給另一個 fresh-context 代理（完全不認識這份程式的人）驗，要嘛實跑測試驗。驗收結果逐筆記錄，留下軌跡。

測驗策略：免費跑量，錯誤摘要 <5 行

測試是整個工作流裡最大的「量」，也是成本最容易失控的地方。我的策略：

全部用免費的 subprocess 跑——pytest 直跑，零 token 消耗；
失敗摘要限制在 5 行以內——失敗訊息太長就截斷，只把重點餵回 context，避免把整個測試輸出倒進對話，浪費 token 又淹沒重點；
重跑前「把失敗當作最有價值的訊息」，先看失敗軌跡再動手。

踩過的坑：代理把「看起來完成」當成「真的完成」

便宜代理最危險的不是錯，是**「看起來很像對」**。

舉例：我派廉價代理「把 X 功能完成」，它跑了一輪測試全綠就回報「完成」。但測試全綠，是因為測試本身寫得太弱——它可能根本沒測到主流程，或者測的是自己剛寫的假資料。

所以「驗證不自驗」不只是鐵則，它是防呆：驗收必須由不寫那份程式的人做，而且驗收要看「這測試到底測了什麼」，不是「綠不綠」。

結果：466 條測試，真的擋住過問題

Learning Hub 最後有 466 條離線測試，而且不是裝飾品——真抓到過 bug，例如「舊題目版本被誤當新題目發布」這種邏輯錯，就是測試先抓到的，而不是使用者。

當一個系統的測試數量能上千、又全部免費跑，品質保證就不再是「靠一個人小心」，而是靠流程。

這套工作流的錢花在哪

到目前為止，整年的 AI 預算控制在兩萬台幣以內：

貴的代理：按需、單發、刀口用（架構決策、仲裁、審查）
廉價代理：便宜量產（量大、可並行、不需判斷）
測試：免費跑量

關鍵不是「用最貴的模型」，而是「每個環節用對價位的模型」。省錢不是目的，是讓「貴的刀口」永遠有預算可用。

如果你好奇這些系統長什麼樣，下一篇我來講 Game Hub——AI 實戰教育引擎。