软件开发领域正处于一场由大型语言模型 (LLM) 驱动的革命之中。GitHub Copilot 和 ChatGPT 等工具已经展示了令人惊叹的能力: 它们可以自动补全函数、编写单元测试，甚至解决复杂的算法谜题。这让人很容易相信，我们要么即将迎来全自动化的软件工程时代，AI 可以接收高层需求并生成可直接部署的应用程序。

然而，在沙盒中生成排序算法与构建处理真实用户数据的健壮、安全的后端应用之间，存在着巨大的鸿沟。后端是现代软件的引擎室；它们需要跨越多个文件的复杂逻辑，严格遵守 API 规范，最重要的是，需要坚如磐石的安全性。

为了测试 AI 是否真正做好了应对“现实世界”的准备，来自苏黎世联邦理工学院 (ETH Zurich) 、LogicStar.ai、加州大学伯克利分校 (UC Berkeley) 和 INSAIT 的一组研究人员推出了 BAXBENCH 。 这个新的基准测试超越了简单的代码片段，旨在评估 LLM 在端到端后端生成方面的能力。

结果是一次清醒的现实检验。如下图所示，即使是最先进的旗舰模型，也难以生成既能工作又能安全部署的代码。

即使是旗舰模型也难以生成正确且安全的应用程序后端。

在这篇文章中，我们将剖析 BAXBENCH 论文，探讨研究人员如何建立这个严格的测试场，为什么当前的模型会失败，以及这对 AI 辅助开发的未来意味着什么。

当前基准测试的缺口

在深入了解 BAXBENCH 之前，了解为什么现有的基准测试还不够完善是很重要的。

大多数标准的编码基准测试，如 HumanEval 或 MBPP , 都侧重于函数级的任务。它们要求模型“编写一个 Python 函数来反转字符串”或“解决这个动态规划问题”。虽然这对于衡量基本的编码流利度很有用，但这些任务缺乏系统的上下文。它们没有测试:

  1. 系统级的一致性: 跨多个文件管理状态和逻辑。
  2. 框架知识: 正确使用 Django、Express.js 或 Spring Boot 等库。
  3. 安全性: 防御 SQL 注入、跨站脚本攻击 (XSS) 或未经授权的访问。

最近的基准测试如 SWE-bench 已经开始解决仓库级的编辑问题，但它们通常侧重于修补现有的错误，而不是从头开始生成功能。此外，安全性经常被视为事后的想法，或者使用静态分析工具进行隔离测试，而这些工具容易产生误报和漏报。

BAXBENCH 方法论

研究人员设计 BAXBENCH 是为了弥补这一差距，通过模拟真实的软件工程任务: “这是一个 API 规范。构建后端服务器。”

该基准测试围绕三个核心维度构建: 场景 (Scenarios) 、框架 (Frameworks) 和严格的评估 (Evaluation) 。

BAXBENCH 的结构和执行流程概览。

如上图 2 所示，该过程始于场景定义 (例如，计算器或购物车) 和目标框架 (例如，Python-Django) 。LLM 生成解决方案，然后在 Docker 容器中启动。最后，系统运行功能测试来检查它是否工作，并运行安全漏洞利用 (Exploits) 来检查它是否会被黑客攻击。

1. 场景: 契约驱动开发

现实世界的后端开发很少是模糊的。它通常由契约定义——具体来说，就是 API 规范。BAXBENCH 包含 28 个不同的场景 , 从简单的实用程序到复杂的多端点应用程序。

模型不再接收模糊的自然语言提示，而是获得了 OpenAPI 规范 。 这反映了行业的最佳实践，即前端团队和后端团队在编码开始前就 API 契约 (端点、请求体、响应格式) 达成一致。

场景经过精心挑选，涵盖了:

  • 实用性: 真实用例，如用户身份验证、电子商务购物车和文件管理。
  • 复杂性: 需要数据库交互和文件系统操作的任务。
  • 安全风险: 如果处理不当，自然容易受到攻击的应用程序。

表 4: BAXBENCH 的 28 个场景摘要。

2. 框架: 不仅仅是 Python

AI 开发者必须是多面手。仅仅懂 Python 是不够的；如果技术栈有要求，它必须知道如何用 Rust、Go 或 Ruby 构建服务器。BAXBENCH 评估了模型在 6 种编程语言 中的 14 个不同框架 上的表现。

这种多样性有助于识别模型是真正理解后端概念，还是仅仅从训练数据中背诵了大量 Python 代码。

表 1: BAXBENCH 中的框架概览。

3. 评估: 漏洞利用 > 静态分析

BAXBENCH 最重要的贡献在于其安全评估方法。许多先前的研究依赖于 静态应用程序安全测试 (SAST) 工具。这些工具扫描源代码中 看起来 像漏洞的模式。然而，SAST 工具充满了噪音——它们经常将安全的代码标记为危险 (误报) ，或者遗漏复杂的逻辑错误 (漏报) 。

BAXBENCH 采用了“黑盒”方法。对于每个场景，安全专家都编写了 实际的漏洞利用代码 。

  • 功能测试: 当我发送 2+2 时，端点 /calculate 是否返回 4？
  • 安全漏洞利用: 当我发送 2; DROP TABLE users 时，服务器是否会崩溃、泄露数据或执行恶意命令？

该基准测试跟踪 13 种特定的 常见缺陷列表 (CWE) , 涵盖了软件开发中最危险的漏洞，包括 OWASP Top 10。

表 5: BAXBENCH 覆盖的 CWE 摘要。

如果漏洞利用成功，代码无疑是不安全的。这里没有模棱两可的余地。

分析结果

研究人员评估了 11 个最先进的 LLM，包括 OpenAI 的 o1 和 GPT-4o，Anthropic 的 Claude 3.5 Sonnet，以及 Llama 3 和 DeepSeek 等开源模型。使用的指标是 sec_pass@k , 它衡量模型生成的解决方案既在功能上正确又安全的概率。

“正确但不安全”的陷阱

主要的发现令人震惊。如图 3 所示，即使是最好的模型也难以达到 40% 的正确且安全代码成功率 (sec_pass@1)。

图 3: 11 个 LLM 在 BAXBENCH 的 392 个任务上的评估结果。

仔细观察条形图 (图 3) 。条形的全高代表工作的代码 (通过功能测试) 。实心红色部分代表安全的代码。

  • 差值 (The Delta) : 阴影区域代表 工作完美但对黑客有漏洞的代码。
  • 统计数据: 在所有模型中，大约 50% 的功能正确程序是可以被利用的。

这证实了当前 LLM 的一个危险局限性: 它们优先考虑功能性而非安全性。它们会很乐意使用 eval() 来解决数学问题，因为这是通过测试的最简单方法，而忽略了这会为远程代码执行 (RCE) 打开大门的事实。

推理差距: 标准模型 vs. 推理模型

该研究强调了标准模型 (如 GPT-4o) 和“推理”模型 (如 OpenAI o1 或 o3-mini) 之间的区别。推理模型在输出 token 之前会“思考”，它们的表现明显更好。OpenAI o3-mini 获得了最高分，这表明“测试时计算” (模型在处理提示时花费的时间) 使其能够考虑标准模型可能会忽略的边缘情况和安全约束。

我们能仅仅通过提示来获得安全性吗？

提示工程中一个常见的反驳是: “你 告诉 模型要安全了吗？”

研究人员使用三种提示策略测试了这一假设:

  1. 无提醒: 仅任务规范。
  2. 通用提醒: “请遵循安全最佳实践。”
  3. Oracle 提醒 (先知提醒) : 明确列出与该场景相关的特定漏洞 (CWE) (例如，“在这个任务中小心 SQL 注入”) 。

图 4: 通用和 Oracle 安全提醒的影响。

结果 (图 4) 揭示了一个微妙的权衡:

  • Oracle 提示有助于安全性: 明确警告模型注意特定漏洞可以显著提高安全分数。
  • 权衡: 然而，增加安全约束通常会让模型在功能性方面感到困惑，导致 pass@1 (功能正确性) 下降。

有趣的是, 推理模型 (如 o1 和 o3-mini) 从通用提醒中获益最多。它们能够接受“要安全”这一抽象指令，并成功将其应用于代码而不破坏功能。标准模型 (如 GPT-4o 和 Claude 3.5 Sonnet) 从通用提示中获得的改进较少，表明它们缺乏从一般建议中推断具体安全要求的推理深度。

框架彩票

并非所有的代码生而平等。研究人员发现，语言/框架的流行度与模型的表现之间存在很强的相关性。

图 5: OPENAI O1 在不同框架上的表现。

如图 5 所示，OpenAI o1 在 Python-Django 和 JavaScript-Express 上表现令人钦佩——这些框架在训练数据 (GitHub, StackOverflow) 中有大量代表。然而，在 Rust-Actix 或 PHP-Lumen 上，表现则一落千丈。

至关重要的是，在不太流行的框架中，模型不仅无法编译；它们生成的代码 更有可能是不安全的 。 这表明 LLM 对安全性只有“肤浅”的理解。它们不一定理解“SQL 注入”的抽象概念；相反，它们见过数百万个如何在 Django 中清理输入的例子，但在专门的 Rust 库中见过的例子却很少。

复杂性扼杀性能

研究人员还分析了任务的复杂性 (通过 OpenAPI 规范的长度来衡量) 与成功率之间的关系。

图 6: 平均 pass@1 与每个场景的 OpenAPI 规范中的 token 数量的关系。

图 6 中的负相关性很明显: 随着规范变得越长越详细，模型正确实现它的能力就会下降。这突显了“上下文窗口”的限制，不仅在于 token 数量，还在于“注意力跨度”。在复杂的 API 契约中保持一致性仍然是自主生成的一个主要障碍。

深入挖掘: pass@k 指标

对于对评估指标感兴趣的学生来说，该论文使用了一种称为 pass@k 的统计估计量。由于 LLM 是概率性的 (每次生成的代码都不同) ，运行一次是不够的。pass@k 估计的是如果你允许模型尝试 \(k\) 次，至少有一个解决方案是正确的概率。

研究人员定义 sec_pass@k 的方式类似，但增加了一个约束条件，即通过的解决方案必须经受住所有的安全漏洞利用测试。

pass@k 的公式。

当研究人员将评估扩展到 \(k=5\) (给模型 5 次机会) 时，性能有所提高，但安全差距依然存在。

图 9: 我们的主要实验结果，显示了使用 Oracle 提示时的 pass@k 指标。

图 9 显示，即使有 5 次尝试和“Oracle”安全提醒 (最佳情况) ，功能代码 (全长条形) 和安全代码 (实色部分) 之间的差距仍然存在。

为什么模型会失败？

论文指出了几种失败模式:

  1. 样板代码疲劳: 模型经常在琐碎的任务上失败，比如设置正确的文件结构、处理多文件项目中的导入，或者配置服务器监听正确的端口 (0.0.0.0 vs localhost) 。
  2. “Eval”本能: 对于像计算器这样的任务，模型经常使用 eval()，它将字符串作为代码执行。这是解决数学问题的最简单方法，但也是一个灾难性的安全漏洞。实现一个正确的解析器“更难” (需要更多的 token/逻辑) ，所以模型选择了阻力最小的路径。
  3. 框架幻觉: 在不太流行的框架 (如 Rust-Actix) 中，模型经常发明不存在的函数或使用过时的语法，反映出缺乏基于库实际文档的依据。

对软件工程未来的启示

BAXBENCH 为行业提供了一次至关重要的现实检验。虽然 LLM 是强大的助手，但它们目前 不适合自主后端开发 。

研究结果提出了三个主要的改进方向:

  1. 测试时计算: 推理模型 (o1, o3-mini) 的优越表现表明，“思考时间”对于安全性至关重要。安全性是一个约束满足问题；模型必须在最终确定输出之前，根据安全规则检查自己的输出。
  2. 安全对齐: 我们需要训练模型更偏好安全的实现，即使它们更加冗长。模型应该“知道”编写解析器比使用 eval() 更好，即使这需要 50 行代码而不是 1 行。
  3. 智能体工作流: 虽然论文简要测试了智能体 (OpenHands) 并发现仅有适度的改进，但未来可能在于能够迭代运行测试、看到安全漏洞利用失败并自行修补代码的智能体——模仿人类开发者的工作流程。

结论

BAXBENCH 为 AI 生成的代码引入了一个严格的标准。通过将重点从简单的算法转移到全栈、安全的应用程序生成，它暴露了当前 LLM 的脆弱性。

对于学生和开发者来说，结论很明确: 使用 LLM 来加速你的工作，但永远不要相信它们能保障安全。 生成代码的能力已经超过了保护代码的能力，在这一差距缩小之前，人类工程师仍然是循环中最关键的安全屏障。

该基准测试已向社区开放以进行扩展，确保随着模型的发展，“可部署”的标准也在不断提高。