上线前的可执行失败：Meta JiTTesting 用「人在回路之上」把缺陷挡在 diff 门外

Meta 工程博客在 2026年10月29日汇报：Catching Just-in-Time Tests（JiTTests）已不是实验室原型，而是基础设施的一部分。作者团队（含 Sreeja Thummala、Sophie Zeng、Mark Harman 等）强调一个窄而硬的对比：多数 AI 防缺陷做法让模型「像人一样审代码」；JiTTesting 则生成本应失败的可执行测试，用具体行为差分证明这次改动引入了什么。

可证伪主张很清楚：在 Meta 这种规模上，可执行失败测试加上「人在回路之上」的策略触达，能抓住 LLM 代码审查更容易漏掉的严重缺陷类别，同时把工程师从逐条弱捕获审读中解放出来。若生产数据只是审查文案更好看、或假阳性淹没团队，主张不成立。

系统分五段。夜间在空闲算力上，对前一日经 Diff Risk Score 类机制标为「高风险」的 diff 触发测试生成。并行两条工作流：「dodgy diff」把每次改动当作突变体，最大化弱捕获池；「intent-aware」先推断意图与风险，再构造代表意图走偏的突变体并杀灭它们，失败测试回收为弱捕获。

随后 LLM-as-Judge 集成审阅测试代码、失败轨迹、父子差分与推断意图；RubFake 提供可验证的规则判定。两者共同排序。足够靠前的候选才触达工程师——人设定成功标准与聚合监控，而不是审每一条输出。论文《Just-in-Time Catching Test Generation at Meta》在 FSE 2026 报告了早期部署。

硬数字来自官博对生产期的汇总：589 名工程师（触达中的 64%）与系统互动，并报告约 60% 真阳性、结果可行动；2026 上半年在 diff 阶段抓住 74 个严重隐私缺陷，同期隐私 SEV 总体下降约 20%。文中明确对比：审查式 LLM 更快复述人类审阅路径；JiTTests 以更多计算步骤换取「可运行的失败证据」。

边界：20% 下降是同期关联，不是严格因果试验；60% 真阳性依赖工程师反馈定义；「抓住审查式方法抓不到的类别」主要来自机制论证与生产叙事，而非并排 A/B 的公开原始表。事实置信度：部署存在与 SEV 计数高；因果幅度与跨公司可移植性中等。

钢人反驳一：可执行测试更贵，夜间批处理是否拖慢合并速度？Meta 的回答是只打高风险 diff，并用排序减少触达。钢人二：60% 真阳性意味着仍有大量噪声；若「人在回路之上」阈值过松，严重缺陷仍会漏网。钢人三：隐私 SEV 下降可能同时受益于 PrivacyLib 等其他系统（同周工程博客亦有隐私基础设施叙事），不宜单归因 JiTTests。

另一缺口：对外可读的是汇总影响与架构图，不是可复现的开源流水线；其他公司若缺少 DRS 式风险分层与 spare capacity，成本曲线会不同。

对平台公司，这篇把「AI 代码审查」从文案质量争论拉回证据形态：你要的是意见，还是一条能红的测试？对安全与隐私团队，diff 阶段拦截 SEV 的价值在于用户从未接触故障。对工具厂商，人在回路之上——政策与聚合监控优于逐条人工——可能比「再做一个审查机器人」更接近可规模化产品。

对代理式开发加速的行业，测试若不跟上皮，合并速度本身会变成风险放大器。JiTTesting 的可推广形状是：早定义成功标准，让模型执行，人在策略层介入。

未来六个月应看：真阳性与触达率在更多代码域是否稳定；隐私 SEV 下降能否在控制其他干预后仍可归因；以及外部团队复现「可执行失败 + 排序触达」时假阳性是否可控。若可执行差分测试持续贡献 SEV 拦截而审查式 LLM 在同类缺陷上系统性漏检，则主张成立；若成本或噪声迫使团队退回纯审查，主张需要改写。