「审查 AI 代码」不是一个站得住脚的论证

2026年7月19日

AI编程代码审查开发者工具

数据源：Lobsters · HN

2026 年 7 月 18 日，一篇题为《Reviewing AI Code Is Not A Viable Argument》的文章在 Lobsters 上获得了 31 分和 66 条评论——对于一个技术社区而言，这个互动率意味着话题触及了开发者群体的敏感神经。作者 Thomas Depierre 提出了一个尖锐的质疑：当 AI 编程工具的支持者说「你只需要审查 AI 生成的代码就行了」时，他们可能没有认真想过「审查」这件事本身的能力边界在哪里。

核心论证：审查不是免费的

Depierre 的出发点并不复杂。他把 AI 编程助手比作实习生——热情、高产、但经常犯错。面对「AI 代码质量不行」的批评，支持者的标准回应是：你审查一下不就好了？就像你审查人类同事的代码一样。

问题在于，代码审查并不是一个可以无限扩展的能力。Depierre 引用了软件工程领域积累的实证研究，指出两个关键约束：

单次审查的有效时长不超过 1 小时。超过 1 小时后，审查者的注意力会显著下降，缺陷发现率急剧衰减——这与被审查的代码量无关，纯粹是人类的认知耐力问题。
有效审查速度的上限大约是每小时 400 行代码（LOC/H）。超过这个速度的审查，在实证数据中几乎找不到有效发现缺陷的案例。

这两个数字放在一起，形成了一个冷冰冰的计算：每 400 行 AI 生成的代码，需要一个高级开发者投入 1 小时的专注审查时间。而一个开发者在理想情况下，每天可能只能进行 2 到 4 次这样的审查会话——中间还需要未知长度的恢复时间。

按照这个模型，一个使用 AI 编程助手的开发者，在最理想的场景下每天也只能产出数千行经过充分审查的代码。现实场景中，Depierre 估计这个数字可能不到 1000 行。考虑到这 1000 行里包含了样板代码、测试、配置和迁移脚本，真正的功能代码产出可能并不多。

更糟糕的消息

如果只是「审查有成本但 AI 写得快」，至少还有一个净收益的讨论空间。但 Depierre 指出了一个更棘手的问题：初步证据表明，人类在审查 AI 生成的代码时，信心更高但发现的缺陷更少。

换句话说，AI 生成的代码可能更容易让审查者产生「我已经看懂了」的错觉，而实际上遗漏了更多问题。如果这个发现被更多研究复现，那么「审查 AI 代码」不仅有时间成本，还可能是效果更差的审查方式。

Depierre 还指出了一个颇具讽刺意味的现象：AI 编程工具的支持者经常把「最难写的代码」作为 AI 的最佳用例——比如 Shell 脚本、正则表达式、配置解析器。但这类代码恰恰也是最难审查的代码。让一个经常出错的工具去写最不容易发现错误的代码，然后指望人工审查来兜底——这个逻辑链条的每个环节似乎都在相互削弱。

社区反驳：模型在进化，审查可以被重新设计

Lobsters 上的讨论展示了与此不同的视角。获得最高票（39 分）的评论来自用户 sunshowers，他指出速度不需要是唯一的目标。AI 工具让「做对的事情」的边际成本大幅降低——可以把一个 bugfix 拆成独立的预备提交来单独审查，可以花时间重构不满意的类型结构，可以尝试更高级的测试技术。这些带来的都是质量的提升，而非单纯的速度变化。

simonw（17 分）的观点更直接：用 AI 编程工具来构建更高质量的软件，而非走捷径制造更快的劣质代码，是公司需要做出的选择。问题的根源在使用工具的方式，工具本身是中性的。

多位评论者质疑了 Depierre 引用的实证研究的适用性。有人指出软件工程领域的学术研究本身就有严重的方法论问题——以 10 个本科生在工具上使用 1 小时的经验来推断大型公司资深工程师的实践，这种外推本身就站不住脚。还有人提出，如果要用「没有经过同行评审的研究就不能采纳」的标准来审视 AI 编程工具，那么 Git、Rust、CI/CD 和几乎所有现代软件工程实践同样缺乏满足这个标准的证据。

一个被忽视的维度：文章已写了一年

Depierre 在文章开头注明了这篇文字写于近一年前——这本身就是一条重要信息。多位评论者指出，过去六个月（尤其是过去三个月），前沿模型的代码生成能力有了显著提升。用一年前的模型表现来评估今天的工具能力，可能存在时间错位。

一位评论者甚至让 ChatGPT 生成了对原文的逐条反驳，其中提出了一个关键洞见：「审查 AI 代码不是一个站得住脚的论证」这个结论本身，来源于将最愚蠢的工作流程当作技术本质来批评。具体来说：

让一个无约束的 agent 产出巨大变更，粗略浏览 diff，信任它自己写的测试，然后合并——这确实是糟糕的做法。
但这并不能推论出「审查 AI 代码不可行」。真正的工程实践会把审查提前、分解、自动化：用机器检查机器能检查的部分（类型安全、格式、已知漏洞模式），把人的判断力集中在架构、安全边界和业务逻辑的正确性上，约束 agent 可以触碰的范围，在劣质工作变成审查负担之前就丢弃它。

审查瓶颈是真实存在的。工程学的核心恰恰是围绕真实瓶颈设计系统——而不是因为最愚蠢的工作流程行不通，就宣布整个工具类别不可能有效。

从社区讨论判断

这场辩论的深层分歧不在于「AI 代码是否需要审查」——双方都同意需要。真正的分歧在于两点：

第一，审查的目标是什么。Depierre 把审查等同于「逐行查找缺陷」，基于实证研究得出了吞吐量的硬上限。但社区中的实践者指出，AI 辅助编程的价值可能在于把稀缺的审查精力重新分配到更值得关注的维度上——架构、可维护性、安全边界，而不仅仅是「更快地写出经过同样严格审查的代码」。

第二，证据标准应该设在哪里。Depierre 要求支持者用同行评审的实证研究来证明 AI 工具的有效性。而社区中很多人认为这个标准不切实际——它不仅高于软件工程行业对其他工具的要求，而且学术界的产出速度远跟不上工具的迭代速度。等到足够扎实的研究出现时，被研究的工具可能已经迭代了好几代。

从目前的公开讨论来看，一个比较平衡的判断是：「审查 AI 代码就行」作为一个不加限定的万能回答，确实不够——它低估了有效审查的认知成本和容量限制。但这不意味着 AI 编程工具因此失去了价值。更可能的情况是，在审查流程和工具本身共同进化的过程中，开发者的角色会从「写代码 + 审查代码」转向「设计约束 + 验证关键路径」，而审查这件事本身也会被重新定义为一场人机协作的验证活动，而非单纯的人力兜底。