在缺陷落地前捕获它们：JiTTesting 大规模“人在环上”方法
内容提要
Meta将LLM生成的“即时捕获测试”（JiTTests）投入生产：系统夜间针对高风险代码变更，通过“可疑diff”和“意图感知”两种流程生成可执行测试，再经LLM评审团与规则工具过滤误报，并采用“人在环上”模式减少人工负担。589名工程师参与，真阳性率60%；2026年上半年在合入前捕获74个严重隐私缺陷，使此类事故下降20%。
延伸解读
生成可执行测试，而非仅做代码审查
文章强调，Catching JiTTests 与常见的 LLM 代码审查有本质区别：后者像人类评审一样基于经验判断缺陷，而前者会生成可执行的测试，用具体的行为差异证明变更引入了问题。这意味着它需要更多计算步骤，但能捕获代码审查可能漏掉的缺陷类别。对读者而言，这提示 AI 辅助质量保障不只有“让模型读代码”一条路，生成可验证的测试是另一种可规模化的思路。
双流程互补：意图感知与可疑 diff
系统并行运行两种测试生成流程。“可疑 diff”流程把每个变更当作潜在缺陷，用变异引导生成测试以暴露行为差异，目标是扩大候选池；“意图感知”流程则先推断变更意图，再描述实现意图时可能出现的风险，并据此构造变异体。两者结合，既覆盖未知风险，又聚焦高概率失败点。这种设计说明，单一生成策略难以兼顾召回与针对性，互补流程是提升真阳性率的工程手段。
误报过滤依赖规则与 LLM 评审团
生成测试后，系统需区分强捕获与弱捕获。文章介绍了两层过滤：LLM-as-Judge 集成多个先进模型，综合测试代码、执行结果、diff 和推断意图进行判断；RubFake 则用规则方法提供确定、可验证的判断。两者共同给出候选排名，决定是否触达工程师。这一组合的启示是，LLM 判断语义丰富但非确定性，规则判断确定但语义有限，生产环境需要二者互补而非二选一。
人在环上：减少逐条审查负担
文章明确采用“人在环上”而非“人在环中”：工程师设定标准并在聚合层面审查结果，而不是逐条监督每个输出。系统夜间利用空闲算力运行，只针对高风险变更。实际效果是 589 名工程师参与，真阳性率 60%，2026 年上半年在合入前捕获 74 个严重隐私缺陷，使此类事故下降 20%。这表明规模化 AI 测试的关键不只是模型能力，还包括把人工介入控制在可承受的范围内。
Q&A
JiTTesting 和传统的 LLM 代码审查有什么本质区别？
传统 LLM 代码审查是让模型像人类审查者一样阅读代码并基于经验判断缺陷；JiTTesting 则生成可执行的测试，用测试失败来具体展示代码变更引入的行为差异，因此能捕获代码审查可能漏掉的缺陷类别，但需要更多计算步骤。
JiTTesting 系统具体是怎么运行的？有哪些关键步骤？
系统在夜间利用空闲算力运行，针对前一天提交的高风险 diff，分五个阶段：1）用类似 Diff Risk Score 的机制筛选高风险变更；2）通过“可疑 diff”和“意图感知”两种流程生成测试；3）用 LLM-as-Judge 集成评估弱捕获；4）用规则工具 RubFake 做确定性过滤；5）根据排名决定是否触达工程师进行“人在环上”复核。
“可疑 diff”和“意图感知”两种测试生成流程分别是什么？
“可疑 diff”流程把每个代码变更当作变异体，用变异引导的 LLM 测试生成来暴露其行为差异，不推理意图，旨在最大化弱捕获池；“意图感知”流程先用 LLM 推断变更意图并描述可能的风险，再据此构造变异体并生成能杀死每个变异体的测试，最后在真实 diff 上运行并收集失败测试作为弱捕获。
系统如何减少误报并降低工程师的审查负担？
系统结合 LLM-as-Judge 集成（多个先进 LLM 对弱捕获分类）和规则工具 RubFake（提供确定性判断）对弱捕获进行排序，只有排名足够高的才进入人工复核；同时采用“人在环上”模式，工程师设定标准并在聚合层面审查结果，而非逐条监督每个输出，从而减少被拉入审查的概率。
JiTTesting 在 Meta 生产环境中的实际效果如何？
截至文章撰写时，589 名工程师（占触达人数的 64%）参与了使用，真阳性率为 60%；2026 年上半年，该系统在 diff 阶段捕获了 74 个严重隐私缺陷，使此类隐私事故整体下降 20%。
“人在环上”和“人在环中”有什么不同？为什么选择前者？
“人在环中”要求工程师审查每一个输出；“人在环上”则由工程师设定标准、在聚合层面审查结果，而非逐条监督。选择后者是为了减少摩擦，让工程师很少需要阅读测试代码，只需确认观察到的行为变化是否有意，从而在保持人工判断一致性的同时降低审查负担。
