企业官网建设流程全解析

先放一个判断：Uber 用 Agent 接管 70% 代码 PR 这件事，真正的信息量不在“AI 写代码”，而在“AI 账单零增长”这个反直觉结果。

过去一年，很多团队对 AI 编程的印象还停留在两个极端：要么觉得 Copilot 类工具只是“高级补全器”，写不了一个完整 PR；要么担心让 Agent 大规模提 PR，API 成本会失控，代码评审会变成垃圾回收站。

Uber 这个案例恰好把两个问题一起回答了：Agent 能不能在真实工程环境里大规模产出可合并的 PR，以及当 AI 使用量上去之后，成本为什么没有同步暴涨。

这篇文章不打算复述新闻。我想拆的是：这个结果是怎么发生的，它背后改变了哪些工作流，以及一个普通团队如果想复现类似效果，应该从哪一步开始，在哪几步最容易翻车。

1. 先搞清楚“70% 的 PR 由 Agent 接管”是什么意思

1.1 不是 70% 的代码由 AI 独立编写，而是 70% 的 PR 由 Agent 参与

这里首先要做一个关键澄清。很多文章把“Agent 接管 70% 代码 PR”理解成：Uber 现在每 10 个 PR 里有 7 个是 AI 从零写出来的，人类工程师只负责点合并按钮。

这个理解不准确。

“接管”在工程语境里更接近“Agent 承担了 PR 创建链路里的主要工作”。它参与的方式可能包括：根据 issue 描述生成初始 diff、按已有代码风格补全实现、修复测试失败、更新文档和 changelog，甚至根据 Review 意见迭代代码。但真正决定这个 PR 能不能合并，仍然有一整套人工评审、CI 检查和负责人审批机制。

所以更准确的说法是：Uber 把 PR 从“人写机器审”变成了“Agent 起草 + 人审 + 机器校验”的大规模协作模式。

这个区别非常重要。因为如果只在意“AI 写了多少行代码”，就会忽略真正有价值的工程变化：AI 已经嵌入到 PR 的完整生命周期里，而不是作为一个孤立的代码生成器存在。

1.2 为什么这个数字能说明 Agent 真正“能用”了

70% 这个比例，不是 Uber 内部某个团队做了一次实验，而是覆盖了大量真实业务代码的统计结果。它意味着 Agent 生成的 PR 已经能够通过已有的 CI 检查、编译、测试、静态分析和一部分代码评审。

过去 Agent 写代码最大的问题不是“写得不对”，而是“产出根本无法进入评审流程”。很多代码看起来能跑，但放到真实仓库里，风格不一致、依赖引入错误、边界条件缺失、测试不完整，评审人一眼就能挑出大量问题。结果就是 AI 只负责“写”，人负责“全部返工”。

Uber 这个案例里真正质的转变是：Agent 的产出已经跨过了“能提交”的门槛，进入了“值得评审”的区间。

这是从“玩具”到“生产工具”的分界线。

1.3 70% 不是终点，而是组织流程再造的结果

还需要看到另一层：Uber 能跑到 70%，不只是模型能力提升了，而是整条工程体系为 Agent 适配了环境。包括代码库的模块化程度、测试覆盖率、CI 反馈速度、评审规范、PR 模板、甚至 Agent 可以访问哪些仓库和服务的权限边界。

换句话说，70% 不是“AI 突然变聪明了”，而是“整个工程系统开始允许 AI 有效率地工作”。

这给了其他团队一个重要的横向参考：如果你也想让 Agent 大规模提 PR，先不要急着问“哪个模型最强”，而要先看自己的仓库和流程有没有为 AI 做好准备。

2. 为什么“AI 账单零增长”比 70% 更值得关注

2.1 看起来矛盾的组合：用量涨了，钱没涨

如果只看“70% PR 由 Agent 接管”，很多人的第一反应是：那 API 成本不得爆炸？

Uber 的做法却给出了另一个结果：AI 账单零增长。这不是说没花钱，而是说在 PR 数量、Agent 参与比例大幅上升的情况下，总成本被控制在一个稳定区间。

这个组合在工程上其实很不寻常。因为通常“用得越多，成本越高”是自然规律，尤其是调用大模型 API 时，Token 消耗是硬成本。如果 Agent 每天生成几千个 PR diff，每个 diff 还要经历生成、评审意见迭代、多轮修改，Token 量会成为一个不可忽视的数字。

所以“零增长”背后一定不是魔法，而是有明确的成本控制机制。

2.2 成本控制的第一逻辑：不是所有环节都调用大模型

Uber 这类体量的公司，处理成本问题的方式通常不是“不用 AI”，而是“重新设计调用策略”。

一个典型的 PR 生成流程，Agent 可能会经历：

• 理解 issue 描述和仓库结构
• 读取相关文件
• 生成代码 diff
• 运行测试
• 根据报错修复
• 提交 PR
• 根据评审意见修改

如果每一步都调用一次模型，Token 消耗会成倍放大。常见做法是尽量把中间过程落到确定性工具上——比如直接读取文件、执行静态检查、跑测试、处理 Lint 报错——只在真正需要理解和生成的环节调用模型。

这类流程组合有时候也被称为“Agent 链路里的工具优先策略”：能靠脚本、解析器、编译器和正则解决的事情，就不让模型参与。

2.3 成本控制的第二逻辑：用“更长上下文”换“更少返工”

另一个常见策略是提高单次生成质量，避免“生成—失败—再生成”的反复消耗。

与其让 Agent 用很短的上下文先生成一个粗糙版本，再在后续修复循环里烧掉大量 Token，不如从一开始就把相关文件、项目规范、历史代码风格塞进上下文，让模型一次产出更接近可合并状态的 diff。

这个策略下，单次调用的 Token 会变高，但总成本反而下降。因为大模型成本的大头往往是多轮失败迭代，而不是单次调用。

用一句类比来说：如果让一个新人写 PR，你希望他自己带齐资料写，还是让他先交一版，你再逐条批注让他改十遍？后者沟通成本更高，而且极易返工。

2.4 Token 层面的“零增长”不是目的，ROI 才是

回到“AI 账单零增长”这一点，它真正有价值的解读不是“Uber 省钱省得好”，而是：Uber 用几乎不变的成本，换来了显著提升的 PR 吞吐量。

也就是说，每份 AI 账单对应的产出效率变高了。如果 PR 数量涨了 50%，成本却不变，那单 PR 成本其实降了三分之一。这才是工程上更值得关注的结果。

对中小团队来说，虽然体量不同，但可以借鉴同一个原则：不要盯着“每个月花多少钱”，而是盯着“每块钱换来多少可合并的 PR”。

3. 从“人写”到“Agent 起草”的工作流变化

3.1 一条典型的 Agent 生成 PR 链路

下面这条链路不是 Uber 官方文档，但它是当前生产环境里最常见的一种工程化写法，可以当作一个通用参考。

Issue 创建 -> Agent 解析 issue 和关联代码 -> 生成初始 diff -> 自动运行相关测试和静态检查 -> 根据失败信息修复并迭代 -> 创建 PR -> 触发 CI -> 通知工程师评审

这个流程里需要注意几点：

• 第一步不是让 Agent 写代码，而是让 Agent 理解问题。包括 issue 描述、关联模块、涉及文件、已有测试。
• 中间步骤不是一步到位。Agent 通常要经过多轮“生成—检查—修复”循环，才能产出可提交的 diff。
• 最后一步仍然保留人工评审。Agent 提 PR 不代表人不用看了，而是人的工作从“写初稿”变成了“审终稿”。

这种工作流的本质是：把重复性、机械性、低上下文量的部分交给 Agent，把判断、决策和问责保留给人。

3.2 这个流程解决了过去三个顽固问题

第一，写 PR 初稿的速度。一个熟悉业务的老工程师，写一个中等难度的 PR 可能也要二十分钟到一小时。Agent 可以在更短时间内生成初稿，虽然不一定完美，但至少把空白页的恐惧消掉了。

第二，代码风格一致性。大模型在上下文里读到足够多的仓库代码后，生成的代码风格会比新人更加贴合仓库习惯。这是单次生成和长期学习共同作用的结果。

第三，重复劳动。比如修一个跨模块影响的 bug，过去的流程需要先定位调用链，再理解多个文件，最后修改并补测试。Agent 可以在拉取相关文件后，自动生成一个可评审的版本，技术人员只需要关注逻辑对不对、边界有没有漏。

不过这里要提醒一句：Agent 可以把“写代码”变快，但还不能把“该写什么”替你想清楚。如果需求本身模糊，issue 描述不清楚，Agent 生成的代码再快也是错的。

3.3 评审环节从“看实现”变成了“看意图”

这不是概念包装，而是工作重点的真实迁移。

以前人工评审 PR，很大一部分精力花在“这行代码语法对不对”“这个变量名是否清晰”“是否少了类型声明”这类指标上。Agent 接手之后，这些基础问题会大幅减少，因为生成模型天然更少写出低级语法错误。

评审者的注意力会转移到更重要的位置：

• 这个实现是否满足原始需求
• 有没有漏掉边界情况
• 性能上是否有隐患
• 依赖引入是否合理
• 安全性和权限处理是否正确
• 是否考虑了兼容性

这其实是好事。当一个工程师的精力从“挑语法错”变成“审逻辑和意图”时，评审质量会上升，而不是下降。

但前提是：评审人自己得真的去看代码。如果因为信赖 Agent，就只瞄一眼测试绿了就合并，那 Agent 也会给你回报一个足够隐蔽的问题。

4. 想复现 Uber 的效果？先按这四个维度检查你的团队

4.1 代码库的质量：Agent 能读懂的库，才能改得好

决定 Agent 产出质量的第一因素，往往不是模型，而是仓库本身的模块化和可读性。

如果一个仓库里到处是巨型函数、隐式依赖、复制粘贴代码、没有测试，Agent 即使能读，也很难生成达标的修改。因为它没有足够清晰的上下文信号去判断“该在哪里改”“改了之后会牵连什么”。

所以复现 Uber 效果的第一步，不是引进最强 Agent，而是先问：我们的仓库能不能让一个不熟悉业务的新工程师快速上手？如果答案是不能，那 Agent 也会遇到同样的问题。

反过来看，一个测试覆盖率高、模块边界清晰、命名规范的仓库，Agent 的可用性会成倍上升。这也是为什么很多团队在引入 AI 编程后，反而开始重视代码质量和架构规范——不是 AI 带来的负担，而是 AI 放大了优良工程基础的价值。

4.2 CI 和反馈速度：慢的 CI 会拖死 Agent

Agent 迭代修复依赖一个关键反馈：测试和静态检查要跑得快，报错要足够明确。

如果一次代码提交要等 30 分钟才知道结果，Agent 的迭代效率会断崖式下降。它每改一次都得等半小时，人也会在这个过程中逐渐失去耐心。

更好的环境是：

• 小范围测试优先跑
• 静态检查在本地执行
• 报错日志能准确定位到文件、行号和原因
• 快速失败，而不是长时间挂起

如果团队现在 CI 就要跑一个小时以上，那么接入 Agent 之前，还要先优化 CI 反馈速度。否则 Agent 只能靠“碰运气”提交，返工率会非常高。

4.3 权限和工具链：Agent 能访问哪些仓库，运行哪些命令

一个 Agent 如果只能生成代码文件，却不能运行测试、读取日志、查询 CI 状态，那它的能力上限就只是一个高级补全器。

要让 Agent 真正“接管 PR”，需要给它一系列能力：

• 拉取代码库和相关分支
• 读取指定文件
• 运行特定测试
• 获取测试失败日志
• 安装依赖（或至少在受限环境下）
• 提交分支并创建 PR
• 响应评审意见

这些能力在工程上对应的是权限管理、命令白名单、沙箱环境和日志系统。实际落地时，这里也是安全风险最高的地方。必须限制 Agent 能访问的仓库范围、能执行的命令列表、能修改的文件路径，否则就是给攻击面开了口子。

注意：不要把 Agent 的权限设置成“等同于一个全权限开发者的权限”。即使内部团队信任，Agent 也可能因为上下文误判而执行危险命令。权限收敛是必须项，不是加分项。

4.4 成本预算：没有成本控制，Agent 只是另一个烧钱黑洞

“零增长”不是自动发生的，而是有预算上限和策略设计的结果。

一个务实做法是给 Agent 系统设置三层预算：

1. 单任务预算：一次 PR 生成最大允许消耗多少 Token 或多少钱，超出就停止并请求人工介入。
2. 团队月度预算：每个团队、每个项目每月最多消耗多少 AI 资源。
3. 全局配额：公司整体设置一个可控的AI工具预算池，超过后自动降级或提醒。

这三层预算的逻辑是：先设上限，再看结果。不要等到月底账单出来再后悔。

5. 实际落地时最容易被低估的五个环节

5.1 你如何准确描述需求？Agent 的上限是人给它的上下文质量

这是整个流程里最反直觉的一点：Agent 生成代码的质量，在更大程度上取决于“你对问题描述得有多清楚”，而不是“模型有多强”。

很多工程师使用 Agent 时，给的指令是“修复这个 bug”“实现这个功能”，然后期待 Agent 自己把事情全办好。如果 issue 本身只有一句话，而且没有上下文，Agent 只能猜测，猜错之后还要经过多轮修改才能逼近正确答案。

更有效的方式是提供结构化上下文：

• 问题复现步骤
• 期望行为和当前行为的差异
• 涉及的模块或文件
• 相关日志或报错信息
• 参照的历史 PR

这是很多人忽略的一点：给 Agent 写上下文，就像给新同事做背景说明。你输入的信息质量，直接决定输出质量。

5.2 测试覆盖率不够时，Agent 只能盲改

Agent 的修复依赖于测试反馈。如果一个仓库几乎没有测试，Agent 改完代码就失去了“什么是正确行为”的锚点，它只能看着代码结构猜。

没有测试保护的情况下，Agent 生成的代码非常容易出现“看起来合理，但破坏了既有行为”的问题。

所以复现 Uber 类效果，一个硬性前置条件就是：核心模块必须有可运行的测试。没有测试，就不要让 Agent 大规模提 PR。

5.3 评审流程不能只保留“代码对错”，还要保留“需求意图”

如果团队把 PR 评审简化为“CI 过了就合”，那么 Agent 的高产会变成一种诅咒。因为 CI 只验证了代码在已有测试下能跑，并没有验证它是否解决了真实业务问题。

一个合理的评审流程应该同时检查：

• 代码是否符合需求意图
• 边界条件是否考虑完整
• 是否引入不必要的复杂度
• 性能、安全、兼容性是否受影响
• 是否包含合理的测试

换句话说，Agent 接手“写”的部分后，人的责任不是变轻了，而是转移到更稀有的判断力上。

5.4 Agent 会引入依赖，但谁会负责审计依赖？

这是一个在生成式编程里特别容易被忽略的问题。

Agent 在写代码时，可能会顺手引入一个第三方库，或者建议修改依赖版本。如果评审人没有仔细审计，这类变更可能被合并进代码库。长期下来，依赖增长会变成安全隐患和维护负担。

建议在 Agent 生成 PR 时，额外标注依赖变更，并要求 Agent 说明引入依赖的理由。这样评审人可以快速判断：“这个依赖真的有必要吗？有没有更轻量或更成熟的替代？”

5.5 日志、追踪和可观测性，是 Agent 系统自身的必需品

当 Agent 开始大规模提 PR 时，你还需要一套“Agent 行为日志系统”。也就是说，你不仅要记录“Agent 最终提交了什么”，还要记录“Agent 做了哪些尝试、为什么选了这个方案、修改了哪些文件、跑过哪些命令”。

这不是为了监控员工，而是为了排查问题。当某个 Agent 生成的 PR 在线上出问题时，如果没有完整日志，你根本不知道这个 PR 是怎么一步步变成这样的。传统开发里，你可以问工程师当时的思路；Agent 不会主动告诉你，只能靠日志回溯。

所以 Agent 系统的可观测性，和业务系统的可观测性一样重要。这一点真正落地时最容易被忽略。

6. 什么样的团队适合引入 Agent 提 PR

6.1 适合先动手的团队

• 仓库测试覆盖率高，CI 反馈速度快
• 代码风格统一，模块边界清晰
• 团队已经有 Code Review 文化和明确合并规范
• 对 AI 工具成本有预算意识和观测手段
• 工程师愿意花时间写清晰的 issue 描述

这类团队接入 Agent 的收益会非常明显，因为它原本的工程基础已经足够扎实，Agent 只是把已有流程里的重复劳动替代掉。

6.2 不适合急着上 Agent 的团队

• 仓库混乱，大量复制粘贴代码
• 几乎没有测试，CI 很慢
• 评审流程形同虚设，合并前没人认真看代码
• 预算不清楚，成本不可控
• 工程师不愿改变工作习惯，把 Agent 产出当免责声明

这些情况下，Agent 不但不会提升效率，反而会制造更多隐藏债务。你会得到一个看起来很高产、实际上需要大量返工的代码生成机器。

6.3 一个可参考的渐进路线

如果团队想验证 Agent 提 PR 的适配度，建议不要一开始就铺开全仓库，而是按下面的步骤推进：

1. 选一个模块边界清晰、测试覆盖良好的中等模块。
2. 先让 Agent 只负责“生成初始 diff”，人工接手后续所有工作。
3. 记录 Agent 生成的 diff 有多少进入最终 PR，多少被重写。
4. 确认流程稳定后，再让 Agent 参与修复测试和响应简单评审意见。
5. 逐步扩大仓库范围，同时建立成本预算和权限控制。
6. 稳定运行一个季度后，再评估是否适合更大规模接入。

这个路线的核心逻辑是：先验证“可用”，再验证“可控”，最后才验证“可放大”。如果第一步可用性都达不到，后续所有东西都无从谈起。

7. 踩坑清单：如果做不好，这五个问题会集体爆发

我把最常见的五个坑放在这里，按严重程度排序。

7.1 权限失控

Agent 拥有过高权限，执行了不该执行的命令，或者修改了不该修改的文件，甚至影响生产环境。

这是最严重的一类问题。解决方式只有一个：权限最小化。给 Agent 独立的服务账号，限定仓库、分支、命令和文件路径，禁止无差别写操作。

7.2 成本失控

Agent 在某个复杂任务上陷入多轮失败循环，Token 消耗暴涨，甚至一夜之间烧掉一个月的预算。

解决方式：每个任务都设置单次 Token 上限，超时自动终止，并通知负责人介入。

7.3 评审退化为“看绿灯”

CI 通过就被合并，导致很多符合测试但不符合意图的代码流入主干。

解决方式：把评审重点放在需求意图、边界条件、依赖引入和安全隐患上，而不是只关注测试是否通过。

7.4 上下文质量被忽视

issue 描述模模糊糊，Agent 只能靠猜，产出质量自然不会高。团队把锅扣到“Agent 不好用”上，却忘了输入信息散乱。

解决方式：建立统一的 issue 书写模板，明确包含复现步骤、期望行为、涉及文件和验收标准。

7.5 没有 Agent 行为日志

Agent 出了错，整个团队不知道它是怎么得出这个结论的，无法复盘。

解决方式：从一开始就记录 Agent 的每次命令、每次文件和每次决策路径，并建立查看和审计界面。

提醒一句：如果你现在团队连“人工 PR 评审”都做得不够好，那引入 Agent 只会把问题放大，而不是解决。

8. 从 Uber 案例里真正可以带走的方法论

8.1 效率来自工程系统，而不是单一模型

Uber 这个案例里最容易误导人的地方是：让人觉得只要选对模型，就能实现 70% 的 PR 接管率。

真正起作用的是一整套系统：高质量仓库、快速 CI、清晰权限、成本控制、人工评审规范、issue 质量规范、Agent 行为日志。模型只是其中一个环节。

打个比方：一个厨师的厨艺再高，如果厨房没有稳定供气、没有干净的台面、没有新鲜的食材、没有明确的菜品要求，他也做不出稳定好菜。

8.2 AI Agent 的落地路径：先清理河道，再放水

所以我的判断是：Agent 提 PR 的落地路径，不是“先让 Agent 跑起来，再看看哪里要修”，而是“先把工程基础补齐，再让 Agent 在好环境里跑”。

这一步顺序很关键。反过来做的团队，大概率会得出“Agent 代码质量不行”的结论。但真实原因往往是仓库和流程没有给 Agent 搭好跑道。

8.3 每个团队都应该有自己的“AI 账单零增长”

这个目标不一定意味着“完全不花钱”，而更接近：让 AI 成本和业务产出成比例，而不是失控。

• 如果你每月花 1000 元，换来 100 个可合并 PR，那这个成本就是合理的。
• 如果每月花 3000 元，还是只有 100 个可合并 PR，那就需要反思调用策略了。

建议每个团队都建立一个简单的看板：当月 AI 支出、Agent 生成 PR 数量、被合并 PR 数量、被丢弃或返工 PR 数量、线上问题占比。用这些指标来调整 Agent 策略，而不是拍脑袋决定“要不要用 Agent”。

8.4 最后说回工程师个体的位置

当 Agent 接管 70% 的 PR 初稿工作时，工程师的核心竞争力并不会消失，只是发生了转移。

过去拼的是“谁写代码快”，以后拼的是“谁能把需求拆清楚、谁能判断代码是否真的正确、谁能设计出 Agent 改不坏的架构、谁知道什么时候不该让 Agent 动手”。

这不是威胁。对一个有经验的开发者来说，反而是机会——因为你终于可以把时间从重复劳动里拿出来，去做那些模型做不了的事情。

9. 一个简单的自检框架，决定你该不该让 Agent 大规模提 PR

最后给一个可以直接拿去用的自检清单。每一项如果做不到，都建议先补课再上 Agent。

如果这七项里超过三项不达标，那我的建议非常明确：先不要急着铺开 Agent，先把这些基础补上。

越是想让 Agent 高效工作，越要先解决“环境是否允许 Agent 高效工作”的问题。

这个案例真正值得记住的其实是这句话：Agent 不是替代工程师的魔法，而是让工程系统效率上一个台阶的杠杆。杠杆能不能撬动东西，取决于你给它架在什么支点上。