🦀 ClozeMaster：用LLM给Rust编译器"找茬"——AI驱动的模糊测试新范式

论文: ClozeMaster: Fuzzing Rust Compiler by Harnessing LLMs for Infilling Masked Real Programs
作者: Hongyan Gao, Yibiao Yang, Maolin Sun, Jiangchang Wu
arXiv: 2605.00413 | 2026-04-29

一、那个"编译器也有bug"的现实

想象你写Rust代码：

• 代码逻辑正确
• 但编译器崩溃了
• 或者生成了错误的机器码
• 你的程序运行时出错

问题：是代码错了，还是编译器错了？

Rust编译器虽然以安全著称，但它本身也可能有bug。

测试编译器的挑战：

• Rust语法复杂
• 类型系统严格
• 生成有效程序很难
• 随机生成的程序大多编译不过

二、传统模糊测试的困境

模糊测试（Fuzzing）：

• 随机生成输入
• 看系统是否崩溃
• 有效发现bug

但编译器模糊测试很难：

语法约束：

• 随机字符串几乎都不是有效Rust代码
• 编译器在语法检查阶段就拒绝了
• 无法触及深层逻辑

语义约束：

• 即使语法正确
• 类型检查可能失败
• 借用检查可能失败
• Rust的严格性让"随机有效程序"极其稀少

三、ClozeMaster：LLM驱动的填空式模糊测试

这篇论文提出一个创新方法：

核心思想：

不是从零生成程序，而是拿真实程序，挖掉一部分，让LLM填空——既保证语法正确，又引入变化。

技术方案：

1. 获取真实程序

• 从开源代码库收集真实Rust程序
• 这些程序已经通过编译
• 语法和语义都正确

2. 挖空（Masking）

• 随机选择程序的一部分
• 用占位符替换
• 如：函数体、类型注解、表达式

3. LLM填空

• 把挖空后的程序给LLM
• LLM根据上下文推断缺失部分
• 生成合理的替换

4. 编译测试

• 把填好的程序编译
• 看是否：
  • 编译器崩溃？→ 找到bug！
  • 编译通过但输出错误？→ 找到bug！
  • 行为异常？→ 找到bug！

这就像给编译器做"完形填空"：

• 给一段文章，挖掉几个词
• 让人填
• 如果填完后文章"意思变了" → 语言理解有问题
• 如果填完后编译器"行为异常" → 编译器有bug

四、为什么LLM填空比随机生成更好？

随机生成的问题：

无效输入：

• 99.99%的随机字符串不是有效Rust
• 语法检查就过滤了
• 无法测试编译器深层逻辑

LLM填空的优势：

保持有效：

• 基于真实程序
• LLM保证填空的语法正确性
• 大部分输入都能到达编译器深层

引入变化：

• 不同的填空产生不同的程序
• 探索代码空间的多样性
• 触及编译器的不同代码路径

语义合理性：

• LLM填写的代码通常"有意义"
• 不是语法正确但语义荒谬
• 更容易触发真实bug

五、费曼式的判断：好的测试从真实出发

费曼说过：

**"知道一个东西的名字"和"真正理解一个东西"是完全不同的。"

在模糊测试中：

"随机生成是'从虚无创造'。LLM填空是'从真实变异'。后者更接近真实世界的输入分布，因此更可能发现真实bug。ClozeMaster的智慧在于：不是凭空捏造测试用例，而是让AI在真实代码上'做实验'。"

这也体现了测试的基本原则：

• 测试用例应该代表真实使用场景
• 随机不等于真实
• 基于真实的变异 > 完全随机

六、带走的启发

如果你在测试复杂系统或编译器，问自己：

1. "我的模糊测试是否生成了太多无效输入？"
2. "能否利用LLM在真实数据上引入可控变异？"
3. "填空式生成是否比从头生成更有效？"
4. "真实程序的分布是否比随机分布更有价值？"

ClozeMaster提醒我们：测试编译器不需要成为Rust语言专家——只需要聪明地利用LLM在真实代码上做实验。

在软件质量的前线，最好的测试员不是写最多测试用例的，而是最懂得利用AI来探索边界条件的。

在Rust的安全世界里，编译器本身也需要被保护——而ClozeMaster就是它的守护者。

#Fuzzing #Rust #CompilerTesting #LLM #SoftwareQuality #FeynmanLearning #智柴AI实验室