全自動程式碼重構

跨檔案理解依賴關係,一條指令批量重構整個專案 —— 不是改變數名,是真正的結構級重構

傳統重構有多痛,你肯定懂

手動重構 = 加班 + 祈禱

改一個函式名,得全局搜尋改 100 個檔案。改完還怕漏了哪個引用,跑完測試發現三個地方炸了,又開始二分法排查。越是大專案越不敢動,結果技術債越積越多,誰都不想碰那坨程式碼。更別說 class 拆分、模組抽取這種大手術 —— 手動搞,至少一週起步。

OpenClaw 怎麼解決這個問題

一條指令掃描整個專案,跨檔案理解依賴

OpenClaw 不是只看你當前打開的檔案 —— 它會讀取整個專案目錄,分析 import 鏈、函式呼叫關係、類型定義、模組依賴,然後再動手改。改完自動跑測試確認沒破壞現有功能。你只要說「把這個專案從 class 改成 hooks」,剩下的它來。

拿走就能用的 Prompt

這三條 Prompt 覆蓋了最常見的重構場景,直接複製粘貼。

把專案從 Class Component 重構為 React Hooks 黃金指令
請分析當前專案中所有 React Class Component 檔案。

執行以下重構任務:
1. 將每個 class component 轉換為函式元件 + Hooks
2. this.state / this.setState → useState
3. componentDidMount / componentWillUnmount → useEffect
4. 提取可複用邏輯為自訂 Hook
5. 保持 props 介面不變,確保父元件不用改
6. 跑一遍現有測試確認沒有 break

每個檔案的改動單獨列出,說明改了什麼、為什麼這樣改。
這條在 Claude Opus 上效果拉滿,它能正確追蹤 this 引用和生命週期的對應關係。檔案多的專案建議按目錄分批執行。
統一專案的錯誤處理模式 進階技巧
分析當前專案中所有的錯誤處理程式碼。

當前狀態審計:
- 找出所有 try-catch 塊、.catch() 呼叫、error callback
- 列出不一致的地方(有的吞掉錯誤、有的只 console.log、有的往上拋)

統一方案:
1. 建立統一的 AppError 類(包含 code, message, cause)
2. 建立全域錯誤處理中介軟體
3. 所有業務層用 AppError 拋出,不直接 throw new Error
4. API 層統一返回 { success: false, error: { code, message } }
5. 給出修改後的檔案清單和 diff
這條 Prompt 讓 AI 先審計再動手,避免盲目修改。適合專案裡錯誤處理一團糟的情況。
將 JavaScript 專案遷移為 TypeScript 黃金指令
我要把這個 JavaScript 專案遷移到 TypeScript。

請按以下步驟執行:
1. 分析專案結構,生成 tsconfig.json(strict 模式)
2. 從入口檔案開始,按依賴順序逐個遷移 .js → .ts/.tsx
3. 為所有函式參數和返回值添加型別註解
4. 將 any 使用降到最低,盡量用具體型別
5. 為第三方套件安裝對應的 @types 包
6. 建立 types/ 目錄存放公共型別定義
7. 確保 tsc --noEmit 通過,沒有型別錯誤

每個檔案列出改動摘要。如果某些地方必須用 any,說明原因。
JS 轉 TS 是最常見的遷移需求。這條 Prompt 讓 AI 按依賴順序來,而不是亂序遷移導致到處報錯。

推薦配置

重構任務建議用這套配置,讓 AI 更謹慎、更可控。

skill_config — 程式碼重構專用
# .openclaw/skill_config.yaml
refactor:
  model: claude-opus-4-6      # 重構首選 Opus,跨檔案理解最強
  context_depth: full         # 讀取完整專案結構
  safety:
    dry_run: true              # 先預覽改動,確認後再寫入
    run_tests: true            # 改完自動跑測試
    backup: true               # 改之前先備份
  ignore:
    - node_modules/
    - dist/
    - "*.min.js"

OpenClaw vs Copilot —— 重構能力對比

OpenClaw 重構
  • 理解整個專案的依賴圖,改一處自動更新所有引用
  • 跨檔案批量重命名、提取公共模組、拆分巨型檔案
  • 改完自動跑測試驗證,有問題立刻回退
  • 支援自訂重構規則和黑名單
VS
Copilot 重構
  • 主要在當前檔案內補全和建議修改
  • 跨檔案重構需要手動逐個打開檔案
  • 沒有內建的測試驗證流程
  • 依賴 IDE 的重構功能,能力受限於 IDE 外掛

更詳細的對比 👉 OpenClaw vs Copilot · OpenClaw vs Cursor

實戰場景:大型專案重構

10 萬行 React 專案從 Class 遷移到 Hooks
一個 3 年老專案,200+ 個 class component,團隊想遷移到 Hooks 但沒人敢動。預估手動遷移要 3 個月。
OpenClaw 方案
用 Prompt 讓 AI 按模組分批遷移,每批改完跑測試。全程 2 天完成,0 個線上 Bug。關鍵是 AI 能正確處理 this 綁定、生命週期映射、ref 轉換這些容易出錯的地方。
傳統方案
手動逐個檔案改。改到第 50 個檔案的時候開始出現遺漏,this 綁定遺失導致執行時報錯。最後花了 2 個月,還留了十幾個 Bug 在線上。
結論:專案級重構是 AI 最能體現價值的場景 —— 不是快一點點,是量級上的碾壓。

重構場景用哪個模型

重構對模型的程式碼理解能力要求最高,別省這個錢。

  • Claude Opus 4.6 —— 大型重構首選,跨檔案依賴追蹤最強
  • GPT-4o —— 中小型重構夠用,速度更快
  • DeepSeek V3.2 —— 預算有限時的替代方案,效果也不差

幾條經驗

💡 大專案別一次全改 —— 按模組分批重構,每批改完跑測試確認,再改下一批。
⚠️ 重構前先確認測試覆蓋率足夠。沒有測試的程式碼,AI 改完你也不知道對不對。
ℹ️ 用 dry_run 模式先預覽改動。覺得沒問題再讓 AI 真正寫入檔案。
這篇案例對你有幫助嗎?