摘要

LLM 辅助构建模糊测试器，把原本不确定、需要数周的工程任务压缩成数天，最终产出可复现的 bug。 Justin Lebar 让模型为 NVIDIA 的闭源 PTX 编译器和 AMD 的 LLVM GPU 后端构建模糊测试器，随后让 agent 直接检查 LLVM 的 AMD GPU 与 x86 代码。人工检查“基本不可能”，还会“把脑子烧坏”；这意味着基础设施审查首次具备经济性，反而成为更大的机会。
最严重的 x86 发现可能把一个原子操作拆成两个非原子操作，在竞争条件暴露该问题时产生错误结果。 它之所以危险，恰恰因为“绝大多数时候都能正常工作”；没有竞争时，用户可能永远察觉不到，而“1%的时候”会失败。Lebar 找到1个、也可能2个严重程度极高的 x86 bug，以及多个 AMD GPU 错误编译案例，但不愿根据受工具影响的样本推断 AMD 更容易出 bug。
模糊测试器产出了约40个容易复现的 NVIDIA 编译器案例，但模糊测试本身很快进入边际收益递减阶段。 它必须生成古怪但有效的程序，避免未定义行为，比较编译前后的行为，并停止重复发现已知模式。随着排除项不断增加，生成器变得更复杂，随机搜索的产出下降；Lebar 检查的4或5个案例中，每一个都没有未定义行为，且明确属于 bug。
经济性几乎立刻改善：Opus 4.8 加上 Claude Code 的 UltraCode 将扫描 token 消耗削减至约1/10。 Lebar 初步判断，结果质量更高但发现更少；他更偏好这种结果，因为此前很多告警本来也会被丢弃。一项原本支持“$10 grand”（约10,000美元）预算的扫描，使用 UltraCode 后看起来只需约1,000美元。他猜测收益主要来自 harness，而非 4.8 相比 4.7 的差异，但强调：“我真的完全不知道。”
模型在整个修复闭环中都有用，不只是发现阶段。 模型负责对发现结果分诊、编写修复方案、检查 Lebar 的修改；他约50%的时候会改动模型写的修复，模型也经常抓到他自己工作中的 bug。形成的 QA 飞轮仍需要 token 预算、人工筛选，以及愿意合并补丁的维护者。
Lebar 不接受未经证明的说法，即“AI slop cannon”（AI 垃圾代码炮）必然比“human slop cannon”（人类垃圾代码炮）交付 bug 更多的软件。 他承认，模型写的代码不如最优秀的合作者设计得漂亮，也不如他们的代码好读，但尚未看到比较两者 bug 率的科学证据。他的实际判断是：“自己找出来的 bug”总比客户报上来的事故好，即便组织对救火的奖励往往高于对预防的奖励。

精读

1. GPU 编译器可能接受的测试更少

Lebar 测试了两条发现路径：针对 NVIDIA 的 ptxas 和 AMD 的 LLVM GPU 后端进行随机程序模糊测试，随后让 LLM 检查 LLVM 的 AMD GPU、x86 及共享后端代码。
他的判断基于测试暴露度：主流 C++ 编译器已经处理过数亿乃至数十亿行代码，而相比 Google Search 这类产品背后的全部代码，一个 LLM 实际使用的 GPU kernel 数量相对有限。GPU 代码更少，可能意味着编译器接受的测试也更少。
结果只部分支持这一怀疑。AMD 产出了多个错误编译案例，x86 则出现了1个、也可能2个极其严重的 bug；但 Lebar 强调，发现率反映的是工具和搜索方法，不一定代表各后端本身的质量。

2. 模糊测试持续发现 bug，直到自身复杂度反客为主

一个有用的模糊测试器必须生成不寻常但格式正确、且不存在未定义行为的程序，然后证明编译前后行为等价。Lebar 让输出在 GPU 上运行；另一种做法则是使用解释器，逐条检查编译器输出的指令。
收益从3个方面递减：不断扩张合法程序空间变得更难，随机搜索能够触及的有效边界越来越少；而在发现约40个 bug 后，还必须排除已知模式，同时不能把相邻的未知模式一并屏蔽。NVIDIA 的模糊测试器不断重新发现同一种模式，让模型学会避开它的效果也并不好。

3. Agent harness 让代码审查具备经济可行性

在2025年12月至2026年1月期间，Codex 在发现1个或2个 bug 后停下来时，Lebar 一再对它说：“做得好，继续。” 新增的 /goal harness 支持让这项工作持续推进；更好的生成代码也让他可以“凭感觉把整套东西都写出来”，而这种做法在1月还曾失败。
直接检查源代码才是更大的突破口。即便审阅了超过30个 x86 发现，Lebar 仍表示，如果有人先把搜索范围缩到相关的100行代码，他几乎不会发现其中任何一个。
发布后，Opus 4.8 和 UltraCode 将大型 LLVM 扫描的 token 消耗降至“约1/10”。bug 数量下降，但看起来质量更高；而 Lebar 此前已经丢弃了许多发现。
他的归因仍然谨慎：4.8 看起来并没有比 4.7 聪明很多，因此他怀疑真正贡献更大的是 UltraCode 的编排，而非模型版本本身。这只是初步印象，并非受控对比。

4. bug 的严重性要经过分诊和修复才真正显现

最突出的 x86 bug 把一个特意构造的原子操作改写成两个非原子操作。没有竞争时，它可能一直不被发现，随后却偶尔返回错误结果；正是这种低频失败，让错误编译尤其具有破坏性。
NVIDIA 的闭源编译器产出了约40个容易复现的案例。一个明确案例连续4次执行“max, subtract”，结果返回错误答案；但由于无法访问源代码，Lebar 无法判断根因是普遍性问题，还是极其特殊的个案。
LLVM 维护者很快审查了修复方案，Lebar 修复了自己识别出的多数高优先级 x86 bug，其中大部分识别工作由模型完成。模型负责编写补丁，但他约50%的时候会进行修改，之后再用模型检查自己修订中的错误。

5. 软件质量判断仍跑在证据前面

Jordan Nanos 将这场张力概括为“slop AI”会产出有 bug 的软件，同时认为这类代码可能更臃肿，按代码行计算或许更差，却可能按已交付功能计算更好。Lebar 的反驳是，目前没有证据表明 AI 代码 bug 更多，也没有证据说明 LLM 找到其中 bug 更容易还是更难。
更广泛的主张是把资源投入预防：在真正重要的代码库上投入10,000美元；如果使用 UltraCode 扫描，成本约为1,000美元；然后发布更多案例研究。Lebar 希望把这套方法扩展到数据库、浏览器和其他编译器，也许再用 Mythos 或 4.8 检查 NVIDIA 汇编，同时提醒：“轶事的复数不是数据”（the plural of anecdote is not data）。

我们如何走到了史上最大IPO竞赛｜SpaceX、Anthropic与OpenAI 当 AI Agents 运营企业时——Andon Labs 的 Lukas Petersson 与 Axel Backlund