从 Redis 作者到 Uncle Bob：人工智能时代还该不该读代码？

大家好！

如果 AI 一天生成 5000 行代码，你会怎么做？

坐下来，从第一个函数开始读，读到最后一个括号？还是先看整体的设计、跑测试、观察程序的运行行为，只有遇到可疑的地方才打开具体实现？

Redis 创作者 antirez 最近给出了一个相当激进的答案：很多开发者没有真正发挥自动编程的能力，原因就在于他们还在看代码。

“看代码”正在变成瓶颈？

2026 年 7 月 12 日，antirez 发了一条很容易引发争论的推文：

It is my belief that many devs right now are not maximizing what they can do with automatic programming because they still look at the code. Doing it makes you the bottleneck. Your time is better invested in new ideas, QA, design, and asking yourself what is your goal.

大意是：“亲自做这件事，会让你成为瓶颈。你的时间更应该投入到新想法、质量验证和设计上。”

这条推文的文字记录显示，它获得了超过 2500 个点赞，超过 149 万阅读量。antirez 的意思很明确：如果 AI 已经可以持续生成代码，开发者还把大量时间花在逐行阅读上，自己的时间就会被代码生产速度拖住。

这个观点听起来像是在说， AI 写代码超快，程序员反而是拖慢整体速度里，木桶最短的那一块。

我们花了这么多年学习语法、数据结构、并发、内存和各种框架，最后却有人提出这样的建议：代码最好少看一点？

他真正反对的，可能是“默认逐行审查”

antirez 后来在博客里写了《控制思想，而不是代码》，把这件事完整解释了一遍，有兴趣的读者朋友可以去看看。

首先，他并没有建议大家随便写一句提示词，然后等着 AI 交付一个软件。相反，他认为大语言模型 在“局部实现”上已经很强，真正容易出问题的地方往往在更大的设计上：

• 数据结构是否选对；

• 模块之间的关系是否合理；

• 性能目标是否清楚；

• 边界条件有没有被设计进去等等；

他认为如果这些事情没有想清楚，开发者就算把生成的每一行代码都读完，也可能只是认真检查了一条错误的路线。

打个比方，这就像拿着放大镜检查一座桥的每颗螺丝，却没有先问桥要承受多少重量、建在哪里、遇到洪水怎么办。螺丝当然要检查，可它们不是整座桥的设计。

antirez 认为，开发者更应该维护一份清晰的设计文档（DESIGN.md），用人类语言写明每个数据结构的设计、实现技巧和关键取舍。以后有人要修改有序集合，不必先在几千行代码里游泳，而是先读懂设计，再让智能代理按照这个心智模型工作。

这里的重点不在于“代码不重要”。重点在于：代码应该从主要阅读对象，变成验证设计是否落地的一种证据。

antirez 自己也没有真的完全不看

他在博客里承认，自己仍然会检查人工智能生成的 Redis 代码。他参与了 Redis 数组功能的实现，也在做 序集合的内存优化，提到后者可能带来 50% 的内存节省。

他会修改自己不喜欢的写法，也会寻找细小的设计问题。

那他为什么还要说逐行审查“基本没用了”？

他的解释是：Redis 是很多人依赖的公共软件，用户会直接打开源码、修改源码，所以他继续检查代码，更多是出于对用户负责。如果只考虑自己的效率，他宁愿把审查时间拿去做质量保证、想下一步优化，或者补充设计文档（DESIGN.md）。

也就是说，antirez 的观点并不是“代码永远不用看”，而是“逐行看代码不应该再成为所有项目的默认动作”。

对于一个个人工具、一次性的脚本、风险很低的内部功能，逐行阅读可能确实是在浪费时间。对于 Redis 这种基础设施软件，内存、并发、兼容性和错误处理都可能影响大量用户，自然会更谨慎。

Redis 数组功能的开发过程，也没有那么“放手”

antirez 介绍 Redis 数组功能 开发过程的另一篇文章里，反而能看到大量人工参与。

他先花了一个月写规格文档，明确数据结构、稀疏表示、游标语义和操作方式。之后才和 大语言模型 来回讨论设计，再进入实现阶段。代码完成后，他持续检查、重写模块、做压力测试，确认实现足够可靠。

这和“完全不读代码”之间，隔着很长一段距离。

也许更准确的说法是：人要把时间从“平均分配给每一行代码”，改成“集中在最值得怀疑的地方”。

如果一个模块处理内存分配、锁、权限、支付金额或用户数据，那些关键路径当然值得读。可是一个已经被类型系统、单元测试、集成测试和压力测试反复验证的局部实现，是否还值得人工从头扫到尾？

这个比例该怎么分配，没有一个统一答案。

代码质量，真的只取决于有没有人工看过吗？

很多人反对 antirez，而且反对的人还不少，很多人担心的是软件质量。

这个担心很合理。AI 可以生成一段看起来完整的代码，也可以顺手写一组看起来完整的测试。问题是，测试本身可能漏掉了关键场景，代码和测试还可能共同建立在一个错误的理解上。

但是，“我看过每一行”也不等于“我理解了整个系统”。

反过来，完全不看代码也有问题。你怎么知道设计文档（DESIGN.md）中的设计真的被实现了？如果文档漏掉了一个锁的顺序、一个整数溢出条件，或者一个异常路径，谁来发现？

代码有时候像建筑的施工现场。设计图能告诉你房子想怎么建，但墙里有没有少几根钢筋，总不能永远靠设计图推断吧？

所以，真正影响 AI 代码质量的因素，可能至少包括：

• 模型本身的能力；

• 任务范围是否清晰；

• 代码库是否容易理解；

• 设计文档有没有写到关键取舍；

• 智能代理 有没有足够的工具和上下文；

• 测试、质量保证、监控和回滚是否可靠；

• 这段代码出错后，会不会带来严重后果等等。

在一个干净的小项目里，AI 可能给你一个很好的结果。在一个历史包袱很重、边界条件很多的系统里，同样的模型可能会把问题越改越深，把一切搞砸。

把两种情况用一句“以后不要看代码”按下，显然有点扯淡。

Uncle Bob：用约束代替逐行阅读

这也让我想到 Uncle Bob Martin 最近表达的另一个真实策略。他的做法比“少看代码”更激进：他甚至不读 智能代理 写出的代码，而是把 智能代理 放进一整套极端约束里。

他说:

中文翻译：我六十年代末就开始写代码了。我现在的策略是不阅读智能代理写出的任何代码。只有这样，我才能真正利用它们的生产力。我的做法，是给智能代理套上极其严格的约束：单元测试、场景测试、质量保证流程、质量指标、变异测试、测试覆盖率，以及许多其他检查。最终，我对它们生成的代码有很高的信心，因为这些代码必须闯过我设置的所有约束和测试。

他的答案和 antirez 的判断有一个重要差别：antirez 更强调人应该控制设计、心智模型和关键判断；Uncle Bob 则进一步把“信任”外包给一套必须通过的测试与质量门槛。代码不需要被人平均阅读，但必须在单元测试、场景测试、质量保证流程、质量指标、变异测试和测试覆盖率等约束下闯过一轮又一轮检查。

这补上了“不要逐行看代码”最容易被忽略的另一半：不读代码不等于不控制代码。人的控制权从每一行实现，移动到了约束条件、测试场景和验收标准。

当然，约束本身也不是魔法。如果测试漏掉了关键场景，或者场景描述写错了产品意图，智能代理 依然可能很高效地通过一套错误的考试。所以，开发者仍然要负责设计这些约束，确认它们测的是正确的问题，而不是只看最后的结果。

社区争论，其实很有代表性

这篇文章在 技术社区的讨论里很快分成了几种声音。

有人认同 antirez 的判断，认为开发者真正应该花时间做架构、写规格、设计测试和思考产品方向。代码已经多到读不完，继续坚持逐行检查，只是在维护一种旧的职业习惯。

也有人提出反问：

如果一个人没有通过写代码、读代码和处理 缺陷 建立心智模型，他凭什么只控制“想法”？设计文档（DESIGN.md）也可能写得很漂亮，却遗漏了真实实现中的细节。更年轻的程序员尤其需要通过实际编码，慢慢获得判断设计好坏的经验。

还有一种意见我觉得很值得注意：代码审查本来就不应该等于审查所有代码。很多开发者会选择重点查看公共 接口、关键数据结构、并发逻辑和高风险路径，把其他部分交给测试与自动化工具。

这可能更接近大多数团队现在能落地的方式。

从代码工匠变成系统的掌舵者？

antirez 想推动的，也许是一种工作身份的变化。

过去，程序员像工匠一样亲自加工每个零件。代码是一行一行写出来的，理解系统也常常从阅读这些代码开始。

现在，AI 可以加工大量零件，而且速度极快。打个比方，程序员更像航海船长：决定船往哪里开，规定不能驶入哪些海域，设置仪表盘，安排测试，在风浪里判断是否返航。

但这个比喻也有一个危险的地方。

船长不能因为自己不亲手焊接发动机，就完全不懂发动机。否则仪表盘坏了，船偏离航线时，他可能连问题发生在哪里都不知道。

所以问题远远比我们想象中的复杂，在这个 AI 快速发展的时代，现在留下的定论也许很快就会被推翻，一切变得扑朔迷离，难以捉摸...

也许应该把它当成一个实验

antirez 的话之所以有冲击力，是因为他说得很绝对。

绝对的表达容易传播，也容易让人站队。但真正落到项目里，变量太多了：项目规模、代码质量、模型能力、测试体系、开发者经验、失败成本，都会改变答案。

也许我们现在应该尝试的是：

先写清楚设计，再让 AI 实现；用测试、质量保证、类型系统和运行结果去验证；人工重点检查公共接口、关键路径和高风险的核心逻辑。

至于普通的局部实现，逐行阅读可以从“必做动作”降级为“发现异常时再做”。

这不一定适合每个人，也不一定适合每个项目。

无论如何，这个问题值得我们每一个开发者思考：

当 AI 生成代码的速度已经超过我们阅读代码的速度，开发者还要把一天的时间平均切成两半，一半用来产生新想法，一半用来追赶 人工智能 生成的文本吗？

也许我们真正需要重新设计的，不是代码审查本身，而是“什么值得审查”。

写到这里，我自己也有点迷糊了，让子弹再飞一会吧！