主要观点总结
本文报道了Antirez关于人类程序员与大模型AI在编程方面的比较和分享，Antirez认为人类在打破常规、设想出奇特且有效的解法方面仍优于大模型。同时，文章还讨论了开发者们对于AI作为编程助手的看法，以及AI在编程领域的应用和影响。
关键观点总结
关键观点1: Antirez分享人类与AI在编程方面的优势对比
Antirez通过个人经历分享，展示了人类在编程过程中能够打破常规、设想出奇特且有效的解法，相较于大模型AI仍具有优势。大模型AI虽然能够提供一定的帮助，但在某些情况下缺乏创造性和批判性思维。
关键观点2: 开发者对AI作为编程助手的看法
部分开发者认为AI可以作为编程助手，提供交流和思路的启示。但也有开发者指出AI助手存在的问题，如自信过度、提供错误答案或干扰思路等。有效利用AI的关键在于经验和对AI的理解。
关键观点3: AI在编程领域的应用和影响
AI在编程领域的应用逐渐普及，如IDE、版本控制、自动化测试等。AI能够生成代码、自动化任务、调试软件等，但仍不能完全取代程序员。未来软件工程师需要随着AI的发展而进化，理解并有效使用AI是关键。
正文
之后在扫描该 graph 时，一旦到达 B 时就会遇到 A：释放后重用……
因此在加载数据之后，Antirez 需要检查每个链接是否互换。在一般情况下，结果应该是 O(N^2)，代表着对于每个节点，开发人员需要扫描所有层级、在每个层级上扫描该节点的全部邻居，再通过扫描该层级的链接来检查其是否同样链接至该节点。“这显然不好。”
Antirez 首先采用了最常规的办法，看看模糊测试器能不能找到 bug。结果确实有效，但加载一个包含 2000 万向量的大型向量集的时间从 45 秒变成了 90 秒左右。这当然不能接受，于是 Antirez 打开了 Gemini 2.5 PRO 的聊天窗口，问大模型：“我该怎么办？有没有速度更快的办法？”
Gemini 给出的最佳方案是：对相邻链接的指针进行排序，这样就能使用二分查找。
Antirez 认为这也有点道理……他知道可以这样，但不确定在拥有 16/32 个指针的数组中，这种方法是不是真的更快。所以 Antirez 问：“还有其他办法吗？”
很遗憾，Gemini 给不出更好的方案。所以，Antirez 告诉它：那咱们这样想，当我们在 X 层级上看到 A 链接到 B 时，会将其以 A:B:X 的形式将其存储在一个哈希表中（我们会始终对 A 和 B 进行排序，使得 A>B，因此无论方向如何链接均相同），而在再次看到该链接时就将其清除。这样我们只需要扫描整个表，类似于我们在将 ID 解析为链接中指针时所做的那样。如果最后该哈希表不为空，我们就能确定肯定存在着某个非互换链接。
Gemini 表示这确实是个好主意，虽然这需要使用 snprintf() 来创建键，而且哈希运算也需要时间等待……但已经比 Antirez 的方法（甚至包括对指针进行排序）要好。Antirez 则提醒 Gemini：其实这里不需要 snprintf()，可以直接 memcpy() 固定大小的键中的指针。Gemini 再次被说服。
之后，Antirez 告诉 Gemini：要不要对 A:B:X 使用一个固定大小的累加器？这甚至连哈希表都不需要。每当我们看到一条链接（A:B:X，也就是 8+8+4 个字节）时，我们就把它跟当前的 12 字节累加器进行异或运算，而如果存储两次，则结果抵消，因此最后如果寄存器非零，我们就可以判断是否出了问题！
Antirez 还预料到了 Gemini 可能提出的异议，并提前做好了回应——尽管 Redis 会默认关闭此功能，但一部分用户确实会需要启用这项额外检查来获得更强的保护，以防攻击者故意创建恶意负载。
Gemini 对这个想法印象深刻，但仍固执地提醒 Antirez：指针也拥有类似的结构、只是改变了几个 bit。所以如果有三条伪链接 L1、L2 和 L3，L1 和 L2 之间的异或运算结果有可能跟 L3 的 bit 相同，这样我们就会遇到漏报的问题（寄存器仍然为零）。Antirez 还想到，分配器往往非常容易预测，而且很可能被外部人士猜到。
Antirez 询问 Gemini 该如何改进这个问题，它还是没什么好主意。后来 Antirez 想，其实可以用一条质量够好且速度够快的哈希函数来做哈希处理，比如 murmur-128 之类（在这项任务中，不需要它具有加密属性），于是向 Gemini 提出了以下方案：
-
获取链接 A:B:X，但使用通过 /dev/urandom 获取的种子作为所有密钥的前缀，这样我们实际上就得到了 S:A:B:X。
-
只需将 murmur-128（S:A:B:X）的输出进行异或运算，放入 128 位寄存器即可。
