在缺陷上线前拦截：JiTTesting 在全规模下的人机协同方法

中文精读

原文约 2,320 词 · 13 节

1. 开场与核心结论

   • 文章由 Sreeja Thummala、Sophie Zeng、Mark Harman、Weini Liu、Eric Liu 撰写，归入 AI 研究、机器学习应用、安全与隐私三个栏目。
   • 过去一年团队持续分享用大语言模型（LLM）在代码合入前即时抓 bug 的工作，即 Catching Just-in-Time Tests（JiTTests）。
   • 本次公开的是 Catching JiTTests 投入生产后的结果与正面影响；论文《Just-in-Time Catching Test Generation at Meta》详述了初期部署与测试。
   • Meta 代码库有数亿行且持续演进，传统测试跟不上节奏；在代码合入生产前主动识别风险，能更早发现、更有效响应，并在规模上保证可靠体验。
   • 公布五个月后，Catching JiTTests 已不再是研究原型，而成为 Meta 基础设施的一部分，帮工程师以更低负载、更少误报抓到更多 bug。

2. Catching JiTTests 的优势

   • 多数基于 AI 的防 bug 方法用 LLM 或智能体（agentic AI）依据既往经验审代码找缺陷，走的是与人类评审相同的流程，只是更快。
   • Catching JiTTests 是根本不同的思路：生成可执行的测试，用具体行为差异证明本次改动引入了问题。
   • 它需要更多计算步骤，但能抓到 LLM 或智能体代码评审可能漏掉的那几类 bug。

3. 在 Meta 的落地实现

   • JiTTests 自动生成且被设计为应当失败，从而在代码改动（diff）合入生产前暴露 bug。
   • 在超大规模代码库上，难点是区分强捕获（真实阳性失败，揭示真 bug）与弱捕获（可能是误报的测试）。
   • 核心问题：对每个待评审 diff，如何自动生成测试，以高真阳性率、且在不妨碍工程师交付速度的前提下抓到最严重的 bug。
   • 为此采用两条并行工作流：意图感知（intent-aware）工作流推断改动意图与风险，把测试对准可能的失效点；可疑 diff（dodgy diff）工作流把每个改动当作变异体/ bug，不看意图直接生成暴露行为差异的测试，隐含断言「这个 diff 有 bug」。
   • 为过滤误报，系统将传统规则方法与名为「LLM-as-Judge」的集成方法结合，后者汇总多个最先进 LLM 的判断，将弱捕获分类为可能的真阳性或假阳性。
   • 同时保留人工评审但以降低评审负担为目标：在保持人工标注一致性的同时，减少工程师被拉进来审弱捕获的概率。

4. 整体流程概览

   • 整个系统工作流分为五个阶段：定向与触发、两条 diff 感知的测试生成工作流、LLM-as-Judge 集成自动评估、基于规则的评估器、人在环上（human-on-the-loop）的工程师介入。

5. 阶段一：定向与触发

   • 系统利用空闲算力在夜间运行，针对前一天提交的 diff。
   • 用类似 Diff Risk Score（DRS）、基于历史代码改动训练的机制筛出「有风险」的 diff，使测试生成聚焦在最可能包含严重回归的改动上。

6. 阶段二：两条 diff 感知的测试生成工作流

   • 可疑 diff 工作流把每个 diff 当作变异体，用变异引导的 LLM 测试生成，产出能区分 diff 与其父版本行为的测试，目标是最大化弱捕获池、从而在其中提高找到强捕获的机会。
   • 意图感知工作流用 LLM 结合代码改动、diff 标题与摘要推断意图，再由 LLM 描述「风险」，即实现该意图时可能出错的方式。
   • 系统据此构造变异体，每个代表实现该意图时可能引入的一个 bug，并生成测试去杀死（kill）每个变异体，即区分变异体行为与父版本。
   • 这些测试随后在真实 diff 上运行，失败的测试被收为弱捕获。

7. 阶段三：LLM-as-Judge 集成自动评估

   • 弱捕获生成后，系统需判定每一条是假阳性还是真正的强捕获（真阳性）。
   • LLM-as-Judge 集成由多个 LLM 组成，它们审查四类材料：弱捕获的测试代码；测试执行结果（失败码、消息、执行轨迹）；父版本与子版本之间的代码改动（diff）；推断出的 diff 意图。

8. 阶段四：基于规则的评估器 RubFake

   • 以名为 Rule-Based False-Positive Killing Environment（RubFake）的传统规则方法补充 LLM-as-Judge。
   • LLM-as-Judge 语义丰富，但判断不确定、难以验证；RubFake 则给出可验证、确定性的判断。
   • 两者共同产出弱捕获候选的整体排名，排名足够高的候选才值得进一步处理。

9. 阶段五：人在环上（工程师触达）

   • 依据 LLM-as-Judge 与 RubFake 的排名，系统决定是否联系人类工程师。
   • 与人在环内（human-in-the-loop，即人工审查每条输出）不同，方案采用人在环上（human-on-the-loop）：人工设定标准、在聚合层面审查结果，而非监督每条输出，从而降低摩擦。

10. 在 Meta 的影响

    • 系统上线后的目标是让工程师真正使用其结果。
    • 截至成文，已有 589 名 Meta 工程师（触达人数的 64%）与 Catching JiTTests 互动，反馈其能给出真正可执行的发现，真阳性率为 60%。
    • 2026 年上半年，Catching JiTTests 在 diff 阶段协助抓出 74 个严重（SEV）隐私 bug，使其在生产上线前被拦下，该时段隐私 SEV 总体发生率下降 20%。

11. 为何重要

    • 智能体式软件开发让人写代码、评审、发布都更快，部署变快就要求测试也更快；每个在上线前被抓住的 bug，都意味着终端用户不必再面对它。
    • LLM 可提供传统测试可能漏掉的额外安全层，说明 AI 生成的测试在规模上足以降低组织风险。
    • Catching JiTTests 在技术与社会层面都可扩展：结合人在环上，工程师很少需要读测试代码，只需确认观察到的行为变化是否是有意为之。
    • 方法可推广：工程师预先定义成功标准，让 AI 执行测试，在聚合层面监控结果，并在策略层面而非逐条介入。

12. 论文与延伸阅读

    • 论文《Just-in-Time Catching Test Generation at Meta》在 FSE 2026 发表，并在 Product@Scale 上展示，详述了 Catching JiTTests 在 Meta 基础设施中的初期部署与测试。
    • 后续页面是分享按钮，以及安全与隐私栏目的其他文章推荐（PrivacyLib、Meta AI 眼镜的私有处理、组织第二大脑、WhatsApp 诈骗提醒、AI 原生时代的隐私感知基础设施、Labyrinth 1.1）。

13. 其余页面内容（招聘、技术站点、开源、Cookie）

    • 页面列出若干招聘职位：AI 专家（技术领导，Menlo Park）、Reality Labs 研究科学家（Sunnyvale、远程、纽约）、竞争情报项目经理（Bellevue）。
    • 技术站点部分给到 Engineering at Meta 的 X 账号、AI at Meta、Meta Quest 博客、Meta for Developers、Meta Bug Bounty 与 RSS 的链接。
    • 开源部分介绍 Meta 通过开源技术建设社区，并指向 AI、数据基础设施、开发工具、前端、语言、平台、安全、虚拟现实等项目的入口。
    • 页面末尾为 Meta 的 Cookie 使用提示，区分必需 Cookie 与用于站点分析和内容表现度量的可选 Cookie，用户可拒绝可选 Cookie 或随时在设置页更改选择。