这次我们来看 Uber 在 AI 工程实践上的一个公开分享：70% 的代码由 Agent 生成。这个数字在 2025 年的 AI 辅助编程浪潮里不算最激进，但放在 Uber 这种体量的工程团队里，意义完全不同。它不是实验室里跑通一个 Demo，而是把 AI Agent 嵌进了大规模软件交付的 SDLC（软件开发生命周期）流程，让代码生成、代码审查、测试、发布这些环节真正跑成了一条流水线。
这篇文章不聊概念，直接拆三件事：Uber 是怎么把 Agent 放进 SDLC 的、这套架构里每个环节解决什么问题、以及普通团队能借鉴哪些工程化做法。如果你正在做 Agent 开发、AI 编程工具选型，或者想把 AI 辅助编码从“个人提效”升级成“团队流程”，这篇值得完整看一遍。
1. 核心能力速览
先给一张速览表，把 Uber 这套 AI 原生 SDLC 的关键维度说清楚。
| 维度 | 说明 |
|---|---|
| 项目类型 | 企业级 AI 工程实践，AI Agent 驱动的软件交付流程 |
| 核心指标 | 约 70% 的代码由 Agent 生成，开发者负责审查与指导 |
| 关键环节 | 需求拆解、代码生成、代码审查、测试编写、缺陷修复、发布辅助 |
| 技术基础 | LLM、代码生成 Agent、IDE 插件、CI/CD 流水线集成 |
| 流程改造重点 | 从“人写代码机器跑”变为“人指导 Agent 写代码，人审查代码” |
| 上手门槛 | 需要团队有 AI 工具链基建，同时对代码质量和安全有强管控 |
| 适用场景 | 中大型研发团队、有 CI/CD 基础、愿意改造开发流程的组织 |
| 不适合场景 | 一次性 Demo、无代码审查体系的小项目、对生成代码无约束的团队 |
需要明确一点：Uber 的 70% 是特定团队、特定时间段内的数据，不代表所有业务线都一样。更稳妥的理解是，他们已经把 AI Agent 作为软件交付的一等公民，而不是偶尔用一下的辅助工具。这套架构的核心不是“让 Agent 多写代码”，而是“让 Agent 写代码这件事变得可控、可测量、可回滚”。
2. 为什么 Uber 敢把 70% 代码交给 Agent
先回答一个最直接的问题：70% 的代码生成率，为什么没有把代码库搞乱？Uber 敢这么做，不是靠某个单一模型的能力，而是靠一整套工程约束。
2.1 代码生成不是终点，审查才是关键
在传统开发流程里，代码提交后也有 Review，但 Review 主要看逻辑对不对、风格好不好。在 AI 原生 SDLC 里，Review 的权重被大幅放大。因为 Agent 生成的代码可以做到语法正确、风格统一，但业务语义是否正确、边界条件是否覆盖、安全问题是否引入，这些必须由人来判断。
所以 Uber 的模式本质上是把开发者的工作重心从“写代码”平移到了“审查和指导”。开发者的日常变成了：给 Agent 清晰的任务描述、审查 Agent 生成的 diff、指出问题让 Agent 修复、合并前做最终确认。这套模式能不能成立，取决于团队是否愿意接受这种角色转变。
2.2 小步快跑，频繁提交
Agent 生成代码如果一次性产出上千行，审查负担会非常大。Uber 的做法更接近小步快跑：把需求拆细，让 Agent 按小块生成代码，每次提交的 diff 控制在可审查的范围内。这样既降低单次审查压力，也能在早期发现问题，避免把错误一路带到集成阶段。
2.3 质量门禁和自动化测试兜底
代码审查靠人，但人不可能盯住每个细节。Uber 的流水线里，自动化测试、静态分析、安全扫描这些质量门禁一个都没省。Agent 生成的代码必须通过同样的质量检查才能合并，不存在“因为是 AI 写的所以放宽标准”这种说法。
2.4 可回滚、可观测
只要代码进入版本控制，每一次变更都有记录，出了问题可以快速回滚。这套机制和 AI 无关，但恰恰是它让团队有信心把生成比例提上去。AI 生成代码只是把生产环节前移，质量保障、回滚机制、日志监控依然是整个体系的底座。
3. AI 原生 SDLC 的整体架构
从公开分享的信息来看，Uber 的 AI 原生 SDLC 可以理解为一个分层架构，每一层解决不同的问题。下面给出一套通用的架构参考，企业团队可以按这个思路设计自己的流水线。
| 层级 | 职责 | 参与方 |
|---|---|---|
| 需求层 | 把自然语言需求拆成可执行任务 | 产品经理、开发者、Agent |
| 开发层 | 代码生成、代码补全、重构、单测生成 | Agent、IDE 插件 |
| 质量层 | 代码审查、静态分析、安全扫描、测试执行 | 开发者、CI 系统、Agent |
| 发布层 | 构建、部署、监控、回滚 | CI/CD 平台、监控系统 |
| 数据层 | 代码库索引、埋点、反馈收集、模型迭代 | 数据平台、ML 团队 |
这五层不是孤立存在的。最关键的连接点是：Agent 在开发层生成的代码，必须流向质量层接受检查；质量层的审查结果又回流到 Agent，形成修正循环；最终通过的数据再进入发布层。每一次交互产生的新数据，又被数据层收集起来，用来优化后续的代码生成质量。
从材料来看，Uber 这套系统的核心逻辑不是“某个模型特别强”，而是“让每个环节的产出都能被下一个环节校验”。代码生成可以靠模型，但代码能不能合并、能不能发布，依然由工程体系说了算。
4. Agent 在 SDLC 各阶段的工作方式
下面具体拆解 Agent 在软件交付流程的各个阶段都做了什么。这部分不仅适用于 Uber 的实践，也适合作为团队设计 Agent 工作流的参考。
4.1 需求拆解与任务规划
传统模式下，需求拆分是开发者的工作。在 AI 原生 SDLC 里，Agent 可以辅助把一段需求描述拆成若干子任务，每个子任务包含：
- 任务目标：用一句话说明这段代码要完成什么。
- 输入输出：明确函数签名、数据结构、接口协议。
- 约束条件：代码风格、依赖限制、性能要求。
- 验收标准：什么情况下这段代码算写完。
这个阶段的目标是让后续的代码生成有据可依。任务描述越清晰，Agent 生成代码的准确率越高。如果需求本身就是模糊的，Agent 生成的结果大概率也不会靠谱。
4.2 代码生成
代码生成是 Agent 最核心的产出环节。在这个阶段，Agent 会参考代码库中的既有模式、依赖库的用法、团队规定的代码风格，生成符合约束的代码片段或完整文件。
这里有几点工程化的关键：
第一，Agent 需要能访问代码库索引。如果 Agent 不理解项目的目录结构、依赖关系、已有接口，它生成的代码很难融入现有工程。Uber 的做法是通过代码库索引让 Agent 知道“这个项目里已经有什么、应该复用什么”。
第二，提示词工程不只是写 Prompt。对代码生成 Agent 来说，提示词往往是一个结构化的任务说明，包含背景信息、相关文件路径、依赖约束和验收标准。把任务信息组织好，比堆砌“请生成高质量代码”这种空话有用得多。
第三，生成结果的格式要规范。Agent 返回的代码需要能被 IDE 插件正确解析、形成 diff、进入审查流程。这里的难点是格式统一和集成稳定，而不是模型本身的生成能力。
4.3 代码审查
代码审查是 AI 原生 SDLC 里最值得投入的环节。Agent 生成的代码不能直接合入主干，必须经过一轮或多轮审查。审查内容包括：
- 逻辑正确性：代码是否实现了需求描述的功能。
- 边界情况：空值、异常、并发、超时等场景是否处理。
- 代码风格：是否符合团队规范，命名是否清晰。
- 安全问题：是否存在注入、越权、敏感信息泄露等风险。
- 性能问题：是否有明显的性能瓶颈或不合理的数据结构使用。
Uber 这套流程里，审查者可以是人，也可以是带审查能力的 Agent。比较合理的做法是：先由自动化工具做静态扫描，再由开发者做语义层面的审查，遇到问题把修改意见反馈给生成代码的 Agent，让 Agent 修正后重新提交。
4.4 测试生成与执行
Agent 写功能代码的同时，还要生成对应的单元测试和集成测试。测试用例的覆盖范围直接影响代码合并的信心。Uber 的实践里，测试代码同样是 Agent 生成、人来补充关键场景。
这个环节可以观察三个指标：测试覆盖率是否达到团队标准、关键业务路径有没有测试覆盖、失败用例是否被正确归因。如果 Agent 生成的测试大量失败，首先要看的不是测试本身，而是功能代码是否满足需求——也就是说，失败的测试是发现问题的信号，而不是修复对象。
4.5 缺陷修复
当测试失败或代码审查发现问题时，Agent 会根据错误信息、堆栈日志、测试失败输出，尝试定位并修复代码。这个环节对 Agent 的要求最高，因为它需要：
- 理解错误信息背后的原因。
- 找到相关的代码文件。
- 设计合理的修复方案。
- 重新生成代码并通过测试。
从工程角度看，缺陷修复环的闭环程度决定了整套系统能不能长期运转。如果每次修复都需要人工介入，效率会被严重拖慢。Uber 的做法是把修复过程中产生的数据收集起来，形成“失败案例库”，持续用于后续 Agent 的调优。
4.6 发布辅助
代码合并之后，Agent 还能参与发布环节。比如辅助生成变更日志、分析发布影响范围、基于历史数据判断此次变更的风险等级。这部分工作相对轻量，但能让 AI 的覆盖面从开发阶段延伸到交付阶段。
5. 工程化落地的关键基础设施
要把 Agent 从“能写代码”变成“能稳定交付代码”，还需要几个关键的基础设施。下面这些内容来自 Uber 公开实践中可以推导出来的工程要求，也符合行业里做 AI 代码生成平台的一般规律。
5.1 代码库索引与上下文检索
Agent 要生成符合项目现状的代码，前提是理解项目现状。代码库索引要做的事包括：
- 解析仓库结构，记录文件和目录之间的关系。
- 索引函数、类、接口、依赖，形成语义层面的知识库。
- 为 Agent 提供“给定一个任务，应该看哪些文件”的检索能力。
没有这层基础设施，Agent 只能靠提示词里写的上下文拼凑答案，效果很不稳定。这也是很多团队接入 AI 编程工具后觉得“生成的代码能跑但不匹配项目风格”的主要原因。
5.2 Agent 执行沙箱
Agent 在本地生成代码是一回事，在云端沙箱里自动执行又是另一回事。Uber 这种体量的公司不可能让 Agent 在开发者的工作机上随意跑命令，所以 Agent 执行环境必须被隔离。
沙箱里要做的事包括：
- 隔离文件系统，避免 Agent 修改非相关代码。
- 控制网络访问，防止 Agent 在运行过程中触发不安全的网络请求。
- 限制资源消耗，避免 Agent 占满 CPU 或产生超大输出。
- 记录执行日志，方便事后审计和问题定位。
5.3 质量评估体系
要回答“Agent 写的代码到底行不行”，不能靠感觉，需要一组可量化的指标。Uber 这套体系里，评估维度通常包括：
| 指标 | 说明 |
|---|---|
| 生成通过率 | Agent 生成的代码一次通过测试的比例 |
| 审查反馈率 | 每轮提交被审查者要求修改的比例 |
| 缺陷密度 | 合并后每千行代码发现的缺陷数 |
| 合并耗时 | 从提交到合并的平均时间 |
| 回滚率 | 因代码质量问题触发回滚的比例 |
这些指标要按团队、按项目、按 Agent 版本分别统计，才能看出改动是变好了还是变差了。
5.4 数据飞轮
AI 原生 SDLC 和普通 AI 工具最大的区别在于数据闭环。每一次代码生成、审查意见、修复结果、合并决策，都是可以用来优化后续生成的训练数据或评测数据。
实际落地时不需要一上来就追求训练专属模型，更可行的做法是：先把“什么样的输入产出了什么样的输出、最终是否被接受”记录下来，积累一段时间后，用这些数据做提示词优化、模型微调或评估集构建。数据飞轮转起来之后，整个系统的质量提升会越来越快。
6. 可参考的 Agent 工作流代码示例
下面给出一套通用的 Agent 工作流代码示例。注意：这不是 Uber 内部代码，而是根据公开的 AI 原生 SDLC 思路整理的可参考模板，实际使用时需要按项目情况替换路径、接口和模型服务。
6.1 任务定义示例
from dataclasses import dataclass, field from typing import List, Optional @dataclass class CodingTask: """一个可交给 Agent 完成的编码任务""" task_id: str title: str description: str related_files: List[str] = field(default_factory=list) acceptance_criteria: List[str] = field(default_factory=list) dependencies: List[str] = field(default_factory=list) output_path: Optional[str] = None # 示例任务 task = CodingTask( task_id="TASK-001", title="实现订单金额计算函数", description="实现 calculate_order_amount 函数，根据订单项和优惠券计算最终应付金额。", related_files=[ "src/order/models.py", "src/order/services.py", "tests/order/test_services.py", ], acceptance_criteria=[ "金额计算精确到分", "支持满减优惠券", "订单项为空时返回 0", "优惠券不能叠加使用", ], output_path="src/order/services.py", )6.2 Agent 生成与审查流程示例
import requests import json # 假设你有一个代码生成 Agent 服务 AGENT_API_URL = "http://127.0.0.1:8080/api/generate" REVIEW_API_URL = "http://127.0.0.1:8080/api/review" def send_task_to_agent(task: CodingTask) -> dict: """把任务发送给代码生成 Agent""" payload = { "task_id": task.task_id, "title": task.title, "description": task.description, "related_files": task.related_files, "acceptance_criteria": task.acceptance_criteria, } response = requests.post( AGENT_API_URL, json=payload, timeout=120, ) response.raise_for_status() return response.json() def run_auto_review(generated_code: str, related_files: list) -> dict: """对生成代码做自动化审查""" payload = { "code": generated_code, "context_files": related_files, } response = requests.post( REVIEW_API_URL, json=payload, timeout=60, ) response.raise_for_status() return response.json() # 主流程 if __name__ == "__main__": result = send_task_to_agent(task) generated = result.get("generated_code", "") print("Agent 生成代码，长度：", len(generated)) review_result = run_auto_review(generated, task.related_files) if review_result.get("approved"): print("自动审查通过，可以进入人工复审") else: print("自动审查未通过，需要返回 Agent 修复") print("审查意见：", review_result.get("comments"))6.3 批量任务示例
from concurrent.futures import ThreadPoolExecutor, as_completed task_list = [ CodingTask( task_id=f"TASK-{i:03d}", title=f"任务 {i}", description=f"实现第 {i} 个模块的基础逻辑。", related_files=[f"src/module_{i}/service.py"], acceptance_criteria=["通过现有测试用例"], ) for i in range(1, 20) ] def handle_task(t: CodingTask) -> dict: """单个任务处理入口，包含生成和审查""" result = send_task_to_agent(t) review = run_auto_review(result.get("generated_code", ""), t.related_files) return { "task_id": t.task_id, "generated_length": len(result.get("generated_code", "")), "approved": review.get("approved"), "comments": review.get("comments"), } # 批量执行，控制并发数 with ThreadPoolExecutor(max_workers=4) as executor: futures = [executor.submit(handle_task, t) for t in task_list] for future in as_completed(futures): print(future.result())这段代码演示的是一个典型的“批量任务加审查反馈”闭环：先把任务队列交给 Agent，再对生成结果做自动审查，每批次执行完记录结果。实际接入 Uber 风格的流程时，这里还要加上测试执行、静态分析、数据入库等步骤。
7. 资源占用与性能观察
AI 原生 SDLC 的资源占用和传统开发流程完全不同。这里不涉及某个具体模型的显存数字，而是讲这类系统在落地时最值得关注的性能维度。
7.1 代码生成服务的响应延迟
代码生成服务如果要嵌入 IDE 或 CI 流程，响应延迟直接决定开发者体验。如果一次生成要等 30 秒以上，开发者很难接受。观察这个指标时重点关注：
- 生成请求的平均响应时间。
- 长代码生成场景下的尾延迟。
- 并发请求数增加时，响应时间是否线性劣化。
7.2 批量任务吞吐量
批量任务场景下，吞吐量比单次延迟更重要。比如一次性给 100 个子任务，系统能在多长时间内完成，是所有任务都开始排队还是并发执行，单任务的失败是否会阻塞后续任务。这些都是批量任务设计时要回答的问题。
7.3 上下文构建的耗时
代码生成 Agent 在拿到任务后，需要先检索相关代码文件，构建上下文，再调用模型生成。上下文构建这部分往往比模型推理更耗时。如果检索逻辑写得不好，可能 70% 的时间花在找文件上。
一个可行的优化方向是给代码库索引做预计算，把检索阶段从“任务进来再查”变成“定时更新索引、任务进来直接取”。这是工程层面的优化，和模型能力无关，但对整体体验的提升非常明显。
7.4 任务队列与失败重试
批量任务一多，必须引入任务队列。队列至少要做到：
- 失败任务自动重试，并限制重试次数。
- 每个任务的状态可查询，方便定位卡住的任务。
- 队列长度和吞吐量有监控，避免任务积压。
{ "queue": { "max_retry": 3, "timeout_seconds": 300, "concurrency": 4, "monitor_interval": 30 }, "task_status": [ "pending", "running", "succeeded", "failed", "retrying" ] }8. 常见问题与排查方法
Uber 这套模式听起来高效，但落地时会有不少坑。下面把常见问题整理成排查表，供团队参考。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| Agent 生成代码无法通过测试 | 任务描述不清晰或验收标准缺失 | 检查任务定义，确认验收条件是否明确 | 补充验收标准和输入输出示例 |
| 代码生成响应很慢 | 上下文检索耗时过长或模型服务负载过高 | 查看链路耗时分布；观察模型服务吞吐 | 优化检索逻辑；增加模型服务实例 |
| Agent 生成代码风格不一致 | 没有注入团队代码风格规范 | 检查提示词是否包含风格约束 | 在提示词中加入代码风格说明 |
| 自动审查频繁误报 | 审查规则过于严格 | 查看误报样本，调整规则 | 按样本迭代审查规则 |
| 批量任务执行中途卡住 | 单个任务超时无处理 | 检查队列状态和日志 | 为任务设置超时和失败重试 |
| 生成代码存在安全问题 | 模型未感知安全约束 | 检查安全扫描结果 | 引入安全扫描工具，在生成阶段加入安全要求 |
| 合并后质量下降 | 审查流程流于形式 | 对比合并前后缺陷率 | 加强人工审查比例，增加发布门禁 |
| 项目知识缺乏，生成结果偏差大 | 代码库索引未建立或未更新 | 检查索引覆盖率和更新时间 | 建立并定期更新代码库索引 |
| 开发者只信 Agent 不审代码 | 流程设计问题 | 观察合并记录中人工批准占比 | 明确人审是硬性要求 |
| 数据飞轮未转起来 | 生成日志和审查结果未记录 | 检查埋点和数据存储 | 建立数据回传机制 |
这十个问题基本覆盖了 AI 原生 SDLC 从搭建到稳定运行的常见卡点。最核心的一条：不要期待 Agent 一步到位，流程设计的重点始终是“发现问题 -> 反馈给 Agent -> 修正 -> 重新验证”这个循环能不能转起来。
9. 适合哪些团队参考
Uber 的实践不适合所有团队。如果把“70% 代码由 Agent 生成”当成一个可以直接复制的数字，大概率会踩坑。下面按团队类型给出参考建议。
9.1 适合参考的团队
- 有一定工程化基础，CI/CD 和代码审查已经跑得很顺的团队。
- 愿意在流程上投入，而不是只想“开个账号让 AI 帮我写代码”的团队。
- 有专门的人可以做代码库索引、提示词管理、评估系统建设的团队。
- 业务规模足够大，批量任务能体现出效率红利的团队。
9.2 不建议盲目跟风的团队
- 代码审查体系薄弱，合并代码基本不 Review 的团队。
- 需求描述本身不规范的团队，Agent 拿到模糊任务只会生成更模糊的代码。
- 没有自动化测试兜底的团队，Agent 生成代码的质量无人把关。
- 把 AI 生成率当成 KPI，要求所有团队都达到某个百分比的组织。
第 4 条尤其重要。如果团队把“AI 生成代码占比”作为唯一指标，开发者会为了让数字好看而让 Agent 生成大量低质量代码，最终反而拖垮交付效率。合理的评估方式应该综合看缺陷率、合并耗时、回滚率这些质量维度。
9.3 推荐的落地路线
想从零开始搭一套 AI 原生 SDLC，比较稳妥的路线是分四步走：
- 先选一个质量要求中等、代码结构清晰的业务模块做试点。
- 把代码库索引建好，让 Agent 能理解项目现状。
- 从“单文件生成 + 人工审查”开始，跑通最小闭环。
- 统计生成通过率和缺陷率，确认质量稳定后再扩大范围。
Uber 能到 70%，也是一步步迭代出来的，不是直接换了一套工具就立刻见效。
10. 总结与下一步
Uber 的 AI 原生 SDLC 实践，最值得关注的不是“70% 代码由 Agent 生成”这个数字，而是它背后完整的工程体系。这个体系的本质是：Agent 进入软件交付流程后，每一个环节都有人或工具在做校验，代码生成、审查、测试、发布被串成了一条可观测、可回滚、可迭代的流水线。
如果你想在自己的团队里应用这套思路，最先要验证的不是代码生成模型的能力，而是你现有的工程基础设施能不能支撑这套流程。具体来说，先做好三件事：
- 把代码库索引和上下文检索搭起来，这是 Agent 生成有效代码的前提。
- 把代码审查和自动化测试做成硬性门禁，不管代码是 AI 写的还是人写的都必须过。
- 把每次生成、审查、修复的数据记录下来，让数据飞轮先转起来。
最容易踩的坑是把“AI 生成代码占比”当成核心 KPI，忽略质量闭环。更合理的目标是：用 Agent 缩短从需求到合并的周期，同时保证缺陷率和回滚率不劣化。当这两点同时成立，70% 这样的数字才真正有意义。
后续可以继续扩展的方向包括：把多模态能力引入需求文档解析、基于生成历史做个性化模型微调、以及把 Agent 从代码开发延伸到架构设计和系统运维。Uber 的实践只是一个起点，AI 原生的软件工程正在从“辅助编码”走向“全流程智能交付”，而这个方向值得每一个工程团队持续关注。
建议收藏备用，等你的团队准备开始搭建 AI 原生 SDLC 时，这篇能作为第一份参考清单。
