一、当下 AI 编程的痛点：编码能力之外的迷失问题
1.1 从“会写代码”到“能改对代码”的鸿沟
目前 AI 在代码生成任务上已经取得了显著进展，无论是算法实现、接口封装，还是单文件级别的功能补全，它都能够给出结构清晰、语法正确、甚至风格良好的代码片段。在理想化的 Demo 场景中，AI 编码似乎已经足够聪明。
然而，一旦进入真实的软件工程环境，尤其是一个拥有数十万行代码、复杂模块划分、多层抽象与历史演进痕迹的项目中，这种会写代码的能力，往往迅速失效。而问题不在于模型不会写代码，而在于它不知道该改哪一行代码。
这并不是一个语法或算法问题，而是一个工程级定位问题。
1.2 大型项目中的迷路：AI 的典型失败模式
在一个真实的工程项目中，完成一个看似简单的需求修改，通常至少涉及以下隐含步骤：
- 理解需求对应的抽象层级（接口层/应用层/领域层/仓储层）。
- 在多个候选模块中定位真正的责任归属点。
- 区分定义、实现与调用路径。
- 判断修改是否需要跨文件、跨模块联动。
而当前主流 AI 编码助手，在面对这类任务时，往往表现出高度一致的模式：
（1）文件级“猜测式跳转”：AI 通常会通过关键词匹配或语义相似度，在项目中搜索相关文件名或类名，然后猜测修改点。这在小项目中可能还管用，但在大型项目中很可能出现这些问题：
- 找到名字相似但职责不同的模块。
- 修改接口定义但没实现实现类。
- 直接在调用方打补丁，绕过核心逻辑。
（2）上下文碎片化导致的认知偏移：由于 AI 的上下文窗口有限，模型无法同时看到接口定义、实现类、调用点等，结果就是 AI 在修改的过程中不断丢失前提条件，生成的代码局部合理，但整体上不一致，甚至引入新的逻辑错误。
（3）看起来合理，但实际上没改到点：这是最危险的一类，AI 给出了语法正确、风格统一、逻辑自洽的修改，但这些修改并没有真正作用于需求对应的执行路径。
1.3 问题的本质：缺失工程级执行路径的建模
其问题的本质并非源于大模型能力的不足，而是源于当前 AI 编码系统缺乏对工程级执行路径的显示建模能力。
我们日常在修改代码时，并不是随机浏览文件，而是沿着一条隐式但稳定的路径工作，我们知道该从哪里找是因为我们的脑里维护了一张可执行的项目地图，这张地图并非仅仅是代码文件的目录结构，它还包含了代码之间复杂的依赖关系。
因此，当前 AI 编码的痛点就好比一个人看到了拼图的几块碎片，却没有清晰的全局视图，因此无法准确判断如何将它们组合起来。
二、Serena MCP：为 AI 引入不迷路的能力
2.1 Serena 是什么
Serena 是一款功能强大的开源 AI 编码代理工具包，它作为 MCP 服务器 运行，旨在通过语言服务器协议 （LSP） 提供的符号级理解能力，弥补传统基于文本搜索的 AI 编程工具在处理复杂代码库时的短板。
我们日常使用的 AI 编程工具通常通过类似 grep 这种文本搜索命令来读取整个文件，这种方法往往效率低下，且难以理解代码的上下文和层次结构。而有了 Serena 之后，AI 能够执行符号级别的精确操作，例如利用 find_symbol（查找符号）、find_referencing_symbols（查找引用）等工具，AI 可以精确查找并理解一个特定符号的定义和对某一符号的所有引用，从而构建起代码的全局视图。
2.2 Serena × LSP
前面提到，Serena 本质是依赖语言服务器协议（LSP）的能力来工作的，LSP（Language Server Protocol）可以理解为 IDE 与语言智能引擎之间的一套通用接口标准。
- 在 LSP 出现之前，每个 IDE 要想支持某门语言的补全、跳转、重命名、错误提示等能力，往往只能自己写一整套语言插件/引擎，并且由于 IDE 之间也有差异，同一门语言在不同 IDE 里也要重复开发多份。
- 在 LSP 出现之后，编辑器只负责界面与交互（打开文件、光标位置、按下快捷键），而把理解代码的重活交给独立进程里的语言服务器（Language Server）。这样一来，不同 IDE 就不需要为每种语言各写一套解析、索引和类型推导逻辑，只要实现一次 LSP 客户端，就能复用同一套语言服务器能力。这种解耦式协议设计的思想和 MCP 的设计思路非常类似。
Serena 和 LSP 的配合流程如下：用户向 AI 提出问题后，AI 会先理解需求并把任务拆分成清晰的步骤，当任务涉及到代码库分析、工程结构理解或需要精确的符号信息，AI 会调用 Serena MCP，并发送工具调用请求。随后，Serena MCP 会把这些请求转换成 LSP 能理解的标准指令（例如打开文件、定位到某一行、查询符号、查找引用等），并把必要的上下文一起传给 LSP 。LSP 负责提供与代码/工程相关的智能支持，比如语法解析、补全、跳转、诊断和查找引用等，并把结果返回给 Serena MCP。最后 Serena MCP 汇总这些返回信息再交给 AI，最后 AI 再根据这些信息生成最终答案或进行下一步指令。
2.3 Serena 核心工具与联动
Serena 核心的工具如下表所示：
| 工具名 | 用途 |
|---|---|
| activate_project | 按名称激活项目 |
| check_onboarding_performed | 检查当前项目是否完成初始化 |
| onboarding | 初始化当前项目 |
| initial_instructions | 提供 Serena 使用手册 |
| find_symbol | 根据给定的名称、路径模式检索所有符号/代码实体 |
| get_symbols_overview | 快速了解一个文件里有哪些类、函数等核心结构 |
| find_referencing_symbols | 找出某个符号的所有引用点 |
| search_for_pattern | 在项目里做模式搜索 |
| list_dir | 列举目录 |
| find_file | 查找文件 |
| read_file | 读文件 |
| create_text_file | 创建/覆盖文件 |
| insert_before_symbol | 在符号定义前插入 |
| insert_after_symbol | 在符号定义后插入 |
| rename_symbol | 符号重命名 |
| execute_shell_command | 执行 shell 命令 |
| write_memory | 写记忆 |
| read_memory | 读记忆 |
| list_memories | 列出记忆 |
| delete_memory | 删除记忆 |
| think_about_collected_information | 检查信息收集是否充分 |
| think_about_task_adherence | 检查是否跑偏 |
| think_about_whether_you_are_done | 检查任务是否真的完成 |
在完成一次需求时，Serena 各个工具的联动可以分为五大步骤：
- 进入项目与建立长期上下文：其目标是让 Serena 知道你在做哪个项目，并把项目知识沉淀为可复用的记忆。涉及 activate_project、check_onboarding_performed、onboarding、write_memory 等工具。
- 需求定位：其目标是快速找到该改哪里、影响哪些调用点，会进先行符号级导航，再最小化读取。涉及 find_symbol、get_symbols_overview、find_referencing_symbols、read_file 等工具。
- 实施修改：其目标是把改动限制在正确的定义边界内，减少误伤与冲突，会围绕符号边界做精确编辑，涉及 insert_before_symbol、insert_after_symbol、create_text_file 等工具。
- 验证与迭代：其目标是让需求真正完成，而不是代码写完就算，会用 Shell 工具跑通可交付闭环，涉及 execute_shell_command、think_about_collected_information、think_about_whether_you_are_done 等工具。
- 交付与沉淀：其目标是减少下次同类需求的成本，把这次需求变成下次的“加速器”，涉及 write_memory 等工具。
三、Serena 实践：一次简单的方法重命名效果对比
说明：有关代码的信息已脱敏。
3.1 环境搭建
Serena 的集成方式非常简单，这里以 Claude Code 为例：
# 进入项目目录，这里需要替换为你自己的目录名
cd ${project}
# 添加项目级 MCP
claude mcp add serena -- uvx --from git+https://github.com/oraios/serena serena start-mcp-server --context ide-assistant --project $(pwd)
# 提前为项目建立索引，索引的目的是提前建立符号文件
uvx --from git+https://github.com/oraios/serena serena project index --timeout 1000
在执行完后，项目中会多出一个 .serena 的文件夹，里面存放的就是 Serena 会使用到的符号、记忆等内容。
3.2 案例说明
本案例的目的是让 AI 将 xxx.A#func 这个方法的名字重命名为 func2，同时修改所有的调用点，在我所处的代码仓库中，共有 8 个调用的类。因此：
- 评判标准：AI 需要改对 10 个类文件（1 个接口、1 个实现类、8 个调用类）。
- 环境对比：AI 不携带 Serena MCP 运行 VS AI 携带 Serena MCP 运行，其他条件一致。
3.3 运行结果
| 维度 | 带 Serena | 无 Serena |
|---|---|---|
| 操作路径 | 直接调用 rename_symbol 工具 | 逐个文件查找并修改 |
| 操作结果 | 修改正确（共修改了 10 个类文件） | 修改错误（共修改了 13 个类文件，包括 3 个非相关类的同名方法） |
| Token 耗用 | 112.7K | 1.10M |
3.4 原因分析
对比一下二者的运行过程：
| 带 Serena | 无 Serena |
|---|---|
| 1.mcp__serena__find_file（查找用户所指的类文件） 2.mcp__serena_find_symbol（查找对应类的符号定义） 3.mcp__serena_rename_symbol（修改符号名称） | 1.grep .func()：查询包含 .func() 的文件列表（A、B、C、D...，其中 D 不是本次应该改动的点，只是他刚好包含了同名的方法） 2.read 文件 A：读取文件 A 的内容 3.read 文件 B：读取文件 B 的内容 4.read..... 5.edit：修改文件内容 |
从二者的运行过程可以看出，携带了 Serena MCP 的 AI 使用的都是符号级操作，通过直接调用 rename_symbol 工具来完成符号重命名，既可以修改方法名，又能同步更新所有调用点，这种操作就类似于我们使用 IDE 的 rename 功能一次性完成所有的重命名操作；而不携带的则使用的是文件级操作，逐个文件查找并修改 func，最终错误地把非相关类的同名方法也修改了。因此可以看出，文件级操作不仅容易出错，而且还消耗了相当多的 token。
四、总结与思考
目前 AI 编程的关键早已不在会不会写代码，而在于它能否在真实工程中不迷路、改得准、改得全。很多失败并不是模型不够聪明，而是缺少工程级的执行路径：不知道该从哪里下手、一次改动会牵连哪些位置、哪些问题会被编译与诊断暴露出来。
Serena MCP 的价值是把 LSP 等工程能力接入 AI，让它能够基于符号信息、引用关系、诊断结果来推进任务，把凭直觉改升级为按工具链改。在重构类场景（例如重命名、批量替换、跨文件修改）中，这种优势尤其明显。
但也需要强调：仅靠 Serena 仍不足以支撑高质量的 AI 编程。它主要解决 “定位与导航”，却无法覆盖需求边界、架构约束、运行时行为差异等关键问题。因此，最终仍需要与其他方法配合，才能把 AI 编程真正做稳、做对。
