基于与 OpenAI Codex 团队工程负责人一次对话的洞察：他们如何协作、如何使用 AI、团队结构、开发理念，以及更多内容
引言
AI 不再只是工程师手里的工具，它也正在深刻影响工程团队的组织结构、决策方式，以及软件是如何被构建出来的。
我在许多初创公司和中型公司里都看到了这种变化：它们试图通过创建“AI 原生”的工程团队来调整组织结构。但在我看来，真正把这件事做到位的团队并不多，而 OpenAI 的 Codex 团队是其中最典型、最彻底的例子之一。
在 Codex 应用、IDE 扩展、以及开源编码智能体等产品背后，是一个相对精简的小团队——大约 40 人——却以极高的自治度、速度与信任运行。他们的工作覆盖低层系统工程、大规模分布式基础设施、产品设计、研究与用户体验等多个方向，并且在几乎所有工作中都大量使用 AI。
Codex 团队最有趣的地方不仅是他们做什么，而是他们如何做。他们把 AI 当作工作流的核心层：从规划与入职培训，到代码审查、测试、优先级管理，AI 都深度参与其中。
Codex 团队规模约 40 人
Codex 团队大约 40 人，内部又划分为多个更小的子团队，分别负责不同项目，比如：开源编码智能体、Codex 的 IDE 扩展、Codex 应用本体，以及其他项目。
他们强调授权与本地决策。整体感觉更像“现代版本的贝尔实验室（Bell Labs）”。
个体被充分信任去做决定，因为变化的速度要求他们必须如此。
整个 Codex 团队只有 1 位产品经理，2 位设计师，其余大多是具备不同专长的工程师。
Thibault 提到一个例子，能非常具体地说明他们的产品经理为什么效率惊人。
他们的产品经理为什么能如此高效
Codex 团队的产品工作几乎由一位产品经理在驱动。这位 PM 借助 Codex，把自己“扩展”成了类似 100 倍效率的产品经理。看他工作的方式简直不可思议，完全是另一个层级。
他用 Codex 快速挖掘用户反馈、分拣问题、实时做优先级决策。
最近一次一小时的 bug bash 里，全团队在测试应用并记录问题。问题一出现，这位 PM 立刻就能把它们分类、设定优先级、分配负责人。
他们在那一小时里处理了 100 多个问题，而且大多数问题在 24 小时内就被修复。这样的速度与协同，来自 PM 的规划与决策能力，但如果没有 AI，这几乎不可能做到。
他们做的工作是什么？团队工程师是什么画像？
团队里有大量工作属于低层系统工程，主要使用 Rust。
他们的一大核心工作围绕 Codex harness 展开。它是一个内部的软件框架与运行时逻辑，为 Codex 编码智能体提供动力——可以理解为负责“编排” Codex 如何行为、如何与用户交互、如何在不同界面中稳定执行任务的那部分系统。
此外，他们也维护开源仓库：Codex CLI 编码智能体，这是一个可以在本地运行的工具，能够直接在终端里协助完成编码任务。
再往上，是后端基础设施，它把 GPU 与运行模型的系统连接起来。
他们还参与 Responses API 的工作。Responses API 是生成模型输出的核心 API 接口，Codex 通过它与模型对话，从而完成读文件、运行命令、分析代码等能力。
除此之外，他们还构建并维护一套自己的后端系统，用来处理认证、用量追踪，以及请求与响应在系统中的可靠传递，确保一切能在规模化条件下稳定运行。这是一个大型分布式系统工程，团队需要承担 on-call 轮值。
与此同时，也有前端与全栈工程师在构建各种用户真正使用 Codex 的产品体验。
团队中也有研究方向的成员，负责开展相关研究，确保 OpenAI 能产出最强的模型能力。
开发流程
他们会从整体战略出发，然后把重点放在激励人、给予自主权与主人翁意识上，同时仍然保持明确的问责机制。
最成功的项目通常来自非常小的团队，往往只有两三个人。有时一个完整功能甚至由单个工程师端到端完成，并对全链路负责：
- 规划与设计
- 实现与落地
- 发布、定位与对外沟通
- 根据用户反馈持续迭代
在 Codex 团队里，这种端到端的完整所有权不仅被允许，而且被强烈鼓励。
大多数想法也来自自下而上：团队成员对某个点子兴奋，便推动它成形。
他们与研究团队合作非常紧密。很多时候，他们从新的研究方向或即将到来的能力中获得启发，然后提前构建基础设施或新的产品体验。
整个过程具有很强的创造性。关于“如何监督和引导智能体”的正确方式，没有人已经完全想清楚，而 Codex 应用只是他们思考方式的一种体现。
他们的流程中也包含大量实验与构思。并不是所有东西都会发布，但探索新想法会被鼓励并得到回报，最终他们只会发布最好的成果。
他们保持极度精简，并尽可能减少会议
他们确实会开会，但多是临时发生、由真实需求驱动的会议。办公室的布局也鼓励线下面对面协作，领导层非常可接近，因此许多问题可以在几分钟到最多几小时内解决。
他们做决策非常快。因为 Codex 随时可用，试错成本大幅降低：他们可以快速尝试、观察结果，如果方向不对就迅速调整。
因此他们非常强调速度与产出节奏。许多一两年前仍有效的流程，如今已无法规模化，他们几乎是重新发明了自己的工作方式。
新工程师的入职搭档是 Codex
Thibault 分享说，Codex 会带新员工完成入职流程：协助设置整台电脑，帮助理解代码库、项目、既有功能，就像一个非常资深的工程导师。
从最初的环境搭建到产生生产力，入职流程的大部分都由 AI 工具承担，因此入职速度比过去快得多。
OpenAI 还有一种强烈文化：第一天就要发布（ship on day one）。他们非常重视让每位工程师尽快创造价值。
传统团队可能把“第一周上线代码到生产环境”当作目标，而在 Codex 团队里，他们认为这应该在第一天完成。
在这样的文化与系统支持下，新人即使完全没有上下文，也能快速理解系统，并在入职第一天就发布真正有意义的功能。
接下来，我们进入他们如何利用 AI 提升生产力的部分。
Codex 团队如何使用 AI
他们在内部几乎用 Codex 做所有事情。
他们构建了很多专用于开发 Codex 自身的定制技能（skills）。例如其中一个技能可以让 Codex 对自己的构建版本运行完整 QA：当他们发布一个新的 CLI 构建时，Codex 可以自动检查多种功能并验证没有出现破坏性变化。
他们内部也大量使用子智能体（sub-agents）。这仍是实验性能力，但他们用它来做大规模并行测试以及大规模重构。
在规划侧，Codex 连接了 Linear、Notion、Slack 等工具，让他们能够更快收集并综合用户反馈。
他们的反馈渠道极其活跃，尤其是 Codex 相关频道，任何人类都很难完全跟上。Codex 会总结每日主题，并帮助工程师决定下一步优先做什么。
如果你在办公室里走一圈，会看到 Codex 几乎出现在每个人的屏幕上：它在为 YouTube 编辑视频、在为 Linear 工单做优先级排序、在运行大规模重构，比如他们最近从 Python 重写到 Rust 的工程。Codex 真的是他们工作方式的核心。
Codex 会自动审查所有 Pull Request
他们为 Codex 设置了定制指令，使其能够强制执行非常具体的工程标准：确保结构正确、模块边界被遵守、语义正确、覆盖率达到他们设定的门槛。
这些审查会自动发生在每一个 PR 上。
除此之外，他们也大量进行本地代码审查：工程师可以运行一个简单的 “review” 命令，然后在循环里不断迭代。
在有了子智能体之后，这变得更常见：很多人会让多个子智能体在 PR 对外分享前先进行审查。这个过程经常能发现一些细小问题与改进点，否则可能会被忽略。
他们也投入很多时间去维护一个健康且结构良好的代码库，因为他们知道：如果缺乏正确护栏与结构，方向很容易漂移，最终会拖慢整体速度。
Codex 帮助他们在加速的同时保持高质量。
他们如何组织提示词，才能更有效地使用 AI
当然，Codex 团队内部用的是 Codex，但对你来说可以使用你偏好的任何 AI 工具。Thibault 的建议是从以下方式开始：
与模型进行深入的设计讨论
这也是他们推出 Plan Mode 的原因：它为需要更结构化帮助的用户服务。Plan Mode 会邀请模型进入一个来回对话的过程，而不是给出一次性的答案。
它能帮助你暴露那些你甚至没意识到缺失的需求。
很多时候，你提出的需求其实是不充分的。比如你说“让后端更快”，听起来很清晰，但实际上并不清晰。
在 Plan Mode 里，Codex 会追问：
- 哪些端点在关键路径上？
- 能否查看日志？
- 我们愿意做哪些取舍？
这种对话会帮助你厘清自己到底想优化什么。
下一步：持续追问关键问题
当你确定一个实现方向后，要继续深挖为什么它有效、它如何工作、还有哪些替代方案。
AI 的一个巨大优势是：尝试不同实现的成本几乎为零。你可以并行探索多个实现方案，再做更有信息量的取舍。
最后：主动进行找 bug 的深度探索
没有软件是没有 bug 的。Thibault 也提到，每次他和 Codex 做一次深入的找 bug 会话，总能挖出点东西：也许还不是立刻爆发的 bug，但往往是值得改进的潜在问题。
还有一个补充点：他们把许多最佳实践编码成可复用技能，并在 OpenAI 内部共享。如今他们已经拥有数百个这样的技能。
这显著提升了新同事入职效率，因为大家起步用的不是“空白版 Codex”，而是已经被优化过、升级过的版本。
这已经成为他们扩展知识、加速团队成长的重要方式。
他们的大量代码通过 Codex 生成
当然，仍然会有需要手工编辑代码的情况，但这种情况正在越来越少。OpenAI 内部的 Codex 应用非常成功，他们的大量设计、实现与日常工作都迁移到了 Codex 应用中完成。
至于“手写代码 vs 使用 Codex 的比例”，他们目前没有可以公开的精确数据。
但他们能说的是：Codex 应用会与其他工具形成互补，尤其是 IDE。Codex 可以利用 IDE 的上下文，例如当前打开了哪些文件，因此两者并行使用会非常顺畅。
在实践中，越来越清晰的一点是：很大一部分工作直接在 Codex 应用中完成，而手动编辑更多用于细节打磨。这两种工作流配合得非常好。
OpenAI 倾向于招聘“两种极端”的工程师
最后，我想分享一个很有意思的洞察，来自我最近与 OpenAI 工程负责人 Sulman Choudhry 的交流。
我之后会对 OpenAI 的整体工程文化做一次深度解析，敬请关注。
Sulman 提到，OpenAI 喜欢招聘两类工程师，走“两种极端”：
- 非常强的通才（generalists）
- 在某个非常具体领域里极其专业、同时又能跳出框架思考的人
我很认同这个偏好，因为强通才能放大团队每个人的努力，并能解决各种不同类型的问题。
而那些能跳出框架的人能够挑战“既定现状”，我喜欢把他们看作“破局者（disruptors）”：他们凭借独特的专业知识与视角，常常能带来决定性的差异。
我认为越来越多公司会采用类似路线，而对工程师来说，两条路径都是合理的成长方式。
我的建议是：发挥你的优势，想清楚你要成为强通才，还是在一个具体领域做到异常优秀。
结语
Codex 团队最突出的地方不只是他们构建的技术，更是他们重新想象了“在 AI 原生世界里，一个工程组织可以如何运作”。
他们以高度的信任、自主与速度运行：决策很快，所有权清晰，个人被赋能去端到端地构建与交付。
他们也真正把 AI 当作提升生产力的方式。AI 不是一个附带的效率技巧，也不是旁边的助手，而是一位一等公民般的队友：它参与规划、执行、审查、入职、迭代，并塑造了团队的运作方式。
最终结果是：一个能以初创公司级别的速度推进的团队，同时还在构建世界上最复杂的一类系统。