给代码审查者记功，解决AI垃圾代码问题
我最近在审查一个PR（Pull Request，代码合并请求）时，碰到了一个bug，你看看能不能发现：
# 分支C没有打印机
user = new Person(...)
... user 做了一些操作 ...
if user not in branch_c:
user.print_document()
... 50行库逻辑 ...
### PR中新增的代码：
+ staff = new Person(...)
... staff 做了一些操作 ...
- staff.print_document() 显然我不是在图书馆工作——我把真实的调用替换掉了。但事情就是这么简单。# Branch C doesn’t have a printer 这行注释也不是为了提供上下文才加的，它就在代码里。我们做的任何测试都会通过，但一旦部署到分支 C，就会开始出现故障。也许更好的代码库不会让这种错误发生。但嘿，别怪我——生产代码库很少是完美的，就我见过的而言，这个还不算太差。不过，老老实实地盲目复制粘贴本可以避免这个问题。往上翻一翻也应该能避免。然而，AI 编写了它，AI 模型审查了它，人类审查者把它粘贴到 AI 里审查，然后盖了章。我被标记为第二个（人类）审查者。这次我碰巧读了代码，但我承认——大多数时候，我只会把 PR 粘贴到 AI 里，然后错过同样明显的 bug。
审查者的意义何在？说真的？
我一直被教导，审查者和作者一样对代码负责。我也总是会检查一堆东西：它能工作吗，它合适吗，一年后有人能看懂吗。但有一件事我以前从不需要检查——作者自己到底有没有读过。这本来是理所当然的。你不可能在没按 ctrl+f 找到 staff.print_document() 用法示例的情况下就把它敲出来。然而今天，人们可以发布他们从未见过的代码。审查者完全有可能是第一个真正阅读代码的人。我看到的那个 bug 不需要任何专业知识就能发现。AI 居然漏掉了它，老实说让我挺震惊的。但与此同时，让一圈 AI 用几乎相同的提示词读同一段代码，常常跑的是同一个模型¹，还指望能发现不同的东西，这毫无道理。我们把第二遍（第三遍、第四遍）AI 审查误当成了人类审查，仅仅因为是人把 PR 复制粘贴到了他们最喜欢的 AI 工具里。到什么时候你该干脆把人从流程里去掉，给大家省点时间？
抛弃人类？
过去一年里，我跟好几家公司的团队聊过，不止一个团队已经完全取消了人工评审。有的团队会让 AI 自己判断——这次改动风险够不够大，值不值得让人来看？就我个人来说，绝大多数工作我还是愿意保留人工评审。也许是我落伍了。不管怎样，这篇不是来讨论你想要多少人工参与的。重点是：一旦你定下了这个比例——不管是 0%、100%，还是中间的某个值——那就该有意识地把这个方向贯彻下去。如今我们很多人卡在一种不上不下的尴尬地带：人工评审的旧要求还留着，可这个人不过是又一轮 AI 评审的代理人罢了。
那干脆把 AI 砍掉？乍看之下，一个诱人的办法是禁止用 AI 做评审，除非评审者自己先完整读一遍。但你管不了别人在自己终端里干什么，就算管得了，这多半也没碰到真正的根因。没有比审一个 PR 或文档更让人火大的事了——你心里清楚，自己读它要花的时间，比作者写它还多。他花五分钟给 AI 写提示词，你却要花一小时来审。到底从什么时候起，变成你在替别人做功能了？而你花在审代码上的这些钟头——从来不算你的功劳。
把 PR 贴进 AI，不是偷懒。如果你看重自己的时间，这是最合理的选择。以我的经验，真想钻空子的人很少。大多数人都想做诚实、踏实的工作，并因此被认可。他们只是不想干那种看不见、也不算功劳的苦活。
把它摆到看板上
这个问题困扰了我好几周，不过我现在觉得答案其实很简单：把评审作为子任务加到你的冲刺看板上。放在 AI 之前，管理这点额外开销会很烦人。而现在 AI 能替你做了——把它接进 PR 流水线，让它自动创建工单。我知道，我知道，冲刺进行到一半再加任务是不好的实践。但去它的吧，时代变了。
除非你想让交付变慢，而没人希望这样，那你只能把这些任务塞进当前迭代。一张评审工单能起两个作用。第一，它逼着你去做估算。当然，这活儿大概就值 1 个点，但花 30 秒估一下本身就是一个信号：这是我们真正在意的事。第二，它让成本变得可见。一个 3 点的功能，引出一个 3 点的评审，这部分投入终于能和功能开发本身并排摆出来了。而且有史以来第一次，评审者不会再因为认真把关而吃亏。
你可能会说，把评审加进迭代看板算什么解决方案？大家照样能用 AI 省时间。答案是，这是一套组合拳。给评审者记功，是在为团队文化打地基：愿意花时间做评审、尽早发现问题的人会得到回报。把评审放进迭代看板，则相当于多砌一道墙，文化想滑向 AI 垃圾内容，就得先把这堵墙拆掉。所以，认真评审 PR 的人值得被认可，下次有人点下 approve 时，它才真正有分量。
感谢阅读。如果你觉得有意思，欢迎订阅，我还会继续写这类内容。
1 就算换用不同的模型，可能也没多大用——2025 年的一项研究发现，当两个不同的模型答错同一个问题时，有 60% 的概率会错成同一个答案。
代码审查不是免费劳动力，别再把它当成理所当然。