跨国深谈← 返回←Uber 用 AI 给 AI 评审代码:每周 2.5 万条评论是这样炼成的

Uber 用 AI 给 AI 评审代码:每周 2.5 万条评论是这样炼成的

关联

人物 Will Bond · Ameya Ketkar

公司 Uber

概念 uReview · 自动化代码评审 · 代码审查 · 智能体化的 SDLC · 智能体 · 可观测性 · 护栏 · 内环与外环

工程师提交代码后要等 9 个小时才能收到第一条评审——这不是几年前的 Uber,而是 2026 年的 Uber。随着 AI 生成代码暴增，PR 数量和体积都在膨胀，「首次评审时间」这一指标从 2024 年的 3 小时涨到了 9 小时。

代码评审成了整个研发流程的瓶颈。这一集，Uber 工程师 Will 和 Amaya 带来了他们的解法：uReview,一个内部自建的自动化代码评审系统 。

为什么自建,不买现成的?

Uber 的约束条件决定了他们只能自己做:第一,Uber 长期使用代码托管工具 Fabricator,正在向 GitHub 迁移,而市面上的方案基本都不支持 Fabricator;第二,Uber 正在推进「智能体化的 SDLC」(让 AI 智能体参与软件开发生命周期的各个环节),他们要让智能体提交的代码和人类代码走完全相同的评审规则;第三,公司有数百个团队,评审规则和知识不能集中管理,必须接入现有的团队所有权体系分散出去;第四,评审量太大,必须能按风险画像和变更复杂度区别对待——不是所有代码都配得到同样的评审;最后是可靠性,安全和合规评审必须在所有代码上强制运行,不能指望每个团队自觉开启 。

系统长什么样

架构分三层:GitHub、Fabricator 和智能体循环作为入口,汇入 uReview 服务,由它接收评审请求、收集用户反馈并进行路由;下面挂着一组针对不同性能与成本调优的生成器,还能接入第三方评审系统做横向对比;最后是后处理——多路生成器会产出大量重复、低质的评论,系统对评论做评分、分类、过滤、去重,只把置信度最高、可操作的评论送到工程师面前 。

可观测性:模型不知道自己是错的

uReview 起点非常简陋:一个「按文件做逻辑检查」的提示词加一个智能体。早期只收集成本和 NPS 问卷,质量成本比「一团糟」。转折点是开始系统性地收集数据 :

• 情绪分析:把开发者对 uReview 评论的回复分为正面/负面并归类,从中发现了一大堆可以修的 bug 和问题;
• 处理率:一条评论发出后,开发者是否真的去改了;
• 运行时画像:追踪智能体的完整轨迹——它调用了哪些工具、经历了怎样的思考过程——据此调优运行时,让智能体快速、低成本地产出高质量结果 。

这中间最大的体会,用 Amaya 的话说:「模型不知道自己是错的」——它总是自信满满地给出评审,但实际上非常需要每个团队注入自己的风格指南和反模式清单,这些必须内置到智能体里;同时要给智能体设护栏,告诉它别把轮次浪费在不该做的事上,否则评审质量会很差 。

团队定制:写技能容易,规模化跑起来难

uReview 的评审栈分四层:单文件评审器(通用逻辑 bug 检查)、多文件深度评审器(六个按语言划分的 monorepo 各自内置反模式和风格指南)、AI linter(一种少样本提示系统,开发者提供上下文后按规则确定性地找出机械性问题)、以及最强大的自定义智能体——团队可以定义自己的评审智能体,链接知识库和历史 PR,赋予它评审技能 。

定制的落地靠三件事:把定制配置放在开发者写代码的地方旁边,方便随时更新;实现智能的确定性路由,决定哪个团队用哪种评审、哪个模型;把可观测性数据(轨迹、处理率、情绪分析)反馈给团队,让他们看到「我写的这条规则没人喜欢,该改了」 。

一个反直觉的发现:写技能本身非常容易——团队让 Claude「翻遍我过去的 PR 评审,给我写一个技能」,几分钟就写出来了。难的是以一致的质量、低成本大规模运行这些技能,平台方和每个团队都要反复迭代 。

成绩单

每周约 25,000 条评论,其中 10% 得到开发者反馈,只有 4% 的 PR 收到负面反馈;整体处理率约 67%,近四分之三的高严重性问题被开发者真正处理。相比朴素的实现,成本下降 60%,质量和准确率提升约 70% 。

内环与外环:不是杀死人类评审,而是上移一层

随着智能体化 SDLC 推进,工程师越来越不亲自写代码,人类评审员的角色要重新设计,而且内环(智能体)和外环(人类)的需求不一样:内环需要更高的准确率,否则智能体会陷入空转——修一个问题、又收到一条低质量评论、再反向修一遍;而且智能体非常乐意把一个 PR 里的 100 个小瑕疵全修掉,人类工程师遇到这种事会非常沮丧 。

最要命的是反馈问题:uReview 的高质量很大程度靠人类反馈调优提示词和智能体,如果人类彻底退出评审循环,「让想象力去发挥吧——质量退化、垃圾内容等等」。所以 Uber 的答案不是杀死外环,而是扩展外环:把人类的职责上移一层。智能体擅长写软件,也越来越擅长像人一样评审软件;人类工程师不再操心性能优化和 API 兼容性,而是在评审中更多思考架构、贡献领域专长和产品思维 。

本集带走

• 代码评审已成新瓶颈:AI 让 PR 暴涨,Uber 的首次评审时间从 3 小时涨到 9 小时——如果你的团队也上了 AI 编程,先盯这个指标。
• 别信模型的自评:它不知道自己是错的。要靠情绪分析、处理率、智能体轨迹这些真实数据来定位质量问题,再针对性调优。
• 给智能体设护栏:告诉它别浪费轮次,把团队风格指南和反模式清单内置进评审智能体。
• 定制分散、安全集中:团队自定义评审规则和智能体,但安全合规评审由平台强制在所有代码上运行。
• 评论后处理不可省:评分、分类、过滤、去重,只给工程师高置信度、可操作的评论——低质评论淹没工程师比没有评审更糟。
• 人类评审上移一层:让智能体修小瑕疵,人专注架构、领域专长和产品思维——这是扩展外环,不是取消人类。

简而言之,代码评审现在成了我们遭遇的瓶颈。
So in short, code review is now the bottleneck that we are running into.
—— Will Bond · [01:16]

在这个过程中最大的一个体会是,模型不知道自己是错的。
One of the biggest learnings in this process was the model doesn’t know that it’s wrong.
—— Ameya Ketkar · [06:35]

然后,通过我经历的所有可观测性和评估,我们发现,和一个非常朴素的实现相比,我们的成本下降了 60%,我们的质量和准确率提升了大约 70%。
And then with all the observability and evals that I went through, we saw that against like a very naive implementation, our costs were down by 60% and our quality and our accuracy was up by around 70%.
—— Ameya Ketkar · [10:46]

否则我们可能会陷入智能体的空转:它修复了某个问题,回头又收到一次代码评审,然后不得不反向再修一遍,因为那条评论的质量很低。
Or else we can result in dealing with cavitation of an agent where it fixes something, goes back, gets another code review, and has to kind of like fix backwards because the quality of the comment was low.
—— Will Bond · [12:23]

与其把人类从代码评审流程中移除,我们是把他们的职责上移一层。
Rather than removing humans from the code review process, we are moving their responsibilities up a layer.
—— Will Bond · [13:55]

你不再是去担心性能优化和 API 兼容性,而是在代码评审中更多地去思考架构。
Instead of you worrying about the optimization of the performance and the API compatibility, you’re going to be thinking more about architecture in your code reviews.
—— Will Bond · [14:19]