要用 AI 重構程式碼，先凍結行為，再逐個測試小改動。遵循如何使用 AI限定範圍；模型輸出是提案，不是等價證明。

關鍵要點

編輯前先定義可觀察行為。

凍結修訂、允許檔案、命令、環境與回退點。

用特徵測試保護不明確的舊有行為。

先讓 AI 提供唯讀方案，再逐個批准小變換。

比較輸出、錯誤、狀態、副作用及必要的效能屬性。

測試通過是證據，不是語義等價的普遍證明。

範圍擴大或測試預言不足時立即停止。

何時適合用 AI 重構程式碼？

重構是在保留可觀察行為的前提下改善現有程式碼設計。Martin Fowler 將其描述為一連串小型、保持行為的變換；小步推進能降低系統長期處於損壞狀態的風險。［1］

請求	是否屬於重構	應採用的流程
更改內部輔助函式名稱而呼叫端不變	通常是	保持行為的重構
拆分長函式而輸出和副作用不變	通常是	重構加特徵測試
修改錯誤碼或回應欄位	不是	帶相容審查的契約變更
修正算錯的結果	不是	使用除錯流程
更換協議或資料庫結構	不是	使用程式碼遷移計劃
只因模組看起來陳舊便重寫	暫時不是	先定義問題和可觀察契約

不要把功能、缺陷修復、依賴升級或政策調整藏在 AI 程式碼重構內。只要期望行為需要變化，就應拆成另一項變更，單獨定義驗收條件。

凍結 AI 程式碼重構的修訂與範圍

向模型提供上下文前，先建立一張重構卡。它讓任務可重現，也能阻止看似聰明的建議悄悄擴大修補範圍。

欄位	合成例子
重構 ID	`RF-017`
起始修訂	`reviewed-revision-id`
目標	抽取重複解析邏輯
允許檔案	`parser.ts`、`parser.test.ts`
禁止變化	公開類型、訊息、資料庫寫入
測試命令	單元測試加一個整合場景
環境	執行環境版本與相關標誌
回退點	乾淨分支或已保存修補
負責人	逐步審批的工程師

同時記錄生成檔案、忽略檔案、本機改動與不可用依賴。不要把整個私人程式庫交給未經批准的服務；只提供完成任務所需的最小程式碼與契約，並移除憑證、客戶資料、私人 URL 和生產設定。

權限邊界和提示詞同樣重要。OpenAI 把沙箱與審批描述為互補控制：前者限制可寫位置與網絡，後者讓高風險動作停下來接受覆核。［3］預設從唯讀、窄寫入範圍和無網絡開始。

編輯前定義保持行為的重構

「不改變行為」必須說明觀察者。純函式可能只看回傳值和錯誤；服務還會暴露 HTTP 狀態、欄位、事件次序、交易、日誌欄位、重試、時間預算與下游訊息。

行為 ID	輸入或前置條件	預期觀察	預言	必須保持
`B-01`	合法合成記錄	相同規範化物件	精確斷言	是
`B-02`	缺少必填欄位	相同錯誤類型和代碼	快照加類型檢查	是
`B-03`	重複事件	只發生一次冪等寫入	整合斷言	是
`B-04`	10,000 筆批次	在獲批預算內完成	受控基準	只在契約要求時

加入失敗、邊界與狀態轉換，不要只測正常路徑。標出哪些行為是明確設計、哪些是呼叫端依賴的歷史特徵、哪些仍未知。未寫入文件的細節也可能已成為相容契約。

效能不必自動成為語義行為，但真實系統可能把延遲、記憶體或次序寫進服務目標。此時要先定義門檻與量度環境，不能在看到結果後讓 AI 臨時發明標準。

如何建立可信基線？

首次編輯前執行獲批命令，並保存完整退出碼與結果。如果沒有證明相同測試在起始修訂通過，重構後的綠色結果就缺少可比較對象。

舊有程式碼意圖不清時，用特徵測試記錄目前觀察。它們描述「現在做甚麼」，不表示每個歷史細節都永遠正確。生成測試的流程可協助列出輸入，但預期值必須來自規格、呼叫端、測試夾具或受控基線，而不是讓模型照着目前實作猜測。

基線包至少記錄：

修訂與工作樹狀態；
執行環境、依賴、功能開關、區域設定和時區；
精確命令與退出碼；
測試總數與具名失敗；
基準檔案或快照的欄位理由；
關鍵副作用的最小整合追蹤記錄；
已知缺口、不穩定測試和不可用環境。

若實作與測試由同一個模型同時猜測，兩者可能共享同一錯誤假設，這不是獨立證據。

先讓 AI 提交唯讀變換方案

先要求模型解釋目前路徑並拆出最小步驟，讓「理解」與「修改」分開。

目標：改善內部結構，同時保持 Behavior ID B-01..B-04。
範圍：只允許 parser.ts 和 parser.test.ts；公開類型與訊息凍結。
證據：已附基線命令和結果。
先返回唯讀計劃，把每項編輯對應到程式碼壞味道、不變量和檢查它的測試。
不得編輯檔案、加入依賴、改變行為、刪除測試或執行網絡／高權限命令。
缺少證據的內容標為 [UNKNOWN]。

要求它列出假設、受影響呼叫端、副作用和每步回退方法。若模型無法沿程式碼追蹤資料或狀態，可先使用解釋陌生程式碼的方法，不要急於授權編輯。

GitHub 的負責任使用文件指出，AI 生成程式碼可能看似合理，語義上卻是錯誤；敏感應用尤其需要覆核與測試。［2］自信的方案仍只是假設。

一次只應用一個小變換

先批准最小且可逆的改動，例如重命名局部符號、抽取純輔助函式、移除已證實的重複、把巢狀條件改為等價保護條件，或隔離適配器。不要讓模型一次重寫整個模組。

每一步之後：

閱讀改動行及完整差異；
確認沒有越界檔案、依賴、生成資產或設定變化；
執行最窄的相關測試；
執行約定基線；
比較副作用追蹤記錄與快照；
把結果寫回行為台賬；
按程式庫正常政策保存本機回退點。

避免在行為敏感重構中混入大範圍格式化。噪音會掩蓋條件、預設、遺漏分支和錯誤路徑變化。若必須格式化，應拆成獨立且可重現的機械步驟。

模型若提出更換公開名稱、加入程式庫、修改並行或重寫資料庫，就先停止。這些可能有價值，但需要新的契約與風險評估。

怎樣逐層驗證不改變行為的程式碼重構？

層級	前後比較內容
純邏輯	回傳值、錯誤、狀態變更、確定性
公開 API	狀態、欄位、類型、次序、相容性
持久化	語句、交易邊界、影響筆數
事件與佇列	主題、載荷、數量、次序、冪等性
檔案	路徑、位元組、權限、必要原子性
並行	取消、擁有者、競態、資源釋放
營運	日誌、指標、告警、啟動與失敗行為

使用合成或獲批測試夾具。對非確定輸出比較穩定屬性，而不是不斷接受被重寫的快照；對時間行為控制時鐘；只有契約允許時才固定隨機種子，並繼續檢查允許範圍。

測試通過只能提高信心，不能證明所有狀態等價。NIST 的生成式 AI 風險資料把虛構、私隱、資訊保安與人工監督納入生命週期治理。［4］模型解釋自己的修補為何安全時，同樣需要外部證據。

如何覆核差異並判斷何時回退？

脫離模型敘述重新閱讀最終差異，檢查條件、預設、例外、清理路徑、邊界轉換、鎖和外部呼叫。然後可用AI 程式碼審查方法作第二視角，但不能把它當唯一批准者。

出現以下任一情況就回退目前步驟：

原本通過的基線測試失敗；
可觀察結果在沒有契約變更下改變；
修補觸及允許範圍外檔案；
模型刪除或削弱測試以製造綠色結果；
公開介面、依賴、權限或網絡行為變化；
效能越過預先定義的契約預算；
環境無法重現基線；
差異大到無法逐行解釋。

歸檔行為台賬、命令、結果、剩餘缺口、覆核人和最終修訂。「AI 說等價」不是證據；小型可解釋差異與可重複觀察才是。

總結檢查表

任務是內部重構，不是隱藏功能或缺陷修復。
用 AI 重構程式碼所用的修訂、環境、檔案範圍和回退點均已凍結。
行為契約涵蓋輸出、錯誤、狀態和必要副作用。
首次修改之前已有基線證據。
特徵測試使用獨立理由確定預期值。
AI 在編輯前提交唯讀計劃。
每個變換都小、可逆，並被單獨驗證。
最終差異沒有無關格式化或依賴變化。
公開契約與必要營運行為完成前後比較。
未驗證屬性繼續明確保留。

常見問題

用 AI 重構程式碼時，怎樣避免變成重寫？

重構以小步驟改善內部結構，並保持已定義行為；重寫替換更大的實作，等價性問題和風險範圍通常更闊。

測試能證明用 AI 重構程式碼絕對安全嗎？

不能。測試只證明選定案例在選定環境中的觀察一致，還要結合規格、類型檢查、覆核、整合證據和安全監察。

用 AI 重構程式碼時，甚麼是特徵測試？

它記錄意圖不完整或不明確程式碼的目前可觀察行為。它保護已被依賴的行為，但不宣稱每個歷史特徵都永遠正確。

可以一次用 AI 重構程式碼覆蓋整個模組嗎？

通常不應。先限制一個關注點和少量檔案，逐步驗證；大規模生成式重寫很難定位行為變化的具體原因。

更高覆蓋率是否代表用 AI 重構程式碼更安全？

覆蓋率只顯示程式碼是否執行，不證明斷言正確，也不涵蓋所有相關狀態。還要檢查斷言質素、邊界、副作用和整合路徑。

非確定行為怎樣比較？

在合理範圍內控制時間和隨機性，再比較穩定不變量、允許範圍或事件集合。不要因精確相等麻煩而不斷接受變化的快照。

效能必須完全一樣嗎？

只有預先寫入契約的效能屬性需要保持在獲批預算內。要在可比較環境量度，並區分真實回歸與噪音。

AI 想修改公開介面怎麼辦？

從重構中拒絕該步驟，另建相容或遷移提案，明確消費者、版本、上線與回退。

甚麼時候不應用 AI 重構程式碼？

程式碼不能進入獲批工具、行為預言缺失、修補無法被人理解，或任務跨越高風險權限邊界而沒有合資格監督時，應避免或嚴格限制。

來源

Martin Fowler, “Refactoring” — https://www.martinfowler.com/books/refactoring.html
GitHub Docs, “Application card: GitHub Copilot inline suggestions” — https://docs.github.com/en/copilot/responsible-use/inline-suggestions
OpenAI, “Running Codex safely at OpenAI” — https://openai.com/index/running-codex-safely/
National Institute of Standards and Technology, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile” — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

如何用 AI 重構程式碼而不改變行為：基線、小步變換與逐層驗證