用 AI 重構代碼：先補測試、小步修改、逐步驗證的安全流程與提示詞

本文根據 GitHub 官方 Copilot Chat Cookbook 的重構章節、Cursor 官方教學和 Claude Code 官方最佳實踐整理，資料核對於 2026-10-11。「重構」在這裏指不改變外部行為、只改善內部結構的修改。

適用於誰

• 接手了一份沒人敢動的老代碼，想借 AI 之力整理的人；
• 搜「ai 重構代碼」「ai 重構代碼提示詞」的人；
• 讓 AI 重構過一次，結果行為悄悄變了、或者改出一個審不動的巨型 diff 的人。

結論先說

1. 重構的定義就是行為不變。所以第一件事不是讓 AI 動手，而是用測試把現在的行為鎖住。
2. 先理解、再計劃、後動手。Cursor 官方把「沒弄懂現狀就讓智能體改」稱為常見的失敗模式：它可能新建一個已經存在的工具函數，或用一種和代碼庫不一致的寫法。
3. 一次只做一種重構，每一步都能獨立通過測試、獨立提交。
4. 寫清「什麼不能變」。Kiro 的 Bugfix Spec 把「不應改變的行為」單獨列成一項，是同一個思路。
5. 留好退路：Git 提交、工具的檢查點、獨立的 worktree。
6. 做不對時別硬修：撤銷 → 把方案寫得更具體 → 重來。

六步流程

第一步：先讓它講清現狀

用只讀的方式開始（Cursor 的 Ask 模式、Cline / Claude Code / Devin Desktop 的 Plan 模式），它就不會順手改東西：

text
先不要修改任何文件。閱讀 src/order/ 目錄，告訴我：
1. 下單流程經過哪些函數，畫一個調用順序；
2. 哪些地方有重複邏輯；
3. 項目裏已經有哪些公共工具函數是這裏本該複用的；
4. 哪些函數被目錄外的代碼調用（改它們的簽名會影響別處）。

Cursor 官方給的同類提示詞是：「在做任何修改之前，先給我看現有的表單校驗是怎麼工作的，用了什麼模式，共享的校驗器在哪。」

第二步：用測試鎖住行為

text
在重構之前，為 calculateOrderTotal 補「特徵測試」：不評判現在的行為對不對，
只把它現在對各種輸入的輸出記錄下來，包括邊界值。運行並確認全部通過。
不要修改業務代碼。

如果你發現現有行為裏有 bug，記下來，另開一個任務修。重構和修 bug 混在一起，出了問題就分不清是哪一步引起的。寫測試的細節見《用 AI 寫單元測試》。

第三步：讓它先出方案

涉及多個文件的重構，用 Plan 模式。Cursor 官方對 Plan 模式的適用場景描述正好對應重構：任務涉及很多文件或系統、有多種可行做法、想先審一下思路。

text
目標：把 src/order/ 裏三處重複的折扣計算合併成一個函數。
約束：
- 對外導出的函數簽名不變
- 不引入新依賴
- 不改數據庫結構
請給出分步方案，每一步都要能單獨通過測試、單獨提交。先不要實現。

看方案時重點看兩處：步驟是不是夠小；有沒有它沒提到、但你知道會受影響的調用方。

第四步：小步執行

按方案一步一步來，而不是「全部執行」：

text
執行方案的第 1 步。完成後運行測試和類型檢查，把結果貼給我，然後停下等我確認。

每一步確認沒問題就提交一次。Cursor 官方建議用小而語義清晰的提交——評審的人可以沿着提交歷史一步步看，而不是面對一整面牆的改動。

第五步：每步都跑三種檢查

Cursor 官方列的三種可驗證信號，重構時全都用得上：

• 測試：行為有沒有變；
• 類型檢查：改了簽名後有沒有漏改的調用方；
• lint：風格和模式有沒有走樣。

Claude Code 官方還有一條：讓它拿出證據（測試輸出、執行的命令和返回），而不是隻說一句「完成了」。

第六步：留好退路

常見的小型重構與提示詞

下面前三條的場景和提示詞思路來自 GitHub 官方 Cookbook《Improving code readability and maintainability》，做法都是先在編輯器裏選中要改的函數再提要求：

GitHub 的 Cookbook 裏還有針對性能優化、設計模式、數據訪問層、橫切關注點、繼承層次簡化、跨語言翻譯的重構示例，可以按需查閱。

大型重構怎麼辦

• 拆成多個 PR。按模組、按步驟拆，每個 PR 都能獨立上線。
• 把計劃寫成文件。Cursor、Devin Desktop 的 Plan 模式都會生成 Markdown 計劃文件，可以在新會話裏引用它繼續，避免長對話把上下文撐滿。
• 規則先行。把新的寫法約定寫進規則文件或 AGENTS.md。TRAE 官方文檔提醒過一個現象：項目裏已有大量不合規範的代碼時，模型可能沿用舊風格而不是新規則，建議明確告訴它當前任務是「重構」，並要求嚴格遵循新規則。
• 可以交給雲端智能體的部分。Cursor 官方把「重構」列為適合雲端智能體的任務之一——前提是有測試能驗證結果。

為什麼會翻車

行為變了沒發現。沒有測試，或者測試是重構之後才讓 AI 補的——那時測試只會記錄新行為。

diff 太大。一句「重構這個模組」換來兩千行改動，誰都審不動。永遠給出範圍和步驟。

順手做了別的。它把格式化、改名、升級依賴一起做了。在指令裏寫明「只做這一件事，不要順手修改無關代碼」。

重複造輪子。沒讓它先了解現有的公共函數。

在同一個長對話裏反覆修。Cursor 官方的建議：與其一輪輪追着修，不如回到計劃，把要求寫得更具體再跑一次，通常更快、結果更乾淨。Claude Code 官方也建議做完一件事就清空上下文。

常見問題

Q：沒有測試的老項目也能讓 AI 重構嗎？

先補特徵測試（第二步），哪怕只覆蓋要動的那幾個函數。完全沒有驗證手段時，只做風險最低的重構：改名、提取常量、格式整理，並逐個看 diff。

Q：讓它一次把全項目的某種寫法都改掉可以嗎？

機械性的批量修改可以，但要分批：先在一個目錄試，確認無誤後再推廣；每批跑一次全量檢查。

Q：重構後要不要再讓 AI 審一遍？

要，而且用新會話或專門的審查功能。見《AI 代碼審查怎麼做》。

參考資料

• Improving code readability and maintainability（GitHub 官方 Copilot Chat Cookbook）：https://docs.github.com/en/copilot/tutorials/copilot-cookbook/refactor-code/improve-code-readability
• Understanding your codebase（Cursor 官方教學）：https://cursor.com/learn/understanding-your-codebase
• Reviewing and testing code（Cursor 官方教學）：https://cursor.com/learn/reviewing-testing
• Plan Mode（Cursor 官方）：https://cursor.com/docs/agent/plan-mode
• Best practices（Claude Code 官方）：https://code.claude.com/docs/en/best-practices