OpenAI 自述：怎么建 AI 原生工程组织

「让 agent 写代码」这件事，多数团队已经试过了。真正难的是下一个问题：当 agent 能端到端做完一个功能，团队里剩下的那些人，每天该干什么。

OpenAI 给了一份自己的答案，写成了公开文档。

一、发生了什么

这份文档叫《构建 AI 原生工程团队》，放在 OpenAI 的开发者站点上，讲编程智能体如何改变软件开发生命周期的每个阶段。全文按七段展开：规划、设计、构建、测试、代码审查、文档、部署与维护。

开篇引了一组能力数据：截至 2025 年 8 月，前沿模型能以大约一半的把握完成两小时十七分钟的连续工作，而这个时长大约每七个月翻一倍。几年前，模型只能撑三十秒左右。

每一段都按同一个骨架写：agent 做什么、人审查什么、谁最终负责。

规划阶段，agent 接进工单系统，读需求、对照代码库、标出含糊处、拆子任务、估难度。人保留优先级和方向的最终决定权。

构建阶段，agent 出第一版实现，连同脚手架、接口、界面、测试和文档一起给。人转向评审架构影响、性能、安全和迁移风险，以及那些需要系统直觉的活——新抽象、跨领域改动、模糊需求。

测试阶段有个细节值得抄：让模型在独立于实现的会话里先生成测试，先确认这些测试会按预期失败，再让它写实现。人负责看它有没有写空壳测试糊弄。

代码审查那段给了一个数字：开发者平均每周花两到五小时做评审。文档的建议是让 AI 先审一轮，但必须专门调过，只报真正严重的缺陷，啰嗦的评审意见会和噪音一样被忽略。

文档阶段的做法更省事：把「按需更新文档」写进项目说明文件，让它在每次提示里自动带上；再把文档生成塞进发布流程。

文末给了三个客户例子：Cloudwalk 用它把需求变成可运行代码，Sansan 用它查竞态条件和数据库关系，维珍航空用它统一日志排查。

如果你是工程负责人。 这份文档最有用的是那个三段式：委派、审查、负责。三者不能压缩成两者。

如果你是一线工程师。 你的工作重心会从写，转到定义边界和判断质量。判断力变成主要产出。

如果你在推内部落地。 别从「全员上工具」开始，从一件定义清楚、验收标准明确的任务开始。

「照这份文档做，团队就能提效数倍。」 这是 OpenAI 写自己在用 Codex 的经验，客户案例由它自己挑。它没说失败的项目长什么样，也没给基线数据。

「agent 能承担所有阶段，所以人可以减少。」 文档里每一段都明确写了人保留的部分：方向、架构、安全、上线责任。这些没有一段被交出去。

「流程可以一步到位。」 文档自己说，不需要推倒重来，从小而具体的工作流起步，会逐步产生复利。反过来，一次性改完流程的团队，通常连基线都没测。

AI 原生不是把活交给模型，是把「谁做第一轮、谁签字」写清楚。

2026 年 10 月 31 日

功能与价格以官方公告为准。本文写于 2026 年 10 月 31 日。