• 在过去一年里，我们一直在分享利用大语言模型即时发现 bug 的工作——这种新方法被我们称为 Catching Just-in-Time Tests（JiTTests）。
  • 现在，我们将分享把 Catching JiTTests 部署到生产环境后看到的成果和积极影响。
  • 我们的论文《Just-in-Time Catching Test Generation at Meta,” 详细介绍了 Catching JiTTests 的初次部署和测试情况。

每一次代码变更都在改进我们的平台，但也会带来新的复杂性。Meta 数亿行代码在不断演进，传统测试已难以跟上步伐。在代码合入之前主动发现风险，能够帮助我们更早识别风险、更有效地做出应对，并大规模提供可靠的体验。

在过去一年里，我们分享了应用大语言模型（LLM）生成软件测试的研究。更具体地说，我们分享了即时测试（JiTTests）方面的工作。这是一种新颖的测试方法，我们利用 LLM 即时发现 bug，甚至包括传统测试可能发现不了的问题。

自从我们首次公布这项工作以来，五个月里，我们部署了 Catching JiTTests 方法，以确定它的可扩展性以及在更广泛行业中的适用性。如今，Catching JiTTests 已不再是研究原型；它们已成为 Meta 基础设施的一部分，帮助工程师以更低的工作负担、更小的误报概率发现更多 bug。

Catching JiTTests 的优势

大多数基于 AI 的代码缺陷预防方法都使用 LLM 和/或智能体 AI，根据过往经验审查代码并检测缺陷。它们遵循与人工审查者相同的审查流程，只是速度更快。Catching JiTTests 采用的方法从根本上有所不同（表 1）：它生成可执行的测试，展示变更引入的具体行为差异。虽然它需要更多计算步骤，但能发现 LLM 或智能体代码审查可能遗漏的某些类别的 bug。

我们如何在 Meta 实现 Catching JiTTests

JiTTests 会自动生成，旨在通过测试失败的方式，在代码变更（diff）进入生产环境之前暴露其中的 bug。当它们被应用于 Meta 这样规模的代码库时，一个挑战是区分强发现（即揭示真实 bug 的真阳性失败）和弱发现（即可能是误报的测试）。

归根结底，这是一个具体的问题：对于每一个拟议的 diff，我们如何自动生成测试，在最严重的 bug 造成严重问题之前将其找出，同时保持较高的真阳性率，又不影响工程师的工作速度？

为了解决这个问题，我们开发了两条协同工作的流程：

  • 一条“意图感知”流程，推断代码变更的意图和风险，并针对可能出现故障的位置生成测试。
  • 一条“可疑 diff”流程，将每一次代码变更都视为一个变异体或 bug，不推断其意图，而是生成测试来揭示其行为差异。它隐含地断言 diff 存在 bug（“可疑”一词由此而来）。

为了过滤误报，我们将传统的基于规则的方法与一种集成方法结合起来；后者被我们称为“LLM-as-Judge”，它汇总多个先进（SOTA）LLM 的判断，所有这些模型的任务都是判断弱发现更可能是真阳性还是假阳性。

我们也保留了人工审查，同时着眼于减轻审查负担。我们的目标是保持人工标注的一致性，同时降低需要请工程师审查弱发现的概率。

工作原理

整个系统工作流程分为五个阶段：

阶段 1：目标选择与触发

系统利用闲置算力在夜间运行，针对前一天提交且被判定为“有风险”的 diff 开展工作。它使用一种类似于 Diff Risk Score（DRS）的机制，该机制基于以往的代码变更训练而成。这有助于确保测试生成聚焦于最可能包含严重回归问题的 diff。

阶段 2：两条感知 Diff 的测试生成流程

可疑 diff 流程将每个 diff 视为一个变异体，并使用变异引导的、基于 LLM 的测试生成来生成测试，以区分该 diff 与其父版本的行为。这里的目标是尽可能扩大弱发现的候选池，从而提高从中找到强发现的机会。

与此同时，意图感知流程使用 LLM，根据代码变更、diff 标题和摘要推断 diff 的意图。然后，LLM 会描述相关“风险”——即尝试实现该意图时可能出现错误的方式。接着，它利用这些风险描述构建变异体，每个变异体都代表实现推断出的意图时可能引入的一个 bug。

系统会生成测试来杀死每个变异体（即区分变异体与父版本的行为）。

随后，这些测试会在实际 diff 上运行。所有失败的测试都会被收集为弱发现。

阶段 3：LLM-as-Judge 集成（自动评估）

生成弱发现后，系统必须确定每一项是误报，还是实际上的强发现（真阳性）。

LLM-as-Judge 集成由一组 LLM 构成，它们会审查：

  • 弱发现的测试用例代码。
  • 测试执行结果（失败代码、消息、执行轨迹）。
  • 父版本与子版本之间的代码变更（diff）。
  • 推断出的 diff 意图。

阶段 4：基于规则的评估器（RubFake）

我们使用一种更传统的基于规则的方法来补充 LLM-as-Judge，称为 Rule-Based False-Positive Killing Environment（RubFake）。

LLM-as-Judge 具备丰富的语义理解能力，但它的判断具有非确定性，且难以验证。相比之下，RubFake 提供经过验证的确定性判断。RubFake 和 LLM-as-Judge 协同工作，对弱发现候选项生成综合排名，排名足够靠前的候选项值得进一步考虑。

阶段 5：人类监督（联系工程师）

根据 LLM-as-Judge 和 RubFake 的排名，系统随后决定是否联系人类工程师。

我们没有采用让工程师审查每一项输出的人在回路方法，而是通过人类监督方法减少工作阻力：工程师设定标准，并从整体层面审查结果，而不是监督每一项输出。

Catching JiTTests 在 Meta 的影响

测试系统就位后，我们的目标是让工程师关注并处理其结果。

截至撰写本文时，Meta 有 589 名工程师（占我们联系对象的 64%）参与了 Catching JiTTests。这些工程师反馈称，Catching JiTTests 揭示了真正可供采取行动的问题，其真阳性率达到 60%。

在 2026 年上半年，Catching JiTTests 在 diff 阶段发现 74 个严重（SEV）隐私 bug 方面发挥了关键作用，在它们进入生产环境之前将其发现，并使同期隐私 SEV 的总体发生率降低了 20%。

为什么这很重要

智能体软件开发正在帮助全行业的工程师和开发者以前所未有的速度编写、审查和发布代码。但部署速度加快也意味着测试需要更快。每一个在进入生产环境之前被发现的 bug，都是最终用户无需面对的问题。我们已经证明，LLM 可以提供额外的安全防护层，发现传统测试可能遗漏的问题，也证明了 AI 生成的测试可以扩展到足以降低组织风险的规模。

Catching JiTTests 是一种在技术和社会层面都具有可扩展性的解决方案。将这些测试与人类监督方法结合，有助于确保工程师很少需要阅读测试代码，只需确认观察到的行为变化是否符合预期。

这种方法具有普遍适用性：工程师尽早定义成功标准，让 AI 执行测试，从整体层面监测结果，并在策略层面而非逐项进行干预。

阅读论文

我们的论文《Just-in-Time Catching Test Generation at Meta,” 详细介绍了 Catching JiTTests 在 Meta 基础设施中的初次部署和测试情况。该论文曾在 FSE 2026 上发表，并在 Product@Scale 亮相。

文章 在漏洞进入代码库之前捕获它们：JiTTesting 大规模应用中的人在回路方法 最初发表于 Engineering at Meta。