在日常軟體維護中，手動重構龐大且混亂的遺留函式往往是工程師面臨的效率瓶頸。一個長達數百行、交織著多層條件巢狀、隱式狀態修改、回呼地獄（Callback Hell）以及陳舊廢棄邏輯（殭屍代碼）的複雜函式，若完全依賴逐行人工修改，極易引入細微的語法錯誤，破壞原有的變數作用域，甚至引發嚴重的迴歸缺陷。
針對這項工程痛點，Mutable.ai 在其官方 Visual Studio Code 擴充套件中推出了 Auto Edit（自動編輯） 功能。與單純依賴游標位置的行級代碼自動補全，或是需要頻繁在瀏覽器與 IDE 之間複製貼上代碼的外部聊天介面不同，Auto Edit 是一個深度整合在編輯器內部的自然語言重構引擎。開發者只需在編輯器中選定目標代碼塊，輸入具體的自然語言指令，即可借助代碼庫全域上下文完成原子級、可驗證的代碼重構與邏輯更新。
1. Auto Edit 與傳統代碼補全及 AI Chat 的核心區別
在 AI 輔助開發工具中，常見的互動型態主要分為兩類：
- 行內補全（Inline Autocomplete / Ghost Text）： 類似 GitHub Copilot 的補全機制，根據當前游標位置預測接下來的一兩行代碼。這種模式適合快速編寫樣板代碼，但無法理解整段複雜函式的架構脈絡，也無法安全地重新梳理跨邏輯塊的依賴關係。
- 側邊欄聊天（Chat Panel）： 開發者透過側邊欄對話框要求 AI 提供重構方案。但這種方式需要開發者手動將代碼複製到側邊欄，生成後再手動貼回檔案，打斷了連續的編程心流，且容易因局部上下文缺失導致介面調用脫節。
Mutable.ai 的 Auto Edit 將自然語言指令與原生 IDE 互動無縫融合：
- 原地就地修改（In-Place Transformation）： 重構直接在當前活躍的檔案編輯視窗中執行，嚴格遵循原有的縮排格式、代碼風格與行號佈局。
- 全域代碼庫感知（Codebase Awareness）： 借助對整個專案依賴與架構的索引，模型能夠確保重構後的函式簽名、型別定義及調用關係與儲存庫其他模組保持一致。
- 直觀 Diff 審查（Visual Diff Inspection）： 重構結果生成後，以 VS Code 原生紅綠高亮差異視圖呈現，開發者擁有行級的審查與確認權。
2. 在 VS Code 中喚起 Auto Edit 的三種方式
Mutable.ai 擴充套件為開發者提供了極具針對性的觸發入口：
| 觸發方式 | 入口路徑 | 最佳使用場景 |
|---|---|---|
| Code Lens | 點擊懸浮於函式宣告上方的 Auto Edit 快捷標籤 | 針對單一函式、方法或類別的精確重構 |
| 狀態列（Status Bar） | 點擊 VS Code 底部狀態列中的 Mutable.ai 圖示 | 快速呼出全域編輯指令或檢視服務狀態 |
| 右鍵快顯功能表 | 在編輯器內反白選取範圍或在檔案總管中右鍵點擊檔案，選擇 Mutable.ai: Auto Edit | 多代碼塊批量修改或跨檔案邏輯調整 |
觸發後，編輯器會在目標代碼上方彈出一個輕量級的懸浮提示框，等待開發者輸入重構指令。
3. 自然語言重構複雜函式的標準工作流程
使用 Auto Edit 重構高圈複雜度函式的推薦工程步驟如下：
[目標複雜函式]
│
▼
[步驟 1: 選定代碼範圍] ──► [步驟 2: 喚起 Auto Edit] ──► [步驟 3: 編寫精確提示詞]
│
▼
[步驟 5: 提交與驗證] ◄──── [步驟 4: 審查原生 Diff] ◄──── [AI 引擎上下文合成]
步驟 1：精確選定目標函式
完整反白需要重構的函式代碼塊，或將游標放置在函式名稱所在的宣告行。清晰的選取範圍能為模型劃定確切的重構邊界，避免誤傷相鄰函式或不相關的頭部引用宣告。
步驟 2：透過 Code Lens 啟動 Auto Edit
點擊函式頂部的 Auto Edit Code Lens 標籤。此時擴充套件會鎖定當前函式內容作為上下文輸入，並啟用自然語言輸入框。
步驟 3：編寫高精準度的重構提示詞
提示詞應清晰表述重構目標、架構規則與向下相容性，避免模糊的「最佳化這段代碼」。推薦採用結構化提示：
- 「重構此龐大函式：將參數驗證與回應資料解析提取為獨立的私有輔助函式，主函式僅保留呼叫骨架。」
- 「消除深層 if-else 條件巢狀，改為基於保護語句（Guard Clauses）的提前返回（Early Return）結構。」
- 「將基於 Promise .then() 的回呼鏈改造為現代 async/await 語法，並增加型別化的 try/catch 例外攔截。」
- 「為所有輸入參數與回傳值補充嚴格的 TypeScript 介面型別，清理不再使用的遺留暫存變數與殭屍分支。」
步驟 4：審查編輯器內生成的 Diff 視圖
Mutable.ai 生成重構代碼後，會在當前編輯器內展示差異對比：
- 紅色區塊： 被移除的深層巢狀分支、冗餘暫存變數或歷史廢棄邏輯。
- 綠色區塊： 扁平化的保護語句、新提取的子函式以及規範的型別標註。
開發者需重點核對：函式對外暴露的回傳結構是否被破壞、錯誤拋出機制是否符合系統原有規範。
步驟 5：採納、微調或復原
- 採納（Accept）： 按 Enter 鍵或點擊
Accept Diff，重構代碼直接寫入檔案。 - 微調（Iterate）： 若生成的邏輯存在邊界瑕疵，可在提示框中繼續追加指令（如：「保留原有的錯誤代碼 ERR_INVALID_PAYLOAD」），引擎將即時更新 Diff。
- 復原（Discard）： 按
Esc鍵或點擊放棄，代碼瞬間恢復原狀。
4. 實戰案例：重構混亂的訂單處理函式
以下是一段典型的遺留 JavaScript 函式，存在多層回呼巢狀、隱式狀態計算以及早已失效的促銷降級分支。
遺留代碼（重構前）
function processOrder(order, callback) {
if (order) {
if (order.id && order.items && order.items.length > 0) {
var total = 0;
for (var i = 0; i < order.items.length; i++) {
if (order.items[i].price && order.items[i].qty) {
total += order.items[i].price * order.items[i].qty;
} else {
// 2021年促銷活動的遺留降級邏輯
if (order.legacyPromo) {
total += 10;
}
}
}
if (order.user && order.user.email) {
database.saveOrder(order.id, total, function(err, res) {
if (err) {
callback(err, null);
} else {
emailService.sendReceipt(order.user.email, res, function(err2) {
if (err2) {
callback(null, { status: "partial_success", res: res });
} else {
callback(null, { status: "success", res: res });
}
});
}
});
} else {
callback(new Error("Missing user email"), null);
}
} else {
callback(new Error("Invalid items payload"), null);
}
} else {
callback(new Error("Empty order"), null);
}
}
Auto Edit 自然語言指令
「將 processOrder 重構為符合現代標準的 TypeScript 代碼：使用 async/await 取代回呼函式，使用提前返回的保護語句展平多層條件巢狀，將訂單總額計算拆分為獨立的輔助函式，徹底移除 legacyPromo 殭屍分支，並為 Order 和 OrderResult 定義嚴格的介面型別。」
重構後的現代代碼（重構後）
interface OrderItem {
id: string;
price: number;
qty: number;
}
interface Order {
id: string;
items: OrderItem[];
user: { email: string };
}
interface OrderResult {
status: "success" | "partial_success";
res: unknown;
}
function calculateOrderTotal(items: OrderItem[]): number {
return items.reduce((sum, item) => sum + item.price * item.qty, 0);
}
async function processOrder(order: Order): Promise<OrderResult> {
if (!order) {
throw new Error("Empty order");
}
if (!order.id || !order.items || order.items.length === 0) {
throw new Error("Invalid items payload");
}
if (!order.user?.email) {
throw new Error("Missing user email");
}
const total = calculateOrderTotal(order.items);
const res = await database.saveOrder(order.id, total);
try {
await emailService.sendReceipt(order.user.email, res);
return { status: "success", res };
} catch (emailError) {
return { status: "partial_success", res };
}
}
重構帶來的架構改善：
- 圈複雜度大幅降低： 巢狀層級從最初的 6 層縮減為平鋪直敘的單層保護語句。
- 清除技術債務： 徹底剔除無測試涵蓋的歷史遺留分支
legacyPromo。 - 職責單一化： 訂單金額計算剝離至
calculateOrderTotal，便於單獨編寫單元測試。 - 編譯期安全： TypeScript 介面為上游調用方提供了堅固的型別保障。
5. 工程最佳實踐與避坑要點
在使用自然語言重構複雜邏輯時，團隊應遵循以下工程規範：
推薦實踐
- 堅持原子化重構： 切忌一次性對上千行的模組下達「全面重寫」指令。應拆解步驟：先展平邏輯分支，再拆分子函式，最後完善型別體系。
- 優先建立測試防護網： 在重構前確保函式具有核心單元測試或端對端測試。Diff 合併後立即執行測試套件驗證行為一致性。
- 對齊專案既有範式： 在指令中要求沿用代碼庫既有規範（例如：「遵循專案中已有的 Result<T, E> 錯誤處理模式」）。
常見誤區
- 盲目採納 Diff： 絕不在未經審查的情況下直接一鍵 Accept，需特別檢查閉包參照、預設參數及例外拋出時機。
- 指令過於籠統： 像「最佳化效能」這樣空泛的詞彙容易導致模型誤解意圖，甚至引入過度複雜的快取或演算法改動。
- 忽視外部調用契約： 若原本的同步函式被改為非同步 Promise，必須核實所有外部調用端是否已支援 await。
6. 產品發展現狀與當代工具生態
Mutable.ai 由 Omar Shams 與 Maxwell Siegelman 創立於 2021 年（Y Combinator W22 批次），早期以高品質代碼自動文件（Auto Wiki）與全專案上下文感知編程助手聞名。
2024 年 12 月，Mutable.ai 被 Alphabet（Google）正式收購。收購完成後，Mutable.ai 獨立商業服務及其在 VS Code 市集的獨立擴充套件逐步完成歷史使命，相關核心資產與團隊併入 Google 生態體系。儘管該擴充套件已不再於主渠道分發，但 Mutable.ai 所確立的「編輯器內原地自然語言編輯」、「跨儲存庫上下文理解」與「互動式原生 Diff 確認」設計哲學，已成為當今 AI 編程體系的標準規範。如今，Cursor 的 Composer、GitHub Copilot Edits 以及開源工具 Continue.dev 和 Aider 等，均在延續並深化這一自然語言驅動的代碼重構範式。