建设 AI 团队

人工智能模型正在迅速扩大它们可以执行的任务范围，这对工程产生了重大影响。 Frontier 系统现在支持 multi-hour 推理：截至 2025 年 8 月，METR 发现领先模型可以完成 2 小时 17 分钟的连续工作，并且有大约 50% 的置信度产生正确答案。

这种能力正在迅速提高，任务长度大约每七个月就会增加一倍。仅在几年前，模型可以管理大约 30 秒的推理——对于小型代码建议来说足够了。如今，随着模型维持更长的推理链，整个软件开发生命周期可能都在人工智能辅助的范围内，使编码代理能够有效地为规划、设计、开发、测试、代码审查和部署做出贡献。

在本指南中，我们将分享真实的示例，概述人工智能代理如何为软件开发生命周期做出贡献，并提供有关工程领导者今天可以做什么来开始构建 AI-native 团队和流程的实用指导。

人工智能编码工具的进步已经远远超出了其作为自动完成助手的起源。早期的工具处理快速任务，例如建议下一行代码或填写函数模板。随着模型推理能力的增强，开发人员开始通过 IDE 中的聊天界面与代理进行交互，以进行结对编程和代码探索。

今天的编码代理可以生成整个文件、搭建新项目并将设计转换为代码。他们可以通过 multi-step 问题进行推理，例如调试或重构，代理执行现在也从个人开发人员的机器转移到 cloud-based、multi-agent 环境。这正在改变开发人员的工作方式，使他们能够花更少的时间使用 IDE 内的代理生成代码，而将更多的时间用于委托整个工作流程。

在OpenAI，我们亲眼目睹了这一点。开发周期加快，曾经需要数周时间完成的工作现在仅需几天即可交付。团队可以更轻松地跨领域移动，更快地加入不熟悉的项目，并在整个组织中以更大的敏捷性和自主性运作。许多例行任务和 time-consuming 任务，从记录新代码和进行相关测试、维护依赖关系到清理功能标志，现在都完全委托给 Codex。

然而，工程的某些方面保持不变。代码的真正所有权（尤其是对于新问题或模糊问题）仍然取决于工程师，并且某些挑战超出了当前模型的能力。但有了 Codex 这样的编码代理，工程师现在可以将更多时间花在复杂和新颖的挑战上，专注于设计、架构和 system-level 推理，而不是调试或死记硬背实施。

在以下部分中，我们将详细介绍 SDLC 的每个阶段如何随编码代理而变化，并概述您的团队开始作为 AI-native 工程组织运营时可以采取的具体步骤。

组织中的团队通常依靠工程师来确定某个功能是否可行、构建需要多长时间以及将涉及哪些系统或团队。虽然任何人都可以起草规范，但形成准确的计划通常需要深入的代码库意识和多轮工程迭代，以发现需求、澄清边缘情况并与技术上的实际情况保持一致。

AI 编码代理在规划和范围界定期间为团队提供即时的 code-aware 见解。例如，团队可以构建将编码代理连接到其 issue-tracking 系统的工作流程，以读取功能规范，根据代码库对其进行 cross-reference，然后标记歧义，将工作分解为子组件，或估计难度。

编码代理还可以立即跟踪代码路径，以显示某个功能涉及哪些服务——以前需要数小时或数天手动挖掘大型代码库的工作。

团队在核心功能工作上花费了更多时间，因为代理可以提供以前需要召开会议来进行产品调整和范围界定的上下文。预先确定关键的实施细节、依赖关系和边缘情况，从而可以通过更少的会议更快地做出决策。

设计阶段常常因基础设置工作而减慢。团队花费大量时间连接样板、集成设计系统以及完善 UI 组件或流程。模型和实现之间的不一致可能会导致返工和较长的反馈周期，而探索替代方案或适应不断变化的需求的带宽有限，会延迟设计验证。

人工智能编码工具通过搭建样板代码、构建项目结构以及立即实施设计标记或风格指南，极大地加速了原型设计。工程师可以用自然语言描述所需的功能或 UI 布局，并接收符合团队约定的原型代码或组件存根。

他们可以将设计直接转换为代码，提出可访问性改进建议，甚至分析代码库以了解用户流程或边缘情况。这使得在数小时而不是数天内迭代多个原型成为可能，并尽早以高保真度进行原型设计，为团队提供 decision-making 更清晰的基础，并使客户能够在此过程中更快地进行测试。

通过代理处理日常设置和翻译任务，团队可以将注意力转移到 higher-leverage 工作上。工程师专注于完善核心逻辑、建立可扩展的架构模式并确保组件满足质量和可靠性标准。设计师可以花更多时间评估用户流程并探索替代概念。协作工作从实施开销转向改善底层产品体验。

构建阶段是团队感受到最大摩擦的阶段，也是编码代理产生最明显影响的阶段。工程师花费大量时间将规范转换为代码结构、将服务连接在一起、在代码库中复制模式以及填充样板文件，即使是很小的功能也需要数小时的 busy-work。

随着系统的发展，这种摩擦会加剧。大型单一存储库积累了模式、惯例和历史怪癖，这些都减慢了贡献者的速度。工程师可以花费与实现功能本身一样多的时间来重新发现做某事的“正确方法”。规范、代码搜索、构建错误、测试失败和依赖关系管理之间不断的上下文切换会增加认知负担，而 long-running 任务期间的中断会破坏流程并进一步延迟交付。

在 IDE 和 CLI 中运行的编码代理通过处理更大的 multi-step 实施任务来加速构建阶段。他们不仅可以生成下一个函数或文件，还可以在一次协调运行中生成完整功能的 end-to-end — 数据模型、API、UI 组件、测试和文档。通过对整个代码库的持续推理，他们可以处理曾经需要工程师手动跟踪代码路径的决策。

通过 long-running 任务，代理可以：

实际上，这将大部分机械“构建工作”从工程师转移到了代理身上。代理成为first-pass实施者；工程师成为审稿人、编辑和指导来源。

当代理可以可靠地执行 multi-step 构建任务时，工程师会将注意力转移到 higher-order 工作上：

工程师不是将功能规范“翻译”为代码，而是专注于正确性、连贯性、可维护性和 long-term 质量，这些领域的人文环境仍然最重要。

例子：

云从科技的工程师、PM、设计师和操作员每天都使用 Codex 将规范转换为工作代码，无论他们需要脚本、新的欺诈规则还是在几分钟内交付的完整微服务。它消除了构建阶段的繁忙工作，并赋予每位员工以惊人的速度实施想法的能力。

开发人员通常很难确保足够的测试覆盖率，因为编写和维护全面的测试需要时间、需要上下文切换以及对边缘情况的深入理解。团队经常在快速行动和编写彻底的测试之间面临 trade-offs。当最后期限临近时，测试覆盖率往往是首先受到影响的。

即使编写了测试，随着代码的发展保持更新也会带来持续的摩擦。测试可能会变得脆弱，由于不明原因而失败，并且随着底层产品的变化，可能需要进行重大重构。高质量的测试让团队更加自信地更快地交付。

人工智能编码工具可以帮助开发人员通过多种强大的方式编写更好的测试。首先，他们可以根据阅读需求文档和功能代码的逻辑来建议测试用例。模型在建议开发人员可能很容易忽视的边缘情况和故障模式方面出奇地出色，特别是当他们深入关注该功能并需要第二意见时。

此外，模型可以帮助测试随着代码的发展而更新，减少重构的摩擦并避免过时的测试变得不稳定。通过处理测试编写的基本实现细节和呈现边缘情况，编码代理可以加速开发测试的过程。

使用人工智能工具编写测试并不能消除开发人员考虑测试的需要。事实上，随着代理消除了生成代码的障碍，测试作为应用程序功能的真实来源发挥着越来越重要的作用。由于代理可以运行测试套件并根据输出进行迭代，因此定义高质量测试通常是允许代理构建功能的第一步。

相反，开发人员更关注于查看测试覆盖率中的高级模式，构建并挑战模型对测试用例的识别。加快测试编写速度可以让开发人员更快地发布功能，并实现更雄心勃勃的功能。

开发人员平均每周花费 2-5 小时进行代码审查。团队经常面临一个选择：是投入大量时间进行深入审查，还是对看似很小的更改进行快速“足够好”的检查。当这种优先级被取消时，错误就会溜进生产中，给用户带来问题并造成大量返工。

编码代理允许扩展代码审查流程，以便每个 PR 都能获得一致的关注基线。与传统的静态分析工具（依赖于模式匹配和 rule-based 检查）不同，AI 审阅者实际上可以执行部分​​代码、解释运行时行为以及跨文件和服务跟踪逻辑。然而，为了有效，模型必须经过专门训练以识别 P0 和 P1 级错误，并进行调整以提供简洁的 high-signal 反馈；过于冗长的响应就像嘈杂的 lint 警告一样容易被忽略。

在 OpenAI，我们发现人工智能代码审查让工程师更有信心他们不会将重大错误带入生产中。通常，代码审查会发现贡献者可以在引入另一位工程师之前纠正的问题。代码审查不一定会使拉取请求过程更快，特别是当它发现有意义的错误时 - 但它确实可以防止缺陷和中断。

即使有了人工智能代码审查，工程师仍然有责任确保代码准备好交付。实际上，这意味着阅读并理解变化的含义。工程师将最初的代码审查委托给代理，但拥有最终的审查和合并过程。

例子：

Sansan 使用 Codex 审查竞争条件和数据库关系，这是人类经常忽视的问题。 Codex 还能够捕获不正确的 hard-coding，甚至可以预测未来的可扩展性问题。

大多数工程团队都知道他们的文档落后了，但发现追赶的成本很高。关键知识通常由个人掌握，而不是在可搜索的知识库中捕获，并且现有文档很快就会过时，因为更新它们会使工程师远离产品工作。即使团队进行文档冲刺，其结果通常也是 one-off 的努力，随着系统的发展，这种努力就会消失。

编码代理非常有能力根据阅读代码库来总结功能。他们不仅可以编写部分代码库的工作原理，还可以使用 mermaid 等语法生成系统图。当开发人员使用代理构建功能时，他们还可以通过提示模型来简单地更新文档。借助 AGENTS.md，根据需要更新文档的说明可以自动包含在每个提示中，以提高一致性。

由于编码代理可以通过 SDK 以编程方式运行，因此它们也可以合并到发布工作流程中。例如，我们可以要求编码代理审查版本中包含的提交并总结关键更改。结果是文档成为交付管道的 built-in 一部分：生成速度更快，更容易保持最新状态，并且不再依赖于“抽出时间”的人。

工程师从手工编写每份文档转向塑造和监督系统。他们决定如何组织文档，添加决策背后的重要“原因”，为代理制定明确的标准和模板以供遵循，并审查关键或 customer-facing 部分。他们的工作是确保文档结构化、准确并融入交付流程，而不是自己完成所有打字工作。

了解应用程序日志记录对于软件可靠性至关重要。在发生事件期间，软件工程师将参考日志记录工具、代码部署和基础设施更改来确定根本原因。令人惊讶的是，这个过程通常是手动的，并且需要开发人员在不同的系统之间来回切换，在事件等高压情况下会花费关键的时间。

借助 AI 编码工具，除了代码库的上下文之外，您还可以通过 MCP 服务器提供对日志记录工具的访问。这允许开发人员拥有一个单一的工作流程，他们可以在其中提示模型查看特定端点的错误，然后模型可以使用该上下文来遍历代码库并查找相关的错误或性能问题。由于编码代理还可以使用命令行工具，因此他们可以查看 git 历史记录来识别可能导致在日志跟踪中捕获问题的特定更改。

通过自动化日志分析和事件分类的繁琐环节，人工智能使工程师能够专注于 higher-level 故障排除和系统改进。工程师可以专注于验证 AI-generated 根本原因、设计弹性修复和制定预防措施，而不是手动关联日志、提交和基础设施变更。这种转变减少了花在被动消防上的时间，使团队能够在主动可靠性工程和架构改进上投入更多精力。

例子：

维珍航空使用 Codex 来加强团队部署和维护系统的方式。 Codex VS Code 扩展为工程师提供了一个单一位置来调查日志、跟踪代码和数据问题以及通过 Azure DevOps MCP 和 Databricks 托管 MCP 查看更改。通过在 IDE 内统一此操作上下文，Codex 可以加快根本原因发现、减少手动分类，并帮助团队专注于验证修复和提高系统可靠性。

编码代理正在通过承担传统上拖慢工程团队速度的机械式 multi-step 工作来改变软件开发生命周期。凭借持续的推理、统一的代码库上下文以及执行真实工具的能力，这些代理现在可以处理从范围界定和原型设计到实施、测试、审查甚至操作分类的任务。工程师牢牢控制着架构、产品意图和质量，但编码代理越来越多地充当 first-pass 的实施者和跨 SDLC 每个阶段的持续合作者。

这种转变不需要彻底的改革；随着编码代理变得更加强大和可靠，小型、有针对性的工作流程会迅速复合。从 well-scoped 任务开始、投资护栏并迭代扩展代理职责的团队在速度、一致性和开发人员关注度方面看到了有意义的收益。

如果您正在探索编码代理如何加速您的组织或准备首次部署，请联系 OpenAI。我们随时帮助您将编码代理转化为真正的杠杆——设计跨规划、设计、构建、测试、审查和运营的 end-to-end 工作流程，并帮助您的团队采用 production-ready 模式，使 AI-native 工程成为现实。