静态分析+LLM：代码变更影响分析F1提升至33.3%

代码变更影响分析的老问题：精度与召回难以兼得

开发者提交代码变更后，需要判断哪些代码实体（类、方法、字段等）会被这次改动波及。变更影响分析（Change Impact Analysis, CIA）正是为此而生，但现有方法长期陷入两难：精度高的方法漏报多，召回高的方法误报多，开发者不得不花费大量精力人工核对结果。

更隐蔽的问题在于评估本身。许多CIA研究使用的数据集和实验设置存在偏差，导致报告出来的指标未必反映真实水平。这篇来自arXiv的论文从数据集和算法两个层面同时入手，试图给出一条更可靠的改进路径。

变更影响分析（CIA） 是软件维护领域的经典问题：当开发者修改一处代码（如一个方法或字段）后，需要找出整个代码库中哪些其他实体可能受到波及，例如调用该方法的位置、继承该类的子类、依赖该字段的模块等。传统方法分为静态分析（沿调用图、依赖图传播影响）和动态分析（基于运行时轨迹），前者偏向高召回但误报多，后者精度较高但漏报严重。评估CIA方法通常使用精度（Precision，报出的受影响实体中真正受影响的比例）和召回（Recall，真正受影响的实体中被报出的比例）以及二者的调和平均F1值。由于开发者需要逐一核对报出的实体，误报会直接转化为人工成本，因此精度与召回的平衡是CIA实用化的核心矛盾。

先修数据集：1931个代码实体的人工标注

论文的第一步是构建更可信的评估基础。作者从22个开源Java项目的263次提交中，人工标注了1,931个发生变更的代码实体。这一规模在CIA研究中并不常见——人工标注意味着每个实体是否真正受影响都经过了判断，而不是依赖启发式规则自动生成标签。

数据集的重要性常被低估。如果测试集的"标准答案"本身有偏差，再精巧的算法也只能在错误的地基上比较优劣。作者明确指出，这是对既有CIA方法数据集局限性的直接回应。

FQN（Fully Qualified Name，全限定名） 指包含完整包路径的实体名称，例如 com.example.service.UserService.findById，能够唯一标识一个代码实体，避免不同包下同名类或方法的歧义。CE（Class + Entity name）匹配 则只比较实体所属的类名与实体自身的名称，忽略包路径等前缀信息。采用CE口径的原因在于：不同项目或重构后的代码可能改变包结构，但开发者关心的往往是“这个类里的这个方法是否受影响”，FQN匹配会因包名差异把本应算作命中的结果判为未命中，从而低估方法效果；CE匹配更宽松，也更贴近实际使用场景。论文同时报告两种口径，正是为了展示方法在不同严格程度下的表现差异。

katIA的两套方案：单提示与多智能体

在数据集基础上，作者提出了名为katIA的方法，核心思路是把静态影响分析与大语言模型的推理能力结合起来：先用静态分析生成一个初始影响集，再让LLM对结果进行精炼。

论文给出两个变体。katIA-SP 使用单一提示词完成精炼，结构简单、开销低。katIA-MA 则拆分为三个专职智能体分工协作，流程更复杂但推理更充分。这种"静态打底、LLM收口"的混合架构，本质上是用LLM弥补静态分析在语义层面的盲区，而不是让LLM从零开始猜测影响范围。

多智能体（Multi-Agent） 在这里指将精炼任务拆解给多个各司其职的LLM实例，每个实例拥有独立的提示词和职责（例如分别负责筛选候选实体、补充遗漏实体、校验最终结果），再通过消息传递或结果汇总形成完整流程。与单提示相比，多智能体的优势在于每个环节的推理负担更轻、角色约束更明确，能减少单一提示下模型“一次做太多事”导致的遗漏或幻觉；代价是需要多轮调用，token消耗和延迟成倍增加。论文中katIA-MA拆分为三个专职智能体，正是希望用分工换取更充分的推理，这也解释了为何其F1提升伴随着生成时间从亚秒级升至十余秒。

实验数据：多智能体把CE匹配F1推到33.3%

评估采用两种匹配口径：按全限定名（FQN）匹配，以及按类名与实体名（CE）匹配。后者相对宽松，更贴近开发者实际关心的"这个类/方法是否受影响"。

使用Gemini 2.5 Flash时，katIA-SP的FQN匹配F1为22.4%，CE匹配F1为27.0%，后者相比当时最优方法提升2.0个百分点。katIA-MA进一步提升到FQN 29.1%、CE 33.3%。

代价同样明确：中位生成时间从0.570秒升至11.214秒，中位token消耗从1,235增至6,462。作者的判断是性能提升足以抵消额外成本——考虑到CIA结果最终要由开发者逐一验证，减少误报带来的时间节省确实可能超过推理开销。

模型对比：Gemini 2.5 Flash一致性最好

在katIA-SP框架下对比三个LLM，Gemini 2.5 Flash表现最为稳定。这一结论对实际选型有参考价值：在精炼类任务中，输出的一致性和稳定性往往比单次峰值表现更重要，因为开发者需要的是可预期的结果质量。

几点观察

33.3%的CE匹配F1放在绝对尺度上并不算高，说明代码变更影响分析仍是开放难题。但这项工作有两个值得关注的信号：一是把评估数据集的质量问题摆上台面，人工标注的1,931个实体为后续研究提供了更干净的基准；二是验证了"静态分析+LLM精炼"这一混合范式——不让LLM替代程序分析，而是让它修正程序分析的输出，这种分工在多智能体变体上收益更明显。

对工程实践而言，多智能体方案带来的秒级延迟在离线分析或CI流程中可以接受，但若要做IDE内的实时提示，成本与延迟仍需进一步压缩。