Evaluating and Mitigating the Misguidance Effect of Buggy Code in LLM-Generated Unit Tests
本文识别并量化了“误导效应”，即有缺陷的代码会促使大语言模型生成验证错误而非检测错误的测试，并提出了一种基于规范的提示范式，通过利用生成的规范替换有缺陷的代码，从而有效地缓解这一问题，以生成更有效的单元测试。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下你是一个试图学习如何烘焙完美蛋糕的机器人厨师。你有一本食谱书，但其中一页被一个混乱且错误的指令弄脏了：“加入一杯盐而不是糖。”如果你向一个聪明的 AI 请教如何编写一个测试来检查蛋糕的味道是否正确，并把那张弄脏的页面展示给它，AI 可能会感到困惑。它可能会想：“哦，食谱说要加盐，所以这个蛋糕应该是咸的！”然后它会写出一个测试说：“美味，这个咸味蛋糕很完美！”这并不是说 AI 很笨，它只是太“乐于助人”了。它在试图理解给定的指令，即便这些指令是错误的。这就是软件测试领域的一个核心问题，在这个领域，计算机通过检查其他计算机来确保它们不会崩溃或表现异常。
在这个数字厨房里，“大语言模型”（LLs）是那些超级聪明的 AI 厨师。它们非常擅长编写代码和创建“单元测试”，而单元测试就像是微小的“味觉测试”，用来检查程序的特定部分是否工作正常。通常，科学家们通过给这些 AI 厨师提供完美的、没有漏洞的食谱来进行测试。但在现实世界中，我们需要测试的代码往往本身就是有问题的。这篇论文提出了一个可怕的问题：当我们要求一个 AI 为一个已经出错的食谱编写味觉测试时，会发生什么？AI 是会修复这个错误，还是会不小心习得了这个错误并试图证明它是正确的？
这篇论文的作者 Junda Zhao、Shurui Zhou 和 Eldan Cohen 决定调查这种“误导效应”（misguidance effect）。他们发现，当你向 AI 展示一段有缺陷的代码时，AI 经常会被欺骗。它并没有写出“嘿，这坏掉了！”这样的测试，而是写出了“这个坏掉的东西完全符合预期！”这样的测试。这就像 AI 厨师品尝了咸味的蛋糕，然后写下一篇评论说：“五星好评！这种咸味是一个特色，而不是一个错误。”
研究人员发现这种效应是“双重打击”。首先，它产生了大量的“误导性测试”，这些测试验证了错误。其次，它阻止了 AI 编写能够真正发现漏洞的“有效测试”。这就像 AI 太忙于为错误辩护，以至于忘记了去寻找真正的核心问题。为了证明这不仅仅是一个偶然现象，他们观察了 AI 的“大脑”（其内部评分系统），发现当面前是那段错误的代码时，AI 确实更倾向于选择那个错误的答案。
那么，如何修理一个被坏食谱搞糊涂了的厨师呢？你不能只是把坏食谱给它，然后寄希望于它能自行发现。相反，作者尝试了一个聪明的技巧：他们要求 AI 先写一段关于蛋糕“应该”是什么味道的描述，完全忽略掉那些混乱的指令。他们称之为“规范说明”（specification）。然后，他们让 AI 根据这个描述，而不是根据那份破损的食谱，来编写味觉测试。
结果令人惊喜。通过用清晰的行为描述替换掉破损的代码，AI 不再编写赞美咸味的测试，而是开始编写能够正确识别缺失糖分的测试。作者发现，这种方法减少了那些困惑且错误的测试数量，并显著增加了能够实际捕捉到漏洞的测试数量。他们甚至尝试了一个更高级的版本，即让 AI 在编写描述之前先分析食谱中的错误，效果甚至更好。
至关重要的是，论文表明即使食谱没有问题，这个技巧同样有效。如果代码本身已经是完美的，使用描述而非代码并不会让测试变差；它只会让测试保持同样优秀的水准。这意味着该方法在现实世界中是安全可用的，因为在现实中，我们往往不知道正在测试的代码是否是有问题的。
简而言之，这篇论文表明，当我们希望 AI 在软件中寻找漏洞时，我们不应该只是把破损的代码交给它并祈祷好运。相反，我们应该先让 AI 想象代码“应该”做什么，然后针对那个完美的愿景进行测试。这是一个简单的视角转变，它帮助 AI 停止成为破损代码的“唯唯诺诺者”，转而成为软件质量的真正侦探。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。