是时候清理“人类垃圾”了

随着AI模型开始主导代码编写，讨论焦点已转向如何有效利用AI审查当前创建的代码库。如果共识是应将人类检查点前移，那么问题就来了：人类开发者到底应该在哪里工作？

这是一个在团队中常见的痛点：强制性的同行评审往往沦为橡皮图章。一个拉取请求在同行评审渠道中搁置几天，最终另一位对上下文知之甚少的开发者才出现，并说：“赌一把，合并吧。”

Groundcover软件工程师Avital Tamir认为：“我们必须认识到，是时候清理‘人类垃圾’了——即人类比AI更常犯的一类错误。对于这些类型的错误，AI审查者比疲倦的人类可靠得多。”

大多数开发团队仍在经历这种场景，或许是因为人们乐观地认为利大于弊，或许是因为这给软件团队带来了一种标准化的秩序感。Tamir呼吁改变软件团队处理代码审查的方式，他告诉The New Stack，他并非建议完全放弃秩序，而是认为过去二十年来的代码审查方式需要与时俱进。

Tamir说：“关于AI垃圾（如幻觉、误解上下文和自信的错误）有很多讨论，这些都是真实的问题。但我们也必须认识到，是时候清理‘人类垃圾’了。对于这类错误，AI审查者比疲倦的人类可靠得多。”

他描述了一个典型场景：功能完成后，开发者发起拉取请求，然后等待。同事在Slack上被提醒，但第一天无人回应。48小时后，有人评论变量命名问题或提出代码中已回答的问题。开发者修复这些琐碎问题，因为争论比修复更耗时。最终，有人回复“LGTM”（看起来不错）。

Tamir问道：“这完成了什么？本可以周二上线的功能拖到了周五。你的竞争对手周二上线，周三发现真正的bug，周四修复。而你在审查地狱中浪费了两天，优化了推诿责任的可能性，而不是迭代速度。”

他认为，审查时间真正捕捉到的是那些真正有害的bug吗？“真正有害的bug，如竞态条件、数据边界情况或负载下的故障模式，很少被孤立阅读代码的人发现。通常的反馈是风格上的，比如‘使用提前返回’、‘提取函数’等——这些都是好的静态分析应该自动捕获的东西。”

如果将此过程乘以数十名工程师、每周多次拉取审查和多审查员策略，复合成本变得巨大，最终表现为错失的发布特性和学习周期。

Tamir提倡严格的自我审查流程：与AI紧密合作，阅读每次编辑，测试套件，手动端到端验证，打开拉取请求让AI工具运行，迭代，合并，监控。他说：“这个过程比等待48小时获得LGTM更严格。而且，它将责任置于最了解问题的人手中。不舒服的真相是，许多代码审查只是走过场，制造了严格的假象，却没有可靠地交付。”

考虑到这些AI代码审查工具的存在，问题最终可能归结为软件工程团队结构和管理方法的本质。Tamir建议，如果领导层不信任工程师负责任地审查自己的工作，“这是一个招聘问题，而不是流程问题”。他认为，高绩效团队的信任是通过成果建立的，而不是通过审批队列。

团队可以考虑从低风险的内部工具或非面向客户的系统开始尝试这些方法，同时衡量成功指标，保留同步人类协作用于更高风险决策。这样，团队协作才能真正发挥作用，从LGTM转变为“真的看起来很优秀”。