我说过程序员要转向审代码，四个月后 Redis 之父说：逐行审 AI 代码基本没用

封面：控制思想而不是逐行审 AI 代码

三月我发过一篇《从写代码到审代码》。里面有个我当时很得意的切片：AI 两分钟生成 200 行，我花 40 分钟逐条推边界、修错误。我把那 40 分钟当作新职责的证明——写的价值在贬值，审的价值在上涨。

上周我读到 antirez 的新博客，标题几乎是冲着那篇文章来的：Control the ideas, not the code。这位 Redis 之父说得很直接：逐行 review AI 代码，他自己还在做，但这件事“基本上没用”。

我第一反应是不服。再读一遍，我发现他给的不是一组足以定案的数据，而是一笔我没认真算过的机会成本。

他不是在唱高调

antirez 最近在做 DwarfStar，一个本地 LLM 推理的开源项目。DeepSeek v4 和 GLM 5.2 的推理实现，他用 AI 全自动写完。

这不是“一句话让 AI 实现 XYZ”的 vibe coding。他强调你仍然得懂原理、懂设计、懂性能该怎么压，区别在于力气花在这些上面，而不是花在读生成出来的每一行。

结果比他预想的更难看。他拿这份 AI 写的实现和其他系统比对正确性，发现别人手写的实现反而错误更多。再往下挖，本地推理生态里到处是累积起来的微妙错误：比如 indexed attention 的实现是坏的，做了多余的工作，上下文一超过某个长度，性能就开始滑坡。

这些错误，都长在人逐行写过、逐行看过的代码里。逐行看，没有拦住它们。

他还在逐行审，但把实话说了

Matteo Collina 当面问过他：你不是说 Redis 的 AI 代码你全都要检查吗？

他承认，是的，还在查。Redis sorted sets 那个省 50% 内存的优化 PR，他照样逐行过，改掉不合口味的写法。但他明说：这件事从 GPT 5.5 开始就越来越没意义，到了 Fable 和 GPT 5.6，基本上没用。他继续做，是出于对用户的尊重——太多人会亲手打开 Redis 的文件改代码。

真正让我停下来的是这句：他判断 Fable 和 GPT 5.6 对那个 PR 的 review，会比他本人抓到更多错误和隐蔽竞态条件。

这不是 benchmark，只是 antirez 对自己工作流的判断，不能直接推出所有人都该停止看代码。但它逼出一个更难躲的问题：如果独立的模型 review 和可执行验证已经覆盖了大部分缺陷，我花 40 分钟逐行扫 diff，究竟新增了什么信号？

逐行审查只有在能新增判断时才是质量保障；说不出新增了什么，它就只剩仪式。

逐行审查与新增判断的机会成本

他算过账：一天八小时，读代码是有机会成本的。省下来的时间他想投三处：做更多 QA；想下一个优化点子；用 LLM 给每个数据结构写一份 DESIGN.md，用人类语言描述它承载的想法、取舍和实现技巧。未来想改 sorted sets 的人，读设计、own 想法，然后带着正确的心智模型去指挥 agent。

Own ideas，而不是 own code。他提醒说，这个提法来自七十年代的《人月神话》。

我退到哪一层

三月那篇文章里，我其实已经写了“不逐行当人肉 linter，用 lint 和测试挡低级错误”。但我把“审代码”当成了人的新核心能力，当成了终点。antirez 把它往前又推了一格：审代码也是过渡形态，人的控制点要上移到想法。

这一格我认。回想逐行 review 里我真正创造价值的时刻，很少是“这行有 bug”，更多是“这个模块不该这么切”“这个边界条件设计里就没考虑”。前者机器越来越擅长，后者本来就发生在代码之前。

但这也是最难跨的一格。

antirez 敢只控制想法，是因为 sorted sets 的每一个字节怎么排，他脑子里本来就有一份。他的”想法”能落到数据结构、约束和取舍上，不是一句”帮我做个又快又省内存的东西”。多数时候我们说”控制想法”，给出的其实是愿望，不是约束。从愿望到约束之间的距离，就是你还需要在代码层面保留多少判断力。

先有一份配得上被控制的想法，才轮得到只控制想法。

你可以试一下他说的 DESIGN.md：挑一个自己负责的模块，不看代码，用人类语言把它的数据结构、关键取舍、失败时的行为写清楚。写不出来，说明逐行审查时你其实也只是在看表面——你判断不了自己不理解的东西。这句话是我三月写的，现在依然成立，只是它指向的结论变了。

在生成代码前审结构、取舍和失败行为