构建 AI 原生工程团队
原文：Building an AI-native engineering team，OpenAI 出品
引言
AI 模型正在快速扩展其可完成的任务范围，对工程领域产生了深远影响。最前沿的系统如今能够维持数小时的连续推理：截至 2025 年 8 月，METR 发现领先模型可以完成 2 小时 17 分钟的连续工作，且有约 50% 的置信度产出正确答案。
这一能力正在快速提升，任务时长约每七个月翻一番。仅仅几年前，模型只能处理约 30 秒的推理——刚好够给出小段代码建议。如今，随着模型能够维持更长的推理链条，整个软件开发生命周期都可能纳入 AI 辅助的范围，使 coding agents 能够有效地参与规划、设计、开发、测试、代码审查和部署。
METR 测量了不同 LLM 能以 50% 置信度完成软件工程任务的时长上限。 任务时长约每 7 个月翻一番。
本文将分享真实案例，展示 AI agents 如何为软件开发生命周期做出贡献，并为工程领导者提供切实可行的指导，帮助团队开始构建 AI 原生团队和流程。
AI 编程：从自动补全到 Agent
AI 编程工具早已超越了作为自动补全助手的最初形态。早期工具只能处理快速任务，如建议下一行代码或填充函数模板。随着模型推理能力增强，开发者开始通过 IDE 中的聊天界面与 agents 交互，进行结对编程和代码探索。
如今的 coding agents 可以生成完整文件、搭建新项目、将设计转换为代码。它们能够推理解决多步骤问题（如调试或重构），而且 agent 执行正从个人开发者机器迁移到云端多 agent 环境。这正在改变开发者的工作方式——让他们在 IDE 内与 agent 协作生成代码的时间减少，更多精力放在整个工作流程的委托上。
| 技术进步 | 带来的能力 |
|---|---|
| 跨系统统一上下文 | 单个模型可以读取代码、配置和遥测数据，在不同层面提供一致的推理，而此前需要分别使用不同工具。 |
| 结构化工具执行 | 模型现在可以直接调用编译器、测试运行器和扫描器，产生可验证的结果，而非静态建议。 |
| 持久化项目记忆 | 长上下文窗口和压缩等技术使模型能够跟踪一个功能从提案到部署的全流程，记住之前的设计选择和约束。 |
| 评估循环 | 模型输出可以针对基准进行自动测试——单元测试、延迟目标或风格指南——使改进建立在可衡量的质量之上。 |
在 OpenAI，我们亲眼见证了这一点。开发周期加速了，曾经需要数周的工作现在几天就能交付。团队更容易跨领域协作，更快上手陌生项目，组织内运作更加灵活自主。许多常规且耗时的任务——从为新代码写文档、查找相关测试、维护依赖项到清理特性开关——现在都完全委托给了 Codex。
然而，工程领域有些方面并未改变。代码的真正所有权——尤其是新问题或模糊问题——仍然属于工程师，某些挑战也超出了当前模型的能力范围。但有了 Codex 这样的 coding agents，工程师现在可以将更多时间花在复杂和新兴的挑战上，专注于设计、架构和系统级推理，而非调试或机械实现。
下面我们逐一拆解软件开发生命周期（SDLC）的每个阶段在 coding agents 加入后会发生什么变化，并概述团队成为 AI 原生工程组织所需的具体步骤。
一、规划（Plan）
团队往往依赖工程师来确定一个功能是否可行、需要多长时间构建、以及涉及哪些系统或团队。虽然任何人都能起草规格说明，但形成准确的计划通常需要深入了解代码库，并与工程团队进行多轮迭代——挖掘需求、澄清边缘情况、对齐技术上可实现的内容。
AI agents 如何帮忙
AI coding agents 在规划和估算阶段为团队提供即时、具备代码上下文的洞察。例如，团队可以构建工作流，将 coding agents 与问题跟踪系统连接——读取功能规格说明、交叉参考代码库，然后标记歧义、将工作拆分为子组件、或评估难度。
Coding agents 还能即时追踪代码路径，显示一个功能涉及哪些服务——这在以前需要在大代码库中手动挖掘数小时甚至数天。
工程师转而做什么
因为 agents 提前暴露了此前需要开会才能对齐的产品和估算上下文，团队可以将更多时间花在核心功能工作上。关键实现细节、依赖关系和边缘情况提前识别，使决策更快、会议更少。
| 角色 | 职责 |
|---|---|
| 委托（Delegate） | AI agents 可以率先进行可行性和架构分析。它们读取规格说明、映射到代码库、识别依赖项，并标记需要澄清的歧义或边缘情况。 |
| 审查（Review） | 团队审查 agent 的发现，验证准确性、评估完整性、确保估算反映真实技术约束。故事点估算、工作量评估和非显而易见的风险识别仍需人类判断。 |
| 主导（Own） | 战略决策——如优先级、长期方向、排序和权衡——仍由人类主导。团队可以向 agent 询问选项或后续步骤，但规划和产品方向的最后责任由组织承担。 |
起步清单
- 找出功能和源代码之间需要对齐的常见流程，如功能估算和工单创建
- 先实现基础工作流，例如标记和去重问题或功能请求
- 考虑更高级的工作流，如根据初始功能描述为工单添加子任务
- 或当工单达到特定阶段时启动 agent 运行，为描述补充更多细节
二、设计（Design）
设计阶段常常被基础搭建工作拖慢。团队花费大量时间连接样板代码、集成设计系统、完善 UI 组件或流程。设计稿和实现之间的不一致会产生返工和冗长的反馈循环，而有限的带宽使得无法充分探索替代方案或适应需求变化，导致设计验证延迟。
AI agents 如何帮忙
AI 编程工具通过搭建样板代码、构建项目结构、即刻实现设计令牌或风格指南，极大地加速了原型开发。工程师可以用自然语言描述所需功能或 UI 布局，获得符合团队约定的原型代码或组件存根。
它们还可以直接将设计转换为代码、提出可访问性改进建议，甚至分析代码库中的用户流程或边缘情况。这使得在数小时内而非数天内迭代多个原型成为可能，并能尽早进行高保真原型制作，为团队提供更清晰的决策依据，并更早进行客户测试。
工程师转而做什么
当 agents 处理了常规的搭建和翻译任务后，团队可以将注意力转向更高杠杆的工作。工程师专注于完善核心逻辑、建立可扩展的架构模式、确保组件满足质量和可靠性标准。设计师可以将更多时间用于评估用户流程和探索替代方案。协作工作从实现开销转向改善底层产品体验。
| 角色 | 职责 |
|---|---|
| 委托（Delegate） | Agents 通过搭建项目、生成样板代码、将设计稿翻译为组件、应用设计令牌或风格指南来处理初始实现工作。 |
| 审查（Review） | 团队审查 agent 的输出，确保组件遵循设计约定、满足质量和可访问性标准、并与现有系统正确集成。 |
| 主导（Own） | 团队拥有整体设计系统、UX 模式、架构决策和用户体验的最终方向。 |
起步清单
- 使用支持文本和图像输入的多模态 coding agent
- 通过 MCP 将设计工具与 coding agents 集成
- 以编程方式通过 MCP 暴露组件库，并与 coding 模型集成
- 构建工作流：设计稿 → 组件 → 组件实现
- 使用强类型语言（如 TypeScript）定义有效的 props 和子组件供 agent 使用
三、开发（Build）
开发阶段是团队感受摩擦最大的地方，也是 coding agents 影响最清晰的地方。工程师花费大量时间将规格说明转换为代码结构、连接服务、在代码库中复制模式、填充样板——即使小功能也需要数小时的机械工作。
随着系统增长，这种摩擦会加剧。大型 monorepo 积累了大量模式、约定和历史遗留问题，拖慢了贡献者的速度。工程师在重新发现”正确做法”上花费的时间可能和实现功能本身一样多。在规格说明、代码搜索、构建错误、测试失败和依赖管理之间不断切换上下文会增加认知负担——而长时间任务中的中断会破坏心流状态，进一步延迟交付。
AI agents 如何帮忙
在 IDE 和 CLI 中运行的 coding agents 通过处理更大的多步骤实现任务来加速开发阶段。它们不再只是生成下一个函数或文件，而是可以在一次协调运行中端到端产出完整功能——数据模型、API、UI 组件、测试和文档。通过在整个代码库上持续推理，它们处理曾经需要工程师手动追踪代码路径的决策。
在长时间任务中，agents 可以：
- 根据书面规格说明起草完整功能实现
- 在出现构建错误时即时修复，而非暂停等待人工干预
- 跨数十个文件搜索和修改代码，同时保持一致性
- 作为单一工作流的一部分编写测试
- 生成符合约定的样板：错误处理遥测、安全包装器或风格模式
- 产出遵循内部指南并包含 PR 消息的、可以直接提的变更集
实际上，这将从工程师到 agents 的机械”构建工作”大量转移。agent 成为第一轮实现者；工程师成为审查员、编辑者和方向来源。
工程师转而做什么
当 agents 能够可靠地执行多步骤构建任务时，工程师将注意力转向更高阶的工作：
- 在实现前澄清产品行为、边缘情况和规格说明
- 设计指导 agent 生成代码的模式、护栏和约定
- 审查 AI 生成代码的架构含义，而非执行机械连接
- 与 PM 和设计协作迭代功能意图，而非样板
- 完善需要深度领域推理的业务逻辑和性能关键路径
工程师不再”翻译”功能规格为代码，而是专注于正确性、连贯性、可维护性和长期质量——这些人类上下文仍然最重要的领域。
| 角色 | 职责 |
|---|---|
| 委托（Delegate） | Agents 为规格良好的功能起草第一轮实现——搭建、CRUD 逻辑、连接、重构和测试。随着长时间推理的改进，这越来越多地覆盖完整端到端构建而非孤立代码段。 |
| 审查（Review） | 工程师评估设计选择、性能、安全、迁移风险和领域对齐，同时纠正 agent 可能遗漏的细微问题。他们塑造和完善 AI 生成的代码，而非执行机械工作。 |
| 主导（Own） | 工程师保留需要深度系统直觉的工作的所有权：新抽象、跨切面架构变更、模糊的产品需求和长期可维护性权衡。随着 agents 承担更长任务，工程从逐行实现转向整体规划和审查。 |
案例
Cloudwalk 的工程师、PM、设计师和运营人员每天使用 Codex 将规格说明转化为工作代码——无论是脚本、新的欺诈规则，还是完整微服务，都在几分钟内交付。它消除了开发阶段的机械工作，让每个员工都能以惊人的速度实现想法。
起步清单
- 从规格说明良好的任务开始
- 让 agent 通过 MCP 使用规划工具，或通过编写 commit 到代码库的 PLAN.md 文件
- 检查 agent 尝试执行的命令是否成功
- 在 AGENTS.md 文件中迭代，解锁 agent 循环——如运行测试和 linter 以接收反馈
四、测试（Test）
开发者常常为确保足够的测试覆盖而苦恼，因为编写和维护全面测试需要时间、上下文切换、以及对边缘情况的深入理解。团队经常面临快速前进和编写全面测试之间的权衡。当截止日期临近时，测试覆盖往往是第一个受损的。
即使编写了测试，随着代码演进保持测试更新也会带来持续摩擦。测试可能变得脆弱、以不明确的原因失败、并在底层产品变化时需要自己的重大重构。高质量测试让团队能够更自信地更快交付。
AI agents 如何帮忙
AI 编程工具可以通过几种强大的方式帮助开发者编写更好的测试。首先，它们可以基于阅读需求文档和功能代码逻辑来建议测试用例。模型在建议边缘情况和失败模式方面出人意料地擅长——尤其当开发者已经深度聚焦于功能、需要一个第二意见时容易忽略这些。
此外，模型可以帮助测试随代码演进保持更新，减少重构摩擦并避免变得不稳定的脆弱测试。通过处理测试编写的基本实现细节并暴露边缘情况，coding agents 加速了测试开发过程。
工程师转而做什么
用 AI 工具编写测试并不会消除开发者对测试的思考。事实上，当 agents 消除了代码生成的障碍时，测试作为应用功能事实来源的作用变得越来越重要。由于 agents 可以运行测试套件并根据输出迭代，定义高质量测试通常是允许 agent 构建功能的第一步。
相反，开发者更多关注测试覆盖的高层模式，在模型识别的测试用例基础上构建和挑战。让测试编写更快，使开发者能够更快交付功能，并承担更宏大的功能。
| 角色 | 职责 |
|---|---|
| 委托（Delegate） | 工程师将基于功能规格生成测试用例的第一轮委托给 agents。他们还将使用模型进行测试生成的第一轮尝试。让模型在与功能实现不同的会话中生成测试可能更有帮助。 |
| 审查（Review） | 工程师仍然必须彻底审查模型生成的测试，确保模型没有走捷径或实现存根测试。工程师还确保测试可由 agents 运行；agent 具有适当的运行权限；agent 具有对不同测试套件可用的上下文感知。 |
| 主导（Own） | 工程师拥有将测试覆盖与功能规格和用户体验期望对齐的所有权。对抗性思维、边缘情况映射的创造力以及对测试意图的关注仍然是关键技能。 |
起步清单
- 引导模型将测试作为单独步骤实现，并验证新测试在进入功能实现前失败
- 在 AGENTS.md 文件中设置测试覆盖指南
- 给 agent 具体示例，说明它可以调用哪些代码覆盖工具来理解测试覆盖
五、审查（Review）
平均而言，开发者每周花费 2-5 小时进行代码审查。团队经常面临选择：要么在深度审查上投入大量时间，要么对看似微小的变更做一个”差不多”的快速通过。当这种优先排序失误时，bug 会溜进生产环境，为用户造成问题并产生大量返工。
AI agents 如何帮忙
Coding agents 使代码审查流程得以规模化，使每个 PR 都获得一致的基础关注。与传统静态分析工具（依赖模式匹配和基于规则的检查）不同，AI 审查者实际上可以执行部分代码、解释运行时行为、跨文件和服务追踪逻辑。然而，要有效，模型必须专门针对识别 P0 和 P1 级 bug 进行训练，并调优以提供简洁、高信号的反馈；过于冗长的响应会像噪音 lint 警告一样容易被忽略。
工程师转而做什么
在 OpenAI，我们发现 AI 代码审查给了工程师更大的信心，相信他们不会将重大 bug 交付到生产环境。通常，代码审查会发现贡献者在引入另一位工程师之前可以纠正的问题。代码审查不一定让 PR 流程更快——尤其当它发现了有意义的 bug 时——但它确实防止了缺陷和故障。
| 角色 | 职责 |
|---|---|
| 委托（Delegate） | 工程师将初始代码审查委托给 agents。这可能在 PR 被标记为可供队友审查之前发生多次。 |
| 审查（Review） | 工程师仍然审查 PR，但更多强调架构对齐；是否在实现可组合的模式、是否使用了正确的约定、功能是否匹配需求。 |
| 主导（Own） | 工程师最终拥有部署到生产环境的代码的所有权；他们必须确保它可靠运行并满足预期需求。 |
案例
Sansan 使用 Codex 审查竞态条件和数据库关系——这些是人类经常忽略的问题。Codex 还能捕捉不当的硬编码，甚至预见未来的可扩展性问题。
起步清单
- 整理 gold-standard PR 的示例，包括代码变更和留下的评论。保存为评估集以衡量不同工具
- 选择经过代码审查专门训练的模型产品。通用模型往往吹毛求疵且信噪比低
- 定义团队如何衡量审查质量。建议跟踪 PR 评论反应作为标记好坏审查的低摩擦方式
- 从小处着手，一旦对审查结果有信心就快速推广
六、文档（Document）
大多数工程团队知道文档落后了，但发现迎头赶上代价高昂。关键知识通常由个人持有而非捕获到可搜索的知识库中，现有文档很快就会过时，因为更新文档会将工程师从产品工作中拉走。即使团队进行文档冲刺，结果通常也是一次性努力，一旦系统演进就会衰减。
AI agents 如何帮忙
Coding agents 在基于阅读代码库总结功能方面能力很强。它们不仅能写出代码库各部分如何工作，还能用 mermaid 等语法生成系统图表。随着开发者与 agents 一起构建功能，他们也可以通过简单提示模型来更新文档。通过 AGENTS.md，可以自动在每个提示中包含按需更新文档的指令，以保持更高的一致性。
由于 coding agents 可以通过 SDK 以编程方式运行，它们也可以纳入发布工作流。例如，我们可以让 coding agent 审查包含在发布中的提交并总结关键变更。结果是文档成为交付流水线的内置部分：生产更快、更容易保持最新，不再依赖某人”找到时间”。
工程师转而做什么
工程师从手工编写每个文档转变为塑造和监督文档系统。他们决定文档如何组织、添加决策背后的重要”为什么”、为 agents 遵循设置明确的标准和模板、审查关键或面向客户的文档。他们的工作变成确保文档结构化、准确和连接到交付流程，而非自己做所有打字工作。
| 角色 | 职责 |
|---|---|
| 委托（Delegate） | 将低风险、重复性工作完全委托给 Codex，如文件和模块的第一轮摘要、输入输出的基本描述、依赖列表和 pull request 变更的简短摘要。 |
| 审查（Review） | 工程师在发布前审查和编辑 Codex 起草的重要文档，如核心服务概述、公共 API 和 SDK 文档、runbook 和架构页面。 |
| 主导（Own） | 工程师对整体文档策略和结构、agent 遵循的标准和模板、以及所有涉及法律、监管或品牌风险的面向外部或安全关键的文档负责。 |
起步清单
- 通过提示 coding agent 来实验文档生成
- 将文档指南纳入 AGENTS.md
- 识别可以自动生成文档的工作流（如发布周期）
- 审查生成内容的质量、正确性和重点
七、部署与维护（Deploy & Maintain）
理解应用日志对软件可靠性至关重要。在事故期间，软件工程师会参考日志工具、代码部署和基础设施变更来识别根本原因。这个过程通常出人意料地手动，需要开发者在不同系统间来回切换，在事故等高压情况下浪费关键分钟。
AI agents 如何帮忙
使用 AI 编程工具，除了代码库上下文外，你还可以通过 MCP 服务器将日志工具接入。这允许开发者拥有单一工作流——提示模型查看特定端点的错误，然后模型可以利用该上下文遍历代码库找到相关 bug 或性能问题。由于 coding agents 还可以使用命令行工具，它们可以查看 git 历史以识别可能导致日志追踪中捕获问题的特定变更。
工程师转而做什么
通过自动化日志分析和事故分类的繁琐方面，AI 使工程师能够专注于更高层次的问题排查和系统改进。无需手动关联日志、提交和基础设施变更，工程师可以专注于验证 AI 生成的根本原因、设计有弹性的修复方案、制定预防措施。这种转变减少了被动救火的时间，使团队能够将更多精力投入到主动可靠性工程和架构改进中。
| 角色 | 职责 |
|---|---|
| 委托（Delegate） | 许多运营任务可以委托给 agents——解析日志、暴露异常指标、识别可疑代码变更，甚至提出热修复方案。 |
| 审查（Review） | 工程师审查和完善 AI 生成的诊断，确认准确性，批准补救步骤。确保修复符合可靠性、安全和合规标准。 |
| 主导（Own） | 关键决策由工程师保留，特别是新发事故、敏感的生产变更或模型置信度低的情况。人类对判断和最终签字负责。 |
案例
Virgin Atlantic 使用 Codex 加强团队部署和维护系统的方式。Codex VS Code 扩展让工程师可以在一个地方调查日志、跨代码和数据追踪问题、并通过 Azure DevOps MCP 和 Databricks Managed MCP 审查变更。通过在 IDE 内统一运营上下文，Codex 加速了根本原因发现、减少了手动分类、帮助团队专注于验证修复和提高系统可靠性。
起步清单
- 连接 AI 工具到日志和部署系统：通过 MCP 服务器和日志聚合器集成 Codex CLI
- 测试工作流：运行模拟事故场景，确保 AI 暴露正确的上下文、准确追踪代码，并提出可操作的诊断
- 定义访问范围和权限：确保 agents 可以访问相关日志、代码库和部署历史，同时维护安全最佳实践
- 迭代改进：从真实事故中收集反馈，调整提示策略，随着系统和流程发展扩展 agent 能力
- 配置提示模板：为常见运营查询创建可重用提示，如”调查端点 X 的错误”或”分析部署后的日志峰值”
结语
Coding agents 正在通过承担传统上拖慢工程团队的机械性、多步骤工作来改变软件开发生命周期。凭借持续推理、统一代码库上下文和执行真实工具的能力，这些 agents 现在处理从估算和原型到实现、测试、审查乃至运营分类的各种任务。工程师牢牢掌控架构、产品意图和质量——但 coding agents 越来越多地作为每个 SDLC 阶段的第一轮实现者和持续协作者。
这种转变不需要彻底重建；小规模、有针对性的工作流会随着 coding agents 变得更加有能力而快速复合。从规格良好的任务开始、投资护栏、迭代扩展 agent 责任的团队，在速度、一致性和开发者专注度上看到了有意义的收益。
如果你正在探索 coding agents 如何加速你的组织，或准备第一次部署，请联系 OpenAI。我们在这里帮助你将 coding agents 转化为真实的杠杆——设计跨越规划、设计、开发、测试、审查和运营的端到端工作流，帮助你的团队采用使 AI 原生工程成为现实的生产级模式。