AI生成的代码我们是否需要进行更多的测试？-Toy模板网

为了评估代码的适用性，我们需要借助一些工具来进行验证和验证。同时，自动化测试工具可以帮助我们检测代码的行为，并提高测试的自信度。

AI在帮我们写代码示意图

越来越多的软件开发中使用了基于人工智能的编码工具，例如GitHub Copilot，百度的文心一言，阿里的通义千问，还有各种人工智能工具。这些工具承诺提高生产力，但也有一些声称通过允许非程序员编写应用程序来实现编程的民主化。

但我们如何确切地知道由AI工具编写的代码是否符合预期目标？

接下来，我们将了解什么是“符合预期目标”，以及可以用来评估代码的工具。我们将看到，基于人工智能的编码工具无法保证其所建议的代码在功能正确性和安全性方面的任何问题。然而，我们还将看到，实际上存在一些可以帮助回答上述问题的AI工具。

回顾历史

值得一提的是，我们先稍微回顾一下历史，因为这个问题并不陌生：我们总是不得不问自己：“我们如何确切地知道由人类编写的代码是否符合预期目标？”几十年来，人们一直在苦苦思索软件工程中的这个根本问题以寻找解决方案。

从可编程计算机系统的早期开始，工程师们就遭遇了当程序无法按照他们的意图运行时的令人讨厌的惊喜。那时，调试和验证程序需要非常昂贵的试错周期。低级别的代码需要手工编写并打孔在卡片上。应对不必要的循环的主要对策是代码审查。代码审查意味着专家阅读并尝试理解代码的功能，并发现错误并提出改进建议。这是一项成功的技术，在今天仍被广泛实践。然而，随着程序规模和复杂性的增加，代码审查的有效性和彻底性显著降低，成本也急剧上升。

不久，问题出现了：如何以更严格的方式去判断程序是否按照预期运行？挑战在于如何表达程序应该做什么。需要以某种方式将用户真正想要的东西传达给机器。这是一个非常具有挑战性的问题，直到今天仍未得到完全解决。

这个问题在所有学科的产品工程中都是普遍存在的，并被分为两个步骤，通常可以表述为以下两个问题：

我们是否构建了正确的产品？
我们是否正确地构建了产品？

验证和验证

评估是否构建了正确的产品称为验证。最终用户会验证产品是否实现了其预期目标。验证从需求规范开始，它作为产品构建者与用户或客户之间的沟通手段。规范应该能被双方理解：用户（领域专家）和工程师（可能不是领域专家）。验证的目标是评估产品的实现是否符合需求规范。验证显然是一个更难的问题。什么是“正确”的产品高度主观，并且很难进行自动化。

好消息是，验证部分可以完全自动化：从计算和复杂性理论的限制来看，可以数学证明实现满足规范。这个学科被称为形式方法或形式验证，它依赖基于逻辑的形式化描述来编写规范，并使用自动推理来执行证明。

尽管听起来很有前途，但主要问题仍然是谁来编写规范。这需要找到一个既是领域专家又是编写形式规范专家的人员，而这类人非常难以找到并且非常昂贵。即使找到了这样的人，并且成功验证了实现，问题仍然存在验证部分，即规范是否实际上从用户的角度描述了正确的产品。

通常观察到规范往往比实现“更错误”，因为编写准确的形式规范极其困难。将自动推理扩展到大型系统仍然是巨大的挑战。在实践中，形式验证已经在嵌入式控制、密码学、操作系统内核和智能合约等小型、复杂且关键（安全、保密、金融）软件的领域找到了应用。

不同的观点

在20世纪70年代，出现了一个从不同角度解决问题的想法，称为N-版本编程。基本思想是由于编写程序甚至规范都非常困难，因此让多个独立团队来实现系统，然后对输出进行投票。其基本假设是不同的团队会犯不同的错误；他们可能对需求规范有不同的解释。因此，整体上结果在验证和可能还包括验证方面将比单个实现“更正确”。然而，事实证明这一假设是错误的：后来的研究表明，即使是独立的团队也会犯相同的错误。

这种方法的遗产是将验证视为2版本编程：需求规范和实现是同一个硬币的两面。它们用不同的形式和观点以不同的方式描述相同的系统。此外，它们通常由不同的人或团队编写。规范与实现在任何意义上都不是“更正确”的。这种思维方式可以引导我们对实际可实现的目标有一个现实的看法。

那么为什么我们要同时需要规范和实现呢？好处来自于2版本编程：比较同一系统的两个描述可以让我们在它们之间达成一致时增加信心，并在它们之间发现错误，从而使我们能够反思两个描述，并最终得到“更正确”的描述。