AI 写代码还在全仓库乱搜？下一步该给 Agent 装语义导航

GitHub 昨天发了一篇很适合普通开发者看的文章，讲 Copilot CLI 怎么接入 language servers，也就是 LSP。这件事听起来有点底层。但我觉得它其实戳中了 AI 编程里一个特别现实的问题：

很多 Agent 不是不聪明；是它看代码的方式太原始。

让 AI 改项目，它经常会先全局搜索关键词，rg 一遍，grep 一遍，翻 node_modules，读一堆看起来相关的文件，再从文本里猜函数关系。

这当然能用，但它本质上还是在「看文字」，不是在「理解代码结构」。

人类开发者为什么很多离不开 IDE？

不是因为 IDE 好看，是因为 IDE 给了我们语义导航。

跳转定义、查找引用、类型提示、重命名符号、看到一个函数到底从哪里来、一个接口到底被谁实现。这些能力让你不用靠猜。而现在 AI Agent 也开始需要这些东西。

GitHub 这篇文章的重点，就是让 Copilot CLI 通过 LSP 拿到更精准的代码信息，而不是靠纯文本搜索和启发式猜测。比如 Java、Python、TypeScript 这种项目，Agent 如果只翻文件，很容易漏掉泛型、重载、编译产物、跨包类型和间接引用。

这给我们一个很重要的提醒：

AI 编程下一阶段，不只是换更强模型。还要给 Agent 配更好的工作环境。

以前我们总爱问：「哪个模型写代码最强？」

这个问题当然重要。但以后更应该加一句：「它拿到的代码上下文是怎么来的？」

如果上下文只是全仓库搜索出来的一堆片段，再强的模型也可能把项目理解成散文。

如果上下文来自语言服务器、测试结果、类型系统、日志、数据库 schema、真实页面截图，它就更像是在一个完整工位里工作。

我现在会把 AI 编程环境分成三层。

第一层是文本层。

也就是最基础的读文件、搜索、看 diff。这层必须有，但只靠它不够。

第二层是语义层。

包括 LSP、类型检查、跳转定义、引用关系、接口实现、错误诊断。它解决的是「这个符号在代码系统里到底是什么意思」。

第三层是运行层。

包括测试、浏览器验收、数据库查询、日志、构建结果。它解决的是「改完以后真实世界有没有坏」。

很多 AI 编程翻车，不是模型不会写，而是只活在第一层。

它看到一个 UserService，就去搜 UserService。

但它不知道这个类实现了哪个接口，不知道哪些调用点只在运行时注入，不知道某个类型其实来自生成代码，不知道一个看似没用的字段被序列化框架依赖。

于是它改得很自信；也错得很隐蔽。

所以我现在会在复杂项目里这样要求 AI：

「在动手前，先说明你准备使用哪些代码理解工具。不要只做关键词搜索。请优先确认相关符号的定义、引用、类型关系、调用链和测试覆盖。如果当前环境没有 LSP / 类型检查 / 测试能力，请明确说明缺口，并降低修改范围。」

这段 prompt 的重点，是逼 AI 承认它的视野边界。

它不能只说「我看过代码了」。它要说清楚，是怎么看的。

是只搜了文本？还是确认了类型？有没有跑测试？有没有看调用链？有没有验页面？

这就是从「会让 AI 写代码」到「会给 AI 搭工位」的区别。

模型是员工，工具是办公桌。

你不能让一个要改大型代码库的 Agent 只拿一把文本搜索刀，就期待它像资深工程师一样稳。

GitHub 这波 Copilot CLI + LSP 的信号很明确：

AI 编程正在从聊天框，走向真正的开发环境。

以后差距不会只来自谁的模型更大。

还会来自谁的 Agent 能看见更多结构，调用更多工具，留下更多可验证痕迹。

附原文链接：https://github.blog/ai-and-ml/github-copilot/give-github-copilot-cli-real-code-intelligence-with-language-servers/