「我不再看 code」很容易被讀成放棄 code review。Robert C. Martin（Uncle Bob）真正提出的，是把審查面往上移：人先定義一份可驗證的 source，agent 再負責產生與整理實作，最後由測試、架構與品質閘門留下證據。

這個說法在最近一個月的討論裡重新爆開；例如 r/ExperiencedDevs 的討論在 2026 年 8 月 22 日累積 201 分、203 則留言，焦點卻不是「哪個模型最強」，而是大 PR 如何讓人類根本無法審查。至於 7 月 23 日那則常被轉述的回覆與完整流程，主要細節可先看 Quid Pro Quo 的整理；它是二手重建，不是 Martin 的原始頁面。

他改的不是責任，是審查面

在 Clean Coders Agentic Discipline Part 2 裡，Martin 把「source」定義成建立系統的高層文件，並示範同一份描述如何被重建成五種語言與平台。他的前提是：實作 code 已經是 AI 的領域，人應該守住意圖、限制與可觀察結果。

所以 review 不會消失，只是從逐行閱讀改成檢查幾個外部訊號：需求是否完整、測試是否真的能失敗、模組依賴是否合理、變異測試是否抓得到錯誤、最終 UI 是否符合原始程序。這些訊號能減少注意力成本，但不能自動回答商業規則、資安、效能或可用性問題。

Swarm Forge 的六段品質閘門

Part 6 描述一條由六種角色接力的 pipeline。每個角色在隔離的 Git worktree 工作，交付的是下一個角色可以重跑的證據：

角色做什麼交付證據
Specifier把 Story 寫成 Gherkin acceptance tests，並補一份手動 UI QA 程序可重跑的情境與 QA checklist
Coder實作功能、unit tests 與 acceptance harness所有 Gherkin 測試通過的 worktree
Cleaner以 DRY 與 CRAP 等品質規則反覆重構 production code 和 tests品質報告與通過的測試
Architect檢查模組邊界、dependency graph，必要時補 property-based tests邊界審查與 invariant tests
Hardener對語言層與 Gherkin 層執行 mutation testingsurvivor mutants 與處置決策
QA把原始 QA 程序轉成自動化 UI 操作並驗證成品UI 執行結果對應原始程序

這不是「六個聊天視窗一起寫 code」。它比較像一串品質閘門：前一關沒有可驗證的輸出，下一關就沒有資格開始。

用 Warrant 約束一個 Story 的交付

2026-10-02 更新：原先採用的 ForgeFlow／PraxisBound 已封存，現在由 Warrant 接替。Warrant 把工作限定在一份人類核准的 Story，完成證據則來自儲存庫在 AGENTS.md 指定的唯一驗證命令與逐條驗收觀察。它不規定 agent 角色或人工審查方式；下面是我的工作流示意，角色分工由團隊選擇：

story: "specs/stories/<slug>.md：Goal、Out of Scope、Acceptance Criteria"
source: "approved Story + business rules + constraints"
roles:
  specifier: "補齊可重跑情境與必要的 QA procedure"
  coder: "實作與測試，直到 acceptance 通過"
  cleaner: "只在有明確品質訊號時重構"
  architect: "檢查邊界與依賴，不替人做產品決策"
  hardener: "repository 能支援才執行 mutation/property checks"
  qa: "用原始程序驗證使用者可觀察行為"
canonical_gate: "AGENTS.md 宣告的唯一驗證命令（例如 make verify）"
completion_report: "逐條驗收證據、跳過或受阻的檢查、殘餘風險"
human_gate: "確認產品意圖、架構與風險後才 merge"

落地時先只做一個 Story。若既有驗證已能阻擋一種錯誤，就不為了湊角色增加 agent；若某種失敗重複出現，才新增一個能留下獨立證據的 specialist。採用時以 Warrant 規則區塊 為準：Agent 不得改需求、放寬驗收標準或擴大範圍，任何一條驗收條件缺少通過證據，就只能回報部分完成。Warrant 本身提供規則，強制力仍由採用端的 CI 與人工審查負責。

指標是閘門，不是判決

社群反彈其實指出同一個盲點。那篇 8 月的 Reddit 討論裡，u/siktech101 留下「Software development just keeps getting worse.」（359 分）；u/jvlomax 則說自己曾經收進 3,000 行 PR，後來改成超過約 600 行就關掉（164 分）。Hacker News 的「Uncle Bob: It’s Over」討論也有人提醒，重構、非同步 bug 與錯誤 mock 仍需要人類追問。

我的判斷是：PR 大小、coverage、CRAP 或 mutation score 都是很好的停止訊號，卻不是「可以不用理解系統」的通行證。指標只知道它被定義的失敗；產品語意與未定義的風險，仍要由熟悉上下文的人負責。這也是 Grady Booch 的批評整理所指出的界線：metrics 看不到完整的 business context、security 與 performance。

下一步：先做一個可回滾 Story

挑一個兩小時內能完成、失敗可撤回的 Story，留下四樣東西：

  1. 一份寫清楚規則與錯誤情境的 source。
  2. 在 AGENTS.md 宣告一個模型外可執行的驗證命令（可沿用既有 make verify），並讓 CI 執行同一命令。
  3. 一份逐條驗收證據、跳過或受阻的檢查與殘餘風險的完成回報。
  4. 一個明確的 human stop：意圖、架構、資安或效能有疑問就停止，不讓 agent 自己批准。

做完再問：哪一種錯誤仍只能靠人看？那個答案，才是下一個值得加入的 agent。

參考資料