随着AIGC技术大行兴起，大量开发者开始实际使用AI助手为自己编码、查询技术问题、生成文本或编写文档。这类工具（如ChatGPT）确实帮我们节省了大量搜索和简单编码时间。但是，它并非无所不能，有时候会"抽风"一下。
这种现象，我们一般称之为AI幻觉 (AI Hallucination) 。
AI幻觉：是指不基于事实或数据，AI生成了看似合理但第一眼看不出错的错误结论或信息。
下面我们通过我自身经历的三个简单案例，来看看AI怎么幻觉。
案例1：用TRAE编写在线考试系统，一个跑起来全是空的项目
首先揭示的是这篇文章：用AI写了一个在线考试系统，我按照AI给出的方案开始搭建基于TRAE的项目。
初看没问题，但一运行项目，惊下一身冲：全部页面是空的！
经过一段时间调试我发现：
- AI 在配置路径、vite和react-router配置时给错了值；
- 前端VUE生成的标签有频繁的"闭合错误"问题。
最过分的是有次生成4000个一样的标签，直接弄倦IDE。
后来我全部代码删掉，再重新生成一次代码，才稍微解决问题。
这里最值得提醒的是：AIGC生成的前端代码看上去没问题，但实际实现不少粗差。特别是含有跨环境、路径配置、JSX编译时。
案例2：DDL语句不锁表？你信了就上当
我还用AI查询过关于MySQL DDL语句是否锁表。原问：MySQL5.6 InnoDB表扩元素时是否会锁表。
AI回答"不会锁表，InnoDB是支持在线DDL操作的"，但我经过添加列、修改列类型、删除等DDL操作对环境上一组大表演练后，发现：
但许多
ALTER TABLE操作（尤其是加列并指定位置、加索引等）仍可能引发元数据锁或表拷贝，导致实质锁表。
部分DDL操作会导致全表锁，如果直接影响环境线业务，很有可能造成大量请求缓慢或扩散故障。若轻信AI在现网执行，后果将是服务大规模中断与用户投诉风暴。
这种错误不得不规范一下AI"说得有理"之后，自己还是要稍微清醒点脸。
案例3：调研SQL WHERE条件时序时，AI拿错Stack Overflow链接
最后还有一段经历是我最"短路"的一次。
我讲经过一组工作是研究下MySQL WHERE条件式A AND B vs B AND A的执行效率是否有差别。
AI回答第一句话是正确的："序序不会影响结果，但可能影响执行效率。"
但后面很坑爽：它为了证明"SQL 不支持短路"，给了一个Stack Overflow的链接，我开开看------
根本和短路无关！
他还说"有多位工程师确认SQL不支持短路"，我是短路了才相信他说的话。
- AI生成的"信息源"有时是虚构或错误绑定；
- 看似优雅而且专业的表达，其实可能是脱离实际的"纯美时光" 。
总结
从上面三个案例我想表达一个核心观点：
- 保持怀疑态度：对 AI 提供的信息进行独立验证，尤其是在关键操作和配置上，比如数据库的DDL操作，linux的rm -rf操作等。
- 查阅官方文档：优先参考官方文档和权威资料，确保信息的准确性。
- 进行测试验证：在生产环境部署前，先在测试环境中验证 AI 生成的代码和配置。
- 持续学习：不断提升自身的技术能力，减少对 AI 的依赖。
AI 是强大的辅助工具，但不能完全替代人类的判断和经验。在享受 AI 带来便利的同时，我们更应保持警惕，确保最终产品的质量和可靠性。