企业官网建设流程全解析

我最早看到Uber那条分享时，第一反应是：这确定不是PR稿？70%的PR让Agent接走，那工程师还能干嘛？但后来我把他们在开发者大会上的公开内容翻了一遍，发现事情没那么玄，也没那么简单。简单说，Uber内部把AI Agent引入了代码提交流程，从一个想法到代码改动、写测试、跑CI、生成PR描述，甚至收到review意见后做二次修改，都有一部分交给了Agent处理，最后由人类工程师做兜底把关。这篇文章不打算复述PPT上的数字，而是想把这个数据拆开看：Agent到底接走了PR流程里的哪些活？普通团队能不能复刻这套玩法？以及工程师手上的牌，到底该怎么重新打。

1. “70% PR被接管”到底是怎么回事

1.1 被接管的不是合并权限，而是“码字工作”

先把这个传播最广的数字说清楚。Uber提到的70%，指的是“由Agent生成代码改动/参与生成的PR数量”占到了PR总量的70%，而不是说70%的PR在无人值守的情况下被自动合并进主干，这两者差别非常大。

我在很多群里看到有人焦虑，说“工程师不动手了”“代码全让AI写了”，这其实是误解。真实的流程更像是：Agent作为“写代码的实习生”把第一版改动做好，生成PR描述，推到分支上，然后人类工程师作为reviewer去看、去改、去否决。主导权始终在工程师手里，Agent干的是最耗体力的那段——把零散需求翻译成代码改动，把改动整理成能看的PR。

这个细节很重要，因为它决定了整套方案的落地姿态。Uber没有选择让Agent直接往主干推代码，而是把Agent嵌到了“人类审核”的既有流程里。表面上看只是换了个写代码的人，实际上是在不改变GitHub工作流习惯的前提下，把生产力护城河往前推了一大截。

1.2 数据背后藏着三个关键信号

第一个信号是跨仓库、跨服务的代码上下文理解能力已经过了及格线。Uber这种体量的代码库，服务和依赖关系极其复杂，Agent不是在一个空目录里写hello world，而是要理解某个内部服务的API该怎么调、测试该用什么框架、代码风格该怎么保持一致。70%这个数字说明Agent在这种“脏乱差”的真实环境里已经能稳定产出，而不是只在demo里秀肌肉。

第二个信号是团队对“AI生成的代码”接受度，已经从尝鲜变成常态。我见过不少团队买了AI编码工具，结果半年后只有两个人偶尔用，根本原因不是工具不行，而是流程没跟上。Uber的做法是把Agent当成一个正式的代码贡献者来对待，该走review走review，该挂标签挂标签，这就让使用Agent不再是个人的“技术玩具”，而是团队的标准工作方式。

第三个信号是70%是平均值，不是每个团队都到了这个比例。不同业务的代码特点、测试覆盖度、需求清晰度差异很大，有的团队可能只有30%，有的可能接近90%。所以如果你所在团队目前只有10%的比例，也不用觉得落后，关键是先把流程跑通。

1.3 为什么不是100%，剩下的30%给谁干

这个问题的答案，恰恰是理解Agent能力边界最好的窗口。剩下的30%通常集中在几类场景：核心支付链路的逻辑改动、跨多个服务的架构级重构、涉及隐私合规的敏感变更，以及需求本身模糊到没法拆成清晰指令的探索性任务。

这些任务的共同特点不是“代码难写”，而是“说不清楚要什么”。Agent对模糊需求的理解能力虽然比一年前强了不少，但遇到产品经理自己都没想清楚的逻辑，它也只能给你一版“看起来合理”的实现，这种风险在核心模块上是不可接受的。所以Uber留下来的30%，本质上不是Agent写不了这些代码，而是一旦出错代价太大，必须让最了解业务上下文的人类来做判断。

我在自己的项目里也有同样的体感：Agent在“把需求翻译成代码”这件事上越来越强，但在“判断这个需求到底对不对”这件事上，仍然需要人来兜底。认清这个边界，才不会对Agent抱有不切实际的期待。

2. Agent能接管PR，靠的不只是大模型

2.1 一个能“写PR”的Agent，至少要过三关

很多人以为，把GitHub仓库喂给一个会写代码的大模型，它就能自动产出PR了。真这么简单，就不会有这么多团队在Agent落地上翻车了。一个能稳定干活的Agent，至少要过三关。

第一关是上下文关。它得知道这个仓库的结构、相关的文件在哪、依赖关系是什么、同类功能以前是怎么实现的。换到Uber的体量，就是几百上千个仓库之间互相依赖，Agent不能只盯着当前仓库看，还得能跨仓库检索到正确的API定义和调用方式。这一关做不到，后面全是空中楼阁。

第二关是执行关。写代码只是第一步，写完之后还得能跑起来：格式化、跑lint、跑单元测试、构建，出错了得读日志、找原因、改代码、重跑。这本质上是一个“计划-行动-观察-调整”的循环，一个Agent如果只会在代码编辑器里生成diff，但不会自己关闭报错循环，那它就只能欺负最简单的场景。

第三关是沟通关。代码写对了，PR描述写得像鬼画符，reviewer照样不想看。Agent要能生成清晰简洁的PR描述，说清楚改了什么、为什么这么改、怎么测试验证，还要能针对review意见给出合理的回复和修改。很多团队低估了这一关，结果Agent代码能跑，但人在review时看得一头雾水，最后还是得重写描述，效率反而更低了。

2.2 从Issue到PR，Agent的工作流长什么样

虽然Uber官方分享里没有把完整技术栈逐行公开，但从这套体系的通用形态来看，Agent处理一个PR请求的标准工作流是可以还原出来的，大致分七步：

1. 接收任务描述：从Issue、任务卡片或聊天指令里解析需求，拆解成“要改什么、达到什么效果、有什么约束”。
2. 检索相关代码：基于语义搜索和代码图谱，找到需要修改的文件以及相关的测试、依赖、调用方。
3. 制定改动方案：对比几种实现路径，按最小改动原则选择方案，并列出改动清单。
4. 写代码并补充测试：按要求生成代码改动，配套补上单元测试或集成测试。
5. 本地验证：自动跑格式化、lint、静态检查、构建和测试，失败就回到第4步迭代。
6. 提交分支并生成PR描述：创建独立分支，commit，生成结构化的PR描述，附上改动说明和测试结果。
7. 监听后续反馈：PR创建后继续盯CI状态，reviewer提了意见就基于意见迭代修改。

这套流程里，最容易被忽视的是第5步和第7步。很多Agent方案demo看着很酷，但一接真实项目就露馅，就是因为没有把“验证-反馈-迭代”这个闭环做好。Uber能做到70%，说明他们的Agent在这两步上已经相当稳定。

2.3 为什么先从PR环节切入，而不是让Agent直接改主干

我在给团队设计AI辅助开发方案的时候，发现一个规律：凡是让Agent自由发挥、直接改主干代码的方案，最后都死得很难看；凡是把Agent按进既有review流程里的方案，活下来的概率就大得多。

原因其实不复杂。PR是代码质量的天然闸门，它自带一套人类确认机制，可以让Agent的能力边界在可控范围内试错。就算Agent生成了一坨不太完美的代码，reviewer也能拦住，不会直接污染主干。另外PR有明确的格式和验收标准，什么算完成、什么算通过，边界很清楚，这种结构化场景恰好是Agent最容易表现的领域。

所以Uber选择从PR环节切入，不是保守，而是聪明。它没有改变工程师既有的工作习惯——照常在GitHub上review、合入、管理分支，只是把“从零开始写PR”这个环节外包给了Agent。用最小的流程改造成本，换来了最大的效率提升，这也是普通团队最值得参考的思路。

3. 普通团队复制这套方案，从哪几步开始

3.1 先盘点自己的工程底座，别急着上Agent

说实话，很多团队看到Uber的数据就热血上头，第二天就想让Agent接管全部PR，结果第三天就灰头土脸撤下来。我见过太多失败案例，根子不在Agent能力不行，而是团队的工程底座压根没准备好。

动手之前，先对照下面这个清单做个体检：

• 代码托管平台：用的是GitHub、GitLab还是其他平台？对API的支持够不够？
• CI/CD能力：有没有现成的流水线？测试和构建是不是自动跑的？
• 测试覆盖面：核心模块有没有测试保护？没有测试的代码，Agent改完你敢合吗？
• 分支规范：PR流程是否统一？有没有明确的review人分配规则？
• 代码质量门槛：有没有lint、静态检查、覆盖率卡点？

如果你团队的CI还在“点击按钮手动触发”的阶段，核心服务一行测试都没有，那第一步要做的不是上Agent，而是先把这些基础补上。Agent本质上是个“写代码很快但不太懂事的新人”，没有测试和CI当护栏，它闯的祸会比省的时间多得多。

3.2 第一层改造：先给工程师配一个单人Agent助手

工程底座达标之后，我建议不要一上来就搞“Agent自动开PR”这种大动作，先从最轻的一层开始：给团队里的核心工程师配上单人Agent助手。

这一层的做法很简单，给工程师开一个能访问私有仓库的Agent工具（比如Codex CLI、Claude Code这类命令行助手，或者IDE里的Agent模式），让他们在本地用自然语言描述需求，让Agent生成改动、跑测试、提交分支。这个阶段的目标不是追求自动化比例，而是让团队成员熟悉Agent的工作方式，摸清它在自己代码库里的脾气。

我在团队里推这个阶段时踩过一个坑：一开始让所有人自由使用，结果接受度两极分化严重，爱折腾的人用得很爽，不爱折腾的人觉得“不如自己写”。后来我们改成“先选两三个愿意尝鲜的人跑两周，把常见用法沉淀成文档，再组织分享推广”，接受度一下就上来了。工具落地最难的不是工具本身，而是改变人的习惯。

3.3 第二层改造：让Agent参与PR评审，而不是只写代码

第二层，是把Agent从“写代码的助手”升级为“评审流程里的一员”。具体做法是在CI流水线里加一个Agent评审步骤，PR一创建，Agent自动跑一遍diff检查，分析改动可能引入的bug、测试覆盖盲区、代码规范问题，然后以评论的形式输出评审意见。

这一步的代码逻辑其实不复杂，核心是搭一个小服务，监听PR创建事件，拉取diff，把diff和相关的仓库文档、历史代码上下文一起打包发到模型接口，再把返回的评审意见以评论的形式回写到PR里。我实际用的配置里，对Agent的要求分三层：第一层看必改项，比如明显的逻辑错误、空指针风险；第二层看建议优化，比如性能隐患、可读性问题；第三层只给提示，比如测试覆盖不足，供人参考。

这里有个很关键的细节：Agent评审意见不能直接进入正式review流程，更不能block合并，它只能以“仅供参考”的机器人评论存在。一旦Agent的自动评论有了过大的决策权重，工程师就会想办法绕过它，整个机制就废了。保持“辅助”的定位，这个工具才能活得久。

3.4 第三层改造：让Agent以“贡献者”身份自动创建PR

做完前两层，人和流程都磨合得差不多了，再上第三层：让Agent独立创建PR，形同团队里多了一位全天候的“虚拟贡献者”。这一层才是Uber那种70%比例的实现路径。

操作上，Agnet会领取一个任务，独立拉分支、写代码、跑测试、提交PR，PR上会打上“generated-by-agent”的标签，reviewer通过标签可以快速识别哪些PR是Agent生成的，从而用不同的心态去review——不是不审查，而是知道重点要看什么。合入门禁、Owner review规则、CI检查全部照旧，Agent的PR没有任何特权。

这一层能不能跑成，我总结下来有三个决定性因素：一是任务描述的拆解模板，写得越清晰，Agent产出越稳定；二是仓库的上下文检索能力，代码索引和文档质量直接影响Agent表现；三是diff审核机制，Agent容易出现“顺手改多了”的毛病，需要靠diff评审钩子拦住无关改动。

3.5 工具选型：自研编排还是商用方案

最后聊一下工具选型。市面上现在有三类东西：一是通用Agent框架，你可以基于它们自己编排“读取需求-检索代码-生成PR”的工作流；二是商用编码Agent工具，比如OpenAI的Codex、Anthropic的Claude Code、各类IDE的Agent模式；三是更接近完整平台的解决方案，比如GitHub Copilot coding agent这类直接和代码托管平台深度集成的能力。

我自己对不同规模的团队建议如下：

• 小团队（5人以内）：直接用商用工具的Agent模式，每人一个助手，先把个人效率拉满，不需要自研。
• 中型团队（20-50人）：用商用工具+轻量自建CI步骤，把Agent评审、Agent自动PR这层薄薄地包一层，不用自己训练模型。
• 大团队（100人以上）：考虑自研编排加上代码索引基建，因为到了这个规模，上下文检索、权限隔离、成本控制都是商用工具没法直接给的。

选型时有一个原则：能用别人的轮子就不要自己造。Agent领域迭代极快，今天自研的编排框架，可能三个月后就被某个开源项目超越了。除非你的需求真的非常特殊，否则把精力放在流程设计和prompt打磨上，比放在框架自研上划算得多。

4. 工程师的新技能清单：Agent来了，谁被替代，谁被放大

4.1 “写代码”正在从体力活变成管理活

很多开发者的焦虑点是“AI都写代码了，我还要干嘛”。这个焦虑可以理解，但方向错了。不是“AI替代工程师”，而是“代码生产方式的劳动分工变了”。

我打个比方：以前工程师是木匠，自己量尺寸、自己锯木头、自己打磨，活干得细但慢。现在Agent是一个力气很大、手艺还不错但没什么审美的新学徒，你把图样画清楚，它能帮你把粗活干完，剩下的精修、判断、决策还是你的。工程师的角色正在从“抡锤子的人”变成“看图说话、盯质量的人”。

这个转变带来的直接结果，是下面几项能力变得比以前更值钱了：

• 需求澄清能力：能把模糊的产品需求拆成Agent能执行的清晰任务，这个能力直接决定Agent的产出质量。
• 代码审查能力：Agent写得更快，意味着你需要review的代码量更大，能不能快速看出逻辑漏洞和隐性问题，成了核心技能。
• 业务上下文理解：Agent不懂业务，也不知道这个功能在真实场景里要怎么用，只有你懂，这是无法外包的壁垒。
• 系统工程思维：Agent擅长写局部代码，但跨模块交互、数据一致性、故障恢复这层系统级的思考，目前仍然是人的主场。

4.2 把Agent当成“刚入职的实习工程师”来带

这个类比是我在带团队时反复强调的。你对一个新来的实习生是什么管理方式，对Agent就该是什么管理方式，甚至更严格。

实习生你不敢放手，是因为你不知道他会捅什么篓子。Agent也一样，只是它动作更快、闯祸范围更大。所以你要做三件事：第一，任务拆得足够细，每个任务有明确的验收标准，而不是一句“把这个功能实现一下”就丢给它；第二，给它配好工具和文档，仓库里有没有清晰的README、有没有合理的代码目录结构，直接决定它能不能找到该改的文件；第三，设定复查节奏，Agent每完成一个阶段你就要检查一次，不要等PR出来了再惊觉方向全错了。

我个人的习惯是，给Agent布置任务时，一定会附上三样东西：需求背景、验收清单、约束条件。缺一样都不行。需求背景告诉它为什么做，验收清单告诉它做到什么程度算完，约束条件告诉它哪些事不能做。有了这三个东西，Agent的表现会稳定很多。

4.3 把Agent生成的PR当成“外部贡献者”来管理

Uber这套方案里，有一个细节很值得普通团队学习，就是给Agent生成的PR打上专属标签，把它当外部贡献者的代码来管。

这个设计的妙处在于，它从流程上就锁定了风险边界。外部的陌生贡献者提交的PR，你会自动提高警惕，仔细看逻辑、看测试、看有没有安全风险。给Agent生成的PR打上标签，等于让所有reviewer在打开PR的瞬间就切换到“审慎模式”，而不是因为“这是我们自己的Agent写的”就放松警惕。

在团队落地时，可以配套几个具体动作：给PR标签加颜色让人一眼识别；设置至少一名有代码库ownership的工程师review Agent PR；Agent PR里的测试覆盖率必须达到团队既定标准；如果是核心模块的改动，必须有第二个人二次确认。这几条规则听起来简单，但在真实运行中能拦住绝大多数翻车事故。

5. 我踩过的坑：Agent处理PR的典型翻车与排查手记

5.1 PR描述很漂亮，代码却在摸鱼

先说一个我早期印象最深的翻车。有一次Agent提交的PR，描述写得那叫一个专业，背景、方案、改动点、测试结果列得清清楚楚，乍一看是高级工程师的水准。结果我点开diff一看，核心逻辑压根没实现，只是搭了个空壳，测试也是那种“为了跑过而跑过”的假测试。

后来我总结出规律：大模型天生擅长生成“看起来合理”的文本，所以PR描述漂亮不代表代码靠谱。防范的方法是强制要求Agent在PR描述里附上可验证的证据，比如关键测试的实际输出、覆盖率报告、构建日志摘要。没有这些硬证据的PR，直接打回。但这还不够，人一定要拿着diff逐行看，确认描述和改动对得上。把“描述漂亮”作为加分项，而不是信任依据，能避开大量画饼型Agent。

5.2 改一行代码，顺手改坏了三个文件

另一个高频翻车，是Agent在完成目标时“路径依赖太强”，为了让它觉得代码更合理，往往会附带一堆无关的重构和格式调整。你要它修一个边界问题，它顺手把整个函数的命名都给你改了，diff看起来很大，review成本直线上升不说，还容易引入隐藏回归。

这类问题我排查下来，根因通常是两个：要么是Agent上下文检索时抓错了相关文件，跑偏了；要么是prompt里没有加“最小改动”的约束，模型偏好生成看起来更完善的代码。

解决办法有两层。提示词层面，我会在任务描述里明确写“禁止无关重构，只修改与目标直接相关的代码”；流程层面，会加一个diff规模检查步骤，当单个PR改动文件数或行数超过设定的阈值时，自动提示风险并要求人工确认。这两个手段一起用，基本能把“顺手改坏”的概率压到很低。

5.3 多个Agent同时提交，互相覆盖的“幽灵冲突”

当Agent被普及到团队以后，会遇到一个人肉时代不太常遇到的问题：多个Agent在同一个时间段基于同一个仓库状态做修改，提交时互相覆盖。由于Agent的动作频率比人高得多，这个问题会被急剧放大。

我遇到过最头疼的一次，两个Agent被安排到不同任务，结果它们同时改了同一个公共模块，互相把对方的改动打成冲突，最后合入时代码逻辑直接错乱。排查下来我发现根因是Agent的工作流程里少了“前置同步”和“状态可见性”这两个环节。

现在我们的做法是：涉及公共模块的任务放进同一个队列串行执行；Agent开始工作前必须先rebase到最新主干；同一时间同一文件最多只有一个Agent在动；合并前再强制跑一次全量测试。这套规则看起来笨，但实际跑下来，冲突率降了八成。

5.4 常见问题速查表

5.5 实操心得：Agent能帮你写代码，但不会替你背锅

现在但凡问到要不要引入Agent来写PR，我给的建议都是“要，但得想清楚边界”。Agent最大的价值不是替你写代码，而是把你从重复性劳动里解放出来，让你把精力花在更复杂的判断和决策上。但同时你也要明白：PR上签的是你的名字，线上的故障不会去找Agent，只会来找你和你的团队，这个责任是Agent替代不了的。

所以我个人体会是，引入Agent最合适的心理预期不是“我去休息”，而是“我换个更高级的活干”。让Agent去跑腿写初稿，自己去盯架构、盯质量、盯那些机器判断不了的东西。这样你既不会被工具淘汰，还能借着工具跑得更远。

最后再分享一个我实测好用的技巧：不要让Agent一次性生成一个巨无霸PR，而是把大任务拆成几个小PR，每个PR只做一件清晰的事，每完成一个就合并一个。这样Agent的每一步改动都足够小、足够可控，review难度低，出错了也好定位，回滚了也不心疼。你照这个节奏试一两周，会发现Agent交付的PR质量稳定上一个大台阶。