靠人工评审兜底，并非 AI 编程助手的可行解法

围绕大模型编程助手是否真正提升开发效率的争论从未停歇。一篇发布于 Hacker News 的长文从代码评审的实证研究出发，系统质疑了"靠人工 review 兜底"这一主流辩护逻辑，认为它忽视了人类评审者客观存在的认知与时间边界。

LLM 编程助手本质上是"实习生"

文章首先承认大模型在编程上的能力进步，但仍坚持其核心缺陷并未消除：模型会幻觉、会拼写错、会写出与任务无关的代码、会在实现路径上"跑偏"。许多试用过 AI 编程工具的开发者把体验概括为"像带一个实习生"——热情有余，但产出常常需要被推翻重做。

而支持者最常见的回应也直白：你只需要像对待实习生和初级开发那样，亲自 review 它们写的每一行代码即可。在他们看来，代码评审本来就是合并到主干前的标准流程，多审一份 AI 输出并不增加额外负担。

代码评审并非可以无限扩展的资源

问题在于，文章将这种辩护放到代码评审领域的实证文献中检验，得出了与直觉相反的结论。

• 时长上限：经验研究表明，单次评审超过 1 小时，边际收益迅速衰减。这并非单纯因为"已审得足够多"，而是持续高强度注意力会带来疲劳与厌倦，必须休息。
• 数量上限：在保证有效性的前提下，每小时能够审阅的代码量约 400 LOC；超过这个速度的评审在实证数据中几乎无法稳定发现缺陷。

文章也指出，目前几乎没有公开研究回答"两次 1 小时评审之间需要多长恢复时间"，但即便按极端上限估算出"每天数次"，相较于 LLM 可在短时间内吐出的大量代码，供给与需求之间仍存在巨大缺口。

推论：评审无法承担 LLM 代码的把关职责

把上述两条实证边界与支持者的辩护放在一起，文章的结论是：每当 LLM 编程助手写出约 400 行代码（复杂场景下更少），就需要一位专业开发人员投入近 1 小时专注评审。这意味着，要让 AI 编程助手在工程团队中持续运转，组织必须为评审环节额外配置大量人力时间——而这恰恰违背了引入 AI 工具追求效率提升的初衷。

仍未被回答的问题

文章最后坦承，这一批评并不意味着 LLM 编程助手在所有场景下都没有价值，但它确实指出支持者长期回避的一个关键命题：如果评审本身存在硬性上限，那么"用评审来解决 LLM 的不可靠"就不能被视为默认前提，而需要给出具体的、可量化的方案来证明这种把关在工程上是可持续的。截至文章发表，支持者们给出的更多是经验性背书，而非对这一硬性约束的正面回应。