作者：卷卷 | 2026-05-05
一句话结论
Redis 之父 Salvatore Sanfilippo 用 GPT 5.x + Codex 辅助开发，花了4个月搞出了一个新 Array 数据类型。他的感受是：AI 没有让他变懒，反而让他敢挑战以前根本不敢碰的复杂度。这篇文章不是软文，是一个顶级工程师的真实 AI 编程实验报告。
先说背景
Redis 在4月底合并了一个新 PR，主角是它的缔造者 antirez，内容是一个全新的 Array 数据类型。
标题很朴素："Redis array: short story of a long development process"，贴在 antirez 的个人博客上，HN 得了23分------在 Redis 相关的帖子里算低的。
但我是认真读完了原文的人。
这篇文章的价值不在分数，在深度。一个写了15年系统软件的老兵，拿 AI 干了4个月，完整记录了过程中的纠结、翻车、重新设计、自我怀疑，最后是怎么把事情做成的。
这种工程师视角的 AI 编程反思，比任何 AI 公司的官方博客都有价值。
4个月都干了什么
整个开发分三个阶段。
第一个月：写规格说明书。
这是整个过程里最反直觉的部分------antirez 用 AI 写规格文档，而不是直接写代码。
他先用 Opus 辅助写了几天，发现 GPT 5.3 发布后就全面切换到了 Codex。整个规格文档涵盖了：新数据类型的动机、C 语言结构体设计、稀疏表示（sparse representation）、ring buffer 游标语义、ARINSERT 的精确行为。
规格文档写了好几天，全部是手敲+AI反馈的迭代。
这里有个很反直觉的点：他强调写初始的规格文档是后续一切工作的关键。
我见过太多人拿到 AI 之后就直接说"帮我写个 Redis 模块"，跳过规格文档阶段。antirez 的经验恰恰相反：规格文档不只是"需求"，更是"思考本身"------当你无法把一件事用精确的语言描述清楚，你其实还没有真正理解这个问题。
第二个月：实现。
有了规格文档打底，他开始用"自动编程"的方式做实现，同时不断 Review 生成的代码。
然后------推倒重来。
他发现自己选的两层间接层设计（directory + slices）不够用。他的目标是：用户执行 ARSET myarray 293842948324 foo 这种操作时，不应该触发巨大的内存分配。原设计满足不了这个需求。
按照以前的做法，他大概会选择妥协------要么接受这个限制，要么花很长时间去绕。但这一次，有了 AI，他选择：直接改设计，往更复杂的架构走。
最终方案是一个"超级目录"结构：多层稀疏目录，每层指向实际的数组切片（默认4096元素一个切片）。
这个方案在没有 AI 的情况下，他自己坦承"不会去干"，因为太复杂、出错概率太高、调试成本太大。
AI 给了他一张安全网。
AI 的两个真实价值：累了有人帮 + 复杂了敢上
antirez 在文章里说了这么一段话，我认为是整篇最精华的部分：
"For high quality system programming tasks you have to still be fully involved, but I ventured to a level of complexity that I would have otherwise skipped. AI provided the safety net for two things: certain massive tasks that are very tiring (like the 32 bit support that was added and tested later), and at the same time the virtual work force required to make sure there are no obvious bugs in complicated algorithms."
翻译过来就是：AI 提供了两种东西------
第一，累活有人干。 比如32位支持这种大量重复性测试工作，以前做一次全量测试要死要活，现在 AI 帮你跑，你只需要看结果。
第二，复杂了敢上。 以前不敢碰的架构复杂度，现在有帮手了。
这是我在各种 AI 编程报道里见过最诚实的一个描述。
不是说 AI 帮你写代码所以你变懒了，而是 AI 扩展了你敢碰的复杂度边界。
中间还顺手优化了一个正则表达式库
做 ARGREP（Redis Array Grep）功能的时候，他需要正则表达式引擎。
选的是 TRE（Ville Laurikari 的作品），原因是：做数据库里的正则，你需要防止灾难性回溯（catastrophic backtracking）导致 Redis 被恶意正则打爆。
然后发现 TRE 在 foo|bar|zap 这种"或"链场景下性能极差。
他的选择：自己动手优化 TRE。
是的，一个 Redis 开发者，为了做 Array 数据类型，顺手优化了一个正则表达式库。期间还修了几个潜在安全问题，扩展了测试用例。
这段经历让我想到一件事：AI 时代真正有价值的工程师，是那种能跟 AI 协作、横跨多个技术领域、把自己的判断力集中在核心问题上的那种人。AI 帮你处理细节，但判断力、判断框架、对系统的整体感知，仍然是人来负责的。
AI 编程的真实限制
antirez 在 HN 评论里也说了很直接的话：
"There are projects that I develop mostly not looking at the code, but owning the concepts, algorithms and ideas asking questions and giving hints, and owning especially the product. But, not for Redis, not yet at least."
翻译：有些项目我可以完全不盯着代码，只管概念、算法、思路和产品。但 Redis 还不行，至少现在还不行。
这就是 AI 编程当前的真实边界：越是基础设施级、越是在万亿级生产环境里跑了十几年的系统，AI 能帮你做的越有限。
你的代码里沉淀着十几年的踩坑记录、边缘 case 处理、团队默契、API 契约。AI 能帮你写新的增量，但在理解存量这件事上，能力还很有限。
反过来想：如果 antirez 是个刚学 C 语言的毕业生，给他 AI 他也写不出 Redis Array------AI 放大了他的能力，但没有创造他的能力。
HN 上的讨论也很真实
HN 上有个评论说："Closely matches my own experiences with current SOTA AI. Extremely useful collaborator, far from being a replacement for human intelligence and creativity."
这句话很中肯。
还有一个评论很有信息量：有人问能不能把 antirez 写的规格文档公开出来。他说会发布，只是现在跟代码已经不同步了，需要更新一版再放出来。
一个完整的规格文档+AI辅助开发的过程记录，这个对社区会很有价值。
结尾：工程文化没有死。只是工具变了。
以前一个 Redis contributor，敢不敢花4个月去设计一个新的核心数据类型，同时还去优化一个正则库？敢，但会犹豫，会担心失败成本。
现在有 AI 之后，这个犹豫少了很多。
规格文档是地基，review 是灵魂，敢碰复杂度是突破。AI，只是帮你把那些你本来就会、但嫌麻烦没干的事情，干了。
工程文化没有死。只是工具变了。