AI AI 工具解析

Claude Code 加上 LSP，改變的不是會不會寫，而是你還要不要在大型專案裡瞎找

很多人第一次聽到「Claude Code 加上 LSP」時，直覺都會把它理解成：喔，AI coding tool 又多了一個進階配件，像是把編輯器的自動補完接進來。這樣講不算錯，但其實也剛好錯過重點。

真正重要的地方不是「它多會了一個功能」，而是 Claude 在大型專案裡找路的方式變了。

如果專案很小、檔案不多、命名乾淨、改動範圍很窄，其實純靠 grep、ripgrep、全文搜尋，再加一點模型本身的推理能力，就已經能解掉很多事。但一旦程式進入真實開發現場：monorepo、跨套件共用型別、interface 與實作分散、動態匯入、alias、re-export、generated code、測試與正式碼交錯，事情就會開始變質。這時候，Claude Code 不缺的是「再看更多字」，它缺的是看懂哪個符號真的指向哪裡、哪一次改名會波及誰、這個錯到底是語法問題還是型別契約真的破了。

LSP 讓它多出來的，正是這一層語意導覽能力。

這篇文章會先講清楚：為什麼這件事在大型專案會變重要、哪些工作流會明顯受益、哪些情境其實不用急著裝；再往下談 Claude Code + LSP 到底改變了什麼、怎麼安裝與驗證、常見坑在哪裡，以及幾個真實開發場景裡它到底有沒有幫上忙。

English TL;DR:

  • Claude Code with LSP is not just “better autocomplete”; it changes how the agent navigates a large codebase.
  • The key improvement is semantic navigation: definitions, references, implementations, symbols, and automatic diagnostics after edits.
  • This matters most in large, typed, multi-module projects where grep hits a wall.
  • It is excellent for debugging, refactoring, and onboarding in real codebases, but much less useful in tiny scripts, highly dynamic code, or poorly configured repos.

為什麼這件事值得現在看

Anthropic 在 Claude Code 文件裡，已經把「code intelligence」列成獨立能力。官方對這件事的描述很直接：裝上 code intelligence plugin 之後，Claude 會得到兩種能力，一種是編輯後自動看到 type errors / warnings / missing imports 等診斷，另一種是更精準的 code navigation，例如 go to definition、find references、hover type info、list symbols、find implementations、call hierarchy。這些都不是終端機 agent 本來天然擁有的能力，而是透過 LSP 補進來的。

這件事之所以重要，不是因為 LSP 很新，剛好相反：LSP 一點都不新。它早就是 VS Code、Neovim、JetBrains 生態裡非常成熟的一層。真正新的地方是，Claude Code 這種 agentic coding 工具，開始能把編輯器原本才有的語意能力拿來當推理素材。

這會讓 AI coding 從「讀很多文字、猜專案結構」往前走一步，變成「不只看文字，還能沿著語言伺服器建立的符號關係移動」。如果說過去很多 AI coding 成功案例還偏向單檔修修補補、簡單功能生成、用 shell 指令慢慢驗證，那 Claude Code + LSP 比較像是開始碰到真正的工程工作：跨檔案修正、型別導向重構、追引用、查呼叫鏈、理解大型專案裡的局部影響範圍。

為什麼 grep / 文字搜尋在大型專案會遇到瓶頸

這一段反而最值得先講。因為很多人其實不是不會用 grep，而是高估了 grep 在大型專案裡的上限。

grep 很強，rg 更強，這點沒什麼好否認。它快、直覺、可組合、幾乎是每個工程師的肌肉記憶。但它的核心能力本質上還是：找字串。

問題在於，大型專案裡最麻煩的事，往往不是「這串字在哪裡出現過」，而是下面這幾種：

  • 這個 User 指的是 domain entity、DTO、ORM model，還是前端 form state？
  • 這個函式是 interface 宣告、抽象基底，還是實際被 call 的那一個實作？
  • 這個符號被 re-export 了三層之後，真正來源到底在哪？
  • 這個 rename 看起來只改到兩個檔案，但還有哪些動態引用、型別約束、測試 fixture 會一起爆？
  • 搜出來 200 個結果裡，哪些是註解、哪些是 dead code、哪些才是有語意關聯的使用點？

換句話說，grep 的瓶頸通常不是速度，而是它對語意一無所知。

在小專案裡，這個缺點可以被上下文彌補；但在大型專案裡，這會演變成三種實際成本。

第一種成本是 誤命中太多。同名符號、過時代碼、測試資料、文件片段、樣板字串會一起跑出來。Claude 或人類都得自己再二次判讀。

第二種成本是 漏掉真正關聯。例如符號不是直接寫死字串，而是經過 alias、import path、framework convention、generated binding、type inference 才接起來。grep 看不到這層關係。

第三種成本是 不知道影響範圍。你可以搜到一個函式名，但不代表你知道誰在實作它、誰在覆寫它、誰在不同模組裡引用它。對真實 refactor 來說，這比單純找得到字更重要。

所以比較準確的說法不是「grep 沒用了」，而是：當任務從找文字升級成找關係，grep 就會開始吃力。

LSP 真正改變的是什麼

如果只把 LSP 理解成「可以跳定義、找引用」，其實還是講淺了。那些只是表面功能名詞。真正的改變有三層。

第一層：從字串搜尋，變成符號導航

Claude Code 本來就能讀檔、搜尋、跑指令；但裝上 LSP 之後，它多了一條更可靠的路徑去回答這些問題：

  • 這個名字到底綁定到哪個定義？
  • 這個介面有哪些實作者？
  • 這個方法被哪些地方實際呼叫？
  • 這個變數目前推導出的型別是什麼？

這讓它不必每次都靠「猜」哪個檔案最相關，而是可以沿著語言伺服器產生的符號圖往前走。對大型專案而言，這個差別很像從看平面地圖變成開導航。

第二層：從改完再跑，變成改完立刻知道哪裡壞

Anthropic 官方文件提到，裝好 code intelligence plugin 後，Claude 在每次 edit 之後都能自動收到 diagnostics。這件事很關鍵，因為它把回饋週期縮短了。

沒有 LSP 的情況下，Claude 很可能要靠額外跑 npm run build、tsc、pytest、pyright、phpstan 之類的命令，才知道剛剛那個改動是不是又引入新的問題。這當然也能做，但成本比較大，也更慢，尤其是在大型 repo。

有 LSP 之後，很多低階但很常見的錯誤會在編輯後立刻冒出來：缺 import、型別不相容、參數簽名錯、找不到 symbol、某個屬性不存在。這代表 Claude 的 agent loop 不用等到晚一點才發現自己挖坑，而是能在同一輪修掉一部分問題。

第三層：從「能寫」變成「比較能安全地改」

這是最容易被低估的一點。現在多數 AI coding 展示，都把焦點放在生成能力：寫功能、補測試、改 bug。但在成熟專案裡，很多工作的價值其實不是新寫一段，而是改既有系統而不把別的地方弄壞。

LSP 不會保證安全，但它會讓 Claude 在這件事上比較像一個有 IDE 輔助的工程師，而不是只拿著全文搜尋和 shell 的實習生。它知道哪些變更和哪個符號真正有關，知道哪些檔案是引用點，知道改完立刻冒出了哪些型別診斷。對大型專案來說，這種「降低誤改機率」的價值，往往比多寫十行樣板碼還大。

哪些工作流會很有感，哪些其實先不用急

不是每個團隊都會對 Claude Code + LSP 有同樣體感。這件事很吃專案規模、語言特性、型別密度，也很吃你平常到底在做哪種工作。

很有感的情境

1. 大型 TypeScript / Python 專案的除錯與追呼叫鏈

當 bug 不在單一檔案，而是從 API schema、service layer、UI props、資料轉換一路串過去時，LSP 的 definition / references / hover type info 幫助很大。Claude 不必靠關鍵字一路試猜。

2. 安全重構

例如 rename 一個 public interface、拆 module、替換舊 API、把鬆散物件改成明確型別。這些工作本來就不是「寫」而是「整理依賴關係」。LSP 讓 Claude 比較看得見影響面。

3. 新人 onboarding 或接手陌生 repo

當任務是「先搞懂這坨東西怎麼接的」時，語意導航的價值遠高於炫技生成。Claude 能更快指到真正定義與實作，而不是給一堆含糊的猜測路徑。

4. 多模組 monorepo

有 alias、workspace、shared package、cross-package imports 的專案，全文搜尋通常很快就會失焦。LSP 至少能在支援度夠好的語言裡，把解析結果拉回比較可靠的軌道。

其實先不用急的情境

1. 很小的腳本型專案

如果 repo 只有幾十個檔案，或主要就是改一兩支 script，LSP 能帶來的提升有限，因為 grep 根本還沒碰到瓶頸。

2. 動態性很高、型別資訊很薄的程式

例如大量魔術方法、動態屬性注入、runtime metaprogramming、弱型別使用習慣非常重。LSP 不是失效，但效果會打折，Claude 看到的語意圖也會比較破碎。

3. 專案本身就沒整理好

tsconfig 壞掉、pyright 設定不對、venv 沒對上、node_modules 缺半套、generated types 沒產、workspace root 開錯。這種狀態下，LSP 不會變魔法，它只會把原本的混亂忠實反映給你看。

4. 完全以執行時行為為主的問題

像是 race condition、效能瓶頸、外部 API timeout、基礎設施配置錯誤。LSP 幫助有限，因為它主要解的是靜態結構與語意導航，不是所有 runtime 問題。

怎麼安裝與驗證

這裡先講最實用的版本。Anthropic 官方目前是透過 Claude Code 的 code intelligence plugins 來接不同語言的 LSP。文件列出的官方對應關係裡，TypeScript 用 typescript-lsp + typescript-language-server，Python 用 pyright-lsp + pyright-langserver，PHP 用 php-lsp + intelephense。

重點有兩個：插件本身 和 語言伺服器 binary 本身，兩個都要有。只裝 plugin 不裝 binary，Claude 會在 /plugin 的 Errors 裡看到 Executable not found in $PATH。

TypeScript / JavaScript

先裝語言伺服器：

npm install -g typescript-language-server typescript

這是 typescript-language-server README 的官方安裝方式。它本質上是把 TypeScript 的 tsserver 能力包成 LSP 介面，讓非 VS Code 的 client 也能用同樣的語意能力。

接著在 Claude Code 裡安裝對應 plugin：

/plugin install typescript-lsp@claude-plugins-official
/reload-plugins

如果是 monorepo，還要確認 repo 裡的 tsconfig.json、jsconfig.json、path alias 與 workspace 設定本來就是健康的，不然 LSP 只會把設定錯誤放大給你看。

驗證方式：

  • 開 Claude 進專案後，請它找某個明確符號的定義與引用
  • 改一個已知會觸發型別錯誤的欄位名稱，確認是否立即收到 diagnostics
  • 看 /plugin 是否沒有 executable 錯誤

Python

Anthropic 官方列的是 pyright-langserver。如果只是要跟官方文件完全對齊，可以直接裝 pyright：

npm install -g pyright

Claude Code plugin：

/plugin install pyright-lsp@claude-plugins-official
/reload-plugins

如果平常就用 Pyright / BasedPyright 做型別檢查，這條路會最自然。Pyright 官方文件也提供 CLI 與專案設定方式，像是 pyright -p .、--pythonpath、--venvpath 等，這些在排查 LSP 異常時很重要，因為很多問題根本不是 Claude 壞掉，而是 Python 環境解析本來就沒對上。

驗證方式：

  • 在有型別標註的 Python 檔裡，請 Claude 找某個 class 或 function 的 references
  • 故意把某個參數型別改錯，觀察 diagnostics 是否回來
  • 手動跑一次 pyright -p .，確認 CLI 與 Claude 看到的世界一致

PHP

Anthropic 官方目前列的 PHP binary 是 intelephense。它是跨 editor 的 PHP LSP server，官方文件也明講：要有 LSP client 搭配、並且最好是打開整個專案資料夾讓它索引，而不是只開單一檔案。

安裝語言伺服器：

npm install -g intelephense

Claude Code plugin：

/plugin install php-lsp@claude-plugins-official
/reload-plugins

驗證方式：

  • 讓 Claude 跳到某個 Laravel service / controller / model 的定義
  • 請它找某個 interface 的實作者或 references
  • 如果專案非常大，注意 Intelephense 的索引是否完整，以及是否排除了 vendor 或不必要資料夾

三個真實工作場景，哪裡真的有差

場景一：接手陌生 monorepo，先找登入流程到底怎麼走

這是最典型的一種。你接到一個 bug：使用者在某些 tenant 下登入後會拿到錯誤權限。專案是前端 React + 後端 Node + 共用 schema package，登入流程從 UI form、API client、BFF、auth service、RBAC mapping 一路串下去。

如果純用 grep，通常做法會是從 login、auth、tenant、permission 這些字開始往下挖。但真實情況往往是：關鍵邏輯可能不叫 login，權限映射也不一定叫 permission，很多關係是透過型別、interface、schema re-export 串起來。

這時候 Claude Code + LSP 的差別在於，它可以從某個回傳型別、某個方法定義、某個 enum 直接沿著 references / definitions 往前後追，不用每一步都重新猜字串。它比較像在沿著結構走，而不是在文字堆裡淘金。

場景二：重構共用型別，避免改一個欄位炸半個前端

另一個非常有感的場景，是把舊的 API response shape 改成新的契約。例如把 user_name 改成 displayName，同時把一些 nullable 欄位收緊。

這種工作最怕的不是改不到，而是以為改完了，其實還有三個地方靠舊欄位在跑。grep 當然能搜 user_name，但它無法清楚分辨哪些是註解、哪些是舊 fixture、哪些是真正型別依賴點，也不一定能看出某些使用其實經過轉型或中介函式包裝。

有 LSP 之後，Claude 至少可以更可靠地追到符號引用與編輯後的型別診斷。這不保證百分之百沒漏，但對「安全改動」這件事已經差很多。尤其是 TypeScript 專案，diagnostics 會直接把破掉的點浮上來，不用等到 build 全跑完才發現。

場景三：Python 後端查一個看起來像資料問題，其實是型別契約漂移

Python 專案很常見一種 bug：表面看起來是資料內容錯，實際上是某個函式回傳型別默默漂掉了。比如 repository layer 本來回 User | None，某次重構之後變成 list 或 dict-like 結構，但 service layer 與 API serialization 還照舊使用。

如果沒有 LSP，Claude 也不是不能查，但它通常得靠讀更多檔案與手動推理。裝上 Pyright 類的 language server 之後，它比較能直接看見 hover type info、references 與 diagnostics，知道這不是資料庫髒資料，而是靜態契約從中間某層開始失真。

這種場景對 Python 特別重要，因為 Python 不是不能做靜態分析，而是很多團隊平常沒有把那層能力用到位。Claude 接上 LSP 之後，至少會開始吃到這塊紅利。

場景四：PHP 舊系統不是不能用 AI，只是要先接受邊界

PHP 這邊的體感通常比較兩極。假如專案有比較清楚的型別、PHPDoc、框架慣例穩定，Intelephense 能提供的導航與診斷還是很有價值，尤其是找 service container 綁定、interface 實作、跨 controller / service / model 的引用。

但如果是高度動態、歷史包袱很重的舊專案，那 Claude Code + LSP 的表現就很看運氣，因為語言伺服器能看到的世界本來就不完整。這種情況下它仍然比裸 grep 好一些，但不會神到哪裡去。比較穩健的期待應該是：它幫你少走彎路，不是直接替你理解所有魔法。

常見坑與排查

這一段建議一定要先有心理準備。因為很多人會把 LSP 想成「裝了就變聰明」，實際上比較像「裝了之後，你終於能比較早看到專案本來就有多亂」。

1. Plugin 裝了，但 binary 不在 PATH

這是最基本也最常見的。Claude Code 官方文件已經直接提醒，如果 /plugin Errors 裡看到 Executable not found in $PATH，就是語言伺服器 binary 沒被找到。檢查方式很簡單：

which typescript-language-server
which pyright-langserver
which intelephense

2. 專案根目錄開錯，LSP 解析到半套世界

尤其是 monorepo。你在 package 子目錄開 Claude，LSP 卻需要 workspace root 才能正確吃到 tsconfig / pyproject / composer 設定，結果 references 和 diagnostics 就會怪怪的。這不是 Claude 的理解問題，而是 language server 從一開始就站錯地方。

3. TypeScript 可以跳定義，但 diagnostics 一堆假警報

通常不是 LSP 壞，是 tsconfig、path alias、project references、generated types 沒對齊。先手動跑一次：

tsc --noEmit

如果本來就錯一片，Claude 也只會看到同一片火海。

4. Python 最大的坑通常是環境

pyright / pyright-langserver 能不能準確解析 import，往往取決於 venv、python path、pyproject / pyrightconfig 是否健康。先自己跑：

pyright -p .

如果 CLI 看不到正確模組，Claude 通常也不會 magically 看懂。

5. PHP 的問題常在索引範圍與型別資訊不足

Intelephense 官方文件特別提到，最好是打開整個專案資料夾讓它索引；如果 workspace 太大，也要排除不必要目錄。另一個現實是，PHPDoc 與型別標註越差，LSP 的效果就越差。這不是偏見，是工具本身的資料來源限制。

6. 把 LSP 當成測試替代品

這是觀念坑。LSP 很適合幫 Claude 做靜態導航與早期診斷，但它不是 runtime correctness 的保證。你還是要跑測試、跑 build、驗證實際流程。比較務實的定位是：LSP 讓錯誤更早浮出來，不是把驗證流程整個刪掉。

比較務實的結論：它不是讓 Claude 更像神，而是更像一個有 IDE 的工程師

Claude Code + LSP 最容易被講歪的地方，就是把它包裝成某種神奇升級包，好像裝上去之後，AI 就突然從會寫程式變成懂你的整個系統。

比較準確的說法是：它把 Claude 從「主要靠文字搜尋與上下文猜測」往前推到「可以沿著語意資訊導航、能更早看到靜態診斷」。對大型專案來說，這個差別非常實際，因為真實開發最貴的通常不是打一段新 code，而是找到正確位置、理解真正關係、改完不要連帶炸掉別處。

所以如果今天問的是：「Claude Code 裝上 LSP 之後，到底改變了什麼？」比較務實的答案會是：它改變的不是生成能力的天花板，而是大型專案裡的找路成本、誤判成本與回饋速度。

這對大型 TypeScript / Python / PHP 專案、需要重構與追影響面的工作流，很有感；對小腳本、低型別密度、極度動態、或本來就沒整理好的 repo，體感會有限。

換句話說，Claude Code + LSP 真正值錢的地方，不是讓它更會寫，而是讓它比較不需要在大型專案裡瞎找。

來源

換個腦袋讀

想再讀深一點？

深入解讀
ChatGPT Google AI
© 2026 我獨自AI睏😪｜時事・技術・腦內噪音管理