Meta 详解 Catching JiTTests 全量部署：LLM 生成测试在代码合入前捕获 bug

Meta Engineering Blog·2026-10-30 00:00· 1 小时前AI 评分66

在缺陷上线前捕获它们：JiTTesting 在全规模下的人类在环方法

AI 导读

Meta 介绍其 LLM 驱动的 Catching JiTTests 已从研究原型进入生产基础设施，通过 dodgy diff 和 intent-aware 两条工作流自动生成测试，在代码合入前暴露 bug，并用 RubFake 规则与 LLM-as-Judge 集成过滤误报、以 human-on-the-loop 方式降低人工审查负担。

正文 · 原文

在过去一年里，我们一直在分享利用大语言模型即时捕获缺陷的工作——我们称之为 Catching Just-in-Time Tests（JiTTests）的一种新方法。
现在，我们分享将 Catching JiTTests 部署到生产环境后所看到的结果和积极影响。
我们的论文《Just-in-Time Catching Test Generation at Meta》完整详述了 Catching JiTTests 的初始部署与测试情况。

每一次代码变更都在改进我们的平台，但也引入了新的复杂性。在 Meta，数亿行代码持续演进，传统测试无法跟上节奏。在代码合入前主动捕获风险，使我们能够更早识别风险、更有效地响应，并大规模交付可靠的体验。

在过去一年里，我们分享了关于应用大语言模型（LLM）生成软件测试的研究。更具体地说，我们分享了在 Just-in-Time Tests（JiTTests）方面的工作，这是一种新颖的测试方法，我们利用 LLM 即时捕获缺陷，甚至是传统测试可能无法捕获的缺陷。

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

Catching JiTTests 的优势

大多数基于 AI 的代码缺陷预防方法使用 LLM 和/或智能体 AI，基于过往经验审查代码并检测故障。它们通过人类审查者会采用的同一审查流程工作，只是速度更快。Catching JiTTests 是一种根本不同的方法（表 1）：它生成可执行测试，以展示变更引入的具体行为差异。虽然它需要更多计算步骤，但它能捕获基于 LLM 或智能体的代码审查可能无法捕获的各类缺陷。

表 1. 传统基于 LLM 的代码审查与 Catching JiTTests 的关键差异。

我们如何在 Meta 实施 Catching JiTTests

JiTTests 自动生成，并被设计为失败，从而在代码变更（diff）进入生产环境之前暴露其中的缺陷。当它们应用于像 Meta 这样庞大的代码库时，一个挑战是区分强捕获（即揭示真实缺陷的真阳性失败）与弱捕获（即可能是误报的测试）。

归根结底是一个具体问题：对于每一个提议的 diff，我们如何自动生成测试，在造成严重问题之前发现最严重的缺陷，并以高真阳性率做到这一点，同时不妨碍工程师的工作速度？

为此，我们开发了两条协同工作流：

一种“意图感知”工作流，它会推断代码变更的意图和风险，并将测试生成定向到可能的故障点。
一种“可疑差异”工作流，它将每个代码变更都视为变异体/缺陷，并生成测试以暴露其行为差异，而不对意图进行推理。它隐含地断言某个差异是有缺陷的（因此称为“可疑”）。

为了过滤误报，我们采用了传统的基于规则的方法，并结合一种我们称为“LLM-as-Judge”的集成方法，该方法汇总来自多个最先进（SOTA）LLM 的判断，所有这些 LLM 的任务都是将弱捕获分类为可能的真阳性或假阳性。

我们还保留了人工审查，并着眼于减少审查负担。我们的目标是保持人工标注的一致性，同时降低工程师被引入审查弱捕获的可能性。

工作原理

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

阶段 1：定向与触发

系统在夜间利用空闲容量运行，并使用类似于 Diff Risk Score (DRS) 的机制，针对前一天提交的、被认为“有风险”的差异，并基于先前的代码变更进行训练。这有助于确保测试生成聚焦于最可能包含严重回归的差异。

阶段 2：两个差异感知的测试生成工作流

可疑差异工作流将每个差异视为变异体，并使用变异引导的基于 LLM 的测试生成来生成能够区分差异行为与其父版本的测试。这里的目标是最大化弱捕获池，从而增加在其中找到强捕获的机会。

同时，意图感知工作流使用 LLM，通过代码变更、差异标题和摘要来推断差异的意图。然后，LLM 描述“风险”——即尝试实现该意图可能产生错误的方式。接着，它使用这些风险描述来构造变异体——每个变异体代表在实现推断意图时可能引入的一个缺陷。

生成测试以杀死每个变异体（即区分变异体行为与父版本）。

然后，这些测试会在实际差异上运行。任何失败的测试都会被收集为弱捕获。

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

一旦生成弱捕获，系统必须确定每个弱捕获是假阳性还是实际上是强捕获（真阳性）。

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

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

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

我们用一种更传统的、基于规则的方法来补充 LLM-as-Judge，该方法称为基于规则的假阳性消除环境（RubFake）。

LLM-as-Judge 具有丰富的语义，但其判断是非确定性的，且难以验证。相比之下，RubFake 提供经过验证的、确定性的判断。RubFake 与 LLM-as-Judge 协同工作，对弱捕获候选者生成总体排名，排名足够高的候选者值得进一步考虑。

阶段 5：人在环上（工程师主动联系）

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

我们并未采用人在环中（human-in-the-loop）的方式——即由人类工程师审查每一个输出——而是通过人在环上（human-on-the-loop）的方式减少摩擦：人类工程师设定标准，并在总体层面审查结果，而非监督每一个输出。

Catching JiTTests 在 Meta 的影响

测试系统就位后，我们的目标是让工程师参与其结果。

截至本文撰写时，Meta 已有 589 名工程师（占我们主动联系人数的 64%）参与了 Catching JiTTests。这些工程师反馈称，Catching JiTTests 能发现真正可操作的发现，真阳性率为 60%。

2026 年上半年，Catching JiTTests 在 diff 阶段发挥了关键作用，捕获了 74 个严重的（SEV）隐私缺陷，使其在生产环境上线之前就被拦截，并将该时间段内隐私 SEV 的总体发生率降低了 20%。

图 2. 2026 年上半年 Catching JiTTests 在 Meta 的影响。

为何重要

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

Catching JiTTests 是一种在技术上和社会上均可扩展的解决方案。将这些测试与人在环上的方式相结合，有助于确保工程师很少需要阅读测试代码，只需确认观察到的行为变化是否是预期的。

该方法具有通用性：工程师尽早定义成功标准，让 AI 执行测试，在总体层面监控结果，并在策略层面而非逐项进行干预。

阅读论文

我们的论文《Just-in-Time Catching Test Generation at Meta》已在 FSE 2026 上展示，并在 Product@Scale 上亮相，详细介绍了我们在 Meta 基础设施中初步部署和测试 Catching JiTTests 的情况。

文章 Catching Bugs Before They Land: JiTTesting’s Human-on-the-Loop Approach at Full Scale 首次发表于 Engineering at Meta。

来源：Meta Engineering Blog · engineering.fb.com