antirez 这次做 Redis Array，最有意思的地方不是“用了 AI 写 C”。

更反常的是：用了 AI 之后，他没有把设计压简单，反而走向了更复杂的稀疏数组结构。

这件事从 1 月开始。先写规格文档，再和 Opus 协作打磨设计，后面按他的说法转向 GPT 5.x / Codex 辅助系统编程。最近 PR 进入 Redis 仓库，前后大约四个月。

先说清楚边界：这不是 Redis 已经正式发布 Array。它目前是一个 PR，作者希望被接受。也不是 AI 独立完成系统编程。作者明确说自己深度参与，并逐行审查 sparsearray.c 和 t_array.c。

Array 到底是什么，卡在哪里

Array 是 Redis 的新数据类型提案。它让数字索引成为语义的一部分，可以用 ARSET、ARSCAN、ARPOP 等命令操作。

最关键的问题只有一个：怎么支持超大索引，又不把内存打爆。

比如 ARSET myarray 293842948324 foo。如果按普通连续数组理解，这个索引会逼出巨量分配。Redis 不能这么干。

所以 antirez 走了稀疏数组路线。最初是 directory + slice 两层结构，后来变成更复杂的 super directory + directory + slice。默认每个 slice 4096 个元素。

问题取舍结果
超大索引写入不做连续巨量分配支持稀疏位置存值
两层结构不够引入 super directory + directory + slice结构更复杂，但索引空间更可控
扫描成本按实际存在元素扫描ARSCAN、ARPOP 不必按巨大跨度硬扫
文本检索需求增加 ARGREP，并使用 TRE 正则库让数组里的文本场景更顺手

ARGREP 是中途长出来的能力。原因不玄：作者把 markdown 文件放进 Redis arrays，发现文件很适合这种结构，于是加了 grep 能力。

正则库选了 TRE。这里的约束很现实：Redis 里跑正则，不能被病态模式拖垮时间和空间。作者还提到，在 GPT 帮助下优化了 TRE 对 foo|bar|zap 这类模式的效率，并补了测试、修了潜在安全问题。

这部分对普通 Redis 使用者的影响，短期不用想太多。还没合入，也没发布，谈迁移太早。

真正该看的是 Redis 内核开发者和后端工程师：如果这个 PR 后续被接受，Array 会增加一种新的建模方式。它可能适合稀疏索引、按位置追加/弹出、文本片段存储和检索这类场景。但 API 是否稳定、内存行为是否足够好、真实负载下是否划算，目前都还要等评审和使用反馈。

AI 参与了什么，也没参与什么

这次 AI 不是只帮忙补几行代码。它参与了规格反馈、设计讨论、编码、测试、重构，还包括 32 位支持这类不太性感但很耗人的工作。

但分工不能说反。

环节AI 的角色人的角色
规格设计提供反馈、帮忙推演定方向、定边界
数据结构协助讨论复杂实现判断取舍是否值得
编码与重构生成、修改、整理代码逐行审查关键文件
测试与兼容补测试、查边界、处理繁琐项判断覆盖是否有效
安全与性能帮助发现和优化局部问题对风险负责

我更在意的是 antirez 的一句判断：没有 AI，他也许四个月也能做出实现；有了 AI，同样时间能做更多。

这比“效率提升多少倍”可信得多。

系统编程的难，常常不在第一版。难在后面的脏活：规格反复推敲、边界条件验证、测试扩展、低效路径重写、32 位兼容、复杂算法里找明显 bug。

这些活不酷，但每一项都要命。

AI 在这里提供的不是魔法，而是安全网和虚拟劳动力。它把一部分疲劳工作提前吃掉，让人有余力继续往复杂方案里走。

这也解释了为什么他敢把结构从两层改成三层。没有 AI，很多工程师会做一个“够用”的版本：两层目录能跑，边界以后再说。不是不会做，是不值得。时间、体力、风险预算，会把设计野心压下去。

“天下熙熙，皆为利来。”工程里的“利”不只是钱，也是注意力和风险预算。AI 改的正是这张预算表。

过去很多好设计死在一个朴素原因：太麻烦。理论上可行，工程上没人愿意为测试、重构、边角和兼容性付账。现在账单没有消失，只是 AI 先垫了一部分。

受影响的人该怎么判断

这件事最该触动两类人。

一类是后端和数据库工程师。短期动作很简单：不要因为一个 PR 就改架构，也不要急着把现有 Redis 建模推倒重来。更合理的做法，是先把 Array 当成一个待评审的新数据结构看：关注命令语义、内存模型、扫描复杂度、正则能力和失败边界。

另一类是关注 AI 编程边界的工程师。这里的动作更直接：别只测试“AI 能不能写一个 demo”。要测试它能不能帮你写规格、补测试、做重构、查兼容、解释复杂 C 代码里的边界。

如果团队正在引入 AI 编程工具，我会把这个案例读成一个提醒：采购和试点不该只盯生成速度。更该看代码审查能力有没有跟上。审查能力没跟上，生成越多，债越厚。

这也是这件事的现实约束。

AI 让复杂方案变得可承担，不等于复杂方案自动变好。系统软件里最危险的用法，是把“能跑”误读成“可靠”。antirez 的做法有参考价值，正因为他没有把模型当作者，而是当一批能干、但必须被审的初级劳动力。

门槛没有下降。它换了位置。

你得会写规格，能判断结构取舍，能看懂 C 里的内存和边界，能知道测试覆盖哪里是假安全。否则模型看着更强，产品反而更虚。

接下来真正要看的，不是某个模型名字。

看三件事就够了：PR 是否被接受；API 和内部结构会不会在评审中大改；真实用户是否能把 Array 用在比现有 List、Hash、Sorted Set 更合适的场景里。

如果这三件事走通，Redis Array 才不只是一次有趣实验。它会成为一个更清楚的信号：AI 编程最先放大的，不是普通人的“凭空造系统”，而是高手的执行半径。

这很像早期电力进工厂。不完全一样，但有一处相似：电机没有替代工程师，它让生产线可以重新设计。真正受益的人，不是只会按开关的人，而是知道电机该接到哪里的人。

回到开头。Redis Array 最值得看的不是新命令，也不是模型名单。它展示的是一条更冷的变化：AI 没把系统程序员赶下船，但它开始给船加桨。前提是，掌舵的人还看得懂水流。