AI 写代码再 AI 审查：程序员仍是深夜故障的唯一责任人

AI 写了代码。AI 审了代码。猜猜谁还在大半夜被呼叫。

我们教会 AI 写代码，它确实在写，而且速度之快让去年的效能图表看起来像加密货币骗局。于是，某个规划会议上自然有人说了下一句显而易见的话：现在是评审成了瓶颈，那也让 AI 来做吧。

新的流水线是这样的。一个模型生成代码，第二个模型审查代码，然后人类收到一份压缩后的审查摘要，决定是否批准。一个机器人在给另一个机器人的作业打分，而你是在报告卡上签字的人。

问题在于，报告卡放进的是你的档案，不是它的。当这段代码在凌晨两点崩溃时，事故群不会呼叫一个模型。它呼叫的是一个人。很可能是你。

所以真正的问题不是 AI 代码审查做得好不好。它已经在路线图上了。问题是一个人类如何在不变成一个人肉批准按钮的前提下，复审机器对机器代码的审查结果。

陷阱：压缩后的审查让人感觉像是确定的

压缩后的 AI 审查之所以危险，原理和电影预告片一样。它给你看爆炸场面，藏起剧情漏洞。它到达时自信满满、格式规范、内容完整，而你的大脑悄悄地把整个 PR 归类为"已检查"。

随后有两种失败模式。第一种，评审者扫一眼摘要，看到"无严重问题"，然后批准。你的审查流程现在只是一种感觉。第二种，评审者什么都不信，从头重读每一行，AI 审查零分钟节省，还多出了一份没人要的文件。大多数团队在两者之间摇摆，然后称之为流程。

还有一个更安静的问题：责任洗白。开发者以为 AI 审查者发现了问题。审查者以为开发者和 AI 都看过了。当 bug 上线时，它是"被所有人审查过"的，却"没有人负责"。球不是戏剧性地掉落。它礼貌地掉落在"AI 检查过了"和"有人检查过了"之间的缝隙里。这两句话不是同一个意思。

不同的机器人来执笔

在我们理清人类之前，先把机器那边的组织架构修好：写代码的模型不应该是审查代码的模型。同一个模型意味着同样的训练、同样的习惯、同样的盲区。要求一个模型审查自己家族的输出，就像让你的双胞胎来审计你的税表。技术上是第二个人。精神上是同一个人。

财务几个世纪前就解决了这个问题，称之为职责分离：写支票的手从不批准支票。把它应用到流水线上。审查用不同的模型家族，理想情况下来自不同的供应商，这样审查者带来的是不同的偏见，而不是同一个偏见戴了单片眼镜。额外好处：两个模型之间的分歧是免费的信号。当写作者和审查者发生争执时，那正是人类首先应该关注的地方。

分工：广度给机器，深度给人类

AI 审查者确实擅长广度。命名、风格、遗漏的空检查、明显的注入模式、第 240 行那个每个人类都会略过的未处理错误。让机器完全拥有这一切。如果你还在检查机器人是否检查了格式，那你是在把一个人类大脑浪费在一个已经解决的问题上。

机器做不到的是上下文。它不知道这个服务每到报税季就会崩溃。它不知道需求本身就是错的。它不知道碰这张表曾经终结过一些人的职业生涯。它审查的是存在的代码。人类审查的是那段代码是否应该存在，以这种形态，在这个系统里，此刻存在。

这种分工让每个人都有真正的工作。以下是每个角色的样子。

开发者的职责：你仍然是作者

写提示词就是创作。"AI 写的"是新的"在我的机器上能跑"，它在事故复盘中会得到完全一样的同情。

在任何其他人之前阅读你自己的 diff。每一行。如果有一行你解释不了，你有两个选择：理解它或者删除它。没有第三个选项让你照样上线。

跑一遍。AI 审查者阅读代码。它不会体验到你预发布环境的脾性。行为需要由一个开着日志的人类来验证。

在 PR 上标注意图。三句话：这次改了什么、为什么改、以及你不确定什么。自己指向有问题的部分。审查者原谅怀疑，不原谅意外。

标注需要人类关注的地方，并且要让它们显眼。你知道你生成时哪些部分是点头附和的，哪些部分碰了有风险的东西。用一个明确的、可搜索的标签在 PR 上标记它们，比如 HUMAN REVIEW REQUIRED，标在权限变更、资金路径、迁移、你无法用一句话解释的代码块上。AI 审查者不知道它不知道什么。你知道。在人类开始滚动之前就引导他们的注意力。

在人类看到之前先整理 AI 审查。修复真正的问题，回复错误的问题并说明理由，不要像打开一个鬼屋日历一样给你的审查者留下 37 条开放的机器人评论。

开发者的产出不再只是代码。它是代码加上一份关于实际检查了什么的签名声明。那份声明才是让人类审查变快而不是变假的东西。

审查者的职责：审查代码，也审查审查

你现在在审查两个产物，第二个会因遗漏而说谎。

不要重做机器的工作。如果你在 AI 审查之后还评论变量名，你是在cosplay 2021。

去模型有盲区的地方。这次变更符合架构吗？它符合真实需求，还是符合提示词想象中的需求？爆炸半径有多大？下游什么会坏？审计员能通过吗？

抽检 AI 审查本身。选两三个它的结论，对照 diff 验证。如果结论成立，给予一些信任。如果有一个是错的，摘要就是虚构的，你应该好好读代码。

把"未发现问题"当作一个提示，而不是一张许可证。干净的报告值得更多怀疑，而不是更少。

对于任何有风险的部分，打开原始 diff 查看。权限、资金流转、数据迁移、删除。摘要是张地图。地图以省略细节著称。

护栏，让球留在空中

把风险分层，并且把层次写下来。低风险的变更比如文档、测试、配置调整可以走 AI 审查加轻微的人类扫一眼。高风险的变更——任何涉及权限、支付或客户数据的——始终需要人类阅读真实代码，无论机器人的摘要多么亮眼。这必须写成政策，因为"使用判断力"在一个月内就会衰变成"点击批准"。

加一条硬规则：任何东西都不能仅凭机器批准就合并。永远不行。AI 审查是人类决策的输入，不是人类决策的替代品。再加一条对应的：任何带有 HUMAN REVIEW REQUIRED 标签未解决的东西都不能合并。开发者请求了人类关注。如果没有人类出现，那个合并不是快，而是一份供状。

然后测量正确的东西。如果审查时间下降了 80%，而逃逸缺陷却在上升，你没有变快。你变松了，还多了步骤和订阅费。追踪什么泄漏到了生产环境，而不是你批准得有多快。

AI 审查是一份简报，不是一份判决。一个机器写，一个不同的机器读一切，然后人类思考机器不能思考的东西。开发者标记自己的风险并为他们的产出负责。审查者审问代码及其机器人监护者双方。没有人外包责任，因为责任是这条流水线上唯一仍然无法被生成的东西。