這個系列從 Day 01 到現在，講的都是怎麼讓 AI 安全動手——基準線、乾淨環境比對、Repository 收斂、記憶系統、多 agent 協作。如果讀到這裡，會有種「只要把這套流程做齊，AI 就能安全處理任何重構」的錯覺。這個錯覺本身就違反了系列主題句：如果我對這套方法論的信心，沒有誠實劃出它查證不到、覆蓋不到的邊界，那這份信心本身就跟 AI 過早下結論犯的是同一種錯。 今天要做的，是誠實列出這套方法論解決不了的事。
前面幾天提過幾次「AI 查出差異之後，該不該保留這個差異」這類問題——一段重構後的行為出現了細微不同，這個不同是刻意的設計改變，還是意外的迴歸，取決於這段差異對使用者、對業務邏輯的實際影響有多大。這個判斷需要業務脈絡，而業務脈絡不是靠讀程式碼能推導出來的——AI 能做的，是把差異攤開來、講清楚查證過的範圍是什麼，但「這個差異能不能接受」這個最終決定，必須留給有業務判斷權的人。這條邊界從 Day 03 那個 trim() 案例開始就一直存在，只是這裡把它講清楚：不是「AI 能力不夠」的問題，是這類決定本質上就不屬於「查證範圍夠不夠」能解決的範疇。
系列中提過一種記憶類型，記的不是「已解決的問題」，而是「已知但決定先不改」的架構風險——例如某個判斷邏輯有已知的缺陷，但因為修復成本高、影響範圍不確定，團隊決定先接受這個風險，之後找時間全面檢視。這個決定的關鍵在於：接受風險是一個有意識的取捨，需要衡量修復成本、影響範圍、時間壓力,這些都是需要人來拍板的判斷，AI 的角色只能是把這個風險講清楚、記下來,不能自己決定「這個風險我覺得還好，先跳過」。 如果 AI 自己拍板接受了一個沒有被明確授權接受的風險，這就不是「效率」，是在使用者不知情的狀況下，替他承擔了一個他沒有機會表態的決定。
這是最容易被誤判的一類。系列中提過一個具體案例：曾經考慮過用某種自動探索機制，取代手動維護的一份明確清單，理由是「這樣以後有新項目就會自動被涵蓋，不用每次手動更新」。這個方向聽起來很合理，效率也確實更高——但這份清單本身是一個安全邊界，改成自動探索意味著任何新增的項目都會自動變成可以被觸發的入口，隱性擴大了原本刻意收斂的攻擊面。 這個方向最後被否決了。
這個案例值得記住的教訓是：AI 覺得「更自動化、更省事」的做法，不一定是對的方向,特別是牽涉到安全邊界、權限範圍這類「明確收斂」本身就是設計意圖的地方。 手動維護一份清單看起來笨拙，但這種笨拙有時候就是刻意的、用來限制風險範圍的設計，不是待優化的技術債。
用一組對照來看這三類問題的共同模式：
❌ AI 自己拍板：
「這個差異看起來影響不大，我保留新行為。」
「這個風險我評估了一下，應該還好，直接改掉了。」
「這份清單改成自動探索比較有效率，我改掉了。」
→ 三種情況的共同問題：AI 用自己的判斷,
取代了本該由人來做的取捨決定
✅ AI 呈現選項，人拍板：
「這個差異是這樣，影響範圍是這些，
需要你決定要不要保留這個行為改變。」
「這個風險存在，成本估算是這樣，
是要現在修，還是先記錄下來、之後再處理？」
「這份清單可以改成自動探索，
但這樣會讓攻擊面隨新項目自動擴大，
這個取捨你能接受嗎？」
→ 呈現查證過的事實跟選項，決定權留給人
這套方法論從 Day 01 到 Day 28 講的，本質上都是「怎麼把 AI 的查證範圍收斂到跟它的自信範圍一致」——這件事能解決「AI 是不是誤判了技術事實」，但解決不了「這個決定該不該由 AI 來做」。 前者是能力問題，後者是授權問題,兩者完全獨立。一個查證得再紮實的判斷，如果本質上是一個需要業務授權、安全授權的決定，紮實的查證只是讓這個決定的「呈現」更可信，不代表 AI 因此就有資格自己拍板。
回想這個系列前面提過的案例：有沒有哪一次，是 AI 明明查證得很紮實，卻不該由它自己做最終決定的情況？你當時有沒有意識到「查證得對」跟「有資格拍板」是兩件事？
明天是這個系列的最後一篇：如果重來一次，這整套流程會怎麼被重新設計——30 天的總結與回顧。
iThome鐵人賽
看影片追技術