这次我们来看 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_factorylist) acceptance_criteria: List[str] field(default_factorylist) dependencies: List[str] field(default_factorylist) output_path: Optional[str] None # 示例任务 task CodingTask( task_idTASK-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_pathsrc/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, jsonpayload, timeout120, ) 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, jsonpayload, timeout60, ) 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_idfTASK-{i:03d}, titlef任务 {i}, descriptionf实现第 {i} 个模块的基础逻辑。, related_files[fsrc/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_workers4) 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 时这篇能作为第一份参考清单。 Uber AI原生SDLC实践：70%代码由Agent生成背后的工程体系
这次我们来看 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_factorylist) acceptance_criteria: List[str] field(default_factorylist) dependencies: List[str] field(default_factorylist) output_path: Optional[str] None # 示例任务 task CodingTask( task_idTASK-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_pathsrc/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, jsonpayload, timeout120, ) 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, jsonpayload, timeout60, ) 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_idfTASK-{i:03d}, titlef任务 {i}, descriptionf实现第 {i} 个模块的基础逻辑。, related_files[fsrc/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_workers4) 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 时这篇能作为第一份参考清单。