Claude Code 缺失实时诊断？教你绕过 LSP 瓶颈，提速代码修正流程

最近在折腾 Claude Code 的时候，发现了一个挺让人头疼的问题。

Claude Code 支持配置 LSP，但目前缺乏自动诊断功能。

大家都知道，Claude Code 现在是可以通过配置来支持 LSP（Language Server Protocol）的。照理说，配好了 LSP，像跳转到定义、补全代码这些基本功能肯定要有。

但问题来了：它竟然不会像我们的 IDE 那样，进行实时的 LSP 错误诊断。

痛点：Claude Code 的 LSP 只是“半残”状态

我主要是在用 C# 开发，配置了 csharp-ls 之后，基本功能倒是没问题，想看个定义或者查个引用都能用。但对于最核心的“实时报错”功能，它就像是瞎了一样，完全没有反应。

这就导致我每次改完代码，根本不知道有没有语法错误或者类型不匹配，只能在心里打个问号。

这时候我不禁想到了隔壁的 OpenCode。这玩意儿虽然也是新出的，还有各种小毛病，但有一点做得确实好：每次编辑完文件，它会自动触发 LSP 诊断，并且把错误信息直接推送到你面前。这种所见即所得的反馈，才是开发该有的样子啊。

之前的“笨办法”：耗时且低效

在没找到好的解决办法之前，我想出了一个“笨招”。为了确保代码没问题，我让 AI 在工作流里自动跑这么一条命令：

dotnet format --severity info --verify-no-changes
``

这招虽然能解决问题，但代价太大了。

这不仅仅是一个格式化命令，它实际上是在全盘扫描你的代码风格和潜在问题。每次跑这一遍，**少说也要花掉四五分钟**。

这就很尴尬了：
1.  **效率极低**：本来改个代码风格可能只需要几秒钟，现在为了检查，得先等几分钟。
2.  **死循环体验**：AI 修完一个问题，我想确认修没修好，得再跑一遍命令，又是四五分钟。有时候为了改几个代码规范问题，前前后后折腾下来，**半个小时就没了**。
3.  **占用心智**：这种长时间的等待，很容易打断开发思路，比起 LSP 毫秒级的响应，简直是一个天上一个地下。

## 破局思路：如何找回开发速度？

既然目前 Claude Code 的 LSP 诊断功能暂时指望不上（或者是配置门槛极高），我们只能想办法优化现有的检查流程，或者寻找替代方案。

### 1. 将全量检查改为增量检查

如果你还在用 `dotnet format` 这种全量扫描工具，建议先看看有没有增量参数，或者只针对当前修改的文件进行检查。比如编写一个简单的脚本，只让 LSP 针对当前 Buffer（当前文件）进行诊断，而不是扫描整个项目。

### 2. 利用本地 IDE 与 AI 协作

虽然我们很想把所有工作都丢给 AI，但在当前技术阶段，最高效的模式可能是 **“本地 IDE 实时反馈 + Claude Code 批量重构”**。

*   在本地 VS Code 或 JetBrains 中，利用 LSP 的实时高亮和报错功能，快速定位低级错误。
*   把复杂的重构、逻辑优化、或者大段的代码生成工作交给 Claude Code。

不要强求 Claude Code 一个人干完所有脏活累活，术业有专攻，让它做它擅长的（比如理解意图和生成逻辑），让本地工具做它们擅长的（比如毫秒级的静态分析）。

### 3. 尝试自定义 Agent 工作流

对于必须使用命令行检查的情况，可以尝试优化 AI 的工作流。不要让它盲目地“跑完全部代码再检查”，而是让它在修改每一个关键节点后，只调用轻量级的 Linter（比如针对单文件的 linter），而不是重量级的项目级 Format 工具。

## 写在最后

Claude Code 和 LSP 的融合肯定还在进化中，现在的“不支持自动诊断”大概率只是暂时的。相比 OpenCode那种虽然诊断快但其他毛病变多的情况，Claude Code 的底子无疑更厚。

但在理想的功能到来之前，我们得学会“偷懒”。别拿四五分钟的刀工去切几秒钟的菜，合理搭配本地工具的实时反馈和 AI 的超强算力，才是当下玩转 AI 编程的正确姿势。

如果你也有类似的困扰，或者发现了在 Claude Code 里开启 LSP 诊断的隐藏配置，欢迎在评论区交流！