🤖 AI

Beyond Summaries: Structure-Aware Labeling of Code Changes with Large Language Models

本文提出了一种基于大语言模型的两阶段少样本提示流程，用于对代码变更执行结构感知且基于分类体系的标注，在实现高精确率和召回率的同时，为提升代码审查效率提供了一种灵活且与语言无关的替代传统静态分析的方法。

原作者： Bar Weiss, Antonio Abu-Nassar, Adi Sosnovich, Karen Yorav

发布于 2026-05-26

📖 1 分钟阅读☕ 轻松阅读

原作者： Bar Weiss, Antonio Abu-Nassar, Adi Sosnovich, Karen Yorav

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你是这份庞大而混乱的报纸的主编。每天，数百名记者提交微小的文本片段（补丁）以供刊登。你的任务是阅读每一个片段，准确判断它属于何种类型的变更，并为其打上标签，以便团队知道如何处理。

“这仅仅是一个拼写错误修正吗？”
“他们把整段内容移到了新页面吗？”
“他们重命名了故事中的某个角色吗？”
“这是一个全新的剧情转折吗？”

手动完成这项工作令人精疲力竭。而使用老式的计算机程序则如同试图用一本僵化的、预先写好的规则手册来整理图书馆，这本手册仅适用于英文书籍，一旦尝试整理法文书籍就会崩溃。

本文介绍了一种利用大语言模型（LLMs）——即那种能够撰写故事或与你聊天的同类型人工智能——来完成此项分类工作的新方法。但作者并非要求人工智能仅仅“总结”变更（这好比要求它撰写书评），而是让它扮演一位超级有条理的图书管理员，为每一次变更打上具体且结构化的标签。

以下是他们如何实现这一点的简要拆解：

1. 问题：“总结”陷阱

大多数人使用人工智能进行代码审查是为了获取快速总结，例如“此补丁修复了一个漏洞”。这对人类阅读很有帮助，但对于试图自动化工作流的计算机而言却毫无用处。你无法轻易地筛选或排序一堆自由文本的总结。

作者希望人工智能能完成更精确的任务：结构感知标记。他们希望人工智能在查看代码变更时，能说出“这是一个重命名"，接着还能指出“哦，下面三行处的另一个变更也是同一个重命名，只是应用到了不同的文件中”。

2. 解决方案：两阶段流水线

作者构建了一个两步流程，如同工厂流水线，以确保人工智能能准确无误地完成工作，而不会感到困惑。

阶段一：“标记器”（快速扫描器）
想象一个快速扫描器，它查看单个代码片段（“差异块”），并询问：“这是什么？”

它可能会说：“这看起来像是一个样式变更”（仅涉及格式）。
或者：“这看起来像是一个逻辑变更"（代码实际执行了不同的操作）。
它是通过查看该片段以及其前后的一小部分代码来实现的（就像阅读一个单词前后的句子来理解其含义）。

阶段二：“优化器”（侦探）
有时，扫描器会感到困惑，因为它没有看到全貌。也许它看到了变量名的变更，却不知道该变量在其他地方是如何被使用的。
优化器就是那位侦探。它一次性审视整批变更。

它串联线索：“啊，扫描器在这里标记了‘重命名’，在那里也标记了‘重命名’。这两个实际上属于同一个事件！”
它补充缺失的细节：“旧名称是 user_id，新名称是 client_id。”
它将它们关联起来，使计算机知道它们属于同一个“故事”。

3. “魔法”与“规则手册”

本文将这种新的人工智能方法与旧的“静态分析”方法（即僵化的规则手册）进行了比较。

规则手册（静态分析）： 它极其准确，但就像一把只能匹配特定钥匙的锁。如果你想检查新编程语言的代码，就必须聘请工程师建造一整把新锁。这既昂贵又更新缓慢。
人工智能（LLM）： 它就像一位读过数百万本书的聪明实习生。它不需要为每种语言都配备一把新锁；它只需要被告知“这是该语言的规则”。它灵活、快速，并能同时处理多种不同的语言。代价是什么？它并非 100% 完美（偶尔可能会犯错），但足以变得极其有用。

4. 结果：这位实习生表现如何？

作者在真实世界的代码变更和虚构示例的混合体上测试了该系统。他们使用了四种不同的“聪明实习生”（不同的 AI 模型）。

最佳表现者： 其中一个 AI 模型（Gemini-3）在查找所有变更时（召回率）约有 84% 的正确率，而在声称某项变更属于特定类型时（精确率）达到了 81% 的准确率。
“侦探”工作： 该系统在关联相关变更方面表现出色。如果一个函数在一个文件中被重命名，并在另一个文件中使用，该系统能正确识别这两个变更属于同一个“重命名”事件。
成本： 人工智能略显“话痨”，消耗的计算机资源（Token）比旧的基于规则的方法更多，但其灵活性物有所值。

核心结论

本文表明，我们可以利用人工智能不仅仅是为了撰写代码变更的总结，而是为了自动对其进行分类和结构化。

这就像从一位仅仅阅读信件并说“这很重要”的人类，升级为一位阅读信件、盖上“紧急”、“账单”和“新地址”印章，然后自动将其归档到正确抽屉的机器人。它并没有取代人类编辑，但它承担了排序和打标签的繁重工作，使整个审查过程更快、更有条理。

技术摘要：超越摘要：利用大语言模型进行代码变更的结构感知标注

问题陈述

代码审查是缺陷检测和知识共享的关键软件工程实践，然而，随着代码补丁的规模和频率不断增加，该实践面临瓶颈。虽然大语言模型（LLM）已成功应用于代码审查任务（如摘要生成和评论生成），但这些方法主要产生非结构化文本输出。此类非结构化输出难以集成到自动化工作流、分析管道或仪表板系统中。

相反，传统的静态分析工具提供具有形式化保证的结构化变更检测，但它们通常特定于某种语言、扩展成本高昂，且需要大量的工程努力来维护。文献中缺乏一种能够提供结构化、语言无关的代码变更（diff 块）标注的方法，该方法不仅能捕捉变更类型，还能捕捉结构关系（例如重命名传播）和语义属性，同时无需传统静态分析管道的开销。

方法论

作者提出了一项系统性研究，以及一个利用 LLM 进行基于分类法的代码变更标注的两阶段管道。该系统将补丁分解为 diff 块，并根据定义的分类法 $T$ （例如重命名、移动、类型重定义、逻辑变更、样式变更）分配标签。

两阶段管道

标注器（标签分配）：
- 任务： 基于内容为一个或多个 diff 块分配零个或多个标签类型。
- 机制： 使用包含任务描述、标签分类法定义和示例的少样本提示（few-shot prompting）。
- 上下文策略： 作者评估了三种操作模式以研究上下文权衡：
  - 逐块（Per-hunk）： 在单个块上进行推理，仅使用有限的局部上下文（前后 5 行）。
  - 逐文件（Per-file）： 在单个文件内的所有块上进行推理。
  - 逐补丁（Per-patch）： 在整个补丁的所有块上进行推理。
- 输出： 每个块的一组标签类型，结构字段初始化为默认值。
精炼器（结构提取）：
- 任务： 通过分配结构关系和语义属性来细化初始标签。
- 机制： 在单次推理中处理整个补丁（或相关子集），以捕捉跨块关系。
- 关键功能：
  - 关系编码： 识别父子关系（字段 $p$ ），用于重命名操作（将声明链接到用法）和移动操作（将删除链接到添加）。
  - 属性提取： 提取语义属性（字段 $a$ ），例如重命名的旧/新标识符或类型重定义的旧/新类型。
  - 修正： 纠正标注器阶段可能因局部上下文不足而导致的标签类型分配错误（例如，在获得全局上下文后，将“逻辑变更”重新分类为具体的“重命名”）。

评估设置

基准： 一个手动策划的数据集，包含 13 个拉取请求（6 个自然生成，7 个伪造），共包含 95 个 diff 块和 142 个标注实例。该数据集包含 Java 和 Python，以测试语言无关性。
模型： 评估了四种 LLM：SWE-Agent-LM-32B、Llama-4-Maverick-17B-128E-Instruct、Claude Sonnet 4.5 和 Gemini-3-Pro-Preview。
指标：
- 标注器： 预测器交集（IoP）和真实值交集（IoGT），用于衡量逐块的精确率和召回率。
- 精炼器： 父字段匹配的精确率和召回率，以及属性字段提取的精确率和召回率。

关键结果

整体性能： 最佳配置（Gemini-3 在逐文件模式下）在标签分配方面实现了 84% 的召回率和 81% 的精确率。
上下文权衡： “逐文件”推理模式通常在上下文可用性和模型专注度之间提供了最佳平衡，对于大多数前沿模型而言，其表现优于逐块和逐补丁模式。
结构与属性：
- 精炼器在捕捉结构关系方面表现出高准确性。对于重命名操作，父字段匹配的精确率在多种配置中达到 1.0（完美），召回率范围从 0.69 到 0.92。
- 属性提取（例如旧/新名称）显示出高精确率（通常 >0.90），但召回率较低。作者指出，错误通常源于未能正确拆分或枚举单个块内的多个实例，而非属性提取错误。
模型比较： 前沿模型（Gemini-3 和 Sonnet）的表现显著优于开源模型（SWE 和 Llama）。然而，由于输出中包含更详细的推理字段，Gemini-3 的 Token 成本显著更高（高达 Sonnet 的 7.5 倍）。

意义与主张

本文声称首次对 LLM 进行基于分类法的 diff 块标注进行了系统性评估。其主要贡献如下：

用于自动化的结构化输出： 该方法生成结构化、机器可解释的输出（包含标签、关系和属性的 JSON），而非自由文本，从而能够集成到自动化审查和分析管道中。
语言无关性与灵活性： 与静态分析工具不同，基于 LLM 的方法在很大程度上是语言无关的，并且可以轻松定制以适应新的分类法，而无需大量的工程开销。
对静态分析的互补性： 作者将这种方法定位为对静态分析的补充，而非替代。它用形式化保证换取了更快的采用速度、多语言支持以及处理复杂语义关系（如重命名传播）的能力，而这些关系在基于规则的系统中难以编码。
结构感知标注的可行性： 结果表明，LLM 可以有效地捕捉跨 diff 块的结构关系（重命名、移动）和语义属性，这一能力在代码审查文献中此前尚未得到充分探索。

作者总结道，尽管该方法并非没有错误，但所达到的准确度水平足以补充人工审查，并实现灵活且易于自动化的工作流。他们指出的未来工作包括将分类法扩展到语义/意图层面的变更（例如缺陷修复、性能优化），以及将这些结构化输出集成到结合 LLM 与传统静态分析的混合框架中。