前言：講了 28 天「架構能做到什麼」，今天要誠實講「做不到什麼」

這個系列從 Day 01 到現在，一路在講架構邊界怎麼限制 AI 的改動範圍、怎麼讓查證範圍變得可控。如果只讀到這裡，很容易產生一種錯覺：只要架構分層做對、邊界劃清楚，AI 協作的風險就被解決了。這個錯覺本身就違反系列主題句——如果我對「架構邊界」這件事的信心，沒有誠實劃出它管不到的地方，這份信心就跟 AI 對自己查證範圍過度自信是同一種錯誤。 今天要做的，是誠實列出架構解決不了的三類問題。

今日目標

• 認識架構邊界管不到的三類問題
• 理解「這個功能該不該做」跟「這個功能該怎麼放進系統」是兩個不同層次的問題
• 看清楚「邊界清楚」跟「程式碼細節寫得好」是兩件獨立的事
• 建立一套「架構之外還需要什麼機制」的判斷

第一類：架構管不到「這個功能該不該做」

架構規則能約束的是「一個功能被實作出來之後，它該放在系統的哪個位置、能改動的範圍有多大」——但它完全不回答「這個功能一開始該不該存在」。一個需求本身是不是重複造輪子、是不是偏離產品方向、值不值得投入這次的開發成本，這些判斷發生在架構規則能介入之前，屬於產品/業務層次的取捨。

再乾淨的模組邊界，也擋不住一個不該被實作的功能，被實作得很乾淨。 架構審查（Day 20、21 講過的角色）能檢查「這段程式碼有沒有違反分層規則」，檢查不了「這段程式碼原本就不該被寫出來」。

第二類：架構管不到團隊溝通不良導致的重複造輪子

即使每個模組的邊界都劃得清清楚楚，如果團隊裡兩個人（或兩個 agent）不知道對方在做什麼，同一個問題還是可能被解決兩次，甚至用兩種不一致的方式解決。這不是架構失效，是架構解決的問題本來就不包含「資訊有沒有在對的時間傳到對的人手上」——那是溝通機制、進度追蹤機制該負責的事。

用一組對照來看這個邊界：

❌ 誤以為架構能解決溝通問題：
「我們的模組邊界劃得很清楚，
 每個團隊各自負責自己的模組，應該不會重工吧。」
→ 邊界清楚只保證「改動範圍可控」，
  不保證「有沒有人已經在做一樣的事」

✅ 架構之外還要有溝通機制：
「模組邊界劃清楚之後，我們還是需要一個進度看板，
 讓大家知道誰在動哪個模組的哪個功能，
 避免兩邊各自解決同一個問題。」
→ 架構解決「改動範圍」，溝通機制解決「資訊落差」，
  兩者缺一不可，不能互相替代

第三類：架構管不到程式碼細節的品質

架構審查看的是「這段程式碼放在系統裡的位置對不對、有沒有違反分層/依賴方向規則」，這跟「這段程式碼本身寫得好不好」是兩條獨立的檢查維度。一段完全符合架構規則的程式碼，變數命名可以還是很糟、邏輯可以還是有 bug、測試可以還是沒斷言到重點——這些問題要靠一般的 code review、靠「驗證跟判斷分開」這個更廣義的紀律去把關，架構審查本身不負責這一層。

如果把架構審查當成程式碼品質的唯一把關，會漏掉一大塊真正決定程式碼能不能維護的細節。 架構審查跟一般 code review 該是互補的兩層檢查，不是其中一層可以取代另一層。

這三類問題的共同模式

架構邊界解決的是「改動範圍能不能被收斂到一個可查證的區域」，這件事跟「這個改動本身值不值得做」「團隊有沒有溝通好」「程式碼細節寫得好不好」是完全獨立的維度。 前者是架構的職責，後三者分別需要產品判斷、溝通機制、code review 各自的紀律來補上。把架構當成萬能解方，跟這個系列從第一天就在警告的「自信範圍大過查證範圍」是同一種錯誤，只是換了一個更高的層次重演一次。

今日思考題

回想你手上的專案：有沒有哪一次，明明架構邊界劃得很清楚，問題卻還是發生了？那次的根因，落在今天講的哪一類——產品判斷、團隊溝通，還是程式碼細節品質？

今日重點回顧

• 架構管不到「這個功能該不該做」，那是產品/業務層次的判斷
• 架構管不到團隊溝通不良導致的重複造輪子，那需要獨立的溝通/進度追蹤機制
• 架構管不到程式碼細節品質，架構審查跟一般 code review 是互補、不是替代關係
• 把架構當成萬能解方，是「自信範圍大過查證範圍」這個系列核心錯誤在更高層次的重演

明日預告

明天是這個系列的最後一篇：如果重來一次，這 30 天講的這套架構方法論會怎麼被重新設計——總結與回顧。