上週我花了 40 分鐘 review 一段 AI 產生的 PR。功能正確、測試全過、CI 也是綠燈。從任何傳統指標來看，它都是一段「沒有問題」的程式碼。
但我盯著其中 12 行 code 看了很久，才意識到一件事——它把整個 service layer 繞過了。這不是 bug，而是 AI 的預設行為。
專案上線不到兩個月，架構已經開始悄悄死亡。
Contract 看起來像答案，但其實不是
在上一篇文章，我們提出了一個直覺的解法：把架構規則轉成 machine-readable contracts。當 layer dependency、module boundary、IRQL constraint 都被結構化之後，看起來 AI 應該就能避免破壞架構。
但這裡有一個關鍵誤解：AI 並不會主動遵守你的規則。
Architecture Contracts 確實解決了一件事——它讓規則可以被機器看見。但它沒有解決更本質的問題：這些規則在什麼時候被執行，以及誰來確保它們被遵守。
AI 的優化目標始終是完成任務、讓程式碼能運作，而不是維持 architecture。這導致一種很危險的模式：局部正確，但整體錯誤。
一個很小，但很真實的例子
舉個簡單的例子。我曾經讓 AI 修一個 repository 的資料讀取問題，它給出的解法很直接：
varresult=awaithttpClient.GetAsync(...)
這段程式碼功能完全正確，不會 crash、不會讓測試失敗，甚至連 CI 都不會攔下它。從表面上看，它是「最有效率的修正」。
但問題也正出在這裡。
Repository layer 根本不應該直接呼叫 HTTP API。
這段 code 在系統裡偷偷鑿開了一條新的依賴路徑，而且這條路徑不會被記錄、不會被質疑，甚至不會被注意到。
當這種改動發生十次、二十次，你的架構並不會瞬間崩壞，而是會在你毫無察覺的情況下，慢慢失去邊界。
如果沒有執行機制，Contract 只會退化
這就是現實：沒有 enforcement 的 contract，最後只會退化成另一份文件。它只是從 ARCHITECTURE.md 變成 architecture_rules.yaml，本質沒有改變。
在傳統開發裡，這還可以勉強運作——規則靠人記，違規靠 code review 補救。但在 AI coding 的情境下，這個模型開始失效。因為 code 的生成速度遠遠超過人類能審查的速度，違規不再是例外，而是常態。
問題已經不是「有沒有規則」，而是「規則什麼時候被執行」。
關鍵轉折：問題不是 rule，而是 timing
這是整個問題真正的核心。
如果規則只在 PR review 或 CI check 時才被執行，那其實已經太晚了。AI 早就沿著錯誤的方向生成了一整段程式碼，甚至在多輪修改中不斷強化這個錯誤。
換句話說，architecture 問題本質上不是「缺少規則」，而是「規則的執行時機錯誤」。
你不是沒有 boundary，而是 boundary 來得太晚。
所以真正缺的是：Governance Layer
如果把整個流程重新畫一次，你會發現 AI 與 codebase 之間其實少了一層東西：
AI Agent
↓
（缺少的東西）
↓
Codebase
這一層不是單一工具，而是一個持續運作的系統：
Governance Layer
它的目的不是定義規則，而是確保規則在整個開發過程中持續發生作用。
Governance 不是檢查，而是過程控制
很多人第一個直覺會是：「那就是寫一個 validator？」
但這個想法其實還停留在舊世界。
傳統工具的特性是——它們只在某個時間點作用，例如 commit、build 或 PR review。但 AI 的問題不是某一刻出錯，而是整個生成過程都可能逐漸偏離架構。
因此，governance 的本質不是「找出錯誤」，而是：
在過程中持續限制錯誤發生的空間。
一個更接近現實的流程
當 governance layer 存在時，開發流程會變成這樣：
AI 理解任務
↓
[Governance: 注入規則]
↓
AI 生成程式碼
↓
[Governance: 驗證違規]
↓
AI 修正 / 再生成
↓
[Governance: 長期 drift 偵測]
這裡的關鍵改變在於：規則不再只是事後檢查，而是整個過程的一部分。
拆開來看，其實是四種控制
這整個系統可以簡化成四個層次：
- Pre-generation：限制 AI 的解空間
- In-generation：防止 context drift
- Post-generation：即時修正違規
- Long-term：監控架構侵蝕
少任何一層，系統都會失效。因為架構問題從來不是單點錯誤，而是長期累積的結果。
關鍵差異：從「找錯誤」到「限制錯誤」
這也是一個很根本的轉變。
傳統工具的目標是找出錯誤，而 governance 的目標是讓錯誤變得難以發生。這兩者在 AI 時代的差距會被放大，因為錯誤產生的速度已經遠超過人類能補救的速度。
一個不太舒服的結論
如果沒有 governance layer，architecture erosion 幾乎是必然的結果。而且它不會劇烈發生，而是以一種非常安靜、合理、甚至看起來「沒問題」的方式逐漸出現。
直到某一天，你才發現整個系統已經失去邊界。
工程師的角色正在改變
這也意味著開發流程正在改變。
過去是：
write code → review → fix現在則更接近：
AI generate → governance enforce → validated output
工程師的角色，也從單純的 implementation，轉向規則設計、邊界定義與系統治理。
結尾
當 governance layer 真正運作起來時，AI 不再是失控的實習生，而是一個被嚴格約束、但效率極高的工程夥伴。
但前提是——你必須先定義好哪些邊界是不能被跨越的。
否則，AI 不會幫你維持架構。
它只會在你沒注意的地方，慢慢重寫整個系統。
