用人工 review 把关 AI 代码为何不成立
作者引用代码评审实证研究指出，评审存在 1 小时时长和 400 LOC/H 速度上限，难以承担 LLM 编程助手生成代码…
一篇发布在个人博客、被 Hacker News 转载的观点文章提出：在现有软件工程实践中，「靠人工 review 来兜底 LLM 编程助手生成的代码」这一常见辩护并不成立。文章并非否定 LLM 本身，而是从代码评审的实证研究出发，论证人工 review 在容量上无法承接 AI 编程助手的工作量。
「实习生」比喻与随之而来的方案
作者先把 LLM 编程助手类比为「热情但常常犯错、并不真正理解任务的实习生」，承认它们确实会产出错误，包括幻觉、拼写问题、跑偏到无关任务等。业界对此的主流回应是：把它们当作实习生管理即可——也就是说，由开发者逐份审查它们产出的代码，再合入代码库。
作者认为，这种方案默认了团队已经在对每一段进库的代码做完整 review，但事实上，工业界最常见的 review 形态只是「轻量且高度分散」的，目的更多是知识分发和表层规则校验，并不适合作为监督 LLM 输出的标准。
代码评审的两条实证上限
文章引述了软件工程领域关于 code review 的实证研究，提出两条被反复验证的边界：
- 单次评审的有效时长上限约为 1 小时，超过后收益迅速递减，参与者会明显疲劳、注意力下降。
- 评审速度上限约为 400 行/小时（LOC/H），超过这一速度后，缺陷检出率显著降低。
基于这两条数据，作者粗略推算：即便按每天最多几次高强度评审（他估计极端上限是个位数，通常约为 2 次）来安排，一个团队一天也只能完成数千行代码的实质审查。
这一上限与 LLM 输出的碰撞
把上述上限套回 LLM 编程助手，作者写道：每 400 行（复杂代码还会更少）由 LLM 生成的代码，就需要一位专业开发者投入一小时的注意力去评审。在多数团队的工作节奏下，这种审查强度难以长期维持；而一旦 review 速度被压缩、时长被拉长，缺陷漏检概率又会显著上升。换言之，把「人工 review」当作 LLM 编程助手风险的主要缓冲手段，在产能上并不自洽。
文章的立场与边界
需要说明的是，这是一篇个人立场的观点文章，作者自陈并非出于版权、生态或「LLM 都很差」的理由反对 AI 编程工具，而是聚焦于「review 不可行」这一具体论断。文中引用的实证数据多来自已有软件工程文献，但其推论（如每日评审次数的估算）属于作者个人的判断，并非严格实验结论。文章原文在发布时也标注，距今已近一年，期间相关工具能力已发生变化，因此其结论需放在当时的模型与产品背景下理解。