构建 AI 原生工程团队

简介

AI 模型正在迅速扩展其可执行任务的范围，对工程领域产生了重大影响。前沿系统现在能够维持数小时的推理：截至 2025 年 8 月，METR 发现领先模型能够完成 2 小时 17 分钟 的连续工作，且大约有 50% 的置信度 能产生正确答案。

这种能力正在快速提升，任务时长大约每七个月翻一番。就在几年前，模型只能处理大约 30 秒的推理——仅够提供一些小的代码建议。如今，随着模型能够维持更长的推理链，整个软件开发生命周期都有可能纳入 AI 辅助的范畴，使编程智能体能够有效地参与规划、设计、开发、测试、代码审查和部署。

在本指南中，我们将分享真实案例，概述 AI 智能体如何为软件开发生命周期做出贡献，并为工程领导者提供切实指导，说明他们现在可以采取哪些措施来开始构建 AI 原生团队和流程。

AI 编程：从自动补全到智能体

AI 编程工具的发展早已超越了作为自动补全助手的起点。早期工具负责处理快速任务，例如建议下一行代码或填充函数模板。随着模型获得了更强的推理能力，开发者开始通过 IDE 中的聊天界面与智能体进行交互，进行结对编程和代码探索。

如今的编程智能体能够生成整个文件、搭建新项目，并将设计转化为代码。它们能够推理多步骤问题（例如调试或重构），并且智能体的执行现在也从单个开发者的机器转移到了基于云的多智能体环境。这正在改变开发者的工作方式，使他们能够花更少的时间在 IDE 内部使用智能体生成代码，而将更多时间用于委派整个工作流。

在 OpenAI，我们亲历了这一点。开发周期不断加快，过去需要数周的工作现在几天内就能交付。团队能更轻松地跨领域工作，更快地适应不熟悉的项目，并在整个组织中以更高的敏捷性和自主性运作。许多耗时且日常的任务，从编写新代码文档和挖掘相关测试，到维护依赖项和清理功能标志，现在都完全委派给了 Codex。

然而，工程方面的某些因素依然未变。真正的代码所有权——尤其是对于新的或模糊的问题——仍然掌握在工程师手中，而且某些挑战超出了当前模型的能力范围。但是借助 Codex 等编程智能体，工程师现在可以将更多时间花在复杂且新颖的挑战上，专注于设计、架构和系统级推理，而不是调试或机械的实现。

在接下来的部分中，我们将详细分解编程智能体如何改变 SDLC（软件开发生命周期）的每个阶段——并概述您的团队可以采取哪些具体步骤，以开始作为 AI 原生工程组织运作。

1. 规划

组织中的各个团队通常依赖工程师来确定一个功能是否可行、构建需要多长时间，以及会涉及哪些系统或团队。虽然任何人都可以起草规范，但制定准确的计划通常需要对代码库有深入的了解，并与工程团队进行多轮迭代，以发掘需求、澄清边缘情况，并就技术上切实可行的方案达成一致。

编程智能体如何提供帮助

AI 编程智能体在规划和范围界定期间为团队提供即时的、结合代码的洞察。例如，团队可以构建工作流，将编程智能体连接到他们的工单跟踪系统，以读取功能规范，结合代码库进行交叉引用，然后标记模糊之处、将工作分解为子组件或评估难度。

编程智能体还可以即时追踪代码路径，以展示某项功能涉及哪些服务——而这项工作以前需要在庞大的代码库中耗费数小时甚至数天进行人工翻阅。

工程师转而做什么

团队将更多时间花在核心功能开发上，因为智能体提供了以前需要开会进行产品对齐和范围界定才能获得的上下文。关键的实现细节、依赖项和边缘情况会在一开始就被识别出来，从而实现更快的决策，减少会议次数。

入门检查清单

• 找出需要在功能与源代码之间保持一致的常见流程。常见领域包括功能范围界定和工单创建。
• 从实现基本工作流开始，例如标记和去除重复的工单或功能请求。
• 考虑更高级的工作流，例如基于初始功能描述向工单添加子任务。或者在工单到达特定阶段时启动智能体运行，以补充更多细节。

2. 设计

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

编程智能体如何提供帮助

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

它们可以直接将设计转换为代码，提出可访问性改进建议，甚至可以分析代码库以了解用户流程或边缘情况。这使得在几小时而非几天内迭代多个原型成为可能，并且能够在早期进行高保真原型设计，为团队提供更清晰的决策基础，并使得客户测试能够在流程中更早进行。

工程师转而做什么

随着常规设置和转换任务由智能体处理，团队可以将注意力重新转移到更具价值的工作上。工程师专注于优化核心逻辑、建立可扩展的架构模式，并确保组件满足质量和可靠性标准。设计师可以花更多时间评估用户流程和探索替代概念。协作努力从实现开销转向改善底层的用户体验。

入门检查清单

• 使用接受文本和图像输入的多模态编程智能体
• 通过 MCP 将设计工具与编程智能体集成
• 通过 MCP 以编程方式公开组件库，并将它们与您的编程模型集成
• 构建将设计映射为组件并实现这些组件的工作流
• 利用类型化语言（例如 TypeScript）为智能体定义有效的属性和子组件
  

3. 构建

构建阶段是团队感到摩擦最多的地方，也是编程智能体影响最明显的地方。工程师花费大量时间将规范转化为代码结构、将服务连接在一起、在代码库中复制模式以及填充样板代码，即使是小型功能也需要数小时的繁琐工作。

随着系统的增长，这种摩擦会加剧。大型单体仓库积累了模式、约定和历史遗留的怪癖，这些都拖慢了贡献者的速度。工程师在重新发现做某事的“正确方法”上花费的时间，可能与实现该功能本身一样多。在规范、代码搜索、构建错误、测试失败和依赖管理之间不断切换上下文增加了认知负荷——而在长时间运行的任务中被打断会破坏心流，并进一步延迟交付。

编程智能体如何提供帮助

在 IDE 和 CLI 中运行的编程智能体通过处理更大的、多步骤的实现任务来加速构建阶段。它们不再仅仅生成下一个函数或文件，而是能够在一次协调运行中端到端地生成完整的功能——数据模型、API、UI 组件、测试和文档。凭借对整个代码库的持续推理，它们能够处理曾经需要工程师手动追踪代码路径才能做出的决策。

对于长时间运行的任务，智能体可以：

• 根据书面规范起草完整的功能实现。
• 在数十个文件中搜索并修改代码，同时保持一致性。
• 生成符合规范的样板代码：错误处理、遥测、安全封装或样式模式。
• 在构建错误出现时即时修复，而无需暂停等待人工干预。
• 将编写测试与实现代码作为同一工作流的一部分同步进行。
• 生成符合内部规范的、可直接用于 diff 的变更集，并附带 PR 提交信息。

在实际操作中，这会将大部分机械性的“构建工作”从工程师转移到智能体。智能体成为第一轮实现者；工程师则成为审查者、编辑和决策的来源。

工程师转而做什么

当智能体能够可靠地执行多步骤构建任务时，工程师可以将注意力转移到更高阶的工作上：

• 在实现之前，明确产品行为、边缘情况和规范。
• 审查 AI 生成代码的架构影响，而不是执行机械的连接工作。
• 完善需要深度领域推理的业务逻辑和性能关键路径。
• 设计用于指导智能体生成代码的模式、防护措施和规范。
• 与产品经理和设计师协作，迭代功能意图，而不是处理样板代码。

工程师不再将功能规范“翻译”成代码，而是专注于正确性、一致性、可维护性和长期质量，这些领域仍然最需要人类的上下文背景。

Example:

Cloudwalk 的工程师、产品经理、设计师和运维人员每天都在使用 Codex 将规范转化为可运行的代码——无论他们需要的是脚本、新的欺诈规则，还是在几分钟内交付的完整微服务。它消除了构建阶段的繁杂工作，并赋予每位员工以惊人的速度实现想法的能力。

入门检查清单

• 从定义明确的任务开始
• 让智能体通过 MCP 使用规划工具，或者编写一个 PLAN.md 文件并将其提交到代码库中
• 检查智能体尝试执行的命令是否成功
• 迭代维护 AGENTS.md 文件，以解锁运行测试和 linter 来接收反馈的智能体循环
  

4. 测试

开发者经常在确保充足的测试覆盖率上遇到困难，因为编写和维护全面的测试需要花费时间，需要上下文切换，以及对边缘情况的深入理解。团队常常面临快速迭代与编写详尽测试之间的权衡。当截止日期临近时，测试覆盖率往往是最先被牺牲的。

即使编写了测试，随着代码的演进保持测试更新也会带来持续的摩擦。测试可能会变得脆弱、因不明原因而失败，并且随着底层产品的更改，可能需要自行进行大规模重构。高质量的测试让团队能更有信心地加快发布速度。

编程智能体如何提供帮助

AI 编程工具可以在几个强大的方面帮助开发者编写更好的测试。首先，它们可以根据需求文档和功能代码的逻辑建议测试用例。模型在建议开发人员容易忽略的边缘情况和故障模式方面表现出色，特别是当开发人员一直深度专注于某项功能并需要第二意见时。

此外，随着代码的演进，模型可以帮助保持测试的更新，减少重构带来的摩擦，避免测试变得陈旧和不稳定。通过处理测试编写的基本实现细节并暴露出边缘情况，编程智能体加速了测试的开发过程。

工程师转而做什么

使用 AI 工具编写测试并不意味着开发者不再需要思考测试问题。事实上，随着智能体消除了生成代码的障碍，测试作为应用功能的真实来源发挥着越来越重要的作用。由于智能体可以运行测试套件并根据输出进行迭代，定义高质量的测试通常是让智能体构建功能的第一步。

相反，开发者将更多注意力放在观察测试覆盖率的高层模式上，在模型识别测试用例的基础上进行构建并提出挑战。提高编写测试的速度，不仅能让开发者更快地交付功能，还能让他们着手处理更具挑战性的功能。

入门检查清单

• 指导模型将实现测试作为一个单独的步骤，并在进入功能实现之前验证新测试是否会按预期失败。
• 在 AGENTS.md 文件中设定测试覆盖率的指导原则
• 为智能体提供其可以调用的代码覆盖率工具的具体示例，以帮助其理解测试覆盖率
  

5. 代码审查

平均而言，开发者每周花费 2-5 小时进行代码审查。团队常常面临两难选择：是投入大量时间进行深度审查，还是针对看似微小的更改进行快速的“差不多就行”的审查。如果优先级判断失误，bug 就会流入生产环境，给用户带来问题，并造成大量的返工。

编程智能体如何提供帮助

编程智能体使得代码审查过程得以扩展，从而让每个 PR 都能获得一致的基准关注。与依赖模式匹配和基于规则检查的传统静态分析工具不同，AI 审查者能够实际执行部分代码、解释运行时行为，并跨文件和服务追踪逻辑。然而，要发挥效用，必须专门训练模型以识别 P0 和 P1 级别的 bug，并对其进行微调以提供简洁、高价值的反馈；过于冗长的回复就像嘈杂的 lint 警告一样容易被忽视。

工程师转而做什么

在 OpenAI，我们发现 AI 代码审查让工程师们更有信心，确信自己不会将重大 bug 发布到生产环境中。代码审查通常能找出问题，让代码提交者在拉入另一位工程师审查之前就能将其修正。代码审查不一定会让拉取请求的过程变快——特别是当它发现了实质性的 bug 时——但它确实防止了缺陷和停机的发生。

委派 vs 审查 vs 负责

即使有了 AI 代码审查，工程师仍有责任确保代码已准备好发布。实际上，这意味着阅读并理解更改的影响。工程师将初步的代码审查委派给智能体，但自己负责最终的审查和合并过程。

Example:

Sansan 使用 Codex 审查竞态条件和数据库关系，这些都是人类经常忽略的问题。Codex 还能捕获不当的硬编码，甚至能预见到未来的可扩展性问题。

入门检查清单

• 精心挑选由工程师完成的黄金标准 PR 示例，包括代码更改和留下的评论。将其保存为评估集，用于衡量不同工具的效果。
• 选择使用专门针对代码审查训练的模型的产品。我们发现通用化模型往往会吹毛求疵，提供较低的信噪比。
• 定义团队将如何衡量审查质量。我们建议跟踪 PR 评论的反馈，作为一种低摩擦标记好坏审查的方法。
• 从小处着手，但一旦对审查结果建立起信心，就迅速推广。
  

6. 文档

大多数工程团队都知道他们的文档落后了，但发现迎头赶上的代价很高。关键知识通常掌握在个人手中，而不是被捕获在可搜索的知识库中；并且现有文档很快就会过时，因为更新文档会分散工程师进行产品开发的精力。即使团队开展文档冲刺，其结果通常也是一次性的努力，一旦系统演进就会迅速失效。

编程智能体如何提供帮助

编程智能体在基于阅读代码库总结功能方面具有极高的能力。它们不仅能描述代码库各部分的工作原理，还能使用 mermaid 等语法生成系统图表。随着开发者使用智能体构建功能，他们也可以简单地通过提示模型来更新文档。借助 AGENTS.md，可以在每次提示中自动包含“根据需要更新文档”的指令，以保持更高的一致性。

由于编程智能体可以通过 SDK 以编程方式运行，它们也可以被整合到发布工作流中。例如，我们可以要求编程智能体审查包含在发布中的提交，并总结关键更改。结果是，文档成为了交付管道中内置的一部分：生产速度更快、更容易保持最新，且不再依赖于有人“抽得出时间”。

工程师转而做什么

工程师从亲自动手编写每份文档，转变为塑造和监督整个系统。他们决定文档的组织方式，补充决策背后重要的“原因”，为智能体设定明确的遵循标准和模板，并审查关键或面向客户的内容。他们的工作是确保文档结构合理、内容准确，并整合到交付流程中，而不是亲自完成所有的打字工作。

入门检查清单

• 通过提示编程智能体来尝试生成文档
• 将文档指导原则纳入您的 AGENTS.md
• 识别可以自动生成文档的工作流（例如发布周期）
• 审查生成内容的质量、正确性和侧重点
  

7. 部署与维护

理解应用程序日志对软件的可靠性至关重要。在突发事件期间，软件工程师会参考日志工具、代码部署和基础设施变更，以确定根本原因。这个过程往往出人意料地依赖人工，需要开发人员在不同系统之间来回切换，在突发事件等高压情况下，这会耗费极其宝贵的时间。

编程智能体如何提供帮助

借助 AI 编程工具，除了代码库的上下文外，你还可以通过 MCP 服务器提供对日志工具的访问。这使得开发人员能够拥有统一的工作流：提示模型去查看特定端点的错误，随后模型便能利用这些上下文遍历代码库，进而找出相关的错误或性能问题。由于编程智能体同样可以使用命令行工具，因此它们能够查看 git 历史记录，以识别可能导致日志追踪中捕获问题的特定变更。

工程师转而做什么

通过将日志分析和事件分流中繁琐的环节自动化，AI 使工程师能够专注于更高层次的系统故障排查和改善。工程师无需再手动关联日志、代码提交和基础设施变更，而是可以把精力集中在验证 AI 生成的根本原因、设计高可靠的修复方案以及制定预防措施上。这种转变减少了花在被动“救火”上的时间，使团队能将更多精力投入到前瞻性的可靠性工程和架构改进中。

Example:

Virgin Atlantic 使用 Codex 来增强团队部署和维护系统的方式。Codex VS Code 扩展为工程师提供了一个统一的平台，用于调查日志、跨代码和数据追踪问题，以及通过 Azure DevOps MCP 和 Databricks 托管 MCP 审查变更。通过将运维上下文统一在 IDE 中，Codex 加快了根本原因的发现，减少了人工分流工作，并帮助团队专注于验证修复和提升系统可靠性。

入门检查清单

• 将 AI 工具连接至日志和部署系统：将 Codex CLI 或类似工具与你的 MCP 服务器及日志聚合器进行集成。
• 定义访问范围和权限：确保智能体能够访问相关的日志、代码库和部署历史记录，同时严格遵守安全最佳实践。
• 配置提示词模板：为常见的运维查询创建可复用的提示词，例如“调查端点 X 的错误”或“分析部署后的日志激增”。
• 测试工作流：运行模拟的突发事件场景，以确保 AI 能呈现正确的上下文、准确追踪代码，并提出可操作的诊断建议。
• 迭代与改进：从真实的突发事件中收集反馈，优化提示词策略，并随着系统和流程的演进不断扩展智能体的能力。
  

结论

编程智能体正通过承担传统上拖慢工程团队进度的机械化、多步骤工作，改变着软件开发的生命周期。凭借持续推理能力、统一的代码库上下文以及执行真实工具的能力，这些智能体现在可以处理从范围界定、原型设计到具体实现、测试、代码审查，甚至运维分流等各种任务。工程师依然牢牢掌控着架构、产品意图和质量——但编程智能体已日益成为 SDLC（软件开发生命周期）每个阶段中的“首发实现者”和持续协作者。

这种转变并不需要进行大刀阔斧的彻底改革；随着编程智能体变得越来越强大和可靠，小而精的针对性工作流会迅速产生复利效应。那些从界定清晰的任务入手、投入建设安全防护机制并逐步扩展智能体职责的团队，将在速度、一致性和开发者专注度上获得显著收益。

如果你正在探索编程智能体如何为你的组织提速，或正在筹备首次部署，请联系 OpenAI。我们将助你把编程智能体转化为真正的杠杆——跨计划、设计、构建、测试、审查和运维设计端到端工作流，并帮助你的团队采纳可用于生产的模式，让 AI 原生工程成为现实。