Finding Miscompiles for Fun, Not Profit：当 AI 代理成为编译器调试的主力军

背景

作者拥有在 Google、Waymo 和 OpenAI 从事机器学习编译器工作的十年经验，曾参与 clang 的 CUDA 支持、XLA:GPU、Triton 以及 OpenAI 的定制硬件开发。尽管见多识广，但在 2026 年 5 月左右，作者经历了一次职业生涯中令人不安的时刻：仅仅在一个下午，通过让 AI 代理运行编译器代码，他花费了超过 10,000 美元，在 LLVM 编译器中发现了数百个看似合理的 bug，其中包括许多误编译（miscompiles）以及至少一个“相当严重”的漏洞。

这一经历促使作者回顾并记录了他如何利用 AI 技术从传统的模糊测试（fuzzing）转向更激进的代码审查模式，以及这一转变背后的技术细节、成本效益分析以及对未来的启示。

核心内容

从 LLVM 到 ptxas：传统模糊测试的局限

2026 年 1 月，作者以个人项目为由，尝试在 LLVM（clang、rustc 以及 AMD GPU 编译器背后的编译器）中寻找 bug。他与 Codex 协作编写了一个模糊测试器。其基本逻辑是：生成随机程序，通过编译器的一部分进行编译，然后检查编译后的程序是否与原始程序行为一致（通常通过运行两个程序来比对）。经过几周的努力，他在 LLVM 的 instcombine（一种窥孔优化 pass）中找到了 5 个 bug 并修复了它们。随后，模糊测试器发现新 bug 的效率下降，作者便失去了兴趣。

到了 2026 年 5 月中旬，作者加入 SemiAnalysis 担任承包商，决定将同样的技术应用到 NVIDIA 的低级编译器 ptxas 上。他原本预期结果不会太乐观，原因如下：

1. 陷入局部最优：模糊测试器一旦找到 bug，往往会不断寻找触发同一 bug 的新方式。对于开源的 LLVM，修复 bug 后即可继续测试；但对于闭源的 ptxas，只能修改模糊测试器以跳过已发现的 bug，这非常繁琐。
2. 端到端编译的复杂性：在 LLVM 中，作者可以只运行特定的 pass（如 instcombine），而在 ptxas 中必须运行整个编译器。这可能导致需要更复杂的重现用例，降低了模糊测试器发现 bug 的概率。
3. 缺乏仪器支持：作者可以自行构建 LLVM 以添加仪器代码（instrumentation），帮助模糊测试器选择“有趣”的输入。虽然 AFL++ 支持从预编译二进制文件中收集仪器数据，但这会显著降低被测程序的速度，且效果不如预期。最终，作者在测试 ptxas 时仅使用了纯无向模糊测试（undirected fuzzing）。

然而，结果令人震惊。在短短三天内，作者发现了 40 个 ptxas 误编译的程序（一周后增至约 80 个）。许多重现用例（reproducers）简化后看起来是非常“正常”的指令序列。这些 bug 的测试用例托管在 GitHub 的 FuzzX 仓库中。

AI 驱动的模糊测试：从手动到“氛围编码”

这次模糊测试器之所以更容易编写，主要归功于 LLM 的进步。作者指出，这是 ChatGPT 5.2 与 5.5 之间的差异。这次，他完全通过“氛围编码”（vibe-coding，即通过自然语言描述意图而非编写代码）完成了整个模糊测试器，甚至没有看过一行代码。

LLM 承担了以下繁琐工作：

• 在每次发现 bug 后修改模糊测试器，避免重复触发同一 bug。
• 最小化生成的测试用例，有时耗时一小时以上。
• 独立决定模糊哪些 PTX 指令，以及哪些指令序列是“安全”的（即不会触发未定义行为）。

作者只需将其放入循环中，然后去睡觉。这种几乎零手动投入的方式，让他迅速发现了大量 bug。

从模糊测试到 AI 代理代码审查

在成功测试 NVIDIA 的 ptxas 和 AMD 的 AMDGPU 后端（发现 bug 的速度与 ptxas 相当）后，作者的 ChatGPT Pro 账户额度耗尽，转而使用 SemiAnalysis 的 Claude 账户。他发现 Opus 4.7 和 ChatGPT 5.5 在质量上没有显著差异，表现都很出色。

此时，AMD 已经修复了其中 5 个 bug。由于 AMD 编译器是开源的，作者可以立即应用这些修复。这展示了开源工具链的优势。

然而，随着 ptxas 和 AMDGPU 模糊测试器发现新 bug 的速度急剧下降（需要数小时才能找到一个新 bug），作者产生了一个念头：如果我不再构建模糊测试器，而是直接让 Claude 阅读 LLVM 代码并寻找 bug 会怎样？ 他意识到自己可能没有吸收“苦涩教训”（The Bitter Lesson，指通用方法最终胜过专用方法）。

于是，他让 Claude 每次启动 50 个子代理（subagents）来寻找 bug。结果令人咋舌：

• Claude 发现 bug 的速度为每 4 分钟一个（相比之下，模糊测试器需要数小时）。
• 一位朋友建议对 x86 后端进行同样的操作，发现 bug 的速度接近每分钟两个。
• 这些 bug 查找代理在停止前没有显示出减速的迹象，暗示潜在问题可能非常多。

成本与严重性分析

Bug 的严重性：

• 模糊测试发现的 bug：通常是可证明的误编译，严重性较高。
• AI 代理发现的 bug：平均严重性较低，因为代理依赖判断力，有时会误报。但在作者检查的 30 多个由代理发现的 bug 中，有一个极其可怕的案例：LLVM 会将原子存储（atomic store）转换为两个非原子存储。
  • 这种 bug 很难通过模糊测试发现（因为原子操作模糊测试很困难）。
  • 在生产环境中，99% 的情况下降级为原子存储可能没问题，但 1% 的情况下会导致数据损坏。这种静默数据损坏会破坏几乎任何生产系统，且极难根因分析。

成本分析：

• 氛围编码模糊测试器：相对便宜。作者使用了双倍的 ChatGPT Pro 月度配额（$200/月）同时编写 AMD 和 NVIDIA 的模糊测试器。
• Opus 4.7 模糊测试：按 token 付费，几天工作花费约 $1,000。
• AI 代理代码审查：非常昂贵。作者花费了超过 $10,000（甚至未使用快速模式），但这笔钱花得值得。因为代码审查可以发现通过模糊测试极难发现的整类 bug。

作者总结道，如果预算允许，他不会再 bother 与模糊测试，而是直接释放他的“代理大军”。那个原子操作 bug 潜在造成的损害远超 $10,000。

关键要点

• AI 大幅降低了编译器调试门槛：通过“氛围编码”，开发者无需深入代码细节，即可利用 LLM 构建复杂的模糊测试器，并自动化处理 bug 去重、测试用例最小化等繁琐任务。
• 从“执行测试”到“静态分析”的范式转移：传统的模糊测试依赖于运行程序来发现误编译，而让 AI 代理直接阅读源代码进行静态分析，能够以更高的速度发现潜在 bug，尤其是那些难以通过运行时测试触发的逻辑漏洞。
• AI 代理发现 bug 的速度远超传统模糊测试：在测试中，AI 代理发现 bug 的速度为每 4 分钟一个，而模糊测试器需要数小时。这表明在代码审查领域，AI 代理具有极高的效率。
• 严重性与发现方式的权衡：模糊测试倾向于发现可复现的、严重的误编译；而 AI 代理倾向于发现逻辑上的潜在问题，虽然平均严重性较低，但能发现如“原子操作降级”这类极难通过模糊测试捕捉的高风险漏洞。
• 高昂的成本换取极高的价值：虽然让 AI