前言：為什麼想寫這個系列

決定寫「AI 寫 code 之後，我們還需要 Software Architecture 嗎」這個題目，其實是被一個很具體的煩躁感推著走的：這陣子看到太多次「AI 已經能自己規劃架構」這種說法，每次聽到都覺得哪裡怪怪的，卻說不清楚問題出在哪。直到有一次看著 AI agent 在沒有明確邊界規則的情況下，用一個晚上把一段原本乾淨的模組改得到處都是隱性依賴——才終於想清楚：AI 不是不會畫架構圖，是它沒有立場決定「這條邊界該畫在哪」。這系列想寫的，就是這個立場問題。

分階段回顧

第一部（Day 1-7）：為什麼架構的角色沒有消失，反而更重要。 從「沒有邊界時 AI 會怎麼寫」這個具體情境開始，一路講到 Repository 分層、介面切分、依賴方向、模組邊界——這幾天想建立的是一個基礎認知：架構不是規範寫法的美學偏好，是限制改動範圍的實際工具。現在回頭看，這個開場選得算是對的：後面每一天遇到的具體陷阱，幾乎都能收斂回「邊界劃在哪裡」這一個問題。

第二部（Day 8-16）：沒有架構約束時，AI 實際上會怎麼寫。 跨模組耦合、ADR 缺席導致的技術債誤判、過度抽象化、DI 容器的兩面性——這一部分故意選了很多「看起來能動、但邊界被悄悄破壞」的案例，因為這正是 AI 協作裡最難察覺的風險型態：不是寫出明顯的 bug，是寫出一段當下測試會過、卻讓系統邊界變得模糊的程式碼。

第三部（Day 17-23）：具體的架構工具，把約束變成可執行的規則。 這幾天從「架構規則不能只寫在文件裡」出發，講到把規則變成可執行的檢查、AI 架構審查角色的設計、技術債跟刻意妥協的分辨、最後收在「哪些決定不該讓 AI 自己拍板」。這是整個系列裡我覺得最重要的一部分，因為前兩部講的都是「問題長什麼樣」，這一部才真正回答「那該怎麼辦」。

第四部（Day 24-29）：實戰案例與方法論的邊界。 用正反兩個對照案例（邊界不清引入新 bug、清楚邊界讓重構可控）把前面的原則具體化，再往下講依賴方向規則被忽略的教訓、遺留系統重建時該先畫邊界還是先補測試、AI 時代架構師角色的轉變，最後誠實面對這套方法論解決不了什麼。這幾天寫下來，越來越確定一件事：案例比論述更有說服力，因為讀者要的不是被說服，是看到「這件事真的會發生」。

一個誠實的失敗經驗

寫到系列中段時，我想起自己真的放任過一次類似 Day 13 講的過度抽象化——手上一段原本五行就能解決的邏輯，因為當時剛好在強調「業務邏輯要收斂進 Service 層」這條規則，讓 AI 把它包成了 Interface、實作類別、外加一個 Factory，三層結構換一個五行函式。

當下沒有多想，覺得「反正符合規則」。真正付出代價是幾個月後：想追一段邏輯到底在哪裡執行，得先跳過介面定義、再跳過 Factory 怎麼決定實例，才找到真正做事的那五行。那次之後我才真正想清楚：架構規則本身不會犯錯，犯錯的是把規則套用得不分情境。分層是為了在「將來真的需要替換實作」時保有彈性，如果那個「將來」從來沒有具體到能講出一個理由，硬套上去的抽象層就只是延遲了每一次追蹤程式碼的速度，換不到任何真正的彈性。

這件事也讓我對這系列的立場更謹慎了一點——我沒有想把「有架構」講成萬靈丹。架構做錯一樣會傷人，只是傷的方式跟「完全沒架構」不一樣：沒架構是短期方便、長期失控；架構套用過頭是短期看起來嚴謹、長期拖慢每一次理解程式碼的速度。兩者都是沒有守住「邊界要為具體理由而畫」這條線。

回到系列主題句：一個可以帶走的判斷框架

Day 01 立下的主題句是：AI 越會寫 code，架構的約束力反而越重要——沒有清楚的邊界，AI 會用最短路徑寫出能動但難維護的東西；架構的角色不是規範「怎麼寫」，是限制「能改到哪裡」。

30 天走下來，這句話可以再拆成一個更具體的判斷框架：

• AI 適合做的：在已經劃好的邊界內生成程式碼、依照既有的分層規則做技術實作、用靜態分析工具檢查有沒有違反邊界。
• 人該保留的：決定邊界該畫在哪裡（這是取捨問題，不是技術問題）、判斷一段看起來奇怪的程式碼是技術債還是刻意妥協、決定要不要為了某個還沒發生的需求先做抽象化。
• 兩者都容易犯的錯：把「規則存在」當成「規則永遠適用」，而不去檢查眼前這個情境是不是真的需要套用它。

給讀者的實用建議

立即可行的第一步：挑一個你手上正在維護的模組，問自己一句話——「如果要在不讀懂整個系統的情況下改動這裡，改動範圍會停在哪裡？」如果答不出來，那就是一個值得優先劃邊界的地方。

漸進式的技能發展路徑：先從最小單位開始——一個 Repository、一個外部服務的介面切分，把「邊界收斂改動範圍」這件事做出具體效果，親眼看到差異之後，再往依賴方向、模組邊界這種需要跨團隊共識的規則推進，不要一開始就想把整個系統的架構規則都定義齊全。

架構規則要跟工具綁在一起：Day 17 講過，只寫在文件裡的規則會被遺忘。從一條最容易寫成檢查的規則開始（例如某個目錄不能被另一個目錄依賴），把它變成 CI 裡會實際擋下來的檢查，而不是停留在「應該遵守」的期待。

結語

回到 Day 01 那句「AI 已經能自己生成架構了，架構師是不是快沒事做了」的疑問——寫完這 30 天，我更確定答案是否定的，但理由跟一開始想的不太一樣。不是因為 AI 畫不出分層圖，是因為畫邊界從來不是一個能被自動化的技術決定，是一個需要人對系統的未來負責任的取捨決定。AI 越擅長把任何邊界都填滿程式碼，人越需要先想清楚邊界該畫在哪——這件事，這 30 天沒有變過，我猜接下來也不會變。

謝謝陪我走完這 30 天。這套判斷框架還在持續修正，如果你在自己的專案裡也遇到類似的邊界取捨，歡迎跟我聊聊你的判斷方式。