面向软件工程的人工智能（AI）近年来取得了显著进展，成为生成式人工智能领域的一个重要成功案例。然而，在自动化软件工程达到其全部潜力之前，仍有许多需要解决的挑战。应有可能实现高度自动化的状态，使人类能够专注于构建什么和如何平衡困难权衡等关键决策，而大多数常规开发工作可以被自动化取代。要达到这种自动化水平，需要学术界和工业界的大量研究和工程努力。在本文中，我们以三方面的方式讨论了这一目标的进展。首先，我们提供了面向软件工程的人工智能具体任务的结构化分类法，强调了软件工程中除了代码生成和补全之外的许多其他任务。其次，我们概述了限制当前方法的几个关键瓶颈。最后，我们提供了一些建议的研究方向列表，以应对这些瓶颈，希望能够激励未来在这个快速成熟的领域中的研究。

面向软件工程的人工智能（AI）近年来取得了显著进展，成为生成式人工智能领域的一个重要成功案例。然而，在自动化软件工程达到其全部潜力之前，仍有许多需要解决的挑战。通过额外的努力，应该可以实现高度自动化，使人类能够专注于构建什么和如何平衡困难权衡等关键决策，而大多数常规开发工作可以被自动化取代。然而，要达到这种自动化水平，仍然需要学术界和工业界的大量研究和工程努力。本文提供了实现这一目标的任务、挑战和有希望的方向的意见性观点。

许多现有的调查与本文讨论的主题重叠。Liang等人 (2024) 和 Sergeyuk等人 (2025) 调查了AI编程助手的成功与挑战，(Wang等人, 2024c) 调查了使用LLM进行软件测试的情况，Joel等人 (2024) 调查了在低资源和特定领域语言中使用LLM的情况，Zhang等人 (2023c) 关注自动化程序修复，无论是使用还是不使用LLM。最后，Yang等人 (2024d) 提供了一个形式数学推理的路线图，并与我们在软件验证方面的讨论有一定重叠。

此外，许多论文讨论了当前AI在软件工程中的状态、挑战和未来 (Fan等人, 2023; Ozkaya, 2023; Wong等人, 2023; Zheng等人, 2023; Hou等人, 2024; Jin等人, 2024; Wan等人, 2024b; Roychoudhury等人, 2025a)。我们的工作从中汲取灵感，并建议读者参考它们以获得不同的视角。

在本文中，我们的目标是三重的。在第2节中，我们提供了一个面向软件工程的AI具体任务的结构化分类法。特别是，我们强调了软件工程中有许多其他任务超出了代码生成和代码补全的范围，鼓励在这些领域的研究。我们提供了三种衡量每个任务的具体实现方式的标准：问题规模、逻辑复杂性和人类干预水平。

接着在第3节中，我们突出了当今模型面临的九个领域的挑战，这些问题跨越多个任务且适用于多个任务。在第4节中，我们提出了应对上述挑战的一系列有前景的研究方向，图1总结了哪些方向对应于每个挑战。我们希望通过本文，读者能够欣赏到该领域取得的进步，理解当今最先进模型的不足之处，并从我们建议的未来想法中获得灵感以应对这些挑战。

AI 软件工程中的任务

我们首先提供一个AI软件工程任务的分类法。为了以结构化的方式考虑每个任务的具体实现，我们定义了三个适用于所有任务的衡量标准：范围、逻辑复杂性和人类干预水平。为了实现AI软件工程师，我们努力让AI在所有三个衡量标准上都具备全面的能力。

范围衡量标准：我们将范围定义为三个层次，即AI对代码库所做的更改程度。函数级范围指的是单个独立的函数，例如HumanEval (Chen等人, 2021a) 和MBPP (Austin等人, 2021) 中的功能。自包含单元范围超越了单一函数，扩展到更大的代码块，如整个文件和类，例如FullStackBench (Liu等人, 2024d) 和BigCodeBench (Zhuo等人, 2024)。最后，项目级范围指的是较大的代码库，例如整个存储库，如Commit0 (Zhao等人, 2024) 和SWE-Bench (Jimenez等人, 2024)。

逻辑复杂性衡量标准：当设计算法来解决问题时，任务需要广泛的推理能力。低逻辑复杂性任务几乎不需要推理，例如编写CRUD（创建、读取、更新、删除）应用程序或使用API。中等逻辑复杂性任务包括大多数LeetCode问题、发现模糊简单程序的输入以及推理多线程程序的执行行为。高逻辑复杂性任务需要细致和具有挑战性的算法和逻辑推理，要么因为算法本身复杂，要么因为问题需要巧妙的思考和见解。这包括困难的竞赛编程问题、编写大型线程安全并发程序、破解加密密钥和解决类似SMT的问题。许多流行的编码基准是功能级别的，中等到高的逻辑复杂性，例如APPS (Hendrycks等人, 2021)、CodeContests (Li等人, 2022a) 和LiveCodeBench (Jain等人, 2024b)。

图1：AI在软件工程中的挑战（第3节）和前进路径（第4节）概览

代码库的语义理解：有效编写代码依赖于对整个代码库的强语义理解（某种程度上类似于世界模型）：结构性地看到代码的各个部分是如何结合在一起的，知道某个功能在哪里实现，理解算法的工作原理，并跟踪某些程序点的不变性。大语言模型（LLMs）在全局语义理解方面存在困难。

潜在解决方案：4.1

代码库的全局和整体语义理解对于完成几乎所有与代码相关的任务至关重要。例如，假设一位工程师被要求改进查询的运行时性能。为此，他们必须首先充分理解代码库的结构，以便知道算法的所有部分在哪里实现。然后，他们需要详细理解算法和实现。这包括高层次算法（包括其时间复杂度）和低层次实现细节，以识别算法和实现瓶颈。最后，在想出解决方案后，他们必须回到对全局代码结构的理解，以便在不引入新错误的情况下将新算法整合进去。

LLMs在代码库的语义理解方面遇到困难的原因有几个。首先，代码的拼接方式可能相对复杂，理解所有这些复杂关系可能会很困难。其次，代码通常包含逻辑复杂的单元，其中包含从未出现在训练数据中的自定义算法。最后，由于不成比例的大数量的LLM训练标记用于代码生成而不是其他编码任务，模型可能缺乏对代码的整体意识和世界模型。

一个期望是模型可以在各种编码任务之间推广知识 (Roychoudhury and Zeller, 2025)。然而，这可能并不像仅仅在更多任务上训练那么简单：Gu等人 (2024) 发现，在自然语言/代码对上微调的编码模型在代码生成方面有所改善，但未能推广到

代码理解和执行推理。尽管已有成功尝试通过增强代码LLM训练中的执行信息来改进总体编码能力 (Ni等人, 2024; Ding等人, 2024c)，但赋予代码LLM对代码的通用和整体理解仍然是今天的重大挑战。

2.2 代码转换

2.2.1 代码重构

在代码重构中，目标是对软件的现有实现进行重写，同时保持正确性。此任务的一个挑战是，成功不仅限于功能正确性或指标。通常的目标是提高代码的可维护性、可读性或可扩展性——这些都是难以量化且高度依赖上下文的质量。

例如，将共享功能提取到辅助方法中会涉及到模块化与认知复杂性之间的权衡 (Parnas, 1972)。软件工程师采用的一种启发式方法是“三次打击则重构”规则——抽象应在某段代码被复制三次时使用。由于确定重构应在哪一级别进行常常不清楚，因此在高自主级别下完成重构也很困难。这些挑战进一步因需要理解针对特定代码库的隐含权衡、尊重约定以及推理结构变化对长期维护的影响而加剧。虽然代码重构通常具有较低的逻辑复杂性，但在实践中可能非常耗时，因为看似小的重构可能会在整个代码库中传播。

示例：React Fiber架构重构：React的主要重构是由原始引擎的性能限制驱动的，特别是在涉及动画和动态更新的复杂用户界面中。除了优化实现的挑战外，另一个主要挑战是在完全重写React的核心算法的同时提供向后兼容性。作为一种开源工具，这次重构还要求开发者了解新概念而不破坏现有的思维模式，突显了现实世界软件系统设计中的细微差别。

2.2.2 代码迁移和翻译

一项极其耗费资源（时间和手动努力）并频繁影响公司的任务是迁移大量代码，同时保留所有原有功能和语义。这类高价值迁移为AI辅助自动化提供了减少成本和手动工作的机会。代码迁移通常具有非常大的范围（许多文件和系统受到影响及其相互依赖）和较高的逻辑复杂性（所需的转换深度，不同语言中的构造可能不同）。当前解决方案可能在处理具有大规模但适度逻辑需求的迁移（如API迁移、类型转换）时表现良好，但在跨组件边界的变化方面却面临困难 (Nikolov等人, 2025)。

代码翻译（转译）是一种特殊情况：将代码从源语言重写为目标语言。在行业中，这项任务可能是出于多种原因，例如遗留语言的安全性和可扩展性问题、避免项目多年积累的技术债务以及提高代码库的性能。由于许多迁移的安全关键性和跨系统特性，这项任务通常在实践中需要大量的人工监督，无法完全自主完成。

示例：Scala 版本迁移：最近的一次 Scala 2.13 到 3 的迁移 (Ricadat, 2025) 描述了这些挑战，记录了一年的努力过程。关键问题包括宏注解的丢失、类型投影的中断、不兼容的库以及编译器性能下降——所有这些问题都需要创新的解决方案和架构变更。由于这是一个开源工具，此次重构还需要教育开发者关于新概念，而不会扰乱现有的思维模式，从而突出实际软件系统设计中的细微差别。

示例：COBOL：COBOL 每天处理超过 2200 亿行生产代码，支持80%的面对面金融服务交易和95%的ATM刷卡操作，同时每天处理3万亿美元的商业活动 (Taulli, 2020)。然而，COBOL程序员越来越少，导致人们希望从COBOL迁移到现代语言如Java (Sneed, 2001; Sellink等人, 2002; Sneed, 2010)。然而，由于现有的COBOL代码规模庞大且逻辑复杂性高，从COBOL迁移到Java将是一项巨大的任务，许多公司选择继续使用COBOL。这些公司仍然被迫迁移到更新的版本如COBOL V6，因为早期版本的COBOL逐渐退出服务。此任务仍需要熟练的COBOL工程师和高精度，因为在理解遗留代码的业务逻辑和引入错误可能带来危险后果方面往往存在困难。

示例：Twitter迁移以提高延迟：Twittera 使用Ruby on Rails构建了其初始平台，促进了快速开发。然而，随着用户群的增长，性能和可扩展性问题出现了。他们将关键组件迁移到Java和Scala，实现了延迟降低3倍的效果。这种过渡需要重新设计系统以适应Ruby的动态特性到Java和Scala的静态类型环境，体现了大规模代码翻译的复杂性。

ahttps://www.infoq.com/news/2012/11/twitter-ruby-to-java/

示例：C 到 Rust：推动使用翻译作为消除基于C系统的内存安全性漏洞的前瞻性方法。这种方法甚至引起了美国国防部a 的关注，因为他们长期以来依赖于老化的C系统，支持着运行多年的程序。近期的努力如Syzygy (Shetty等人, 2024)、C2SaferRust (Nitin等人, 2025) 和 AlphaTrans (Ibrahimzada等人, 2024) 展示了结合LLM与传统程序分析技术的混合方法的潜力。然而，一些显著的挑战依然存在，包括确保在大规模代码库中保持正确的属性，如速度、减少漏洞和惯用性。

ahttps://www.darpa.mil/news/2024/memory-safety-vulnerabilities

2.2.3 代码优化

将程序转换为提高性能特征的同时保持功能正确性是一个关键的软件任务。优化现实世界的系统带来了重大挑战，因为任务的规模大且逻辑复杂性高，必须识别性能瓶颈并提出新的算法来缓解它们。代码优化通常有

大量的搜索和解决方案空间，竞争目标包括速度、内存效率和可读性，例如在PTX级别优化GPU上的AI模型内核代码 (Zhao等人, 2025; Ouyang等人, 2024)。在许多情况下，高水平的自主性可能并不理想，因为权衡可能高度依赖外部因素，例如硬件，最佳优化可能最终影响可读性。

示例：Google Chrome性能改进：二十多年来，Chrome浏览器的变更一直是优化真实代码的典范 (Chromium, 2018)。他们的V8引擎通过多层次的协调优化实现了性能提升20倍，包括实现并发垃圾回收以减少膨胀100倍、开发专门的编译器TurboFan以提高5-10%的性能、启用背景解析和编译以减少编译时间20%。跨层和底层代码变更的需求（如编写新的JavaScript解释器）以及构建工具以测量和测试代表性性能指标是利用LLM在现实世界中产生影响的关键挑战。

2.3 软件测试与程序分析

在软件开发过程中，不可避免会出现bug。检测这些bug的难度取决于其规模和逻辑复杂性。对于LLM来说，轻微的拼写错误或正确性bug（小规模，低逻辑复杂性）更容易被发现 (Mosolyg ´o等人, 2021)，而复杂的并发bug和安全漏洞（大规模，高逻辑复杂性）则较为棘手，因为它们可能隐藏在调用栈深处，包含微妙的逻辑错误，或者由于大规模难以隔离 (Trent和Li, 2025)。

2.3.1 软件测试

软件测试是一种预防开发和生产中出现bug的实际方法。有几种流行的软件测试方法，有些短期，有些长期。单元测试是指使用输入输出风格的测试来验证一段代码的功能。基于属性的测试基于正式规范，依靠指定确保已知代码属性成立的测试用例。变异测试通过对程序进行细微修改，确保测试套件能检测到这些变异中的错误。模糊测试是指使用意外输入执行程序并监控异常，通常持续较长时间。

示例：OSS-Fuzz 在 FreeType 上的表现：OSS-Fuzz (Chang等人, 2024)，Google的自动化模糊测试基础设施，通过迅速发现关键软件中的安全漏洞证明了其价值。例如，当FreeType——一个部署在超过十亿台设备上的字体渲染库——最近的源码更改后，OSS-Fuzz在数小时内检测到了堆缓冲区溢出：

错误: AddressSanitizer: 堆缓冲区溢出，地址为0x615000000ffa
READ大小为2，地址为0x615000000ffa，线程T0
SCARINESS: 24 (2字节读取堆缓冲区溢出，远离边界)
#0 0x885e06 in tt_face_vary_cvtsrc/truetype/ttgxvar.c:1556:31

软件测试的目标是设计能够可靠暴露bug的测试。这通过诸如代码覆盖率等指标进行评估——运行测试套件时执行了多少源代码。另一种方法是变异分数，其中生成变异体，分数定义为导致套件失败的变异体百分比。虽然实用，但软件测试面临着传统工具的可扩展性限制和手动设计具有良好覆盖范围的测试的困难。随着LLM在编码方面的不断进步，它们为自动生成高质量测试提供了有前途的方向。

Meta中的故障导向测试生成示例：Meta的Automated Compliance Hardening (ACH)系统 (Foster等人, 2025) 是一个旨在捕捉现实世界bug的测试生成系统。ACH分三步工作：首先，工程师描述他们担心的bug。其次，ACH结合LLM与变异测试生成带有这些bug的代码。最后，这些变异体被用来开发捕捉它们的单元测试。ACH用于Messenger和WhatsApp的测试生成，工程师接受了其测试的73%。

2.3.2 程序分析

虽然测试可以捕获bug，但最具挑战性的软件问题是安全漏洞和零日攻击，从内存损坏到权限升级。这需要深入的程序理解，这是测试/模糊测试经常遗漏的。例如，零日漏洞是软件开发者未知的漏洞，由攻击者发现，供应商没有可用的补丁。在这种情况下，唯一可行的方法是进攻性安全研究、人工源代码审计和先前漏洞的根本原因分析以强化代码库。

示例：变体分析：Google的Project Zero (Hawkes, 2019) 的调查揭示了许多野外零日漏洞并非全新——它们通常是之前修补过的漏洞的变体。在他们对最近零日报告的分析中，近一半的问题与早期漏洞密切相关（如影响Windows win32k和iOS IOMobileFrameBuffer的问题）。这一发现强调了进行严格根本原因和变体分析的重要性。不仅仅是修复单一的漏洞路径，安全团队必须全面解决底层漏洞类别，确保关闭所有可能的利用路径——使得这项任务更具挑战性。

另一个有价值的但具有挑战性的分析例子是不变量检测。程序不变量是指无论输入是什么，某段代码在指定程序点处总是为真的属性。一个简单的例子是，执行int x = c * c;之后，x 必须是非负的。在测试、调试和修改代码时，识别不变量是非常有用的。这项任务可能具有挑战性，因为它需要抽象地推理代码执行，考虑许多潜在输入和执行路径，以确定所有可能输入都必须满足的属性。

2.3.3 程序修复

定位bug是程序修复中的一个重要挑战，因为准确定位bug的确切位置可能很困难，尤其是在大规模代码库中。一旦定位到bug，下一步就是修复它。LLMs非常适合这项任务，因为它们在训练过程中接触过各种类型的bug。函数级、低逻辑复杂性的bug可以通过向模型反馈错误信息轻松修复。然而，在更大范围内（如仓库）进行修复，尤其是代码具有更高逻辑复杂性时，可能需要多个步骤，包括设计和实现新算法或跨多个文件进行复杂的重构。

2.4 软件维护

2.4.1 代码文档和总结

为了确保代码的可维护性、可读性和易于协作，代码必须有良好的文档。好的文档需要清晰简洁地撰写，描述函数的作用和工作方式。它还应预测并解决程序员可能存在的任何误解，如潜在的副作用或特殊情况。人类通常将文档视为一种负担并忽视它，导致代码和文档经常不同步。这促使了“自我说明代码”的概念，即清楚传达其目的的代码。由于文档通常是一个逻辑复杂性低且不需要太多人为干预的任务，LLMs可以帮助确保文档是一个与代码同步更新的连续产物。

2.4.2 拉取请求（PR）审查

审查拉取请求是软件开发生命周期中的一个重要方面。虽然PR最基本的要求是正确实现新功能，其他重要考虑因素包括检查是否满足代码库的样式约定、确保PR不引入新bug、验证程序不变性和保证仍然成立以及检查测试是否稳健。一般来说，审查PR是一个逻辑复杂性低且可以相对容易自动化的任务。

2.4.3 代码理解、导航和问答

首次接触一个代码库时，开发者经常会发现很难理解和建立良好的代码心理模型。这可能是由于多种原因：过多的包装函数、过多的错误处理样板代码、深调用栈或代码不够干净。代码理解中的一个重要挑战是代码导航：找到相关功能的实现位置。要做好这一点，需要理解代码库中每个功能的高层布局和实现每个功能所使用的辅助函数的低层理解。

另一个挑战是代码问答：回答有关代码库的复杂问题，这需要强大的代码理解和推理能力。模型不应产生幻觉或给出歪曲开发者代码心理模型的不正确信息。超出本节提到的其他任务，开发人员可能经常询问与数据流（何时何地数据结构发生变化）、代码功能（是否有任何副作用）、性能特征（确定函数的运行时间和内存复杂度）或错误处理（是否处理了某些边缘情况）相关的问题。

2.5 支架和元代码

为了让软件系统正常工作，核心逻辑必须编写得很好，但这还不够。许多基础架构方面必须到位以支持软件。我们将这些分为两类：支架和元代码。我们定义支架为在代码之外必须完成的任务，以使软件正常运行。支架的例子包括设置Google身份验证、订阅API、管理文件存储和生成API令牌。相比之下，我们定义元代码为对系统工作至关重要的代码，但它不参与主逻辑的执行。元代码的例子包括测试框架、配置文件、CI/CD代码、Makefiles、Dockerfiles、沙盒数据库和预处理器。支架和元代码通常规模较小且逻辑复杂性低，但需要大量的应用领域知识，因此需要人类干预。

示例：配置验证：Ciri (Lian等人, 2024) 是一种使用LLM对开源项目（包括Django、PostgreSQL和Redis）进行配置验证的工具。他们发现，虽然Ciri在检测语法和范围违规方面表现出色，但在检测依赖和版本违规方面却遇到了困难，局限于少量的配置错误。他们还发现LLM偏向更受欢迎的配置参数，这可能导致在领域外场景下的幻觉。

基础设施即代码和安全：一个特别具有挑战性的情况是生成基础设施即代码，例如Terraform，您可以在其中以代码的形式指定基础设施规范（如AWS EC2实例、Kubernetes集群、S3桶、VPC桶），然后执行以创建基础设施。在生成此类代码时，LLM在安全配置方面存在困难，因为服务级权限（例如，AWS资源访问）、资源级权限（例如，特定允许的操作）和提供商特定的安全原语（如IAM角色、安全组和网络访问控制）之间存在复杂的交互。

示例：区分集群设置中的权限级别：Terrateam (2024) 显示，在启动集群的任务中，模型无法区分ECS（Amazon Elastic Container Service）任务执行角色（用于容器操作）和任务角色（用于应用程序级权限）。这导致了过度宽松的策略，其中单个角色被授予图像拉取权限和DynamoDB表访问权限，违反了最小特权原则。

2.6 形式化验证

形式化验证任务涉及生成可检查的机械化证明，以确保一段代码按预期工作。有两种主要的形式化验证类别：完整功能性验证（FFV）和属性验证（PV）。在FFV中，目标是设计一个完整且精确的形式规范，捕捉实现所需的行为，例如完全验证的数据结构（可变列表、树、图、哈希表）(Zee等人, 2008)。完整功能性验证的主要挑战在于正确编写规范，以便涵盖所有期望的属性。FFV通常具有较大的范围和中等的逻辑复杂性，因为一旦找到正确的抽象，待验证的属性往往很容易写出。

虽然FFV提供了完整的—— 保证，但通常选择PV就足够了，其中只证明系统的一些关键属性。属性验证的例子包括：确保两个线程不会同时进入程序的关键部分；验证复杂程序总会终止；证明不存在像缓冲区溢出这样的安全漏洞；保证内存安全。一个使 用属性验证变得困难的实际问题是假阳性的存在：功能正确的代码通常无法通过属性检查。一个典型的例子是Rust：尽管其强大的类型系统强制执行了许多期望的保证，但语义正确的代码往往无法通过类型检查。另一个挑战 ——是许多独立的属性验证工具往往依赖于特定的语言语义，这使得它们在语言语义发生变化时难以维护。

示例：高昂的灾难成本：在关键任务应用中，如飞机软件，形式化验证非常重要，因为软件漏洞可能会导致昂贵的灾难。例如，在Ariane 5火箭的首次飞行中，浮点数转换错误导致火箭在升空后40秒爆炸。另一个案例是计算机控制的放射治疗机Therac-25，其中并发漏洞导致六人受到严重过量辐射，造成严重伤害和死亡。

示例：已验证编译器：CompCert (Leroy等人, 2016) 是一个正式验证的优化C编译器，支持ISO C 99语言的大部分受限子集。CompCert使用Coq证明助手进行了正式验证 (Coq Development Team, 2024)，消除了编译器漏洞的可能性。

尽管形式化验证工具已经开始在工业界得到采用，但由于这些挑战，它们尚未成为主流。代码LLM可以大大减轻这一负担，并使更大规模的代码验证变得更加可行，特别是对于逻辑复杂性较低的属性验证。

示例：属性验证：Coverity：Coverity是一个静态分析工具，旨在发现通用错误（内存损坏、数据竞争）和系统特定违规（例如函数顺序约束）。在他们的报告 (Bessey等人, 2010) 中，他们突出了两个之前提到的问题：变更和假阳性。第一个问题，变更，涉及确保工具在代码库修改或不同版本的工具之间产生相同的结果，使得升级“不断头痛”。第二个问题是，当假阳性率超过30%时，用户会忽略该工具，而真正的漏洞则被淹没在这些假阳性之中。

4 前进路径

4.1 数据收集

在开源社区开发AI用于SWE的一个瓶颈是缺乏对细粒度和高质量代码数据的访问。在第4.1.1节中，我们讨论了如何通过增强现有程序的符号信息和生成带有符号验证器的合成数据来缓解这一问题的自动化技术。然而，编程中的其他关键信号可能很难自动化。我们设想，大规模基于社区的编码数据整理工作将非常有影响力。在第4.1.2节中，我们讨论了这样一个社区可以创建的数据集示例，这些数据集将解锁代码LLM的新能力。

解决的挑战：3.1, 3.3, 3.6

4.1.1 自动数据整理

为程序添加数据以增强LLMs的世界模型：让LLMs开发出代码的世界模型的一个挑战是程序通常被视为文本：作为没有语义信息的标记。然而，现代编程工具允许我们提取丰富的语义和结构化信息关于代码。通过利用这些工具，我们可以为训练数据集增加详细的注释，描述程序的各种属性。我们推测这种增强将显著提高模型对代码的理解，从而带来更好的泛化能力和更强的编码能力。信息可以包括：

• 静态分析：程序的语法结构（抽象语法树、控制流图）、变量类型的详细信息、数据流分析（可达性、活动性分析）
• 程序工具化：内存消耗、运行时分析、别名、代码覆盖率（如语句或分支覆盖率）
• 动态分析：程序在不同点的状态、调用栈、动态生成的属性（通常依赖于工具化）
• 形式化验证：并发分析、程序不变量、循环不变量、内存安全性
  文献中有几个这样的例子：Ouyang等人 (2024) 利用性能分析反馈改进GPU内核生成；Ding等人 (2024c,b); Ni等人 (2024) 引入执行跟踪信息；Pei等人 (2023) 使用程序不变量进行训练；GraphCodeBERT (Guo等人, 2020) 引入数据流信息；Shypula等人 (2023) 在性能改进编辑的数据集上进行训练。
  高质量、可验证的合成数据：代码的优势在于可以通过测试用例、程序执行引擎和其他符号工具实现强大且可验证的反馈。这使得高质量的合成数据生成可行，因为可以生成大量的
  数据并过滤掉低质量样本。例如，为了生成具有有趣程序不变量的代码，我们可以生成大量程序，运行不变量检测引擎，并保留只有那些具有有趣不变量的程序。虽然合成数据主要集中在函数级范围内，但在扩展到更大范围时并没有根本性的瓶颈。由于代码相当组合性强，各个构建块可以结合在一起生成复杂的合成数据在存储库级范围内，这对训练和评估都非常有帮助。
  在DSLs中，程序可以用语义和重写规则清晰描述，因此可以通过采样生成具有所需属性的程序，借助程序综合中的枚举技术 (Gulwani等人, 2017)。这种方法已在诸如ARC-AGI (Li等人, 2024d) 和数学奥林匹克问题 (Trinh等人, 2024); Google, 2024; Chervonyi等人, 2025) 的难题中取得了显著进展。
  4.1.2 以人为中心的数据整理
  下面，我们列出了三种对下一代编码LLM极具价值的人工标注数据类别。
  细粒度的开发过程数据：许多代码LM是在像 Stack (Kocetkov等人, 2022); (Lozhkov等人, 2024) 这样的数据集上训练的，这些数据集由GitHub上的数万亿个标记组成。然而，仅在原始GitHub标记上训练会遗漏软件开发过程中许多关键的人类信号。例如，像Google这样的公司依赖内部捕获的高质量SWE数据日志。这包括“细粒度代码编辑、构建结果、解决构建问题的编辑、代码复制粘贴操作、修复粘贴的代码、代码审查、修复评审问题的编辑以及向存储库提交更改”(Chandra, 2024)。同样，Meta和GitHub Copilot使用其AI编码助手的遥测技术来跟踪和利用AI生成代码的信号 (Murali等人, 2024; Ziegler等人, 2024)。这些工具，加上像Cursor这样的编码IDE，可以为基于RL的方法提供丰富的奖励数据。通过直接访问整个代码库的历史和演变，它们可以跟踪哪些建议随着时间被采纳。然而，从人类使用中收集数据也会引发关键的隐私和知识产权问题。
  多样化的SWE任务数据：如今大多数代码LLM训练方法仍然主要集中在代码生成上，因为大规模数据集大多是以连续的标记化格式存在的。然而，正如在第2节所述，软件工程中有许多模型缺乏暴露的任务。在更广泛的范围内进行训练将激励模型学习超越单纯生成的程序的一般能力（例如更好地理解程序语义）。初步证据表明，Li等人 (2025a) 发现，在输入输出预测数据上训练模型可以一致地提高推理任务的表现。
  这些任务缺乏高质量数据，使得训练变得困难。自动整理这些数据在GitHub上也可能很困难。例如，对于代码重构（第2.2.1节），我们需要
  重构前后的配对仓库，理想情况下还应附带重构更改的描述。虽然一些信号如提交消息和版本发布可以使用，但许多仓库缺乏干净的提交历史，版本发布经常混淆多个特性。因此，为了解决这个问题，我们设想需要大规模的社区努力来整理这些多样化任务的具体数据。
  以人为中心的数据：代码LLM通常是在精心整理的数据集上进行训练和评估，这些数据集包含明确的指令和可验证的测试用例。然而，正如在第3.3节中讨论的那样，这些模型通常部署在现实场景中，用户在查询中提供了模糊的规范或不完整的条件。收集以人为中心的数据反映真实世界模型使用情况是一种有希望的方法，可以在模型开发和部署之间架起桥梁。最近的努力，如Copilot Arena (Chi等人, 2025) 和 WebDev Arena, 已经探索了通过游戏化平台收集人类偏好的数据，提供了一种替代精心策划的数据集的方法。然而，这种数据收集方法可能会引入噪声，而且竞技场风格的方法不太适合长期的交互任务。一种潜在的方法是利用现有的编码工具和环境，例如为GitHub Copilot (Bajpai等人, 2024) 或开源IDE开发插件，以捕捉真实世界的互动。与静态数据集不同，以人为中心的数据还可以包括各种互动模式，例如用户为AI编码系统提供草图进行Web开发 (Li等人, 2024c)。随着AI编码系统的不断涌现和进化，启动聚焦于以人为中心的SWE数据的数据倡议也是推进软件开发中人机协作的重要方向。
  4.2 训练
  4.2.1 针对代码RL的环境设计
  通过可验证奖励进行强化学习 (RLVR) (Lambert等人, 2025) 已经成为数学和编码领域中的一种强大范式，模型输出可以通过与真实结果对比进行评估，例如完全匹配和通过一系列单元测试。在这个方向上，有前途的途径包括收集可执行代码库环境、从GitHub获取任务提示/奖励，以及基于程序语法和语义设计非执行奖励。
  解决的挑战：3.4,3.9
  收集可执行代码库：在最近几个月，RLVR在算法编程问题上的成功通过DeepSeek-R1 (DeepSeek-AI等人, 2025) 和OpenAI o1得以体现。最近，在SWE-Bench上，SWE-RL (Wei等人, 2025) 使用基于规则的奖励来提升SWE-Bench的表现。我们认为继续扩大RL方法至从现实世界软件工程存储库中收集的问题是有前景的。为此，我们相信收集执行辅助的类似gym的强化学习环境将进一步提升表现。这些环境可用于进一步提升推理技能、环境交互能力和工具使用。
  若干先前的工作 (Jain等人, 2024c; Pan等人, 2024; Guo等人, 2025; Xie等人, 2025) 通过支持CI/启发式存储库安装来整理可执行环境。然而，这些工作的规模相对较小，范围有限，仅提供来自最多千个存储库的数千个任务，更重要的是，局限于Python语言。大幅扩展这一规模需要解决若干研究和工程问题。首先，即使使用CI，安装任意GitHub存储库也颇具挑战性，我们需要更智能的解决方案，可能涉及基于LLM的安装代理。其次，设置执行基础设施需要将已安装的存储库镜像存储在类似于Docker的东西中，以便高效存储和快速容器启动时间 (Team等人, 2025)。值得注意的是，组合的Docker镜像可能会变得非常庞大，即使在几百个存储库的适度规模下，也可能会增长到数百GB。这需要工程支持以高效存储和提供此类镜像。
  任务提示和奖励来源：除了环境，进行大规模强化学习还需要收集多样的具有挑战性的问题，并以适当的方式计算奖励。这些问题提示可以从GitHub (Pan等人, 2024) 收集或从GitHub上的问题合成生成。此外，假设可以获得许多可执行存储库，我们可以为超出bug修复的任务（如优化、模糊测试等）提供端到端问题源。访问预先存在的或生成的测试用例可以用来衡量正确性并提供奖励。
  然而，我们预计仍有许多实际挑战。例如，长跨度任务通常更模糊，方法可能需要多轮交互而非自主编码代理。这在强化学习过程中提出了重大挑战，其中模糊性的解决可能需要建模。我们在第4.2.3节中进一步讨论了人类协作。奖励欺骗 Skalse等人 (2022) 是另一个挑战，当我们建立更多现实世界编码挑战时。测试用例常常因覆盖不足而将正确解误判为错误解。例如，Baker等人 (2025); Denison等人 (2024) 发现，模型在使用强化学习优化时试图绕过或欺骗测试框架。
  无需执行的奖励：由于设置执行环境可能导致相当大的开销，另一种潜在策略是使用代理指标和训练好的语言模型来判断正确性。这在预LLM时代很常见，研究人员通常使用BLEU/Code-BLEU (Papineni等人, 2002; Ren等人, 2020) 和BERTScore/CodeBERTScore (Zhang等人, 2019; Zhou等人, 2023) 来评估文本和代码的正确性。在代码中，语义和结构属性可以用来改进相似性度量。这两个例子是Dolos (Maertens等人, 2022)，一个AST感知的抄袭检测器，和difflib.SequenceMatcher，它可以用来计算两个补丁之间的相似性 (Wei等人, 2025; Ma等人, 2025b)。除了基于规则的奖励外，LLMs-as-a-judge方法也可以用作奖励函数，可能与其他基于执行或无执行的方法结合使用。
  4.2.2 适应专用和快速变化的代码库
  低资源语言（第3.7节）、自定义API、库版本更新（第3.8节）、大代码库（第3.5节）和自定义编码风格都表明代码LM在适应未见过的专用上下文方面存在困难。通过测试时训练或保持专用信息的信息库可以实现定制化。一种比测试时训练更便宜的替代方法是应用提示和前缀调整，根据上下文学习并应用代码库特定的嵌入。
  解决的挑战：3.7,3.8
  测试时训练 (TTT) 至自定义代码库：TTT是最近的一种范式，通过在分布内的实例上训练来适应特定问题 (Aky ¨urek等人, 2024; Sun等人, 2020)。这可以用于低资源环境中，例如在一个特定代码库、新领域或未见过的API上进行训练。在此设置中的一个挑战是在保持一般编码知识的同时定制模型以适应特定代码库，可能通过使用能够诱导可控遗忘的算法来实现 (Wu等人, 2024)。为了获得专业背景下的数据，我们设想两种缓解策略：生成合成数据和收集轨迹。分布内的合成数据可以大量生成，然后通过过滤和标注带有符号（如编译器）信息来获得对当前环境和设置的更全局的理解。为了收集代理轨迹，我们可以跟踪模型之前的尝试和失败，从中学习过去的成功经验并避免重复犯错。这将引导模型更接近所需的分布——例如，生成符合当前上下文中使用的指定版本库的代码。
  保持代码信息的信息库：对于库和版本问题，检索（第4.3.1节）在防止错误版本库的幻觉方面非常有效，这本质上可以带来更好的合成数据和代理轨迹。在TTT过程中，我们还可以维护一个不断增长的专门上下文中的代码、文档、合成代码和代理轨迹的大内存库。从内存库中检索信息将提高生成代码的成功率，然后可以将其增强到内存库中，如此循环，持续增加可用的数据和知识量。
  针对特定代码上下文的提示和前缀调整：每次库更新时都进行全量微调是非常昂贵的，因为在需要学习的知识量与预训练模型相比非常小的情况下，我们相信提示调整 (Lester等人, 2021) 和前缀调整 (Li和Liang, 2021) 就足够了。这两种方法都是通过在输入序列中附加一组学习到的任务特定向量来模拟指定的上下文，不过提示调整只修改输入，而前缀调整则在每一层修改输入。这些方法也被证明具有良好的OOD性能，我们相信它们为应对多个库版本提供了有前途的方向。每个版本都可以单独训练提示/前缀，然后根据上下文应用。当API有新更新时，提示/前缀可以廉价地重新调整以反映新更新，而无需进行全量微调。这种方法也适用于遵循特定编码风格，其中可以学习代码库特定的提示/前缀。
  即时学习：当人类面临从未见过的任务时，他们通常能够从过去的经验中吸取教训，并迅速适应和推广到新的领域。这是当今LLM面临的重大未解挑战之一：面对OOD编码任务时，模型如何快速跟上并在少量样本的情况下高效完成任务？在玩具领域，一个例子是DreamCoder (Ellis等人, 2021)，这是一个通过编写程序和自动发现领域概念及组合概念来解决问题的系统。为更实用的应用设计此类方法是一个令人兴奋的研究方向，它将在编码和推理方面产生深远的影响。
  4.2.3 训练代码LLM与人类协作
  训练下一代代码LLM需要考虑人机协作，因为这些模型很可能在模糊和交互场景中部署。我们强调两个关键方向来改进协作：首先，通过形式方法和用户指定测试学习利用超越自然语言的规范可以缓解模糊规范。其次，通过后训练改进不确定性量化和主动沟通，有可能防止幻觉和失调。
  解决的挑战：3.3
  学习利用超越自然语言的规范：如第3.3节所述，尽管自然语言提示为表达需求提供了直观和灵活的方式，但它们通常遭受模糊性和不完整性的困扰。一个解决此限制的方向是训练模型利用增强规范，这些规范具有更精确和可验证的表示形式，如形式规范和基于测试的规范。
  形式规范：为了缓解规范不足的问题，一个解决方案是开发能够将用户意图转化为形式规范的系统 (Szegedy, 2020; Endres等人, 2024)。虽然当前的自动形式化方法在准确捕捉用户意图方面面临挑战（见下方示例），但我们设想下一代系统将通过与人类反馈的交互验证逐步完善形式规范。这些系统将呈现易于理解的中间形式化内容，使非专家用户能够在代码生成之前验证正确性。
  示例：Verus中不完整的规范：这里展示了一个LLM在Verus中编写规格和证明时的失败模式。要求LLM为环形缓冲区队列函数编写确保后置条件条款。这里的后置条件是不完整的：例如，它没有检查环形缓冲区中原有的元素是否保持不变。
  fn enqueue(&mut self, val: T) -> (ret: bool)
  ensures
  ret == !old(self).is_full(),
  self.inv(),
  if ret { self.view() === old(self).view().push(val) } else { self.view() === old(self).
  ֒→ view() }
  {
  if self.is_full() {
  false
  } else {
  self.ring.set(self.tail, val);
  self.tail = (self.tail + 1) % self.ring.len();
  true
  }
  }
  a 完整示例在这里
  测试作为规范：另一种指定软件行为的方法是通过测试。这些范围从输入输出示例和断言到基于属性的测试。然而，在实践中，手工制作的测试套件往往是不完整的，未能捕捉到完整的预期行为，尤其是边缘情况。这会导致失调，即AI生成的代码通过了测试，但并未真正满足功能需求，可能误导用户。接下来的方向是训练模型根据用户的初始查询生成高质量的测试用例，以确保更全面的规范覆盖。
  示例：例如，在Sakana AI发布的AI CUDA Engineer的一个版本中，一个AI生成的CUDA内核用于矩阵乘法的下三角部分——据称实现了显著的速度提升——后来被发现利用越界内存访问来绕过正确性检查a。推动研究框架以促进测试生成和自动化对抗测试代表了一个重要的方向。
  a 全部LLM生成的内核代码可以在Lange等人 (2025) 第46-47页找到。
  学习量化不确定性并主动沟通：随着AI编码系统越来越多地应用于复杂的软件工程任务，它们遇到的模糊和不确定场景比传统的编码模型基准要多得多。理想情况下，在这种情况下，这些系统应该主动与用户沟通以澄清任务并承认自身的局限性，而不是陷入无休止的失败循环或生成有bug的代码。一个关键挑战是使模型能够区分明确和模糊的指令，同时以稳健的方式量化不确定性。早期研究表明，交互式的LLM可以通过寻求澄清的行为来提高性能，但当前模型在不确定性估计方面仍然存在困难。赋予模型量化不确定性的能力可能需要在后训练阶段纳入相应的推理数据。
  除了不确定性量化之外，Shao等人 (2024b) 指出沟通是人类代理协作中的主要挑战，强调了提高模型主动性沟通能力的需求。当前模型在用户输入模糊或不充分时往往无法提出有意义的问题，并在交互环境中难以提供进度更新或验证计划。增强模型的主动性沟通能力需要创新的方法来奖励跨多个步骤有益的行为。由于与用户的沟通不会立即解决手头的任务，但可能会改善长期结果，有效的策略必须在训练中考虑延迟奖励。
  示例：讨论帮助编码代理解决GitHub问题：在SWE-bench (Jimenez等人, 2024) pydata xarray-4750的问题描述中，原问题请求限制repr中显示的数据行数。虽然它建议最多显示25行，但并未具体说明这个数字是否可以配置——这是一个在问题讨论中出现的关键需求。当SWE-Agent (Yang等人, 2024b)（由GPT-4o驱动）仅使用问题描述作为问题陈述时，它生成了一个将最大值硬编码为25的函数，导致解决方案未能通过测试。然而，加入问题讨论后，代理能够生成一个正确的、通过测试的实现（参见列表 2)。这表明，使编码代理能够参与与用户的讨论可能会潜在地提高问题解决率。
  列表2：SWE-Agent在加入问题讨论后有所改进
  # 仅使用问题描述
  def _mapping_repr(mapping, title, summarizer, col_width=None):
  if col_width is None:
  col_width = _calculate_col_width(mapping)
  summary = [f"{title}:"]
  if not mapping:
  summary += [EMPTY_REPR]
  else:
  items = list(mapping.items())
  if len(items) > 25: # 显示前12项和最后12项
  first = items[:12]
  last = items[-12:]
  summary += [summarizer(k, v, col_width) for k, v in first]
  summary += [" ..."]
  summary += [summarizer(k, v, col_width) for k, v in last]
  else:
  summary += [summarizer(k, v, col_width) for k, v in items]
  return "\n".join(summary)
  # 使用问题描述和讨论
  def _mapping_repr(mapping, title, summarizer, col_width=None):
  col_width = _calculate_col_width(mapping)
  summary = [f"{title}:"]
  if mapping:
  items = list(mapping.items())
  if title == "Data variables" and len(items) > OPTIONS["display_max_rows"]:
  # 如果数据过多，显示前半部分和后半部分的变量
  first_n = OPTIONS["display_max_rows"] // 2
  last_n = OPTIONS["display_max_rows"] - first_n
  selected_items = items[:first_n] + [("...", "...")] + items[-last_n:]
  else:
  selected_items = items
  summary += [summarizer(k, v, col_width) if k != "..." else " ..."
  for k, v in selected_items]
  else:
  summary += [EMPTY_REPR]
  return "\n".join(summary)
  4.3 推理时间方法
  4.3.1 语义感知嵌入和检索
  与文本不同，代码的嵌入应结合执行和语义信息，从而改善检索。RAG受益于既定情境下的检索和显式训练如何使用这些检索，增强了跨语言和API的代码复用。
  解决的挑战：3.5
  语义和执行感知代码嵌入：在训练LLMs时，代码通常被视为纯标记（就像文本一样），而不是显式地结合代码特定信息，如 程序执行和语义。因此，嵌入空间中相近的代码更可能是语法相似而非语义相似 (Utpala等人, 2023; Zhao等人, 2023)，目前很少有可靠的方法来检索语义相似的代码。然而，在LLM时代之前，已有多种努力在训练嵌入时结合代码属性。例如，Nye等人 (2020) 训练神经模块以表示程序操作，导致复合程序表示能够编码底层编程语言的语义。许多其他工作 (Zohar和Wolf, 2018; Ellis等人, 2019; Chen等人, 2021b) 尝试学习部分和完整程序的执行感知潜在表示，考虑到语义。
  我们推测，将这些技术融入训练模型以获得更好、更语义感知的表示可能会导致对代码有更普遍理解的模型（参见第3.6节）。例如，如果正确的和有缺陷的程序可以在嵌入空间中分离，那么模型就可以被引导远离错误的程序空间。尽管这种清晰的分离可能不可行，但我们相信训练嵌入以具有有趣的语义属性是值得探索的。
  更好的检索增强代码生成：当检索增强语言模型首次推出时，它们通常依赖于联合训练检索器和语言模型，如FiD (Izacard和Grave, 2020)、RETRO (Borgeaud等人, 2022) 和Atlas (Izacard等人, 2023)。随着语言模型规模的增大，该领域转向黑盒设置 (Shi等人, 2023)，其中检索模块独立调整以适应预训练的黑盒LLM。这种设置更具成本效益，但语言模型并未明确训练如何利用其检索结果。
  黑盒设置非常适合低资源语言或特定上下文的挑战。在这种情况下，模型尚未看到足够的训练数据以完全掌握上下文，而挑战通常是语法而非算法方面的。例如，在适应需要特定API功能或代码样式的领域或代码库时，检索结果可以非常有指导意义。当使用具有多个版本的API时，提供正确版本的检索结果可以告知模型如何使用API。当用全新的语言编写代码时，展示for循环和while语句的例子可以教会模型这些构造的语法。检索结果应多样化并以多种形式给出，包括文档、所使用API的功能定义和目标函数的示例用法。
  在许多其他情况下，我们相信黑盒设置是不够的。正如在第3.5节中所述，有两个挑战：1）知道要检索什么和2）使用检索结果。第一个挑战依赖于检索相关示例，无论是语法上还是语义上。我们认为拥有更语义感知的嵌入将极大地改善这一点。例如，可以通过对比训练来最小化语义相似程序之间的距离。另一个潜在方向是考虑多样化的潜在检索结果，然后训练检索器优先选择有助于生成的样本，如Atlas (Izacard等人, 2023) 所示。
  第二个挑战，使用检索结果，是一项代码复用任务，需要复杂的推理和代码理解。检索结果提供的算法可能需要显著修改和调整以适应当前环境。例如，当检索到的是Java版本的最短路径算法时，模型可能需要编写C++版本的最短路径算法，这是一种模型可能未明确训练过的翻译任务。检索到的大量文档可能需要精确理解，以便正确使用超参数和标志。然而，在黑盒设置中，模型并未明确训练如何利用这些信息。因此，正如训练错误-正确代码对可以提高程序修复一样，我们认为直接训练对于代码复用和检索增强生成非常有益。执行信息也可能很有用，因为代码复用通常需要很好地理解检索代码和当前上下文之间的细微差别。
  通过代码导航即时检索：标准的检索增强方法保持一个包含数百万嵌入的大检索索引，这需要较高的一次性成本来创建。随着代码库的发展，这些嵌入可能也需要不断更新。另一种方法是通过即时导航代码库来查找检索结果。我们可以想象一个学会使用命令行功能（如cd、ls和grep）以及IDE功能（如跳转到函数定义或查找函数的所有引用）的代理。静态分析工具也可以与代理结合使用以改进代码导航，例如提供代码库的抽象语法树（AST）或文件结构。
  4.3.2 与SWE开发框架集成
  将AI与SWE开发框架集成对于实际应用和影响开发者工作流程至关重要。虽然软件开发本质上与工具、工作流程、支架和元代码集成，但这些在源代码和AI训练数据中通常很少见。确保AI深入了解软件部署而不只是代码编辑至关重要，因为编写代码只是开发周期的一小部分。这些可以包括自动化审查、部署风险评估和文档生成。我们还可以对LLM进行微调，以识别和避免已知的软件反模式。
  解决的挑战：3.4,3.5
  将AI整合到CI/CD过程中：在持续集成和持续部署（CI/CD）中，自动化流水线是构建、测试和部署代码变更的核心。CI/CD加速了反馈循环并尽量减少了集成问题。AI在CI/CD中提供了几个整合点。AI驱动的代码审查工具可以整合到CI管道中，自动识别并标记样式违规、潜在的安全漏洞和代码异味，然后再交给人类审查者。此外，AI可以提供智能的部署风险评估。通过分析代码变更、测试结果和历史部署数据，AI可以预测部署问题的可能性，从而为是否继续自动部署或强制手动验证步骤提供决策依据。最后，AI可以在CI/CD过程中通过总结提交消息、问题追踪器数据和相关的代码修改来自动化生成发布说明。
  避免软件反模式：在软件工程中，某些反模式经常导致bug。例如，常见的弱点枚举（CWE）是对经常导致漏洞的软硬件弱点进行分类。由于公开可用的GitHub代码通常包含反模式、bug和CWE漏洞，LLMs经常会写出易受这些问题影响的代码 (Asare等人, 2023; Fu等人, 2023)。我们推测，明确引导模型避开这些漏洞将有助于生成更安全和正确的代码。一种方法是收集大量违反每个CWE的程序样本（无论是合成的还是来自GitHub），然后在进一步的监督微调或强化学习阶段中使用这些样本作为负面信号。
  4.3.3 整合SWE工具
  软件工程师在编写代码时会整合各种特定领域的工具。通过以RL风格反复与工具互动，AI可以发展出类似的能力。除了工具使用之外，整合程序分析和类型检查等神经符号方法也可以增强LLM的能力。
  解决的挑战：3.2
  学习使用SWE工具：如第3.2节所述，我们认为SWE代理应该理解编程工具的复杂性，并能够根据需要自主调用它们。有三项技能需要学习：使用哪个工具、如何使用工具以及如何整合工具的结果。类似于模型学习玩复杂游戏的方式，我们相信智能工具集成可以通过以RL风格反复与工具互动来学习。我们设想如下方式：首先，工具接口必须精确指定。其次，应收集包含工具反复互动的数据（成功程度各异）。最后，可以通过多轮RL和专家迭代来改进对工具的理解并从误用中学习。
  有证据表明学习更高层次策略可能是可行的，例如通过测试时技术，OpenAI的o3模型学会了编写暴力解决方案以验证更复杂解决方案的正确性 (El-Kishky等人, 2025)。我们设想，在学会使用工具后，AI编码代理可以根据需要自主调用工具，以改善其对代码的整体世界模型，从而提升其软件工程能力。
  神经符号方法：代码是一个独特的领域，因为有大量的编程语言研究技术可供借鉴，但当前大多数AI代码研究并未利用代码的符号属性。其中一些PL技术包括以下内容：抽象解释 (Cousot和Cousot, 1977) 是一种计算程序状态的过度近似的技术，以便在代码中的某些点证明程序属性的健全性。符号测试 (Godefroid等人, 2005; Sen等人, 2005) 通过结合具体执行和符号执行来发现软件中的bug。模型检查 (Clarke, 1997) 是一种通过时间逻辑证明执行轨迹属性的方法。语法检查和类型检查 (Cardelli, 1996) 提供静态检查，以确保变量、表达式和函数符合编程语言规则。最后，许多其他利用这些工具设计的程序分析算法旨在防止bug并确保代码正确性属性。
  传统的PL方法有一些常见的缺点，这与第2.6节提到的一些问题重叠。首先，它们通常需要非常完整和精确的规范。许多工具需要为所有库函数提供规范，需要针对语言的特定版本进行专门化，并且需要针对构建系统进行专门化。其次，由于搜索空间大，通常会有很高的计算成本。第三，由于工具的限制，可能会有很多假阳性。我们认为将这些符号工具深度整合到LLMs中可以部分缓解这些挑战。
  我们提供了这种潜在整合的几个例子。在生成代码时，可以应用程序分析技术于较短的人工智能生成代码片段上，以揭示潜在的bug或证明生成代码的属性。为了提高对代码的一般理解，LLMs可以训练关于程序结构的信息，例如抽象语法树 (Gong等人, 2024)。在调试大型代码库时，如果规模太大无法直接应用PL技术，AI可以首先用于缩小可能有问题的部分，然后再交给PL工具进行调试。在DSL中的代码生成过程中，LLMs可以利用编程语言的语法来进行约束解码 (Poesia等人, 2022; Geng等人, 2023; Wei等人, 2023b)，以减轻语法错误。在代码重构过程中，可以使用抽象解释和静态分析来识别是否引入了新错误，并提前切断不具前景的搜索路径。
  演绎综合与中间语言：早期程序综合依赖于 演绎综合 方法 (Burstall和Darlington, 1977)，程序员会先写出一个简单干净的实现，然后应用转换规则将其转化为更高效的实现。演绎方法的优点在于这些重写规则保持语义不变，因此具有构造上的正确性保证。演绎综合的一个成功案例是Spiral (Puschel等人, 2005)，这是一种用于信号处理内核的DSL，它利用领域特定的转换规则生成超越专家手工优化代码的实现。另一个例子是Halide (Ragan-Kelley等人, 2013)，这是一种用于高性能图像和数组处理代码的DSL。由于编写优化代码的难度，人们通常选择在这些中间DSL中编写代码，我们发现这对于LLMs来说也很有前途。
  示例：LLM辅助的张量加速器编译：作为一个例子，Hong等人 (2024) 考虑从高级计算规范（例如C++代码）生成高度优化和硬件高效的张量加速器代码的任务。他们的流水线分为两个步骤：首先，将高级规范翻译为DSL；然后，使用成本模型驱动的搜索对DSL代码进行优化，并提出保证语义等价的重写和调度操作（例如循环重新排序）。
  4.3.4 架构人类监督
  在推理时间，大多数机器生成的代码将以由人机界面设计决定的格式呈现给人类。由于AI可能负责生成人类-AI团队中大部分代码，因此确保人类控制和监督非常重要。通过总结和交互验证来架构人类监督，我们可以潜在地提高对AI生成代码的信任。
  解决的挑战：3.3
  一旦代码LLM被部署用于推理，确保对AI生成代码的人类监督至关重要。这不仅是为了增强AI生成代码的准确性，因为人类常常仍然需要做出最终决定，或者理解代码以便未来集成和维护。一项关于Github Copilot使用的研究表明，程序员倾向于减少对AI生成代码的视觉关注(Al Madi, 2023)。虽然一种解决方案是训练人类更好地识别AI生成代码中的问题 (Singhal和Kumar, 2023)，但
  更为理想的方案是设计能够架构人类监督的AI系统，从而减少他们在审查生成代码时的认知负担。
  实现这一目标的一种方法是通过增加额外的上下文信息来丰富AI生成的内容。现代LLM聊天机器人现在经常生成带有引用的知识密集型查询文本。在协作STORM (Jiang等人, 2024) 中，研究人员展示了动态呈现分层“思维导图”显著增强了人机协作，特别是在长时间会议中。在软件工程方面，Sun等人 (2024b) 强调了高质量源代码摘要在帮助软件开发人员理解和维护机器生成代码中的好处。其次，交互方法也可以增强监督。一个例子是 实时编程 (Ferdowsi等人, 2024)，即通过连续显示程序运行时值的方式来降低验证AI生成代码的成本。然而，这些现有研究大多局限于特定编程语言和小型代码库。最后，提高AI生成代码本身的可读性和可解释性也提供了一个有希望的方向。例如，Pu等人 (2020) 表明，将程序综合建模为理性沟通可以提高最终用户的解释和后续沟通代码的能力。基于这些想法，未来的研究所应优先考虑在设计和优化AI编码系统时强调人类可解释性，从而促进在AI辅助软件开发中建立更大的信任和控制。
  5 局限性
  我们指出了以下一些局限性：
  未来工作的推测性质：我们在未来工作部分列出的想法是我们认为有很大成功机会的意见方向。许多观点来源于文献中的相关工作，但缺乏强有力和具体的证据。我们鼓励进一步的研究来验证或反驳这些想法的有效性。
  未来工作范围有限：我们也未包含任何新颖的突破性想法，而且我们提出的许多方向都源于现有的代码LLM文献。我们的未来工作部分也比较通用，整体适用于代码AI。然而，该领域有许多任务和挑战可以从使用领域特定知识和见解中受益，而我们未涉及这些方面。最后，本文主要由学术界人士撰写，他们可能不了解前沿工业实验室所采用的最新方法的细节。我们将文章重点放在我们更有专长的领域，因此省略了许多有希望的方向，如新颖的架构。
  专注于代码特定挑战：在本文中，我们主要关注代码特定的挑战和技术。然而，有许多技术适用于一般的LLM推理和开发，可以直接应用于代码。我们相信，许多这些方法可以与代码特定技术协同使用。
  领域快速变化的性质：LLM用于软件工程的领域正在迅速发展，每周都有新的创新发布。几个月后阅读本文的读者可能会发现，文中提到的许多挑战已经部分或完全解决。
  6 结论
  在这篇立场论文中，我们确定了AI在软件工程中的关键任务以及一组三个衡量标准来分类这些任务的不同实现。我们还突出了贯穿许多任务的关键交叉挑战。最后，为了推动代码AI的发展，我们指出了缓解这些挑战并推进AI成为更胜任的软件工程师的一系列令人兴奋和有希望的研究方向。我们希望这项工作能提供关于当前AI在软件工程领域的宝贵见解，并鼓励未来在这些方向上的研究。通过建立在这些见解之上，我们乐观地认为社区可以朝着开发更好的支持现实世界场景下软件工程师的AI驱动解决方案迈进。
  7 致谢
  我们感谢Alex Polozov、Baptiste Roziere、Daya Guo、Jenny Liang、Jiawei Liu、Justin Chiu、Kexun Zhang、Leonardo Hernandez Cano、Li Zhong、Michael Wang、Silas Alberti、Theo Olausson、Valerie Chen、Xingyao Wang、Yangruibo Ding、Yuxiang Wei、Zhiruo Wang和多位匿名研讨会评审员在草稿不同阶段提供的宝贵反馈。
  我们还要感谢以下人士在本文中提到的说明性示例：Silas Alberti（调试云应用程序）、Chuyue Sun（Verus中的不完整规范）、MIT的6.172课程（性能工具化）、Theo Olausson（昂贵的灾难）、Songlin Yang（Triton中的语法错误）。
  A. Gu受到美国国家科学基金会（NSF）研究生研究奖学金资助，编号2141064。N. Jain受到NSF资助CCF:1900968、CCF:1908870以及SKY Lab工业赞助商和附属机构的支持。A. Solar-Lezama受到NSF和Intel Corporation通过NSF资助CCF:2217064的支持。D. Yang受到ONR YIP奖N000142412532的支持。
  参考文献
• Pranjal Aggarwal, Bryan Parno 和 Sean Welleck. Alphaverus：通过自我改进的翻译和细化引导正式验证代码生成。arXiv预印本 arXiv:2412.06176, 2024. (第76页引用)
• Lakshya A Agrawal, Aditya Kanade, Navin Goyal, Shuvendu K Lahiri 和 Sriram K Rajamani. 使用监控器通过全局上下文引导代码中的语言模型。arXiv预印本 arXiv:2306.10763, 2023. URL https://arxiv.org/abs/2306.10763. (第70页引用)
• Toufique Ahmed, Christian Bird, Premkumar Devanbu 和 Saikat Chakraborty. 研究LLM在闭源和开源数据上的表现。arXiv预印本 arXiv:2402.15100, 2024a. (第22页引用)
• Toufique Ahmed, Kunal Suresh Pai, Premkumar Devanbu 和 Earl Barr. 自动语义增强语言模型提示（用于代码摘要）。在 IEEE/ACM第46届国际软件工程会议论文集, 第1–13页, 2024b. (第74页引用)
• Ekin Aky ¨urek, Mehul Damani, Linlu Qiu, Han Guo, Yoon Kim 和 Jacob Andreas. 测试时训练在抽象推理中的惊人有效性，2024。URL https://arxiv.org/abs/2411.07279。(第[32页引用)]
• Naser Al Madi. 模型生成的代码有多可读？检查GitHub Copilot的代码可读性和视觉检查。在 第37届IEEE/ACM自动化软件工程国际会议论文集, ASE ’22, New York, NY, USA, 2023。Association for Computing Machinery出版。ISBN 9781450394758。doi: 10.1145/3551349.3560438。URL https://doi.org/10.1145/3551349.3560438。（第[39页引用]）
• Reem Aleithan, Haoran Xue, Mohammad Mahdi Mohajer, Elijah Nnorom, Gias Uddin 和 Song Wang. Swe-bench+: 针对LLM的增强编码基准。arXiv预印本 arXiv:2410.06992, 2024.（第[14页引用]）
• Anthropic. 在Claude 3.5 sonnet验证下提升Swe-bench的标准。2024.（第[15页引用]）
• Owura Asare, Meiyappan Nagappan 和 N Asokan. GitHub的Copilot在代码中引入漏洞的能力是否像人类一样糟糕？经验软件工程, 28(6):129, 2023.（第[37页引用]）
• Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le 等人. 使用大规模语言模型进行程序综合。arXiv预印本 arXiv:2108.07732, 2021.（第4, [70页引用]）
• Pavel Avgustinov, Oege de Moor, Michael Jones Peyton 和 Max Schafer. QL: 关系数据上的面向对象查询。ECOOP, 2016.（第[74页引用]）
• Ramakrishna Bairi, Atharv Sonwane, Aditya Kanade, Arun Iyer, Suresh Parthasarathy, Sriram Rajamani, B Ashok 和 Shashank Shet. Codeplan: 使用LLM和规划进行存储库级别的编码。ACM软件工程学报, 1(FSE):675–698, 2024.（第[15页引用]）
• Yasharth Bajpai, Bhavya Chopra, Param Biyani, Cagri Aslan, Dustin Coleman, Sumit Gulwani, Chris Parnin, Arjun Radhakrishna 和 Gustavo Soares. 让我们一起修复这个问题：GitHub Copilot的对话式调试。在 2024 IEEE可视化语言和以人为中心计算研讨会 (VL/HCC)，第1–12页。IEEE, 2024.（第[30页引用]）
• Bowen Baker, Joost Huizinga, Leo Gao, Zehao Dou, Melody Y Guan, Aleksander Madry, Wojciech Zaremba, Jakub Pachocki 和 David Farhi. 监督推理模型的行为并评估促进混淆的风险。arXiv预印本 arXiv:2503.11926, 2025.（第[31页引用]）
• Ola Benderius, Christian Berger 和 Victor Malmsten Lundgren. 2016年合作驾驶挑战赛中最佳评分的人机界面设计。IEEE智能交通系统汇刊, 19(4):1302–1307, 2017.（第[18页引用]）
• Ian Berlot-Attwell, Frank Rudzicz 和 Xujie Si. 库学习并不：单次使用”库”的奇怪案例。arXiv预印本 arXiv:2410.20274, 2024.（第[19页引用]）
• Al Bessey, Ken Block, Ben Chelf, Andy Chou, Bryan Fulton, Seth Hallem, Charles Henri-Gros, Asya Kamsky, Scott McPeak 和 Dawson Engler. 数十亿行代码之后：使用静态分析在现实中发现bug。ACM通讯, 53(2):66–75, 2010.（第[13页引用]）
• Dirk Beyer. 软件验证和见证验证竞赛：SV-COMP 2023。在 工具和算法构造与分析国际会议：第29届国际会议，TACAS2023，欧洲联合软件理论与实践会议的一部分，ETAPS2023，巴黎，法国，2023年4月22日至27日，会议记录，第二部分, 第495–522页，柏林，海德堡，2023。Springer-Verlag出版。ISBN 978-3-031-30819-2.（第[76页引用]）
• Dirk Beyer 和 Alexander K. Petrenko. Linux驱动程序验证。在 第五届形式方法应用国际会议论文集：应用和案例研究卷II, ISoLA’12, 第1–6页，柏林，海德尔堡，2012。Springer-Verlag出版。ISBN 9783642340314。（第[76页引用]）
• Manish Bhatt, Sahana Chennabasappa, Cyrus Nikolaidis, Shengye Wan, Ivan Evtimov, Dominik Gabi, Daniel Song, Faizan Ahmad, Cornelius Aschermann, Lorenzo Fontana, Sasha Frolov, Ravi Prakash Giri, Dhaval Kapil, Yiannis Kozyrakis, David LeBlanc, James Milazzo, Aleksandar Straumann, Gabriel Synnaeve, Varun Vontimitta, Spencer Whitman 和 Joshua Saxe. Purple Llama CyberSecEval: 面向语言模型的安全编码基准，2023。URL https://arxiv.org/abs/2312.04724。（第[71页引用]）
• Google BigSleep. 从午睡到大睡眠：使用大规模语言模型捕捉真实代码中的漏洞。2024。URL https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html。（第15, [73页引用]）
• Andrew Blinn, Xiang Li, June Hyung Kim 和 Cyrus Omar. 使用类型孔洞静态上下文化的大规模语言模型。ACM编程语言学报, 8(OOPSLA2): 468–498, 2024.（第[22页引用]）
• Sebastian Borgeaud, Arthur Mensch, Jordan Hoffmann, Trevor Cai, Eliza Rutherford, Katie Millican, George Bm Van Den Driessche, Jean-Baptiste Lespiau, Bogdan Damoc, Aidan Clark 等人. 通过检索数万亿个标记改进语言模型。在 国际机器学习会议论文集, 第2206–2240页。PMLR, 2022.（第[36页引用]）
• Islem Bouzenia 和 Michael Pradel. 名称任意，我执行：一种用于任意项目测试的语言模型代理，2024。URL https://arxiv.org/abs/2412.10133。（第[75页引用]）
• Islem Bouzenia, Premkumar Devanbu 和 Michael Pradel. RepairAgent: 一种自主的基于LLM的程序修复代理。arXiv预印本 arXiv:2403.17134, 2024.（第74, [75页引用]）
• Matthew Bowers, Theo X. Olausson, Lionel Wong, Gabriel Grand, Joshua B. Tenenbaum, Kevin Ellis 和 Armando Solar-Lezama. 自顶向下综合以学习库。ACM程序语言学报, 7(POPL), January 2023. doi: 10.1145/3571234. URL https://doi.org/10.1145/3571234.（第[18页引用]）
• Rod M Burstall 和 John Darlington. 发展递归程序的变换系统。ACM杂志 (JACM), 24(1):44–67, 1977.（第[39页引用]）
• Jialun Cao, Zhiyong Chen, Jiarong Wu, Shing chi Cheung 和 Chang Xu. JavaBench: 评估大规模语言模型的对象导向代码生成基准，2024。URL https://arxiv.org/abs/2406.12902。（第[70页引用]）
• Luca Cardelli. 类型系统。ACM计算机调查 (CSUR), 28(1):263–264, 1996.（第[38页引用]）
• Federico Cassano, John Gouwar, Daniel Nguyen, Sydney Nguyen, Luna Phipps-Costin, Donald Pinckney, Ming-Ho Yee, Yangtian Zi, Carolyn Jane Anderson, Molly Q Feldman 等人. MultiPL-E: 一种可扩展且多语言的神经代码生成基准方法。IEEE软件工程汇刊, 49(7):3675–3691, 2023.（第23, [71页引用]）
• Federico Cassano, John Gouwar, Francesca Lucchetti, Claire Schlesinger, Anders Freeman, Carolyn Jane Anderson, Molly Q Feldman, Michael Greenberg, Abhinav Jangda 和 Arjun Guha. 将高资源转化为低资源编程语言的知识转移用于代码LLM。ACM程序语言学报, 8(OOPSLA2):677–708, 2024.（第[71页引用]）
• Linzheng Chai, Shukai Liu, Jian Yang, Yuwei Yin, Ke Jin, Jiaheng Liu, Tao Sun, Ge Zhang, Changyu Ren, Hongcheng Guo 等人. MCEval: 大规模多语言代码评估。arXiv预印本 arXiv:2406.07436, 2024.（第[71页引用]）
• Saikat Chakraborty, Rahul Krishna, Yangruibo Ding 和 Baishakhi Ray. 深度学习在优化软件开发过程中的应用。arXiv预印本 arXiv:2404.13630, 2024b.（第[74页引用]）
• Haolin Jin, Linghan Huang, Haipeng Cai, Jun Yan, Bo Li 和 Huaming Chen. 从LLM到基于LLM的代理进行软件工程：当前状况、挑战和未来方向。arXiv预印本 arXiv:2408.02479, 2024.（第[4页引用]）
• Yanjie Jiang, Hui Liu, Nan Niu, Lu Zhang 和 Yamin Hu. 从版本控制系统中提取简洁的bug修复补丁。在 IEEE/ACM第43届国际软件工程会议 (ICSE 2021)，第686–698页，Los Alamitos, CA, USA，五月2021。IEEE Computer Society出版。doi: 10.1109/ICSE43902.2021.00069。URL https://doi.ieeecomputersociety.org/10.1109/ICSE43902.2021.00069。（第[74页引用]）
• Kush Jain, Gabriel Synnaeve 和 Baptiste Rozière. TestGenEval: 真实世界的单元测试生成和测试完成基准。arXiv预印本 arXiv:2410.00752, 2024a.（第[14页引用]）
• Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Armando Solar-Lezama, Koushik Sen 和 Ion Stoica. LiveCodeBench: 全面且无污染的大型语言模型代码生成评估，2024b。URL https://arxiv.org/abs/2403.07974。（第5, 14, [75页引用]）
• Naman Jain, Manish Shetty, Tianjun Zhang, King Han, Koushik Sen 和 Ion Stoica. R2E: 将任何GitHub仓库转换为编程代理环境。在 第四十一届国际机器学习会议, 2024c。（第19, [30页引用]）
• Yanjie Jiang, Hui Liu, Nan Niu, Lu Zhang 和 Yamin Hu. 提取简明的bug修复补丁：版本控制系统中的人工补丁。在 IEEE/ACM第43届国际软件工程会议 (ICSE 2021)，第686–698页，洛杉矶，加利福尼亚州，美国，2021年5月。IEEE计算机协会。doi: 10.1109/ICSE43902.2021.00069。URL https://doi.ieeecomputersociety.org/10.1109/ICSE43902.2021.00069。（第[74页引用]）
• Yanjie Jiang, Hui Liu, Xiaoqing Luo, Zhihao Zhu, Xiaye Chi, Nan Niu, Yuxia Zhang, Yamin Hu, Pan Bian 和 Lu Zhang. BugBuilder: 一种自动化的bug库构建方法。IEEE软件工程汇刊, 第1–22页，2022a。doi: 10.1109/TSE.2022.3177713。（第[74页引用]）
• Yanjie Jiang, Hui Liu, Yuxia Zhang, Weixing Ji, Hao Zhong 和 Lu Zhang. bug是否导致源代码的不自然性？在 第30届ACM联合欧洲软件工程会议和基础软件工程研讨会论文集, ESEC/FSE 2022, 第1085–1096页，纽约，纽约，美国，2022b。计算机协会。ISBN 9781450394130。doi: 10.1145/3540250.3549149。URL https://doi.org/10.1145/3540250.3549149。（第[74页引用]）
• Yucheng Jiang, Yijia Shao, Dekun Ma, Sina J Semnani 和 Monica S Lam. 探索未知中的未知：通过参与语言模型代理对话实现积极的人类学习。arXiv预印本 arXiv:2408.15232, 2024.（第[40页引用]）
• Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press 和 Karthik R Narasimhan. SWE-Bench: 语言模型能否解决真实的GitHub问题？在 第十二届国际学习表示会议, 2024. URL https://openreview.net/forum?id=VTF8yNQM66.（第5, 14, [34页引用]）
• Haolin Jin, Linghan Huang, Haipeng Cai, Jun Yan, Bo Li 和 Huaming Chen. 从LLM到基于LLM的代理：现状、挑战和未来。arXiv预印本 arXiv:2408.02479, 2024.（第[4页引用]）
• Xin Jin, Jonathan Larson, Weiwei Yang 和 Zhiqiang Lin. 二进制代码摘要：Benchmarking ChatGPT/GPT-4及其他大规模语言模型，2023。URL https://arxiv.org/abs/2312.09601。（第[75页引用]）
• Sathvik Joel, Jie JW Wu 和 Fatemeh H Fard. 基于LLM的低资源和特定领域编程语言代码生成综述。arXiv预印本 arXiv:2410.03981, 2024.（第4, [71页引用]）
• René Just, Darioush Jalali 和 Michael D Ernst. Defects4J: 一个数据库，用于研究Java程序中的现有故障。在 2014年国际软件测试与分析研讨会论文集, 第437–440页，2014。（第[74页引用]）
• Adharsh Kamath, Aditya Senthilnathan, Saikat Chakraborty, Pantazis Deligiannis, Shuvendu K Lahiri, Akash Lal, Aseem Rastogi, Subhajit Roy 和 Rahul Sharma. 使用大规模语言模型寻找归纳循环不变量。arXiv预印本 arXiv:2311.07948, 2023.（第[73页引用]）
• Majeed Kazemitabaar, Justin Chow, Carl Ka To Ma, Barbara J Ericson, David Weintrop 和 Tovi Grossman. 研究AI代码生成器对初学者在入门编程中的支持效果。在 2023年CHI大会论文集, 第1–23页, 2023a.（第[71页引用]）
• Majeed Kazemitabaar, Xinying Hou, Austin Henley, Barbara Jane Ericson, David Weintrop 和 Tovi Grossman. 在自定进度学习环境中，初学者如何使用基于LLM的代码生成器解决CS1编程任务。在 第23届KoliCalling国际计算教育研究会议论文集, 第1–12页, 2023b.（第[71页引用]）
• </span 阿维什丽·卡哈尔、萨伊特·杜塔、齐阳·李、阿拉·索尔科-布雷斯林、拉杰夫·阿尔尔和梅约尔·奈克。理解大规模语言模型在检测安全漏洞方面的有效性。arXiv预印本 arXiv:2311.16169,2023。（第[73页引用]）
• 穆罕默德·卡尔玛、苏赫延·崔、穆罕默德·阿尔汗纳费塞、大卫·莫海森。安全性和质量在LLM生成代码中的多语言、多模型分析。arXiv预印本 arXiv:2502.01853, 2025。（第[25页引用]）
• 格温·克莱因、凯文·埃尔芬斯通、格诺特·黑瑟、朱尼·安德里克、大卫·考克、菲利普·德林、达姆米卡·埃尔库韦、凯·恩格尔哈特、拉法尔·科尔兰斯基、迈克尔·诺里斯等。seL4：正式验证的操作系统内核。在 ACM SIGOPS第22届操作系统原理研讨会论文集, 第207–220页，2009。（第[76页引用]）
• 丹尼斯·科切特科夫、雷蒙德·李、卢比娜·本·阿拉尔、贾亚·李、程成·穆、卡洛斯·穆尼奥斯·费兰迪斯、雅克·埃弗特、玛格丽特·米切尔、肖恩·休斯、托马斯·沃尔夫等。The Stack：3 TB的开源代码数据。arXiv预印本 arXiv:2211.15533, 2022。（第[29页引用]）
• 蒂姆·克拉卡、亚历克斯·贝乌特尔、艾德·H·奇、杰弗里·迪恩和尼奥克利斯·波利佐蒂斯。学习索引结构的案例研究。在 2018年国际数据管理会议论文集, 第489–504页, 2018。（第[19页引用]）
• Andarsh 库马兰南帕、Mo 蒂瓦里、Peiyang 歌、罗伯特·乔治、查欧威·晓和Koushik Sen。Syzygy：使用LLM和动态分析将双代码转换为（安全）Rust代码。arXiv预印本 arXiv:2412.14234, 2024。（第8, [72页引用]）
• Kensen Shi、Deniz Altınbükén、Saswat Anand、Mihai Christodorescu、Katja Grünwedel、Alexa Koenings、Sai Naidu、Anurag Pathak、Marc Rasi、Fredde Ribeiro 等人。自然语言大纲用于代码：LLM时代的文学编程。arXiv预印本 arXiv:2408.04820, 2024。（第[74页引用]）
• 魏佳亚、晨荣·巴鲁斯、米希·雅辛加、迈克尔·刘易斯、卢克·泽特勒莫耶、卢卡·索达伊尼、诺亚·A·史密斯、易兹中·王、普拉迪普·达西吉和汉纳内·哈吉什尔济。Tulu 3：开放语言模型后训练的前沿推进，2025。URL https://arxiv.org/abs/2411.15124。（第[30页引用]）
• 安德烈·席尔瓦、亚历山德拉·门德斯和若昂·F·费雷拉。利用大规模语言模型提升Dafny开发者的生产力。arXiv预印本 arXiv:2401.00963, 2024a。（第[76页引用]）
• 安德烈·席尔瓦、努诺·萨维德拉和马丁·蒙佩鲁斯。GitBug-Java：一个可重现的最近Java错误基准。在 第21届国际软件仓库挖掘会议论文集, 第118–122页, 2024b。（第[74页引用]）
• Shreya Singhal 和 Viraj Kumar。为AI生成的代码创建彻底的测试很难。在 第16届年度ACM印度计算大会论文集, COMPUTE ’23, 第108–111页, 纽约, NY, USA, 2023。计算机协会出版。ISBN 9781450394574。（第[39页引用]）
• 乔尔·斯卡尔斯、尼古拉斯·豪、德米特里·克拉斯亨尼科夫和大卫·克鲁格。定义和表征奖励游戏。神经信息处理系统进展, 35:9460–9471, 2022。（第[31页引用]）
• 哈利·M·斯尼德。从现有的COBOL程序中提取业务逻辑作为重开发的基础。在 第九届国际程序理解研讨会论文集, 第167–175页。IEEE, 2001。（第[8页引用]）
• 哈利·M·斯尼德。从COBOL迁移到Java。在 2010年IEEE软件维护国际会议论文集, 第1–7页。IEEE, 2010。（第[8页引用]）
• Peiyang Song, Kaiyu Yang 和 Anima Anandkumar. 大型语言模型作为Lean定理证明的副驾驶。arXiv预印本 arXiv:2404.12534, 2024。（第[76页引用]）
• Benjamin Steenhoek, Sewon Min, Michihiro Yasunaga, Minjoon Seo, Rich James, Mike Lewis, Luke Zettlemoyer 和 Wen-tau Yih. Replug: 增强的黑盒语言模型。arXiv预印本 arXiv:2301.12652, 2023.（第[36页引用]）
• Alexander Shypula, Aman Madaan, Yimeng Zeng, Uri Alon, Jacob Gardner, Milad Hashemi, Graham Neubig, Parthasarathy Ranganathan, Osbert Bastani 和 Amir Yazdanbakhsh. 学习性能改进的代码编辑。arXiv预印本 arXiv:2302.07867, 2023.（第28, [72页引用]）
• Xujie Si, Hanjun Dai, Mukund Raghothaman, Mayur Naik 和 Le Song. 学习循环不变量以验证程序。神经信息处理系统进展, 31, 2018.（第[73页引用]）
• Mohammed Latif Siddiq 和 Joanna C. S. Santos. SecurityEval 数据集：挖掘漏洞示例以评估基于机器学习的代码生成技术。第29–33页, 纽约, NY, USA, 2022。计算机协会出版。ISBN 9781450394574。（第[71页引用]）
• 阿尔瓦罗·席尔瓦、亚历山德拉·门德斯和João F Ferreira. 利用大规模语言模型提升Dafny开发者生产力。arXiv预印本 arXiv:2401.00963, 2024a.（第[76页引用]）
• André Silva, Nuno Saavedra 和 Martin Monperrus. GitBug-Java: 一个可重现的最新Java Bug基准。在 第21届国际软件仓库挖掘会议论文集, 第118–122页, 2024b.（第[74页引用]）
• Shreya Singhal 和 Viraj Kumar. 创建全面测试AI生成代码困难。在 第16届年度ACM印度计算大会论文集, COMPUTE ’23, 第108–111页, 纽约, NY, USA, 2023. 计算机协会出版。ISBN 9798400708404. doi: 10.1145/3627217.3627238. URL https://doi.org/10.1145/3627217.3627238.（第[39页引用]）
• Joar Skalse, Nikolaus Howe, Dmitrii Krasheninnikov 和 David Krueger. 定义和表征奖励游戏。神经信息处理系统进展, 35:9460–9471, 2022.（第[31页引用]）
• Harry M Sneed. 从现有COBOL程序中提取业务逻辑作为重新开发的基础。在 第9届国际程序理解研讨会论文集, 第167–175页。IEEE, 2001.（第[8页引用]）
• Harry M Sneed. 从COBOL迁移到Java。在 2010年IEEE软件维护国际会议论文集, 第1–7页。IEEE, 2010.（第[8页引用]）
• Peiyang Song, Kaiyu Yang 和 Anima Anandkumar. 向大型语言模型作为Lean定理证明的副驾驶迈进。arXiv预印本 arXiv:2404.12534, 2024.（第[76页引用]）
• Benjamin Steenhoek, Hongyang Gao 和 Wei Le. 受数据流分析启发的深度学习以实现高效的漏洞检测。arXiv预印本 arXiv:2212.08108, 2023.（第[73页引用]）
• Benjamin Steenhoek, Md Mahbubur Rahman, Monoshi Kumar Roy, Mirza Sanjida Alam, Earl T Barr 和 Wei Le. 对大型语言模型在漏洞检测方面的能力进行全面研究。arXiv预印本 arXiv:2403.17218, 2024.（第[73页引用]）
• Elias Stengel-Eskin, Archiki Prasad 和 Mohit Bansal. Regal: 重构程序以发现通用抽象。在 第41届国际机器学习会议论文集, ICML’24. JMLR.org, 2024.（第[18页引用]）
• Chia-Yi Su 和 Collin McMillan. Distilled GPT：用于源代码摘要的预训练模型。自动化软件工程, 31(1):22, 2024.（第[74页引用]）
• Hongjin Su, Howard Yen, Mengzhou Xia, Weijia Shi, Niklas Muennighoff, Han-yu Wang, Haisu Liu, Quan Shi, Zachary S Siegel, Michael Tang 等. BRIGHT：一种现实且具有挑战性的推理密集型检索基准。arXiv预印本 arXiv:2407.12883, 2024.（第[20页引用]）
• Chuyue Sun, Ying Sheng, Oded Padon 和 Clark Barrett. Clover: 闭环可验证代码生成。在 人工智能验证国际研讨会论文集, 第134–155页。Springer, 2024a.（第14, [76页引用]）
• Jiao Sun, Yufei Tian, Wangchunshu Zhou, Nan Xu, Qian Hu, Rahul Gupta, John Frederick Wieting, Nanyun Peng 和 Xuezhe Ma. 在受控生成任务上评估大规模语言模型，2023. URL https://arxiv.org/abs/2310.14542.（第[70页引用]）
• Tao Sun, Jian Xu, Yuanpeng Li, Zhao Yan, Ge Zhang, Lintao Xie, Lu Geng, Zheng Wang, Yueyan Chen, Qin Lin 等. BitsAI-CR: 实践中的大规模语言模型自动代码审查。arXiv预印本 arXiv:2501.15134, 2025.（第[74页引用]）
• WeiSong Sun, Yun Miao, Yuekang Li, Hongyu Zhang, Chunrong Fang, Yi Liu, Gelei Deng, Yang Liu 和 Zhenyu Chen. 源代码摘要的大规模语言模型时代。arXiv预印本 arXiv:2407.07959, 2024b.（第40, [74页引用]）
• Yu Sun, Xiaolong Wang, Liu Zhuang, John Miller, Moritz Hardt 和 Alexei A Efros. 使用自监督训练进行分布偏移下的泛化。在 ICML, 2020.（第[32页引用]）
• Nigar M Shafiq Surameery 和 Mohammed Y Shakor. 使用ChatGPT解决编程错误。国际信息技术与计算机工程期刊, (31):17–22, 2023.（第[71页引用]）
• Christian Szegedy. 一条通往自动形式化和通用人工智能的有希望路径。在 智能计算机数学：第13届国际会议，CICM 2020, Bertinoro, 意大利,2020年7月26日至31日，会议记录13, 第3–20页。Springer, 2020.（第[33页引用]）
• Shin Hwei Tan, Jooyong Yi, Sergey Mechtaev, Abhik Roychoudhury 等. CodeFlaws：一个编程竞赛基准，用于评估自动化程序修复工具。在 2017 IEEE/ACM第39届国际软件工程会议附录 (ICSE-C), 第180–182页。IEEE, 2017.（第[75页引用]）
• Shin Hwei Tan, Zhen Dong, Xiang Gao 和 Abhik Roychoudhury. 修复Android应用崩溃。在 2018年第40届国际软件工程会议论文集, 第187–198页, 2018.（第[74页引用]）
• Hao Tang, Keya Hu, Jin Zhou, Si Cheng Zhong, Wei-Long Zheng, Xujie Si 和 Kevin Ellis. 使用LLM进行代码修复提供了一种探索-利用权衡。神经信息处理系统进展, 37:117954–117996, 2025.（第[75页引用]）
• Tom Taulli. COBOL语言：称其为回归？2020年7月。URL https://www.forbes.com/sites/tomtaulli/2020/07/13/cobol-language-call-it-a-comeback/.（第[8页引用]）
• Kimi Team, Angang Du, Bofei Gao, Bowei Xing, Changjiu Jiang, Cheng Chen, Cheng Li, Chenjun Xiao, Chenzhuang Du, Chonghua Liao 等. Kimi K1.5: 使用LLM扩展强化学习。arXiv预印本 arXiv:2501.12599, 2025.（第[31页引用]）
• Terrateam. 使用LLM生成Terraform代码。https://terrateam.io/blog/using-llms-to-generate-terraform-code/, 2024.（第[12页引用]）
• The Coq Development Team. Coq参考手册 – 发布8.19.0。https://coq.inria.fr/doc/V8.19.0/refman, 2024.（第13, [76页引用]）
• Angelica M Tinga, Diane Cleij, Reinier J Jansen, Sander van der Kint 和 Nicole van Nes. 自动驾驶期间连续支持模式感知的人机界面设计：在线模拟。交通研究部分F：交通心理学和行为, 87:102–119, 2022.（第[18页引用]）
• David A Tomassi, Naji Dmeiri, Yichen Wang, Antara Bhowmick, Yen-Chuan Liu, Premkumar T Devanbu, Bogdan Vasilescu 和 Cindy Rubio-González. BugSwarm：挖掘并持续增长可重现的失败和修复数据集。在 2019 IEEE/ACM第41届国际软件工程会议 (ICSE), 第339–349页。IEEE, 2019.（第[75页引用]）
• Benjamin Trent 和 Ao Li. Lucene中的并发错误：如何修复乐观并发错误。https://www.elastic.co/search-labs/blog/optimistic-concurrency-lucene-debugging, 2025.（第[9页引用]）
• Christoph Treude 和 Marco A Gerosa. 开发者如何与AI互动：软件工程中的人工智能协作分类。arXiv预印本 arXiv:2501.08774, 2025.（第6, [18页引用]）
• Trieu H Trinh, Yuhuai Wu, Quoc V Le, He He 和 Thang Luong. 使用深度强化学习发现更快的排序算法。自然, 625(7995):476–482, 2024.（第[29页引用]）
• Rosalia Tufano, Luca Pascarella, Michele Tufano, Denys Poshyvanyk 和 Gabriele Bavota. 朝着自动化代码审查活动迈进。在 2021 IEEE/ACM第43届国际软件工程会议论文集 (ICSE), 第163–174页。IEEE, 2021.（第[74页引用]）
• Rosalia Tufano, Simone Masiero, Antonio Mastropaolo, Luca Pascarella, Denys Poshyvanyk 和 Gabriele Bavota. 使用预训练模型增强代码审查自动化。在 第44届国际软件工程会议论文集, 第2291–2302页, 2022.（第[74页引用]）
• Marcel Ullrich 和 Sebastian Hack. 排序核心的综合。在 第23届ACM/IEEE国际代码生成与优化研讨会论文集, CGO ’25, 第1–14页, 纽约, NY, USA, 2025. 计算机协会出版。ISBN 9798400712753. doi: 10.1145/3696443.3708954. URL https://doi.org/10.1145/3696443.3708954.（第[27页引用]）
• 赛泰加·乌特帕拉、亚历克斯·顾和品友·陈。语言无关的代码嵌入。arXiv预印本 arXiv:2310.16803, 2023.（第20, [36页引用]）
• 亚历山大·维尔德、穆罕默德·哈姆达嘎、莱森·达·席尔瓦和傅特赛·科姆。基础设施即代码中的安全性实践探索：实证研究，2023。URL https://arxiv.org/abs/2308.03952。（第[75页引用]）
• Mark Vero, Niels M ünder, Victor Chibotaru, Veselin Raychev, Maximilian Baader, Nikola Jovanović, Jingxuan He 和 Martin Vechev. BaxBench: LLM能否生成正确且安全的后端？2025。URL https://arxiv.org/abs/2502.11844。（第[71页引用]）
• Sanidhya Vijayvargiya, Xuhui Zhou, Akhila Yerukola, Maarten Sap 和 Graham Neubig. 交互式代理克服软件工程中的模糊性。2025。URL https://arxiv.org/abs/2502.13069。（第34, [71页引用]）
• Vasudev Vikram, Caroline Lemieux, Joshua Sunshine 和 Rohan Padhye. 大型语言模型能否编写良好的属性测试？arXiv预印本 arXiv:2307.04346, 2023.（第[72页引用]）
• Shengye Wan, Cyrus Nikolaidis, Daniel Song, David Molnar, James Crnkovich, Jayson Grace, Manish Bhatt, Sahana Chennabasappa, Spencer Whitman, Stephanie Ding 等人。CyberSecEval 3：推进大型语言模型中的网络安全风险和能力评估。arXiv预印本 arXiv:2408.01605, 2024a.（第[71页引用]）
• 盛烨·万，张谦倩，杨一，张天阳，周松旺，和清旺，王英琳，徐海进，刘洋。深度学习在代码智能中的应用：综述、基准和工具包。ACM计算调查, 2024b.（第[4页引用]）
• 程鹏·王，章武琦，苏子安，许象哲，谢小恒，张。LLMDFA: 使用大型语言模型分析代码中的数据流，2024a。URL https://arxiv.org/abs/2402.10754。（第[73页引用]）
• 崇·王，郑建楠，彭新，刘洋，周玉玲，陈立，夏基廷，赵志鹏，胡文浩，陶等。通过基于大型语言模型的资源导向意图推断提高静态资源泄漏检测效果。arXiv预印本 arXiv:2311.04448, 2023.（第[73页引用]）
• 崇·王，张建，刘旭，宋阳，杜大成，张雄，王瑶，孙文松，刘洋，彭欣。TIGER: 一种实用Python类型推断的生成-然后排名框架。arXiv预印本 arXiv:2407.02095, 2024b.（第[74页引用]）
• 俊杰·王，黄宇超，陈春阳，张哲，王向茹，和王青。使用大型语言模型进行软件测试：综述、现状和愿景。IEEE软件工程汇刊, 2024c.（第[4页引用]）
• 李忠元，张雨涵，许翔哲，谷歌开源安全团队。AI驱动的模糊测试：突破漏洞猎捕障碍。https://security.googleblog.com/2023/08/ai-powered-fuzzing-breaking-bug-hunting.html, 2023a.（第[73页引用]）
• 东哥·刘，奥利弗·张，Metzman·乔纳森，马丁·萨博特尼，和米哈伊·马鲁塞克。OSS-Fuzz-Gen: 自动模糊目标生成，2024b。URL https://github.com/google/oss-fuzz-gen。（第[73页引用]）
• 纪伟·刘，余天越。Code-R1: 通过可靠的奖励进行代码生成。2025。（第[29页引用]）
• 俊杰·刘，叶松润，王军浩，周云庄，黄远峰，张天明。评估语言模型的有效代码生成。在 第一届语言建模会议, 2024c。URL https://openreview.net/forum?id=IBCBMeAhmC。（第[14页引用]）
• 明杰·刘，内森·平克尼，布鲁斯克·凯哈良尼，和郝兴星·任。VerilogEval: 评估大规模语言模型在Verilog代码生成中的表现。在 2023 IEEE/ACM国际计算机辅助设计会议 (ICCAD)，第1–8页。IEEE, 2023b。（第[71页引用]）
• 培培·刘，建孙·张，李铭佳，张佩璋，孙达朋，王道卫，邓白风。利用大规模语言模型支持二进制污点分析。arXiv预印本 arXiv:2310.08275, 2023c。（第[74页引用]）
• 思瑶·刘，朱和，刘杰瑞，许象哲，李傲燕，长·彭，陈立，杨金霞，张兆贤，张志高，冯宣宁，丁光，胡凯申，和祥。FullStack Bench: 评估大规模语言模型作为全栈编码器，2024d。URL https://arxiv.org/abs/2412.00535。（第[4页引用]）
• 吴维柳，Rubaiat Habib Kazi, 李怡义·韦，马修·费舍尔，蒂莫西·朗格洛斯，塞斯·沃克，和莉迪亚·奇尔顿。LogoMotion: 通过视觉接地代码合成创建和编辑动画，2025b。URL https://arxiv.org/abs/2405.07065。（第[70页引用]）
• 叶露·刘，毕剑秋，比张庆，王云轩，许向哲，张佩璋，孙达朋，王道卫，李丹。CodexEmbed: 一种面向多语言和多任务代码检索的通用嵌入模型家族，2024e。URL https://arxiv.org/abs/2402.10754。（第[74页引用]）
• 岳婉，比张谦倩，杨阳，钟子安，薛向哲，张佩璋，张建，刘洋，彭欣。Tiger: 一种生成-然后排名的框架，用于实际的Python类型推断。arXiv预印本 arXiv:2407.02095, 2024b.（第[74页引用]）
• 俊杰·王，黄宇超，陈春阳，刘哲，王松，和王青。使用大型语言模型进行软件测试：综述、现状和愿景。IEEE软件工程汇刊, 2024c.（第[4页引用]）
• 李渊媛，张星行，许子安，许翔哲，谢晓恒，张向哲。LLMDFA: 使用大型语言模型分析代码中的数据流，2024a。URL https://arxiv.org/abs/2402.10754。（第[73页引用]）
• 若彤·王，程锐佳，福特·戴娜，和托马斯·齐默曼。调查和设计对AI赋能代码生成工具的信任。在 2024 ACM公平性、问责制和透明度会议论文集, FAccT ’24, 第1475–1493页, 纽约, NY, USA, 2024e。计算机协会出版。ISBN 9798400704505。doi: 10.1145/3630106.3658984。URL https://doi.org/10.1145/3630106.3658984。（第[18页引用]）
• 帅阳·王，沈亮，苏航，刘洋，右毅·周。Boosting Static Resource Leak Detection via LLM-Based Resource-Oriented Intention Inference. arXiv预印本 arXiv:2311.04448, 2023.（第[73页引用]）
• 星耀·王，Boxuan Li，宋玉凡，Frank F. Xu，汤象如，祝明臣，潘家奕，宋悦琪，李博文，Singh Jaskirat，Tran Hoang H.，李富强，马仁，郑明章，钱比尔，邵燕军，Niklas Muennighoff，张义哲，Binyuan Hui，林俊阳，Robert Brennan，彭昊，姬恒，和Neubig Graham。OpenHands: 一个供AI软件开发人员使用的开放式平台，2024g。URL https://arxiv.org/abs/2407.16741。（第15, [74页引用]）
• 彦林·王，江天跃，刘鸣伟，陈佳琦。超越功能正确性：调查大型语言模型中的编码风格不一致。arXiv预印本 arXiv:2407.00456, 2024h。（第[17页引用]）
• 子若·王，Asai Akari，Velocity Yu Xinyan，Frank F Xu，谢轶琴，Graham Neubig 和 Daniel Fried. CoderAG-Bench: 检索是否能增强代码生成？arXiv预印本 arXiv:2406.14497, 2024i.（第[20页引用]）
• 家仪·韦，Greg Durrett 和 Isil Dillig. TypeT5: 使用静态分析进行序列到序列类型推断。arXiv预印本 arXiv:2303.09564, 2023a.（第[74页引用]）
• 宇祥·韦，Chunqiu Steven Xia 和 Lingming Zhang. Copiloting the Copilots: 将大型语言模型与补全引擎融合以实现自动程序修复。在第31届ACM联合欧洲软件工程会议和基础软件工程研讨会论文集, 第172–184页, 2023b.（第[39页引用]）
• 宇祥·韦，Olivier Duchenne，Jade Copet，Quentin Carbonneaux，Lingming Zhang，Daniel Fried，Gabriel Synnaeve，Rishabh Singh 和 Sida I. Wang. SWE-RL：通过在开放软件进化上的强化学习提升LLM推理能力，2025。URL https://arxiv.org/abs/2502.18449。（第30, [31页引用]）
• Justin D Weisz，Shraddha Kumar，Michael Muller，Karen-Ellen Browne，Arielle Goldberg，Ellice Heintze 和 Shagun Bajpai. 考察企业中AI代码助手的使用及其对开发者生产力和体验的影响。arXiv预印本 arXiv:2412.06603, 2024.（第[17页引用]）
• Sean Welleck 和 Rahul Saha. LLMStep: 在Lean中的LLM证明步骤建议。arXiv预印本 arXiv:2310.18457, 2023.（第[76页引用]）
• Ratnadira Widyasari，秦胜，Camellia Lok，Qi Haodi，Jack Phan，Tay Qijin，Constance Tan，Fiona Wee，Tan Jodie Ethelda，Yuheng Yieh 等人。BugsInPy：一个现有的Python程序错误数据库，以支持受控测试和调试研究。在 第28届ACM联合欧洲软件工程会议和基础软件工程研讨会论文集, 第1556–1560页, 2020.（第[74页引用]）
• Man-Fai Wong，郭尚新，陈清南，霍秀伟 和谭启仁。用于AI辅助编程的大规模代码自然语言生成与理解综述。熵, 25(6):888, 2023.（第[4页引用]）
• Yuk Wah Wong 和 Raymond Mooney. 面向语义解析的学习：统计机器翻译方法。由Robert C. Moore, Jeff Bilmes, Jennifer Chu-Carroll 和 Mark Sanderson编辑，在 NAACL人类语言技术会议论文集，主会议, 第439–446页, 美国纽约市, 2006年6月。计算机语言协会出版。（第[70页引用]）
• Tongtong Wu，罗林浩，李元芳，潘世瑞，吴秋玉 和 Gholamreza Haffari. 持续学习的大规模语言模型：综述。arXiv预印本 arXiv:2402.01364, 2024.（第24, [32页引用]）
• 春丘·Steven Xia，邓阴琳，索伦·邓恩 和 张灵明。Agentless: 解密基于LLM的软件工程代理。arXiv预印本 arXiv:2407.01489, 2024a.（第74, [75页引用]）
• 春丘·Steven Xia，Matteo Paltenghi，田家乐，Michael Pradel 和 张灵明。Fuzz4All: 使用大规模语言模型进行通用模糊测试。在 IEEE/ACM第46届国际软件工程会议论文集, 第1–13页, 2024b.（第[73页引用]）
• 肖涛，Christoph Treude，Hata Hideaki 和 Matsumoto Kenichi. DevGPT: 研究开发者的GPT对话。在 第21届国际软件仓库挖掘会议论文集, 第227–230页, 2024.（第[71页引用]）
• 谢伊青，叶爱霞，迪维扬舒·塞特，刘鹏飞，弗里德·丹尼尔 和 Rose Carolyn. Repost: 可扩展的存储库级编码环境构建与沙盒测试。arXiv预印本 arXiv:2503.07358, 2025.（第[30页引用]）
• 程旭，关淑豪，格林 Derek，Kechadi M 等人。大型语言模型基准数据污染调查：综述。arXiv预印本 arXiv:2406.04244, 2024a.（第14, [29页引用]）
• 智星许，郭圣建，奥克斯纳 Tkachuk，Nejati Saeed，Razavi Niloofar 和 Argyros George. 云资源保护：通过自动安全属性推理。在 第39届IEEE/ACM自动化软件工程国际会议论文集, 第2170–2175页, 2024b.（第[76页引用]）
• 严昊，Thomas D Latoza 和尧子宇。IntelliExplain: 增强非专业程序员的会话式代码生成。arXiv预印本 arXiv:2405.10250, 2024.（第[71页引用]）
• 杨晨远，赵子杰 和 张灵明。KernelGPT: 借助大型语言模型增强内核模糊测试。arXiv预印本 arXiv:2401.00563, 2023a.（第[73页引用]）
• 杨晨远，李旭恒，Misul Md Rakib Hossain，姚建安，崔卫东，龚业纬，Chris Hawblitzel，拉希 Shuvendu，洛奇 Jacob R，卢帅 等人。AutoVerus: Rust代码的自动化证明生成。arXiv预印本 arXiv:2409.13082, 2024a.（第[76页引用]）
• 阳达宇，刘天洋，张道安，Simoulin Antoine，刘晓毅，曹雨威，滕昭普，钱欣，杨Grey，罗Jiebo 等人。从思考到代码，从代码到思考：关于代码增强推理和推理驱动代码智能的大规模语言模型调查。arXiv预印本 arXiv:2502.19411, 2025.（第[75页引用]）
• John Yang，Carlos E Jimenez，Alexander Wettig，Kilian Lieret，Shunyu Yao，Karthik R Narasimhan 和 Ofir Press。SWE-Agent: 通过代理-计算机界面实现自动化的软件工程。在 第三十八届年度神经信息处理系统会议, 2024b。URL https://arxiv.org/abs/2405.15793。（第15, 34, [74页引用]）
• John Yang，Carlos E Jimenez，Zhang Alex L，Kilian Lieret，Joyce Yang，吴欣地，Press Ori，Niklas Muennighoff，Gabriel Synnaeve，Karthik R Narasimhan 等人。SWE-Bench 多模态：AI系统能否推广到视觉软件领域？arXiv预印本 arXiv:2410.03859, 2024c.（第[20页引用]）
• 杨凯宇，斯沃普 Aidan，顾亚历山大，查克拉马赫 Rahul，宋培洋，高赛德，哥迪尔 Saad，雷恩 Ryan J Prenger 和 Anandkumar Animashree。LeanDojo: 使用检索增强的语言模型进行定理证明。神经信息处理系统进展, 36:21573–21612, 2023b。（第[71页引用]）
• John Yang，Poesia Gabriel，He Jingxuan，Li Wenda，Lauter Kristin，Chaudhuri Swarat 和 Song Dawn。形式数学推理：AI的新前沿。arXiv预印本 arXiv:2412.16075, 2024d.（第4, [76页引用]）
• 银周宁，马小，郑静，周远源，拜拉瓦斯undaram Lakshmi N. 和帕苏帕提 Shankar。商业和开源系统中配置错误的实证研究。在 第二十三届ACM操作系统原理研讨会论文集, SOSP ’11, 第159–172页, 纽约, NY, USA, 2011。计算机协会出版。ISBN 9781450309776。（第[75页引用]）
• 石文于，王婷，王吉。基于SMT求解增强的强化学习循环不变量推断。在 第32届ACMSIGSOFT国际软件测试与分析研讨会论文集, 第175–187页, 2023。（第[74页引用]）
• 陶宇，张瑞，杨凯，弥雅那加，王东旭，李子凡，马詹姆斯，李艾琳，姚青宁，罗曼 Shannon，张志霖，施奈尔，李文倩，多格莫夫 Daniel Radev。Spider: 一个大规模人工标注的数据集，用于复杂和跨域的语义解析和文本到SQL任务，2019。（第[70页引用]）
• Karen Zee，Viktor Kuncak 和 Martin Rinard。全功能验证链接数据结构。ACM SIGPLAN公告, 43(6):349–361, 2008。（第[13页引用]）
• Luke S. Zettlemoyer 和 Michael Collins。将句子映射到逻辑形式的学习：具有概率范畴语法的结构化分类，2012。URL https://arxiv.org/abs/1207.1420。（第[70页引用]）
• 凯琪·张，李珠若，李佳，葛等 和 金志。SelfEdit: 故障感知代码生成器。在 计算语言学协会第六十一届年会论文集(长篇论文卷), 第769–787页, 加拿大多伦多, 2023a。（第[75页引用]）
• 科迅·张，丹青·王，夏敬涛，威廉·杨·王 和 李磊。Algo: 使用生成的Oracle验证器综合算法程序。arXiv预印本 arXiv:2305.14591, 2023b。（第[73页引用]）
• 全军·张，方春荣，马宇翔，孙蔚松 和 金志。大规模语言模型在自动化程序修复中的应用综述。ACM软件工程与方法论汇刊, 33(2):1–69, 2023c。（第[4页引用]）
• 全军·张，方春荣，杨阳，马宇翔，孙蔚松，杨云，和金志。大规模语言模型在自动化程序修复中的系统文献综述。arXiv预印本 arXiv:2405.01466, 2024a。（第[75页引用]）
• 天一·张，Varsha Kishore，武斐，韦恩伯格 Kilian Q，和 Artzi Yoav。BERTScore: 使用BERT评估文本生成。arXiv预印本 arXiv:1904.09675, 2019。（第[31页引用]）
• 云通·张，海丰·阮，范志华 和 罗伊周。Autocoderover: 自动程序改进。在 第33届ACMSIGSOFT国际软件测试与分析研讨会论文集, 第1592–1604页, 2024b。（第[74页引用]）
• 成刚·赵，周尚言，李丽悦，邓诚齐，许哲安，刘玉轩，余快，李家诗 和 赵良照。DeepEP: 一种高效的专家并行通信库。https://github.com/deepseek-ai/DeepEP, 2025。（第[9页引用]）
• Wenting Zhao，江楠，Lee Celine，Justin T Chiu，Cardie Claire，Gallé Matthias 和 Rush Alexander M。Commit0: 从零开始生成库。<arXiv预印本 arXiv:2412.01769>, 2024。（第5, [14页引用]）
• 成钢·赵，龚琳娜，张皓翔，余耀深 和 黄志秋。如何获得更好的嵌入？——一项关于代码预训练模型的经验研究。<arXiv预印本 arXiv:2311.08066>, 2023。（第[36页引用]）
• 丹·郑 和 Koushik Sen。Python机器学习程序中可能符号张量形状的动态推断。在 第46届国际软件工程会议：软件工程实践论文集, 第147–156页, 2024。（第[73页引用]）
• 子彬·郑，凯文·宁，王艳琳，张景文，郑得伍，叶铭雪 和 陈基池。大规模语言模型在代码领域的应用综述：演化、基准测试和未来趋势。<arXiv预印本 arXiv:2311.10372>, 2023。（第[4页引用]）
• 子航·钟，王志龙 和 上官玲波。像人类一样调试：通过逐步验证执行来实现的大规模语言模型调试。<arXiv预印本 arXiv:2402.16906>, 2024a。（第[75页引用]）
• 子航·钟，王志龙 和 上官玲波。LDB: 通过逐步验证运行时执行实现的大规模语言模型调试。<arXiv预印本 arXiv:2402.16906>, 2024b。（第[15页引用]）
• Victor Zhong，Caiming Xiong 和 Richard Socher。Seq2SQL: 使用强化学习从自然语言生成结构化查询。2017。（第[70页引用]）
• 淑妍·周，乌里 Alon，Frank F Xu，王志若，姜正宝 和 Graham Neubig。DocPrompting: 通过检索文档生成代码。<arXiv预印本 arXiv:2207.05987>, 2022。（第[71页引用]）
• 淑妍·周，乌里 Alon，Sumit Agarwal 和 Graham Neubig。CodeBERTScore: 使用预训练代码模型评估代码生成。<arXiv预印本 arXiv:2302.05527>, 2023。（第[31页引用]）
• 雅琴·周，柳上清，Siow J，杜霞宁 和 刘洋。Devign: 使用图神经网络进行有效的漏洞识别。, 2019。（第[73页引用]）
• 昌柱，王子阳，张子龙，Anton Xue，Ati Priya Bajaj，威尔 Gibbs，刘逸博，阿鲁 Rajeev，葆 Tiffany，韩俊 Dai，Adam Doupe，Mayur Naik，Yan Shoshitaishvili，王若愚 和 Aravind Machiry。TYGR: 使用图神经网络进行类型推断的剥离二进制文件。<33rd USENIX Security Symposium (USENIX Security 24)>, 2024。ISBN 978-1-939133-44-1。（第[74页引用]）
• 特里·岳·朱，周子阳，宁凯文，张子凡，李振峰，何俊峰，杨宇轩，刘旭，和 Artzi Yoav。BigCodeBench: 使用多样函数调用和复杂指令评估代码生成。<arXiv预印本 arXiv:2406.15877>, 2024。（第[4页引用]）
• Albert Ziegler，Eirini Kalliamvakou，Alice Li Z，Andrew Rice，Devon Rifkin，Shawn Simister，Ganesh Sittampalam 和 Edward Aftandilian。衡量GitHub Copilot对生产力的影响。, 67(3):54–63, 2024。（第[29页引用]）
• 阿米特·佐哈尔 和 利奥 Wolf。自动程序综合：带有学习垃圾收集器的长程序。神经信息处理系统进展, 31, 2018。（第[36页引用]）

附录A 相关工作调查：AI软件工程中的任务

在本节中，我们简要调查了我们在第2节中提到的每个任务的相关工作。这些工作并不完整，我们鼓励读者查看介绍和本节中提到的调查文章以获取更多参考。

A.1 代码生成

代码补全：补全通常与实时编程或在IDE内结合使用，通过提供相关建议帮助开发者更快编写代码。传统的代码补全系统高度依赖于语法和类型感知模型（如基于AST的模型），但最近的进步利用了在代码语料库上训练的大规模语言模型，提供语义丰富且上下文感知的建议，自然遵循语言建模中的下一个标记预测任务 (Radford等人, 2019)。GitHub Copilot和Codex就是这种趋势的例子 (Chen等人, 2021a)，随后出现了商用工具如Cursor4 和 Tabnine5 。最近在情境感知 (Agrawal等人, 2023)、语法对齐 (Park等人, 2024) 和基于约束的解码 (Sun等人, 2023) 方面的进步提高了局部补全的质量，特别是对于较短的代码片段。对于较长的代码片段，典型的任务设定是根据函数签名合成方法实现。这种设定通常使用MBPP (Austin等人, 2021) 和HumanEval (Chen等人, 2021a) 进行评估。

自然语言到代码生成：将自然语言转化为代码长期以来一直是编程AI的核心挑战。早期尝试涉及语义解析 (Zettlemoyer和Collins, 2012; Wong和Mooney, 2006)，其中自然语言被转化为逻辑形式或特定领域的语言。一个突出的例子是从自然语言问题生成SQL查询，如Seq2SQL (Zhong等人, 2017) 和 Spider (Yu等人, 2019) 所示，目标语言受限、较小且领域特定。最近的研究表明，大规模语言模型（LLMs）可以推广到通用编程语言，从而能够生成更大和更复杂的代码片段 (OpenAI, 2023b)。当应用于代码补全时，用户通常以注释的形式给出自然语言指令，LLMs将其作为代码合成的上下文。超越函数级别的代码生成 (Austin等人, 2021; Chen等人, 2021a)，最近的工作已经扩展到了类级别生成 (Du等人, 2023)，这针对面向对象编程中的类，并且甚至项目级别的代码生成 (Cao等人, 2024; Wang等人, 2024f)，这涉及到生成或完成整个多文件代码库。

多模态代码生成：虽然文本可以描述大多数代码生成案例，但某些指令最好通过视觉定义。例如，在图形应用程序中，视觉上下文如轨迹或3D模型对于合成正确代码至关重要。GPT-4多模态能力的演示表明，模型可以从纸草图直接生成功能性网页代码，将视觉布局转换为HTML和CSS (OpenAI, 2023a)。LogoMotion (Liu等人, 2025b) 探索了JavaScript动画和运动图形的视觉接地代码生成。该系统利用视觉-语言模型（VLMs）整合视觉输入和用户指令，使生成的代码与空间和时间视觉提示一致。其他工作，如SynthesizeCAD (Nandi等人, 2020) 和 SGP-Bench (Qiu等人,

4https://www.cursor.so

5https://www.tabnine.com

2024)，探索了LLM如何通过生成SVG和CAD等语言中的代码与视觉和3D模式交互。

低资源语言代码生成：如第3.7节所述，一个主要挑战是在采用率较低的通用目的语言和领域特定语言（DSLs）中编写代码。包括MultiPL-E (Cassano等人, 2023)、McEval (Chai等人, 2024) 和 VerilogEval (Liu等人, 2023b) 的基准测试涵盖了这一方面。一种流行的方法是训练手动整理和处理的低资源语言数据，如Coq (Florath, 2024) 和 Verilog (Pei等人, 2024)。另一条研究路线旨在实现不同低资源语言之间的迁移 (Paul等人, 2024); Cassano等人, 2024; Orlanski等人, 2023)。最后，由于缺乏数据是一个很大的瓶颈，另一个流行的方向是使用相关的检索结果，如有用的函数和库文档 (Yang等人, 2023b; Zhou等人, 2022; Yang等人, 2023b)。对于低资源语言和DSL的代码生成近期调查，请参见 (Joel等人, 2024)。

围绕代码生成的安全问题：尽管LLM在代码生成方面的能力不断增强，但其输出往往仍然不安全、不正确或与用户意图不符。例如，BaxBench (Vero等人, 2025) 评估了LLM在生成安全和正确的后端代码方面的能力，揭示了平均功能正确性已经适中（∼60%），而安全输出率更低（<35%）。为了更好地理解和量化这些限制，提出了几个基准和评估套件。SecurityEval (Siddiq和Santos, 2022)、SafeCoder (He等人, 2024)、CodeLMSec (Hajipour等人, 2023)、CWEval (Peng等人, 2025) 和 CyberSecEval (Bhatt等人, 2023; Wang等人, 2024a) 提供了不同的视角来评估漏洞、不安全API使用或符合常见弱点枚举（CWEs）的情况。作为回应，一些方法引入了人在环路的防护栏，开发者可以通过互动引导、检查或限制生成过程。Dynex (Ma等人, 2025a) 支持带用户反馈的动态、分步代码合成，允许实时纠正和迭代完善，避免错误积累。

人类参与的代码生成：现代代码LLM通常通过对话接口支持交互式代码生成。Champa等人 (2024) 使用DevGPT数据集定量分析了开发者与ChatGPT的互动(Xiao等人, 2024)，考察了初始提示质量如何影响对话长度。代码LLM可以进一步优化各种交互场景，包括调试环境(Surameery和Shakor, 2023)、教育设置(Kazemitabaar等人, 2023a,b; Prather等人, 2023; Sheese等人, 2024)，以及非专业程序员的使用Yan等人 (2024)。除了聊天环境中的以人类为主导的互动外，更高级别的代码生成系统如编码代理还可以主动提出澄清问题Vijayvargiya等人 (2025)，或者为用户提供验证生成测试用例Lahiri等人 (2022; Fakhoury等人, 2024)，以帮助解决歧义。

A.2 代码转换

代码重构：代码重构的目标是对复杂存储库中的代码进行简化和消除重复，而不改变高层程序意图。虽然已有传统方法(Pailoor等人, 2024) 对数据结构进行重构，Aider AI引入了一个重构基准6 ，评估LLM生成长段代码以简化复杂程序而不改变行为的能力。最近，RefactorBench (Gautam等人, 2024) 引入了一个

6https://github.com/Aider-AI/refactor-benchmark

更加复杂的基准，包含自然语言重构请求，以及一个可以执行重构的LLM代理。

代码迁移：相比于代码重构，代码迁移通常指的是影响程序接口、依赖关系或底层架构的中期规模修改。常见的例子包括将后端数据库从MySQL切换到PostgreSQL，将机器学习模型从TensorFlow迁移到PyTorch，或将Java版本从旧版Java 8升级到更现代的Java 17。最近的工作引入了评估库迁移的基准设计 (Islam等人, 2023)，Google (Nikolov等人, 2025) 和Amazon (Omidvar Tehrani和Anubhai, 2024) 已经探索了简单但庞大的LLM驱动解决方案。Google的系统识别需要更改的位置，使用微调过的内部代码LLM生成修改，并通过编译和测试执行自动验证更改。

代码翻译（转译）：超出代码迁移，转译涉及程序底层编程语言的大规模转换。转译不仅用于现代化过时的代码库，还用于消除老语言固有的安全类别问题。一个特别活跃的研究领域涉及将基于C的系统转译为Rust，这是一种提供强大内存和并发安全性保证的系统级语言。这个方向引起了关注，包括来自美国国防部7 ，他们维护着关键基础设施，这些基础设施建立在老化的C代码之上。一个端到端的LLM为基础的方法，如Flourine (Eniser等人, 2024) 已被提出用于实际代码翻译，但由于频繁的编译错误，它仅取得了有限的成功。最近的努力如Syzygy (Shetty等人, 2024)，C2SaferRust (Nitin等人, 2025) 和 AlphaTrans (Ibrahimzada等人, 2024) 展示了结合LLM与传统程序分析技术的混合方法的潜力。然而，正如 Li等人 (2025b) 所指出的一些重大挑战仍然存在，包括确保在大规模代码库中保持正确性的同时维持期望的属性，如速度、减少漏洞和惯用性。具体而言，我们认为第A.3节讨论的技术可能有助于应对这些剩余的挑战。

代码优化：某些重构或转译任务专门针对优化代码性能。先前的工作探讨了LLM在优化独立程序中的应用，如PIE (Shypula等人, 2023)，其目标是C++函数，以及AlphaDev (Mankowitz等人, 2023a)，它在汇编级别发现了更高效的排序算法。这些任务特别具有挑战性，因为可能的代码转换搜索空间非常庞大。最近，KernelBench (Ouyang等人, 2024) 引入了一个专注于优化用高级PyTorch代码编写的机器学习模型到低级高性能CUDA GPU内核的基准。(Gong等人, 2025) 的调查。

### A.3 软件测试与程序分析

短期测试：对于短期测试如单元测试 (Lemieux等人, 2023) 和基于属性的测试 (Vikram等人, 2023)，LLM被用于自动生成针对性的测试用例 (Li和Yuan, 2024; M ¨undler等人, 2025)，甚至通过爬山算法在代码覆盖率上进行改进以提高测试效果 (Ryan等人, 2024)。在单个函数的粒度上，LLM生成的测试也被用于支持下游任务，如基于行为正确性的实现过滤 (Chen等人, 2022; Zhang等人, 2023b)，以及通过暴露错误行为的输入协助程序调试 (Chen等人, 2025)。

长期测试：长期测试涉及评估系统行为在扩展执行、复杂交互或多个组件中的表现，可能嵌入在CI/CD（持续集成或交付）管道中。模糊测试 (Miller等人, 1990) 是一种连续生成新随机输入的长期测试方法。最近的工作如Fuzz4All (Xia等人, 2024b)、KernelGPT (Yang等人, 2023a) 和OSS-Fuzz (Liu等人, 2023a; Chang等人, 2024) 表明，LLM可以通过更好的输入生成和探索策略显著提升效率。具体而言，OSS-Fuzz-Gen (Liu等人, 2024b) 使用多样化的LLM生成模糊测试框架，帮助发现新颖且复杂的崩溃交互。

静态分析漏洞检测：漏洞检测是指识别软件代码中的弱点或缺陷的任务，这些弱点或缺陷可能会被利用来危及系统的安全性、稳定性和正确性。大量的先前工作利用了诸如图神经网络（GNNs）和递归神经网络（RNNs）等机器学习模型来检测软件漏洞 (Zhou等人, 2019; Chakraborty等人, 2020; Dinella等人, 2020; Hin等人, 2022; Li等人, 2021)。虽然一些近期方法在特定数据集上预训练或微调LLM以改进漏洞分类 (Fu和Tantithamthavorn, 2022; Steenhoek等人, 2023; Cheng等人, 2022)，但若干研究已指出LLM在现实世界软件中的局限性 (Steenhoek等人, 2024; Ding等人, 2024a; Khare等人, 2023)。为应对这些局限性，Li等人 (2024a)、IRIS (Li等人, 2024f)、LLMDFA (Wang等人, 2024a) 和Infer-ROI (Wang等人, 2023) 等工作探讨了将静态分析工具（如CodeQL）与LLM结合以进行污点和资源泄漏分析的方法。更近一步，BigSleep (2024) 展示了在更大规模上使用LLM通过探索性变体分析发现真实的SQLite漏洞的潜力。

专用程序分析：除了长时间运行的分析以识别漏洞外，许多传统的程序分析方法尽管理论上很有前途但在实践中难以扩展。例如，推断程序不变量（即始终被认为在程序点处为真的属性）对传统符号方法如Daikon (Ernst等人, 2007; Padon等人, 2016) 来说是具有挑战性的，但它们对暴露bug (Hangal和Lam, 2002) 和辅助软件演化 (Ernst等人, 1999) 非常有价值。类似地，动态类型语言的类型推断受到规则方法覆盖限制的影响，并需要专门工具如ShapeIt (Zheng和Sen, 2024) 来解决领域特定挑战，如推断符号张量形状。

规范推断：规范推断任务是自动恢复程序预期行为的形式描述，包括前置条件、后置条件或不变量。规范的可用性是建立信任的核心 (Roychoudhury等人, 2025b)，现有的工作 (Dinella等人, 2024b; Ruan等人, 2024) 显示LLM可以帮助推断这些规范。例如，Dinella等人 (2024a) 提出了一个程序结构感知的技术，用于合成任意代码片段的前置条件，并建立了一个包含在真实Java项目上生成的18K LLM前置条件的数据集。

不变量推断：作为规范推断的一个子任务，不变量推断旨在推断循环、函数或类不变量，这对自动程序验证非常有帮助。已有几种基于LLM的不变量识别方法。它们通过结构化表示增强传统方法 (Si等人, 2018)，基于LLM的提示 (Kamath等人, 2023; Pei等人, 2023) 和重新排序 (Chakraborty等人, 2023)，以及

强化学习 (Yu等人, 2023)。同样，工作中使用了序列到序列模型 (Wei等人, 2023a)、少量样本LLM方法如TypeGen (Peng等人, 2023) 和生成-然后排名方法如TIGER (Wang等人, 2024b) 进行类型推断。因此，我们观察到新基准在此空间中出现，如LIG-MM (Liu等人, 2024a) 用于循环不变量检测。

二进制分析：前述任务主要集中在人类可读的编程语言上，但许多任务也可以扩展到操作编译后的机器代码或二进制文件上。一个突出的例子是二进制类型推断，它旨在从低级二进制代码中恢复高级类型信息。深度学习模型和LLM在此方面取得了显著改进 (Pei等人, 2021; Zhu等人, 2024)。这些进展与其他基于LLM的分析一起增强了反编译器的能力，使它们能够从二进制文件中合成人类可读的代码 (Liu等人, 2025a)。除了反编译之外，LLM还被应用于检测二进制文件中的安全漏洞 (Liu等人, 2023c) 以及生成捕捉二进制代码高层意图的语义摘要 (Jin等人, 2023)。

A.4 软件维护

代码导航：代码导航指的是根据自然语言描述 (Liu等人, 2024e) 或程序化规格 (Avgustinov等人, 2016) 在代码库中定位特定位置的任务。常见的用例包括确定某个功能的实现位置、追踪导致漏洞的用户输入源，或者在开始新功能开发时定位相关文件。此能力支撑了许多下游任务，如软件测试、漏洞检测、程序修复和代码问答。代码导航或代码搜索模块是现代代码代理的重要组成部分 (Yang等人, 2024b; Bouzenia等人, 2024; Xia等人, 2024a)，通常使用find命令、基于嵌入的相似性搜索或像CodeQL和Semgrep这样的查询工具实现。

代码文档和总结：已有几项工作使用LLMs进行代码总结，采用的技术包括提示 (Sun等人, 2024b; Su和McMillan 2024; Haldar和Hockenmaier, 2024; Ahmed等人, 2024b)。RepoAgent (Luo等人, 2024) 是一个框架，它分析源代码中的全局上下文关系以生成详细的文档。Shi等人 (2024) 显示，LMs能够生成良好的自然语言大纲——伴随代码的文字描述，将其划分为语义连贯的部分。一项挑战在于该任务的评估非常棘手：学术界目前缺乏包含良好文档的数据集和基准，自动评估指标与人工评估指标不一致 (Diggs等人, 2024)。

拉取请求（PR）审查：在工业界，自主软件代理如OpenHands (Wang等人, 2024g) 和 Devin 已经能够自动审查甚至修复PR。在字节跳动，BitsAI-CR (Sun等人, 2025) 是一个基于手动构建审查规则分类的代码审查系统。在学术界，已有几项工作研究了AI系统自动审查PR的能力 (Tufano等人, 2021, 2022; Li等人, 2022b, 2024b)。最近，AutoCodeRover (Zhang等人, 2024b) 将LLMs与代码搜索相结合，自动修复GitHub问题。

程序修复：自动化程序修复有着悠久的历史，涵盖不同范围和语言的许多基准。其中包括针对安卓应用的DroixBench (Tan等人, 2018)；针对Java的实际问题的Defects4J (Just等人, 2014)，GitBug-Java (Silva等人, 2024b)，以及不断增长的Bugs (Jiang等人, 2021, 2022a,b)。还有多语言的BugSwarm (Tomassi等人, 2019)；LeetCode风格问题的DebugBench (Hu等人, 2024)，LiveCodeBench (Jain等人, 2024b) 和 Codeflaws (Tan等人, 2017) 等更多。

历史上，这个任务有许多技术，包括基于启发式的APR（使用遗传编程探索正确补丁的搜索空间）、基于约束的APR（将修复视为约束求解任务）、基于模式的APR（应用专家手工制作的修复模板）和基于学习的APR（使用语言模型）(Zhang等人, 2024a)。最近，随着LLMs的发展，出现了基于代理的方法，例如FixAgent (Lee等人, 2024)，它使用专注于不同调试方面的代理，以及RepairAgent (Bouzenia等人, 2024)，它调用合适的工具。另一方面，Agentless (Xia等人, 2024a) 使用三阶段过程：定位、修复和补丁验证。

最后，程序修复也已被用作改进代码生成的工具，其中错误消息和不正确的测试用例被反馈给模型以改进代码生成 (Madaan等人, 2023; Chen等人, 2024; Zhang等人, 2023a; Olausson等人, 2024; Zhong等人, 2024a; Tang等人, 2025)。这被称为自我修复或自我调试。有关自动程序修复的更全面调查，我们推荐读者查看 这个网站8。

代码理解和问答：多年来，人们一直在研究使用语言模型进行代码理解。早期的研究者使用了CodeXGLUE (Lu等人, 2021) 基准，其中包含了克隆检测、代码搜索、代码总结等任务。Nam等人 (2024) 创建了一个包含解释高亮代码部分和解释特定领域代码的功能的IDE插件，帮助用户理解代码。Yang等人 (2025) 提供了一篇关于推理增强代码智能的综述。

A.5 支架和元代码

除了代码生成之外，更广泛的软件工程生态系统还包括DevOps工作流、CI/CD管道和基础设施即代码（IaC）。LLM在生成、调试和解释CI/CD配置（如GitHub Actions、Jenkinsfiles）方面显示出特别的前景，协助环境设置、测试编排和部署逻辑。爱立信的一项案例研究 (Chaudhary等人, 2024) 展示了如何使用基于LLM的聊天机器人支持CI/CD问答，使工程师更好地理解和管理部署管道。LLM也在异构软件环境中进行自动化测试方面得到探索。ExecutionAgent (Bouzenia和Pradel, 2024) 提出了一种由语言模型驱动的代理，可以自主安装、配置并为任意项目运行测试套件。

除了CI/CD和测试之外，LLM越来越多地用于推理配置逻辑和支架代码，这是现代软件系统中关键但常常被忽视的一层。例如，Yin等人 (2011) 对实际配置错误进行了实证研究，识别了失败的系统原因，如外部依赖、参数间冲突和默认参数的忽略。以此为基础，Ciri (Lian等人, 2024) 确认了使用LLM进行配置验证的可行性。此外，在IaC领域，对812个开源Terraform项目的实证研究表明，尽管访问策略普遍采用，但诸如静态加密等关键实践往往被忽视 (Verdet等人, 2023)。这凸显了LLM协助从业者检测和强制执行IaC配置中最佳安全实践的机会。

8https://program-repair.org/

A.6 形式化验证

近年来形式化软件验证出现了多种成功的编程语言设计原则。其中一些流行的语言包括TLA (Lamport, 1994)，Coq (The Coq Development Team, 2024)，Lean (De Moura等人, 2015)，Dafny (Leino, 2010)，Isabelle (Nipkow等人, 2002) 和Verus (Lattuada等人, 2024)。

形式软件验证在过去几年中取得了一些重大成功：Astrée (Cousot等人, 2005) 完全验证了Airbus A340的主要飞行控制软件没有运行时错误，验证了132,000行C代码。更近的是，形式方法被应用于验证密码服务器 (Erbsen等人, 2024) 和硬件和软件级别的IoT灯泡 (Erbsen等人, 2021)。CompCert (Leroy等人, 2016) 和 seL4 (Klein等人, 2009) 展示了形式方法在可验证代码方面的潜力。在亚马逊，形式方法被用于验证和保护密码软件 (Goel等人, 2024)、云资源 (Xu等人, 2024b) 和授权 (Disselkoen等人, 2025)。值得注意的是，SV-COMP (Beyer, 2023) 是一个年度竞赛，旨在使用整理好的可验证C和Java代码基准评估程序验证器。它甚至包括来自Linux Driver Verification (LDV) 项目 (Beyer和Petrenko, 2012) 的样本，有助于验证Linux内核设备驱动程序。对于更多应用，我们参考Huang等人 (2023) 的调查。

最近，LLMs编写形式化验证代码的能力得到了关注。基准如DafnyBench (Loughridge等人, 2024) 和 miniCodeProps (Lohn和Welleck, 2024) 分别被设计用来衡量LLMs在Dafny和Lean中编写软件证明的能力。在Dafny中，Poesia等人 (2024) 使用搜索和提示的组合创建了一个注释的综合数据集，极大地提高了DafnyBench的表现。Clover (Sun等人, 2024a) 生成代码的同时进行一致性检查（如Dafny注释），Li等人 (2025c) 使用Dafny作为中间语言来改进代码生成，而Misu等人 (2024) 探索了提示和检索生成Dafny的方式。在Rust中，Verus是一种流行的形式验证语言，AlphaVerus (Aggarwal等人, 2024) 和 AutoVerus (Yang等人, 2024a) 生成了经过验证的Rust函数的规范和证明。也有许多IDE插件设计用于帮助人类在形式语言如Dafny和Lean中编写代码，如Silva等人 (2024a)，Lean Copilot (Song等人, 2024) 和llmstep (Welleck和Saha, 2023)。

最后，使用形式语言如Lean进行数学定理证明的工作兴趣正在增长，这在 Li等人 (2024e) 和 Yang等人 (2024d) 中得到了全面覆盖。

参考 Paper:https://arxiv.org/pdf/2503.2262