构建 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 编程工具可通过生成样板代码、构建项目结构并立即应用设计 Token 或风格指南，大幅加快原型开发。工程师可以用自然语言描述所需功能或 UI 布局，并获得符合团队约定的原型代码或组件存根。

它们可以将设计稿直接转换为代码、建议无障碍改进措施，甚至分析代码库中的用户流程或边缘情况。这样一来，多个原型可以在数小时内而非数天内完成迭代，还能在早期构建高保真原型，为团队决策提供更清晰的依据，并让客户测试能在流程的更早阶段开展。

工程师转而做什么

智能体处理常规设置和转换任务后，团队可以将注意力转向价值更高的工作。工程师专注于完善核心逻辑、建立可扩展的架构模式，并确保组件符合质量和可靠性标准。设计师可以投入更多时间评估用户流程和探索替代概念。协作重心将从应付实现工作转向改善产品体验本身。

入门检查清单

• 使用同时接受文本和图像输入的多模态编程智能体
• 通过 MCP 将设计工具与编程智能体集成
• 通过 MCP 以编程方式公开组件库，并将其与您的编程模型集成
• 构建可将设计 → 组件 → 组件实现对应起来的工作流
• 使用类型化语言（如 Typescript）为智能体定义有效的 props 和子组件
  

3. 构建

构建阶段是团队感受到阻力最大的阶段，也是编程智能体影响最明显的阶段。工程师需要投入大量时间将规范转化为代码结构、连接服务、在代码库中重复套用模式以及补充样板代码，即使是小功能也需要花费数小时处理机械性工作。

随着系统不断发展，这些阻力会叠加。大型单体代码仓库会积累各种模式、约定和历史遗留的特殊情况，拖慢贡献者的速度。工程师重新摸索某件事的“正确做法”所花的时间，可能与实现功能本身一样多。在规范、代码搜索、构建错误、测试失败和依赖项管理之间不断切换上下文，会增加认知负担；长时间运行的任务一旦被打断，还会打乱工作节奏，进一步延迟交付。

编程智能体如何提供帮助

在 IDE 和 CLI 中运行的编程智能体可以处理规模更大、包含多个步骤的实现任务，从而加快构建阶段。它们不再只生成下一个函数或文件，而是可以在一次协调运行中端到端地实现完整功能，包括数据模型、API、UI 组件、测试和文档。通过在整个代码库范围内持续推理，它们可以做出以往需要工程师手动追踪代码路径才能做出的决策。

在长时间运行的任务中，智能体可以：

• 根据书面规范起草完整的功能实现。
• 在数十个文件中搜索和修改代码，同时保持一致性。
• 生成符合约定的样板代码，包括错误处理、遥测、安全封装或样式模式。
• 发现构建错误时立即修复，而不是暂停并等待人工干预。
• 在同一工作流中实现功能的同时编写测试。
• 生成遵循内部准则、包含 PR 说明且可直接进行差异审查的变更集。

实际上，这会把许多机械性的“构建工作”从工程师转交给智能体。智能体负责第一轮实现；工程师则负责审查、编辑和指明方向。

工程师转而做什么

当智能体能可靠地执行多步骤构建任务时，工程师会将注意力转向更高层次的工作：

• 在实现前明确产品行为、边缘情况和规范。
• 审查 AI 生成代码对架构的影响，而非机械地进行代码串接。
• 优化需要深入领域推理的业务逻辑和性能关键路径。
• 设计用于指导智能体生成代码的模式、防护机制和约定。
• 与 PM 和设计团队协作，反复打磨功能意图，而非样板代码。

工程师不再把功能规范“翻译”为代码，而是专注于正确性、一致性、可维护性和长期质量；这些方面仍最需要人类对上下文的理解。

示例：

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

入门清单

• 从定义明确的任务开始
• 让智能体通过 MCP 使用规划工具，或编写并向代码库提交 PLAN.md 文件
• 确认智能体尝试执行的命令都能成功运行
• 持续完善 AGENTS.md 文件，从而启用智能体循环，例如运行测试和代码检查工具以获取反馈
  

4. 测试

由于编写和维护全面的测试既耗时，又需要切换上下文并深入理解边缘情况，开发者常常难以确保测试覆盖率充足。团队经常需要在快速推进与编写详尽测试之间做出取舍。交付期限临近时，测试覆盖率往往首当其冲。

即使已经编写了测试，随着代码演进让测试保持最新状态也会带来持续的负担。测试可能变得脆弱、因不明原因失败；随着底层产品变化，测试本身也可能需要大规模重构。高质量测试能让团队更快、更有信心地交付。

编程智能体如何提供帮助

AI 编程工具可以通过多种有效方式帮助开发者编写更好的测试。首先，它们可以阅读需求文档和功能代码的逻辑，据此建议测试用例。模型在提出开发者容易忽略的边缘情况和故障模式方面，表现往往出人意料地好，尤其是当开发者一直专注于功能本身、需要另一种视角时。

此外，随着代码演进，模型还可帮助测试保持最新状态，减少重构阻力，并避免过时测试出现偶发性失败。通过处理测试编写中的基础实现细节并发现边缘情况，编程智能体可以加快测试开发过程。

工程师转而做什么

使用 AI 工具编写测试并不意味着开发者无需思考测试。事实上，随着智能体降低生成代码的门槛，测试会越来越成为应用功能的事实依据。由于智能体可以运行测试套件并根据输出反复迭代，要让智能体构建功能，第一步往往是定义高质量测试。

相反，开发者会更加关注测试覆盖的整体模式，在模型识别出的测试用例基础上继续完善，并审视其判断。加快测试编写不仅让开发者能更快交付功能，还能让他们开发更具挑战性的功能。

入门清单

• 指导模型将测试实现作为单独步骤，并在继续实现功能之前验证新增测试会失败。
• 在您的 AGENTS.md 文件中设定测试覆盖率准则
• 向智能体提供可调用的代码覆盖率工具的具体示例，帮助它了解测试覆盖情况
  

5. 审查

开发者平均每周花费 2–5 小时进行代码审查。对于看似较小的变更，团队往往需要在投入大量时间进行深入审查与快速完成一次“足够好”的审查之间做出选择。如果优先级安排不当，缺陷就可能进入生产环境，给用户造成问题并带来大量返工。

编程智能体如何提供帮助

编程智能体可扩展代码审查流程，让每个 PR 都能得到一致的基础审查。与依赖模式匹配和规则检查的传统静态分析工具不同，AI 审查工具可以实际执行部分代码、解读运行时行为，并跨文件和服务追踪逻辑。不过，要发挥作用，模型必须专门针对识别 P0 和 P1 级缺陷进行训练，并经过调优以提供简洁、切中要害的反馈；过于冗长的回复与充斥噪声的代码检查警告一样容易被忽略。

工程师转而做什么

在 OpenAI，我们发现，AI 代码审查让工程师更有信心，确信不会把重大缺陷带入生产环境。代码审查经常会发现一些问题，贡献者可以先自行修正，再请其他工程师参与。代码审查未必会加快 Pull Request 流程，尤其是在发现有实质影响的缺陷时，但它确实能防止缺陷和服务中断。

委派、审查与负责

即使使用 AI 代码审查，工程师仍有责任确保代码已做好交付准备。具体来说，这意味着要阅读并理解变更所带来的影响。工程师将初步代码审查委派给智能体，但最终审查和合并流程仍由工程师负责。

示例：

Sansan 使用 Codex 来审查竞态条件和数据库关系，这些问题往往容易被人忽略。Codex 还能发现不当的硬编码，甚至预判未来的可扩展性问题。

入门清单

• 整理由工程师完成的标杆 PR 示例，其中包括代码变更和所留评论。将这些示例保存为评测集，用于衡量不同工具的表现。
• 选择一种产品，其中的模型专门针对代码审查进行过训练。我们发现，通用模型往往会纠结于细枝末节，信噪比很低。
• 确定您的团队将如何衡量审查质量。我们建议跟踪 PR 评论的表情回应，以便低成本标记审查质量的优劣。
• 先从小范围开始，但对审查结果建立信心后应迅速推广。
  

6. 编写文档

大多数工程团队都知道自己的文档更新滞后，但补齐文档欠账的成本很高。关键知识往往掌握在个人手中，而没有沉淀到可搜索的知识库中；现有文档也会迅速过时，因为更新文档会占用工程师开展产品工作的时间。即使团队集中开展文档冲刺，通常也只是一次性行动，系统一旦演进，成果便会逐渐失效。

编程智能体如何提供帮助

编程智能体擅长通过阅读代码库来总结其功能。它们不仅能说明代码库各部分的工作原理，还能使用 mermaid 等语法生成系统图。开发者使用智能体构建功能时，只需向模型发出提示，也能更新文档。借助 AGENTS.md，可以在每次提示中自动加入按需更新文档的指令，从而提高一致性。

由于可以通过 SDK 以编程方式运行编程智能体，因此也能将其纳入发布工作流。例如，我们可以要求编程智能体审查将包含在发布版本中的提交，并总结关键变更。这样一来，文档便成为交付流水线的内置环节：生成速度更快，更易保持最新，也不再依赖某个人“抽出时间”来处理。

工程师转而做什么

工程师不再手动编写每一篇文档，而是负责塑造和监督整个系统。他们决定文档的组织方式，补充决策背后重要的“为什么”，制定供智能体遵循的明确标准和模板，并审查关键内容或面向客户的部分。他们的职责转变为确保文档结构清晰、内容准确并融入交付流程，而不是亲自完成所有文字工作。

入门清单

• 尝试通过向编程智能体发出提示来生成文档
• 将文档编写准则写入您的 AGENTS.md
• 确定哪些工作流（例如发布周期）可以自动生成文档
• 审查生成的内容，确保质量达标、内容正确且重点明确
  

7. 部署与维护

了解应用程序的日志记录机制对软件可靠性至关重要。发生故障时，软件工程师会查看日志工具、代码部署记录和基础设施变更，以确定根本原因。这一过程往往出人意料地依赖人工，需要开发者在不同系统之间来回切换，在故障等高压情形中耗费宝贵的处置时间。

编程智能体如何提供帮助

使用 AI 编程工具时，除了提供代码库上下文，您还可以通过 MCP 服务器向工具开放日志工具的访问权限。这使开发者可以在单一工作流中提示模型检查特定端点的错误，然后模型便可利用这些上下文遍历代码库，找出相关缺陷或性能问题。由于编程智能体也能使用命令行工具，因此还可以查看 git 历史记录，找出可能导致日志跟踪所记录问题的具体变更。

工程师转而做什么

通过自动化日志分析和事件分诊中繁琐的环节，AI 让工程师能够专注于更高层次的故障排除和系统改进。工程师不再手动关联日志、提交和基础设施变更，而是可以专注于验证 AI 找出的根本原因、设计稳健的修复方案并制定预防措施。这一转变减少了被动救火所占用的时间，让团队能够将更多精力投入主动式可靠性工程和架构改进。

示例：

Virgin Atlantic 使用 Codex 来强化团队部署和维护系统的能力。Codex VS Code 扩展程序让工程师可以在一个位置分析日志、追踪横跨代码和数据的问题，并通过 Azure DevOps MCP 和 Databricks Managed MCPs 审查变更。Codex 将这些运维上下文统一汇集到 IDE 中，从而加快根本原因定位、减少手动分诊，并帮助团队专注于验证修复和提高系统可靠性。

入门清单

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

结论

编程智能体正在接手长期以来拖慢工程团队的机械性、多步骤工作，从而改变软件开发生命周期。凭借持续推理能力、统一的代码库上下文以及执行实际工具的能力，这些智能体现在可以处理从范围界定和原型设计，到实现、测试、审查，甚至运维事件分诊的各类任务。工程师依然牢牢掌控架构、产品意图和质量，但编程智能体正日益成为首轮实现者，以及贯穿 SDLC 各阶段的持续协作伙伴。

这种转变并不需要彻底改造现有体系；随着编程智能体的能力和可靠性不断提升，小而聚焦的工作流会迅速积累成效。从范围明确的任务入手、投入构建防护措施并逐步扩大智能体职责的团队，可以显著提升速度和一致性，并让开发者更加专注。

如果您正在探索编程智能体如何提升组织的开发效率，或正在为首次部署做准备，请联系 OpenAI。我们可以帮助您将编程智能体转化为切实的生产力：设计覆盖规划、设计、构建、测试、审查和运维的端到端工作流，并帮助您的团队采用可用于生产环境的模式，让 AI 原生工程真正落地。