奉行價值，而非紀律

資料來源#

• Uncle Bob on Software Fundamentals in the Age of AI

摘要#

Robert C. Martin（Uncle Bob on Software Fundamentals in the Age of AI，2026-08-19，practitioner-opinion）用一句話說明這項原則：

"要求代理程式遵守人類的紀律，大概是個錯誤。要求代理程式遵守人類的價值觀，並沒有錯，但我們可能需要調整門檻。至於紀律本身，也就是那些行為，我不認為強加給代理程式是明智之舉。"

關鍵差異在於價值（實踐的目的——涵蓋每個分支、限制複雜度、讓測試真正約束程式碼）與紀律（能可靠產生這些價值的人因工程儀式）。價值可以移轉到代理程式身上。紀律則是針對特定認知架構所做的調適，而代理程式的認知架構不同。

代價高昂的實例：他不會要求代理程式做 TDD#

Martin 是這批資料中最堅定的測試驅動開發倡議者，而這項原則正好讓他必須放棄一些東西：

"我是測試驅動開發的大力倡議者。但那是人類的紀律，因為人類的思考方式就是如此。我不能，也不會要求代理程式照做。我不認為要求代理程式先寫一行測試，再寫一行正式程式碼，然後再寫下一行測試，這樣有任何道理。"

問題出在工作記憶。red-green-refactor 之所以需要緊密交替，是因為人類一次只能在腦中記住一個失敗的斷言及其實作，無法再多；Matt Pocock 將這點轉述給他：「TDD 很適合短期記憶力非常有限的人，像人類」，而他也認同。代理程式有「龐大的短期記憶，而且短期記憶完全準確」，所以這套儀式毫無助益；而那項價值——讓測試涵蓋程式碼的所有分支——就得用其他方式達成。在 Martin 的做法裡，是透過最後的變異測試關卡來達成（重啟不切實際的品質工具）。

行為證據：它們終究會回到原本做法#

他提出的最有力證據是：即使明確要求，這項紀律依然無法持續：

"所以我讓代理程式採用比較像 John Ousterhout 的做法：先寫一個函式，再為那個函式寫測試，接著寫下一個函式，再為那個函式寫測試。即使我已經明確要求它們嚴格遵守測試驅動開發，我還是讓它們這麼做。它們總是會回到這個做法，最後也總是這麼做。所以我想這大概沒問題。"

這是另一個獨立理由，說明不必再花力氣下達紀律層級的指令：這類指令會逐漸失效。這究竟是負載下的指令衰退、他在其他地方歸咎於的中間遺失效應（情境視窗智慧區），還是訓練資料的先驗偏好讓模型傾向更常見的先寫程式碼、再寫測試順序，他並未區分——而這三種原因的解法各不相同。他的做法是不再對抗，改為在後續流程中落實價值；不論是哪種原因，這都行得通。

門檻會調整，價值不變#

這項原則的另一面是，同一個價值可能需要採用不同的設定：

"代理程式可以處理比人類更高程度的複雜度……我採取的做法之一，就是放寬函式的允許大小，調整 CRAP 分數。對人類，我會把 CRAP 數值維持在四以下。但對代理程式，我把門檻設在六，而且在考慮是否提高到八。"

在測試涵蓋率達到 100% 時，CRAP 分數為六代表函式中有六條經過測試的路徑。價值（「這個函式的每條路徑都經過執行，而且路徑數量不該太多」）沒有變；「太多」的判準取決於讀者，而讀者換了。他沒有找出新數值的原則性方法，也坦承如此——「我正在找門檻在哪裡，這不是容易找到的門檻」——而且他明確表示，不會照單全收代理程式對六的認可：「你不能相信自己和代理程式進行的任何辯論，但我還是會和它們辯論。」

為什麼這是通用的檢驗方式，而不只是對 TDD 的個人看法#

這項區分能快速檢視任何被帶進代理程式工作流程的實踐。先問這項實踐的目的是什麼，再問實現目的的機制是著眼於程式碼，還是著眼於人：

實踐	帶來的價值	這套儀式是否符合人類的人因需求？
Red-green-refactor	每個分支都由曾經失敗的測試固定下來	是——交替頻率配合人類工作記憶。改用變異測試關卡。
小型函式	限制每個理解單位的路徑數量	部分符合——價值保留，門檻調整（4 → 6 → 8）
由另一個人進行程式碼審查	由沒有編寫程式碼的人，以挑剔的角度檢視	否——價值在於獨立性；使用全新情境的審查者也能提供這點（為代理程式打造深層模組）
深層模組／窄介面	讀者不必讀取模組本體也能使用它	否——代理程式和人類受益的原因相同，Martin 也直接這麼說
結對程式設計	持續審查並傳遞知識	知識傳遞這部分是——第二部分沒有對應的代理程式做法

這項檢視讓原則真正具有實質作用，而不只是好聽的說法：它能指出哪些既有實踐應設為關卡、哪些應重新調校，以及哪些應淘汰，因為它們只是為了支援新工作者並不具備的認知限制而搭起的支架。

尚未解決的張力#

這項原則與 Martin 自己提出的學徒訓練方式有些衝突，因為後者恰好反其道而行。他希望初階工程師「像代理程式一樣受到對待」——在幾個月內接受符合代理程式特性的任務，並通過符合代理程式特性的關卡（代理程式程式設計中的專業回歸）。如果紀律是人類才需要、而代理程式應該免受其苦的調適方式，那為什麼人類的訓練制度要採用代理程式的做法，就不太清楚了。他沒有處理這種不對稱，而這是他立場中最明顯、原本可以避免的缺口。

關聯文章#

• Robert C. Martin (Uncle Bob) — 這項原則的提出者，以及堅持它讓他付出的代價
• 重啟不切實際的品質工具 — 他如何透過變異測試關卡，不採用 TDD 也能達成 TDD 的價值
• 驗證成為新的瓶頸 — 早已指出代理程式讓「TDD 不再有額外成本」；本文更清楚說明了原因
• Agent-Generated Test Quality — 衡量代理程式自行決定順序時實際會怎麼做
• 指令複利效應 — 說明紀律指令為何無法持續的一種可能解釋
• 情境視窗智慧區 — 他自己對長篇規則文件為何逐漸失效的解釋
• 為代理程式打造深層模組 — 依據他和 Ousterhout 的說法，這項價值不變地移轉過去
• 潛在空間與確定性空間 — 落實原則的另一半：把價值變成檢查器，而不是提示文字
• 代理程式程式設計中的專業回歸 — 他在這裡反過來對待人類受訓者

開放問題#

• 代理程式為什麼會從遵循指令的 TDD 退回先寫程式碼、再寫測試？是指令衰退、訓練先驗，還是兩者都有？三者的解法不同，但沒有任何來源區分它們。
• 有沒有原則性的方法替代理程式讀者設定複雜度門檻？還是 4 → 6 → 8 純粹是實務工作者的直覺？

資料來源#

• Uncle Bob on Software Fundamentals in the Age of AI — Robert C. Martin 與 Matt Pocock，2026-08-19，practitioner-opinion