Part 2 講完了怎麼建一座工廠。

但有一個問題沒回答：建完之後呢？

Part 3 這四天要講的就是這件事，而且答案不是「維護它」，是一個更主動的動作。

一個容易被忽略的事實

回想 Day 16 講第 3 層的時候，我提過一個限制：

這一層天然是滯後的 ——因為「要擋什麼」通常要踩過才知道。

這句話有一個直接的推論：

你不可能在專案開始的時候，就設計好所有該有的護欄。

你會知道一些明顯的（不可以改資料庫、命名要一致），但那些真正會咬人的東西。某個 hook 攔截範圍太寬、某個檢查誤報率太高、某份單一真相自己過期了。要跑一段時間才會浮出來。

所以護欄不是一份設定檔，它是一個會演化的系統。

而如果它會演化，那就需要一套方法來管理演化。

束縛工程

Martin Fowler 的網站上有一篇 Birgitta Böckeler 寫的文章，叫 Harness Engineering for Coding Agent Users（2026-04-02，出處見文末）。

我看到的那個案子，整套做法就是照它建的。核心主張是這樣：

束縛（harness）不是一次性配置，而是持續工程。

工程師的角色從「編碼者」轉為「束縛工程師」。

我第一次讀到「束縛工程師」這個說法的時候，覺得有點過度包裝。但看完那個案子的實際紀錄之後，我改觀了。因為它確實描述了一種新的工作內容。那個工作不是寫功能，也不是 review 程式碼。它是：

• 觀察 AI 在哪裡反覆出錯
• 判斷那個錯誤屬於哪一類缺口
• 設計一道新的護欄
• 然後驗證那道護欄真的有降低錯誤機率

而這四件事，構成一個迴圈。

四階段迴圈

① 觀察  →  ② 判斷  →  ③ 改進  →  ④ 驗證
問題重複    缺前饋      寫規則／     問題機率
出現？      還是反饋？   加 Linter    下降了嗎？
              ↑                          │
              └──────────────────────────┘

四個階段各自要回答一個問題：

① 觀察：這個問題是不是重複出現的？

單次的錯誤不需要護欄。護欄的成本（寫、維護、誤報）只有在問題重複時才划算。那份日誌的模板裡有一句提示：「具體到『第 N 次發生』最佳」。

② 判斷：這是前饋不足，還是反饋缺失？

這個區分我覺得很有用：

• 前饋（feed-forward）：在 AI 動手之前給它的東西——規範、範例、事實、規格
• 反饋（feedback）：在 AI 動手之後給它的東西——測試結果、檢查失敗、審查意見

同一個問題，兩種解法完全不同。「AI 寫的錯誤處理格式不一致」可以是前饋問題（沒給範例），也可以是反饋問題（沒有檢查）。選錯了就會做白工。

而這一軸還要再交叉第二軸——計算式 / 推論式：

• 計算式：確定性的。linter、schema 驗證、編譯、測試——答案是唯一的
• 推論式：機率性的。AI 審查、code review——答案要靠判斷

兩軸交叉出四格，而 Day 22 那條「確定性的問題要用確定性的機制解決」，在這張圖上就是一句很具體的話：能落在左半邊的，就不要放到右半邊。

③ 改進：具體做了什麼改動？

④ 驗證：問題的發生機率真的下降了嗎？

第四階段是最容易被跳過的，也是明天後天要展開的重點。

為什麼一定要有日誌

那個案子把這個迴圈的紀錄叫做「束縛迭代日誌」。它的說明文件裡有一句話，我覺得講得很好：

沒有日誌 → 改了什麼記不得 → 回不去也無法學習 → 迴圈斷裂。

拆開來看是三個問題：

一、記不得改了什麼。

三個月後你發現某個檢查一直在誤報。它是什麼時候加的？為了解決什麼？當初有沒有考慮過誤報？沒有日誌，你只能重新推理一次，而且推理不出來的話，通常的處理是直接關掉它。連同它本來要擋的東西一起。

二、回不去。

你加了一道護欄，結果整個團隊的開發速度掉了三成。要不要回退？回退的話會失去什麼？

沒有紀錄，這個決定只能憑感覺。

三、無法學習。

這是最貴的。如果你不記錄「這個改動有沒有效」，你就永遠不知道哪一類護欄划算、哪一類不划算。十次改動下來，你有十個做法，但沒有任何一條可遷移的經驗。

那本日誌實際長什麼樣

講到這裡都還是原則。給你實際的格式，因為這件事的成敗全在「填不填得動」。什麼情況必須登錄——只有一條判準：

凡是動到「AI 會讀到的東西」或「會擋住 AI 的東西」，一律登錄一條。 包含刪除。

CLAUDE.md、規範文件、黃金範例、hook、腳本、skill、agent 設定、schema。動了就記。刪除尤其要記，因為「為什麼把那條拿掉」是三個月後最想不起來、也最容易被重新加回去的東西。

時限是 24 小時。 不是因為 24 小時有什麼魔力，是因為超過一天你就只記得「我改了什麼」，不記得「我當時看到什麼才決定改」。**而後者才是這本日誌唯一的價值。**一條登錄長這樣：

## SL-017｜把「禁止異動 schema」從文件搬進 hook

**觀察**  第 3 次有人在沒開票的情況下改了 schema，兩次是 AI 主動改的
**判斷**  第 0 層擋不住這件事，而它的失敗成本是資料遷移
**改進**  加 PreToolUse hook，比對 migrations/ 以外的 schema 檔就 exit 2
**驗證**  ⬜ 待回填（期限 2026-xx-xx）

四個小節對應那四個階段，而第四格是空的。它要等七天後才有資格被填。那個工作區的日誌到目前累積了兩百多條。登錄的人是「動手的那個人」，不是主管，也不是週會。因為只有動手的人知道「觀察」那一格該寫什麼。

跟前面幾天的關係

這裡我想把 Part 1、Part 2、Part 3 的關係講清楚，因為它們容易被看成三套不同的東西。

Part 1 是靜態的、Part 2 是一次性的、Part 3 是持續的。

而 Day 19 講的那個「每發現一個 bug，決定它該沉澱到哪一層」。那個動作就是這個迴圈的 ②③ 兩步。

換句話說，Part 1 給了你分類的語言，Part 3 給了你使用那個語言的節奏。

一個誠實的補充：我原本讀的是第二手

這一篇初稿寫完的時候，我在文末寫了一句話：**「Fowler 那篇文章我沒有完整讀過。」**我當時看到的是那個案子對它的中文解析，以及照它建起來的實作。所以我轉述的是「那個案子怎麼理解它」，不是「Böckeler 原文說了什麼」。

後來我回頭把原文讀了。結果是這樣：

• 前饋 / 反饋這條軸，二手轉述是準的——原文用的詞是 Guides（feedforward）與 Sensors（feedback）
• 但轉述漏了第二條軸。原文把兩者各自再切成 Computational（確定性）與 Inferential（推論式），而那正好是這套做法最有用的部分——也就是我上面補進去的那一段
• 原文還有第三層分類（可維護性 / 架構適應度 / 行為），那是後天講日誌格式時會用到的東西

所以二手轉述沒有錯，但它少了一半。

而少的那一半，剛好是能讓你判斷「這道護欄該用腳本還是該用 AI 審查」的那一半。我把這段留在文章裡，因為它比我原本想講的那個道理更有說服力：

引用的時候要說清楚你讀的是哪一手——
而如果那句話會影響你的做法，就去讀第一手。

（這正好是二手轉述的老問題：它的失效方式不是「講錯」，是「講少了」。而你從轉述的形狀看不出它少了什麼。這件事後面會再遇到一次，而且會有一張表。）

小結

• 護欄不可能一開始就設計完整，因為「要擋什麼」要跑過才知道
• 所以它是一個會演化的系統，需要方法來管理演化
• 四階段迴圈：觀察 → 判斷 → 改進 → 驗證
• ② 的關鍵區分：這是前饋不足還是反饋缺失
• 沒有日誌，迴圈會斷——記不得、回不去、學不到

明天講那本日誌長什麼樣，以及一條我認為很多團隊做不到的規定：凡是動到護欄，24 小時內必須登錄。

參考文獻

1. Böckeler, B.（2026-04-02）。Harness Engineering for Coding Agent Users。martinfowler.com。
   https://martinfowler.com/articles/harness-engineering.html
   — 本文「前饋／反饋」與「計算式／推論式」兩條軸皆出自此文（原文為 Guides/Sensors × Computational/Inferential）。作者 Birgitta Böckeler 為 Thoughtworks Distinguished Engineer。

2. Böckeler, B.。Maintainability Sensors for Coding Agents。martinfowler.com。
   https://martinfowler.com/articles/sensors-for-coding-agents.html