在 Bug 上线前抓住它：Meta 如何让 JiTTests 规模化守住代码变更
Meta 把 Catching JiTTests 推进生产：以可疑 diff 和意图感知双路生成失败测试，再经 LLM 评审团与规则系统筛选，由工程师判断行为变化是否符合意图。
代码变更让平台不断变好，也让它不断变复杂。面对持续演化的数亿行代码，传统测试很难及时回答一个新问题：这次 diff 究竟改变了什么可观察行为，而这种改变是不是开发者想要的？Meta 提出的 Catching JiTTests 试图把质量保障从“让模型先读一遍代码”推进到“让模型现场生成一个能够失败的测试”。这套方法已经从研究原型进入生产基础设施，在五个月内覆盖了大规模工程组织的一部分高风险变更。
它的关键不只是用大语言模型写测试。更重要的设计是：系统先假设 diff 可能有问题，构造能够区分父版本与变更后版本的测试；测试只有在父版本通过、变异体与真实 diff 上失败时，才成为一条“弱命中”；随后再由规则系统、LLM 评审团和工程师共同判断，这次行为变化是否真的是 bug。
本文基于 Meta Engineering 原文及其 FSE 2026 论文《Just-in-Time Catching Test Generation at Meta》，完整拆解系统流程、生产结果、组织设计与现实边界。
一、为什么“再看一遍代码”不够
大多数 AI 代码审查仍然沿用人类 review 的基本形态：模型阅读 diff，结合代码库上下文和历史经验，输出一条评论，告诉作者“这里可能有问题”。它当然比等人来读快，但证据形式没有改变，最后仍然是工程师判断这条建议是否可信。
Catching JiTTests 走的是另一条路。系统生成的是可执行测试，不是仅凭语义猜测得出的评论。一个有效测试必须先证明父版本行为正常，再证明变更后的行为不同。这样，审查意见从“模型觉得这里有风险”变成了“某组输入在这里产生了不同的结果”，问题被转化为一个可以被运行、复现和讨论的行为差异。
这并不代表生成测试比代码审查便宜。相反，它需要更多计算、更强的执行基础设施和额外的误报过滤。Meta 的判断是：只要多出来的计算集中在高风险 diff 上，并且最终能减少工程师排查误报的时间，这笔账就值得算。
| 维度 | 传统 LLM 代码审查 | Catching JiTTests |
|---|---|---|
| 主要输出 | 一条“这里可能有 bug”的评论 | 一个失败的测试，以及可观察的行为差异 |
| 覆盖方式 | 从代码语义推断潜在问题 | 通过执行激活具体行为 |
| 人工判断 | 作者判断审查者的建议是否正确 | 作者确认观察到的行为变化是否符合意图 |
二、什么是“弱命中”和“强命中”
JiTTests 是即时生成、并以失败为目标的测试。它们被用来在代码落地前暴露 diff 中的 bug。但“测试失败”不等于“发现真 bug”。Meta 把候选分成两个层次：
- 弱命中：测试在真实 diff 上失败，看起来可能揭示了问题，但其中可能包含误报。
- 强命中：经过后续证据与人工确认，测试对应的行为变化确实是 bug，也就是真阳性。
整套系统真正困难的地方不是生成更多会失败的测试，而是从大量弱命中中筛出少量强命中，同时避免把工程师淹没在噪声里。如果每天生成一千个失败测试，却要求工程师逐个阅读，系统只是把计算瓶颈换成了人的瓶颈。
三、两条并行的测试生成路径
Meta 使用两条互补的工作流。它们不要求系统事先知道本次变更“应该”怎么写，而是从两个角度制造可区分的测试。
1. “可疑 diff”工作流
这条路径把每一个 diff 都当作一个 mutant，也就是故意注入的 bug。系统使用 mutation-guided、基于 LLM 的测试生成，构造能够区分“父版本代码”和“diff 版本代码”的测试。它不试图理解作者的意图，而是先假定 diff 有问题，尽量扩大候选池。
流程可以概括为：先生成能够杀死 mutant 的额外测试，再检查这些测试是否在父版本上通过；通过后，再拿它们同时运行于 mutant 和真实 diff。只有在 mutant 与 diff 上失败、在正常父版本上通过的测试，才会成为弱命中。
这种“先保证父版本正确，再区分变更”的顺序很重要。一个测试如果一开始就在父版本上失败，它可能只是环境问题、旧 bug 或测试本身错误，不能作为本次 diff 的行为证据。
2. “意图感知”工作流
第二条路径先让 LLM 结合代码改动、diff 标题和摘要，推断这次变更想实现什么，再列出实现这个意图时可能出现的错误方式。系统根据风险描述构造一组 mutant，每个 mutant 代表一种“看起来在完成目标，实际上可能写错了”的实现。
例如，如果变更想把一次访问限制在某个范围内，风险可能是边界条件写反、默认值处理错误、异常路径绕过检查，或者某个调用方没有同步更新。系统围绕这些风险生成测试，再拿测试去验证真实 diff。
两条路径的哲学不同：一条不信任意图，穷举行为差异；另一条利用意图缩小搜索空间。它们并行运行，既保留“没想到的风险”，也提高与作者目标直接相关的 bug 命中率。
四、五阶段生产流程
| 阶段 | 做什么 | 主要目的 |
|---|---|---|
| 1. 目标选择 | 利用类似 Diff Risk Score 的机制挑出前一天的高风险 diff，在夜间使用闲置算力运行 | 把昂贵测试集中到最可能出现严重回归的变更上 |
| 2. 测试生成 | 并行运行可疑 diff 与意图感知两条路径，收集弱命中 | 同时扩大行为覆盖和意图覆盖 |
| 3. LLM 评审团 | 多个 SOTA 模型阅读测试代码、失败结果、diff 与推断意图 | 利用语义理解过滤明显误报 |
| 4. RubFake | 用确定性规则检查失败是否由已知的非 bug 原因造成 | 补充可验证、可重复的硬约束 |
| 5. 人守回路之上 | 只把综合评分足够高的候选触达工程师 | 减少逐条监督，同时保留最终行为判断 |
阶段 1：先决定哪里值得花算力
这套系统不会对每个变更平均用力。它夜间运行，目标是前一天提交且被判定为高风险的 diff。排序机制类似 Diff Risk Score，并利用历史代码变更训练。这样做并非为了“更智能”，而是因为生成测试、变异代码和反复执行都需要真实成本。风险路由是整套系统能否规模化运营的前提。
阶段 2：自动生成弱命中
可疑 diff 工作流负责增加候选数量，意图感知工作流则把搜索导向作者最可能写错的边界。任何在真实 diff 上失败、但在正常父版本上通过的测试，都会先被记录下来。此时系统还不知道它是不是 bug，只知道它发现了本次变更引入的行为差异。
阶段 3：LLM 评审团
LLM-as-Judge 不是让一个模型给出最终裁决，而是让多个模型综合检查四类证据：弱命中测试本身、失败的退出码与堆栈、父版本与子版本之间的 diff，以及系统推断出的变更意图。
这种集成方式的价值在于降低单模型语义判断的波动。但原文也明确承认，LLM 的判断具有丰富语义，却不一定确定、也很难完全验证。因此它不能单独决定是否打扰工程师。
阶段 4：RubFake 补上确定性
Meta 使用规则系统 RubFake，也就是 Rule-Based False-Positive Killing Environment，排除已知的假失败模式。它可能检查环境、依赖、测试构造或执行路径中的确定性条件，从而给出比模型判断更容易复现和审计的结论。
LLM 评审团负责理解上下文，RubFake 负责提供硬约束。最终系统将两类信号合成为排序，而不是让任意一方单独决定。这个组合是整套方法最有工程价值的部分：生成模型扩大召回，规则系统提供下限，人类处理真正的产品意图。
阶段 5：Human-on-the-Loop
Meta 特意区分了 human-in-the-loop 与 human-on-the-loop。前者要求人审核每一个输出，后者由人提前定义成功标准、监控总体结果，并只在异常或高价值候选上介入。
在这套系统里，工程师通常不需要阅读测试代码。他们只需要确认：系统展示出来的行为变化，是不是此次变更本来就打算造成的。如果行为不符合意图，就说明测试找到了真实问题；如果行为符合意图，则测试本身可能缺少正确的预期。
| 维度 | Human-in-the-loop | Human-on-the-loop |
|---|---|---|
| 工作模型 | 人审核每一个动作或输出 | 人定义成功标准，由 AI 自主执行 |
| 瓶颈 | 人的吞吐量决定系统吞吐量 | 人设置护栏并查看聚合结果 |
| 扩展方式 | 随人力线性增长 | 随算力增长，人只处理例外 |
| 监督粒度 | 逐项监督 | 策略、阈值与异常处理 |
五、生产结果说明了什么
Meta 在博客中给出了截至发文时的结果：589 名工程师参与了触达，占触达总数的 64%；这些工程师认为系统能给出可执行的发现，真阳性率为 60%。2026 年上半年，Catching JiTTests 在 diff 阶段帮助发现了 74 个严重隐私 SEV，Meta 同时观察到该时期隐私 SEV 总发生量下降 20%。
论文摘要提供了更细的早期实验数据：研究分析了 22,126 个生成测试；与“加固测试”相比，代码变更感知方法把候选命中提高约 4 倍，与偶然失败测试相比提高约 20 倍；规则与 LLM 评估器把人工复核负载降低 70%。在最初报告的 41 个候选中，8 个被确认是真阳性，其中 4 个如果不拦截会导致严重故障。
| 指标 | 结果 | 应如何理解 |
|---|---|---|
| 工程师参与 | 589 人，触达参与率 64% | 说明结果进入了真实工作流，而不只是离线实验 |
| 可执行发现比例 | 60% 真阳性 | 仍需关注剩余 40% 的噪声成本及统计口径 |
| 严重隐私 SEV | diff 阶段拦截 74 个 | 价值发生在生产事故之前，但“发挥关键作用”不等于唯一原因 |
| 隐私 SEV 总量 | 同期下降 20% | 属于相关结果，博客没有给出严格的因果归因 |
| 候选生成效率 | 相对加固测试提升 4 倍 | 来自论文的早期 22,126 个测试分析，不是对所有组织的普遍保证 |
| 人工负载 | 评估器减少 70% | 这是系统能规模化的关键，不只是模型测试生成能力 |
最值得注意的不是 74 这个绝对数字，而是发现问题的位置。测试发生在代码合并前，此时作者仍掌握上下文，回滚和修改成本都低；等隐私问题进入生产后，再通过监控、事故响应和补救流程处理，组织付出的代价完全不同。
六、为什么它对智能体开发尤其重要
智能体让写代码、改测试和提交 PR 的速度同时上升。如果测试仍主要依赖人在最后一道关口逐项判断，开发速度越快，瓶颈只会越早出现。Catching JiTTests 给出的方向不是“取消人”，而是把人的工作从重复阅读迁移到标准制定、结果审计和意图判断。
这里有三条可以迁移到其他工程组织的原则：
- 优先验证行为，而不是增加评论。“看起来可能有 bug”很难规模化裁决；一个先通过父版本、再在变更版本上失败的测试，至少给出了可操作的证据。
- 把误报治理当成核心功能。生成测试越多，不等于系统越有用。没有多层次裁决，生成能力最终会变成工程师的待办列表。
- 风险路由比全量执行更现实。高风险 diff 值得多花算力，低风险变更则应保持快速。质量系统的目标不是让每次提交都经过最重流程，而是让检查强度与潜在损失匹配。
这套方法也改变了“测试”的含义。传统回归测试通常要求生成时通过，并在未来持续防止行为退化；Catching JiTTests 则故意在可疑变更上失败，用来证明本次修改引入了一个不同行为。它不是替代全部回归测试，而是在变更进入主分支之前增加一层动态证据。
七、亮眼数字之外，仍有五个问题
1. 第一方结果缺少外部复现
博客与论文的数据都来自 Meta 自己的代码库、工具链和工程师。22,126 个生成测试与 64% 的参与率很有说服力，但它们不能自动证明其他组织会得到相同收益。Meta 拥有超大规模代码库、成熟的变异测试基础设施、专门的评估器和可调用的模型资源，这些条件本身就是系统能力的一部分。
2. 真阳性不等于覆盖了所有 bug
系统统计的是被触达候选中工程师确认有效的比例，不能直接等同于整体 bug 召回率。没有命中的 diff 仍可能存在测试无法表达的问题，例如需求理解错误、跨系统语义变化、数据分布问题，或者不会在测试环境中显现的性能与并发故障。会失败的测试很强，但它只能覆盖能够被当前 oracle 和运行环境观察到的行为。
3. 成本被分散到了多个基础设施层
生成测试需要模型调用，验证 mutant 需要编译与运行，判断意图需要 diff 上下文，最终一条可执行发现还要经过评审团和规则系统。夜间闲置算力能降低成本，但报告没有给出每条强命中的模型 token、运行时长、存储和工程师确认时间，因此还不能据此推导通用 ROI。
4. Human-on-the-loop 需要成熟的治理
减少逐项审核的前提是系统能够稳定处理大部分噪声，并且组织知道何时应该收紧阈值。阈值过松会消耗工程师时间，阈值过紧又会漏掉低分但真实的 bug。聚合监督还要求持续监控不同代码区域、不同语言和不同风险类型的表现，否则一个总体真阳性率会掩盖局部失效。
5. 严重隐私 SEV 下降不能简单归因为单一系统
博客写的是 Catching JiTTests 在半年内“发挥了关键作用”，并同时观察到隐私 SEV 下降 20%。这足以说明系统参与了风险降低，但不能排除同期其他安全项目、流程变化或事件分类口径的影响。严谨的结论应当是：该系统已经成为隐私风险防线的一部分，并与更好的结果同时出现。
八、如果要把它搬进真实团队，先做这六件事
- 从一类高风险变更开始。先选安全边界、权限、数据访问或计费逻辑，避免一上来覆盖所有 diff。
- 建立父版本与变更版本的对照执行。没有稳定父版本基线，失败测试无法证明行为变化来自本次修改。
- 分别度量召回、误报和人工时间。只看生成了多少测试会奖励噪声；只看真阳性又会忽略漏报。
- 保留确定性过滤器。让规则系统处理环境、依赖和已知假失败，把 LLM 留给语义判断。
- 让工程师确认意图，而不是阅读测试实现。系统展示输入、父版本行为、变更后行为和失败轨迹，人只回答“这是不是预期变化”。
- 记录逃逸 bug，并回流评估集。每次生产事故都应反过来检查：当时为什么没有生成测试，或者为什么候选被错误地过滤掉。
九、结论：把模型从评论者变成实验者
Catching JiTTests 的真正贡献，不是证明 LLM 会写测试，而是把 LLM 放进一个可以检验自己的工程闭环。模型提出候选，执行系统验证行为差异，规则与评审团排序，人类只判断产品意图是否正确。每一层都只做自己最擅长的事，也没有任何一层被要求单独承担真相。
当代码生产速度因为智能体而提高，这种“生成候选、执行验证、分层裁决”的结构会越来越重要。最可靠的 AI 软件工程系统，不会只比人类更快地发表意见；它会把意见变成实验，把实验结果变成可复核的证据，再把人留在决定什么行为应该发生的位置上。
原文与延伸阅读
原文：Catching Bugs Before They Land: JiTTesting’s Human-on-the-Loop Approach at Full Scale，Engineering at Meta，2026 年 10 月 29 日。
论文：Just-in-Time Catching Test Generation at Meta，FSE 2026 Industry Track。