Claude Code LSP使用评估

上周，我看着 Claude Code 阅读了 47 个文件，寻找一个工具函数的定义位置。它最终找到了定义——在耗尽上下文和几分钟时间之后。

同一天下午，我注意到 Claude Code 更新日志中的 "LSP tool"。语言服务器协议支持。与在 VS Code 中支持转到定义的技术相同，现在可用于 Claude Code。

我在一个 200 文件的 TypeScript/Python 代码库上设置了它。接下来是两个小时的故障排除，一个关于 Claude Code 如何实际导航代码的启示，以及真正的生产力转变——尽管不是我预期的。

这是诚实的评估。

1、为什么 LSP 对 AI 编码代理很重要

你每天都在使用 LSP，却不知道。当你在 VS Code 中悬停在函数上并看到其类型签名时——那是 LSP。

当你右键点击 "转到定义" 并跳转到确切的行时——那是 LSP。当红色波浪线在运行任何东西之前出现在损坏的代码下时——那是 LSP。

微软创建了语言服务器协议，以便代码智能可以构建一次并在任何地方工作。你的 TypeScript 语言服务器在 VS Code、Cursor、Neovim 和现在 Claude Code 中以相同方式工作。

有趣的是： 在 LSP 支持之前，Claude Code 正在进行复杂的文本搜索。当它需要找到函数定义的位置时，它基本上在你的文件上运行花哨的 grep。这工作得令人惊讶地好——LLM 理解代码模式，因为它们已经看到了数十亿行代码。

但它从根本上受到限制。你要求 AI 从原始文本中重建语义理解，而你的 IDE 已经内置了这种理解。

有了 LSP，Claude Code 可以访问与你的编辑器相同的代码智能：

goToDefinition — 跳转到定义的位置
findReferences — 查找代码库中的每个使用
hover — 获取类型信息和文档
documentSymbol — 列出文件中的所有符号
getDiagnostics — 在编辑后查看错误和警告

承诺： 更快的导航、更少的浪费令牌阅读无关文件，以及更准确的重构。

2、设置变得复杂的地方

我的栈： 一个 Next.js 前端（TypeScript）、FastAPI 后端（Python），总共大约 200 个文件。不庞大，但足以感受到 Claude Code 在重构会话中逐个阅读文件的痛苦。

官方设置看起来很简单：

export ENABLE_LSP_TOOLS=1

将其添加到你的 shell 配置文件中，重启 Claude Code，然后安装插件。简单。

除了它不是。

2.1 第一堵墙

在从官方市场安装 TypeScript 插件后，我要求 Claude Code 查找函数的引用。响应：

No LSP server available for file type: .ts

插件已安装。二进制文件在我的系统上。环境变量已设置。但 Claude Code 看不到语言服务器。

我在这个问题上花了 45 分钟，然后找到了 GitHub 问题。原来有一个竞态条件：LSP 管理器在插件完成加载之前初始化。在版本 2.0.74 中，管理器在启动时以零服务器完成，然后插件在 50 毫秒后加载——太晚了。

这在 GitHub 问题 #14803、#13952 和 #15413 中有记录。截至 2026 年 1 月初，Anthropic 已经修复了一些问题，但体验因平台而异。

2.2 有效的变通方法

社区市场比官方市场有更可靠的插件。这是真正让我运行起来的东西：

# 添加社区市场
/plugin marketplace add boostvolt/claude-code-lsps

# 安装 TypeScript (vtsls，而不是 typescript-lsp)
/plugin install vtsls@claude-code-lsps

# 安装 Python
/plugin install pyright@claude-code-lsps

官方的 typescript-lsp 插件有问题。社区的 vtsls 插件立即工作。

2.3 PATH 的陷阱

即使有正确的插件，你也需要语言服务器二进制文件已安装并在你的 PATH 中：

# TypeScript
npm install -g @vtsls/language-server typescript

# Python
pip install pyright

# 验证它们是否可访问
which vtsls
which pyright

如果 Claude Code 在 /plugin 错误选项卡中说 "Executable not found in $PATH"，这就是你的问题。

2.4 验证

你怎么知道它实际上在工作？没有状态指示器。没有视觉反馈表明服务器正在运行。

测试：明确要求 Claude Code 使用 LSP。

Find all references to the processRequest function using LSP

如果 Claude Code 使用 find_references 工具而不是 grep，你就好了。如果它仍然逐个阅读文件，有些东西坏了。

总设置时间：大约两个小时，包括故障排除。文档稀少，功能仍在成熟。

3、我的工作流程发生了什么变化

一旦 LSP 运行，差异立即显现。

3.1 LSP 之前

重构一个在代码库中使用的函数意味着观看 Claude Code：

阅读当前文件
Grep 函数名
打开每个匹配的文件
阅读寻找实际使用（不仅仅是字符串匹配）
有时错过上下文相关的引用

对于在 12 个文件中使用的函数，这可能意味着 Claude Code 阅读 20+ 个文件，燃烧上下文令牌，并偶尔错过边缘情况。

3.2 LSP 之后

相同重构：

Claude Code 调用 findReferences
在不到一秒的时间内获取确切的文件路径和行号
只编辑相关位置

Token节省是显著的。准确性改进更显著。

3.3 一个真实例子

我重命名了一个在代码库的 12 个文件中导入的工具函数 formatUserData。LSP 之前，Claude Code 找到了并更新了其中 9 个。测试文件中的三个导入被遗漏——后来测试失败时被发现。

LSP 之后： Claude Code 立即找到了所有 12 个引用。一个 findReferences 调用返回了每个位置。重构在第一次传递中完成。

3.4 数字

我在一周内计时了特定操作：

操作	LSP前	LSP后
查找函数用法（12 个文件）	~45 秒	<1 秒
跳转到不熟悉代码中的定义	15–30 秒	<1 秒
理解函数签名	读取文件 + 推断	即时悬停

45 秒到 50 毫秒的改进与其他报告的匹配——导航任务大约快 900 倍。

但这里是细微差别： 我花了两个小时设置。净生产力收益直到大约第三天才实现，当时我使用了 LSP 足够次数来收回设置投资。

对于小项目或快速脚本，那个数学不成立。对于较大代码库的持续开发，它值得。

4、LSP仍然不足的地方

每个 LSP 教程都强调胜利。这里是他们没有提到的。

4.1 诊断差距

TypeScript LSP 插件不像完整的 tsc 运行那样显示所有错误。类型错误有时出现，有时不。我仍然单独运行 TypeScript 编译器来捕获一切。

"每次编辑后的实时诊断" 的承诺部分正确。在我的经验中，也许 70% 的类型错误通过 LSP 显示。其他 30% 需要明确编译。

4.2 文件:行:列问题

Elixir 的创建者 José Valim 在 LSP 支持启动时在 X 上指出了这一点：

"LSP API 对代理使用很尴尬，因为它们需要传递文件:行:列，你不能简单地问'告诉我 Foo#bar 在哪里定义。"

他是对的。LSP 是为人类点击第 47 行第 12 列而设计的。代理想要语义查询——"这个函数在哪里？"——不是基于坐标的 API。

Claude Code 适应。它找出位置。但偶尔它仍然回退到 grep，尤其是当查询不明确或文件在当前会话中尚未打开时。

4.3 多语言摩擦

我的项目有 TypeScript 前端和 Python 后端。这意味着两个语言服务器同时运行。

这大多有效，但有摩擦：

工作区符号搜索不跨越两种语言
在 TypeScript 和 Python 文件之间切换上下文有时会混淆服务器状态
没有跨语言依赖的统一视图

如果你在具有多种语言的 monorepo 中工作，期望一些粗糙的边缘。

4.4 重构限制

这里是让我惊讶的部分： LSP 给你读取操作。转到定义。查找引用。获取类型信息。

它不给你写入操作。没有"跨代码库重命名符号"自动更新每个引用。

Claude Code 仍然必须读取引用，对每个引用进行推理，并逐个文件进行编辑。LSP 使查找引用瞬间，但重构本身仍然是 LLM 驱动的编辑。

JetBrains 风格的自动化重构——你重命名一次，每个引用原子更新——还没有在这里。LSP 关闭了一半差距，不是全部。

5、当我跳过 LSP 时

一些任务不受益：

快速字符串搜索：Grep 对于"查找此文本任何地方"更快
小脚本：设置开销不值得一次性代码
跨语言跟踪：当依赖从 TypeScript 跨越到 Python 时，LSP 不帮助

对于这些，我让 Claude Code 使用其默认工具。

6、实际有效的设置

在故障排除之后，这里是截至 2026 年 1 月的经过验证的设置：

TypeScript (Next.js, Node.js, React)

# 1. 安装语言服务器
npm install -g @vtsls/language-server typescript

# 2. 添加社区市场
/plugin marketplace add boostvolt/claude-code-lsps

# 3. 安装插件
/plugin install vtsls@claude-code-lsps

# 4. 重启 Claude Code
exit
claude

Python (FastAPI, Django, general Python)

# 1. 安装 Pyright
pip install pyright

# 2. 安装插件（市场应该已经添加）
/plugin install pyright@claude-code-lsps

Go, Rust 和其他

同一个市场有 Go (gopls)、Rust (rust-analyzer)、Java、C/C++、PHP、Ruby 等插件。同一个模式：安装语言服务器二进制文件，然后插件。

验证

Find all references to [your function name] using LSP

如果你看到 Claude Code 使用 find_references 工具，你就设置好了。如果它开始阅读文件，检查 /plugin 是否有错误。

如果它不工作

检查 /plugin → 错误选项卡的"Executable not found"
验证二进制文件：which vtsls，which pyright
重启 Claude Code (服务器在启动时加载) - 尝试社区插件而不是官方插件

7、我仍在弄清楚的事情

几周后，一些问题仍然开放：

一致性：Claude Code 并不总是使用 LSP，即使它可用。有时它仍然 grep。我还没有找到可靠的方法让它在每个导航任务中优先使用 LSP。向提示添加"使用 LSP"有帮助但不是万无一失。

子代理：当我使用 Task 工具生成子代理进行并行工作时，我不确定它们是否共享 LSP 状态还是每个都有自己的服务器实例。文档没有澄清这一点。

更大的代码库：我的 200 文件项目工作良好。我很好奇这如何扩展到 500+ 文件或具有数千文件的 monorepos。

官方 vs 社区插件：社区市场目前更可靠。但长期来看，我更喜欢官方支持。Anthropic 正在积极修复问题——值得检查更新日志以获取更新。

我希望看到添加的东西：

重命名符号操作 (不仅仅是查找引用)
当 LSP 静默失败时更好的错误消息
统一的多种语言工作区符号
视觉指示器表明 LSP 服务器正在运行

8、诚实的评估

Claude Code 中的 LSP 支持是一个重大进步，不是革命。

设置摩擦是真实的。错误是有记录的。文档是最小的。这是一个快速发货的功能，仍在成熟。

但一旦它工作，生产力收益是真实的。查找函数使用在不到一秒而不是观看 Claude Code 阅读数十个文件——那会复合。在一周的重构工作中，我估计它节省了 2–3 小时的等待和上下文窗口开销。

我的看法：

如果你在 100+ 文件的代码库上工作并进行定期重构，设置它。两个小时的投资在一周内收回。
如果你在编写快速脚本或小项目，跳过它。开销不值得。
如果你遇到 "No LSP server available" 错误，在放弃之前尝试社区市场。

这是基础设施，不是魔法。Claude Code 仍然做推理。LSP 只是给了它更好的眼睛来看你的代码库。

原文链接：I Set Up Claude Code LSP for a 200-File TypeScript Codebase — Here's What Actually Happened

汇智网翻译整理，转载请标明出处