2025 年如果你还在纠结“AI 能不能写代码”很可能已经落后了一个身位。真正值得关注的已经不是“AI 能不能写”而是“AI 写的代码怎么安全地进入生产环境”。Uber 在公开技术分享中提到其软件工程团队已经有约 70% 的代码由 Agent 生成这个数字在传统大型互联网公司里相当激进。很多人第一反应是“那程序员是不是要失业了”但如果你深入看它背后的 SDLC 架构调整会发现结论完全相反AI Agent 并没有取代工程师它正在把工程师从“写代码的人”变成“定义问题和验收结果的人”。这篇文章我想抛开“AI 编程工具测评”这种表层话题直接拆解 Uber 这类大厂在推行 AI Agent 编码时真正在做的工程化改造。你会看到Agent 生成代码不是简单地给 IDE 装一个插件而是需要重构整个软件开发生命周期包括需求拆解、代码评审、测试门禁、部署验证和线上监控。文章会从这几个角度展开先讲清楚 70% 这个数字背后的判断然后解释 SDLC 架构发生了什么变化接着用三个可落地的代码示例演示 Agent 编程的工程化思路最后给出实践中最容易踩的坑和我的建议。如果你正在团队里推 AI 辅助开发或者想理解 AI Agent 开发到底是什么这篇文章应该能给你一个比“AI 很强大”更具体的答案。1. 70% 代码由 Agent 生成这不是替代开发者而是重构工程流程先把这个数字拆开看。70% 代码由 Agent 生成并不意味着 70% 的代码不需要人管。恰恰相反它意味着代码的生产方式从“人工逐行编写”变成了“人机协作的流水线生产”。在 Uber 对外分享的工程实践中这个比例背后是一整套工程机制Agent 负责生成初稿代码工程师负责拆解任务、审查逻辑、补充边界条件、验收测试结果。这里真正值得关注的变化是代码产生的“瓶颈”变了。传统开发流程里一个需求的交付速度受限于工程师的编码速度。你懂业务、懂架构、懂测试但你一天能写的有效代码量是有上限的。引入 Agent 之后编码这个环节被大幅压缩瓶颈转移到了两个新地方一是需求描述的质量二是代码评审和验证的能力。换句话说过去团队里最稀缺的能力是“写得快”现在最稀缺的能力变成了“把需求讲清楚”和“快速判断代码对不对”。这其实是对工程师能力模型的一次重构。还有一个容易误读的点70% 不是“一次生成直接可用”的比例。从 Uber 的实践看Agent 生成代码之后工程师仍然需要做代码审查、跑测试、修复问题。真正重要的是这些代码生成的“初稿质量”已经足够高能让工程师把精力集中在系统设计、异常处理和业务逻辑验证上而不是纠结语法和模板代码。所以如果你们团队也想推行 AI Agent 开发第一个要调整的不是工具而是流程认知Agent 是给工程师配的“高产出初级工程师”不是替代架构师的“自动驾驶”。2. SDLC 基础概念AI Agent 重新定义了哪些环节SDLC 是 Software Development Life Cycle 的缩写也就是软件开发生命周期。传统上它包含需求分析、系统设计、编码实现、测试验证、部署发布和运维监控这几个阶段。很多团队引入 AI 的方式是只在“编码实现”这一环加一个 AI 插件这恰恰是最容易失败的做法。从 Uber 这类大厂的实践看AI Agent 真正产生价值是它被嵌入到了 SDLC 的每一个环节里。我整理了一张对比表你可以直观看到变化SDLC 阶段传统方式引入 AI Agent 后工程师的核心工作需求分析产品经理写 PRD人工拆解任务Agent 辅助拆解用户故事生成验收标准初稿确认需求边界补充隐含约束系统设计架构师画图、写设计文档Agent 根据历史代码和架构规范生成设计草案审查方案决定技术选型编码实现工程师逐行手写Agent 按任务描述生成代码工程师审查修改拆解任务、编写高质量提示词、审查逻辑测试验证测试人员手工设计用例Agent 自动生成单元测试和集成测试初稿补充边界用例确认覆盖率部署发布人工执行发布流程Agent 生成变更说明、检查发布清单评估变更风险决定是否发布运维监控人工分析告警和日志Agent 辅助分析异常生成初步排查报告确认根因制定修复方案注意看最后一列工程师的工作不是消失了而是从“执行者”变成了“决策者和验收者”。这也是我判断 AI Agent 工程化是否成功的一个核心标准如果引入 AI 之后工程师只是从“写代码”变成了“改 AI 生成的烂代码”那说明接入方式出了问题如果工程师能把更多时间花在需求理解、方案设计、风险判断上那才是真正吃到了红利。Uber 能做到 70% 代码由 Agent 生成本质上是因为它在 SDLC 的每个阶段都建立了“Agent 产出、人来验收”的机制。不是某一环强而是整个链路都重构了。3. 从辅助补全到自主编码Agent 的工作原理与核心组件3.1 Agent 与代码补全的本质区别很多人把 AI Agent 和 GitHub Copilot 这类代码补全工具混为一谈。虽然它们底层都用大语言模型但工作方式完全不同。代码补全的核心是“预测下一个 token”。你写一个函数名它帮你补全函数体你写一个 SQL 的开头它帮你补完整条语句。它响应的是你当下的输入几乎没有“任务规划”能力。AI Agent 的核心是“任务执行”。你给它一个目标比如“修复用户登录接口在并发场景下的竞态条件”它会自己拆解步骤先定位相关代码分析并发逻辑生成修复方案修改代码跑测试然后返回结果。整个过程 Agent 可以自主调用工具、读取文件、执行命令而不是只做文本续写。这个差异决定了工程接入方式的不同。代码补全只需要一个编辑器插件Agent 则需要一个能访问代码仓库、能执行命令、能读取测试结果的运行环境。3.2 Agent 的核心组件从实现角度看一个能写代码的 Agent 至少包含这几个组件第一任务规划模块。它决定 Agent 如何把一个复杂目标拆成可执行的子任务。常见的实现方式包括 ReAct 模式推理加行动交替进行和 Plan-and-Execute 模式先制定完整计划再逐步执行。在代码生成场景Plan-and-Execute 更可控因为你可以先审查 Agent 的计划再让它动手。第二工具调用模块。Agent 需要能读取文件、搜索代码、执行测试、查询文档这些能力都通过工具函数暴露给模型。这个机制是 Agent 区别于普通聊天机器人的关键。实际工程中工具不在多而在精一个能精准搜索代码语义的工具比十个花哨但用不上的工具更有价值。第三上下文管理模块。大语言模型的上下文窗口是有限的而一个大型代码仓库可能有数百万行代码。Agent 必须自己决定哪些文件需要读入上下文哪些历史信息可以丢弃。上下文管理能力直接决定了生成代码的质量上限。第四反馈与修正模块。Agent 写完代码后需要能运行测试、根据错误信息修正代码形成“生成—验证—修复”的循环。只生成不验证的 Agent在真实工程里几乎没有使用价值。理解这四个组件你就能看懂后面示例代码的设计思路。我接下来会用最小可运行的代码演示一个代码评审 Agent它的核心就是把“任务规划”和“工具调用”组合起来。4. 为什么大型互联网公司敢让 Agent 写代码质量门禁体系一个很自然的问题是Uber 怎么敢让 AI 写 70% 的代码代码质量不会崩吗答案是正规做法不是让 Agent“写完就上线”而是建立了一套比人工编码更严格的质量门禁体系。这也是我个人认为最值得借鉴的工程经验。所谓质量门禁就是代码从生成到上线每一道关卡都必须通过否则直接打回。在 Uber 的实践中这些门禁包括以下几个方面。代码审查是第一步。Agent 生成的代码必须经过人工 Review这一点没有商量余地。但注意审查的姿势变了过去工程师看代码是逐行读现在更高效的方式是先让一个审查 Agent 做第一轮过滤标记出可疑逻辑、安全风险和风格问题再由工程师做第二轮确认。这样既保证有人工把关又不至于让工程师被大量初稿代码淹没。自动化测试是第二步。Agent 每生成一个功能对应的单元测试和集成测试也需要生成。覆盖率不是唯一指标但覆盖率过低一定不能合入主干。测试的价值在这里不仅是验证功能更是倒逼 Agent 理解代码的运行时行为而不只是生成静态文本。依赖与供应链安全检查是第三步也是最容易被忽视的一步。AI 生成代码有一个隐藏风险它可能会引入你不熟悉的第三方库甚至推荐一些存在漏洞的旧版本依赖。生产环境必须对每次代码变更做依赖漏洞扫描确认没有引入未经安全审查的组件。最后是灰度发布和线上监控。即使前面所有门禁都通过代码进入生产环境时仍然要走灰度发布流程。线上告警、错误率、延迟等指标都要关联到本次变更上一旦出现异常能快速回滚到上一个稳定版本。看到这里你应该明白了70% 不是 AI 的“自由发挥比例”而是“经过完整质量保障流程后仍然能通过的比例”。AI 负责提高代码生产的效率上限工程体系负责守住质量下限。两者缺一不可。5. 实战一个最小可运行的代码评审 Agent理论讲了不少接下来我们落地。我会用一个最小示例演示 Agent 在代码评审场景中的应用。这个示例不需要复杂框架只需要 Python 和一个 LLM API 接口重点展示“任务规划 工具调用 反馈”的思路。5.1 环境准备操作系统Windows / macOS / Linux 均可Python 版本3.9 及以上依赖openai SDK或你所用模型厂商对应的 SDK一个可用的 LLM API Key安装依赖pip install openai5.2 代码实现创建一个文件code_review_agent.py代码如下# 文件路径code_review_agent.py 一个最小可运行的代码评审 Agent 示例。 核心思路接收代码变更内容调用 LLM 生成结构化评审意见。 import json import sys from openai import OpenAI client OpenAI() def build_review_prompt(diff_text: str) - str: 构造评审提示词明确输出格式要求。 return f 你是一名资深代码评审专家。请审查以下代码变更并输出 JSON 格式的评审结果。 要求 1. 只输出确认存在的问题不输出空泛建议。 2. 按严重程度分级BLOCKER阻塞合并、WARNING建议修改、NIT可选优化。 3. 每个问题说明原因并给出修改建议。 4. 如果代码没有明显问题issues 字段返回空数组。 输出格式 {{ summary: 对本段代码变更的总体评价, issues: [ {{ severity: BLOCKER, location: 文件位置或函数名, problem: 问题描述, suggestion: 修改建议 }} ] }} 代码变更内容 diff {diff_text}def review_code(diff_text: str) - dict: 调用 LLM 评审代码解析返回结果。 try: resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: 你是一个严谨的代码评审助手。}, {role: user, content: build_review_prompt(diff_text)}, ], temperature0.2, ) content resp.choices[0].message.content # 兼容模型输出包含代码块标记的情况 content content.strip() if content.startswith(): content content.strip() if content.startswith(json): content content[4:] return json.loads(content) except Exception as e: return { summary: f评审失败{e}, issues: [] }ifname main: # 从命令行参数或标准输入读取 diff 内容 if len(sys.argv) 1: with open(sys.argv[1], r, encodingutf-8) as f: diff_text f.read() else: diff_text sys.stdin.read()result review_code(diff_text) print(json.dumps(result, ensure_asciiFalse, indent2))### 5.3 运行与验证 创建一个示例代码变更文件 example.diff diff --- a/user_service.py b/user_service.py -10,7 10,8 def get_user_profile(user_id): if user_id is None: raise ValueError(user_id cannot be None) user db.query(User).filter(User.id user_id).first() - return user # 增加默认头像逻辑 if user and not user.avatar: user.avatar default_avatar.png return user运行评审命令python code_review_agent.py example.diff预期输出是一段 JSON包含总体评价和问题列表。如果代码没有严重缺陷issues 可能为空数组如果引入了空指针风险或返回值类型变化Agent 应该标记出来。这个示例的核心是“结构化输出 可解析结果”。真实工程里Agent 的结果需要接入 CI 系统所以一定要让模型输出固定格式而不是自由文本。6. 更进一步让 Agent 生成测试用例与 PR 描述代码评审只是 Agent 的一个应用场景。在实际 SDLC 中还有一个投入产出比非常高的场景自动生成单元测试和 PR 描述。我给一个更完整的思路写一个脚本输入一个函数的源码Agent 自动生成 pytest 测试用例。测试用例的逻辑是固定的Agent 在这个场景里表现通常非常稳定。# 文件路径test_case_generator.py 根据函数源码自动生成 pytest 测试用例。 用法python test_case_generator.py def add(a, b): return a b import sys from openai import OpenAI client OpenAI() def generate_test_cases(func_source: str) - str: prompt f 请根据以下 Python 函数源码生成完整的 pytest 测试用例。 要求 1. 覆盖正常输入、边界输入、异常输入。 2. 测试函数命名以 test_ 开头。 3. 只输出 pytest 代码不要额外解释。 4. 使用 assert 断言不使用 print。 函数源码 {func_source} resp client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}], temperature0.2, ) return resp.choices[0].message.content if __name__ __main__: func_code sys.argv[1] tests generate_test_cases(func_code) print(tests)运行示例python test_case_generator.py def divide(a, b): return a / bAgent 会生成类似这样的测试def test_divide_normal(): assert divide(10, 2) 5.0 def test_divide_by_zero_raises(): import pytest with pytest.raises(ZeroDivisionError): divide(1, 0)测试生成的意义不只是省时间它还在倒逼工程团队把“可测试性”作为代码评审的标准之一。如果 Agent 都写不出某个函数的测试说明这个函数的职责可能不单一耦合度可能过高。这其实是 AI 时代一个很有价值的副产品Agent 的“困惑”可以作为代码坏味道的信号。PR 描述生成也值得做。很多工程师觉得写 PR 描述浪费时间但好的 PR 描述能显著降低 Review 成本。只需把 git diff 传给一个 Agent让它按“变更背景、改动内容、影响范围、测试方案”四个维度生成 PR 描述模板再由工程师补充业务背景。这一步在 Uber 的 AI Agent 实践中也是标准化流程。7. 在 CI 中接入 Agent 质量门禁前面说过AI Agent 编码的核心是质量门禁。在真实工程里这个门禁通常落在 CI 流水线中。下面是一个 GitHub Actions 的示例演示如何把代码评审 Agent 和测试覆盖率门禁集成到每次 Pull Request 中。# 文件路径.github/workflows/ai-quality-gate.yml name: AI Code Quality Gate on: pull_request: types: [opened, synchronize] jobs: ai-review: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 - name: Setup Python uses: actions/setup-pythonv5 with: python-version: 3.11 - name: Install dependencies run: | pip install openai pytest pytest-cov - name: Generate diff run: | git diff origin/${{ github.base_ref }}...HEAD pr.diff cat pr.diff - name: Run AI code review env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} run: | python code_review_agent.py pr.diff review_result.json cat review_result.json - name: Run tests with coverage run: | pytest --cov./ --cov-fail-under80 - name: Upload review artifact uses: actions/upload-artifactv4 with: name: review-result path: review_result.json这个流水线做了三件事第一生成当前 PR 的 diff第二调用我们之前写的代码评审 Agent 生成结构化评审结果第三运行测试并强制覆盖率不低于 80%。需要注意这里的覆盖率阈值 80% 只是示例实际标准要看团队的项目类型。另外AI 评审结果目前是作为 artifact 上传更成熟的方案是把它直接提交为 PR 评论。这个可以通过 GitHub API 实现但代码量会显著增加这里只演示核心链路。接入 CI 的核心目的是把“AI 评审 自动化测试”变成强制门禁而不是可选的辅助工具。只有变成流程的一环Agent 生成代码的质量才有制度保障。8. 常见问题与排查思路在 Agent 工程化实践中团队遇到的问题是五花八门的。我按经验整理了一份高频问题清单。问题现象可能原因排查方式解决方案Agent 生成的代码风格和团队规范不一致提示词里没有注入团队编码规范检查 Agent 的上下文是否包含规范文档在提示词中附带 .editorconfig、checkstyle 规则或规范摘要Agent 生成的代码存在安全漏洞模型训练数据中的旧模式被复用运行依赖扫描和 SAST 工具增加依赖漏洞门禁强制安全扫描Agent 生成测试用例时总是套模板提示词约束不够具体检查是否要求了边界条件和异常场景在提示词中显式要求覆盖正常、边界、异常三类情况CI 中调用 LLM API 超时请求体过大或模型响应慢查看调用日志确认上下文 token 数量精简提示词限制 diff 长度增加重试机制Agent 频繁修改到不相关文件任务拆解时缺少文件范围约束检查任务描述是否指定了影响范围在提示词中明确“只允许修改指定目录下的文件”团队对 AI 生成代码信任度低缺乏可审计的生成和评审记录建立 Agent 变更追踪把每次 Agent 生成的任务描述、代码、评审结果存入变更记录还有一个高频问题值得单独说模型输出的 JSON 格式不稳定。很多人会遇到json.loads直接报错因为模型可能输出 Markdown 代码块或者把注释也输出进来。稳健的做法不是抱怨模型而是加一层容错解析先尝试直接解析失败后剥离代码块标记再不行就截取第一个{到最后一个}之间的内容。我在前面的review_code函数里已经演示了这层容错逻辑。另外API Key 的管理也很重要。不要明文写在代码里更不要提交到 Git 仓库。CI 场景应该使用 Secrets本地场景应该使用环境变量。9. 最佳实践接入 AI Agent 编码的工程建议结合前面的分析和示例我给出几条可以直接落地的建议。第一从高频低风险场景切入。不要一上来就让 Agent 改核心交易系统的代码。先从单元测试生成、PR 描述、代码风格修复这类低风险场景开始跑通流程建立信任再逐步扩展到功能开发。第二把提示词当成代码来管理。提示词不是一次性输入它是你和 Agent 之间的接口协议。团队应该有 repo 来管理提示词模板像管理代码一样做版本管理。提示词里应该包含角色定义、任务目标、输入格式、输出格式、约束条件、示例。第三明确 Agent 的权限边界。Agent 能访问哪些仓库、能执行哪些命令、能不能直接提交代码这些都要有明确策略。最小权限原则同样适用于 AI 系统。第四建立“人机协作”的审查流。不要完全相信 Agent也不要完全人工审查所有生成代码。更高效的方式是分层Agent 做第一轮评审筛掉低级问题工程师做第二轮评审聚焦架构和业务逻辑。这能保证质量同时不会成为流程瓶颈。第五关注上下文工程。Agent 生成代码的质量很大程度上取决于你给它的上下文是否充分。建议把需求描述、相关代码文件路径、团队编码规范、依赖清单都纳入上下文。上下文不是越多越好关键是精准。第六保留回滚能力。AI 生成的代码进入生产环境前必须有版本管理和回滚机制。灰度发布和可观测性建设不是可有可无的它们决定了你有多少试错空间。以上每一条都是 UBer 这类大型工程团队实践的核心逻辑Agent 负责提高效率上限工程体系负责守住质量下限。10. 总结与后续学习方向回到最初的问题Uber 70% 代码由 Agent 生成这个数字真正的含义是什么它不是“AI 取代程序员”的证明而是“AI 重构软件工程流程”的注脚。当编码效率不再受限于人手决定交付速度的变成了需求拆解质量、代码审查效率和测试门禁严格程度。工程师的竞争力也从“谁写得快”转向了“谁能把问题定义清楚、谁能设计出可验证的方案”。如果你想在团队里推进 AI Agent 开发我的建议是先在自己的项目里复现本文的最小示例把代码评审 Agent 和测试文件生成跑通。先让 AI 参与一个低风险环节观察它对团队流程的影响再逐步扩大范围。这个过程会让你对 Agent 的能力边界有实感也会让你更清楚哪些环节值得投入、哪些环节必须保留人工决策。下一步可以深入的方向包括Agent 的上下文缓存机制、工具调用的可靠性设计、基于测试反馈的代码修正循环、以及企业内部代码库上的 RAG 检索增强生成。这些内容已经超出了“AI 工具评测”的范畴进入了 AI 工程化的深水区。如果你正在这个方向探索欢迎收藏这篇文章后续我会继续拆解更多实战细节。