你的质量门禁能看到碗里的棕色M&M豆吗？
我注意到，越来越多的人开始接受变异测试（mutation testing）。他们逐渐明白，要想拓展智能体编程（agentic coding）的边界，质量门禁（quality gates，也就是开发流程里的质量把关环节）必须比现在严格得多，严格得多。
变异测试的做法是，故意往代码里注入错误，生成“变异体”版本——比如把 + 改成 -，或者把某个字符串替换成空字符串——然后看看自动化测试能不能抓住这些错误。如果所有测试都通过了，变异体“存活”下来，那就说明测试套件里可能有漏洞。
变异测试其实是我常说的“棕色M&M测试”的一种专门形式。你大概听过这个故事：范·海伦乐队（Van Halen）在演出合同的后台条款里，偷偷塞了一条要求——化妆间里必须放一大碗M&M豆，而且所有棕色豆子都得挑出来。这可不是摇滚明星耍大牌，而是一个非常实用的测试：如果主办方连这种细节都照做了，说明他们把所有环节都盯得很紧。范·海伦的现场演出有大量复杂的技术要素，一旦他们在化妆间看到棕色M&M豆，就会把整套设备从头再检查一遍。
变异测试的兴起令人鼓舞，而且说实话，早就该来了。但别停在这儿！你的 linter 规则又是怎么测试的？我会故意往随机的源文件里塞没被用到的 import，看看自动化代码审查能不能把它们全部找出来；我还会故意注入安全漏洞、竞态条件（race conditions），或者起一些毫无意义的标识符名称——这些都算是“棕色M&M”——用它们来检验这些质量门禁有没有缺口。（好了，搞“暗工厂”（dark factory）式全自动开发的那几位，承认吧，这招你们大概从来没想到过，对吧？）
过去三年多，通过实验和研究，我得出一个结论：人们对大语言模型（LLM）生成的代码的信心，更多取决于他们有没有看到“碗里的棕色M&M豆”，而不是代码本身的实际质量。当我看到那些声称生成代码质量很高、但我怎么也复现不出来的说法时，我已经不再问“他们做了什么我没做的事？”——在这一点上，我早就走在前面了——而是会问：“我看到了什么，是他们没看到的？”
来参加我的“代码工艺与AI”（Code Craft & AI）工作坊吧。这是一个动手实践、基于证据的工作坊，不吹嘘，不画饼。时间是10月6日（周二）18:45（英国夏令时）。自费学习者只需99英镑加增值税。