把代码生成的活交给AI，bug也跟着进来了。

研究者的办法挺直接——先把这些bug分门别类搞清楚。一篇2025年的调查把AI生成代码里的bug归成了八类：功能bug、可靠性bug、语法bug、代码风格和规范问题、幻觉、系统bug、测试bug，还有一个兜底的“其他”。另一项实证研究从333个真实bug里提炼出十种反复出现的模式，比如误读需求、漏掉边界情况、虚构对象。两套框架各有侧重，拼在一起，大致描出了这片地雷区的全貌。

这个分类不是搞排名，哪个bug更可恶。它的价值在于另一件事：你可以对着这张地图，把每一类bug分配到最能抓住它的那一层防线上去。

先说那些扫描器能稳稳拿下的类型。只要bug身上带着某种结构上的指纹——比如虚构的import语句、性能反模式、硬编码的密钥、语法错误，或者跨文件的数据污染——基于规则的扫描器就能盯上它们。12个扫描器配好规则，匹配的是模式，不是意图。一个根本找不到对应库的import，一段用csv +=在循环里反复重建字符串的代码，一个带着shell=True的subprocess调用，一串长得像AWS密钥的高熵字符串：这些东西每次都触犯同一条规则，不需要判断代码到底想干什么。

这类bug对应着分类法里的语法类、可靠性类，以及幻觉类中的一部分。有人管这摊活叫“确定性门禁”该干的事，说得挺准。规则能稳稳命中的，就交给规则，不打折扣。

另一类bug就完全是另外一回事了。功能逻辑错误、漏掉的边界情况、跑得挺顺但答案算错了的代码——这些东西语法上挑不出毛病，规则根本没东西可匹配。它们对应着调查里提到的功能bug，以及实证研究中发现的误读和边界遗漏模式。要抓住它们，你得知道代码本意是做什么。这需要理解上下文，而一旦扫描器开始推测上下文，它就开始犯错。

所以设计思路是在这里划一条清晰的界线：扫描器把这些可疑的模式和周边上下文按YAML格式报出来，至于逻辑对不对，由人或者像Claude Code这样的大模型来判断。分工明确，不越界。

八类bug中最棘手的“幻觉”类型，至少有一个切口可以变成干净的检查：虚构的import。这种import要么能解析，要么不能，没中间地带。但幻觉类的其他变体——比如代码看起来合理，跑起来也不报错，但实际上完全搞错了事实——就没这么便宜了。语法对，逻辑顺，唯独在现实世界里不成立。这种bug不留下任何规则能抓住的结构性痕迹，它考验的是对代码意图和外部世界的双重理解。

说到底，这份分类法给了一幅分工图。有结构标记的bug，交给确定性扫描器一次性搞定。那些需要理解“代码到底想干什么”的bug，被标记出来，连同上下文一起打包，等着人或更强的模型来做最后的裁决。知道哪类bug属于哪个处理层级，你才能决定哪些环节自动化，哪些环节老老实实读代码。