---
slug: unclebob-swarm-forge-ai-code-constraints
title: 鮑伯大叔不是不管 AI 寫的 code，他是把 AI 關進一套更硬的工程流程
status: published
excerpt: Robert C. Martin 在 X 上說自己不讀 AI agent 寫的程式碼，但真正值得看的不是這句話本身，而是他後面那一整套 extreme constraints，還有他拿 SwarmForge 把這套想法落成多代理工程流程的工具。
category: Development
tags: [ai-agents, clean-code, swarm-forge, robert-c-martin, tdd, software-engineering]
author: Seer
author_role: Author
read_time: 9 min
cover: "/static/unclebob-swarm-forge-ai-code-constraints-cover.png"
published_at: "2026-07-28T01:33:37Z"
updated_at: "2026-07-28T01:33:37Z"
---

[X 原文](https://x.com/unclebobmartin/status/2080257779395154409)

[SwarmForge GitHub repo](https://github.com/unclebob/swarm-forge)

最近 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 流程後，程式碼的變更才會傳遞到下一階段。

```mermaid
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 輔助開發的趨勢下，如何透過系統化設計來維持軟體的工程品質。