2024年，谷歌内部一个团队算了一笔账：每接受一个AI生成的代码合并请求（merge request），团队平均要多花3.2小时的人工审查时间。这个数字没写在任何产品发布会上，直到今年才被开发者社区挖出来。
AI写代码快，但审代码的人快累死了。
这不是某个小团队的牢骚。谷歌工程生产力团队的研究覆盖了整个公司的代码库，样本量足够大，结论也足够扎心——我们以为AI在帮程序员省时间，实际上只是把成本转移到了另一个人身上。
那个被忽略的3.2小时
谷歌的工程师们最初也没意识到问题。2022年GitHub Copilot刚火起来的时候，团队内部试点 enthusiasm 很高。AI补全代码、生成函数、甚至写单元测试，看起来都在帮开发者提速。
但代码提交后的流程开始暴露裂痕。
审查者发现，AI生成的代码有个特点：表面上能跑，但上下文理解经常缺一块。变量命名看似合理，实际跟项目规范冲突；异常处理写了，但覆盖的场景是AI"想象"出来的；注释生成得很勤快，却跟代码逻辑对不上。
谷歌工程生产力研究员Ciera Jaspan在内部复盘时打了个比方：「AI写的代码像一份简历——格式漂亮，关键词齐全，但你得逐行核实每个项目是不是真的。」
这个核实过程，平均每次多花3.2小时。不是AI写得慢，是人审得更累了。
成本转移的隐蔽性
更麻烦的是，这个成本很难被量化到个人头上。
写代码的人爽了。AI辅助下，他们的提交频率确实上升，产出数字好看。但审查者通常是团队里的资深工程师，他们的时间被切成更碎的块，深度工作被不断打断。
谷歌的研究显示，AI生成代码的审查拒绝率（rejection rate）比人工代码高出17%。不是代码质量更差，而是审查者更不信任它——宁可多花20分钟逐行核对，也不想事后背锅。
这种不信任会传染。团队开始形成潜规则：AI生成的核心模块需要双人审查，或者必须原作者现场讲解。流程越来越重，跟AI工具承诺的"提效"背道而驰。
一位谷歌SRE工程师在内部论坛吐槽：「我们现在花在解释AI代码上的时间，比写代码还长。」
为什么现在才被讨论
这个问题被藏了三年，有几个原因。
第一，指标设计本身就偏袒AI工具。开发者效率看的是"代码产出量"，审查效率很少被单独追踪。3.2小时的额外成本分散在多个审查者身上，没人觉得这是系统性问题。
第二，AI代码的审查疲劳有滞后性。初期大家新鲜，愿意多花时间。半年后模式固化，审查者开始敷衍或推拒，团队摩擦才浮出水面。
第三，也是最现实的——没人想承认自己在用"有问题"的工具。2023年各大公司都在推AI编程，质疑这个等于质疑战略方向。
谷歌的研究实际上2024年初就完成了，但直到今年4月才通过学术渠道公开。作者之一的Emily Morgan在论文附录里写了一句：「希望这些数据能帮助行业重新设计审查流程，而不是简单禁用AI工具。」
其他公司在怎么应对
不是所有团队都在硬扛。
Shopify的做法是强制要求AI代码附带"生成意图说明"——开发者必须简述AI建议的逻辑，审查者据此判断重点核查区域。试运行6个月后，平均审查时间从3.2小时降到1.8小时。
Stripe更激进，直接把AI代码的审查权交给另一套AI。人工只处理系统标记的"高风险变更"，其余自动通过。争议很大，但他们的数据是审查者满意度反而上升——人终于可以从繁琐核对中解脱出来。
国内某头部云厂商的架构师告诉我，他们正在试验"AI代码信用分"：同一开发者的AI生成代码如果被多次打回，系统会自动提高其后续提交的审查门槛。用算法解决算法带来的问题。
这些方案的共同点是：不再假装AI代码和人工代码可以同等对待。
谷歌的研究最狠的结论藏在最后一段：如果团队不主动调整审查流程，AI代码的隐性成本会在18个月内抵消掉所有产出增益。不是AI没用，是用错了场景。
现在回到你团队——你们统计过AI代码的实际审查耗时吗？还是跟2022年的谷歌一样，只看提交频率？
热门跟贴