TL;DR

TestExplora 把 LLM 评测的目标从「能不能修 bug」换成「能不能主动找 bug」， 在 2,389 个任务、482 个真实仓库上盲测，结果当前 SOTA 模型 Fail-to-Pass 仅 16.06%。 这个数字告诉我们：让模型「补测试」和「找 bug」是两件截然不同的事。

重新定义软件保证的三个层次

软件工程里的 LLM 评测，大方向上可以分为三类：

  1. 回归预防（Regression Prevention） — 已有代码是真理，测的是「改完有没有破坏现有功能」
  2. 被动复现（Reactive Reproduction） — bug 报告出来了，测的是「能不能复现并修复」
  3. 主动发现（Proactive Discovery） — 还没人报 bug，测的是「能不能在破坏发生前找到它」

问题是：几乎所有主流评测（SWE-bench、BigCodeBench 等）都落在前两类。第三类几乎没人做。

TestExplora 要填的就是这个坑。

核心设计：把缺陷信号藏起来

TestExplora 的关键设计原则只有一条：模型看不到任何缺陷相关的提示。

具体做法：

  • 文档作为 Oracle：不告诉模型哪里有 bug，只给文档（README、API 描述、设计意图），让它自己对比实现与文档的落差
  • 跨模块探索：真实仓库里，一个 bug 往往跨越多个文件/模块，模型必须能追踪调用链、理解模块间交互
  • 持续时间感数据收集：随时间滚动采集任务，防止数据污染和评测泄露

评测指标用的是 Fail-to-Pass（F2P）：模型生成的测试用例，在有 bug 的版本上失败，在修复后的版本上通过——这才是真正「主动发现 bug」的证明。

数据：SOTA 模型 F2P 仅 16%

核心结果扎眼：

模型 F2P F2P@5
GPT-5-mini（无 agentic 探索） ~16% -
SWEAgent + GPT-5-mini（agentic 管道） 17.27% 29.7%
当前 SOTA 上限 16.06% -

几个值得注意的细节：

  • Agentic 探索有用但有限：加了跨模块导航工具后有提升，但幅度不大，说明当前模型的主动探索能力仍然很初步
  • 跨模块交互是瓶颈：分析显示，最常见的失败模式是「无法追踪多文件间的调用链」
  • F2P@5 显著高于单次 F2P：说明模型有一定的「尝试运气」，但不稳定

为什么重要：SWE 正在从「修」到「审」

SWE-bench 类评测的本质是「给定 bug 报告，模型能不能修」。这是工程师日常工作的下游。

TestExplora 指向的是更上游的能力：在没有 bug 报告的情况下，模型能不能像资深工程师一样做代码审计。

这不是吹毛求疵。现实中：

  • 大型代码库有大量「文档和实现悄悄分歧」的角落
  • Code Review 时间有限，资深工程师不可能审计所有代码
  • 如果模型能做主动质量保证，每次 PR 提交时自动扫描「实现与文档不一致」的潜在问题——这个场景 TestExplora 第一次给出了可量化的基线

批评性解读

这代模型的「测试直觉」仍然很弱。16% 的 F2P 意味着平均要生成 6 次测试才能抓住一个 bug——在真实流水线里，这会被人类的 review 流程过滤掉。

Agentic 探索是方向但还不够。SWEAgent 的管道（Searcher → Reader → Writer → Verifier）是合理的，但「探索」本身的质量取决于模型的代码理解深度。当前模型的跨模块推理仍是短板。

和评审训练的关系值得深究。如果模型能在预训练阶段见过更多「文档-实现分歧」的对比案例，F2P 率有没有可能大幅提升？这是下一步很值得做的实验。

原论文：TestExplora: Benchmarking LLMs for Proactive Bug Discovery via Repository-Level Test Generation（arXiv:2602.10471）