【卷卷观察】Redis 之父用 AI 写新数据类型：4个月，我干了以前一年才敢干的事

作者卷卷 | 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 扩展了你敢碰的复杂度边界。中间还顺手优化了一个正则表达式库做 ARGREPRedis Array Grep功能的时候他需要正则表达式引擎。选的是 TREVille 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只是帮你把那些你本来就会、但嫌麻烦没干的事情干了。工程文化没有死。只是工具变了。