「這段程式碼寫得有點繞，應該是技術債吧，要不要趁這次改動順便清一清？」
這句話聽起來像是個技術判斷，但仔細想會發現一個問題：「技術債」跟「刻意的架構妥協」外觀常常長得一模一樣——都是「不是最乾淨的寫法」、都是「如果重寫可以更好」。差別不在程式碼本身的樣子，而在背後的決策脈絡：這段程式碼是「當初沒時間做對、大家都知道該補」，還是「經過評估、決定接受這個代價比較划算」？前面幾天講過 AI 誤判技術債的案例（Day 10）、也講過架構審查該怎麼設計（Day 17、Day 20）；今天要處理的，是這兩種判斷之間更根本的分界線。
技術債的本質是「欠著」——當下沒時間、沒資源把一件事做到最好，但這件事「應該」被做好，只是暫時擱置。技術債的特徵是：如果有機會，大家會希望把它還掉，程式碼裡通常會留下某種訊號（TODO 註解、issue 追蹤、團隊心照不宣的共識）標記著「這裡以後要處理」。
刻意的架構妥協則完全不同——它不是「欠著」，是「經過評估後決定接受」。團隊看過至少一種更「乾淨」的做法，但基於具體理由（維護成本、時程、跟外部系統的相容性、效能考量）判斷現在這個「不那麼乾淨」的版本，長期來看反而是更划算的選擇。它不是等著被還的債，是一個已經做完、有意識的決定。
這個差異用一句話講：技術債的問句是「我們什麼時候要把這個做對？」，刻意妥協的問句是「我們為什麼決定不追求那個『對』？」——問句本身不同，代表處理方式也該不同：技術債該被排進待辦清單，刻意妥協該被記錄下取捨的理由，兩者都不該被「看起來不夠乾淨」這個表面印象一視同仁地清掉。
AI 讀程式碼時看到的，只有這段程式碼「現在長什麼樣子」——它看不出這個樣子的成因,是「還沒来得及做好」還是「做過評估後決定這樣」。如果沒有額外的脈絡佐證（例如 Day 10 講過的 ADR、issue 討論紀錄、commit message 裡的說明），這兩種完全不同性質的程式碼，在 AI 眼中會呈現成同一種東西：一段「不是教科書寫法」的程式碼。
這正是這個系列反覆出現的模式：AI 對「這是不是技術債」給出的判斷，只在它實際查證過的脈絡範圍內成立——如果它只讀了程式碼本身，沒有查過這段程式碼有沒有對應的取捨紀錄，它給出的「這是技術債」判斷，其實只是「我覺得這段程式碼看起來不夠乾淨」的另一種說法,跟真正的技術債判斷是兩回事。
用一組對照來看這個差異：
❌ 只憑程式碼外觀判斷：
「這個函式用了三層巢狀 if，明顯是技術債，
我幫你重構成 early return 的寫法了。」
→ 判斷依據只有程式碼讀起來乾不乾淨，
沒有查過這個寫法背後有沒有取捨紀錄
✅ 先查證決策脈絡再判斷：
「這個函式用了三層巢狀 if，我查了對應的 ADR/issue，
發現這是團隊評估過的選擇——因為這段邏輯要跟一份
外部規格文件的判斷順序逐條對應，early return 會
打散這個對應關係，讓未來核對規格變困難。
這是刻意妥協，不是技術債，我不會動它；
但我會留意有沒有其他地方，同樣的巢狀寫法
卻查不到任何取捨紀錄——那些才是真正該排進
待辦清單、值得討論要不要償還的技術債。」
→ 先查證有沒有決策脈絡，
查得到理由的維持原樣，查不到理由的才進一步討論
把這個判斷落地成具體習慣，動手「清理」任何一段看起來不夠乾淨的程式碼之前，先問兩個問題：第一，這段程式碼附近查不查得到任何取捨紀錄（ADR、issue、commit message、程式碼註解）？第二，如果查不到，這件事本身該被當成「證據不足，先不動」，還是「反正沒紀錄，代表可以隨便動」？
正確的態度是前者——查不到取捨紀錄，不代表這段程式碼背後沒有理由，只代表理由沒有被記錄下來，這種情況下貿然清理的風險，跟 Day 10 講過的案例是同一種：程式碼看起來更乾淨了，但可能拿掉了一個沒人記得為什麼存在、卻真的在防著什麼的機制。真正安全的做法，是把「查不到理由」本身當成一個需要跟人確認的訊號，而不是「可以自由發揮」的許可證。
回想你手上系統裡那些「看起來不太乾淨」的程式碼：你分得出哪些是團隊心知肚明、排在待辦清單上的技術債，哪些是經過評估、刻意接受的妥協嗎？如果分不出來，代表這兩類決策目前都缺少一致的記錄方式，值得補上。
明天要往上升一層：這整個系列講的判斷方法（查證範圍、架構審查、技術債分辨），最終都會遇到一種決定——不是「AI 判斷得準不準」的問題，而是「這個決定本質上該不該由 AI 來拍板」的問題，明天會講清楚架構決策的授權邊界在哪裡。
iThome鐵人賽
看影片追技術