全自動程式碼重構
跨檔案理解依賴關係,一條指令批量重構整個專案 —— 不是改變數名,是真正的結構級重構
傳統重構有多痛,你肯定懂
手動重構 = 加班 + 祈禱
改一個函式名,得全局搜尋改 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 真正寫入檔案。