“近十年最拼！”在OpenAI干满一年，工程师离职发文自曝：7周爆肝冲出智能体Codex、007成日常

最新推荐文章于 2025-07-17 15:42:13 发布

原创最新推荐文章于 2025-07-17 15:42:13 发布 · 8.9k 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能

在 AI 圈，顶尖公司之间“卷”得有多狠？是每天都在 push 到半夜，还是只要有想法，就能落地上线？OpenAI、Anthropic、Google DeepMind……这些前沿的 AI 公司日常是什么样的？

近日，一位离职员工用一篇长文，揭开了其中的一角。

他就是 Calvin French-Owen，曾深度参与 OpenAI 明星产品 Codex 开发的工程师。

Calvin 于 2024 年加入 OpenAI，并在三周前选择离职。在此之前，他是客户数据平台初创公司 Segment 的联合创始人（这家公司已于 2020 年被 Twilio 以 32 亿美元收购）。对他来说，进入 OpenAI 更像是一场“重新上场”的冒险，一次亲自站在前沿、体验技术爆发期的机会。

如今，他选择用这篇坦率又细致的回忆，讲述他在 OpenAI 工作的一年：从公司文化到日常开发节奏，从 GPU 成本到代码风格，从“第一行代码到 Codex 上线只花 7 周”的冲刺经历，到凌晨部署、清晨上线的高强度节奏——他说，那可能是他近十年来最拼的一段时间。

接下来，我们将通过本文透过一线工程师的视角，看清这家明星公司在急速扩张背后的真实模样。

原文：https://calv.info/openai-reflections

作者 | Calvin French-Owen 责编 | 苏宓

出品 | 优快云（ID：优快云news）

投稿或寻求报道 | zhanghy@youkuaiyun.com

以下为译文：

我在三周前离开了 OpenAI，而我是在 2024 年 5 月加入这家公司的。

之所以想分享一些个人感受，是因为业界有很多关于 OpenAI 的争议，但真正来自内部关于工作、文化的一手叙述却不多。

Nabeel Qureshi（作家）曾写过一篇很棒的文章《Reflections on Palantir》，他在其中回顾并思考了美国软件与服务公司 Palantir 的独特之处。我也想趁着记忆还非常清晰的时候，为 OpenAI 写一篇类似的内容。这里不会提及到什么商业机密，只是我想分享一些亲身感受——关于这家有意思的公司，在一个特别关键时期的真实样子。

先说在前头：我离开的决定并没有什么私人恩怨——其实我当时非常纠结。作为曾经的创业者，转而成为一家拥有 3000 名员工公司的普通一员，这种转变确实不容易。

现在的我，更想要重新开始。

当然，未来我也有可能会再次被 OpenAI 的工作氛围吸引而重新加入。毕竟，能参与构建 AGI 这样的事，是很难再遇到的；而大语言模型无疑是这十年最重大的技术创新。我感到幸运，曾亲身见证了一些关键进展，也参与了 Codex 的发布。

显然，这些只是我个人的看法，并不代表公司立场。OpenAI 是一个庞大的组织，而这只是我所看到的一隅。

OpenAI 的企业文化——“自下而上”

关于 OpenAI，首先要知道的一点是它增长得有多快。

我加入的时候，公司好像刚超过 1000 人。一年后，员工数量已超过 3000，而我竟然已经排进了工龄前 30%。几乎所有领导层成员现在做的事情，和他们 2–3 年前的角色完全不同。

当然，组织扩张这么快，各种问题很快都会出现，譬如公司内部沟通方式、汇报结构、产品交付流程、人员管理和组织方法、招聘流程等等。

不同团队之间的文化差异也非常明显：有的团队一直在高速冲刺各种新项目，有的在盯着大规模训练，有的则节奏稳定地去推进项目。不存在某种“统一的 OpenAI 工作体验”，因为研究、应用和 GTM（go-to-market）团队运行的时间尺度完全不同。

OpenAI 一个非常特别的地方是——一切，真的是一切，都在 Slack 上进行。没有电子邮件。在我工作的一年中，我可能只收到了不到 10 封的邮件。如果你缺乏自我管理能力，这种工作方式可能令你分心。但只要你精心筛选频道和通知，其实是可以很好用的。

OpenAI 非常强调“自下而上”的文化，尤其是在研究团队。刚入职时，我开始询问下一个季度的研究路线图时，得到的回答是：“这个东西不存在”（虽然现在有了）。好点子可以来自任何人，而且在事前往往很难判断哪些想法最终会产出成果。与其说是遵循一张宏大的“蓝图”，不如说进展是通过不断迭代、在研究产生成果的过程中逐步实现的。

也正因为这种“自下而上”的文化，OpenAI 的组织运作非常“精英主义”。历史上，公司里的领导者往往是因为他们能提出好想法，并能亲自推动落地而被提拔的。很多能力极强的领导并不擅长在全员大会上发言或搞职场政治——但在 OpenAI，这些事情的重要性远不如其他公司。只要有真正好的想法，通常就能脱颖而出。

OpenAI 整体有非常强的“动手偏好”（bias to action），你可以直接动手去做事。不同团队会不约而同地想到相似的点子也是常见的。我刚加入时参与了一个类似 ChatGPT Connectors 的内部项目。当时大概已经有三四个 Codex 的原型在内部流转，最后才决定推进其中一个版本发布。这类项目通常是几个人在没走流程的情况下自己搞起来的，等到项目有前景后，团队会迅速围绕它组建起来。

Codex 的负责人 Andrey 曾经对我说：你应该把研究员当作“小型高管”来看待。确实，大家都倾向于自主挑选项目然后看看能做到哪一步。也有一种普遍共识是：大多数研究项目是靠“诱捕式 nerd-sniping”推进的——只要某个问题让研究员产生兴趣，他们就会全情投入。如果一个问题被认为“无聊”或“已解决”，基本不会有人继续做。

优秀的研究主管极具影响力，但数量也极为有限。最优秀的那批人，能把不同研究方向之间的点连起来，最终推动大模型训练的集成。产品经理也是如此（特别提名一下 ae）。

我合作过的 ChatGPT EM（工程经理）——Akshay、Rizzo 和 Sulman，是我见过最酷的一批人。他们见多识广，对流程了如指掌，大多采用“少干预、放权用人”的管理方式，努力确保团队能成功推进。

OpenAI 的方向调整可以说是瞬间转弯。这点在我以前的公司 Segment 就很看重——当你获得新的信息时，做出正确决策远比死守旧计划重要。OpenAI 能在这么大体量的情况下依然保持这种文化，实属罕见——Google 显然做不到这点。公司决策迅速，一旦确定方向，就会全力以赴。

一直以来，OpenAI 也受到极大关注。作为一名来自 B2B 企业背景的员工，这对我来说有点震撼。我经常看到媒体抢先发布的新闻，连公司内部都还没宣布。我一说自己在 OpenAI 工作，别人就已经对公司有一套成型看法。有些 X（Twitter）用户甚至用自动化 bot 来监控是否有新功能即将发布。

因此，OpenAI 是个非常保密的地方。我无法向任何人详细说明我在做什么。内部有多个 Slack 工作区，不同权限层级划分明确。公司的营收和支出数据也被严格保护。

OpenAI 也比你想象的更“严肃”，部分原因是因为大家都感觉“赌注极高”。一方面，公司的目标是构建 AGI——意味着很多东西必须做对；另一方面，我们也在构建一个数亿人使用的产品，涵盖从医疗建议到心理治疗等敏感用途；再者，我们正参与全球最大规模的竞争。这意味着我们密切关注 Meta、Google、Anthropic 的动态，我相信他们也在盯着我们。几乎所有主要国家都在密切关注这一领域。

尽管 OpenAI 经常被媒体批评，但我接触到的每个人都是真心想把事情做好。作为最面向消费者的大模型实验室之一，公司自然成为攻击焦点。

话虽如此，你也不应该把 OpenAI 看作一个整体、单一意志的“巨石”。在我看来，OpenAI 更像是当初的洛斯阿拉莫斯实验室（Los Alamos）。最初是一群科学家和爱折腾的工程师，在研究科学的最前沿，结果“意外”打造出史上最火的消费级应用。接着公司又扩展出向政府和企业销售的野心。组织内部，不同工龄和不同团队背景的人有着截然不同的目标与世界观。工龄越久的人，越倾向于从“研究实验室”或“公益非营利”的角度看问题。

我最欣赏的一点是：OpenAI 确实兑现了承诺——将 AI 的红利普惠分发。最新模型并没有只提供给签年单的大客户。全球任何人都可以打开 ChatGPT 获取答案，哪怕不登录账号也行。开发者可以申请 API 来接入使用——即使是 SOTA 或专有模型，通常也会很快开放在 API 中供创业团队调用。我们完全可以想象一种完全不同的做法，但 OpenAI 并没有那样做，这一点非常值得肯定。这种“普惠思维”仍是公司文化的核心。

关于安全，可能跟你从 Zvi 或 Lesswrong 那些地方读到的有所不同：OpenAI 内部其实非常重视安全问题。我看到更多是对“现实风险”的关注，比如仇恨言论、滥用、操纵政治偏见、生化武器、自残、提示注入等，而不是所谓的“理论风险”，比如智能爆炸或模型主动寻求权力。当然，也确实有人在研究后者，但从我所见，这并不是工作的重心。大多数相关工作都没有对外发布，OpenAI 应该多做些对外公开。

和其他科技公司在校园招聘或行业活动上热衷发放各种带有品牌标志的纪念品（swag，例如 T 恤、贴纸、水壶、帽子等）不同，OpenAI 几乎不发放这些东西，甚至连刚入职的新员工也不例外。只有偶尔开放“限量抢购”，有库存才能买。第一次开放就直接把 Shopify 商店干崩了。后来内部还有帖子教大家怎么发 JSON 请求来绕过系统。

最后说个现实层面：几乎所有开销相比 GPU 成本来说都可以忽略不计。打个比方，你就能明白：我们在 Codex 里做的一个非常小众的功能，它消耗的 GPU 资源，居然和我以前在 Segment 时整套基础设施的花费差不多（虽然 Segment 没有 ChatGPT 那么大规模，但它也支撑着不小的一部分互联网流量）。

OpenAI 可能是我见过野心最大的公司。你可能会觉得，拥有像 ChatGPT 这样的顶级消费级应用已经很了不起了，但他们远不满足于此，还想在很多领域同时竞争：比如 API 服务、前沿研究、硬件设备、编程智能体、图像生成，甚至还有一些还没公布的项目。在这里，只要你有想法，就能找到机会把它做出来、跑起来。

此外，OpenAI 内部对 Twitter 上的动态关注程度也超出想象。如果你发了条关于 OpenAI 的相关内容还引发了“病毒式”的传播，很可能有人会看到并认真考虑。我有个朋友打趣说：“这家公司靠 Twitter 氛围驱动”，作为一家面向消费者的公司，可能还真有点道理。当然，我们依然有很多数据分析工作要做，比如使用频率、用户增长、留存率等等，但“氛围感”确实同样重要。

OpenAI 内部团队的流动性远比其他公司高。当我们推进 Codex 时，需要 ChatGPT 那边几个经验丰富的工程师帮忙冲刺上线。于是我们找几个 ChatGPT EM 开了个会提了下需求，第二天就有两位强援直接加入投入工作。没有“等季度规划”或“重新调整人员配置”那一套，节奏非常快。

OpenAI 的领导层也保持时常“在线”，而且参与感很强。这可能听起来不稀奇，但在 OpenAI，几乎每个高管都很上心。你经常能在 Slack 里看到 gdb（Greg Brockman）、sama（Sam Altman）、kw（Karpathy）、mark、dane 等人亲自发言、参与讨论，没人只是挂个名、当个甩手掌柜。

代码：很多基础设施都有点像 Meta

再来谈谈有关 OpenAI 的内部代码开发、管理。

OpenAI 使用一个巨大的 monorepo（单体代码库），主要以 Python 为主（不过现在也有越来越多的 Rust 服务，另外还有一些用 Golang 写的服务，通常用于网络代理这类场景）。

由于 Python 写法极其多样，这也导致代码风格千奇百怪——你可能会看到既有来自 Google 老兵为大规模系统设计的库，也有刚毕业的博士写的临时性 Jupyter Notebook 脚本。几乎所有服务都围绕 FastAPI 来构建 API，使用 Pydantic 进行参数校验。不过公司并没有强制执行统一的代码风格指南。

OpenAI 的基础设施全部部署在 Azure 上。有趣的是，整个 Azure 平台里，我认为真正靠谱的服务只有三个：Azure Kubernetes Service（AKS）、CosmosDB（Azure 的文档型数据库）以及 BlobStore（对象存储）。Azure 并没有 Dynamo、Spanner、Bigtable、BigQuery、Kinesis 或 Aurora 这样的对应产品。自动扩容的概念在这里也不像在 AWS 那样常见。IAM（身份与权限管理）系统的能力也远不如 AWS。整体上，公司倾向于自己造轮子来解决问题。

从人员构成来看（至少在工程团队里），有一条非常显著的“Meta → OpenAI”人才通道。从很多方面看，OpenAI 很像早期的 Meta：一款爆款的消费级应用、基础设施刚起步、以及一种强烈“快干快上”的文化。我见到的大多数基础设施人才，都是从 Meta 或 Instagram 那边过来的，实力都很强。

结合这些因素，可以看出 OpenAI 的很多核心基础设施组件，风格都很像 Meta。例如内部重写了一版 TAO（Meta 的社交图存储系统）；又比如做了一项将身份认证统一至边缘节点的整合尝试；类似的项目我相信还有很多我没接触到的。

Chat 贯穿了整个系统架构。自从 ChatGPT 爆火之后，很多代码都围绕“对话消息”和“会话”来构建。这些原语已经深深植入系统架构中，忽视它们基本等同于自找麻烦。Codex 项目虽然在这方面有所偏离，但我们依然借鉴了很多现有成果。

OpenAI 的工程文化是“代码为王”。公司没有什么中央架构委员会或产品计划委员会，通常都是哪个团队要做事，就自己拍板。这种机制带来一个明显的结果：动手能力强，但也容易出现多个重复实现。我见过五六个不同的库都在处理队列管理或 agent 循环控制之类的功能。

当然，这种工程团队极速扩张而工具建设不完备的状态，也确实会带来问题。比如 sa-server（后端单体服务）基本成了个“垃圾堆”；CI（持续集成）在主分支上崩掉的频率，比你想象的要高；测试套件哪怕并行执行、并只选部分依赖，也要跑近 30 分钟才能在 GPU 上完成。

这些问题虽然不至于无法解决，但确实是提醒我们：工程规模一旦暴涨，这类问题一定会出现，而且还可能更严重。值得肯定的是，内部很多团队正致力于改善这些问题。

其他我学到的东西

什么叫“大型消费品牌”：直到我们开始做 Codex，我才真正理解这件事。在 OpenAI，所有衡量指标都围绕“Pro 订阅用户”展开。哪怕是 Codex 这种偏工具类产品，我们也主要以“个人使用者”的视角来设计引导流程，而不是从“团队使用”角度出发。对我这种 B2B / 企业软件背景出身的人来说，这种模式一开始完全打破了我的认知。只要按钮一开，流量马上就来了。
大模型是怎么训练出来的？简单来说，整个过程从“小试验”到“大工程”是一条渐进的路线。一开始，大多数想法都是先做个小规模的实验，看看效果如何。如果结果不错，才会被加入到更大规模的训练中。这个“试验”阶段不仅仅是调整算法本身，还包括调整训练用的数据配比，并且要非常细致地分析结果。等到真正开始大规模训练时，那就不只是算法的事了，更像是在做一个超大规模的分布式系统工程。你会遇到各种奇怪的边角问题，甚至一些完全没预料到的 bug——而这些都得靠你自己去排查解决。
怎么估算 GPU 要用多少？在 Codex 上线前，我们得提前预测系统的负载需求，这也是我第一次认真去做 GPU 的性能评估。关键的一点是：你不能一上来就研究一块 GPU 能撑多少任务，而应该先从你对产品性能的要求出发，比如：整体响应时间、生成多少个 token、多久能给出第一个 token 等。这些需求决定了你要多少 GPU。而且每一代新模型的计算方式和负载模式可能都不一样，所以用旧经验来估算，很多时候会失准。
如何在大型 Python 代码库中工作：以前我所在的 Segment 公司主要用的是 Golang 和 TypeScript，而且以微服务为主，远不如 OpenAI 的代码库庞大。这里我学到很多：当有大量开发者同时维护一个仓库时，你必须增加各种“防误操作”机制，比如“默认可用”、“主干分支保持干净”、“不容易被误用”等。这些都需要通过规范和工具来系统性保障。

Codex 上线记：全身心投入，7 周开发一个产品出来

我在 OpenAI 的最后三个月，几乎全都投入到了 Codex 的发布中。可以说，这是我职业生涯中最精彩的经历之一。

事情的起点要从 2024 年 11 月说起，当时 OpenAI 定下了一个 2025 年的目标：发布一款编程代理工具。到了 2025 年 2 月，我们已经有一些内部工具在使用大模型做得有模有样了，同时也开始感受到越来越大的压力：我们必须发布一个专门为编程打造的智能体。很明显，模型的能力已经发展到真正能“干活”的程度——从市面上一波接一波的 vibe-coding 工具爆发就能看出端倪。

为了参与 Codex 的冲刺，我提前结束了育婴假回到岗位。一周后，我们经历了两个团队的（略显混乱的）合并，随后就进入了紧张的冲刺模式。

从动第一行代码到正式发布，这个产品只花了 7 周时间就完成了。

那段时间的强度，可能是我近十年来工作最拼的一次。几乎每天都加班到 11 点甚至半夜，早上 5:30 被刚出生的宝宝叫醒，7 点又进办公室，连周末也常常在工作。我们每个人都在全力冲刺，因为每一周都至关重要。那种感觉，就像重回 YC（Y Combinator）时期一样。

很难用言语表达我们推进速度之快有多不可思议。无论大公司小公司，我都没见过哪个团队能从一个点子起步，在如此短的时间里上线一个完整、开放的产品。而且 Codex 的范围也不小：我们构建了容器运行环境，对代码库下载流程做了优化，微调了一个专门用于处理代码编辑的模型，支持各种 Git 操作，设计了全新的交互界面，还接入了互联网访问，最终交付出一个真正好用的产品。

无论你对 OpenAI 有什么看法，这家公司至今仍保留着那种“冲刺发布”的精神。

幸运的是，我们有一群“对的人”，因此才能实现这些“魔法”。我们的核心团队包括约 8 名资深工程师、4 名研究员、2 位设计师、2 位 GTM 和一位产品经理。如果不是这批人参与，我觉得我们不可能做成。每个人都很独立，不太需要被管理，但确实需要相当多的协调。如果你有机会和 Codex 团队的任何一位成员共事，请相信——他们每一个人都很棒。

上线前一晚，我们五个人熬夜干到了凌晨 4 点，才把主服务部署好（整个过程花了好几个小时）。接着早上 8 点又赶回办公室，准备发布公告和直播上线。

我们一开通功能开关，流量立马就开始涌进来。我从没见过一个产品光是出现在 ChatGPT 左边的菜单栏里，就能立刻带来这么大的使用量——这就是 ChatGPT 的影响力。

在产品形态设计上，我们最终选择了完全异步的交互模式。与 Cursor（当时尚未支持此模式）或 Claude Code 不同，我们允许用户发起任务，让智能体在自己专属的运行环境中执行。我们的基本判断是，长远来看，用户应当像与同事协作一样使用智能体：你发送一条消息，智能体执行任务，然后回来给你一个 Pull Request。

当然，这是一个有点冒险的判断。现在的模型能力处在一个“略显尴尬”的阶段：它们可以连续工作几分钟，但还做不到持续数小时。用户对模型的信任程度也差异很大。而我们自己也不完全清楚这些模型的真正上限到底在哪里。

但从长期来看，我相信大多数程序开发都会逐渐演变成类似 Codex 的方式。至于在这个过渡阶段，各类产品会如何演化，也值得我们持续关注。

Codex（毫不意外）非常擅长处理大型代码库，理解并导航其中的结构。与其他工具相比，它最大的优势是可以并发启动多个任务，并对比它们的输出结果。

最近我看到一组公开数据，统计了不同 LLM 智能体生成的 Pull Requests 数量。Codex 截至目前已经生成了 63 万个 PR。平均下来，在上线后的 53 天内，每位工程师贡献了 7.8 万个公开 PR（私有 PR 的数量估计更高）。我不确定自己是否还会参与到比这更有影响力的项目了。