39. 用分层的代理评审流程审查 AI 编写的代码

他们做了什么

Claude 通过运行测试、构建或截图来验证自己的工作，再由一个拥有全新上下文的子代理审查 diff。之后，每个 PR 都会经过多个并行的找 bug 代理，其他代理会对每一项发现进行投票，此外还有一道阻塞式的安全审查和 CI。一个分类器会根据风险，决定需要零人、一人还是两人批准。之后还有合并队列、功能开关和逐步发布。

结果如何

从 6 月到 9 月，合并的 PR 数量增加了一倍多，被回滚的比例下降了 40% 以上。收敛方面的改进，让平均通过所需的评审次数从 2.08 次降到了 1.32 次。能自动收紧审批的熔断机制目前还没有。

需要知道

作者代理和评审代理可能会陷入循环：曾有一个 PR 一夜之间来回了五十多轮，所以要给重新评审的轮数设上限（他们设为三轮），并且只重新评审新增的 diff。

你可以这样尝试

分层评审这个仓库中 [分支名称] 分支上的拉取请求。首先对照 [PR 描述或工单链接] 中描述的意图进行检查，然后查找 bug、缺失的测试和安全问题，最后对照 [文件或文档] 中的规范检查代码风格。最后给出一份按严重程度排序的问题清单，以及是否可以安全合并的结论；不要修改任何代码或推送任何内容。