Redis的创始人Salvatore Sanfilippo最近分享了他的一次研发经历，并明确表示了自己的看法：在编程领域，人类程序员的表现依然优于大型模型。“这是因为我们能够突破常规，构思出一些虽不精确却更有效的解决方案，而这对于大型模型来说却是一项艰巨的任务。”
在社区里，大家更倾向于用 Antirez 这个名字来称呼 Sanfilippo。2009年，他开启了 Redis 项目的征程，而到了2020年，他卸下了维护者的重任，转而成为了 Redis Labs 的技术顾问，继续对 Redis 的未来走向给予指导。他的分享立刻引发了众多开发者的热烈讨论。
1 Antirez：AI 水平不错，但远落后人类智能
今日，我将讲述一则关于人类为何相较于大型语言模型仍保持优势的小故事。在此，我要明确一点，我并非对人工智能或类似技术成果持反对态度，这一点关注我频道的朋友们应当清楚。我本人也经常使用大型模型，如今亦是如此。这则故事的由来，主要是我希望借此检验自己的观点、进行代码审查、观察AI是否能在灵感上超越我，以及探索专业领域内更多的可能性。”Antirez 在开篇写道，并直接抛出了结论：
总体而言，我的最终判断是：尽管现今的AI技术相当出色，应用价值显著，然而它与人类智能相比，仍存在较大差距。我明白这样的观点颇具争议，可能在网络上引发非议，然而……我的真实感受便是如此。
接下来，Antirez 讲述了自己的经历。
Antirez近期致力于为Redis打造Vector Sets，旨在解决一个棘手的bug：在他离岗期间，同事们增设了一项机制，用以阻止数据校验虽通过，但RDB和RESTORE加载过程中出现的损坏问题。这项机制默认是关闭的，其主要目的是为有需要的人提供额外的、更为坚固的安全防护。
然而，存在一个较为显著的难题：为了使HNSW能够迅速地保存至Redis RDB格式并重新加载，Antirez选择了序列化graph的表示形式，而不是元素与向量对的组合。若不这么做，便需重新将数据插入HNSW，这将导致速度降低至原来的百分之一。简而言之，Antirez将各个节点及其与其他节点之间的所有连接以整数的形式进行存储，随后再将这些整数解析为指针。
这是一个相当实用的方法，其效果同样显著。不过，当我们将此方法与表示的随机性破坏相结合，并融入Antirez对HNSW的优化，即强制节点之间建立相互链接（Antirez亲自开发了HSNW的版本，其中集成了众多实用功能，但这些功能的实现很大程度上依赖于相互链接）时，可能会遇到以下情况：
加载的数据存在损坏，数据显示A与B之间存在连接，然而B却不再与A相连（节点的标识信息已受损）。
由于存在互换性违规问题，Antirez 及其团队决定不对从节点 A 至节点 B 的连接进行删除操作。
在扫描该图时，若行至节点B，便会遭遇节点A：实施释放与复用……
在数据加载完毕后，Antirez 必须逐一核实每条连接是否实现了互连。通常情况下，这一过程会呈现出 O(N^2) 的复杂度，即对于每一个节点，开发者都必须遍历所有层级，并在每一层级中扫描该节点的所有邻近节点，随后再检查该层级的连接是否也指向了该节点。“这显然是不理想的。”
人类对大模型
Antirez 初步尝试了最常用的方法，试图通过模糊测试器来发现潜在的错误。令人欣喜的是，这种方法确实奏效了。然而，当处理一个包含两千万个向量的庞大向量集时，所需时间从原本的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位存储单元。
最后，我们检查寄存器是否为 0（所有链接均互换）。
Antirez 让 Gemini 进行了这项分析，结果Gemini给出了高度评价，指出这种方法显著减少了随机遇到异或运算结果为0的孤立链接的几率，并且外部攻击者也无法利用这一点进行入侵——因为“S”是未知的，指针的控制也是必要的，而这些偶然因素同时出现的可能性非常低。这项功能仅作为一项额外的安全保障，属于非必需的增值服务，系统默认是不开启的，用户需手动激活。鉴于此，从实际使用角度来考量，它不太可能对系统性能带来显著影响。
Antirez 刚完成整个分析，就坐下来写了文章分享。
我尚不能肯定自己是否将运用这套系统（可能性相当高），然而，事实表明，相较于大型模型，人类的创造力依然占据上风。这是因为我们有能力突破常规，构思出一些虽然不够精确却极具成效的独特解决方案，而这对于大模型而言却是一项艰巨的挑战。Antirez 如是说。
最终，他进一步解释说，即便如此，在整个检验自己想法可行性的过程中，Gemini依旧扮演了至关重要的角色。因此……我或许应当将其视为一位“相当智慧的助手”，在交流探讨中逐步探寻出更为优化的解决方案。
2 开发者：盲目自信的“AI 橡皮鸭”
我的感受与此相吻合。事实上，我认为这款大型模型助手对我而言，其价值主要体现在它仿佛一个具备一定智能的“橡皮鸭”，能够与我进行互动。而这个“鸭子”偶尔还会表达不同意见，甚至有时还能协助我优化思考过程。开发者mattnewton如是说。
编者按：小黄鸭调试，这一调试技巧，是通过口头或书面形式，用自然语言详尽地阐述问题，进而进行代码的调试。此方法得名于《程序员修炼之道》中的一则寓言，讲述一位程序员习惯携带一只小黄鸭，并强迫自己逐字逐句地向鸭子阐述代码，以此达到调试的目的。
也有开发者表示认同，称“我也有过这样的念头”，他们认为在结对编程过程中，若能拥有一个AI橡皮鸭来倾听和分享彼此的想法，将会非常出色（这样一来，你便无需在同事面前显得笨拙，也不会占用他们的宝贵时间）。这位开发者打造了一款集成API密钥的VSCode插件，该插件依托于OpenAI的即时API，并能与虚拟橡皮鸭实现互动式的语音交流。
观察可见，部分开发者已将大型模型视作编程的得力助手，然而，这位助手却时常令人感到烦恼。
这只鸭子极其自负，它的自负程度与其实际能力极不相称。我目睹了很多人在与它交流后，都陷入了迷途。开发者 marcosdumay 如是说道。
有评论者表示赞同，称：“这正是我迅速关闭 JetBrains AI 助手的原因：其多行补全功能极大地扰乱了我的思维流程，尤其是在它给出看似正确实则错误的建议时。为了验证这些建议的正确性而停下分析，几乎完全中断了我的思考。”
开发者指出，对于他们而言，大型模型并非“安慰玩具”，而是“错误答案”。他们让大模型执行一些简单而繁杂的任务，结果却常常出现令人难以置信的错误。这让他们非常生气，以至于宁愿亲自动手解决问题。
开发者强调，高效运用大型模型的核心在于丰富的经验。由于我编写软件的时长颇长，因此当我向大模型提供代码和问题时，我能迅速辨识大模型是否真正理解了问题，抑或被无关的问题所误导。然而，对于初级开发者来说，这无疑是一项挑战，因为大模型输出的代码在表面上往往看起来质量上乘，即便功能存在严重错误，也难以察觉。
我自学了编程，日常编写代码的频率并不高，然而我深刻感受到大型模型对我的巨大助力。这些模型能够提供详尽的解答，对于那些单靠查阅文档或浏览 Stack Overflow 可能需要耗费大量时间才能解决的问题，它们却能迅速给出答案。更有甚者，它们还能自动生成代码片段，我只需对生成的代码进行可行性判断即可。开发者 cogogo 如是说道。然而，cogogo 也提出，“我实在难以设想，若某人自编程学习之初便接触到了大型模型，那么我们该如何对他进行教学。因为借助大模型，人们很容易找到捷径，这可能导致原本学习编程所必需的关键性思维能力和解决难题的技巧被忽视。而这些能力，不仅是编写代码所必需的，更是有效运用大模型的基础。”
3 结束语
Antirez 提到的情形，在两年乃至更长的时间之后，是否依然适用？
去年二月，NVIDIA的掌门人黄仁勋公开表示，伴随着人工智能技术的迅猛推广，编程或许已经不再热门。对于那些渴望投身科技领域的人来说，将学习编程视为首要任务已不再适宜。
今年三月，Anthropic公司首席执行官Dario Amodei也加入了这场讨论，他强调软件工程是AI自动化程度极高的领域：“编程是AI发展速度最快的几个领域之一。据我们预测，不出三到六个月，我们或许将迎来一个AI编写高达90%代码的新时代。而再过 12 个月，AI 可能几乎能写出所有代码。”
微软首席技术官Kevin Scott的预测显示，到了2030年，将有高达95%的编程代码由AI自动生成。但他紧接着强调，这并不代表软件工程领域的工作将被AI全面取代，人类仍旧会参与到代码编写中。然而，这种转变将使得我们不再是编程语言的专家，而是转变为AI指令的引导者。
无论人工智能能否完全编写代码，它正逐步转变为开发者不可或缺的助手，诸如集成开发环境（IDE）、版本管理以及自动化测试等功能，都体现了其在开发过程中的重要性。例如，开发者们普遍使用GitHub Copilot等AI辅助工具，这些工具能够帮助他们定期定位并修复bug，同时优化程序性能。此外，AI还能加速原型设计和测试过程。不同之处在于：工程师不只是使用 AI，还要理解 AI。
目前来看，人工智能尚无法取代程序员的工作岗位，然而它无疑对开发者的工作模式产生了显著影响。AI能够编写代码、执行自动化操作，甚至进行软件调试，然而它在这方面仍不具备人类的创造力、批判性思维以及直觉。
因此，当前阶段，与其探讨“人工智能是否会替代软件工程师”，或许更值得思考的是：“软件工程师在人工智能的影响下将如何进行自我进化？”
参考链接：
https://antirez.com/news/153
Anthropic公司首席执行官Dario Amodei预测，在六个月内，人工智能将完成90%的代码编写工作。
在Techpoint Africa的指南中，探讨了人工智能是否会取代软件工程师的问题。
本文源自微信公众号“InfoQ”，由褚杏娟和核子可乐整理，并已获得36氪的授权进行发布。
