Meta 如何在代码发布前发现 Bug（阅读需 9 分钟）

# 在缺陷落地前将其捕获：JiTTesting 大规模应用中的人在环上监督方法 来源：https://engineering.fb.com/2026/10/29/security/catching-bugs-before-they-land-jittestings-human-on-the-loop-approach-at-full-scale/ - 过去一年，我们一直在分享利用大语言模型即时捕获缺陷的工作——我们将这种新方法称为即时缺陷捕获测试（Catching Just\-in\-Time Tests，JiTTests）。 - 现在，我们将分享 Catching JiTTests 部署到生产环境后取得的成果和积极影响。 - 我们的论文《Meta 的即时缺陷捕获测试生成（Just\-in\-Time Catching Test Generation at Meta）》(https://arxiv.org/pdf/2601.22832) 详细介绍了 Catching JiTTests 的初期部署和测试情况。 每一次代码变更都会改进我们的平台，但也会引入新的复杂性。Meta 的数亿行代码不断演进，传统测试已难以跟上步伐。在代码落地前主动发现风险，使我们能够更早识别风险、更有效地应对，并大规模提供可靠的体验。 过去一年，我们分享了利用大语言模型（LLM）生成软件测试的研究 (https://engineering.fb.com/2025/02/05/security/revolutionizing-software-testing-llm-powered-bug-catchers-meta-ach/)。更具体地说，我们分享了即时测试（Just\-in\-Time Tests，JiTTests）方面的工作 (https://engineering.fb.com/2025/09/30/security/llms-are-the-key-to-mutation-testing-and-better-compliance/)。这是一种新颖的测试方法，利用 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，我们如何自动生成测试，在最严重的缺陷造成严重问题之前发现它们，同时保持较高的真阳性率，又不妨碍工程师的开发速度？ 为此，我们开发了两套协同工作流： - “意图感知”工作流：推断代码变更的意图和风险，并针对可能发生故障的位置生成测试。 - “可疑 diff”工作流：将每次代码变更都视为一个变异体或缺陷，生成测试来揭示其行为差异，而不推理变更意图。它隐含地断言 diff 存在缺陷，因此称为“可疑”。 图 1。Catching JiTTests 的可疑 diff 和意图感知工作流架构。为了过滤误报，我们将传统的规则方法与一种称为“LLM 即裁判”（LLM\-as\-Judge）的集成方法相结合。该方法汇总多个最先进（SOTA）LLM 的判断，让它们分别将弱捕获结果归类为可能的真阳性或假阳性。 我们也保留了人工审查，同时着眼于减轻审查负担。我们的目标是保持人工标注的一致性，同时降低需要工程师介入审查弱捕获结果的概率。 ## 工作原理 整个系统工作流分为五个阶段： ### 阶段 1：确定目标并触发 系统利用闲置算力在夜间运行，针对前一天提交且被判定为“高风险”的 diff 开展测试。这一判定使用类似于 Diff 风险评分（Diff Risk Score，DRS）(https://engineering.fb.com/2025/08/06/developer-tools/diff-risk-score-drs-ai-risk-aware-software-development-meta/) 的机制，并基于以往的代码变更进行训练。这有助于确保测试生成聚焦于最有可能包含严重回归问题的 diff。 ### 阶段 2：两套感知 diff 的测试生成工作流 **可疑 diff 工作流**将每个 diff **视为一个变异体**，并使用变异引导的 LLM 测试生成方法 (https://engineering.fb.com/2025/02/05/security/revolutionizing-software-testing-llm-powered-bug-catchers-meta-ach/)，生成能够区分 diff 与其父版本行为的测试。这里的目标是尽可能扩大弱捕获结果池，从而提高从中发现强捕获结果的概率。 与此同时，**意图感知工作流**使用 LLM，根据代码变更、diff 标题和摘要来**推断 diff 的意图**。随后，LLM 描述其中的**“风险”**——即尝试实现该意图时可能产生错误的方式。接着，它利用这些风险描述来**构造变异体**，每个变异体代表实现所推断意图时可能引入的一种缺陷。 系统会生成测试来**杀死每个变异体**（即区分变异体与父版本的行为）。 然后，这些测试会在实际 diff 上运行。任何失败的测试都会被收集为弱捕获结果。 ### 阶段 3：LLM 即裁判集成（自动评估） 生成弱捕获结果后，系统必须判断每项结果究竟是假阳性，还是确实属于强捕获结果（真阳性）。 LLM 即裁判集成由一组 LLM 组成，它们审查以下内容： - 弱捕获结果对应的测试用例代码。 - 测试执行结果（失败代码、消息、执行轨迹）。 - 父版本与子版本之间的代码变更（diff）。 - 推断出的 diff 意图。 ### 阶段 4：基于规则的评估器（RubFake） 我们使用一种更传统的规则方法来补充 LLM 即裁判，该方法称为基于规则的假阳性消除环境（Rule\-Based False\-Positive Killing Environment，RubFake）。 LLM 即裁判具备丰富的语义理解能力，但其判断具有非确定性，而且难以验证。相比之下，RubFake 提供**经过验证的、确定性的**判断。RubFake 与 LLM 即裁判协同工作，对弱捕获候选结果进行综合排序，排名足够高的结果值得进一步考虑。 ### 阶段 5：人在环上监督（联系工程师） 系统随后根据 LLM 即裁判和 RubFake 的排名，决定是否联系工程师。 在“人在环中”的方法里，工程师需要审查每项输出；我们则通过“人在**环上**监督”的方法减少了流程阻力，让工程师设定标准并从整体层面审查结果，而不是监督每一项输出。 表 2。人在环中与人在环上监督两种方法在操作上的区别。### 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 执行测试，从整体层面监控结果，并在策略层面进行干预，而不是逐项介入。 ## 阅读论文 我们的论文《Meta 的即时缺陷捕获测试生成（Just\-in\-Time Catching Test Generation at Meta）》(https://arxiv.org/pdf/2601.22832) 已在 FSE 2026 上发表，并在 Product@Scale (https://atscaleconference.com/product-2026/#agenda-item-7) 上得到专题介绍。论文详细阐述了 Catching JiTTests 在 Meta 基础设施中的初期部署和测试情况。