wen aidev
Published on

Kiro SDD 入門（四）：為什麼 AI 幫你重構總是越搞越糟？(AST vs LSP 實戰)

Table of Contents

你是否有過這種經驗：在 Cursor 裡或用 Claude Code 叫 AI 「幫我把專案裡 User 這個變數名稱統一改成 Client」？

結果 AI 回報「修改完成！✨」，你興沖沖地跑 yarn dev，迎面而來的就是滿滿的紅色報錯：

  • 某個檔案的 import { User } 忘記改成 Client。
  • 其他檔案裡單純的註解 // notify the User 莫名其妙變成了 // notify the Client。
  • 更慘的是，某個以 User 為名的資料夾被移動了，導致四五個檔案的相對路徑 ../../User/api 壞得一塌糊塗。

為什麼 AI 那麼聰明，卻連個重新命名都做不好？ 因為你把「重構 (Refactoring)」當成了「純文字替換 (Text Edit)」。

上一篇我們聊了 Bug Fix Paradox，這一篇我們來聊聊，在 2026 年的今天，我們該如何建立正確的 Agentic Workflow，讓 AI 安全且完美地幫我們重構。

理論篇：重構的底層邏輯（AST 與 LSP）

在探討怎麼叫 AI 做事前，我們要先理解為什麼傳統的 Find & Replace（也就是預設 AI 幫你改程式碼的方式）一定會出包。

重構不是編輯文章，而是一個**「尋找 AST (抽象語法樹) 關聯」的精確工程**。當你「只改一個名字」或「搬移一個檔案」時，背後牽扯到 imports、exports、linter 規則，以及 module resolution。

文字替換 vs AST/LSP 語意替換對比圖

1. 傳統 AI：瞎子摸象 (Text-based)

當你叫 AI 改名時，它（如果沒有配備好工具）就是拿著你給的字串，用正規表示式去整個專案裡撈。這種「純文字替換」沒有上下文觀念，它不知道哪個 User 是一個 interface，哪個 User 只是一個恰巧同名的變數。所以誤殺（改錯註解）跟漏殺（沒改到動態 import）幾乎是必然的。

2. 現代作法：上帝視角 (Semantic-based)

如果你平時用 VSCode，當你在一個變數上按下 F2 (重新命名)，IDE 是不會猜測的。它是去問 LSP (Language Server Protocol)。LSP 早就把你的檔案解析成了一棵巨大的 AST 樹狀依賴圖，它知道這個 User 的定義在哪，且被哪 15 個檔案精確引用。

重構是精確的外科手術，不該交給只會文字接龍的 LLM 盲目瞎猜。

實務篇：如何在 2026 讓 AI 幫你正確重構？

既然知道了問題出在哪，我們該怎麼解決？身為開發者，你需要幫 AI 準備對的「手術刀」。

目前我們有兩種手術刀：LSP 與 AST CLI 工具。很多開發者會把它們搞混，認為只要是操作 AST 就好。我們用一張決策矩陣來告訴你何時該用誰：

LSP 與 AST 工具的重構策略象限圖

迷思釐清：AST vs LSP 哪個好？

  • 🥇 LSP 是王者 (負責 90% 日常重構)：如果你只是要重新命名檔案/符號、搬移資料夾、把一段 code 提取成共用函式，直接呼叫 LSP 是最佳解。因為它已經是內建好全域索引的上帝視角（就像你手動按 F2）。
  • 🛠️ AST 工具是特種部隊 (負責大規模客製重構)：如果你遇到 LSP 預設按鈕沒有的功能，比如：「把整個專案的 React Class Component 全部轉換成 Hooks」，LSP 辦不到。這時候才需要派出 AI 去操作 ast-grep 或 jscodeshift 寫腳本硬派轉換。

下指令的藝術 (以 Claude Code 為例)

現在，當你在終端機啟動 Claude Code 時，請改變你的詠唱習慣。

❌ 傳統的災難 Prompt：

「幫我把整個專案的 authHelper 改名成 securityCore，還有幫我把 Auth.tsx 移到 shared 資料夾。」 (下場：Claude 會開始生成 bash 腳本，用 sed 指令或是手動幫你改檔，保證跑完後一堆破圖跟路徑錯誤。)

✅ Agentic Workflow 的正確 Prompt：

「我要把 authHelper 重命名為 securityCore。請你不要手動去改文字，請去呼叫 LSP / 當前專案的 refactor CLI / IDE Rename API 來執行這件事。改完後請跑 yarn lint 確保所有的 import 都有被自動更新。」

如果你使用的環境（如 Kiro 或搭配特定 Agent 擴充包）已經把 IDE 的 LSP Refactor API 暴露給 Agent，AI 就能自己去「按 F2」。

💡 給進階玩家的提示：

如果你的 CLI 環境沒有串接 LSP，你可以直接指使 Claude Code 去跑你設定好的 eslint --fix 或是你寫好的 ast-grep rule。重點在於：讓 AI 腦去下達指令給驗證過的底層工具，而不是讓 AI 的手親自去改 code。

結論：Agentic AI 的正確協作邊界

在 2026 年，一個設計優良的代理（Agent）工作流，不應該是什麼都叫 LLM 自己硬刻。

Agentic 重構協作授權決策模型

就像上圖展示的，一個完美的重構回合應該是：

  1. 開發者 (你)：給出重構意圖（我要重組架構、改名）。
  2. AI Agent (Claude Code)：負責理解意圖與統籌流程。它知道要改名，但它克制住自己寫 code 的衝動。
  3. AST Tool / LSP：做為精確的手術刀。AI 將任務委託給它，由它來尋找語法樹結點，並一次性安全地刷新全部檔案的路徑。

AI 應該成為指揮官，而不是拿著磚頭亂敲的工人。 把「創意與意圖」交給 AI，把「精確與結構」交給編輯器底層工具，這才是 Agentic AI 能真正安全落地的唯一心法。

參考與延伸閱讀

支持作者 ☕

台灣用戶：

透過 LINE Pay 支持

國際用戶：

透過 Ko-fi 支持

留言討論