前言：一個看似該有標準答案的問題

「要重整一套沒有邊界、也沒有測試的遺留系統，到底該先補測試建立安全網，還是先畫邊界重整架構？」

這個問題在社群裡討論很多次，答案通常分成兩派：一派說「沒有測試不敢動架構」，先把安全網建起來；另一派說「沒有邊界寫不出快速可信的測試」，先把邊界畫出來。兩派各自有道理，但把這件事當成「先後順序」的問題，本身就問錯了方向——今天要講的是，這兩件事不是誰先誰後，是互相卡住彼此的一組死結，而 AI 在這種情境下特別容易選錯突破口。

今日目標

• 理解「先補測試」跟「先畫邊界」為什麼會互相卡住彼此
• 認識這個死結對 AI 協作造成的具體困境
• 學會一個務實的漸進做法：局部突破，而不是等一次到位
• 建立判斷「這個角落該先補測試還是先畫邊界」的具體標準

死結：兩件事互相依賴，誰先都卡住

先看「先補測試」這條路為什麼卡住：一套沒有邊界的遺留系統，資料存取、業務邏輯、外部呼叫全部糾纏在一起，要幫一段程式碼寫單元測試，往往得先啟動資料庫連線、模擬一堆跟這段邏輯沒有直接關係的相依物件——測試變得又慢又脆弱，跟「快速、可信」這兩個目標背道而馳。沒有邊界的地方，測試寫起來的成本高到讓人卻步。

再看「先畫邊界」這條路：把糾纏的邏輯拆成 Repository、Service、Controller 這類分層，本質上就是一次重構——而重構最基本的前提是「改完之後行為要跟改之前一樣」，這個保證需要測試來背書。沒有測試網的狀況下畫邊界，等於在沒有安全帶的狀態下走鋼索，任何一次重構都可能悄悄改變行為卻沒人發現。

這正是為什麼「先後順序」這個提問本身就有問題：兩條路各自的前提，都是對方已經完成的狀態。 不是誰比較優先，是兩件事本來就該交替推進，而不是等其中一個先做到完整才開始另一個。

AI 在這個死結裡容易選錯的突破口

用一組對照來看 AI 常見的失誤：

❌ 選擇一次到位的極端做法：
「這個模組完全沒有測試、也沒有邊界，
 我先把整個模組的架構重畫過一輪，畫完再補測試。」
→ 重畫過程完全沒有安全網，任何一個行為差異
  都要等重畫完、補完測試才有機會被發現，
  範圍越大，出錯後排查的成本越高

✅ 局部突破，交替推進：
「先挑這個模組裡『被呼叫最頻繁、依賴最少』的一小段，
 用特徵測試把現有行為釘住，再局部抽出一個介面，
 驗證行為沒變之後，才往外擴大範圍。」
→ 安全網跟邊界在同一個小範圍裡同步建立，
  每一步都有辦法驗證「行為真的沒變」

AI 面對「這裡什麼都沒有」的情境時，容易被「乾脆整個重做」的念頭吸引——因為從零開始規劃一套乾淨架構，比在既有混亂裡見縫插針要簡單得多。 但這個誘惑正是遺留系統重建最危險的陷阱：範圍一次拉大，就沒有東西能告訴你「這裡改壞了」。

務實的漸進做法：找一個最小的突破口

具體的做法是先挑一個範圍夠小、依賴夠少的角落當突破口——通常是「被呼叫頻率高，但邏輯相對獨立」的一小段程式碼。在這個小範圍裡：

1. 先用特徵測試（characterization test，把現有行為原封不動釘住,不評斷行為對不對，只確保重構後行為一致）建立最小的安全網。
2. 在這個安全網保護下，把這段邏輯抽出一個小小的邊界（一個介面、一個獨立的類別）。
3. 驗證行為沒變之後，這個邊界本身就成為下一段重構的立足點——下一次要處理的相鄰邏輯，因為已經有一部分被邊界隔開了，測試起來的成本也跟著降低。

這個過程本質上是滾雪球：第一個突破口最難、成本最高，但每完成一小段，下一段的難度就會因為「已經有一部分邊界存在」而降低。 不需要等「整個模組都有測試了」才開始畫邊界，也不需要等「整個模組都有邊界了」才開始補測試——兩件事在同一個小範圍裡同步發生，範圍逐步往外擴散。

這跟系列反覆講的主題句是同一件事：與其問「AI 該先做哪一件事」，不如問「AI 這次要承擔的查證範圍有多小」——範圍越小，AI 判斷「這樣做安不安全」的可信度就越高，一次到位的大範圍重建，不管先做測試還是先做架構，都是在賭一個 AI 沒辦法窮舉的範圍。

今日思考題

回想你手上有沒有一個「沒測試也沒邊界」的遺留角落：如果要動它，你會選擇先補測試還是先畫邊界？有沒有考慮過先挑一個更小的範圍,讓兩件事同時發生？

今日重點回顧

• 「先補測試」需要邊界讓測試變快變可信，「先畫邊界」需要測試背書重構沒有改變行為——兩者互相依賴，不是單純的先後順序問題
• AI 容易被「乾脆整個重做」的一次到位念頭吸引，範圍越大，出錯後越難排查
• 務實做法是挑一個依賴少的小範圍，用特徵測試建立安全網、局部畫出邊界，再逐步向外擴散
• 核心判斷標準不是「先做哪一件事」，是「這次要承擔的查證範圍有多小」

明日預告

明天要往上升一層，談 AI 時代的架構師角色本身發生了什麼變化——從畫架構圖的人，變成訂邊界規則的人。