OpenAI Codex深度解析：AI如何重塑开发与团队协作，洞察AINEWS前沿

type

status

date

slug

summary

category

icon

password

网址

近日，OpenAI Codex 产品负责人Alexander Embiricos和OpenAI 的开发者体验（Developer Experience）负责人Romain Huet 一起做客播客，聊了不少 Codex 背后的故事。

很难想象，Codex团队在去年5月时总人数才只有8人左右，那时候Alexander是团队中唯一的PM（产品经理），到现在团队人数已增长到50人以上，增长速度惊人。

这场播客里，两位嘉宾一边聊产品，一边“不小心”透露了不少外界平时听不到的内部细节。比如Codex团队在开发新功能时极少撰写详尽的技术文档，Codex的开发就没有具体文档。再比如，Codex开发的最初思路包括高可配置性、不阻碍模型发挥能力和为向Agent委派任务而设计新的交互页面。

还有一些细节也很有意思。比如OpenClaw的创始人一直都在为Codex提供反馈和改进建议，Openclaw很大程度上就是用Codex开发的。在Codex团队中，设计师现在使用AI写的代码比半年前一个工程师写的还多，大家都变成了“构建者”。对于OpenAI，招人只看重高能动性和作品，不在意名校学历。

在对谈中还有不少趣事。Alexander讲到Codex新功能还没在生产环境上线，就有心急的用户钻进开源代码库自己改代码硬跑，跑报错了还跑去推特上向官方投诉说功能坏了。不得不说，Codex的核心用户活跃得夸张，都到“边等更新边自己抢跑”的程度了。

而Romain则分享了身边的一件轶事。他的一个朋友睡前在任务管理软件（Linear）上列了一堆产品想法，命令AI去实现并划掉。第二天一早醒来，AI居然真的把活全干完了。过去觉得是科幻的场景，如今都正在一点点变成现实。

以下是访谈的全部内容，请各位enjoy：

Codex团队写文档非常少，最多十条左右

主持人：好的，欢迎大家。今天我非常激动能邀请到来自OpenAI Codex团队的 Alexander 和 Romain 。

Alexander&Romain：谢谢。谢谢邀请。是的，很高兴能交流。

主持人：我很想知道你们在团队内部到底是如何用Codex构建产品的，Alexander？你现在还会写技术文档吗？或者你会让GPT写文档？在这种工作中，你会使用哪个模型？

Alexander：是的，我想我们在Codex团队写文档非常非常少。实际上，我认为很多工作都是让最接近底层的人尽可能多地做决定。我们唯一会写文档的时候，是当那个问题大到很难装进一个人的大脑里时。

顺便说一下，现在一个人脑子里能装下的东西非常多，因为他们可以将大部分编码工作委派出去。所以一个人能做很多事。但如果这变成了一件需要多人协调，或者是一个非常棘手的决策，那么也许我们会写一份文档。但在这些情况下，我们写的文档往往非常短。我们说的也就是10条要点左右，仅此而已。

主持人：你们能给我展示一下这是怎么运作的吗？比如你给Codex几个要点，然后它也许先写出具体的需求文件？

Romain：我们可以那样做。但我也想向你展示一个更简单的场景。想象一下回到我刚才提到的那个iOS应用，它现在正在完成一项任务。假设你对那个新项目有一些新功能的想法，但你不太确定该往哪个方向走。

现在用Codex非常令人兴奋的一点是，如果我开始说“让我们规划一下后续步骤”，你可以看到Codex已经自动理解了我正试图为下一步构建什么制定计划。如果我按Shift+Tab，它将进入“计划模式”（PlanMode）。如果我问“我们应该构建什么”，我可以把Codex当作头脑风暴的伙伴。

在这种计划模式下，它会查看代码，查看我们目前项目的进度，提出想法，然后我也可以加入自己的想法，开始引导模型制定一个好的计划。

基于此，你可以看到，例如在此时此刻，Codex根据它正在查看的文件产生了一些想法。它实际上会提示我给出一些引导：我们该做什么？是应该继续做刚才那个阿尔忒弥斯的想法？还是对可靠性看板进行一次优化？也许我会说，是的，优化可靠性不错。等等，我们应该为谁进行优化？我可以这样使用Codex。当然，这里我没给输入。在Alexander的案例中，作为产品负责人，我相信你会预先给出更多引导，但这里我算是让Codex自己发挥了一些创意。

Codex设计师现在写的代码比六个月前的一个工程师还多，方向选择和保证质量变得更重要

Alexander：很有趣，我经常这样做并引导它们。通常我会……好吧，变动有几种类型，对吧？有超简单的变动，你直接进去，给个提示词，搞定。

然后是中等复杂度的变动，也许你会推理一下怎么做，或者要求一个特定的计划。但我实际操作中会做一些类似的事情：如果我有一个模糊的想法，我可能会直接进入Codex，让它开始思考如何解决一个问题。我甚至还没有一个明确的功能构想，然后它会去探索，问我一些问题。

在我的案例中，我往往最后甚至不会真的去用那个生成的代码，因为那可能是一个非常复杂的变动。抱歉这里扯远了，但“PM写什么代码”是一个很有意思的话题，我们可以回过头再聊。对于复杂的变动，我实际上并不想负责上线和维护它，但我仍然会走一遍计划模式和探索的过程，这样我就能对我们需要做的事情有一个更好的心理模型。然后这个“思考过程”——而不是计划本身——就成了我与工程师分享的东西。

简单补充一下刚才的跑题：Codex团队的设计师现在写的代码，比6个月前一名工程师写的还要多。他们简直是“大神”级别的。当然，工具在其中起到了巨大的作用。

团队以前还笑话我去年没提交多少个PR。我不会告诉你具体数字，但我心想：确实应该更多一些。尤其是考虑到其中很多只是非常微小的调整。但我感觉我们现在正处于一个阶段，重点不再是“你能否生成代码”——Agent已经很惊人了，你可以委派任务给它。现在的重点变成了：你决定做的这件事是否真的超级重要？我们对于这个产品将变成什么样是否达成了一致？

另一方面是，我们如何确保这东西真的是高质量的？有些团队会自豪地说“整个应用都是凭感觉写出来的（vibecoded）”。但在Codex的案例中，虽然绝大部分代码是由Agent生成的，但我们仍然投入了大量的精力和注意力去思考系统，确保它是高品质的。所以，如果是一个非常复杂的功能，我通常会确保有一个更稳健、可靠的负责人（Owner）去接手。我不认为PM适合长期持有这些系统，PM的部分价值在于他们可以非常跳跃、到处参与，所以你不一定希望PM负责维护这些代码系统。

主持人：完全同意。你肯定不希望PM去维护功能代码。那听起来不像个好主意，我觉得我们会把事情搞砸。

Codex的产品开发思路：高可配置性，产品不阻碍模型发挥

主持人：好的。市面上还有一些其他的专业工具，我也很喜欢它们，但你必须花大量时间去学习它们。我总觉得如果我不上推特（Twitter），我根本不知道该怎么用那些产品。而我真正喜欢Codex的一点是，这个应用用起来非常简单，非常直观。但它也有一些非常高级的功能，比如“技能”（Skills）和“自动化”（Automations），对吧？你们内部会用这些东西吗？

Romain：会，用得非常多。事实上，我认为“技能”是Codex应用界面中最令人兴奋的功能之一。比如，想象一下你正和使用Figma的设计师配对工作。现在开启Figma技能太棒了，它可以直接从Figma文件中提取细节、所有的React组件和变量，然后Codex会相应地实现代码。

再比如你在构建一个应用，你可能想分享它，部署到Vercel、Cloudflare或Render。这些技能就在那里，你只需要告诉Codex该做什么，它基本上就会连接到这个任务生态系统中。

有件事挺逗的，前几天晚上我和一个朋友聊天，他告诉我他有很多改进产品的想法，于是他让Codex把所有这些任务都写在Linear（任务管理工具）上，这样就能随时跟踪进度。最后他说：“好了，我现在要去睡觉了，你去把我刚才讨论的所有任务都实现了并划掉它们。”果不其然，他醒来时，一切都真的完成了。

主持人：太神奇了。回到你刚才提到的应用简洁性，我觉得分享一下我们是如何思考设计它的，可能会很有趣。

Alexander：是的。在这个领域构建产品有一点非常有趣：开发者喜欢为自己做工具。所以我认为产品中一个非常重要的部分是它的高度可配置性。对我们来说，Codex的harness是开源的，你可以深入研究。每当我们构建一个新功能时，我们甚至还没在生产环境启用，就会在推特上收到投诉说这个功能坏了——因为人们已经钻进代码库，自己改代码或者分叉（fork）代码来让这些新功能跑起来了。

对我来说，这是产品中非常棒的一部分。这意味着你的前沿用户正和我们一起生活在未来，并把我们拉向那个未来。但另一方面，如果你只为这类人构建产品，你最后会得到一个几乎无法理解的东西，你得像你刚才说的那样整天泡在推特上。

所以我们有一种观点：我们会非常谨慎地确定我们要构建的核心原语（primitives）是什么。那是会被明确记录下来的地方，而不是随性而为。我们会深思熟虑：如何让产品几乎处于隐形状态，不挡模型的事，让模型发挥。模型每变强一点，它就能做得更多。

从那出发，我们如何以尽可能可配置的方式为高级用户封装这些功能，让他们能弄明白它是什么？例如，目前市面上已经有一个“子Agent” 的实现。人们正在使用和实验，我们从他们身上学到了很多，尽管我们并没有在产品中主动触发它。它只是用户可以了解并使用的东西。然后我们通过观察人们如何使用它来学习，进而思考：我们如何让它对其他所有人来说都变得超简单？

实际上Codex应用就是一个例子。大概在去年12月 GPT-5.2 Codex 发布的时候，突然之间，模型虽然只是在稳步进步，但我们越过了一个临界点：你可以开始向模型委派更长任务，而它无论如何都能一次性搞定。

于是我们看到人们已经在玩“t-muxing”（多路复用）了——对于不知道的人来说，就是人们已经在终端里并行运行很多任务。我们在社交媒体上看到了一些疯狂的图片，比如Peter Steinberger（OpenClaw创始人）有一张照片，开着18个终端，横跨三台显示器。

看到人们以这种非常高级的方式使用Codex，我们非常兴奋。我们不断确保CLI等基础产品中的委派功能表现良好。但接着我们想：也许前1%的工程师会那样工作，但我们如何让这感觉更直观呢？

于是我们开发了Codex应用。你启动它，它感觉非常简单，就像个聊天框。它会干活。但接着你会发现：噢，有个侧边栏；噢，我可以运行多个任务；噢，在任务之间切换非常容易。现在我自己也变得非常高效。接着你会发现：啊，还有一个“技能”标签页。我们试图让它感觉像玩游戏一样，你只是在不断发现下一步。

Romain：完全正确。我认为我们从一开始就有这样一个愿景：编程将以这种“Agent委派”的方式进行。即使我们在快一年前开始做Codex时，我们就一直在思考这样一个未来：作为工程师，你会并行处理多件事。但坦率地说，当时的模型还没到那个水平。

我认为我们需要看到 GPT-5.2 Codex 及其后续版本带来的拐点，看到模型能够超级彻底、可靠地连续工作数小时甚至数天。到那时，你就会觉得：在终端里开多个标签页并让它们运行好几个小时，这种交互界面太奇怪了。所以我们需要一个新的交互界面，我认为Codex应用的时机变得非常完美。

Alexander：Codex 历史上经历了两次“氛围转变”。第一次是八月。我们发布了 CodexCloud 产品，那是个好主意，人们很兴奋，但有点早了。八月左右我们发布了 GPT-5，一个很棒的交互式编程模型。我们心想：好，让我们去解决目前模型能解决的问题。于是发布了 CodexCLI 和 IDE 插件，增长开始爆炸。我记得几个月内我们增长了20到30倍，这太棒了。

然后第二次转变是在12月或1月左右，我们终于可以回到那个“向模型委派任务”的愿景中了。

在OpenAI没有中期计划，Codex的开发没有PRD

主持人：让我们深入聊聊 Codex 应用的开发。你们一年前有类似“年度路线图”的东西吗？比如规划好“我们要在此时发布CodexApp”？还是说你们看到市场在做这些事，然后原型设计了一堆东西？这东西是怎么造出来的？

Alexander：呃，其实都不是。我从这里的一位研究员 Andre 那里得到了一个非常好的建议。他的建议是：在 OpenAI，你执行短期计划或长期计划，但永远不要做中期计划。

这太难了。短期是指从现在起最多八周。八周是绝对的极限。什么是你可以激励团队团结起来并完成的具体事情？这是我们在OpenAI非常擅长的——围绕一件想做的事让团队集结。

另一件你能做的事是拥有一种“感觉”（vibe）。比如，一年后我们的模型会变得聪明得多。它们将能够……我把时间往回拨一点。现在我说的这些可能显而易见，而且不到一年就实现了。但当时你可能会想：“是的，我们会拥有模型，而我们不希望把自己的电脑‘借’给它们干活，因为那样我们一次只能做一件事。我们想要无限多的模型，它们独立工作，验证自己的成果，甚至自己部署和监控代码，我们甚至不需要给它们提示词。”所以你会超前思考这种“氛围”。

而中间的那种东西，也就是产品路线图，我们基本没有。我们将“长期方向”与“我们认为能带我们走向那个方向的事物”结合在一起。

例如，在Codex应用的案例中，我们的战略目标之一是“与特定的工作空间解耦”。这听起来有点抽象。我的意思是，如果你使用像VSCode这样的IDE（这是我最喜欢的IDE），你打开它时是针对一个特定的工作空间的，对吧？那是代码的一个特定切出（checkout），一个特定的文件夹。即使你使用gitworktrees，一次也只能打开一个。所以你基本上一次只能处理一件事。

命令行（CLI）也是如此。因为我们有那个愿景：我们希望人们与他们在云端委派的、独立工作的Agent协作。我们知道我们需要达到一个状态：让你觉得同时与多个Agent交谈，或者让一个Agent为你协调多个Agent，感觉非常自然。

然而我们也学到，如果你直接从云端开始，开发者很难获得价值。因为你的工具不在那，你得设置环境。如果任务只完成了一半，你很难获得“部分功劳”，因为你可能需要跳进去纠正或检查。

所以我们觉得：我们需要一种本地体验，它既与特定文件夹分离，但与你电脑上的文件夹协作时又感觉非常直观。

当我们开始做这个App时，我们脑子里有一堆这种“虚无缥缈”的氛围思考。然后我们有一堆工程师自发构建的原型，他们只是觉得“我希望有个App”。当时有各种版本。实际上在一次“黑客周”里，好几个独立的人构建了不同版本的App。

所以项目启动时，唯一需要写下来的东西就是“为什么我们认为构建一个App是个好主意”。这个App本身并没有具体的文档。最终我们是通过构建过程生成了一个文档，但实际上过程挺有争议的：我们到底应不应该建个App？IDE插件已经很受欢迎了，我们是不是该专注改进它的质量？那CLI呢？CLI也是个东西啊。如果我们建了App，它的意义是什么，我们要走向何方？这些事通常就是这样开始的。

Romain：幸运的是，我们当时已经有了打磨得非常好的IDE插件方案。你可以在VSCode、Cursor、Windsurf等工具里使用它。所以我们从那个插件的代码库中学到了很多，拥有了一个已经很稳健的高起点。

Alexander：是的。实际上，这个App与IDE插件共享很多代码。在底层，App和插件都连接到同一个用Rust编写的核心CodexHarness，它是开源的，CLI也在用它。所以有很多共享和刻意的分层。

但决定构建这个App，现在看来很明显，因为用Codex App确实比开一堆终端窗口容易得多。但当初的决策核心是：它对新手友好，像是在玩。它是同时管理多个代理的最佳界面。

我想说我们的思维方式是……我们非常坚信AGI（通用人工智能）。所以我们在思考：我们正滑向什么样的未来？

所以，我会把顺序调转一下：更像是我们知道需要建立一个让人感觉委派给多个Agent非常自然的界面，因为我们知道模型迟早会为此做好准备，或者事实上我们已经看到人们在跨Agent委派了。所以我们需要一个自然、且能很好地扩展到云端、且符合人体工程学的界面。它不应该让你觉得是在费劲地弄清楚如何同时委派给多个Agent，它应该让你觉得：显而易见，你就想这么工作。

Romain：顺便说一下，这不仅吸引初级开发者，恰恰相反，即使是OpenAI最资深、产出最高的工程师——从Peter Steinberger到Greg Brockman，他们现在都把这个App作为主要的构建方式。所以这是“Agent委派”愿景的实现，它不只是给新手用的，“最顶尖的工程师留在终端里”这种说法已经过时了，他们也在转向这个App。

Alexander：希望如此。我们一直在提Peter，因为他刚加入OpenAI，我们非常兴奋。我不知道有没有跟你说过，去年10月我在旧金山的FortMason跟他散步。我当时没直接告诉他我们要建个App，但我开始试探这个想法，一种能让委派感觉很自然的新界面。他当时基本上跟我说，他永远不会用这种东西。结果上周末他在推特上发：实际上这个App挺好用的。是的，简直是太阳从西边出来了，“我居然喜欢上它了”。

主持人：我也跟Peter聊过。如果你能让他去用这个App，那真是一个巨大的成就，因为他平时都是开20个终端窗口的。

Alexander：没错。我得跟进一下，他可能两者都在用，谁知道呢。

Codex负责人是如何度过一天的

主持人：Alexander，你有一段时间是Codex唯一的PM对吧？那Codex团队有多少人？50到100人左右？

Alexander：听起来差不多。在那个区间。我们去年五月的时候大概只有八个人？

Romain：是的，差不多。

Alexander：我记不清准确数字了，但从那以后我们增长得非常快。大概是在50到100人的范围。

主持人：这很有意思。那你平时怎么分配时间呢，兄弟？典型的一天是什么样的？还是说根本没有“典型的一天”？

Alexander：噢。就我而言，我最近也在想这个问题，因为我发现我不知道该怎么回答。我意识到我有几种不同的工作模式。这不是建议，只是我个人的情况。

我想我有一种模式，比如在我们发布App之前，那就是纯粹的执行：痴迷于质量，确保我们没有遗漏任何细节，搞定每一个小环节。在那档模式下，我会花大量时间泡在Codex里。我们倾向于用Codex来理解发生了什么——我经常用它来理解Slack上的动态：我们得到了什么反馈？我会让Codex去总结，然后发到Linear上。所以有很多“利用Codex了解质量状况”的工作。

然后还有很多利用Codex去了解代码，并用它来做改动。因为现在，对于那些不是构建新系统的小变动——再次强调，我尽量避免干涉新系统，但会照顾现有系统——发送一个经过测试的高质量PR，通常比去跟某人沟通并让他们优先处理这项任务要快。尤其是当我们目标是在两周内发布一个App，而他们手头有10,000件事要做的时候。

所以有这种模式。当然，还有很多人力方面的工作，比如啦啦队、动员，以及对自己构建的东西保持批判眼光。有趣的是，如果我经常发推特，通常说明我正处于这种模式下。

然后还有另一种模式，比如现在：我非常清醒地意识到我们正处于这样一个阶段——我们拥有惊人的模型，GPT5.4非常不可思议。我们也有了这个比预期更受欢迎的App体验，并且它已经覆盖了包括Windows在内的所有平台。

所以现在在我脑子里，我在想：好了，是时候真正回归云端并在那加大投入了。当我们进入这种阶段时，我会花更多时间思考该做什么，去理解现状。这是一种协调模式，实际上我花在Codex里的时间变少了——我更多是用...