安安～我是 ChiYu～

AI 寫得很快，工程師為什麼反而更累？

AI Coding 最迷人的畫面，大概是需求才剛說完，Agent 已經開始新增檔案、補測試、修錯誤，幾分鐘後還很有自信地告訴你：「任務完成。」

接著你打開 Diff，心情就從科技奇蹟變成災後勘查。

這正是 Matt Pocock 訪談《Clean Code》作者 Robert C. Martin，也就是 Uncle Bob 時，最先碰到的矛盾。Agent 很快，卻會留下大量混亂；人類若繼續逐行清理，最後省下的打字時間，很可能全花在善後。

在這場 LIVE: Uncle Bob on Software Fundamentals in the Age of AI 裡，Uncle Bob 沒有把答案押在更長的 Prompt。他重新撿起 CRAP、變異測試、驗收測試與模組依賴檢查，把原本寫在文件裡的品質期待，改成 Agent 必須通過的機械化關卡。

我看完後一直在想：AI 改變了程式碼的生產方式，卻沒有替我們回答「怎樣才算正確」。工程師的工作重心正在移動，從親手產生每一行程式碼，移向定義邊界、設計回饋迴路、保存證據，以及對最後結果負責。

爛程式碼會把 Agent 的速度吃掉

Uncle Bob 一開始讓 Agent 參與既有專案時，確實感受到它的速度。然而 Agent 不斷留下他形容為 dog doo(狗大便) 的混亂，他得一直跟在後面整理。結果很諷刺：Agent 跑得很快，卻讓他本人變慢了。 05:15

更麻煩的情況發生在混亂持續累積之後。Agent 開始修改 A、弄壞 B，修好 B 又破壞其他地方，最後在同一批問題裡打轉。Uncle Bob 的觀察是，人類會被混亂程式碼拖累，Agent 也存在類似的極限；差別可能只在能忍受多少複雜度。 11:00

很多 AI Coding 展示只計算「第一次產出花了幾分鐘」，很少把後面的除錯、回歸、重構與驗收一起算進去。

計算開發速度時，應該從需求開始，一路算到成果可以被信任為止。

如果五分鐘產出功能，後面卻花一小時確認它沒有偷偷改壞其他行為，那就不能只拿五分鐘當成生產力成績。更糟的是，技術債還會留在 Repository 裡，讓下一次 Agent 工作得更慢、更不穩。

Prompt 裡的規則會失焦，工具不會假裝沒看到

遇到 Agent 亂寫，直覺反應通常是繼續擴充 AGENTS.md、CLAUDE.md 或 System Prompt：

  • 函式要短。
  • 必須遵循 Clean Code。
  • 不可以破壞架構。
  • 一定要補測試。
  • 修改前要先理解完整 Context。

規則越補越多，最後就得到一份比需求本身還長的 Agent 生存手冊。

Uncle Bob 也走過這條路。他發現模型會把這些規則逐漸當成參考指引；當 Context 越來越長，位在中間的規則更容易失去注意力，也就是訪談提到的 Lost in the Middle。 13:58

他的調整方式很直接：縮短初始 Prompt，把可以計算的規則交給確定性工具。 14:54

例如，與其只寫「不要建立循環依賴」，更可靠的做法是建立依賴檢查。只要違反規則，Build 或 CI 就失敗。Agent 可以替自己的設計找理由，卻不能把紅燈解釋成綠燈。

不過，工具只能判斷已被形式化的條件。測試通過、Coverage 達標與依賴方向正確，仍然無法自行證明需求理解正確、權限設計安全，或使用者真正得到想要的結果。

AI 讓過去太昂貴的品質技術重新有機會落地

訪談特別提到兩項早已存在，卻常因成本被團隊放棄的技術。

第一項是 CRAP 分數。它把函式的圈複雜度與測試覆蓋率放進同一個評估方式。函式路徑越多、覆蓋越不足，分數就越差。Uncle Bob 過去曾在大型專案執行分析，工具很快找出高風險函式，但人類沒有足夠時間逐一重構與補測試。 05:48

第二項是 變異測試。工具會故意改動程式邏輯，例如把 < 換成 >、把 == 換成 !=，再確認測試能不能抓到這個錯誤。程式已被改壞，測試卻仍然全綠，代表測試沒有真正守住那段行為。 06:57

過去的問題在於，變異測試可能執行很久，後面還有大量測試缺口要補。Agent 剛好很適合承擔這種重複、耗時，而且通過條件清楚的工作。Uncle Bob 讓 Agent 執行 CRAP 分析、清理程式，再跑變異測試並補上漏洞，形成自動化修復迴圈。 08:13

這個做法最打中我。AI 能更便宜地產生功能，也能更便宜地追求品質。

不過，CRAP、Coverage 與 Mutation Score 都是品質訊號，不能升格成萬能裁判。測試的 Oracle 如果一開始就錯了，Agent 只會非常勤奮地把錯誤答案保護得更完整。

五個 Agent 各守一關，比一個 Agent 自己說完成更可信

為了降低單一 Context 持續膨脹與偏航的風險，Uncle Bob 把工作拆成一條多 Agent 品質流水線：

flowchart LR
    A["人類需求"] --> B["Specifier<br/>Gherkin 與 QA 流程"]
    B --> C["Coder<br/>實作與基本測試"]
    C --> D["Cleaner<br/>CRAP 分析與重構"]
    D --> E["Hardener<br/>變異測試與補強"]
    E --> F["QA Agent<br/>系統級自動驗收"]
    F --> G["確定性結果<br/>交回人類判斷"]
  • Specifier：把人類需求轉成 Gherkin 驗收條件與 QA 流程。 20:37
  • Coder：完成實作與基本測試，讓驗收條件開始成立。
  • Cleaner：執行 CRAP 分析與 Code Review，清理實作者留下的混亂。 21:37
  • Hardener：執行變異測試，補強測試沒守住的分支與邊界。 21:50
  • QA Agent：把 QA 文件轉成可執行腳本，從系統外部取得確定性結果。 22:23

每個 Agent 只處理一種問題，Context 比較乾淨；實作者、清理者與驗收者分開，也能降低同一個 Agent 替自己的決定辯護到底的風險。

單一 Agent 可能五分鐘交出一份結果，完整流水線可能需要一小時。Uncle Bob 分享的效率數字來自他的個人實驗，缺少一致任務集與獨立評測，不能直接推廣成所有團隊都能取得相同倍數。 22:41

我會保留這個流程的分工精神，不會照表複製所有角色。小型、低風險修改如果也強制跑五個 Agent，流程成本很可能大於收益。角色數量應該跟風險、可回復性與驗證難度一起調整。

模組化會直接影響 Agent 能不能專心

自動化測試再多，也救不了責任混雜、依賴混亂的系統。

Uncle Bob 也提到，模組結構仍有不少工作需要他手動介入。他會詢問 Agent 模組如何互動，再重新設計真正的分區與溝通方式；他也建立架構檢視器與依賴規則檢查，限制哪些模組可以互相依賴。 26:19

Matt Pocock 在這裡帶入 John Ousterhout 的 Deep Module：用小而清楚的介面，隱藏大量內部複雜度。Agent 可以先理解介面與測試，不必每次把整個實作塞進 Context。 30:14

這和人類閱讀大型系統時的需求很像。好的模組會告訴你「這裡負責什麼、怎麼使用、可以依賴什麼」；差的模組則像把咖啡機、肥皂劇與資料庫交易全部塞進同一個房間，Agent 載入再大的 Context 也只會更困惑。

訪談也誠實保留了限制。Uncle Bob 已能用工具檢查既定依賴規則，卻還沒有成功把整套架構規劃自動化。 27:44

Agent 很擅長在邊界內執行；至於邊界該畫在哪裡，仍然需要長期系統經驗與業務判斷。

人類的工作紀律可以調整，品質價值不能一起丟掉

Uncle Bob 是 TDD 的堅定支持者，但他沒有要求 Agent 完整模仿人類的微觀節奏。他認為，人類先寫一個失敗測試、再補最少實作的紀律，源自人類的認知與工作方式；Agent 未必需要逐行重演同一套行為。 34:03

他保留的是這些品質要求：程式要能測試、測試要有效、複雜度要受控、依賴要合理，成果還要通過外部驗收。

新工具出現時，我們很容易掉進兩個極端：完整複製舊流程，或把舊原則全部丟掉。應該先檢查每項紀律原本要防止什麼風險，再決定 Agent 要照著同一個動作走，還是改用另一套能交出同等證據的流程。

規格要能引導下一步，別寫成 AI 最愛的華麗長文

Uncle Bob 對重度 Spec-Driven Development 的疑慮也很直接。他看見 Agent 很會寫計畫，計畫可以漂亮到像所有問題都已經被解決；真正進入實作後，未預期的細節仍會讓整套計畫崩解。 36:28

這段不能簡化成「不要規格」。他的流程裡明明就有 Specifier，還會產生 Gherkin 與 QA 文件。他質疑的是在動工前試圖窮盡全部細節，再期待 Agent 一次照表完成。

AI 已大幅降低修改程式的成本，因此訪談重新肯定短週期的敏捷節奏：先做一小段、取得回饋、調整設計、重構，再推進下一段。 41:16

我的看法是，規格的重量應該跟「做錯後多難回頭」一起增加：

  • 低風險、容易撤回的小修正，清楚驗收條件通常已經足夠。
  • 涉及多個模組的功能，需要固定名詞、範圍、契約與測試邊界。
  • 涉及權限、個資、金流、資料移轉或外部副作用，重要決策與驗收證據必須留下來，不能用「修改成本很低」合理化省略責任。

快速修改只代表技術操作更便宜，不代表錯誤造成的業務代價也一起歸零。

我整理出的 CLEAN 五原則：把信任拆成五項 User 責任

隨著這場訪談，我也順便提一下近期整理的 AI 開發時代下的 CLEAN 五原則。

CLEAN 承接《無瑕的程式碼 第二版》對 Code、Design、Architecture 與 Craftsmanship 的品質觀念，再結合我操作 AI Agent Coding 時反覆遇到的問題，整理成使用 AI Agent 的 User 應負責的五件事。它不是 Uncle Bob 在這場訪談或書中提出的框架，也不取代 Clean Code。

截至本文撰寫的 2026 年 8 月 31 日。我會在明天正式參加鐵人賽，也就是 2026 年 9 月 1 日開始，透過一系列 AI Coding 與 Clean Code 實作說明 CLEAN 如何形成。在那之前，先把五項原則各自要處理的問題放在這裡：

CLEAN 原則中文定位主要用途
C — Context-Aware Code情境感知先查證需求、Repository 規則、領域語言與既有行為，避免 Agent 把常見做法誤當成專案事實。
L — Localized Change局部變更限制同一批尚未驗證的修改與副作用，設定允許範圍、Checkpoint 與停止條件。
E — Explicit Intent and Boundaries意圖與邊界明確說清楚資料角色、契約、依賴方向、錯誤語意與外部副作用，減少 Agent 自行補完關鍵決策。
A — Auditable by Evidence實據可審保存 Prompt、起始版本、Diff、測試與工具輸出、失敗紀錄及人工裁決，讓完成宣告可以被重建與反駁。
N — Non-Surprising Behavior符合預期先固定可觀察行為與禁止改變項目，再依風險用 Unit、Acceptance、E2E、契約或並行測試驗收。

把五項原則放在同一張圖裡，User 仍然站在中央。Agent 負責執行，最後的接受權沒有跟著外包出去。

暖色技術圖解，中央工程師負責最終決策，周圍以 C、L、E、A、N 五個區塊呈現情境、局部變更、明確邊界、實據可審與符合預期

CLEAN 五原則總覽：User 負責定義與裁決，Agent 在邊界內執行

CLEAN 沒有固定執行順序，也不是交給 Agent 自己勾完的 Checklist。不同任務會同時用到多項原則，證據重量也會隨風險改變。

Agent 動手前，C 先把需求、Repository 規則與既有行為查清楚，E 再把契約、依賴方向與允許修改的邊界畫出來。

工程師檢查 Repository、需求與既有測試，接著確認契約與依賴方向，最後才讓 AI Agent 進入受控範圍工作

C＋E：先理解專案情境，再由 User 開啟允許 Agent 工作的邊界

例如，一次低風險的區域變數改名，可能只需要 E、L 與相關測試。涉及重複通知或資料一致性時，五項原則往往會一起出現：C 查清楚既有契約，E 定義交易與副作用邊界，N 固定不可重複通知的外部行為，L 控制修正範圍，A 保存並行時間線、測試與人工接受理由。

進入修改後，L 控制這一批 Diff 可以碰到哪裡，N 則守住使用者看得見的既有行為。一個管變更範圍，一個管外部結果。

AI Agent 只在局部程式碼範圍內修改，工程師透過停止點、測試與前後輸出比對確認既有行為維持一致

L＋N：限制修改範圍，同時驗證外部行為沒有意外改變

CLEAN 與訪談如何接在一起？

Uncle Bob 從工具面回答了這個問題：用 CRAP、變異測試、架構規則與系統驗收，把品質要求變成 Agent 無法略過的關卡。

CLEAN 則繼續追問 User 必須負責的部分：

  • 工具要檢查哪些條件，由誰定義？
  • 測試代表的外部答案是否正確？
  • Agent 可以修改哪些範圍，何時必須停下來？
  • 通過結果對應哪個版本、哪些輸入與哪些限制？
  • 哪些風險仍然沒有被工具涵蓋？

把兩者接起來，我目前會這樣做：

先由人定義 Context、邊界與可觀察行為，Agent 再在受控範圍內實作。工具反覆驗證能計算的條件；證據齊了，最後仍由人決定接受或拒絕結果。

A 把 Prompt、起始版本、Diff、測試、失敗紀錄與人工判斷串成一條可追溯的證據鏈。Agent 可以整理並提交證據，接受或拒絕結果的人仍然是 User。

AI Agent 提交包含 Prompt、版本、程式碼差異、測試與失敗紀錄的證據鏈，最後由工程師選擇接受或拒絕結果

A：從 Prompt、版本、Diff 與測試一路追溯到人工裁決

AGENTS.md、Skill 與 Policy 可以幫忙重複執行 C、L、E 的一部分；Build、Tests、Complexity 與 Dependency Gates 可以支援 A 與 N。這些工具都不能替 User 接受風險，也不能代替需求、授權與業務 Oracle。

我很認同 Uncle Bob 想把「信任程式碼」轉成「信任一組可重複驗證的證據」。但在高風險系統裡，我不會因為品質指標全綠，就全面停止抽查程式碼、威脅模型、權限路徑與資料生命週期。驗證方式可以依風險調整，責任不能外包給分數。

Agent 擅長戰術，人類必須學會看長期後果

Matt Pocock 在訪談後段引用 John Ousterhout 對 Tactical Programming 與 Strategic Programming 的區分：前者關心眼前功能能不能完成，後者關心今天的選擇會不會拖慢半年後的系統。

兩人對目前 Agent 的判斷很接近：Agent 很擅長戰術性工作，長期架構、模組切分與複雜度管理仍是弱項。 46:02

這也讓「新人還要不要親自寫程式碼」變得更難回答。Uncle Bob 的答案很明確：新人仍然要寫，而且要經歷除錯、重構與失敗，才知道 Agent 正在面對什麼。 47:05

我也認為新人不能跳過這段。工程師如果沒有親自追過 Bug、拆過錯誤邊界，也沒看過技術債怎麼累積，就很難只靠一份 Agent 成功摘要，判斷它正在前進還是原地打轉。

AI 可以縮短累積經驗的回饋週期，前提是我們願意觀察失敗、保存證據並理解修正理由。如果每天只接收「已完成」，使用再多 Agent 也不會自然長出戰略判斷。

軟體基本功正在換一種形狀回來

訪談最後回到一個很樸素的問題：AI 已經站在編譯器之上的新抽象層，軟體基本功還重要嗎？

Uncle Bob 的回答是，基本功存在的原因一直都是管理複雜度。模型同樣需要清楚名稱、模組邊界、依賴方向與可靠測試，才能在有限 Context 裡理解系統。 53:10

從二進位、組合語言、高階語言、Framework 到 AI Agent，每次抽象層提高，都有人覺得底層知識可以退休。抽象層確實讓我們少碰很多細節；當它開始漏水時，最後仍要有人知道下面發生了什麼。 55:07

看完這場訪談，我會把未來工程師稱為「品質系統的設計者」。下 Prompt 只是其中一小段，真正的工作還包括：

  • 把模糊需求轉成可觀察行為。
  • 把品質價值轉成可執行關卡。
  • 把大型工作拆成能獨立驗證的範圍。
  • 看懂工具沒覆蓋到的風險。
  • 為最後的接受、部署與影響負責。

AI 可以替我們做更多戰術工作，也讓過去昂貴的品質實務重新變得可行。

所以我把 CLEAN 五原則放進這篇觀後感。Agent 沒有讓 Clean Code 退場，只是把問題往前推了一層：除了程式碼怎麼寫，我們還得設計一套能約束 AI、驗證結果，而且由人承擔最後責任的工程流程。

延伸閱讀