Meta JiTTests：合并前生成反例测试，上半年拦下 74 个严重隐私 bug

原文 · Meta Engineering · 2026-10-29

Meta 工程博客介绍 Catching JiTTests（Just-in-Time Catching Tests）：用大模型在代码合入前生成可执行测试，专门暴露「这次改动引入的行为差」，从而在 diff 阶段拦住缺陷。作者强调它与「让 LLM 像人一样审代码」不同——审阅靠先验经验，JiTTests 靠跑得起来的反例。

背景是 Meta 体量的持续演进：数亿行代码、海量 diff，传统测试跟不上「每笔改动都可能引入复杂回归」的速度。团队先发过研究与论文（FSE 2026 等），本稿写的是上线生产后的规模化结果。

常见 AI 防缺陷路径是：模型或 Agent 读 diff、对照历史缺陷模式给出评论。优点是快；弱点是缺少「证明行为变了」的可执行证据，误报与漏报都难定量。

Meta 自述要回答的问题是：对每一笔提案中的 diff，如何自动生成最可能抓住严重 bug的测试，同时保持高真阳性、又不拖垮工程师节奏？若把所有弱捕获都推给人，审查负载会爆。

系统分五阶段（据原文整理）：

1. 定向触发：夜间用空闲算力，对前一日「风险」diff（类似 Diff Risk Score）生成测试，把算力花在更可能出严重回归的改动上。
2. 双路径生成：dodgy diff 把每次改动当成突变体，生成能区分父子行为的测试，扩大弱捕获池；intent-aware 先推断改动意图与风险，再构造对应突变体并生成「杀突变」测试，在真实 diff 上失败的收进弱捕获。
3. LLM-as-Judge 集成：多款 SOTA 模型共同看测试代码、失败栈、diff 与意图，判断弱捕获更像真阳性还是误报。
4. RubFake 规则评估：规则化、可复验的假阳性剔除，与非确定性的 Judge 互补，共同排序。
5. Human-on-the-loop：不是每条输出都强制人审（in-the-loop），而是工程师定门槛、看汇总、在策略层干预；只有排得足够前的才触达人。

短引（<30 字）：「JiTTests are no longer a research prototype; they’re part of Meta’s infrastructure。」——Meta Engineering。

相对「更快做完同一套人工审查」，Catching JiTTests 多走计算步骤，但能抓住纯审查可能漏掉的行为差类别。生产目标明确写成：降低工程师阅读测试代码的次数，更多只确认「观察到的行为变化是否符合意图」。作者称方法在技术与社交层面都可扩展：人早定成功标准，AI 执行测试，人在聚合层监控并在策略层干预。

以下数字均来自 Meta Engineering 自述（证据等级 C · 厂商自述）：

• 截至发文，589 名工程师与系统有过互动，约占触达对象的 64%；工程师反馈可行动发现的真阳性约 60%。
• 2026 上半年，JiTTests 在 diff 阶段参与拦住 74 个严重（SEV）隐私 bug；同期隐私 SEV 总体发生约降 20%。

文中未给出：对照实验的因果拆分、各语言/仓库覆盖率、单次生成美元成本、以及「20%」相对基线的完整时间序列表。列表页「74 / 六成真」与本稿一致，无需改口径。

• Judge 集成用了哪些具体模型、如何仲裁分歧，未开源配方。
• 60% 真阳性的标注协议、抽检比例未附。
• 20% SEV 下降有多少可归因于 JiTTests 相对其他安全项目，未做公开因果分析。
• 对外可复现的基准集与论文之外的生产配置差多少，外部无法复刻。

可迁移点：用「可执行反例」补纯审阅；用规则+多模型降误报；把 HITL 做成 on-the-loop（定门槛）而非条条人肉。

minimal_trial：在一个中型服务仓库，对「高风险路径」diff 夜间生成杀突变测试；只用规则（断言新鲜失败、排除 flake 目录）做第一道过滤，人工每周抽 20 条。先量：推给人的条目数、确认真 bug 数、工程师投诉「吵」的次数。

我们的推测（非原文）：隐私 SEV 数字好看，可能与隐私敏感路径被 DRS 加权有关；换到一般业务回归，命中率需自测。证据停在 C，对标采购应自建两周基线。

• Meta Engineering：Catching bugs before they land: JiTTesting’s human-on-the-loop approach at full scale
• FSE 2026：Just-in-Time Catching Test Generation at Meta