Meta详解Catching JiTTests：为每个改动生成会失败的测试，称其在上半年拦下74个严重隐私缺陷中起关键作用

Meta 工程团队于 2026 年 10 月 29 日介绍了“Catching JiTTests”（即时捕获测试）在生产环境的落地情况：用大语言模型为每个待合入的代码改动（diff）现场生成一批设计为会失败的可执行测试，用测试失败来暴露改动引入的缺陷。Meta 称，截至文章写作时已有 589 名工程师参与，工程师反馈的真阳性率为 60%。2026 年上半年，它在 diff 阶段帮助拦下 74 个严重（SEV）隐私缺陷。

Meta 把它与常见的 AI 代码审查区分开。多数基于大模型的方法像人工审阅者一样读代码，凭经验判断哪里可能出错；Catching JiTTests 则生成可执行的测试，用来证明这次改动带来了具体的行为差异。Meta 承认这需要更多计算步骤，但认为它能抓住 LLM 或智能体审查可能漏掉的一类缺陷。难点在于，Meta 有数亿行持续变化的代码，生成的测试里既有真正暴露缺陷的“强捕获”，也有可能是误报的“弱捕获”，必须自动区分，又不能拖慢工程师的节奏。

系统分五个阶段。第一阶段是定位和触发：系统在闲置算力上通宵运行，只处理前一天提交、被判为“有风险”的 diff，风险判断使用类似 Diff Risk Score 的机制，并以过去的代码改动训练。第二阶段是两条并行的测试生成流程。“dodgy diff”流程把每个改动当作一个变异体（带缺陷的版本），用基于变异的 LLM 测试生成，产出能区分该改动与其父版本行为的测试，不推断意图，目的是扩大弱捕获的池子。“intent-aware”流程先让 LLM 根据代码改动、标题和摘要推断改动意图，再描述实现该意图时可能出错的“风险”，据此构造变异体并生成测试去“杀死”每个变异体；这些测试再拿到真实的 diff 上运行，失败的被收集为弱捕获。

第三阶段是“LLM-as-Judge”：由多个先进模型组成的集合，查看弱捕获的测试代码、执行结果（失败码、信息、执行轨迹）、父子版本之间的差异和推断出的意图，判断它更像误报还是真缺陷。第四阶段是基于规则的评估器 RubFake，给出可验证、确定性的判断，弥补 LLM 判断非确定、难验证的弱点；两者共同给弱捕获排序。第五阶段是“human-on-the-loop”（人在回路之上）：由系统根据排序决定是否联系工程师，工程师设定标准并在汇总层面审查结果，而不是逐条监督。

文章给出的效果有几个需要看清边界的数字。589 名工程师占其外联对象的 64%，但文章没有给出外联总人数。60% 的真阳性率是工程师反馈的结果。上半年拦下 74 个严重隐私缺陷中，Catching JiTTests 被称为“起到关键作用”，文章把这些拦截与同期隐私严重事件总体下降 20% 写在同一句里，但没有给出对照基线，也没有说它是唯一原因。对比表和成效图在原文中是图片，这里没有引用其中的任何数值。

文章还交代了背景。Meta 说这项工作已经分享了一年，从最初公布到现在大约五个月，Catching JiTTests 不再是研究原型，而是 Meta 基础设施的一部分，帮助工程师在更低的负载和更小的误报概率下抓到更多缺陷。相关论文《Just-in-Time Catching Test Generation at Meta》在 arXiv 上提交于 2026 年 1 月，并在 FSE 2026 上宣读。文章强调，这种做法让工程师很少需要阅读测试代码，只需确认观察到的行为变化是不是本意；通用的思路是工程师提前定义成功标准，让 AI 执行测试，在汇总层面监控结果，在策略层面而不是逐条干预。强捕获和弱捕获的区分、LLM-as-Judge 与 RubFake 的组合，都是为了让真正被打扰的工程师尽量少。

原文把核心问题表述为：对每个提议的 diff，怎样自动生成测试，找到最严重的缺陷，同时保持高真阳性率，又不拖慢工程师的开发速度。dodgy diff 流程隐含地断言“这个改动有缺陷”，所以得名，作用是扩大弱捕获的池子，让其中出现强捕获的机会更大。Meta 同时保留人工复核，目标是保持人工标注的一致性，同时降低工程师被叫来复核弱捕获的概率。

对其他团队有参考价值的是这套流程的形状：先用风险评分挑出少数 diff，再生成能证明行为差异的测试，用模型和规则两种方式过滤误报，最后只在排名靠前时才打扰人。它的局限同样明确：数字来自 Meta 自己的部署，成本是额外的计算，而且结论取决于隐私缺陷这一类问题，不能直接推到所有缺陷。