一句话说：模糊测试（Fuzzing）是往系统里灌大量随机或半随机变形的输入，看它在哪里出错、崩溃或行为异常。
打个生活化的比方
质检一部手机，说明书式测试是"长按电源键 3 秒开机、滑动解锁、打开相机"。模糊测试是叫一群人上来乱拍乱摔、边充电边泡水、把取卡针插进麦克风孔。它不负责证明产品是对的，它负责找出产品错在哪。
这套流程自动化后靠三件事运转。种子（seed）——一批本身合法、能跑通的输入；变异（mutation）——在种子上随机翻转字节、插入删除、拼接、换编码；反馈——如果某次变异让程序走进了从没走过的代码分支，就把它留下来继续变异，这叫覆盖率引导（coverage-guided）。于是"瞎撞"变成了有方向的搜索。
它的判据很硬
传统模糊测试的信号几乎不需要人写预期结果：进程崩溃（crash）、断言失败、内存越界、卡死超时。所以它擅长发现的是"开发者没想到会发生"的那类问题。
| 方法 | 输入从哪来 | 判断标准 | 擅长发现 |
|---|---|---|---|
| 单元测试 | 人手写 | 人工断言 | 已知逻辑分支 |
| 属性测试 | 按规则随机生成 | 通用不变量 | 边界与组合情况 |
| 模糊测试 | 在种子上变异 | 崩溃、超时、校验失败 | 未知的崩溃点 |
搬过来测提示词和工具调用
大模型不会段错误（segmentation fault），但会"软崩溃"：输出解析不了、调用了不存在的工具、参数填成幻觉、答非所问。
套路完全可以照搬。种子就是一批正常的提示词和正常的工具调用（tool calling）样本；变异则是加错别字、中英混写、塞 Emoji、插入自相矛盾的指令、把上下文拉到很长、把数字参数写成"三"、把枚举值写成近义词、漏掉必填字段、在多轮对话里突然改主意或要求忽略之前的指令。
判据交给自动校验器，而不是人眼：返回的 JSON 能不能按 schema（模式）解析、工具名是否真实存在、参数类型是否合法、回答里有没有凭空捏造的数据。这类检查最适合接进持续集成（CI），每次改提示词或换模型都跑一遍，看通过率有没有掉下来。至于具体用哪个工具、模型支持到什么程度，以官方页面为准。
对普通人意味着什么
你手上那个"偶尔莫名其妙报错"的 App，很多坑就是被这种乱来的测试提前撞出来的。反过来，你自己用 AI 时把同一个需求换三种说法各试一遍，其实就是在手动做一次模糊测试——只不过这次的种子是你，变异是问法。