「我們架構師花了一整週產出一份完整的分層架構圖,貼在 wiki 上,結果 AI 一動手還是把邏輯全塞在 Controller 裡。」
這句抱怨背後藏著一個沒被說出口的假設:只要圖畫得夠清楚、文件寫得夠詳細,遵守就會自然發生。 這個假設在只有人類工程師的時代大致成立——人會讀文件、會被 code review 糾正、會慢慢內化團隊規範。但這個系列從 Day 02 開始就一直在講同一件事:AI 不會「內化」任何東西,它只服從當下讀到的具體規則。一份掛在 wiki 上、沒人強制它讀的架構圖,對 AI 的約束力趨近於零。
這正是這 27 天走下來,架構師這個角色本身也在被重新定義的地方。
架構圖(分層圖、依賴關係圖、C4 model 這類視覺化文件)的價值從來不是「機器可以解析執行」,而是「幫助人快速建立心智模型」——新人加入團隊時,一張圖能比讀十萬行程式碼更快理解系統的大致輪廓;跨團隊溝通時,一張圖能讓雙方在同一個抽象層次上討論,不用陷進實作細節。
這個價值在 AI 時代完全沒有消失。 人還是需要理解系統全貌才能做判斷、才能跟 AI 溝通「我要的是這種架構」。問題從來不在架構圖本身,而在於團隊把「畫了圖」當成「規則已經生效」的終點,而不是起點。
這個系列從 Day 17 開始講過:只寫在文件裡的架構規則,強制力完全依賴 AI 有沒有在當下這輪對話讀到它;一旦 context 被壓縮、規則被淡忘,違規就會發生,而且發生的時候不會有任何警訊。AI 真正會遵守的,是能被工具強制執行、會在違規當下直接擋下來的規則——依賴方向檢查工具、模組邊界的靜態分析規則、CI 裡會失敗的架構測試。
這件事對架構師的產出要求,跟畫圖是完全不同的技能:不是「這個分層長什麼樣子」,而是「這條分層規則要怎麼寫成一段可以被機器判斷真假的邏輯」。同一條規則,用畫圖表達跟用可執行檢查表達,是兩種完全不同的產出物,對讀者的效力也完全不同。
用一組對照來看這個差異:
❌ 只有架構圖,沒有可執行規則:
「Domain 層不能依賴 Infrastructure 層」
→ 畫在架構圖上,寫進 wiki,開會講過一次
→ AI 在下一輪對話裡完全不知道這條規則存在,
除非剛好這輪 context 又載入了同一份文件
✅ 架構圖 + 可執行規則並存:
架構圖:畫出 Domain / Application / Infrastructure 三層
的依賴方向,給人快速建立心智模型
可執行規則:CI 裡跑一支依賴檢查工具,
只要 Domain 層的檔案 import 了 Infrastructure
層的具體類別,直接讓這次建置失敗
→ 圖給人看、幫助理解全貌;
規則給 AI 跟工具遵守,不管有沒有讀過文件都會被擋下來
架構師的核心產出,正在從「一份給人看的靜態文件」,轉移成「一組給機器強制執行的邊界規則」——圖沒有消失,只是不再是唯一、甚至不再是最關鍵的產出形式。
值得說清楚的是:這不是「畫圖過時了,全部改寫成程式碼規則」的極端主張。人類工程師還是需要圖來建立全貌認知,尤其是在做跨系統的重大決策時,一段依賴檢查規則的程式碼完全無法取代一張清楚的架構圖帶來的理解速度。
真正該調整的,是架構師分配時間跟精力的比重——過去可能把大部分心力放在畫出一份精美完整的架構文件,現在則需要多花力氣,把文件裡「真正重要、一違反就會出問題」的那幾條規則,轉成 CI 裡真的會擋下建置的檢查。文件負責讓人理解「為什麼這樣設計」,可執行規則負責讓 AI 跟人都無法在不知情的狀況下違規。
回想你團隊裡最重要的一條架構規則:它目前是只存在文件跟口頭共識裡,還是已經有一段程式碼會在違反的當下讓建置失敗?如果是前者,這條規則對 AI agent 來說,其實跟不存在沒有太大差別。
明天要誠實面對這套方法論的邊界:架構規則、可執行檢查、清楚的模組邊界,這些工具解決不了什麼問題——不是所有架構失敗都能靠更嚴謹的邊界規則避免。