叫 AI 寫少啲 code：由加功能轉去刪重複邏輯，點樣先唔會愈改愈亂
先跑測試、逐小步刪 code，同一句「執整齊啲」差好遠
XDA 作者 Mahnoor Faisal 分享，自己用 AI coding 工具一段時間之後，開始少啲叫模型加功能，反而會問佢邊段 code 可以刪、邊個 function 已經重複、想做嘅功能係咪一早存在。呢個做法值得留意，因為 coding agent 通常會順住要求交出一個可行 patch，未必主動停低檢查兩個月前有冇另一套近似邏輯。結果每個功能都行到，但個 codebase 會慢慢塞滿半重複 helper、冇人行嘅 branch 同過早抽象。
刪 code 之前，先鎖住現有行為
第一步唔應該叫 agent 即刻改檔。先喺乾淨 branch 跑現有 test suite、lint、type check 同 build，確認未開始改之前已經係綠燈；API、CLI 或資料轉換程式亦可以記低幾個代表性輸入同輸出。GitHub 嘅 AI code review 指引同樣建議先跑自動測試同靜態檢查。呢條基線好重要，否則刪完先發現測試失敗，你根本分唔清係模型整壞咗，定個專案本身一早有問題。
跟住可以叫 agent 只交報告，暫時唔改 code：列出冇引用嘅 import、疑似冇 call site 嘅 function、內容近似嘅實作，同每項判斷用過咩搜尋結果。再問多句「呢段邏輯有冇俾 route、config、test、script 或 plugin 間接呼叫？」會穩陣好多。模型最有價值嘅位置係幫你快速縮窄範圍；刪邊段，仍然要由睇得明個系統嘅人決定。
「執整齊啲」範圍太闊，refactor 要講清楚邊樣行為唔可以變
GitHub 對 refactoring 嘅定義係重組現有 code，但保留原有行為。單叫模型「clean this up」就冇呢條界線，佢可能同時改名、搬檔、合併 function、轉 error handling，順手又換埋資料結構。個 diff 睇落幾乾淨，實際要一次過審核幾種風險。穩陣啲嘅做法，係寫明檔案範圍、可以刪邊類 code、邊啲 public API 必須保留，仲要限制每次只處理一組重複邏輯。
落手改時，每次只畀 agent 做一個細任務，例如移除一批已確認冇用嘅 import，或者將兩段相同計算收歸現有 helper。睇完 diff 就重新跑相關測試，再開一個細 commit；下一輪先處理另一項。咁做唔只方便 review，出事時亦容易用版本紀錄搵返邊一步改壞咗。GitHub Copilot CLI 甚至提供 commit 前 review，但機器 review 只宜當多一層檢查，唔應代替原作者或負責嗰部分系統嘅同事。
Test suite 全綠，都未證明嗰段 code 真係可以刪
所謂 dead code 最麻煩係有啲依賴唔會以普通 function reference 出現。Reflection、dynamic import、用字串註冊嘅 handler、feature flag、排程工作、migration、外部客戶用緊嘅 API，都可能令一段「搜尋唔到 call site」嘅 code 繼續有用。舊 branch 亦可能係災難時先用嘅 fallback。GitHub 特別提醒，review AI code 時要防模型刪除或者跳過失敗測試；所以測試本身都要入 review，唔可以俾 agent 為求綠燈順手削弱 assertion。
研究亦顯示，refactoring 唔係模型穩贏嘅項目。2026 年公開嘅 SWE-Refactor 預印本收集咗 18 個 Java 專案、1,099 個由開發者完成、而且保留原有行為嘅重構案例，再用編譯、測試同自動偵測工具驗證。研究入面，複合式重構仍然係主要失敗來源，其中一個 Codex agent 喺 compound cases 嘅成功率只有 39.4%。個 benchmark 唔代表所有語言同工具，但足以提醒大家：一次改得愈多，模型漏睇隱性關係嘅機會就愈高。
實用版本係先查、再刪、逐步驗證
一個可直接用嘅要求可以係：「先檢查指定目錄，搵出重複邏輯、冇直接引用嘅 symbol 同疑似失效 branch；唔好修改檔案。逐項列出 call site、可能嘅間接依賴、建議驗證方法同信心程度。」人工揀定一項之後，再叫 agent 只改相關檔案、保留對外行為、補返缺少嘅 regression test，最後逐行審 diff。用開 coding agent 嘅個人開發者同團隊，可以由下一個細改動試呢套做法，唔使等個 codebase 大到連模型都讀唔清先處理。
參考來源
- XDA Developers — I stopped asking AI to build features and started asking it to remove code — original report
- Refactoring code with GitHub Copilot — GitHub 官方文件，解釋 refactoring 要保留原有行為，亦示範處理重複同冗長 code。
- Review AI-generated code — GitHub 官方審核指引，建議先跑測試同靜態檢查，並提醒留意 AI 刪除或跳過失敗測試。
- Requesting a code review with GitHub Copilot CLI — GitHub 官方文件，交代 commit 前用 Copilot CLI 審查改動嘅方式。
- SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring — 2026 年預印本，以 repository 級案例評估 LLM 重構，顯示複合式改動仍然容易失敗。
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
