鮑伯大叔不是不管 AI 寫的 code，他是把 AI 關進一套更硬的工程流程

最近 Robert C. Martin（大家熟知的 Uncle Bob）在 X 上發表的一番話，引起不少討論：

My current strategy is to not read any of the code written by my agents.

That’s the only way I can take advantage of their productivity.

What I do instead is to surround the agents with extreme constraints.

不少人乍看之下，以為這位軟體工程大師向「Vibe Coding」妥協，甚至是在鼓吹放任 AI 隨意寫 code、放棄 Code Review。

然而，如果只看前兩句話就急著下結論，恐怕會看錯重點。

他想表達的並非放任品質流失，而是當 AI Agent 產出程式碼的速度大於人類閱讀極限時，傳統的「人眼逐行 Review」會成為開發鏈的瓶頸。若想將 AI 的產能轉化為實際價值，品質把關的機制就必須從「人眼看 Code」往外移，改以極端的約束（Extreme Constraints）來規範 AI。

釐清被誤讀的「不看 Code」

這並非在為未經測試的隨性編寫（Vibe Coding）背書，更不是宣稱開發流程不再需要審查。

在傳統軟體開發中，Code Review 是品質把關的核心。然而，當多個 Agent 同時產出程式碼時，開發者很難有精力逐行審查變數命名或邏輯。如果此時仍沿用「人眼讀碼」的流程，容易導致兩種結果：要麼人類審查速度成為限制產能的瓶頸，要麼 Code Review 流於形式。

Uncle Bob 的出發點是：既然人工看 Code 難以跟上 Agent 的速度，就必須將對品質的驗證，從「人眼視覺檢查」轉移到一整套自動化驗證機制上。

品質保證的轉移：從人眼審查到驗證鏈設計

將品質保證移交給工程機制，代表工程師的角色正在發生轉變。

Uncle Bob 在文中列出的約束條件包含：

Unit tests（單元測試）
Gherkin tests（行為驅動開發測試）
QA procedures（品質保證程序）
Quality metrics（品質指標）
Mutation testing（變異測試）
Test coverage（測試覆蓋率）

在此思維下，工程師的重心從挑剔語法與命名，轉向設計與建構這套驗證鏈。只要驗證機制設計完整，Agent 產出的程式碼若無法通過單元測試、變異測試或驗證管線（Acceptance Pipeline），就無法進入下一個階段。

SwarmForge：將方法論落地的開源工具

Uncle Bob 釋出了開源專案 unclebob/swarm-forge 來實踐這套想法。

swarm-forge 並非簡單的 Prompt 整理，也不是雲端 SaaS 服務。README 對其定位為：

A disciplined tmux-based agent orchestration platform that turns swarms of AI agents into reliable, professional software engineers.

這是一套在本地運行、基於 zsh、git worktree、tmux 與 Babashka 的 Agent 編排系統。其核心目的在於將「約束條件」、「角色分工」與「自動化交接協定（Handoff Protocol）」轉化為本地運行的工程工作流。

該專案的結構較為特別：main 分支僅用於文件說明（Documentary），真正可執行的工作流（Runnable Workflows）存放在專屬分支中（例如 two-pack、four-pack、six-pack 與 adversaries）。使用者需取得對應分支的程式碼並在本地執行 ./swarm 來啟動該系統。

從架構設計看 SwarmForge 如何約束 AI

從 swarm-forge 的設計細節，可以看出它是如何透過工程流程來約束 Agent：

1. 工作流分級：以分支代表流程強度

swarm-forge 中的 two-pack、four-pack、six-pack 分支，代表的是不同強度的工程流水線（Pipeline）。

以 four-pack 為例，系統劃分了四個角色：

specifier：負責將使用者意圖轉化為具體且可測試的 Gherkin 驗收規格（Acceptance Specs）。其 Prompt 規定，在將規格移交下一步前，必須先取得人類開發者的核可（Ask for Approval）。
coder：遵循 TDD（測試驅動開發）流程，撰寫單元測試與實作程式碼，以通過前述的驗收測試。此角色專注於讓測試通過，不負責重構與後續的品質檢驗。
refactorer：接手程式碼進行重構，並進行測試覆蓋率檢查、CRAP 指標分析、DRY 原則檢驗與變異測試（Mutation Testing）掃描。
architect：負責架構與相依性方向，進行防護硬化（Mutation Hardening），確認後發出完成通知。

若切換至 six-pack 分支，流程會細分為：specifier -> coder -> cleaner -> architect -> hardender -> QA。這種設計將品質閘門（Quality Gates）拆解，讓每個 Agent 專注於單一任務，避免角色混淆影響品質。

2. 檔案化交接協定（Handoff Protocol）

在多 Agent 協作中，若缺乏規範，Agent 之間的溝通容易導致資訊遺失或流程偏差。

swarm-forge 制定了一套基於檔案系統並由 Daemon（handoffd.bb）管理的交接協定（handoff-protocol.md）：

目錄驅動狀態變更：任務狀態由檔案所在的目錄決定，路徑包含 outbox、inbox、new、in_process、completed 與 failed。
標準化腳本：Agent 需透過特定的工具腳本（如 swarm_handoff.sh、ready_for_next.sh、done_with_current.sh）來推進流程。
無狀態通知：Agent 不直接向其他 Agent 發送自訂的 tmux 訊息。系統的 tmux 喚醒通知（Wake-up Message）僅作為無狀態的觸發訊號，提示目標 Agent 讀取交接目錄。

這項設計使交接過程均能記錄於檔案中，具備可追蹤性與確定性，避免了通訊混亂。

3. Git Worktree 與隔離環境

為了避免多個 Agent 同時修改相同檔案而產生衝突，swarm-forge 為每個角色建立專屬的 Git Worktree 與 Tmux Session。各個 Agent 在隔離的沙盒環境中運作，通過品質閘門並完成 Handoff 流程後，程式碼的變更才會傳遞到下一階段。

flowchart TB
  U["使用者意圖"] --> S["Specifier worktree"]
  S --> H{"人工核可規格？"}
  H -->|no| S
  H -->|yes| C["Coder worktree: TDD 實作"]
  C --> R["Refactorer worktree: 重構與品質檢查"]
  R --> A["Architect worktree: 架構與 hardening"]
  A --> D["完成通知"]
  F["Filesystem handoff + daemon"] -. specs / artifacts .-> C
  F -. changes / reports .-> R
  F -. reviewed output .-> A

此方法試圖解決的工程挑戰

目前關於 AI Agent 的討論多聚焦於模型能力與 Prompt 調校，而 Uncle Bob 關注的是更底層的軟體工程挑戰。

當多個 Agent 同時參與同一個專案的開發時，常面臨以下挑戰：

程式碼合併時產生衝突或覆蓋。
繞過關鍵的測試步驟以求快速產出。
程式碼雖然可運行，但內部架構缺乏維護性。
後期需要花費大量人力進行程式碼整理。

對此，Uncle Bob 的核心思路並非依賴更聰明的模型，而是建構工程流程上的約束。

這也反映出開發者角色的轉變：核心能力不再僅是撰寫程式碼的速度，而是如何設計驗證約束（Constraints）、設定品質閘門（Quality Gates）、制定交接協定（Handoff Protocols），以及編排整體工作流（Workflows）的架構設計能力。

結論：AI 開發模式下的工程紀律

Uncle Bob 所採用的「不讀 Agent 寫的程式碼」策略，並非向程式碼品質妥協。

相反地，正是因為減少了人眼逐行審查，他選擇將重點轉向工程制度、測試強度、角色邊界與交接流程的設計。

swarm-forge 的價值在於提供了一種具體的實踐參考：將基於約束、測試與角色分工的軟體工程方法論，轉化為一個在本地端可運行、可調整工作流的多 Agent 協作體系。這也為我們展示了在 AI 輔助開發的趨勢下，如何透過系統化設計來維持軟體的工程品質。