Codex 产品开发故事

半年前，很少有人相信 Codex 能追上 Claude Code。 那时，开发者几乎一边倒地沉浸在 Claude Code 里。 到了 2026 年夏天，风向变了，很多团队把主力工具切到 Codex，桌面端周活很快突破 500 万。 7 月，OpenAI 干脆把 Codex 桌面 App 改造成了新的 ChatGPT 桌面 App。 当初 ChatGPT 里一个标签页的边缘项目，反过来成了 ChatGPT 的底座。 但在这个爆款背后，过去一年 OpenAI 内部经历了剧烈的方向摇摆。

Claude Code 在本地跑起来时，Codex 在做云端的 Codex Cloud。 结果迟迟找不到 PMF，工程负责人还跳槽去了 Cursor。 退回本地后，面对 Claude Code 的领跑，接手团队的 Tibo 顶着「CLI 不够好用」的压力，把底层 Agent 彻底重写了一遍。 准备做原生桌面端的时候，又开始纠结要不要内置代码编辑器，因为其他家都在做。 结果得到新的更强的模型发布后，这个问题，又不是个问题了。

Codex 几乎把今天做 AI 产品要回答的问题都踩了一遍：模型能力每隔一两个月就变一次，产品形态到底该怎么选？ 明明看清了 Agent 的终局，为什么一步到位，反而会死在半路？ 在一家公司里，产品、工程和模型团队该怎么配合，才能把一个产品救活？ 文章作者，是硅谷 AI 机构 Every 的 CEO Dan Shipper。

从觉得 OpenAI 要失去「天命」，到半年后全团队切回 Codex、感叹「OpenAI 又回来了」，他深入采访了 Tibo、Alexander Embiricos、Mia Glaese 等 Codex 核心成员，还原了这款产品几次转向背后的完整故事。

以下是全文编译，经 Founder Park 编辑整理。原文：https://every.to/p/how-codex-happened

01 OpenAI 内部赛马， Codex 是好几条路线合起来的 打造一名 AI 程序员，是 OpenAI 追逐了太久的目标。 以至于 Codex 有过很多个起点，就连这个名字本身，也已经不是第一次出现。 第一代 Codex 发布于 2021 年。 它是一个在公开代码上微调过的 GPT-3 版本，后来为初代 GitHub Copilot 提供了底层能力。 真正让编程重新成为 OpenAI 重点方向的，是推理模型。 第一代大语言模型只能一个词接一个词地推演答案，既没机会提前规划，也无法在完成后回头修改。

推理模型不同，它在回复前，会先在一个叫作「推理轨迹」的草稿区里工作。 它可以从不同角度切入问题，发现走进死胡同时退回来，再选择一条更可能成功的路径。 OpenAI 将首个此类模型命名为 o1，并于 2024 年 9 月发布预览版。 在此之前，模型进步主要靠扩大规模、延长训练时间。 到了 o1，OpenAI 发现，同一个模型只要在难题上多花一点时间，答案就能变得更好。 有一类工作从中获益的程度远超其他所有领域，那就是编程。 编程尤其适合推理模型，因为它存在一个闭环。

模型可以修改代码、运行代码，并在几秒内看到改动是否生效。 它可以自行测试、修正，不需要每一步都由人来检查。 理论上，只要给足思考时间，推理模型可以独立完成任何编程任务。 在 o1 预览版展现出推理模型的潜力之后的几周里，编程重新成为 OpenAI 最高层级的目标。 来自管理层的一道指令，让 OpenAI 内部的好几个团队再次从不同方向出发，探索编程 Agent。 其中一个起点，来自 2024 年末的 Alexander Embiricos，后来的 Codex 产品负责人。

Alexander Embiricos 是在 2024 年早些时候加入 OpenAI 的，当时 OpenAI 收购了他联合创办的程序员多人屏幕共享工具 Multi。 加入 OpenAI 后，他继续推进一个相关构想，让人类和 Agent 在日常使用的应用里共同工作。 他先是在 ChatGPT 桌面应用上尝试，后来又参与 AI 浏览器 Atlas，但当时的模型读取用户屏幕既慢又笨，很难真正派上用场。 「我第一次真正产生那种强烈的『AGI 降临感』，是看到有人把推理模型接进终端运行。 」他对我说。

「我知道这放到现在已经不稀奇了，」但看着它读取文件、执行命令、自己处理错误，「真的酷毙了。 」在终端里，模型不需要去「看」屏幕，它们可以直接在文本和代码里干活。 看到早期推理模型在终端里的表现，Alexander Embiricos 确信它们完全可以驱动一款真正的编程产品。 当时编程还不是他的全职工作，但他立刻开始画产品草图。 他认为，要让这款产品行得通，用户必须每 30 秒、或者最多每分钟就能看到模型正在做什么。 问题又回到了速度。 当时，大多数 AI 编程产品都围绕 VS Code 生长。

GitHub Copilot 通过扩展提供 AI 自动补全，Cursor 和 Windsurf 则基于 VS Code 的开源代码构建自己的编辑器，在程序员工作的界面旁加入 AI 对话。 这些工具依赖紧密的反馈循环。 Copilot 补全你正在输入的那一行代码，Cursor 和 Windsurf 会在几秒内回答问题。 没有哪款产品会让模型独自工作很久，因为模型做不到。 OpenAI 的早期推理模型正好相反，一旦思考时间被掐断，它们就会变得既慢又弱。

他开始思考，能不能把模型得出响应需要漫长时间这个缺陷，转化成一种优势？ 与此同时，在 OpenAI 的另一边，大家称作 Tibo 的 Thibault Sottiaux，正试图让推理模型反过来作用于模型自身。 用它的能力，帮助研究员打造下一代模型。 「我大概是从 2024 年 12 月开始参与编程 Agent 的。 」他对我说，目标「是帮助我们更快地编写基础设施，更快地做研究」。 Tibo 职业生涯的大部分时间，都在为研究员搭建基础设施，先是在 DeepMind，后来是 OpenAI。

在 AI 的世界里，研究基础设施，也就是 AI 研究员用来运行、评估、复现实验并部署实验结果的共享代码，恰恰是无数核心突破发生的地方。 如果你能缩短跑一次实验所需的时间，就能跑更多实验，从而更快地拿到更好的模型。 Tibo 的团队并不是要面向大众做一款模型，是在 OpenAI 的 Monorepo（统一代码仓库，OpenAI 整个组织的代码都存放在这里）上训练内部使用的编程 Agent。 这些 Agent 负责编写 Python 代码，帮助研究员运行和改进那些用于训练新模型的系统。

研究员每天都在使用这些 Agent，也因此为团队提供了紧密的反馈循环。 「我们看到编程能力进步得非常快。 」Tibo 说。 他的团队频繁训练模型，使用的技术和公司大范围训练公众模型的方法并不相同。 甚至在相当长一段时间里，两边很难调和到一起。 这套方法很快奏效了，他们成功地让模型反过来参与创造模型的研究过程，研究员也正在用这些模型打造下一代模型。 工程师把这叫作「自举」（bootstrapping）。

先做出一个擅长帮研究员跑实验的模型，研究员就能用它造出一个更强大的模型，接着跑出更好的实验，再催生出更强的模型，如此循环往复。 当我问 Tibo 他们是在哪个时间点决定把 Codex 独立模型线从 ChatGPT 中拆分出来时，Tibo 语气平淡地说道：「从来没有什么拆分模型线的决定。 在最开始，这只是一次研究探索，以及对我们研发速度的一次优化。 」这项工作提供了后来 Codex 的一半，一个能够改进新模型研发基础设施的 Agent 。

但要成为一款公司其他人也能使用、最终还能走出 OpenAI 的产品，它还缺少另一半，Alexander Embiricos 关于人类应当如何与这些 Agent 协作的构想。 如果现在回看 2024 年末至 2025 年初的 OpenAI，OpenAI 总裁兼联合创始人 Greg Brockman 告诉我，当时悬而未决的问题是找到正确的「产品形态」。 Agent 究竟应该待在开发者执行命令的终端里、写代码的编辑器里，还是在云端拥有一台属于自己的电脑、独立工作？

有些路径最终被证明是死胡同，但在当时，没有人知道究竟是哪一条。 「从某种意义上说，OpenAI 是在押注一系列创业公司，只不过它们全都在公司内部。 」OpenAI CEO Sam Altman 在 2025 年接受 Ben Thompson 采访时说道。 这种内部并行探索的做法，在几位内部人士看来有时显得混乱且浪费，谁愿意待在那个「做出 OpenAI 内部第三好用的 Agent 产品」的团队里？ 为探索留出空间，与制造彻底的混乱之间，只有一线之隔。 但在技术前沿不断移动时，这种做法是必经之路。

借用已故哈佛大学教授 Clayton Christensen 的术语来说，模型层面快速的「延续性」进步，会让全新的应用形态成为可能，并不断颠覆前一代应用。 一个能补全一行代码的模型，很适合做成自动补全工具。 一个能思考 30 秒的模型，可以在聊天侧边栏里回答问题。 一个能连续工作一小时的模型，需要的则是完全不同的另一种形态。 围绕上一代模型做出成功的产品，并不意味着你就知道下一代该长什么样。 你需要让好几个团队去尝试不同的点子，等看清什么东西真正有用之后