用 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 了……