企业官网建设流程全解析

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 的每一个环节里。我整理了一张对比表，你可以直观看到变化：

注意看最后一列：工程师的工作不是消失了，而是从“执行者”变成了“决策者和验收者”。

这也是我判断 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 openai

5.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( model="gpt-4o", messages=[ {"role": "system", "content": "你是一个严谨的代码评审助手。"}, {"role": "user", "content": build_review_prompt(diff_text)}, ], temperature=0.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", encoding="utf-8") as f: diff_text = f.read() else: diff_text = sys.stdin.read()

result = review_code(diff_text) print(json.dumps(result, ensure_ascii=False, indent=2))

### 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( model="gpt-4o", messages=[{"role": "user", "content": prompt}], temperature=0.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 / b"

Agent 会生成类似这样的测试：

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/checkout@v4 with: fetch-depth: 0 - name: Setup Python uses: actions/setup-python@v5 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-under=80 - name: Upload review artifact uses: actions/upload-artifact@v4 with: name: review-result path: review_result.json

这个流水线做了三件事：第一，生成当前 PR 的 diff；第二，调用我们之前写的代码评审 Agent 生成结构化评审结果；第三，运行测试并强制覆盖率不低于 80%。

需要注意，这里的覆盖率阈值 80% 只是示例，实际标准要看团队的项目类型。另外，AI 评审结果目前是作为 artifact 上传，更成熟的方案是把它直接提交为 PR 评论。这个可以通过 GitHub API 实现，但代码量会显著增加，这里只演示核心链路。

接入 CI 的核心目的是把“AI 评审 + 自动化测试”变成强制门禁，而不是可选的辅助工具。只有变成流程的一环，Agent 生成代码的质量才有制度保障。

8. 常见问题与排查思路

在 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 工程化的深水区。如果你正在这个方向探索，欢迎收藏这篇文章，后续我会继续拆解更多实战细节。