目前，每位 Claude Code 使用者都未啟用 LSP。這表示每當你詢問「processPayment 定義在哪裡？」時，Claude Code 就像你在終端機使用 grep 一樣，透過搜尋整個程式碼庫中的文字模式，閱讀數十個檔案，試圖找出真正的定義。
這方法確實可行，但速度緩慢且模糊，在大型程式碼庫中經常會漏掉或搞混。以真實專案搜尋 User 為例，會得到 847 個匹配結果，分布在 203 個檔案中：類別定義、變數名稱、註解、匯入、CSS 類別、SQL 欄位。你真正想找的東西？往往藏在中間某處。Claude Code 必須逐一閱讀每個匹配結果來縮小範圍，耗時約 30 到 60 秒，有時更久。
有一項功能能徹底改變這種狀況，那就是語言伺服器協定（LSP）。它預設未啟用，且官方文件中並未明顯說明。啟用方式需透過 GitHub 問題中發現的旗標設定，而非官方文件。但一旦啟用，同樣的查詢（「processPayment 定義在哪裡？」）能在 50 毫秒內回傳精確的檔案與行號，不是 30 秒，而是 50 毫秒，且準確率達 100%。
這不只是漸進式改進，而是 Claude Code 導航程式碼方式的質變。
Claude Code 預設使用文字搜尋工具：Grep、Glob 和 Read，就像有個熟練的開發者在終端機用 grep 和 find 搜尋一樣。這是聰明的模式匹配，但本質上仍是文字比對。
核心問題是：grep 將程式碼當作文字，但程式碼不是文字，它有結構、意義與關聯。當你問「getUserById 定義在哪裡？」時，你想要的是那個函式定義，而不是 50 個呼叫它的地方或 12 個提到它的註解。grep 無法分辨這些，LSP 可以。
2016 年以前，每個程式碼編輯器都必須從零開始打造自己的語言支援。VS Code 需要 Python 外掛，Vim 需要另一個 Python 外掛，Emacs、Sublime、Atom 也各自重複相同工作。20 個編輯器乘以 50 種語言，意味著有上千個獨立且多半不完整的實作。
2016 年，微軟有了突破性的想法：將語言智慧從編輯器中分離出來，創造一個協定，讓任何編輯器都能與任何語言伺服器溝通。編輯器以 JSON-RPC 問「這個符號在哪裡定義？」語言伺服器（一個獨立進程，深度理解某種語言）回覆。
這就是 LSP。它將千百個實作問題縮減為約七十個實作。這也是為什麼你的 VS Code Python 體驗和 Neovim Python 體驗一樣好——因為它們都在與 Pyright 溝通。
沒人談論的是：AI 程式碼助理面臨的問題和編輯器在 LSP 出現前一樣。沒有 LSP，Claude Code 只能用文字搜尋工具（Grep、Glob、Read）。這雖然可用，但每次查詢耗時數秒，且一個任務通常需要數十次查詢，時間累積很快。
LSP 給 Claude Code 兩大類超能力：自動發生的事情與它能主動請求的事情。
這是最有價值的部分，但多數人甚至沒察覺。每次檔案編輯後，語言伺服器會推送診斷資訊：型別錯誤、缺少匯入、未定義變數。Claude Code 立即看到這些，並在同一回合修正，甚至在你看到錯誤前就完成。
實務上這意味著什麼？你請 Claude 在 createUser() 新增 email 參數，Claude 編輯函式簽名。語言伺服器立刻回報三個呼叫點因參數錯誤產生的錯誤。Claude 看到錯誤，找到三個呼叫點並修正。你第一次就拿到零錯誤的結果。
沒有 LSP，Claude 會編輯函式，交給你，你嘗試編譯，看到三個錯誤，再貼回 Claude，反覆修正。有了 LSP，整個迴圈縮短為一步完成。
除了自動診斷，Claude Code 還能明確向語言伺服器提問：
你不需要明確使用這些操作，只要自然地問 Claude Code：「authenticate 定義在哪裡？」「找出 UserService 的所有用法」「response 是什麼型別？」它會自動導向正確的 LSP 操作。
完整設定約需兩分鐘，只需做一次。
這是讓人卡關的地方，你必須在 Claude Code 設定中加入一個旗標：
將以下內容加入 ~/.claude/settings.json ：
ENABLE_LSP_TOOL 於 2026 年 2 月尚未正式文件化，是透過 GitHub Issue #15619 社群發現的解決方案，未來版本可能會改變或不再需要。我也建議在 shell 設定檔（macOS 的 ~/.zshrc，Linux 的 ~/.bashrc）加入 export ENABLE_LSP_TOOL=1 作為備援。
安裝你使用語言的對應二進位語言伺服器，這些就是你 IDE 使用的語言伺服器，LSP 是通用的。
首先更新市集目錄：
然後安裝你的語言外掛：
外掛可以安裝但未啟用，未啟用的外掛啟動時不會註冊其 LSP 伺服器。若 claude plugin list 顯示狀態為 disabled，請執行 claude plugin enable <name> 並重啟 Claude Code。
為保險起見，我也會在 ~/.claude/settings.json 明確將它們設為 true ：
這個單一問題——外掛已安裝但未啟用——是大多數「LSP 無法運作」問題的主因。
LSP 伺服器會在啟動時初始化。安裝外掛後需完整重啟，然後透過問 Claude「[某變數] 是什麼型別？」來驗證，若使用 LSP hover 操作而非讀取檔案，即表示設定成功。
我在除錯日誌中發現有趣的事：當 Claude Code 啟動時，所有啟用的 LSP 伺服器會同時啟動，不會等你開啟檔案。
從我實際的除錯日誌（啟用四個語言伺服器）來看，有兩點特別顯著。第一，Java 伺服器因 JVM 預熱約需 8 秒，這是正常現象非錯誤。第二，伺服器會立即開始索引整個專案，掃描所有該語言類型的檔案，建立符號表並解析依賴。當你第一次提問時，索引已經熱身完成。
這表示 goToDefinition、findReferences 和 hover 功能能對專案中任何符號生效，不僅限於你已開啟的檔案，語言伺服器已經看過全部內容。
你不需要學習新指令，只要像平常一樣與 Claude Code 對話即可。
真正的威力在重構階段展現。當你重新命名方法、新增參數或更改回傳型別時，LSP 確保 Claude 找到所有引用並正確更新，而非「grep 找到 47 個但實際有 52 個用法」的情況。
你也可以按 Ctrl+O 查看 LSP 伺服器推送的診斷資訊，實時看到語言伺服器的狀態。
我已經幫你測試過大部分流程，讓你省去麻煩。
即使 LSP 完全設定好，Claude Code 有時仍會預設使用熟悉的工具（Grep、Read、Glob）而非 LSP。這是設定後最常見的抱怨。解決方法是加入明確指示，告訴 Claude 優先使用 LSP 進行程式碼導航。
沒有這些指示，Claude 會把 LSP 當成工具箱中的另一個工具，使用時機不固定。有了指示，它會優先使用 LSP，只有當 LSP 無法協助時才退回文字搜尋。
每次你使用 Claude Code 卻未啟用 LSP，就是每次「尋找定義」花 30-60 秒而非 50 毫秒的時候。每次重構都漏掉語言伺服器能即時捕捉的呼叫點。每次錯誤本可被 LSP 揪出並自動修正，卻流入你的審查流程。
設定只需兩分鐘，功能旗標只是一行設定。效能差異不是微小改進，而是文字搜尋與語意程式碼智慧的巨大差距。這差距曾讓 IDE 超越記事本，現在讓你的 AI 助手更強大。
如果你已在使用 Claude Code，請啟用 LSP，你會在第一次查詢時立刻感受到差異。