🦀 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实验室