「AI 說這裡應該拆成兩個模組會比較好維護，那就照做啊，反正它講的技術理由也沒錯。」
這句話乍聽合理，卻悄悄跳過了一個關鍵問題：「這個技術判斷是不是對的」跟「該不該現在做這個決定」，是兩件完全不同的事。 這個系列從 Day 17 開始講了一連串把架構規則變成可執行檢查、讓 AI 參與架構審查的做法，今天要補上最後一塊：就算 AI 的技術判斷再紮實，有一類架構決策的拍板權，本來就不該交給它。
架構決策大致可以分成兩類。第一類是技術判斷：這個分層合不合理、這個依賴方向有沒有違反既定規則、這段程式碼能不能獨立測試——這些問題的答案，可以靠讀程式碼、對照既有規則、跑靜態分析工具得出，判斷過程不太需要「這個團隊現在缺不缺人」「這個功能明年還要不要維護」這類團隊之外的資訊。這正是 Day 17 到 Day 21 講的東西：把這類判斷變成可執行的檢查、設計成 AI 能參與的審查角色。
第二類是業務/組織判斷：要不要為了一個「可能」出現的未來需求，現在就先做出擴充性設計；要不要接受一個效能上的妥協，換取提早上線的時間；要不要投入這一輪衝刺的時間去做架構重構，還是先把功能做完。這些問題的答案，藏在「業務優先序」「團隊資源」「上線時間壓力」這些 AI 沒有、也不該假裝自己有的脈絡裡。
AI 對第一類問題給出的答案，可信度可以很高；但如果把第二類問題也丟給 AI 自己拍板，它給出的答案再流暢、再有邏輯，都只是建立在它片面理解的脈絡上。
這裡最容易踩的陷阱是：AI 給出技術理由時,語氣跟給出業務判斷時的語氣,聽起來沒有分別。它會說「這裡應該拆成兩個模組，因為職責更清楚、耦合更低」，這句話本身是技術判斷,站得住腳；但如果它接著自己動手把模組拆了，這個「動手」的決定，其實已經跨進了「現在要不要投入這個重構」這個業務判斷的領域，而它從來沒有被授權做這個決定。
問題不是 AI 的技術理由錯了，而是它把「這樣做技術上比較好」直接當成「所以我現在就該這樣做」的授權——這兩件事之間，缺了一個只有人能填的環節：現在做這件事，值不值得？
用一組對照來看這個差異：
❌ AI 自己把技術判斷升級成行動授權：
「這個模組耦合太高，應該拆開。」
→ 直接動手重構，把耦合拆開,提交這次改動
→ 沒有人被問過「這個時間點值不值得投入這個重構」
✅ AI 呈現技術判斷，人決定要不要授權行動：
「這個模組耦合太高，我建議拆開，
理由是：職責混在一起、測試需要啟動整個模組才能跑。
但這是一個中等規模的重構，會影響到三個呼叫端，
要不要現在做，還是先記錄下來排進下一輪？」
→ 技術判斷交出去了,但「現在做不做」這個決定,
留給知道團隊資源跟優先序的人
一個實用的判斷習慣是：這個架構決策的答案，能不能只靠讀程式碼、對照既有規則就得出？如果答案需要團隊之外的資訊（時程、資源、業務優先序、未來規劃），這就是一個需要人拍板的決定，AI 只能呈現選項，不能自己選。
值得注意的是，這條分界不是「AI 能力不夠」的問題——就算 AI 有一天能準確預測業務優先序，這件事的授權責任依然不該落在它身上,因為承擔決策後果的是人,不是 AI。這跟 Day 22 講的「技術債 vs 刻意妥協」判斷是同一個邏輯的延伸：分辨清楚一件事屬於哪一類，比擁有更強的判斷能力更重要。
第三部（Day 17-23）從「架構規則要寫成可執行的檢查」開始，一路講到規則失效的案例、微服務邊界怎麼縮小協作範圍、AI 架構審查角色怎麼設計、技術債跟刻意妥協怎麼分辨，最後落在今天這條授權邊界上。這七天想傳達的核心概念其實是同一件事的不同層面：架構的約束力不是自動發生的，它需要被寫成可執行的規則、被分派給對的角色去檢查、並且清楚劃出「誰有資格做最終決定」——少了任何一環，架構規則都只是一份沒有牙齒的文件。
回想你上一次接受 AI 的架構建議：那個建議背後的理由，是純技術判斷，還是悄悄夾帶了「現在該不該做」這個業務決定？你有沒有意識到自己在授權的，其實不只是一個技術方案？
明天進入第四部：實戰案例與總結。第一個案例——架構邊界不清楚時，AI 修好一個 bug，卻在邊界外引入了另一個。
iThome鐵人賽
看影片追技術