Serena 语义工具实测：Claude Code 在 Tianshou 代码库上的 20 项双工具集对比评估-平芜编程栈

Serena 语义工具实测：Claude Code 在 Tianshou 代码库上的 20 项双工具集对比评估

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

本篇文章完整解读 Serena 官方评估报告 010_cc_on_tianshou.md：由 Claude Code（Opus 4.6，medium 档）在大型 Python 强化学习库 Tianshou（约 2.6 万行、43 个源文件）上，将 Serena 基于 JetBrains 的语义工具与其内置工具（Read/Edit/Write/Grep/Bash 等）逐任务并排执行 20 项实操任务，记录调用次数、载荷大小与前置步骤后得出的增量分析。读完本文，你将掌握"何时该用语义工具、何时该用内置工具"的可量化决策依据，理解名称路径寻址、原子化跨文件重构等核心机制在真实工作流中的价值与边界。

一、评估背景与结论速览

这是 Serena 官方评估体系中的第一份结果，生成方为 Claude Opus 4.6（Claude Code CLI 中的编码 Agent），评估日期为 2026-04-13。评估采用"双工具集并排实测"方法：对同一个任务，先用 Serena 的语义工具执行一遍，再用内置工具执行一遍，所有编辑真实落盘并以git diff验证，随后回滚。评估提示词与完整方法论见 010_evaluation-prompt.md 与 010_methodology.md；全部五份结果索引见 000_evaluation-results.md。

评估结论的一句话概括（摘自报告）：

Serena 基于 IDE 的语义工具是我工具集中最有影响力的新增项——跨文件重命名、移动和引用查找，原本需要 8–12 步小心翼翼且易错的流程，现在坍缩为一次原子调用，我会强烈建议任何与我协作的开发者都配置它。

Serena 在评估中被定位为"增强层"而非"替代品"：它在 JetBrains 后端之上提供文本级工具所不具备的语义层，其价值集中在把多文件、语义感知的操作坍缩为单次原子调用，而内置工具在小型局部编辑、文本搜索、配置文件与 Shell 操作上依然更优。关于"为什么不用标准 Benchmark 评测这类工具增强层"的讨论，可参见 010_methodology.md 中的"Why Not Benchmarks"一节。

二、核心发现：Serena 究竟改变了什么

报告将每一项任务归入三类，其中只有 (b) 类构成中性或负面结论，(c) 类属于范围外背景而非缺陷：

(a) Serena 新增了能力：

跨文件重构（重命名、移动符号、移动文件）：1 次原子调用，对比 N×(Grep+Read+Edit) 调用链。这是 Serena 最强的贡献——把多文件、感知导入关系的操作坍缩为单次语义正确、原子性的调用。
结构化代码导航：符号概览、类型层级、引用查找返回结构化、可消歧作用域的结果，纯文本搜索必须靠人工解读才能得到同等信息。
外部依赖内省：通过 IDE 索引查询已安装包中的符号，无需手动进行环境发现。

(b) Serena 适用但无改进：

单文件内对唯一字符串的重命名：Edit加replace_all=true在 1 次调用内（先 Read）即可达到同等效果，工作量相当。
小改动（方法内 1–3 行）：Edit的子串匹配更高效——发送的载荷更小，无需提供完整符号体。
在已知位置插入新代码：两条路径都约需 1–2 次调用，Edit可按上下文文本定位，Serena 按名称路径定位，工作量相当。

(c) 超出 Serena 范围（仅内置工具）：

非代码文件（配置、文档、notebook、changelog）
仓库范围内的自由文本搜索
Shell 命令、git 操作、测试执行
从零创建文件

结论：Serena 的首要贡献是把多文件、语义感知的操作（重命名、移动、引用查找、类型层级）从多步人工流程坍缩为单次原子调用；对单文件文本编辑，它与内置工具相当或略低效。

三、分领域增值与差异

1. 跨文件重命名 / 移动（强正面）

Serena：1 次调用在 N 个文件中原子地更新定义 + 全部导入 + 全部使用点。
内置：1 次 Grep + N×(Read+Edit) = 2N+1 次调用，非原子。
频率：中等（重构会话中每轮出现数次）。单次价值：高——节省 6–10+ 次调用，并消除部分更新的风险。

2. 结构化概览 / 定向符号读取（中等正面）

get_symbols_overview(depth=1)：1 次调用即通过 IDE 解析器返回全部类、方法与属性的结构化 JSON，语言无关且始终正确。内置等价物Grep用语言特定的启发式正则（如^(class |def )）——对简单 Python 文件可用，但本质上脆弱：正则须按语言手工调参，会漏掉带装饰器或多行声明，还会命中字符串与注释内部。
find_symbol(include_body=True)：按名称路径直接取回指定方法体，无需读取周边代码。内置需先 Grep 拿行号再按 offset Read——2 次调用。
频率：高（每会话多次）。单次价值：低到中等——每次导航省约 1 次调用与部分上下文窗口 token；相比启发式 Grep 的可靠性优势在各语言间一致。

3. 带结构化上下文的引用查找（中等正面）

find_referencing_symbols：返回哪些符号引用了目标，按文件分组并标注用法类型（import、call、type annotation）。内置Grep返回全部文本匹配（含文档、注释、字符串字面量）——召回相同但精度更低。
频率：中等。单次价值：中等——在为广泛使用的符号规划重构时，精度至关重要。

4. 类型层级（正面，小众）

1 次调用返回传递闭包式的完整父类/子类链。内置需迭代 Grepclass X(Y)模式并手工求传递闭包。
频率：低（架构探索时偶尔出现）。单次价值：高——每次省数次调用。

5. 编辑间的稳定寻址（中等正面）

Serena 按名称路径寻址符号（如CollectStats/refresh_return_stats），该路径对文件内其他位置的编辑保持不变。内置工作流从根本上以行号为中介：Grep 返回行号、Read 接收行偏移——文件一经编辑两者即失效。Edit的文本匹配（old_string）比行号更抗变，但它处于以位置查找开头的链路末端。
这意味着用内置工具做多次编辑的会话，每次编辑后都必须重新 Grep/Read 以恢复位置；而 Serena 的名称路径全程有效。在任务 17（三次连续编辑）中，Serena 共需 3 次调用；内置路径恰因文本锚点唯一而只需 4 次（1 Read + 3 Edit）——但若任何一次 Edit 的唯一性校验失败，就必须重新 Read，次数将推高到 5–7。
频率：高（任何对同一文件做多次编辑的会话）。单次价值：中等——每个编辑链省 1–2 次重复读取，并消除"过期行号导致编辑落到错误位置"这类错误。

6. 单文件小/中规模编辑（中性到轻微负面）

对 13 行方法内的 1 行改动，Serena 的replace_symbol_body需发送完整 13 行方法体，Edit只发被改的那一行。前置成本不同：Serena 需find_symbol(include_body=True)取方法体；Edit需 Read 相关行。两者都是 1 次前置 + 1 次编辑调用。
频率：非常高。单次价值：对 Serena 轻微负面——小改动载荷更大。

结论：Serena 最强的贡献集中在跨文件重构（高价值、中频率）与结构化导航（中价值、高频率）；对小文本编辑，内置工具略高效。

四、分能力逐项证据（含源码印证）

评估使用的是 JetBrains 后端版本的 Serena（见 000_evaluation-results.md）。下列工具在仓库中均有真实实现：JetBrains 后端工具位于 jetbrains_tools.py，LSP 后端的对应工具位于 symbol_tools.py。

4.1 结构化概览（任务 2）

指标	Serena`get_symbols_overview(depth=1)`	内置`Grep`class/def
调用次数	1	1
输出结构	JSON 树：14 个类，含嵌套方法与属性	扁平列表：54 行`class`/`def`及行号
可见嵌套？	是——方法分组在类下	否——靠缩进暗示嵌套，无分组
可见属性？	是	否
输出大小	约 2.5KB 结构化 JSON	约 3KB 扁平文本
正确性	始终正确——使用 IDE 解析器，语言无关	启发式——`^(class \\|def \\| def )`仅适用于 Python，会漏掉带装饰器的方法、多行签名，或命中字符串/注释
语言可移植性	对 IDE 支持的任何语言直接可用	每种语言都需重写手调正则
下一步	`find_symbol("ClassName/method", include_body=True)`——1 次调用	`Read(file, offset=line, limit=N)`——1 次调用

源码印证：JetBrainsGetSymbolsOverviewTool（jetbrains_tools.py）默认按语言选择深度——Java/Kotlin 为 1、其余语言为 0，返回"按类型分组的紧凑 JSON"，并支持按深度降级为"仅顶层概览"或"按类型计数"的缩短结果；而JetBrainsFindSymbolTool（jetbrains_tools.py）的name_path_pattern支持简单名、相对路径后缀匹配、以/开头的绝对名称路径，以及[i]下标区分重载、*通配符。

结论：Serena 提供跨语言始终正确的结构化概览；基于 Grep 的概览是启发式近似，在简单场景可用，遇到复杂声明或非 Python 代码库则退化。

4.2 定向方法检索（任务 3）

指标	Serena	内置
调用次数	1（`find_symbol`加`include_body=True`）	2（Grep 找行号 + Read 按 offset）
前置条件	知道名称路径	知道方法名
输出	仅方法体（无周边代码）	含周边代码（需估算 limit）

实测Collector/_collect（330 行）：Serena 精确返回 330 行；内置 Read 返回 332 行（混入下一个方法的签名）。

结论：Serena 省 1 次调用并精确返回所请求的方法体；内置方法可用但需要行号发现。源码层面，find_symbol在include_body=True时会强制depth=0并跳过 quick info 与文档（jetbrains_tools.py），保证输出即纯方法体。

4.3 跨文件引用（任务 4）

指标	Serena`find_referencing_symbols`	内置`Grep`
调用次数	1	1
命中的文件	63（仅代码文件，按符号类型结构化）	83（含 docs、notebook、changelog、README）
输出结构	按文件分组，分类（import、call、type annotation）	扁平文件列表
精度	仅代码引用	全部文本提及

Grep 命中 83 个文件（含README.md、CHANGELOG.md、.ipynbnotebook），Serena 命中 63 个代码文件。回答"代码里谁用了它？"Serena 的结果可直接使用；回答"任何地方哪里提到过？"Grep 才合适。

源码印证：JetBrainsFindReferencingSymbolsTool（jetbrains_tools.py）在返回前会把"引用行号"替换为实际上下文代码（前后各 1 行），并支持按文件统计引用数的缩短结果，属于典型的"代码级引用"语义。

结论：Serena 提供更高精度的代码使用结果；Grep 提供更广的文本级覆盖。不同工具回答不同问题。

4.4 类型层级（任务 5）

指标	Serena`type_hierarchy`	内置
调用次数	1	2+（Grep`class X(BaseCollector`+ Grep`class Collector(`+ 可能的传递搜索）
结果	父类`BaseCollector → ABC → object`，子类`BaseCollector → Collector → AsyncCollector`，附文件位置	`class Collector(BaseCollector[TCollectStats], ...)`位于第 551 行——还需继续读取才能确定 AsyncCollector 的父类

结论：Serena 一次调用产出完整传递层级；内置需迭代搜索。实现上JetBrainsTypeHierarchyTool（jetbrains_tools.py）分别请求 supertypes/subtypes，hierarchy_type可取super/sub/both，深度可限，输出按文件分组的紧凑 JSON，未纳入的层级数会以levels_not_included明示。

4.5 外部依赖查询（任务 6）

指标	Serena	内置
能否取到	能——`find_declaration`配合 IDE 索引	需环境发现：`python -c "import X; print(inspect.getfile(X))"`再 Read
基础设施	IDE 索引（预构建）	可用的 Python 环境、正确激活的 venv
结果	符号位置 + 文档	完整源文件（若环境就绪）

本次会话中 Python 环境无法直接从 bash 访问，内置查询需要额外搭建；Serena 则通过 IDE 索引取回了torch.distributions.Distribution的位置与 docstring。此外find_symbol支持search_deps=True直接搜索项目依赖（jetbrains_tools.py），并约定外部依赖以<ext前缀标识符寻址（不可猜测）。

结论：Serena 无需环境配置即可做依赖内省；内置方法需要可用的解释器。

4.6 小改动——1 行变更（任务 7a）

指标	Serena`replace_symbol_body`	内置`Edit`
前置调用	1（`find_symbol`加`include_body=True`）——任务 3 已完成	1（Read 约 15 行）
编辑调用	1（发送完整 13 行方法体）	1（发送 1 行 old + 1 行 new）
编辑调用载荷	约 550 字符（完整方法体）	约 120 字符（仅变更行）
总调用数	1–2	2

结论：小改动场景下，Edit在编辑调用中少发送约 4.5 倍载荷；总调用数相同。

4.7 中等改写——约 19 行（任务 7b）

指标	Serena	内置
前置	1 次`find_symbol`（已完成）	1 次 Read（约 22 行）
编辑载荷	约 550 字符（新方法体）	约 1000 字符（旧 19 行 + 新 20 行）
总调用数	1–2	2

在此规模下 Serena 载荷反而更小——因为Edit必须同时发送新旧文本，而 Serena 只发送新方法体。交叉点大约在"改动区域超过方法体一半"时。

结论：中等规模下两者载荷趋近；Serena 因只发送替换内容而略小。

4.8 大型改写——55 行（任务 7c）

指标	Serena	内置
前置	1 次`find_symbol`（已完成）	1 次 Read（约 67 行）
编辑载荷	约 2200 字符（新方法体）	约 4400 字符（旧 63 行 + 新 62 行）
总调用数	1–2	2

结论：整方法重写场景，Serena 少发送约 50% 载荷——只发替换内容、不发原文。LSP 后端的ReplaceSymbolBodyTool（symbol_tools.py）明确要求先以include_body=True检索过方法体再替换，并配合诊断上下文返回成功结果，是"按名称路径做整段替换"的规范入口。

4.9 跨文件重命名（任务 10）

指标	Serena`rename`	内置调用链
调用次数	1	1 Grep + 4 Read + 4 Edit = 9
受影响文件	4（自动发现）	4（经 Grep 手工发现）
导入处理	自动	手工——必须逐条定位并改写 import 语句
原子性	原子——全成或全败	顺序执行——中间态不一致

结论：Serena 把跨文件重命名的 9 次调用链压成 1 次，且具备原子性。实现上JetBrainsRenameTool（jetbrains_tools.py）经由JetBrainsCodeEditor.rename_symbol完成，name_path为空时还可直接重命名文件或目录。

4.10 跨模块移动符号（任务 11）

指标	Serena`move`	内置等价
调用次数	1	约 8–12（Read 源、Edit 删源、Edit 加目标、Grep 导入、逐文件 Read+Edit 导入点）
导入更新	自动	手工——必须在每个文件重写`from X import Y`→`from Z import Y`
依赖导入	自动为目标文件补充所需导入	必须手工检查被移动函数的导入并逐一复刻

将get_stddev_from_dist从collector.py移到stats.py：Serena 1 次调用更新 3 个文件（源、目标、测试），包括为目标模块补充必要导入。

结论：move是 Serena 单次价值最高的操作——它处理了手工极易出错的导入依赖图更新。JetBrainsMoveTool（jetbrains_tools.py）同时支持符号移动与文件/目录移动，目标位置即新父节点，且"移动不重命名"。

4.11 移动文件（任务 12a）

指标	Serena`move`	内置等价
调用次数	1	1 次`git mv`+ 1 Grep + N×(Read+Edit) 导入更新 ≈ 12
更新文件	5 处导入自动更新	必须手工发现并重写

结论：与符号移动同模式——Serena 把 N 步过程坍缩为 1 步。

4.12 安全删除（任务 12b）

Serena 的safe_delete在安全模式（默认）下：

删除前报告全部使用点——充当守卫。
对未使用的符号，1 次调用干净删除。
对仍在使用的符号，拒绝删除并列出使用点。

内置等价：Grep 检查使用 → 若无则 Read + Edit 删除，共 2–3 次调用。

结论：安全删除内置了内置路径必须手工实现的安全检查。JetBrainsSafeDeleteTool（jetbrains_tools.py）提供delete_even_if_used（默认 False）与propagate（把删除传播到使用点并清理由此不再使用的代码）两个开关，后者"清理能力强但需谨慎"。

4.13 内联（任务 13）

Serena 的 inline 工具对测试的所有 Python 函数均不工作。JetBrains 后端不支持 Python 函数内联——这是 IDE 重构引擎的语言级限制，而非 Serena 的 bug。

结论：本代码库无合法内联候选；inline 能力对 Python 似乎不可用。对照可见 050_junie_plugin_on_tianshou.md 中 Java 场景对内联的处理差异。

4.14 作用域精度（任务 14）

collector.py中存在三个同名方法reset_env（分别位于BaseCollector、Collector、AsyncCollector）：

Serena：find_symbol("Collector/reset_env")精确返回该 override 的方法体。
Grep：返回 3 个行号，须阅读周边上下文才能判定归属。

结论：Serena 的名称路径寻址消除了 Grep 必须做的类级消歧。名称路径机制（Class/method、重载加[i]下标、*通配）定义见JetBrainsFindSymbolTool的 docstring（jetbrains_tools.py）。

4.15 连续编辑（任务 17）

对CollectStats中三个方法连续三次编辑：

Serena：3 次replace_symbol_body调用，0 次中间读取。名称路径（CollectStats/refresh_return_stats、CollectStats/refresh_len_stats、CollectStats/refresh_std_array_stats）因是结构标识符而非位置，全程有效。
内置：最佳情况 1 Read + 3 Edit = 4 次调用。Read 必须先做（Edit 强制"编辑前必须读取"）；3 次 Edit 无需重读只因old_string锚点恰好保持唯一。但这很脆弱：Edit 在外部工具改动文件时还会强制"文件已被修改"检查而要求重读。更根本的是，若要先找到这些方法（不预先知道行号时的一般情形），第一次编辑前的 Grep 结果在编辑后全部过期——在第 232 行上方插入 2 行后，第 232 行不再是第 232 行。

核心不对称性：Serena 的寻址是结构化的（天然扛编辑），内置寻址是位置化的（Grep/Read 的行号在任何插入/删除后失效）。Edit的文本匹配只能部分缓解——但仅限于最后一步，发现步骤（Grep、带 offset 的 Read）仍然依赖位置。

结论：Serena 的名称路径稳定性消除了编辑之间的重读/重查循环；内置工具在每次位移行号的编辑后都必须重新获取位置。

五、Token 效率分析

按编辑规模对比载荷

编辑规模	Serena 载荷（编辑调用）	Edit 载荷（编辑调用）	胜者
13 行方法内改 1 行	约 550 字符（完整方法体）	约 120 字符	Edit（约 4.5 倍）
19 行中等改写	约 550 字符	约 1000 字符	Serena（约 1.8 倍）
55 行整体重写	约 2200 字符	约 4400 字符	Serena（约 2 倍）
跨文件重命名（4 文件）	约 100 字符	约 800 字符（4 次 Edit 调用）	Serena（约 8 倍）

前置读取

Serena：find_symbol(include_body=True)返回符号体；若探索阶段已导航到该符号，则无需额外调用。
内置：Read 带 offset/limit，Edit 前总是必须（工具强制）。

稳定寻址 vs 临时寻址

Serena 的名称路径（如CollectStats/refresh_return_stats）是稳定标识符——周边代码的任何编辑都不影响它，编辑间无需重读或重新发现。
内置工作流在每一阶段都使用临时、基于位置的地址：Grep 返回行号、Read 接收行偏移，二者都会被目标上方的任何插入/删除作废。Edit的old_string匹配基于内容、相对抗变，但它依赖上游位置步骤才能知道"匹配什么"。行号一旦被编辑位移，整条 Grep→Read→Edit 链必须从头重跑。
在单文件 N 次编辑的会话中，内置工具为此付出最多 N-1 次额外 Grep/Read 往返；Serena 的成本为零——同一个名称路径在第 1 次和第 10 次编辑时同样有效。

结论：Serena 在中大型编辑与跨文件操作上更省 token；Edit在小型局部改动上更高效。跨多次编辑的会话中，Serena 的稳定寻址避免了随内置编辑次数累积的"重读税"。

六、可靠性与正确性（正确使用前提下）

匹配精度

Serena：名称路径精确解析符号。Collector/reset_env无歧义地选中一个方法。
Edit：文本匹配。唯一字符串可正确命中；非唯一字符串失败（Edit 会报告错误）。

作用域消歧

Serena 通过名称路径区分 override、重载（借助下标）与嵌套类。
Grep/Edit 无法区分不同类中的同名方法——除非阅读周边上下文。

原子性

Serena 的跨文件操作（rename、move）是原子的——全部文件更新或全部不更新。
内置的多文件编辑是顺序执行——中途失败会留下不一致状态（可用git checkout恢复）。

语义查询 vs 文本搜索

find_referencing_symbols返回按类型分类的代码级引用；Grep 返回全部文本提及。
type_hierarchy返回传递的子/父类型；无内置等价物，只能迭代搜索。

外部依赖查询

Serena：经 IDE 索引可用，无需环境搭建，可取回符号文档与位置。
内置：需要可用的 Python 环境、正确的 venv 与手工文件发现；环境就绪时信息更全（完整源码），但搭建成本更高。

结论：Serena 在符号级操作上提供更强的正确性保证（作用域、原子性、语义精度）；内置工具在文本级操作上可靠，但作用域消歧需人工投入。

七、跨会话工作流影响

复合优势

探索→编辑无需重新获取位置：Serena 的概览工具产出的名称路径可直接作为编辑目标；内置路径产出行号（经 Grep）供 Read 消费——但编辑后这些行号即过期。典型的"探索-编辑-探索-编辑"循环中，Serena 的名称路径全程有效，内置行号每次编辑后都必须重新获取。3 轮探索+编辑循环约省 3–6 次中间 Grep/Read 调用。
连续编辑无需重读：名称路径稳定意味着同文件多次编辑间零重读。N 次编辑最多省 N-1 次 Read。Edit的文本匹配能部分规避（只要 old_string 保持唯一），但上游发现步骤（Grep 行号、Read 偏移）依然会过期。
跨文件重构：当重命名或移动是更大变更的一部分时，原子执行避免了手工跟踪"还有哪些文件要改"。

边际递减

纯探索会话（只读代码、不编辑）：Serena 优势有限——导航场景 Grep/Read 几乎一样快，结构化输出省不了几次调用。
以小文本编辑为主的会话（配置修改、日志文案微调）：Serena 无增值。

中性发现

单文件工作上两者总调用数相近，差距约每次操作 1 次调用。
代码评审场景（读 diff、理解变更）的输出质量相同——两者都依赖git diff。

结论：Serena 的优势在"每个操作喂给下一个操作"的多步重构会话中复合累积；在读为主或小编辑为主的会话中优势边际化。

八、独特能力（无实际内置等价物）

原子跨文件重命名——1 次调用，全部导入与使用点更新，全成或全败。内置无等价物，除非脚本化多步链。频率：中等（重构会话）；影响：高（省 5–10 次调用，消除部分更新风险）。
原子跨文件移动（符号或文件）并重写导入——含为目标模块补充必要导入。频率：低到中等；影响：单次极高（省 8–12 次调用，处理导入依赖图）。
类型层级遍历——传递父类型与子类型 1 次调用完成。内置需迭代 Grep 加手工传递闭包。频率：低；影响：中等（省 3–5 次调用）。
带使用检查的安全删除——删除前报告全部使用点，可选项传播删除。内置需 Grep + 手工验证。频率：低；影响：中等（价值在安全检查本身）。
经 IDE 索引的外部依赖符号查询——无需 Python 环境。频率：中等；影响：中等（免去环境搭建摩擦）。

结论：Serena 提供了 3–5 项无实际内置等价物的能力，集中于跨文件重构与语义导航。

九、Serena 范围之外的任务（仅内置）

非代码文件操作：读写配置、文档、changelog、notebook →Read/Edit/Write
自由文本搜索：查找日志字符串、URL、魔法常量 →Grep
Shell 操作：跑测试、构建、git 命令、包管理 →Bash
文件创建：从零新建文件 →Write
基于 glob 的文件发现：按模式找文件 →Glob
宽泛代码库搜索：不确定要找什么时 → 带正则的Grep

占日常工作的估计比例：上述任务约占典型编码会话的 40–60%（读文档、跑测试、搜模式、改配置）。Serena 的增强覆盖其余 40–60% 代码级语义操作。

结论：内置工具处理约一半完全超出 Serena 范围的日常工作；Serena 增强代码为中心的另外一半。

十、实操使用准则

任务类型	使用
跨文件重命名、移动、删除	Serena（独特能力）
理解类层级或符号关系	Serena（1 次调用 vs 迭代搜索）
获取大文件结构化概览	Serena（结构更丰富）或 Grep（更简单、更快）
按名称读取特定方法体	Serena（直达）或 Grep+Read（2 次调用）
方法内小改动（1–5 行）	Edit（载荷更小）
整方法重写	Serena`replace_symbol_body`（载荷更小、无需重读）
单文件唯一标识符重命名	Edit 加`replace_all`（等价）
非代码文件、配置、文档	内置`Read`/`Edit`
文本搜索、模式匹配	内置`Grep`
涉及 shell、git、测试	内置`Bash`
外部依赖检查	Serena（无需环境搭建）

结论：跨文件重构与语义导航用 Serena；文本级编辑、非代码文件与 shell 操作用内置工具；单文件代码编辑按规模选择——小改动用 Edit，整方法体重写用 Serena。