北航大学团队突破：AI代码生成不再"自欺欺人"，用属性测试让程序真正靠谱

这项由北京航空航天大学软件学院何乐涵、陈泽仁、高翔、张哲、盛禄等研究人员，以及上海人工智能实验室邵静共同完成的研究发表于2025年6月的arXiv预印本平台（论文编号：arXiv:2506.18315v1）。感兴趣的读者可以通过该编号在arXiv官网查阅完整论文。

当下的人工智能已经能够根据我们的需求自动生成代码，就像一个永不疲倦的程序员助手。GitHub Copilot这样的工具已经走进了千家万户的开发环境。然而，这些AI生成的代码就像一道看起来美味但可能有毒的菜肴——表面上语法正确，运行起来却可能漏洞百出。

传统的解决方案就像给厨师配备一个品尝员：通过测试用例来检验代码是否正确。这种被称为"测试驱动开发"的方法确实有效，但存在一个致命缺陷——如果测试用例本身就有问题呢？这就好比品尝员的味觉出了问题，明明菜里放错了盐却说味道刚好。更糟糕的是，很多时候我们根本没有足够的高质量测试用例，就像让品尝员在没有标准答案的情况下判断菜品好坏。

北航团队发现了一个更聪明的解决方案。与其让AI去猜测具体的输入输出应该是什么样子，不如让它理解程序应该遵循的基本规律。这就像不去记忆每道菜的具体味道，而是掌握烹饪的基本原理：炒菜不能糊、汤不能咸得发苦、甜品不能是酸的。

研究团队把这种方法称为"属性生成求解器"（Property-Generated Solver，简称PGS）。这个系统就像配备了两个专业人员的厨房：一个是负责做菜的厨师（生成器），另一个是负责制定和检查烹饪标准的质检员（测试器）。质检员不需要知道每道菜的具体味道应该是什么，只需要确保基本的烹饪原则得到遵守。

一、传统方法的根本缺陷：自欺欺人的恶性循环

为了理解这项研究的价值，我们需要先看看现有方法存在什么问题。设想你要让AI为你写一个数学函数，比如计算一个数字的质因数分解。传统的方法是给AI提供一些例子：12应该分解为[2,2,3]，15应该分解为[3,5]。然后让AI根据这些例子学会写代码。

但问题来了：如果AI对这个数学概念的理解本身就有偏差怎么办？比如它误以为质因数分解只需要找到能整除的质数，而忽略了重复因子的重要性。在这种情况下，它可能会给出12的分解结果为[2,3]，漏掉了一个2。

更糟糕的是，当我们要求这个有偏见的AI自己生成测试用例时，它很可能会生成同样错误的测试：认为12分解为[2,3]是对的。这样一来，错误的代码通过了错误的测试，整个系统陷入了"自欺欺人"的恶性循环。

传统测试方法还面临另一个挑战：预测正确答案往往比生成代码本身还要困难。考虑一个复杂的图着色问题——给地图上的每个区域涂色，确保相邻区域颜色不同。要为每种可能的地图配置都预测出正确的着色方案，这比编写解决这个问题的代码还要复杂。

第三个问题是现有测试往往只关注代码覆盖率——确保代码的每一行都被执行到——而不关心逻辑的正确性。这就像检查一道菜时只确保每种调料都用到了，而不管最终味道是否正确。

二、属性测试：从具体例子到抽象原则

北航团队的解决方案借鉴了一个在软件工程中相对小众但威力巨大的概念：属性测试（Property-Based Testing）。这种方法的核心思想是，与其关注具体的输入输出对应关系，不如关注程序应该满足的高层次属性或不变量。

继续用质因数分解的例子来说明。与其测试"12分解为[2,2,3]"这样的具体对应关系，属性测试会关注这样的规律："分解结果中所有数字的乘积必须等于原始数字"以及"分解结果必须按照非递减顺序排列"。这些属性相对容易定义和验证，而且不需要我们预先知道每个输入的正确答案。

这种方法的优势显而易见。对于图着色问题，我们不需要为每张地图都找出正确的着色方案，只需要验证"相邻区域的颜色不相同"这个简单属性。对于排序算法，我们不需要预测每个数组排序后的具体结果，只需要确保"结果是非递减序列"且"包含原数组的所有元素"。

属性测试还有一个重要特点：它能够自动生成大量多样化的测试输入。不像传统方法需要人工设计测试用例，属性测试系统可以根据问题的约束条件自动产生各种边界情况和特殊场景，大大提高了错误发现的概率。

三、双智能体协作：生成器与测试器的完美配合

PGS系统的核心是两个AI智能体的巧妙配合。这就像一个高效的软件开发团队：一个专注于编码实现，另一个专注于质量保证。

生成器（Generator）是团队中的"程序员"。它根据问题描述生成初始代码，然后根据测试反馈不断改进。与传统的单一AI不同，这个生成器专门优化了代码生成和迭代改进的能力。当它收到来自测试器的反馈时，能够精确定位问题所在并进行针对性修复。

测试器（Tester）则是团队中的"质量工程师"。它的工作流程包含几个关键步骤。首先，它分析问题描述，识别出程序应该满足的高层次属性。比如对于一个排序函数，测试器会识别出"输出必须是有序的"、"输出必须包含输入的所有元素"等属性。

接下来，测试器将这些抽象属性转换为可执行的检查代码。这些检查代码就像自动化的质检流程，能够对任何给定的输入输出对进行验证。测试器还会设计验证机制，确保这些属性检查本身是正确的——通过已知的正确案例验证检查代码不会误报，通过已知的错误案例验证检查代码能够成功发现问题。

测试器的另一个重要任务是生成多样化的测试输入。它不是随机生成数据，而是根据问题的特性和约束条件，系统性地创造各种测试场景：常见情况、边界条件、极端情况等。这确保了测试的全面性和有效性。

当生成器产生的代码被测试时，测试器会收集所有的执行结果，包括成功的案例和失败的案例。对于失败的案例，测试器不是简单地报告"测试失败"，而是会进行深入分析，找出最具代表性、最简洁的失败案例，并提供详细的错误描述和改进建议。

四、智能反馈策略：简单问题带来深刻洞察

在软件调试中有一个重要原则：最简单的能复现问题的输入往往最有助于定位和解决问题。北航团队在PGS中实现了这一原则，开发了一套智能的反馈选择策略。

传统的软件测试往往追求高代码覆盖率，认为测试应该触及代码的每一个分支和路径。但研究团队发现，对于AI代码生成来说，这种策略可能适得其反。复杂的测试用例虽然能够触及更多代码路径，但也可能让AI"迷失在细节中"，难以识别问题的核心所在。

相比之下，简单的测试用例更容易让AI理解问题的本质。比如，如果一个排序算法在处理包含重复元素的数组时出现问题，那么用[2,1,2]这样的简单例子比用包含几十个元素的复杂数组更容易让AI理解错误的根源。

PGS采用了类似于"增量调试"的策略：在所有导致属性违反的测试用例中，优先选择输入最短、执行时间最快的案例作为反馈。这种策略有多重好处。首先，简单的输入更容易让AI跟踪执行流程，理解错误发生的具体位置。其次，简单的案例往往能够暴露算法的根本性缺陷，而不是边界条件的特殊处理问题。最后，处理简单案例的计算成本更低，提高了整个迭代过程的效率。

研究团队通过实验验证了这一策略的有效性。在LiveCodeBench测试集上，使用最短输入长度的反馈策略比使用最长输入长度的策略在成功率上高出3个百分点，同时减少了12%的计算开销。

五、实验验证：全面超越现有方法

为了验证PGS的有效性，研究团队进行了大规模的对比实验。他们选择了三个具有代表性的代码生成基准测试集：HumanEval（包含164个手写Python编程问题）、MBPP（约500个众包的入门级Python问题）和LiveCodeBench（880个来自实际编程竞赛的挑战性问题）。

实验中使用了三个不同能力级别的大语言模型：DeepSeek-Coder-V2（专门优化的开源代码生成模型）、Qwen2.5-Coder（在编程任务上表现出色的通用模型）和DeepSeek-R1-Distilled-32B（具有长链式推理能力的高性能模型）。

PGS与多种现有方法进行了对比，包括直接提示、链式思维推理、Code-T（使用自动生成测试的方法）、Self-Edit（自我修正方法）、Reflexion（基于反思的迭代改进）等多种先进技术。

实验结果显示了PGS的显著优势。在pass@1指标（一次生成成功的比例）上，PGS相比传统测试驱动开发方法取得了23.1%到37.3%的相对提升。特别值得注意的是，在最具挑战性的LiveCodeBench测试集上，PGS在困难问题（Hard级别）上的表现尤为突出，成功率达到40.7%，远超直接提示方法的28.1%。

在修复成功率（RSR）指标上，PGS同样表现优异。这个指标衡量的是将初始错误代码修正为正确代码的能力。PGS在HumanEval和MBPP上平均比代表性的测试驱动开发方法高出约15.7个百分点，展现了其强大的迭代改进能力。

六、深入分析：为什么属性测试如此有效

实验数据揭示了PGS成功背后的深层原因。首先，研究团队发现，对于大语言模型来说，生成正确的属性检查代码比直接生成完整的解决方案要容易得多。在LiveCodeBench的难题中，直接生成正确代码的成功率只有1.1%，但生成有效属性检查的成功率高达48.9%。

这个现象背后有其合理性。定义"程序应该满足什么条件"往往比"程序应该如何实现"更加直观。比如，描述"排序后的数组应该是有序的"比实现"快速排序算法的具体步骤"要简单得多。

其次，属性测试能够将隐藏的逻辑错误转化为明显的运行时错误。在没有属性检查的情况下，25.3%的错误代码会产生"错误答案"——代码运行正常但结果不正确，这类错误最难调试。而引入属性测试后，这个比例降低到10.5%，同时"运行时错误"（包括属性违反）的比例从4.6%增加到11.8%。虽然总错误数量增加了，但错误变得更容易识别和修复。

第三，属性测试提供了更丰富的语义信息。传统的测试失败通常只告诉我们"期望输出X，实际输出Y"，而属性违反会告诉我们"违反了乘积相等性"或"违反了有序性"，这种高层次的错误信息更有助于AI理解问题的本质并进行针对性修复。

七、跨模型表现：通用性验证

PGS的另一个重要优势是其跨模型的稳定表现。无论是在能力相对较弱的DeepSeek-Coder-V2上，还是在性能强大的DeepSeek-R1-Distilled-32B上，PGS都展现出了一致的改进效果。这说明PGS的核心思想——将代码生成与验证解耦，通过属性测试提供高质量反馈——是一个通用的、不依赖特定模型架构的改进策略。

特别值得关注的是PGS在不同难度任务上的表现差异。在简单任务上，由于大多数现有方法已经能够取得较好效果，PGS的改进幅度相对温和。但在中等和困难任务上，PGS的优势愈发明显。这符合直觉：当问题变得复杂时，高质量的测试和反馈机制变得更加重要。

研究还发现了一个有趣的现象：随着任务难度增加，"通过了可见测试但最终失败"的情况越来越多。在简单任务中，这个比例是62.4%对65.9%（通过隐藏测试对通过可见测试），而在困难任务中变成了1.1%对18.1%。这个巨大的差距说明了传统测试方法在复杂问题上的局限性，也解释了为什么PGS在困难任务上的相对优势更为显著。

八、技术细节：让属性测试真正可行

虽然属性测试的理念很优雅，但要让它在实际的AI代码生成中发挥作用，还需要解决许多技术细节。

首先是属性质量的保证。并非所有AI生成的属性都是有用的，有些可能过于宽泛（比如"输出不能为空"），有些可能存在逻辑错误。PGS设计了一套验证机制：每个属性都必须通过已知正确案例的测试（确保不会误报），同时在已知错误案例上失败（确保具有发现错误的能力）。

其次是输入生成的多样性。属性测试的威力很大程度上依赖于能够生成多样化、有代表性的测试输入。PGS不是简单地随机生成数据，而是根据问题的约束条件和特性，系统性地创造不同类型的测试场景。对于排序问题，它会生成空数组、单元素数组、已排序数组、逆序数组、包含重复元素的数组等各种情况。

第三是反馈的精确性。当属性违反发生时，系统需要提供足够详细但不过于复杂的错误信息。PGS会识别违反的具体属性，提供导致违反的输入和输出，并用自然语言描述问题的本质。比如，不是简单地说"测试失败"，而是说"对于输入12，期望分解结果的乘积为12，但实际乘积为6"。

最后是迭代控制。PGS需要在"快速收敛"和"充分探索"之间找到平衡。系统设置了最大迭代次数限制（通常为5次），确保在合理时间内完成生成过程。同时，它也会动态调整属性的数量和复杂度，避免过度复杂的验证逻辑影响效率。

九、实际应用潜力与局限性

PGS的成功为AI辅助编程开辟了新的可能性。在实际软件开发中，程序员经常面临这样的情况：知道程序应该满足什么条件，但不确定具体如何实现。PGS提供了一种新的交互模式：开发者可以描述程序的功能需求和约束条件，让AI基于这些高层次的规格自动生成并验证代码。

这种方法在某些领域特别有价值。在算法竞赛中，问题通常有明确的输入输出格式和约束条件，但具体的解决策略需要创造性思维。PGS可以帮助参赛者快速验证算法思路的正确性。在教育领域，学生可以通过描述程序应该满足的性质来验证自己的代码实现，获得更有针对性的学习反馈。

然而，PGS也存在一些局限性。首先，它依赖于能够清晰描述程序属性的能力。对于一些涉及复杂业务逻辑或用户体验的应用，很难用简单的属性来完全描述程序的正确性。其次，当前的实现主要针对算法性问题，对于涉及用户界面、数据库操作、网络通信等的复杂软件系统，还需要进一步的扩展和适应。

研究团队也坦诚地讨论了一些技术挑战。属性的生成质量仍然依赖于大语言模型的理解能力，当面对全新的问题域时，可能会生成不够准确或不够全面的属性。此外，当前的实现主要关注功能正确性，对于性能、安全性、可维护性等其他软件质量属性的支持还有待加强。

十、未来展望：走向更智能的编程助手

这项研究为AI辅助编程的未来发展指明了一个重要方向：从"模仿人类代码"走向"理解程序本质"。传统的代码生成模型主要通过学习大量人类编写的代码来获得生成能力，本质上是一种模式匹配和组合。而PGS展示了另一种可能性：让AI理解程序应该满足的抽象性质，基于这些理解来生成和验证代码。

这种方法的潜在影响是深远的。它可能会改变我们与编程工具交互的方式：不再是告诉计算机"如何做"，而是告诉它"要达到什么目标"。这种声明式的编程范式可能会显著降低编程的门槛，让更多人能够参与到软件开发中来。

从技术发展的角度看，PGS也为形式化方法在AI时代的复兴提供了新的可能性。形式化方法一直是计算机科学中确保程序正确性的重要工具，但由于其复杂性，在实际开发中的应用有限。PGS展示了如何将形式化思想与现代AI技术结合，创造出既强大又易用的工具。

研究团队已经开源了PGS的实现代码，这为后续研究和应用提供了良好的基础。可以预期，未来会有更多研究者在此基础上进行扩展，将PGS的思想应用到更广泛的编程任务中，或者开发出更加智能的属性生成和验证机制。

说到底，这项研究最重要的贡献不是具体的技术实现，而是思维方式的转变。它提醒我们，在追求AI生成代码的表面正确性时，不要忘记程序背后的逻辑本质。通过将注意力从"生成什么代码"转向"满足什么性质"，我们可能找到了一条通往更可靠、更智能的AI编程助手的道路。这种方法不仅在当前显示出了明显的技术优势，更重要的是为未来的研究开辟了新的可能性，让我们对AI辅助编程的前景更加充满信心。

Q&A

Q1：属性测试跟传统的单元测试有什么区别？ A：传统单元测试需要预先设定具体的输入输出对（如输入12，期望输出[2,2,3]），而属性测试关注的是程序应该满足的通用规律（如"所有因子的乘积等于原数"）。属性测试不需要预知具体答案，只需要验证程序是否遵循基本原则，这样更容易发现深层逻辑错误。

Q2：为什么说传统AI代码测试会出现"自欺欺人"的问题？ A：当AI对问题理解有偏差时，它生成的代码和测试用例可能包含相同的错误逻辑。比如AI误解了质因数分解的概念，既会生成错误的代码，也会生成错误的测试案例，导致错误代码通过错误测试，形成恶性循环而无法发现真正问题。

Q3：PGS框架的两个智能体是如何分工合作的？ A：生成器专门负责编写和改进代码，就像程序员；测试器负责制定验证标准、生成测试数据和提供反馈，就像质量工程师。测试器会根据问题描述自动识别程序应该满足的属性，然后系统性地验证生成器的代码是否符合这些要求，形成高效的迭代改进循环。