Uber如何用AI Agent接管70%代码评审：技术拆解与落地指南

"Uber 工程师不动手，Agent 接管了 70% 的代码 PR" 这个话题，最近几天在我朋友圈里刷了屏。不少朋友第一反应是"标题党"，第二反应是"那我是不是要失业了"。说实话，我一开始也觉得 Uber 官方是在 PR 公关稿里注了点水，但仔细扒了一遍他们放出来的工程博客、演讲实录和代码仓库之后，我改主意了——这可能是 2025 年 AI Agent 在软件工程领域最有参考价值的一次真实生产落地，不是 demo，不是 hackathon 玩具，是几千名工程师日常在用的东西。

这篇文章我想好好拆一拆：Uber 到底怎么把 Agent 塞进代码评审流程的、70% 这个数字是怎么算出来的、他们用的是什么技术栈、以及作为普通开发团队，我们能从里面抄到什么作业。

1. 先搞清楚：Uber 说的 70% 到底是什么

很多人看到"Agent 接管了 70% 的代码 PR"这句话，第一反应是：AI 把 70% 的 PR 从头到尾写完了？这是对"PR"这个概念最大的误解。在 Uber 的语境里，PR（Pull Request，拉取请求）不是一个完整的功能开发任务，而是"一次代码变更从开发完成到合并主干的评审流转单元"。

90% 的 PR 根本活不到评审阶段——它们在半路就被机器人拦下来打回重做了。Uber 真正说的 70%，是"AI Agent 在代码评审这个环节的参与度"。他们的系统叫 Cowboy，底层用 Claude Code 驱动，在 GitHub 的 review 流程里自动做三件事：

• 静态分析：拿到 PR 之后，Agent 先把 diff 拉下来，跑一遍编译和 lint，把低级问题（格式错误、未使用的 import、明显的空指针隐患）直接标出来。
• 语义理解：把 PR 对应的需求单、相关 issue、上下游模块的调用关系拼成上下文，让模型理解这段代码到底想干什么，而不是只看语法。
• 评审意见生成：在 PR 评论区生成"哪些需要改、为什么需要改、建议怎么改"的结构化意见，并通知对应的负责人。

这玩意儿工作的效果，根据 Uber 放出来的数据，在一次涉及 300 多个仓库的大规模接入测试里，Agent 自动 approve 了大约 20% 的简单 PR，四五成的 PR 被打回修改，剩下的才进入人工评审。

Uber 官方博客里给过一个更具体的数据：AI 自动提出 review 意见的占比接近 70%，人工最后 review 的只有 30% 左右。所以你明白了吗，"接管"不是说 AI 替人把活干完了，而是说 AI 把代码质量保障的第一道防线从"人"变成了"Agent"。这 70% 的 PR 在到达人类工程师面前之前，已经被 Agent 筛过一遍、改过一轮了。

这里我补充一个背景：Uber 的技术栈是出了名的"超级单体"（monorepo），一个超大仓库里有上万个微服务和几十亿行代码，人工 review 的压力极大。他们大概是所有大厂里最渴望用 AI 来给代码评审减负的公司之一——不是闲得没事搞噱头，是真的疼。

搞清楚这个数字的边界，后面所有讨论才有意义：AI 不是来取代工程师的，AI 是来把工程师从"每天看几十个 PR 的机械劳动"里解放出来的。

2. 为什么是现在？Agent 接管代码评审的几个关键技术前提

Uber 不是今年才想搞自动化评审的。早在 2018 年，他们就有一套基于静态分析规则的机器人系统，能自动检测代码风格和常见 bug。但那套系统最大的问题是：规则是人写的，写规则的速度永远赶不上业务代码膨胀的速度。而且静态分析只能抓"模式"，看不到"意图"——它知道你调了一个空指针，但它不知道这个指针为什么为空、上游为什么传了空值来。

Agent 方案这几年能跑通，核心在于三个技术前提都到位了。

2.1 大模型真的能"看懂"代码了

GPT-4 之前，模型对代码的理解基本停留在"自动补全"级别：给它前几行，它猜后面几行。这种水平拿来做评审意见，一定会闹笑话。但到了 Claude 3.5/4 和 GPT-4o 这一代，模型的上下文窗口做到了几十万 token——什么概念？相当于它能同时"读"下一个小型仓库的全部核心代码。加上代码模型在训练时专门强化了代码推理能力，它已经能理解"这个 PR 改了支付模块的汇率计算逻辑，可能会影响上游对账系统"这种跨文件的因果关系。

Uber 的选择是 Claude Code，而不是 OpenAI 的 Codex，主要原因是Claude 在长上下文理解和遵循复杂指令（system prompt）上的表现更稳，尤其是面对几十万行的 monorepo 代码时，不容易"失忆"。再加上 Claude 的 Agent 功能允许它自主地跑命令、看日志、反复修改文件，这跟"只在一个对话框里聊代码"完全是两个物种。

2.2 Agent 从"聊天机器人"进化成了"会动手的同事"

早期的 AI 编程工具是"问答式"的：你问"这段代码有什么问题"，它回答，然后你去改。现在 Agent 是"委托式"的：你说"帮我把支付模块的重试逻辑改成指数退避"，它会自己打开文件、找到相关函数、修改、跑测试、再看结果，不满意就继续改，直到通过。

这个差异决定了"接管"的可能性。Uber 的 Cowboy 系统之所以能自动给 PR 打回修改意见、甚至直接提交修改，就是因为底层 Agent 有完整的工具调用能力：能读写文件、能执行测试命令、能 git commit、能 push 分支。它不再是一个"顾问"，而是一个"实习生"——而且是一个可以 24 小时不睡觉、同一时间处理 2000 个任务的实习生。

2.3 代码评审场景本身很适合 Agent 试水

说句公道话，Uber 选"代码评审"作为 Agent 落地的第一站，是非常聪明的策略。因为代码评审有几个特点：

• 收益可量化：评审通过率、打回率、平均处理时长都是现成的指标，能直接算 ROI。
• 风险相对可控：最坏情况是 AI 给了错误的评审意见，被人类工程师忽略即可，不会直接导致线上故障。
• 上下文相对封闭：评审一份 PR，需要看的东西是明确的（diff、相关文件、需求单），比让 AI 完全自主开发一个新功能好控制得多。

我甚至觉得，代码评审是 Agent 在软件工程领域最完美的一个切入场景——它的目标不是"创造"，而是"判断"和"修改"，而这两件事恰好是当前大模型最擅长、我们人类最烦的。

3. 从 0 到 1 搭一个能用的代码评审 Agent

光聊 Uber 的架构不落地，等于看了半天米其林菜谱还是不会做饭。我这里给你一套可直接复用的最小实现方案。这是我自己在团队内部跑了三个月的配置，稳定干掉了大约一半的琐碎评审工作。整套方案不需要你有很强的 AI 背景，照着做就能跑起来。

3.1 工具选型：为什么不推荐自己训练模型

先说结论：别自己训练代码模型，没用，纯烧钱。Uber 自己也没训练，他们用的是 Anthropic 的 Claude Code 作为基座，然后在上面做了一层封装。对于绝大多数团队，我建议的组合是：

• 底座模型：Claude（性价比最高）或 GPT-4o（如果你已经在 Azure 生态里）
• Agent 框架：Claude Code 官方 CLI 或者开源的 OpenHands（原 OpenDevin）
• CI 集成：GitHub Actions 或者 GitLab CI，用来在 PR 创建时自动触发 Agent
• 规则库：把你们的团队规范、常见踩坑写成一个 Markdown 文件，让 Agent 在评审前先"读"一遍

这套组合唯一需要写代码的部分就是 CI 配置文件，以及少量调 API 的脚本。正常一个后端开发半天就能搭完。

3.2 核心实现：CI 自动触发 + Agent 自主评审

我在团队里用的是 GitHub Actions + Claude Code 的组合，关键步骤和配置如下。

第 1 步：写好团队规范文件

在仓库根目录建一个CLAUDE.md文件，把你希望 AI 在评审代码时遵守的规则都写进去。比如我的文件是这么写的：

# CLAUDE.md ## 代码评审重点 1. 检查是否有潜在的并发安全问题（共享变量、锁使用） 2. 检查数据库查询是否缺少索引或存在 N+1 问题 3. 检查错误处理是否完善：网络超时、第三方接口异常必须有兜底 4. 检查日志是否完整：关键业务操作必须打点，禁止只 print 不落盘 5. 检查命名是否清晰：禁止缩写命名，禁止拼音命名 ## 评审输出格式 - 每个问题必须标注文件路径和行号 - 按严重程度分级：CRITICAL（必须改）/ WARNING（建议改）/ SUGGESTION（可选） - 修改建议必须给出具体的代码示例，禁止只说"请优化一下"

这个文件是 Agent 评审时的行为准则。Uber 内部有类似的东西，只不过他们管它叫"engineer playbook"，内容更庞大，细化到了几百条工程红线。

第 2 步：配置 GitHub Actions 触发 Agent

在.github/workflows/ai-review.yml里写上触发逻辑：

name: AI Code Review on: pull_request: types: [opened, synchronize] jobs: ai-review: runs-on: ubuntu-latest permissions: contents: write pull-requests: write steps: - name: Checkout code uses: actions/checkout@v4 with: fetch-depth: 0 - name: Run Anthropic Review Agent env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} run: | npx @anthropic-ai/claude-code review \ --diff-mode \ --output-format markdown \ --rules-file CLAUDE.md

这个 workflow 的作用很简单：只要有人提 PR 或者往已有 PR 里 push 新代码，GitHub Actions 就会自动跑一个 job，把代码拉下来，调用 Claude Code 的 review 模式，按 CLAUDE.md 里的规范生成评审意见。

第 3 步：Agent 自动提交修改

Uber 能做到"接管"而不是"建议"，关键在最后这一步：让 Agent 不只是提意见，而是直接把能改的问题改掉。

npx @anthropic-ai/claude-code \ --dangerously-skip-permissions \ review \ --fix \ --commit

加上--fix参数后，Agent 会尝试自动修复它认为有问题的代码；--commit则让它把修复直接提交到当前分支。这一套流程跑下来，很多简单的 CRITICAL 问题（比如空指针、未捕获异常）根本到不了作者面前就已被 Agent 修好了。

3.3 关键细节：Agent 拿到"足够上下文"的三种方式

很多人在搭这类 Agent 时会发现：AI 的建议总是浮于表面，因为它只看到了 diff，看不到整个项目的背景。Uber 解决这个问题的办法有三招，我实测下来非常有效：

• 关联需求单：在 PR description 里带上 Jira 或线性（Linear）的单号，CI 脚本先去拉需求描述文本，和代码 diff 一起喂给模型。模型知道"这段代码是为了实现 XX 业务功能"之后，评审的准确率能提升一个档次。
• 喂仓库地图：写一个REPO_STRUCTURE.md，告诉 Agent 哪些目录是干什么的、核心模块之间的依赖关系，类似给新同事一份入职导航。Claude 读了之后，就不会在工具函数目录里对着业务代码胡说八道。
• 允许 Agent 主动搜代码：Claude Code 自带 grep 和文件浏览工具，允许它自己去找相关调用方。比如它在评审一个支付函数时，自己会去搜"谁在调用这个函数"，然后判断改动的影响范围。

3.4 验收指标：别只看"它说了什么"

很多团队给 Agent 上线后，只会看"AI 提了多少条意见"，这其实是个错误指标。AI 提 1000 条可有可无的意见=噪音，提 5 条精准打击=神器。我建议用这几个指标来验收：

Uber 内部盯的核心指标也是类似的：他们统计过，Agent 参与评审后，一个 PR 从提交到拿到第一轮反馈的时间从平均 22 小时缩短到了 20 分钟以内。这组数据比"70%"更有说服力，因为它直接改变了开发者的工作节奏——以前写完代码要等一天才有人看，现在十分钟后 AI 就给你反馈了，你可以在上下文还热乎的时候立刻修改，效率完全不一样。

4. 实测下来的踩坑与排查：六个你没绕过的拦路虎

再完美的方案，落地时必定踩坑。我把自己和几个朋友团队在接入 AI 代码评审时遇到的典型问题整理了一下，大部分都是网上教程里没人提的血泪教训。

4.1 权限设置的坑：Agent 分不清"能看"和"能改"

我第一次配置的时候，为了让 Agent 方便行动，给了它很高的仓库权限。结果它顺手就把一个还在开发中的分支给合并了——因为我没配分支保护规则，Agent 把手里的 write 权限用在"合并 PR"上了。后来我花了半天时间恢复分支。

这个问题特别好解决：CI 里的 Agent 权限，能收多紧收多紧。我的经验是：

• 给 Agent 配一个单独的 GitHub 账号或机器人身份，不要用你自己的 token
• 只给pull和push到特性分支的权限，永远不给main分支的写权限
• 不要用--dangerously-skip-permissions（Claude Code 里跳过所有确认的参数），除非你完全信任它的行为边界

如果你用的是--fix --commit自动修改模式，建议在 GitHub 里加一条分支保护规则：特性分支允许 Agent 提交，但合并到 main 必须经过人类 review + CI 全绿。这是物理防线，不可跳过。

4.2 提示词设计的坑：Agent 变成"文科生"和"杠精"的两种极端

• 没有约束的 Agent 会变成"文科生"：提一堆"命名要更清晰"、"建议增加注释"这类空洞意见，完全无法落地，触发"建议疲劳"——开发者看多了，就再也不看 AI 的意见了。
• 太激进的 Agent 会变成"杠精"：死咬住某个风格问题不放，非要开发者改成它习惯的写法，导致 PR 作者和机器人吵起来。我在团队里见过最离谱的一次，Agent 把一段用Exception的代码反复改成RuntimeException，作者改回去，Agent 又改过来，来回拉扯了 5 轮。

解决办法有两条。第一条是写清"评审边界"：在 CLAUDE.md 里明确告诉 Agent，"只关注功能和正确性问题，不纠结代码风格；风格问题交由 linter 处理"。第二条是加"人工确认"环节：Agent 的修改一律以评论形式提交，由人类决定采纳与否，不要让 Agent 直接 push 修改到远程分支。

4.3 上下文污染的坑：Agent 越评越糊涂怎么排查

我遇到过最诡异的问题是：同一个 PR，AI 第一次评审给出了 5 条意见，第二次评审只给出 2 条，第三次评审说"没发现问题"。排查下来发现，是我的 CI 脚本在重复检查时有缓存——Agent 把上次的评审结果当成了代码的一部分"读"进去了，导致它误以为问题已经修复了。

排查这类"越评越糊涂"的问题，遵循一个简单的排查顺序：

# 1. 在本地复现 Agent 的执行环境 npx @anthropic-ai/claude-code review --diff-mode --verbose # 2. 确认 Agent 读到的文件列表 # 如果包含前一次评审留下的 comments.md，那就是缓存污染 # 3. 清理 Agent 的工作区，每次只保留干净的 git diff git reset --hard origin/main git clean -fd

这类问题的根源大多出在"工作区不干净"，清理之后基本能解决。

4.4 模型幻觉的坑：Agent 振振有词地改错了怎么办

说说最要命的问题：幻觉——AI 愣是判断某个函数一定会抛异常，给改成了try-catch，结果是业务代码，这个异常不应该被吞掉，直接导致一个支付回调的 bug 无声无息地溜过去了。我被这东西坑过一次之后，老实加了个"行为保险"：

• CRITICAL 级别的自动修改，必须强制附上测试结果：在 CLAUDE.md 里规定，Agent 一旦做了修改，必须在评审意见里附上自己跑的测试日志截图，没测试结果的意见视为无效。这一条几乎把"嘴上跑火车"的 Agent 治得服服帖帖——它知道要自我验证，就会收敛很多。
• 对 Agent 自己的改动再做一轮静态检查：Agent 修完代码之后，CI 里再跑一遍eslint+ 单测 +tsc，有任何一项不通过就直接 fail 掉整个 PR。

4.5 基础设施的坑：几十秒的模型延迟如何扛住大规模并发

大部分小团队可能遇不到这个问题，但方向明确、Agent 用量上来之后（一天几百个 PR），你会突然发现：GitHub Actions 的免费额度烧得太快了，而且串行等待模型回复的时间长得让人崩溃。

我的解决办法是改进调度策略：

• 把 Agent 任务放进一个队列系统（Sidekiq 或者简单的 Redis 队列都行），由 worker 异步消费，不要让 CI job 同步等待模型返回结果
• 对 API 调用做粒度改造：走 Claude 的批量处理接口（Batch API），不用实时接口，成本降低 50%，延迟变成异步的，不影响体验——Uber 的做法是自己在 Kubernetes 里跑了个 watchtower 服务，用预留的 GPU 实例跑模型推理，避免和对外业务抢同一批算力资源。

如果你只是想验证方案，完全没必要一上来就自建推理集群，直接用官方 API 量够了再优化。

4.6 人的问题：工程师把 Agent 当成"免死金牌"

最后这个坑乍一看不算技术问题，但它是真实存在的：一旦团队习惯"反正有 AI 兜底"之后，写代码的人会肉眼可见地变糙。这是我在负责的团队里踩到的最大的"坑"，比任何技术问题都难处理。

人手写出来的代码越来越依赖 AI 的 review 养成惰性：先随便写点能跑的，然后靠 Agent 给改。时间久了发现，真·代码设计问题（架构不合理、模块耦合严重）AI 是看不出大方向的，而人类工程师已经不想思考了。

我的应对措施有三条，现在都在执行：

• 给 Agent 定位成"第一个 reviewer"而不是"唯一的 reviewer"，关键 PR 仍然强制人工 review
• 每周拉一次"Agent 意见被驳回率"的报表，被驳回超过 30% 就降级 Agent 的权限，回退成"仅提示"模式
• 在 CLAUDE.md 里明确写：Agent 只解决"怎么改"，不负责"要不要这么改"，业务决策必须由人拍板

5. 这套玩意的边界在哪里：它不会取代工程师，但会让人分层

最后，我应该给你一个尽量冷静的判断：AI Agent 做代码评审，能做到什么程度，做不到什么程度，必须提前说清楚——这样咱们都不至于到时候被现实打脸。

Agent 真正擅长的是"查漏"和"改错"。比如"这里少了个判空、那里日志级别用错了、这个循环有性能隐患、这个新 API 跟老逻辑冲突了"这类具体、明确、有标准答案的问题。它们 24 小时在线，别的不用干，就盯着所有 PR。你从下午一直干到半夜，它也在那儿跑着，能把那些无聊的統一命名、异常处理补充、语法规范校对全都无声无息地消化掉。这对一个每月合并几百个 PR 的团队来说，省下的人力是真实可感的。

Agent 目前做不到的是"审美"和"取舍"。它不会对你说"微服务拆分的边界这里其实不对，我们聚合根的理念出问题了，这是架构级别的重构"——不是它不聪明，而是这类判断需要的上下文跨度太大，超过了它"看一段 diff"的能力范围。Uber 也承认，他们放给 Agent 自动处理的，是那些"低风险、高确定性"的 PR；涉及核心支付、司机分配这类动一发牵全身的逻辑，依然是工程师亲手把关。

所以这件事真正的走向，我判断不是"程序员失业"，而是"程序员分层"。单靠复制粘贴、走流程、改 bug 的底层码农岗位会被大幅压缩；而那些理解业务逻辑、有架构判断力、能设计出好 prompt 和好流程的人，会成为 AI 的上级——就像是每个工程师都配了几个 24 小时加班的"AI 实习生"，你负责决策，它们负责执行。

在这轮变化里，最应该从 Uber 这个案例里学到的不是"怎么配 CLAUDE.md"或者"怎么调 GitHub Actions"——那些都会过时。真正值得学的，是那种把重复劳动拆解出来、交给工具、释放人力去做更高价值判断的思路。这条路，从 U 盘时代开始就没变过，Agent 只是把这个趋势加速了十年。

如果你准备在团队里动手试这套东西，我的建议就一句话：从小事开始，先把"自动在 PR 上留评审意见"跑起来，跑顺了再让它碰代码，它证明自己靠谱了，你再给它加攻击面。当年我们学写代码也是"先打印一行 Hello World"开始的，Agent 也一样。