「把系統拆成微服務，是不是就代表可以放心讓 AI 到處改，反正邊界已經分好了？」
這句話只對了一半。拆分本身不會自動讓 AI 變安全，拆分帶來的真正好處，是讓 AI 每次只需要理解一個小範圍就能安全動手，而不是每次都要先讀懂整個系統才敢下判斷。這件事聽起來理所當然，但很多團隊拆了微服務之後，還是讓 AI 一次跨好幾個服務改動，那拆分的價值就沒有真的兌現。
回到這個系列從 Day 01 就在講的主題句：AI 給出的「已確認安全」，只涵蓋它實際查證過的範圍。在一個邊界清楚的模組化架構裡，「這次改動安不安全」這個問題，可以合理地被限縮成「這次改動有沒有破壞這個模組對外的契約」——只要對外行為沒變，AI 不需要去理解系統裡其他模組的內部實作，就能對這次改動的安全性給出有意義的判斷。
這不是憑空的信心，而是架構邊界本身提供的保證：模組之間只透過明確定義的介面互動，模組內部的實作細節不會被外部依賴，所以「內部改了」跟「外部會不會受影響」這兩件事被切開了。AI 只需要驗證一件事——對外契約有沒有變——就能對整個改動的安全範圍做出合理判斷。
反過來，在一個邊界模糊的單體架構裡，同樣的問題會變成：「這次改動有沒有影響到系統裡任何其他地方？」——這是一個原則上永遠答不完的問題，因為沒有任何機制保證「這段程式碼只會被這裡呼叫」。AI 要嘛花大量時間搜尋整個程式碼庫確認沒有遺漏（成本很高，而且搜尋本身也可能有遺漏），要嘛只查證了眼前這一小段就給出「已確認安全」的結論（範圍不夠、但講得很有信心）。
這正是系列反覆出現的模式：查證範圍要嘛被迫無限擴大到不現實的程度，要嘛悄悄被壓縮到跟結論的自信程度不成比例。架構邊界的價值，就是把這個查證範圍的邊界，事先用系統設計劃好，而不是每次都靠 AI 臨場判斷「這次應該查到哪裡就夠了」。
用一組對照來看這個差異：
❌ 邊界模糊的單體架構：
AI：「已確認這處改動沒問題，測試也過了。」
→ 「沒問題」的查證範圍，取決於 AI 這次搜尋了多廣、
搜尋不到的呼叫端完全沒被排除在外，
範圍隨改動的人當下有多仔細而浮動
✅ 邊界清楚的模組化架構：
AI：「這個模組對外只暴露這三個方法的契約，
這次改動沒有更動這三個方法的輸入輸出行為，
模組內部的其他改動不會影響外部呼叫端。」
→ 查證範圍被架構邊界事先框定，
不會因為改動的人搜尋得夠不夠仔細而浮動
這件事還有一個更直接的實務影響：AI 每次工作要載入的 context 範圍，跟它出錯的機率有直接關係。單一模組的程式碼、測試、既有慣例，是一個 AI 可以合理消化、記得住細節的範圍；一旦要跨模組、甚至要理解整個系統才能安全動手，AI 要同時記住的細節暴增，忽略掉某個關鍵約束的機率也跟著上升——這不是 AI 能力不夠，而是任何有限的注意力資源,面對越大的範圍,越容易漏掉東西。
這也是為什麼「把 AI 限制在單一模組內工作」不只是一個管理上的方便措施,而是實際降低出錯機率的具體手段。如果一個任務真的需要跨越多個模組的邊界,那反而是一個訊號——這個任務的複雜度已經超出「AI 可以獨立安全處理」的範圍，需要更多人的介入,而不是丟給 AI 一次處理完。
具體的判斷標準：如果一個任務的完整範圍能被描述成「改動某個模組的內部實作，同時保證對外契約不變」，這種任務適合讓 AI 在該模組邊界內獨立工作；如果任務本質上需要同時改變兩個模組之間的契約（例如新增一個跨服務的欄位、調整一個 API 的回應格式），這代表這個任務牽涉到架構層級的決定，不該讓 AI 自己判斷「這樣改應該沒問題」，而是要先由人確認契約變更的影響範圍，再把拆解後的、範圍明確的子任務交給 AI。
回想你上一次讓 AI 處理一個牽涉到多個服務/模組的任務：你有沒有先把它拆成「單一模組內可以獨立完成」的子任務，還是讓 AI 自己跨邊界摸索完成？
明天要往前一步：架構評審這件事本身，能不能也交給 AI 做——怎麼設計讓 AI 檢查架構違規，而不是讓它順便寫功能、模糊了審查跟實作的角色分工。
iThome鐵人賽
看影片追技術