Beyond Resolved Rate: A Non-Functional Quality Study
这项研究表明，尽管较新的 AI 模型比早期版本能解决更多的仓库级编程任务，但在两代模型均能成功解决的任务中，它们在静态分析、代码复杂度或资源使用等非功能性质量指标上并未表现出持续的改进。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一个计算机已经学会编写代码的世界，它们就像不知疲倦的初级程序员，能够修复漏洞、构建功能，甚至重构整个软件项目。这就是大语言模型（LLM）在软件工程领域的领域。长期以来，我们衡量这些数字程序员的唯一方法就是问一个简单的问题：“他们修好漏洞了吗？”如果代码通过了测试，它就会获得一颗金星。这被称为“功能正确性”。但仅仅因为汽车引擎能启动，并不意味着刹车灵敏、漆面耐用或燃油效率高。在现实世界中，软件需要具备安全性、易维护性，以及足够快的速度以确保不会导致电脑崩溃。这些被称为“非功能性质量”。研究人员现在提出的重大问题是：随着这些 AI 模型变得越来越聪明和更新，它们是在仅仅变得更擅长解决眼前的问题，还是也在编写更整洁、更安全且更高效的代码？
这篇题为《超越解决率》（Beyond Resolved Rate）的论文深入探讨了这一谜团。作者是来自瑞典林雪平大学的一个团队，他们决定不再仅仅计算 AI 修好了多少个漏洞，而是开始检查它是“如何”修复这些漏洞的。他们将这些 AI 模型比作烹饪比赛中的选手。评委（研究人员）给他们布置了一项特定的任务：修复一个损坏的食谱（软件项目中的一个漏洞）。旧的模型是资深选手，而新的模型则是崭露头角的明星。目标不仅是看谁能端出一道味道正确的菜肴（通过测试），还要看这些更新一代的厨师是否使用了更好的食材、产生了更少的浪费，并为下一位厨师创造了一个更安全的厨房。
研究人员使用一个名为 SWE-bench Lite 的流行基准测试搭建了一个严谨的实验，该测试包含真实的软件修复任务。他们让两代模型在两个不同的家族中进行对决：商业化的“Claude”家族和开源的“DeepSeek”家族。他们提取了旧模型和新模型生成的补丁（代码修复），并让它们通过一系列高科技检测。他们使用 CodeQL 和 CodeScene 等工具来扫描安全风险、混乱的代码结构和可维护性问题。他们还记录了代码运行所需的时间，并测量了它消耗了多少内存，将计算机视为一只需要高效喂养的饥饿野兽。
结果带来了一个情节转折。更新、更“聪明”的模型确实修复了更多的漏洞。它们解决了比旧兄弟姐妹更多的实例，从而获得了更高的“解决率”。然而，当研究人员观察两个模型都成功解决的任务所产生的代码质量时，故事发生了变化。新模型并没有在非功能性质量上表现出任何持续的进步。事实上，数据表明，新模型引入代码异味（code smells）、安全风险或性能问题的可能性与旧模型大致相同。
具体而言，研究发现对于两个模型都解决的任务，新模型并没有产生明显更整洁的代码。静态分析工具显示，两者引入新问题的数量大致相当。在性能方面，新模型对资源的占用略显“贪婪”。在共同的任务中，较新的 Claude 模型比旧版本多消耗了约 0.048 秒的 CPU 时间和约 4.5 MiB 的峰值内存。较新的 DeepSeek 模型则多消耗了约 0.5 MiB 的内存。虽然这些数字很小，但它们表明，变得更擅长修复漏洞并不自动意味着变得更擅长编写高效的代码。
作者还观察了代码的“风味”。他们检查了新模型是否在避免特定的坏习惯，比如混乱的变量名或杂乱的导入。结果是复杂且不一致的；有时新模型在某项规则上表现更好，有时则是旧模型更好，但并没有明显的趋势表明新一代在代码质量上具有普遍的优越性。
最终，这篇论文表明，虽然 AI 模型在“做什么”（修复漏洞）方面变得越来越强，但仅仅凭借其“更新”这一属性，它们并不一定在“怎么做”（编写高质量、可维护的代码）方面变得更好。作者警告说，更高的漏洞修复成功率并不保证整体软件工程水平的提升。他们认为，我们需要超越简单的通过/失败评分，开始衡量 AI 生成代码的隐藏成本，例如安全风险和维护难题，从而真正理解这些数字助手在现实世界中的表现。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。