原本以为现在头部 AI 模型的幻觉已经很低了，而且觉得我挺能辨别 AI 幻觉的，结果今天还是被摆了一道

用 Django ORM 写了个函数查询 Postgres 数据库，发现 ORM 的速度比原生 SQL 语句慢了好几倍，于是去问 Gemini 2.5 。

Gemini 让我打印出生成的 SQL 语句看看是怎么一回事，我一看，ORM 查询条件是大小写不敏感的，使用了icontains算符；但是 Django 在把查询条件翻译成 SQL 语句的时候没用上 Postgres 特有的不区分大小写的ILIKE算符，而是将式子两边都转换成了大写，用了UPPER() LIKE UPPER()。这下知道原因了，这种情况下字段的索引根本没用上。

那就改嘛。然后 Gemini 信誓旦旦地告诉我，这是非常不同寻常的，Django ORM 肯定能自动将 icontains 翻译成ILIKE。我觉得也很有道理，Django 这么老牌的框架，Postgres 也不是什么冷门数据库，怎么会处理不好适配呢，肯定是我自己的问题。

然后我就照着 Gemini 给的方案一步一步调试，是不是你的 Django 配置有问题？是不是 Django / psycopg / Postgres 版本哪里冲突了？做个最小化测试试试？每一步都没有问题，我跟 Gemini 都感到非常困惑。

两个小时之后我才意识到有哪里不太对劲，于是新开了一个对话让他联网搜一下有没有人遇到过类似情况。然后他哐哐搜出来好几篇网页，网页里的人类全都明确地指出 Django 会把icontains转换成UPPER()。但是就算是在包含了这些信息的新对话里，Gemini 还是嘴硬地声称：

标准行为是 ILIKE：多个来源（包括 Django 官方讨论、Stack Overflow 、博客文章）都明确指出，对于 PostgreSQL ，Django 的 icontains 应该被翻译成 ILIKE 。这是 Django 利用 PostgreSQL 对大小写不敏感的 LIKE 查询的原生支持的方式。

最后我只能去翻了翻 Django 的源码，发现源码里确确实实是将icontains翻译成了UPPER() LIKE UPPER()，没有用上ILIKE，原来整个大前提都是 AI 的幻觉。又问了问几个头部模型，每一个都热心地指点我应该如何排查问题，要怎样怎样解决，没有一个指出来这确实就是 Django 应有的行为。反思了一下，我现在写代码似乎有点太过于依赖 AI 了……