人类程序员，依然比LLM 更好

原文链接：antirez.com/user/antirez

本文原作者是 Redis 作者 antirez，他通过一个例子证明人类在创造力优势仍然碾压 LLM。 而我自己的想法呢? LLM 目前只能 解决 100 行代码以内的问题， 或者写一个俄罗斯方块小游戏。

这是一个关于“人类仍远胜于大模型（LLMs）”的小故事。先声明：我并不是反对 AI，如果你认识我，或者关注过我，就知道我其实是 LLM 的常客。我经常用它来测试自己的想法、做代码审查、探索更好的方案，甚至在一些接近我知识盲区的地方借助它发散思路。大概两年前我就写过一篇关于用 LLM 编程的博客——那时候用 LLM 还远没现在“潮”呢。自那以后我一直没停用过，可能该更新一篇新版本的使用感想了，不过这不是本文的重点。

我想强调的是：尽管当前的 AI 很有用，也确实非常强大，但它离“人类智能”还有很长的路。这点我们必须说清楚，尤其是在当下这个“AI 能做一切”的时代，很难和人们进行理性的对话了。

Redis Vector Sets 的真实案例

今天我在修复 Redis 的 Vector Sets 模块里的一个复杂 bug。Redis 的开发工作在我离开后持续进行，我的同事们引入了一个新的数据安全机制：即便数据的校验和（checksum）通过了，如果检测出结构不一致，也会拒绝载入。这个机制默认是关闭的，但对于追求更强健的系统而言，它是一道额外的安全保障。

听起来不错？但也有个严重的问题。

为了加快 HNSW 图结构在 RDB 文件中的保存与加载，我没有序列化向量元素对，而是直接序列化了整张图的连接关系（link graph）。这是因为如果重新插入 HNSW，会比直接载入图结构慢大约 100 倍。我保存的是每个节点的邻居列表，用整数 ID 表示，载入时再把它们解析为指针。这种技巧很好用。

但问题出在这里：

1. 如果数据损坏，可能会出现 A 链接到 B，但 B 不再链接回 A 的情况（链接不再是互相的）。
2. 删除 B 时，因为没有检测到 A 到 B 的链接，A 的引用没被清除。
3. 最后我们扫描图时访问 B，进而访问 A：这就是经典的 use-after-free（释放后使用） 错误，😃 😄 😐。 PS: 这不是重点，重点是跟Gemini 2.5 Pro 对话的过程

人类 Vs LLM

所以我需要一个方案，在载入数据之后检测所有链接是否是互相的。最原始的做法自然是穷举式检查——对于每个节点、每一层，枚举它的所有邻居，确保邻居也反向链接回来。但这是 O(N²) 级别的操作，对于拥有 2000 万向量的大图来说，载入时间直接从 45 秒飙升到 90 秒以上。WTF。

于是我打开了 Gemini 2.5 Pro，问它：你有什么高效方案推荐吗？

它的“最佳建议”是：把邻居链接排序，这样可以用二分查找判断是否互链。这个我当然知道了……而且在节点指针数组长度只有 16 到 32 的情况下，排序能不能带来真正加速都不好说。我继续追问：还有其他更好的方法吗？没有。

于是我给它出了个点子：

我们每当遇到 A 链接 B，记录一个键 A:B:X（X 是层级），不过为了去重，我们始终让 A > B（即只记录其中一个方向的链接），然后用哈希表记录。如果之后发现了对应的反向链接，就从哈希表中删掉。最终如果哈希表非空，就说明有非互相的链接存在。

Gemini 觉得这是个好主意，但它提到 snprintf() 构造键的开销和哈希开销。但我指出，其实根本不用 snprintf()，我们可以直接 memcpy() 三段固定长度的值拼成键，它立刻意识到确实如此。

然后我灵光一闪，继续问它：

如果我们用一个固定大小的累加器（accumulator），每当遇到一个链接 A:B:X（8+8+4 字节），我们就把它 XOR 到累加器里？只要链接是互相的，它们就会抵消（XOR 两次变 0）。如果最后累加器不为 0，说明肯定有遗漏。

不过我也提前提醒它：这种方案可能会发生碰撞（false negative）。虽然这个“增强数据一致性检测”功能默认是关闭的，属于用户自己愿意打开的安全选项，但也不能完全放弃对攻击者构造恶意载荷的防护。

Gemini 表示这个想法“挺酷的”，但指出了潜在的问题：指针通常具有相似的结构，只差几个位。如果三个错误链接 L1、L2、L3 恰好 XOR 得到 0，那就会漏报。而且许多内存分配器的地址分布很有规律，容易被外部预测。

我又问它有没有改进办法，还是没有更好的点子。

我继续推演：那我们能不能用高质量的哈希函数（比如 MurmurHash-128）来代替直接 XOR？

我向它提出了这样的方案：

1. 对每个链接 A:B:X，我们加一个种子 S（来自 /dev/urandom），构造出键 S:A:B:X。
2. 用 MurmurHash-128 对其做哈希，结果 XOR 进一个 128 位寄存器。
3. 最终判断寄存器是否为 0：若非 0，则存在非互相链接。

我请 Gemini 评估这一方案，它这次终于满意了。它说这种方式大大降低了误报的概率：既不容易碰巧抵消，又很难被攻击者利用构造伪数据（因为种子 S 不可预测，指针也不可控）。对于一个默认关闭、强调性能的“最好努力（best effort）”型特性来说，这种方案非常实用。

结语：为什么人类仍然领先

我写完分析后，停下来把整个过程写成了这篇博客。我还没决定是否采用这个方案，但很可能会。

我要说的是：人类的大脑仍然具有压倒性的创造力优势我们可以从完全不同的角度出发，想到那些不那么精确、但非常有效的“非典型”方案。而这，正是目前 LLM 难以企及的。

尽管如此，我必须承认，Gemini 在整个过程中起到了非常有价值的作用——它是个很棒的“智能橡皮鸭”。没有它，我或许不会那么快地走到这个点子。

如果你也正在做高性能系统开发，别忘了：LLM 是强力辅助，而不是人类智慧的替代。聪明的大脑 + 有限的机器学习，才是当下最靠谱的组合。