Copilot CLI 评测 Serena 于 ente 多语言 Monorepo：符号级语义工具的增量价值深度分析

Copilot CLI 评测 Serena 于 ente 多语言 Monorepo：符号级语义工具的增量价值深度分析

【免费下载链接】serenaA powerful MCP toolkit for coding, providing semantic retrieval and editing capabilities - the IDE for your agent项目地址: https://gitcode.com/GitHub_Trending/ser/serena

评测摘要（原文声明）：本报告由 Copilot CLI 中的 GPT-5.4（medium）生成，评测代码库为 ente（一个由 Dart、TypeScript、Go、Rust 等语言构成的大型 Monorepo），评测日期为 2026-04-14。评测遵循"从源码出发、只做可逆实验、每步实验后工作区恢复基线"的方法论。

本篇技术指南完整解读这份针对 Serena 的实战评测报告：评测者以 Copilot CLI 的内置工具（Read/Edit/Grep 等）为对照组，在 ente 多语言 Monorepo 上逐项对比了 Serena 的符号级检索与重构工具。读完本文，你将掌握：Serena 在"符号理解、跨文件重构、依赖查找"三类任务上相对内置工具的量化增量（调用次数、载荷大小、前置读取）、其适用边界（小型局部编辑与文本类任务不如内置工具），以及一整套可直接复用的"先用 Serena、再用内置工具"的混合工作流决策规则。文末结合本仓库源码，指出评测中涉及的核心工具的真实实现位置。

1. 评测背景与方法论

1.1 评测的总体定位

本次评测不是一个"二选一"的营销对比，而是一次增量分析（delta analysis）：假设一个熟练用户同时掌握两套工具集，那么只用内置工具时，Serena 带来了哪些具体的能力与效率差异？评测要求明确区分三类结果：

• Serena 增加能力 / 明显改善工作流（added capability）；
• Serena 适用但无明显改进（applies but offers no improvement）；
• 超出 Serena 设计范围（outside Serena's scope）——这类任务归类为"内置工具专属"，不作为负面结论。

1.2 评测流程与基线约束

评测的起点条件非常严格，与 评测 Prompt 中的"ground rules"一一对应：

• 只从源码出发，不读仓库文档、notes、记忆文件，模拟"从未见过该仓库"的探索状态；
• 以 git 作为安全网，真实执行每次编辑，不模拟；每次实验后用git status --short确认工作区干净再进入下一步；
• 采用正确使用（correct-use）原则：只评估工具设计目标内的输入与调用方式；仓库中不存在合法重构候选时（如无可安全删除的未使用符号），如实报告"no suitable candidate"并跳过，绝不构造非法输入；
• 在每个任务上写出完整端到端调用链（含前置读取与后续验证步骤），分别记录调用次数、输入/输出载荷、前置步骤，并将"调用数、输入载荷、输出载荷、验证成本"作为四个独立维度分开度量。

完整的评测提示词可参见 评估 Prompt 与 总结 Prompt，所有评测结果的汇总入口在 评估结果总览。

2. Headline：Serena 到底改变了什么

评测的核心结论可以浓缩为一句：当任务的对象是"代码符号"而不是"原始文本"时，Serena 改变了工作流。在 ente 仓库中的实际增量体现在三个层次：

1. 增加能力 / 显著改善工作流：TypeScript 中的符号级导航与重构——结构总览、纯代码引用、层级查询、符号定向重命名、文件移动带 import 更新、内联（inline）。这些操作通常把内置工具2–6 步的链条在发现阶段之后压缩为1 次语义操作，并减少了人工范围核对（manual scope verification）。
2. 适用但几乎无改进：在已经理解的方法内部做小型局部编辑。内置工具可以只 patch 被改动的行；Serena 的符号体替换会重发整个符号，因此在1–3 行微调场景下往往载荷效率更低。
3. 超出 Serena 范围：非代码读取、自由文本搜索、git 检查、配置/包文件等文本优先任务，内置工具仍然是自然选择。

两个重要的观察限制了 Serena 的增量：最强增益集中在评测实际动手对比的 TypeScript 桌面应用与 Rust 核心 crate；同时部分重构仍带有 diff 形态上的权衡，例如格式化扰动（formatting churn）或意外的目标文件选择。

Verdict（原文结论）：在这个仓库中，Serena 是构建在内置工具之上的一个强 TypeScript 符号层，而不是文本/文件工作的通用替代品。

3. 按能力域拆解的增量价值

评测报告按"频率 × 单次价值"对各个能力域进行了加权排序，核心对照表如下：

Verdict（原文结论）：Serena 价值最高的增量是语义重构与依赖感知的代码查找（集中在 TypeScript/Rust 部分）；最弱的领域是微小局部编辑。

4. 逐任务证据：代码库理解（Task 1–6）

4.1 Task 1：仓库高层总览 —— 无明显差异

• 目标：获取顶层布局与可能的代码密集区域。
• Serena 链：serena-list_dir(.)→ 目录列表。
• 内置链：无需单独执行，Serena 此处没有超越普通目录列表的独特价值。
• 载荷：两边都是一份简短目录列表。
• 结论：无有意义差异，这是纯文件系统探索。

Verdict：对仓库布局而言，Serena 是中性的。

4.2 Task 2：大文件结构总览 + 具体下一步 —— 明显改进

• 目标文件：desktop/src/main.ts（753 行）。
• Serena 链：get_symbols_overview(main.ts, depth=1)→ 顶层函数与main下嵌套局部的紧凑符号地图；下一步find_symbol(createMainWindow, include_body=true)。
• 内置链：对main.ts执行rg搜索const|function|class|export→ 扁平的文本命中；下一步view第 331–439 行读取createMainWindow。
• 载荷对比：
  • Serena 总览：该文件的紧凑符号列表；下一步的 body 获取只返回选中符号体。
  • 内置总览：大量无结构的匹配行；下一步读取需要约 109 行文件内容。
• 差异：Serena 的总览不仅更短，还为后续调用提供了稳定符号名。内置工具也能回答该问题，但需要先做一次文本定位。

Verdict：Serena 把"总览 → 检视单个函数"流程改进为基于符号而非基于行的后续调用。

4.3 Task 3：不读上下文文件直接取类方法体 —— 温和增益

• 目标符号：desktop/src/main/services/auto-launcher.ts中的AutoLauncher/toggleAutoLaunch。
• Serena 链：find_symbol(AutoLauncher/toggleAutoLaunch, include_body=true)→ 精确方法体。
• 内置链：定位方法后view相关文件区间（20–40 行）。
• 载荷对比：Serena 只返回10 行方法体；内置读取返回21 行周边类上下文。
• 差异：Serena 省去一次定位步骤并避免无关行。

Verdict：对定向方法检索，Serena 带来了真实但适度的效率增益。

4.4 Task 4：引用查找的召回率/精度对比 —— 明显改进

• 目标符号：desktop/src/main/utils/common.ts中的wait。
• Serena 链：find_referencing_symbols(wait)→ 3 个文件带符号上下文：main.ts、ffmpeg-worker.ts、ml-worker.ts。
• 内置链：rg \bwait\b desktop/src→ 7 个文件，其中包括：
  • 真实使用/导入；
  • 注释与文档字符串（preload.ts、watch.ts、main.ts中的 prose）；
  • 定义本身；
  • 扩大范围后desktop/docs/release.md中的文档提及。
• 载荷对比：Serena 返回一个按引用符号分组的结构化结果；内置工具返回一个更宽泛的结果，但回答"谁在代码里使用它？"需要人工过滤。
• 差异：Serena 提升的是精度而非仅仅是便利性。

Verdict：当问题语义化（"谁在代码里用它？"）而非文本化时，Serena 明显改善了引用搜索。

4.5 Task 5：父类型 / 子类 / 实现 —— 中等价值

• 等价用例：web/apps/ensu/src/services/llm/inference.ts中的接口层级（该 TS 区域以接口实现为主，缺乏丰富类继承）。
• Serena 链：type_hierarchy(InferenceBackend, both)→WasmInference、TauriInference；type_hierarchy(WasmInference, both)→ 父类型InferenceBackend。
• 内置链：rg InferenceBackend|implements InferenceBackend→ 从四个文本匹配中人工重建。
• 载荷对比：Serena 直接返回层级；内置工具只返回原始声明/使用。
• 差异：Serena 去掉了人工综合步骤。此处内置工具够用是因为层级很浅，但那是示例较小的缘故。

Verdict：对层级查询 Serena 增加中等价值；价值随层级深度增长。

4.6 Task 6：外部依赖符号查找 —— 在 Monorepo 中价值放大

• 索引可用后使用的目标：桌面 TypeScript 应用中的BrowserWindow与serveNextAt，以及rust/core中的Url与Zeroizing。
• Serena 链（TS）：
  • find_declaration(new BrowserWindow(...), include_body=true)→desktop/node_modules/electron/electron.d.ts，body 为class BrowserWindow extends Electron.BrowserWindow {}；
  • find_declaration(import serveNextAt ... , include_body=true)→desktop/node_modules/next-electron-server/index.d.ts，body 为declare function serveNextAt(uri: string, options?: Options): void;；
  • 对这些依赖文件执行find_symbol(..., search_deps=true)返回依赖侧文档。
• Serena 链（Rust）：
  • find_declaration(use reqwest::{Response, Url};, include_body=true)→<ext:lib.rs|...>外部符号Url[0]及结构体 body；
  • find_declaration(use zeroize::Zeroizing;, include_body=true)→<ext:lib.rs|...>外部符号Zeroizing[0]及结构体 body；
  • 对这些外部符号执行find_symbol(..., relative_path=<ext...>, search_deps=true)返回依赖侧文档。
• 内置等价链：手动推断正确的 Monorepo 局部依赖根（desktop/node_modules而非仓库根），或手动检查 Cargo metadata /Cargo.lock，然后直接打开解析后的依赖文件（Rust 场景位于 Cargo registry 下）。
• 载荷对比：Serena 直接返回声明目标与一小段签名/body；内置工具需要先做包根发现，这在 Monorepo 中是一个真实的额外步骤。
• 差异：一旦索引存在，Serena确实增加能力与效率。收益在 Monorepo 中比单包仓库更大，因为依赖归属分散在包局部 Node 依赖与共享 Cargo registry 源之间。

Verdict：索引可用时，Serena 提供了有意义的外部依赖查找，且其价值被 Monorepo 布局放大。

5. 单文件编辑：按编辑规模横跨全谱（Task 7–9）

5.1 Task 7a：方法内 1–3 行小改 —— 内置工具胜

• 改动：将AutoLauncher/toggleAutoLaunch内的局部变量autoLaunch改名为launcher。
• 内置链：view(auto-launcher.ts, 20-40)→ 对 3 个改动行apply_patch→git diff。
• Serena 链：find_symbol(toggleAutoLaunch, include_body=true)→replace_symbol_body(toggleAutoLaunch)→git diff。
• 载荷对比：内置读取21 行、patch 只改3 个逻辑行；Serena 获取10 行 body、重发完整10 行 body。
• 差异：结果相同、主步骤数相同，但符号编辑重发了未触及的行。

Verdict：对方法内微小调整，内置工具载荷更高效，Serena 无实际工作流优势。

5.2 Task 7b：中等重写（约 10–30 行）—— Serena 胜

• 改动：用candidatePath+for循环重写uniqueSavePath。
• 内置链：view(main.ts, 500-540)→apply_patch替换函数体 →git diff。
• Serena 链：find_symbol(uniqueSavePath, include_body=true)→replace_symbol_body(uniqueSavePath)→git diff。
• 载荷对比：内置读取41 行以安全锚定约 10 行重写；Serena 获取11 行符号体并只重发重写后的 body。
• 差异：此处 Serena 更高效：前置读取量更少，且不依赖周边文件上下文。

Verdict：对中等规模的符号级重写，Serena 更好。

5.3 Task 7c：大型/整函数体重写 —— 增益温和

• 改动：重写整个createMainWindowbody。
• 内置链：view(main.ts, 331-439)→apply_patch替换函数体 →git diff。
• Serena 链：find_symbol(createMainWindow, include_body=true)→replace_symbol_body(createMainWindow)→git diff。
• 载荷对比：内置读取约 109 行并 patch 整个函数；Serena 获取相同符号体并重发整个重写后的 body。
• 差异：Serena 仍避免了文件区间读取，但一旦符号本身主导载荷，token 差距基本消失。

Verdict：对整函数体重写，Serena 的增益是适度的：寻址更好，但载荷并不显著更小。

5.4 Task 8：在结构化位置插入新函数 —— 改进明显

• 插入：在desktop/src/main/utils/common.ts的wait之后插入waitSeconds。
• 内置链：view(common.ts, 1-40)→apply_patch在既有函数后插入。
• Serena 链：find_symbol(wait)→insert_after_symbol(wait)。
• 载荷对比：内置读取26 行来放置一个1 行函数；Serena 在符号名已知后无需额外文件区间读取。
• 差异：Serena 把位置从文本化变成结构化。

Verdict：当插入位置是"符号 X 之后"而非"第 Y 行之后"时，Serena 改进了插入。

5.5 Task 9：单文件私有辅助函数重命名 —— 略优

• 目标符号：desktop/src/main.ts中的openStreetMapUserAgent。
• 内置链：view/rg找调用点 + 定义 →apply_patch同时更新两处。
• Serena 链：rename(openStreetMapUserAgent -> buildOpenStreetMapUserAgent)。
• 载荷对比：内置需要人工找到并更新两个文本位置；Serena 一次 rename 调用，返回简洁成功响应（"Success"）。
• 差异：调用数小幅减少；当文件更大或名字更不唯一时，正确性提升更大。

Verdict：即使是单文件私有重命名，Serena 也略优，因为它消除了人工枚举站点的工作。

6. 多文件变更：语义重构的主战场（Task 10–13）

6.1 Task 10：跨文件符号重命名（含 import）—— 最大赢点之一

• 目标符号：wait→delay。
• 内置链：读取common.ts、main.ts、ffmpeg-worker.ts、ml-worker.ts→ 一次多文件apply_patch→git diff。
• Serena 链：对定义符号执行rename(wait -> delay)→git diff。
• 载荷对比：内置需读取4 个文件并手工更新 export、import 与调用点；Serena 一次语义重命名更新了同样的 4 个文件。
• 成功信号：内置只能通过最终 diff 证明成功；Serena 返回"Success"。
• 差异：这是 Serena 最清晰的胜利之一：最终 diff 相同，但人工范围工作大幅减少。

Verdict：Serena 通过把"发现 + 编辑"折叠为一次基于符号的重构，显著改善了多文件重命名。

6.2 Task 11：跨模块移动符号（更新 import）—— 部分价值

• 目标：将nullToUndefined移出common.ts。
• Serena 链：move(nullToUndefined, target_relative_path=http.ts)→git diff。
• 观察结果：Serena 从common.ts移除了该符号、更新了ffmpeg-worker.ts，但创建了一个新文件desktop/src/main/utils/nullToUndefined.ts，而不是并入http.ts。
• 内置等价：需要手工把符号复制到目标模块、更新 import、再删除旧定义。
• 差异：Serena 仍自动化了跨文件更新，但没有提供评测所测的"移入既有模块"行为。

Verdict：对符号移动，Serena 提供部分价值，但不具备"移入所选既有 TS 文件"的完整能力。

6.3 Task 12：移动文件/包并更新 import —— 真实一次调用

• 目标：把desktop/src/main/utils/http.ts移到desktop/src/main/services/http.ts。
• Serena 链：move(file http.ts -> services/)→git diff。
• 观察结果：文件被重命名/移动，ffmpeg-worker.ts的 import 从../utils/http更新为./http。
• 内置等价：定位所有 import、移动文件、逐个 patch 每个 import 路径，然后验证。
• 差异：这是一次真正的单调用语义文件移动。

Verdict：Serena 实质性地改进了需要 import 更新的文件移动。

6.4 Task 12（续）：无剩余使用的安全删除 —— 无合适候选，跳过

• 尝试：在工作区（main.ts、common.ts、temp.ts、inference.ts）中搜索自然未使用的 TS 符号，检查了多个候选（registerForEnteLinks、minimumWindowSize、AutoLauncher/isEnabled、openStreetMapUserAgent、safeJson、buildSamplingConfig）。
• 观察结果：每个可能候选仍有活跃引用。
• 结果：在 Serena 可靠工作的 TS 区域未找到合适候选，因此跳过对比而非强行使用非法输入。

Verdict：因仓库在 Serena 可靠处理的代码区域没有干净的未使用符号候选，此处无任何方向的证据。

6.5 Task 13：删除符号并传播删除到调用点 —— 无合适候选，跳过

• 尝试：寻找一个调用点可以被语义删除（而非内联或手工重写）的辅助函数。
• 观察结果：本仓库中的好候选更适合建模为inline重构，而非带传播的删除。
• 结果：无合适候选；跳过而非使用不安全输入。

Verdict：因可用候选都是 inline 候选而非安全的传播删除候选，此处无实测差异。

6.6 Task 13（续）：内联小辅助函数 —— 真实能力 + 格式化扰动权衡

• 目标符号：waitForRendererDevServer。
• 内置链：view调用点 + 定义 →apply_patch用await wait(1000)替换await waitForRendererDevServer()并删除辅助函数 →git diff。
• Serena 链：inline(waitForRendererDevServer, keep_definition=false)→git diff。
• 观察结果：两者都完成了内联，但 Serena 还重写了文件顶部的无关 import 格式。
• 成功信号：内置为最终 diff；Serena 为{"status":"SUCCESS"}。
• 差异：Serena 提供了独特的语义重构，但本次运行中也引入了逻辑变更之外的格式扰动。

Verdict：Serena 提供了真实的内联能力，代价是低频但真实存在的更广泛格式化扰动。

7. 可靠性与正确性检查（Task 14–16）

7.1 Task 14：范围精度

• 演示对象：AutoLauncher/toggleAutoLaunch、openStreetMapUserAgent、InferenceBackend。
• Serena：符号名与名字路径精确锁定代码实体。
• 内置工具：对wait、writeToTemporaryFile等名字的文本搜索会过度匹配注释、文档与多个文本出现位置。
• 差异：Serena 的工作单元是符号；内置工具的工作单元是匹配行。

Verdict：只要目标是符号而非字符串，Serena 就可靠地更精确。

7.2 Task 15：原子性

• 观察：Serena 的 rename / file-move / inline 在符号选择后各自作为一次重构操作运行。
• 内置工具：单次apply_patch可以原子地更新多文件，但无法发现遗漏的站点；语义完整性仍需人工保证。
• 差异：Serena 的优势不是事务性全有或全无的 patch，而是范围计算（scope computation）。

Verdict：Serena 在语义完整性上的提升大于在 patch 原子性上的提升。

7.3 Task 16：成功信号

• Serena 观测到的成功输出：body 替换为OK，rename 为"Success"，move 为 JSON 结果，inline 为{"status":"SUCCESS"}。
• 内置工具观测到的成功输出：只能通过git diff/ 干净回退得到间接证据。

Verdict：对重构类操作，Serena 给出了比内置工具更清晰的机器可读成功信号。

8. Token 效率分析

8.1 按编辑规模划分

8.2 强制读取（forced reads）

• 内置工具在编辑前通常需要一次定位读取（localization read）。
• Serena 在符号已知时避免了这一步；但任务本身要求理解 body 时仍需要读取。

8.3 稳定寻址 vs 临时寻址

• Serena 的地址（createMainWindow、wait、openStreetMapUserAgent）在后续操作中持续可用。
• 内置工具view得到的行范围在编辑后会过期，后续文本操作需要重新 grep 或重新 view。

Verdict：Serena 在中到大型符号工作与跨文件重构上 token 效率最高；内置工具在微小局部编辑上仍然更精简。

9. 正确使用下的可靠性与正确性总结

• 匹配精度：Serena 的引用搜索回答"谁在代码里使用它？"优于rg——后者混入了散文/注释匹配。
• 范围消歧：Serena 锁定精确符号（AutoLauncher/toggleAutoLaunch、InferenceBackend），而非依赖唯一文本串。
• 原子性：Serena 在单次重构调用中计算并更新语义范围；内置工具可以在人工发现范围后批量编辑。
• 语义查询 vs 文本搜索：层级与引用是最强例证。内置工具可以重建它们，但需要人工解读。
• 外部依赖：索引可用后，Serena 将桌面 TypeScript 依赖解析为desktop/node_modules下的包局部声明文件，将 Rust 依赖解析为url、zeroize等外部 Cargo 源。内置工具也能触达这些文件，但需先做包根或 registry 路径发现。
• Monorepo 效应：本仓库放大了 Serena 依赖查找的价值，因为"依赖源"并不位于一个明显的全局根目录。Serena 直接从应用代码跳到正确的包局部或 registry 支持的依赖上下文。

Verdict：Serena 通过将工作收窄到精确符号、并跨越 Monorepo 边界解析依赖，提升了正确性。

10. 跨会话的工作流效应

• 优势在符号空间中持续叠加：get_symbols_overview(main.ts)产生的符号名被后续find_symbol(createMainWindow)、rename(openStreetMapUserAgent)、inline(waitForRendererDevServer)反复复用。
• 内置工作流需要刷新：在反复的main.ts实验中，编辑前必须不断用view/rg重新获取行范围，因为先前的行号上下文已不可信。
• Monorepo 中 Serena 进一步叠加：桌面应用中可以从main.ts直接跳入 Electron 与next-electron-server声明，无需先推理工作区根；rust/core中可以通过外部符号句柄跳入 Cargo registry 依赖，而无需从Cargo.lock手工重建 registry 路径。
• 叠加效应在微小编辑与非代码工作中消失：此时内置工具已经直接且最小。
• 一个权衡也在叠加：部分 Serena 重构带有格式化副作用（尤其是inline），语义收益并不保证 diff 足够外科手术式地小。

Verdict：Serena 的优势在代码密集的 Monorepo 会话中叠加最明显——符号复用与依赖跳转同时省去了重复阅读与包根发现工作。

11. 独特能力清单

内置工具可以手工近似所有这些能力，但无法作为一次语义操作完成。

Verdict：Serena 确实增加了独特实用能力，尤其是那些需要范围计算而非文本替换的重构。

12. 超出 Serena 范围的任务（仅内置工具）

• 读取desktop/package.json等非代码文件；
• ente://app或 URL 字符串等自由文本搜索；
• git 检查 / diff / 清理；
• 配置/包/changelog/docs/notebook 读取；
• 行范围已知后的精确文本 patch。

在本会话中，这些仅内置任务按操作步骤数约占总量 40%，但它们通常是围绕更有价值的语义工作的低复杂度步骤。

Verdict：日常终端工作中有相当一部分仍是仅内置的，但 Serena 瞄准的是价值更高的符号密集部分，而非整个会话。

13. 实战使用规则与混合工作流

评测给出了一条可直接落地的决策规则：

• 任务围绕代码符号时优先用 Serena，尤其是涉及多文件、引用或整个符号体时；
• 任务围绕文本、配置/文档、自由文本搜索、git 状态或 1–3 行局部调整时优先用内置工具；
• 本仓库中最高产出的混合工作流是：用 Serena 做发现/重构，用内置工具检查非代码内容与做微小 patch。

Verdict：符号语义选 Serena，文本局部性选内置工具。

14. 评测结论与仓库源码印证

这份评测中的工具调用都能在本仓库源码中找到对应实现，可作为进一步研读的入口：

• 符号总览：GetSymbolsOverviewTool（symbol_tools.py）实现"文件结构总览"，其 docstring 明确建议"理解新文件时第一个调用它"；depth=-1时对.java/.kt默认 1、其他语言默认 0，与评测中depth=1的用法一致。
• 符号查找与 body 获取：FindSymbolTool（symbol_tools.py）实现 name path 模式匹配与include_body；include_body=True时强制depth=0，只返回选中符号体，呼应评测中"只返回 10 行方法体"的载荷观察。
• 引用查找：FindReferencingSymbolsTool（symbol_tools.py）按引用符号分组返回结果，并为每个引用附带 1 行上下文代码；评测中"3 个文件带符号上下文"正对应其输出形态。
• JetBrains 后端重构工具：评测使用的重构工具（rename/move/inline/type_hierarchy/safe_delete/依赖查找）对应 jetbrains_tools.py 中的JetBrainsRenameTool、JetBrainsMoveTool、JetBrainsInlineSymbol、JetBrainsTypeHierarchyTool、JetBrainsSafeDeleteTool、JetBrainsFindSymbolTool（search_deps=True）。其中JetBrainsMoveTool的 docstring 明确支持"符号 → 新父符号/文件/目录"三种移动形态，与评测 Task 11 中"创建新文件而非并入既有文件"的观察吻合；JetBrainsTypeHierarchyTool支持super/sub/both三种方向与深度限制，对应 Task 5 的type_hierarchy(..., both)调用；JetBrainsFindSymbolTool的search_deps=True参数即评测 Task 6 依赖查找所依赖的机制。

评测还揭示了 Serena 在 Monorepo 场景下独有的"依赖上下文跳转"能力，这依赖语言服务器或 JetBrains 后端的索引能力——正如 评估结果总览 所述，本系列评测均使用功能更全的 JetBrains 后端，LSP 后端的能力子集可以独立复测。若你想在自己项目上复现这套对比，可直接复用 评估 Prompt 与 总结 Prompt，并按"先定义任务类别、再分别用两套工具执行、记录调用数/载荷/前置步骤"的流程操作。

【免费下载链接】serenaA powerful MCP toolkit for coding, providing semantic retrieval and editing capabilities - the IDE for your agent项目地址: https://gitcode.com/GitHub_Trending/ser/serena