AI写代码3年，工程师最恨的不是它错，是它错得太像对的

去年某大厂技术复盘会上，一个团队统计了AI辅助编程的返工率。数据让人沉默：模型生成的代码里，有12%需要完全重写，但真正拖垮进度的，是那种"看起来能跑"的错误——语法正确，风格统一，甚至注释都写得像人写的。工程师花了4小时调试，最后发现函数根本不存在。

这就是AI幻觉在工程场景里的隐蔽形态。不是那种一眼假的胡言乱语，而是精心伪装的"合理错误"。

幻觉的进化：从胡说八道到一本正经

早期大模型的错误很好抓。你问它一个API，它可能编个完全不存在的函数名，拼写怪异，参数数量对不上，IDE直接标红。这种错误成本低，编译器帮你拦住了。

但现在不一样了。模型学会了"风格模仿"。

它看到代码库里有个ins_create_event，8个参数，于是推断应该有个ins_create_alert_from_event来处理扩展字段。命名规范一致，语义逻辑通顺，甚至参数设计都符合上下文惯例。唯一的问题是：这个函数是模型当场编的。

更麻烦的是它的输出姿态。语气冷静，措辞专业，"基于现有调用推断"这种说辞听起来像资深工程师的惯性操作。你很难对一份"看起来很有经验"的建议保持警惕。

plausible wrong answers waste far more engineering time than obviously bad ones.

这句话来自原文，也是很多团队的血泪总结。明显错误是即时反馈，合理错误是延迟爆破。

为什么工程师会上当

这里有个反直觉的点：越是经验丰富的开发者，越容易踩这个坑。

新手面对AI输出会逐行核对文档，老手反而依赖"代码嗅觉"——扫一眼风格对、命名规范、上下文衔接自然，就默认可信。而AI恰恰攻破了这层嗅觉防线。它模仿的不是功能正确性，而是"正确性的质感"。

那个虚构的ins_create_alert_from_event，在被质疑后，模型自己承认了：「我推断那个名字来自现有的8参数调用，假设需要一个单独的辅助函数来处理额外字段。那是错误的。」

注意这个措辞："推断""假设""辅助函数"。它不是在随机生成，是在做有逻辑的虚构。这种虚构比胡编更难防御，因为它嵌入了真实的推理链条。

一些团队在用的土办法

没有银弹，但有些做法在降低误伤率。

强制引用溯源：要求AI在建议函数调用时，必须给出定义位置的文件路径或文档链接。编造的函数通常给不出具体出处，或者给出的链接404。

沙箱编译验证：AI生成的代码片段先扔进隔离环境跑一遍，不通过就不进入人工审查环节。这招对"函数不存在"类错误几乎百发百中，但会增加交互延迟。

人机分工重构：把AI输出当作"草稿需求"而非"实现方案"。工程师负责结构把关，AI填充细节。反过来让AI主导架构、人填细节，翻车率会指数级上升。

最朴素的防线可能是：对任何AI生成的函数名，先全局搜索一遍代码库。这个动作只要30秒，能拦截大半幻觉。

但问题是，当AI的输出越来越流畅、越来越"像那么回事"，你还愿意花这30秒吗？