我如何用一个“骚操作”，让 Gemini 2.5 PRO 都赞不绝口

摘要： 这不是一篇鼓吹或唱衰AI的文章。作为一个每天都在使用大语言模型（LLM）辅助工作的开发者，我将通过一次为 Redis 开发核心功能时遇到的真实疑难杂症（Bug），分享我与 Gemini AI 协作解决问题的全过程。故事最终的解决方案，或许能让你更深刻地理解，为何在创造性思维和“非正统”问题解决能力上，人类程序员仍然遥遥领先。

引言：AI是我的日常“副驾”

熟悉我的朋友都知道，我绝不是一个“AI威胁论”者。恰恰相反，LLMs早已深度融入我的日常工作流。无论是快速验证一个想法、进行代码审查、探索更优的实现路径，还是涉足我不那么熟悉的领域，AI都是我首选的“智能伙伴”。

然而，近来关于AI的讨论日益两极分化，理性的声音愈发稀缺。因此，我想通过一个今天发生的真实故事，分享我的观点：AI工具虽已非常强大，但在真正的智慧和创造力面前，它与人类大脑之间仍存在着巨大的鸿沟。

棘手的挑战：向量索引中的“幽灵链接”

今天，我正在为Redis开发一个名为“向量集合”（Vector Sets）的新功能。期间，我遇到了一个极其隐蔽且棘手的Bug。

事情的背景是这样的：在我之前离开Redis期间，我的同事们为了增强系统的数据鲁棒性，增加了一项防护功能。该功能旨在抵御因Redis数据文件（RDB）或恢复命令（RESTORE）发生数据损坏而导致的问题——即便数据通过了常规的校验和（checksum）检查。这项功能默认关闭，但用户可以手动开启以获得更高的安全性。

这个新功能，却给我的工作带来了巨大的麻烦。

为了实现高效的数据持久化和恢复，我对我实现的HNSW向量搜索算法的图结构进行了直接序列化。简单来说，我没有存储海量的原始向量数据，然后在加载时花费漫长的时间（可能慢100倍以上）去重建索引，而是巧妙地将图节点之间的连接关系（用整数ID表示）直接保存下来。加载时，我再将这些整数ID“修复”成内存指针。

问题来了： 如果保存的节点连接数据发生了随机损坏，会发生什么？

由于我改进的HNSW实现强制要求图中的节点链接必须是双向的（即如果A链接到B，那么B也必须链接到A），一旦数据损坏，就会出现致命问题：

1. 我们加载了一份损坏的数据，其中节点A的邻居列表里有节点B，但节点B的邻居列表里却没有节点A。双向链接被破坏了。

2. 当某个操作触发删除节点B时，程序会遍历B的邻居并清理指向B的链接。但由于A的链接信息已损坏，程序找不到B -> A这条路径，因此无法清理A中指向B的“幽灵链接”。

3. 此后，当任何操作试图通过节点A访问它那个已经被释放的“邻居”B时，就会发生使用已释放内存（Use-After-Free）的严重Bug，导致程序崩溃。

因此，在加载完数据后，我必须增加一个验证步骤：检查图中的每一个链接是否都严格满足双向性。

最直接的实现方式是暴力检查，其时间复杂度为 O(N2)，其中 N 是节点的数量。对于一个包含2000万个向量的大型数据集，这意味着灾难。

人类 vs 大语言模型（LLM）

起初，我用最简单粗暴的方法实现了这个检查，虽然解决了Bug，但加载一个大型数据集的时间从原来的45秒飙升到了90多秒。这种性能退化是完全不可接受的。

于是，我打开了 Gemini 2.5 PRO，向它求助。

第一回合：常规方案的极限

我向Gemini描述了问题，并询问优化的可能性。

Gemini的建议很标准，也很正确：它提出了教科书式的最优解——对每个节点的邻居ID列表进行排序，然后使用二分搜索（binary search）来查找反向链接是否存在。

这个方案我当然知道。但问题在于，HNSW图中每个节点的邻居列表通常很短（比如16或32个元素）。对这么短的数组进行排序和二分搜索，其带来的开销很可能比直接线性扫描还要大。

我向Gemini解释了这一点，并追问：“还有没有其他方案？”

Gemini回答：没有更好的方案了。

第二回合：“哈希表”与思维的第一次跳跃

AI的路似乎走到头了，现在轮到人类大脑上场。我向Gemini提出了我的一个想法：

我们可以创建一个临时哈希表。当我们遍历图时，对于每个链接 A -> B，我们始终保持 A 的ID小于 B 的ID，然后将 "A:B:level"（level是链接所在的层级）这个组合作为键存入哈希表。如果哈希表中已存在这个键，说明我们遇到了 B -> A 的反向链接，是成对的，就将它从哈希表中删除。遍历结束后，如果哈希表不为空，那么剩下的键就是那些“单相思”的损坏链接。

Gemini对这个方案表示认可，但它也提出了一个合理的担忧：构建哈希键的开销可能会很大，比如使用 snprintf() 来格式化字符串。

我立刻进行了优化：“我们根本不需要格式化字符串。节点的ID本质上是指针，我们可以直接用 memcpy() 将两个指针（A和B的ID）和一个层级信息（level）拷贝到一个固定大小的字节数组中，以此作为哈希键。”

Gemini同意我的想法，并认为这很高效。

第三回合：灵光一闪的“异或”心法

就在与Gemini的讨论中，我的大脑突然“跳”到了一个更疯狂的思路上。

“等等！” 我对Gemini说：“我们根本不需要哈希表那么复杂的数据结构！”

我们可以用一个固定大小的累加器（accumulator），比如一个12字节的数组，并将其初始化为零。在遍历所有链接时，对于每一个链接（A -> B，在level X），我们将 A、B、X 这12个字节的数据（假设指针是64位，即8字节），与累加器进行**按位异或（XOR）**操作。

accumulator ^= (A_id | B_id | level)

由于异或运算的特性（A ^ A = 0），如果一个链接是双向的（A->B 和 B->A），那么它会被计算两次，正好自我抵消。最终，如果整个图是完整的，累加器的值必然会变回零！

这个想法让我自己都感到兴奋。它将空间复杂度从哈希表的 O(N) 降到了 O(1)，并且计算速度极快。

但同时，我也立刻指出了这个方案的致命弱点：哈希碰撞。如果恰好有多个不同的单向链接（比如 L1, L2, L3），它们异或后的结果可能也为零（L1 ^ L2 ^ L3 = 0），从而导致漏报。

Gemini对我的“异或”想法印象深刻，同时也表达了同样的担忧。它补充道：由于内存分配器（allocator）分配的地址往往具有相似的结构（比如高位地址相同），这会使得指针的值并非完全随机，从而增加了碰撞甚至被攻击者恶意利用的风险。

我追问Gemini如何改进这个“异或”方案，它再次卡住了，想不出更好的办法。

最终方案：人类智慧的“终极骚操作”

AI再次止步的地方，正是我需要再次进行创造性跳跃的起点。我向Gemini提出了我的最终解决方案，一个融合了密码学思想的方案：

1. 在验证开始时，我们首先从 /dev/urandom 获取一个高强度的随机种子（S）。这个种子在每次加载时都不同。

2. 对于每个链接 A -> B，我们不再直接对ID进行异或，而是将 随机种子S 与链接信息（A、B、level）组合在一起，形成一个数据块 S:A:B:level。

3. 我们使用一个快速且高质量的哈希函数（例如murmur-128）对这个数据块进行哈希，得到一个128位的哈希结果。

4. 将这个128位的哈希结果，与一个128位的累加器进行异或。

5. 遍历结束后，检查128位的累加器是否为零。

Gemini对这个最终方案给出了极高的评价。

它完美地解决了所有问题：

• 性能极高： murmur-128 这类非加密哈希函数速度飞快，整个验证过程几乎没有额外开销。

• 碰撞概率极低： 128位的哈希空间使得意外碰撞的概率可以忽略不计。

• 安全性极强： 外部攻击者无法预测随机种子S，也几乎不可能控制节点指针的内存地址来精确构造一次哈希碰撞，从而绕过检查。

这个方案优雅、高效且极其健壮。它是我即将（很大概率）在Redis代码中实现的方案。

结论：AI是伙伴，而非主宰

这次经历清晰地表明：

人类大脑在创造力、思维跳跃性和整合不同领域知识的能力上，依然远远领先于当前的人工智能。

从 O(N2) 的暴力法，到 O(NlogK) 的二分搜索法，再到 O(N) 的哈希表法，这些都是AI知识库里的“存量知识”。但从哈希表跳跃到“裸异或”，再从“裸异或”结合密码学思想升级为“随机化哈希异或”，这种“weird but effective”（怪异但有效）的解决方案，是AI难以独立完成的。

然而，这并非否定AI的价值。恰恰相反，LLM在这个过程中扮演了至关重要的**“催化剂”和“智能陪练”**角色。它帮我确认了常规方案的边界，验证了我初步想法的利弊，它的存在，就如同一个能随时响应的聪明同事，激发了我去思考更深、更“野”的路径。

或许，正是因为有了这个“智能小伙伴”的壁打ち（日文，意为“对着墙壁打球”，引申为思路碰撞），我才能如此迅速地构思出最终的解决方案。

所以，拥抱AI吧，把它当作延伸你智慧的强大工具。但永远不要忘记，那真正能点燃灵感火花、实现从0到1飞跃的，依然是我们人类自己那颗充满无限可能的大脑。