- 在过去一年里，我们一直在分享利用大型语言模型即时捕获缺陷的工作——我们将这种新颖的方法称为即时捕获测试（JiTTests）。
- 现在，我们分享将 Catching JiTTests 部署到生产环境后所看到的结果和积极影响。
- 我们的论文《Meta 的即时捕获测试生成》完整详述了我们使用 Catching JiTTests 进行的初步部署和测试。
每一次代码变更都在改进我们的平台，但同时也引入了新的复杂性。在 Meta，数亿行代码不断演进，传统测试无法跟上步伐。在代码合入前主动捕获风险，使我们能够更早识别风险、更有效地响应，并大规模交付可靠的体验。
在过去一年里，我们分享了关于 应用大型语言模型（LLM）生成软件测试的研究。更具体地说，我们分享了我们在 即时测试（JiTTests），这是一种新颖的测试方法，我们利用 LLM 即时捕获缺陷，甚至是传统测试可能无法捕获的缺陷。
在我们首次公布这项工作后的五个月里，我们部署了 Catching JiTTests 方法，以确定其可扩展性以及对更广泛行业的适用性。如今，Catching JiTTests 已不再是研究原型；它们已成为 Meta 基础设施的一部分，帮助我们的工程师以更小的负载和更低的误报概率捕获更多缺陷。
Catching JiTTests 的优势
大多数基于 AI 的代码缺陷预防方法使用 LLM 和/或智能体 AI，基于以往经验审查代码并检测故障。它们通过与人审查者相同的审查流程工作，只是速度更快。Catching JiTTests 是一种 根本不同 的方法（表 1）：它生成可执行测试，以展示变更所引入的具体行为差异。虽然它需要更多计算步骤，但它能捕获基于 LLM 或智能体的代码审查可能无法捕获的各类缺陷。
我们如何在 Meta 实现 Catching JiTTests
JiTTests 是自动生成的，并被设计为失败，从而在代码变更（diff）进入生产环境之前暴露其中的缺陷。当它们被应用于像 Meta 这样庞大的代码库时，一个挑战是区分强捕获（即揭示真实缺陷的真阳性失败）与弱捕获（即可能是误报的测试）。
归根结底，这取决于一个具体问题：对于每一个待合入的 diff，我们如何自动生成测试，在严重问题发生之前发现最严重的缺陷，并且以高真阳性率做到这一点，同时不阻碍工程师的工作速度？
为解决这一问题，我们开发了两条协同工作流：
- 一种“意图感知”工作流，它推断代码变更的意图和风险，并将测试生成瞄准可能的失败点。
- 一种“可疑 diff”工作流，它将每一次代码变更都视为变异体/缺陷，并生成测试以暴露其行为差异，而不对意图进行推理。它隐含地断言某个 diff 是有缺陷的（因此称为“可疑”）。
为了过滤误报，我们采用了传统的基于规则的方法，并结合一种我们称为“LLM-as-Judge”的集成方法，该方法汇总来自多个最先进（SOTA）LLM 的判断，所有这些 LLM 都负责将弱捕获分类为可能的真阳性或假阳性。
我们还保留了人工审核，同时着眼于减少审核负担。我们的目标是保持人工标注的一致性，同时降低引入工程师来审核弱捕获的可能性。
工作原理
整个系统工作流程分为五个阶段：
阶段 1：定向与触发
系统在夜间利用空闲算力运行，针对前一天提交的、被判定为“有风险”的 diff，判定机制类似于 Diff Risk Score（DRS） ，并基于以往的代码变更进行训练。这有助于确保测试生成聚焦于最可能包含严重回归的 diff。
阶段 2：两个感知 diff 的测试生成工作流
这个 可疑 diff 工作流 将每个 diff 视为变异体，并使用变异引导的基于 LLM 的测试生成来生成能够区分该 diff 与其父版本行为的测试。这里的目标是最大化弱捕获池，从而增加在其中找到强捕获的机会。与此同时，意图感知工作流使用 LLM 通过代码变更、diff 标题和摘要来推断该 diff 的意图。然后，LLM 描述“风险”——即尝试实现该意图可能产生错误的方式。它 视为变异体 并使用 变异引导的基于 LLM 的测试生成 生成能够区分该 diff 与其父版本行为的测试。这里的目标是最大化弱捕获池，从而增加在其中找到强捕获的机会。
同时， 意图感知工作流 使用 LLM 通过代码变更、diff 标题和摘要来推断该 diff 的意图。 推断该 diff 的意图 利用代码变更、diff 标题和摘要。随后，LLM 描述 “风险”——即尝试实现该意图可能产生错误的方式。然后，它利用这些风险描述来 构造变异体 ——每个都代表在实现推断意图时可能引入的一个缺陷。
生成测试是为了 杀死每个变异体（即区分变异体行为与父版本）。 （即区分变异体行为与父版本）。
随后，这些测试会在实际的 diff 上运行。任何失败的测试都会被收集为弱捕获。
阶段 3：LLM-as-Judge 集成（自动化评估）
一旦生成弱捕获，系统必须判定每个弱捕获是误报还是实际上是强捕获（真阳性）。
LLM-as-Judge 集成由一组 LLM 组成，它们负责审查：
- 弱捕获测试用例代码。
- 测试执行结果（失败代码、消息、执行轨迹）。
- 父版本与子版本之间的代码变更（即 diff）。
- 推断出的 diff 意图。
阶段 4：基于规则的评估器（RubFake）
我们用一种更传统的、基于规则的方法来补充 LLM-as-Judge，该方法称为基于规则的误报消除环境（RubFake）。
LLM-as-Judge 具有丰富的语义，但其判断是非确定性的，且难以验证。相比之下，RubFake 提供 且确定性的判断。二者协同工作，RubFake 与 LLM-as-Judge 共同对弱捕获候选给出整体排名，排名足够高的候选才值得进一步考虑。阶段 5：Human-on-the-Loop（工程师介入）基于 LLM-as-Judge 与 RubFake 的排名，系统随后决定是否联系人类工程师。我们并未采用 human-in-the-loop 方式（由人类工程师审核每一个输出），而是通过 human-on-the-loop 方式减少摩擦，其中 判断。RubFake 与 LLM-as-Judge 协同工作，对弱捕获候选给出整体排名，排名足够高的候选才值得进一步考虑。
阶段 5：Human-on-the-Loop（工程师介入）
基于 LLM-as-Judge 与 RubFake 的排名，系统随后决定是否联系人类工程师。
我们并未采用由人类工程师审核每一个输出的 human-in-the-loop 方式，而是通过 human-on-the-loop 方式减少摩擦，即由人类工程师设定标准并在总体层面审核结果，而不是监督每一个输出。on即 human-on-the-loop 方式：由人类工程师设定标准并在总体层面审核结果，而不是监督每一个输出。
在 Meta 捕获 JiTTests 的影响
在测试系统就位后，我们的目标是让工程师积极参与并利用其结果。
截至本文撰写时，Meta 已有 589 名工程师（占我们触达人数的 64%）参与使用了 Catching JiTTests。这些工程师反馈称，Catching JiTTests 能揭示真正可付诸行动的发现，真阳性率达到 60%。
2026 年上半年，Catching JiTTests 在 diff 阶段发挥了关键作用，在严重（SEV）隐私缺陷进入生产环境之前捕获了 74 个此类缺陷，并使该时间段内隐私 SEV 的总体发生率降低了 20%。
为何重要
智能体式软件开发正在帮助全行业的工程师和开发者以前所未有的速度编写、审查和交付代码。但更快的部署也意味着需要更快的测试。每一个在生产环境之前被捕获的缺陷，都是最终用户永远无需面对的缺陷。我们已经证明，LLM 可以提供额外的安全层，能够捕获传统测试可能遗漏的问题，这表明 AI 生成的测试可以扩展到足以降低组织风险的程度。
Catching JiTTests 是一种在技术和社交层面均可扩展的解决方案。将这些测试与 human-on-the-loop 方法相结合，有助于确保工程师很少需要阅读测试代码，只需确认所观察到的行为变化是否符合预期。
该方法具有可推广性：工程师尽早定义成功标准，让 AI 执行测试，在总体层面监控结果，并在策略层面而非逐项进行干预。
阅读论文
我们的论文《Meta 的即时捕获测试生成》，该论文在 FSE 2026 上发表，并在 Product@Scale，详细介绍了我们在 Meta 基础设施中初步部署和测试 Catching JiTTests 的情况。