规模化编排 AI 代码审查

2026-04-20

This post is also available in 简体中文, 日本語, 한국어 and 繁體中文.

Code review is a fantastic mechanism for catching bugs and sharing knowledge, but it is also one of the most reliable ways to bottleneck an engineering team. A merge request sits in a queue, a reviewer eventually context-switches to read the diff, they leave a handful of nitpicks about variable naming, the author responds, and the cycle repeats. Across our internal projects, the median wait time for a first review was often measured in hours.

代码审查是捕获 bug 和分享知识的绝佳机制，但它也是导致工程团队陷入瓶颈的最常见方式之一。一个合并请求在队列中等待，审查者最终切换上下文来阅读 diff，留下一些关于变量命名的琐碎修改意见，作者进行回复，然后循环再次开始。在我们的内部项目中，首次审查的中位等待时间通常以小时来计算。

When we first started experimenting with AI code review, we took the path that most other people probably take: we tried out a few different AI code review tools and found that a lot of these tools worked pretty well, and a lot of them even offered a good amount of customisation and configurability! Unfortunately, though, the one recurring theme that kept coming up was that they just didn’t offer enough flexibility and customisation for an organisation the size of Cloudflare.

当我们最初开始尝试 AI 代码审查时，我们走了大多数人可能会走的路线：我们尝试了几种不同的 AI 代码审查工具，发现其中许多工具效果相当不错，而且很多甚至提供了大量的定制和配置选项！然而遗憾的是，不断出现的一个共同点是，对于 Cloudflare 这样规模的组织来说，它们就是无法提供足够的灵活性和定制能力。

So, we jumped to the next most obvious path, which was to grab a git diff, shove it into a half-baked prompt, and ask a large language model to find bugs. The results were exactly as noisy as you might expect, with a flood of vague suggestions, hallucinated syntax errors, and helpful advice to "consider adding error handling" on functions that already had it. We realised pretty quickly that a naive summarisation approach wasn't going to give us the results we wanted, especially on complex codebases.

因此，我们转向了下一个最显而易见的路径，即获取 git diff，将其塞入一个未经完善的 prompt 中，然后要求大语言模型查找 bug。结果正如你所料，充满了噪音，涌现出大量模糊的建议、幻觉产生的语法错误，以及对已经具备错误处理的函数提出"考虑添加错误处理"的"贴心"建议。我们很快意识到，这种朴素的总结方法无法带来我们想要的结果，尤其是在复杂的代码库中。

Instead of building a monolithic ...