OpenAI Codex 产品负责人亲述：没有规范和路线图，我们是怎么做出产品的？

整理 & 编译：深潮TechFlow

嘉宾：Alex，Codex 产品负责人；Romain，Codex 开发者体验

主持人：Peter Yang

播客源：Peter Yang

原标题：How OpenAI's Codex Team Builds with Codex (43 Min) | Alex & Romain

播出日期：2026年4月5日

要点总结

Alex 是 Codex 的产品负责人，Romain 负责开发者体验。他们让我难得地深入了解了 Codex 团队的运作方式，包括他们如何使用 Codex 构建产品，以及如何在没有传统的产品规范和路线图的情况下进行产品发布。Alex 还分享了一些关于产品经理 (PM) 未来发展的独特见解，以及在招聘中真正重要的因素。

精彩观点摘要

实时构建与 Codex Spark 的“思维速度”

• “当你想构建什么东西……你可以切换到快速模式甚至是 Codex Spark，你就能拥有这种疯狂的思维速度，来构建任何东西。在左边是 GPT-5.4，在右边是 Codex Spark，平均每秒就能有大概 1200 个数据（tokens），这速度太疯狂了。” ——Romain

关于规格文档与决策流程

• “我觉得我们在 Codex 团队写的规范文档非常非常少，其实我觉得大量的工作是让最接近实际的人做出尽可能多的决策，所以我们只有在问题最终变成那种很难装进一个人脑子里的问题时才会写规范。” ——Alex

职业边界模糊与设计师的进化

• “我们团队的设计师现在写的代码量比六个月前的工程师还要多，现在我们的重点已经不再是‘能不能生成代码’，真正重要的是：我们决定做什么，以及如何确保产品的高质量。这也是为什么对于非常复杂的特性，我更倾向于找到一个稳健的负责人来管理，而不是让产品经理 (PM) 去负责这些系统的落地和维护。” ——Alex

产品设计哲学：让模型“隐形”

• “我们对核心功能的设计非常谨慎，确保它们不会成为用户和模型之间的障碍，而是让模型更加智能，自动完成更多任务。” ——Alex
• “然后在此基础上，我们思考如何以尽可能可配置的方式将产品打包给高级用户，让他们自己去探索和使用。比如，现在已经有用户实现了 sub-agents（子智能体）。”——Romain

规划哲学：拒绝“中期的尴尬”

• “在 OpenAI，我们要么规划短期目标，要么规划长期目标，但从不做中期规划，因为中期规划太复杂了。短期规划通常指的是从现在起最多八周的目标，八周是我们能设定的最长时间范围；我们也会制定长期的愿景。例如我们可能会展望一年后的未来，设想那时的模型会变得更加智能；然，中期规划就显得有些尴尬，它通常表现为一个详细的产品路线图，但我们基本上没有这种东西。我们更多的是结合长期愿景，专注于那些能够推动我们实现目标的具体任务。” ——Alex

“智能代理委托”带来的界面变革

• “编码将以一种‘智能代理委托’ (agentic delegation) 的方式进行。你会觉得，在终端中打开多个标签并让它们运行几个小时是一种非常奇怪的交互形式。我们需要一个全新的界面，而那个时机恰好非常完美。” ——Romain

职业阶梯的消失与“人才栈坍缩”

• “这几乎让每一条传统的职业晋升阶梯都开始变得模糊了。我们每个人其实都是“构建者 (builder)”，大家共同协作完成构建。如果一个初创公司有 PM，而工程师少于 20 人左右，那可能是一个危险信号。兴趣和自主性是 AGI 时代人类最核心、最重要的品质。” ——Romain / Alex

招聘标准：作品胜过简历

• “当有人通过私信表示对加入我们团队感兴趣时，我的第一反应是看有没有作品链接。如果有链接我总是点开，了解他们是否真的在构建东西，我更愿意看他们的想法以及他们实际构建的东西。我完全不知道这些人上的是什么大学。” ——Alex

现场演示：用 Codex Spark 在几秒钟内构建一个游戏

主持人 Peter：我今天非常兴奋地主持 Alex 和 Romain，他们来自 OpenAI 的 Codex 团队。他们将演示如何构建 Codex 的新功能，Codex 是什么能力，以及 Codex 团队如何不停地发布产品。你们想不想快速展示一下实际上可以用一次性提示（one-shot）构建什么样的东西？

Romain：

当然，让我分享我的屏幕，其实有非常多东西我可以展示，但也许快速看一眼——比如，这里是我一直在构建的一个 iOS 应用。如果我想为这个应用创建一个新功能，我可以简单地通过口述说："嘿，你能为 NASA 的月球返回任务添加一个新屏幕吗？"然后我用 GPT-5.4 发送这个提示，然后模型就会为这个特定的 APP 创建一个新屏幕。

但我们也有 Codex Spark 模型，它可以帮助你在短短几秒钟内对任何东西进行构思和迭代，让我给你展示一下 Spark 模型快速响应的差异。在左边是 GPT-5.4，在右边是 Codex Spark。然后平均每秒就能有大概 1200 个数据，这速度太疯狂了。所以当你想构建什么东西，比如一个游戏——就在我们开始这次对话之前，我实际上去了 Codex 应用，用一个快速提示创建了一个类似 Animal Crossing 的小 2D 游戏。

当我思路清晰时，我非常喜欢在 Codex 用的另一个功能是，打开 Codex，把对话浮在屏幕顶部，这样如果我真的在做这个游戏，我可以继续迭代并产生更多想法。你有什么想法吗，Peter，对于你想在这个游戏上做什么改变？

Peter：也许添加一些更多的装饰、房子、树木之类的，让它更生动一些？

Romain：

那么我将发送这个任务，然后基本上在几秒钟内 Codex Spark 就能进行编辑，我们会实时看到变化，然后就好了，我们已经看到新的树木出现了。

所以这就是为什么我对 Codex 如此兴奋，你真的可以拥有像 GPT-5.4 这样的前沿模型，它可以承担非常复杂的任务，比如分析或迁移数百万行代码。但如果你灵感涌现又思路清晰的时候，你可以切换到快速模式甚至是 Codex Spark，你就能拥有这种疯狂的思维速度，来构建任何东西。

对于产品规范，我们只写大约 10 条要点，仅此而已

主持人 Peter：我真的很好奇你们在团队里实际上是如何用 Codex 构建产品的，Alex，你们还写规范吗？或者你们让 GPT 写一个规范？你们用哪个模型来让这些东西工作？

Alex：

我觉得我们在 Codex 团队写的规范文档非常非常少，其实我觉得大量的工作是让最接近实际的人做出尽可能多的决策，所以我们只有在问题最终变成那种很难装进一个人脑子里的问题时才会写规范。顺便说一下，现在一个人可以往脑子里装很多东西，因为他们可以做很多事情——他们把大部分编码工作都委托出去了，所以一个人现在可以做很多。但如果它最终变成需要跨几个人协调的事情，或者也许是一个我们必须做出的非常棘手的决策，那么也许我们会写一个规范。但是我们在这些情况下写的文档往往非常非常短。我们说的就是像 10 条要点之类的，然后就没了。

主持人 Peter：好的。你们能给我展示一下这是怎么工作的吗？比如你给 Codex 几条要点，然后也许它先写出实际的需求？

Romain：

当然可以！不过，我想先给你展示一个更简单的例子。假设我们在开发一个 iOS 应用，它目前已经完成了一些任务。现在，你对这个项目有一些新功能的想法，但还不确定具体的方向。这个时候，Codex 的强大之处就在于它能够帮助我们规划下一步的工作。比如，我只需要按下 Shift+Tab 键进入“计划模式” (Plan Mode)，然后输入“我们要构建什么”，Codex 就会自动帮我生成一个初步的计划。它会分析现有的代码库，理解项目的当前状态，并提出一些潜在的想法。与此同时，我也可以加入自己的想法，引导模型生成一个更加完善的计划。

在这个过程中，你会发现 Codex 会根据当前的代码和文件提供一些建议。比如，它可能会问：“我们是否应该继续完善之前提到的功能？还是应该优化可靠性仪表板？”如果我们决定优化可靠性仪表板，它还会进一步引导我们思考：优化的目标用户是谁？整个过程就像与一个头脑风暴伙伴合作一样。

我经常用这种方式来驱动想法的产生。比如，对于一些简单的改动，我会直接输入提示，让 Codex 生成代码。

Alex：

而对于那些中等复杂度的改动，我可能会让它生成一个具体的计划，或者帮我推理实现的方式。而当我有一个模糊的想法时，我通常会直接打开 Codex，让它帮我思考如何解决问题。即使我脑海中没有明确的功能需求，Codex 也能通过提问和探索帮我理清思路。

不过，坦白说，有时候我并不会直接使用 Codex 生成的方案，特别是当改动比较复杂时。我会通过 Codex 的“计划模式”进行探索，形成一个清晰的思路，然后将这些想法分享给工程师团队。最终，这个思考的过程比生成的计划本身更重要。

顺便一提，我们团队的设计师现在写的代码量比六个月前的工程师还要多，这在以前是不可想象的。这主要得益于工具的进步，让设计师能够更深度地参与到开发中。不过，我也经常被团队调侃去年提交的 PR（代码合并请求）太少。虽然很多改动只是一些小调整，但我确实觉得自己应该多做一些。

现在，我们的重点已经不再是“能不能生成代码”，因为智能体 (Agent) 已经能完成大部分编码任务，真正重要的是：我们决定做什么，以及如何确保产品的高质量。这也是为什么对于非常复杂的特性，我更倾向于找到一个稳健的负责人来管理，而不是让产品经理 (PM) 去负责这些系统的落地和维护。

设计师写的代码比 6 个月前的工程师还要多

主持人 Peter：Codex 的应用程序用起来非常直观和简单。与外面一些专业产品相比，我觉得 Codex 的学习曲线低得多。其他一些专业产品虽然功能强大，但需要花费大量时间去学习。我甚至觉得，如果我不在 Twitter 上关注相关的信息，我可能根本不知道该怎么用它们。

但 Codex 让我印象深刻的一点是，它不仅简单易用，还提供了许多高级功能，比如 skills（技能）和 automations（自动化）。你们团队内部会经常用这些功能吗？

Romain：

是的，我们用得非常多，实际上我认为 skills 是 Codex 应用中最有趣的功能之一。举个例子，现在如果你和一个设计师一起使用 Figma，只需要打开 Figma 的 skill，就可以直接从 Figma 文件中提取所有的 React 组件、变量等细节，然后 Codex 会自动生成相应的代码。再比如如果你正在开发一个应用程序，想要将它分享或者部署到 Vercel、Cloudflare 或 Render，只需通过 skills 下达简单的指令，Codex 就会自动完成这些任务。

我最近和一个朋友聊天，他告诉我有很多改进产品的想法，于是他对 Codex 说：“把这些任务全部写到 Linear 上，方便我追踪。”然后他使用了 Linear 的 skill。接着，他又告诉 Codex：“我要去睡觉了，你继续完成我们刚才讨论的所有任务，并把它们标记为完成。”结果他第二天醒来时，发现所有任务真的都完成了。

Alex：

关于你刚才提到的应用程序的简单性，我觉得可以分享一下我们是如何思考其设计的。在这个领域里，开发者普遍热衷于为自己构建自动化工具，以简化日常工作。我们认为，产品的一个关键特性是它必须高度可配置。对于 Codex 来说，它就像一个开源的工具箱，用户可以深入其中，根据自己的需求进行定制。

每次我们推出新功能时，总会有用户在 Twitter 上抱怨这个功能（即使它还没正式上线）有问题，而问题的原因通常是他们自己修改了代码或 fork 了它。但在我看来，这恰恰证明了我们的产品成功，因为这些前沿用户正在与我们共同探索未来，并推动产品的进步。

然而我们也意识到，只有为这些高端用户构建产品是不够的，否则，产品最终会变得复杂难懂。我们必须找到平衡点，既要满足高级用户的需求，也要让产品对普通用户来说简单直观。因此我们对核心功能的设计非常谨慎，确保它们不会成为用户和模型之间的障碍，而是让模型更加智能，自动完成更多任务。

Romain：

然后在此基础上，我们思考如何以尽可能可配置的方式将产品打包给高级用户，让他们自己去探索和使用。比如，现在已经有用户实现了 sub-agents（子智能体）。这些功能并不是我们主动设计的，而是用户自己发现并实验出来的。通过观察用户如何使用这些功能，我们学到了很多东西。

接着我们会思考：如何让这些功能对其他用户来说也变得超级简单？Codex app 就是一个很好的例子。大约在 GPT-5.2 Codex 于去年 12 月发布时，模型的能力开始逐步稳定，但也越过了一个临界点。用户可以开始将更长时间、更复杂的任务委托给模型，而模型可以一次性完成这些任务。

我们开始注意到，有些用户已经在使用 tmuxing（在终端中运行多个并行任务），这是一种在终端中分割窗口以同时运行多个任务的方式。我们在社交媒体上看到了一些非常有趣的例子，比如有一张 Peter Steinberger 的照片，他的屏幕上有 18 个终端窗口，跨越了三个显示器，看起来就像一种“创意的开放式爪子”。我们看到用户以这种非常高级的方式使用 Codex，感到非常兴奋。

同时，我们继续优化基本产品（如 CLI）中的任务委托功能，确保它们运行良好。但我们也意识到，可能只有顶尖的 1% 工程师会使用这种方式工作。于是我们思考：如何让这些功能看起来更加直观？这就是为什么我们开发了 Codex app。

当你第一次打开 Codex app 时，它看起来就像一个简单的聊天窗口。你可以直接开始使用它，它会正常工作，但随着时间的推移，你会逐渐发现更多功能，比如侧边栏、运行多个任务的能力，以及在任务之间轻松切换的功能。你会觉得自己变得超级高效。然后你可能会注意到“skills”标签，点进去探索更多功能。我们希望用户在使用 Codex app 时，能有一种几乎像玩游戏一样的体验，不断发现新的可能性。

Romain：

完全同意。而且，这也正是我们从一开始就有的愿景：编码将以一种“智能代理委托” (agentic delegation) 的方式进行。甚至在我们差不多一年前开始开发 Codex 时，我们就一直在思考这个未来。我们相信，工程师将能够同时处理多项任务，而模型会负责执行复杂的细节工作。

不过坦白说，当时的模型能力还没有达到这个水平。我们必须等到 GPT-5.2 Codex 的发布，以及之后的那个临界点，看到模型能够非常彻底、可靠地工作几个小时甚至几天。到了那个时候，我们突然意识到，传统的终端界面已经不再适合这种工作方式。你会觉得，在终端中打开多个标签并让它们运行几个小时是一种非常奇怪的交互形式。于是，我们需要一个全新的界面，而那个时机恰好非常完美。

Alex：

回顾 Codex 的发展历程，我们经历了两个重要的“vibe shift”（趋势转折点）。第一个是在去年八月，我们推出了 Codex Cloud 产品。那是一个非常棒的想法，用户当时非常兴奋，不过当时可能还稍微有些早。于是我们在八月发布了 GPT-5 这个非常出色的交互式编码模型，并决定专注于解决模型当前能够处理的问题。我们因此推出了 Codex CLI 和 IDE 插件，用户量在几个月内迅速增长了 20 到 30 倍，这真是太棒了。

第二个转折点是在去年 12 月到今年 1 月之间。那时，我们终于实现了最初的愿景——将任务委托给模型。模型的能力达到了一个新的高度，能够独立完成更复杂的任务，这标志着我们进入了一个全新的阶段。

我们的规划分为短期和长期，从不做中期规划

主持人 Peter：我很好奇 Codex app 是如何开发出来的？你们一年前是否制定了某种年度路线图，比如“我们计划在某个时间点推出 Codex app”？还是说，你们更多是观察市场需求，快速原型化了一些想法？

Alex：

其实都不是。我从我们的研究员 Andre 那里听到过一个非常棒的建议：在 OpenAI，我们要么规划短期目标，要么规划长期目标，但从不做中期规划，因为中期规划太复杂了。

短期规划通常指的是从现在起最多八周的目标，八周是我们能设定的最长时间范围。在这个时间框架内，我们会设定一个具体的目标，集结团队全力以赴去完成它。这是 OpenAI 的一个强项——我们非常擅长围绕一个明确的目标组织团队。

另一方面，我们也会制定长期的愿景。例如，我们可能会展望一年后的未来，设想那时的模型会变得更加智能。比如，我们可能会想象未来的模型可以独立工作，不再需要借用我们的电脑资源，也不再局限于一次只能完成一件事。我们希望拥有无限多个模型，它们可以独立完成任务、自我验证代码，甚至能够自我部署和监控，而我们完全不需要手动提示它们。

然而，中期规划就显得有些尴尬。它通常表现为一个详细的产品路线图，但我们基本上没有这种东西。我们更多的是结合长期愿景，专注于那些能够推动我们实现目标的具体任务。

以 Codex app 为例，当时我们的一个战略目标是将用户从特定的工作空间 (workspace) 中解放出来。传统的开发工具（比如 VS Code）通常是绑定到一个特定的工作空间的，比如一个代码库的特定检出点或文件夹。即使使用 git worktree，一次也只能打开一个工作目录，CLI 也是类似的限制。

但我们的愿景是：用户能够与云端的智能代理 (agent) 协作，而这些 agent 可以独立工作。我们希望用户能够同时与多个 agent 进行交互，甚至让一个 agent 为用户协调多个 agent 的工作，这种体验应该是自然且直观的。

同时，我们也意识到，如果一开始就完全依赖云端，开发者可能会觉得不够方便，因为他们需要配置环境，而在模型执行任务时，如果需要手动干预或调整，也会变得麻烦。因此我们决定开发一个本地化的体验，它既能够与本地文件夹无缝协作，又能与云端的智能代理保持连接。

当我们开始开发这个应用程序时，我们有一堆这样的“愿景思考”，这些是一些比较抽象的想法。与此同时，我们的工程师也在进行各种原型设计。他们会说：“我希望我们能有一个应用程序。”于是就开始尝试开发各种不同的版本。实际上，我们还举办了一次“黑客周”活动，多个工程师独立开发了不同版本的应用程序。你可能也参与了，我记不太清了。

当这个项目真正启动时，我们唯一需要明确写下来的就是：为什么我们认为开发一个应用程序是个好主意。我们并没有为这个应用程序制定具体的产品规范，我们是通过实际的开发工作逐渐明确了产品的方向。

不过，当时这个项目还是有一些争议的——我们是否真的需要开发一个应用程序？我们的 IDE 插件已经非常受欢迎了，我们是否应该专注于提升插件的质量？CLI 也很有潜力。那么，如果我们要开发一个应用程序，它的意义是什么？我们应该朝哪个方向努力？这就是这个项目开始时我们面临的一些问题。

Romain：

是的，幸运的是，当时我们已经有了一个非常成熟的 IDE 插件解决方案，并对其进行了深入优化。用户可以在 VS Code、Cursor、Windsurf 以及其他 IDE 中使用这些插件。我们从 IDE 插件的代码库中积累了大量经验，这为开发 Codex app 提供了一个非常稳健的起点。

Alex：

没错。实际上，Codex app 和 IDE 插件在底层共享了大量代码。它们都连接到同一个核心的 Codex harness，这是一个用 Rust 编写的开源框架，CLI 也使用了它。我们有意采用分层设计，以便在不同工具之间实现代码共享和功能扩展。

主持人 Peter：至于决定开发 Codex app 的过程……现在回头看，这似乎是一个显而易见的决定，因为使用 Codex app 比打开一堆终端窗口要直观得多。但当时我们下这个决定的理由主要是：Codex app 对初学者来说更加友好，同时它也是管理多个智能代理协作的最佳界面。

Alex：

我认为，我们团队的思考方式深受 AGI（通用人工智能）愿景的影响。我们一直在思考：未来的工作方式会是什么样子？

其实我会换个角度说，我们很清楚我们需要一个界面，让用户能够自然地将任务委托给多个智能代理。我们知道未来的模型将具备这种能力——事实上，我们已经看到用户在尝试跨智能代理进行任务委托了。我们需要一个界面，让这种协作方式显得顺理成章，同时能够无缝扩展到云端。

我们希望这个界面符合人体工程学设计，让用户觉得与多个智能代理协作是一种直观自然的体验，而不是需要复杂的操作或技巧才能实现。

Romain：

是的，而且这个应用程序的受众不仅仅是初学者，实际上即使是最资深、最有经验的工程师，包括 OpenAI 内部的顶尖工程师，比如 Peter、OpenClaw 和 Greg Brockman，他们现在都开始将 Codex app 作为主要的开发工具。这表明我们关于智能代理委托 (agentic delegation) 的愿景正在逐步成为现实。

Alex：

是的。我们提到 Peter 是因为他刚刚加入 OpenAI，我们对此感到非常兴奋。去年十月，我在旧金山的 Fort Mason 和他散步时，提过开发一个新界面的想法。我说我们希望有一种新的界面，让任务委托 (delegation) 变得更加自然，当时他告诉我，他永远不会使用这样的东西。

但是上周末，他发了一条推文说：“其实这个应用程序还挺好用的，我现在喜欢它了。”

Alex 作为 Codex 产品经理 (PM) 的日常工作内容是什么

主持人 Peter：Alex 你之前有一段时间是 Codex 团队里唯一的产品经理 (PM)，对吧？现在 Codex 团队有多少人？大概是 50 到 100 人之间吗？

Alex：

差不多，大概就在这个范围内。我们在五月份的时候大概只有 8 个人，我不记得确切的数字了。但从那以后我们的团队增长得非常快，现在大概是在 50 到 100 人的范围内。

主持人 Peter：那么平时你是如何分配时间的？你的日常工作是什么样的？还是说你根本没有一个典型的工作日？

Alex：

我最近也在思考这个问题，因为我发现自己很难回答。我意识到，我的工作模式其实是分阶段的，这只是我个人的方式，并不一定适合所有人。

比方说，在我们发布 Codex app 的时候，我完全处于执行模式。那时候，我的全部精力都放在产品的质量上，确保我们没有遗漏任何细节，把每一件小事都落实到位，这种模式下我会花很多时间使用 Codex 工具。

我们会用 Codex 来获取反馈，比如了解 Slack 上的讨论内容，以及用户的反馈。我会让 Codex 总结这些信息，然后将它们记录到 Linear 上。除此之外，我还会用 Codex 来分析代码质量，并直接用它来进行小的代码修改。因为有时候直接用 Codex 处理一些小问题，比去找其他人协调任务并让他们优先处理要快得多，尤其是在我们目标是在两周内发布应用程序的情况下。

在这个过程中，当然还有很多人性化的工作，比如为团队加油打气、激励大家，同时也要对我们正在开发的产品保持批判性。其实我发现自己是否处于执行模式，可以通过我是否频繁使用 Twitter 来判断。我也不知道为什么，但当我需要与人交流时，我就会更多地使用 Twitter。

然后还有另一种模式，比如现在，我的脑海中非常清楚：我们已经达到了一个新的阶段。我们现在有了非常强大的模型，比如 GPT-5.4 表现非常出色。我们的应用程序体验也超出了预期，已经覆盖了所有平台，包括 Windows。所以现在我觉得，是时候真正回到云端了，并在那里投入更多精力。

当我们进入这种阶段时，我会花更多时间去思考接下来该做什么，以及了解当前的状态，这是一种协调模式。在这种模式下，我花在 Codex 上的时间会变少，更多地是用 Codex 来进行沟通，而不是写代码。所以，我至少有这两种工作模式，当然可能还有更多。

主持人 Peter：你们需要进行多少跨职能的对齐工作？

Alex：

我们在团队内部几乎不需要进行太多的跨职能对齐工作，我们有点故意把自己看作是一个像“海盗船”一样的团队。即使在 Codex 团队内部，现在也只有我和最近加入的两个新的产品经理。我们有一些负责人，虽然直到最近大家基本上都直接向我汇报，但我们基本上是以一种模糊的方式一起推进项目，所以团队内部的对齐工作并不多。

不过，现在越来越明显的是，构建 Codex 的一个重要部分是开发这个 coding agent。而且大家现在也越来越清楚，coding agent 不仅仅可以用来写代码，它在其他任务中也非常有用。

比如，我们发现用户使用 Codex app 不仅仅是为了写代码。他们用它来完成整个软件开发生命周期中的各种任务，而且现在整个 OpenAI 的大多数员工都在使用 Codex app，即使是非技术人员，我也经常看到他们在使用这个应用程序。

所以这种认知让我们意识到，我们需要思考如何让 Codex 不仅仅对开发者有用。这就需要更多的跨职能对齐，因为作为 OpenAI，我们还有 ChatGPT，很多用户都在使用它，因此我们需要非常慎重地考虑如何将这些产品更好地结合起来。

Romain：

从我的角度来看，我们的开发者体验团队现在有点像是 Codex 团队的延伸。我们的大部分精力都花在 Codex 上，主要有几个原因。

首先，这是一款非常令人兴奋的产品，开发者们非常喜欢使用 Codex，我们希望让它变得更加出色。正如 Alex 所说，我们的工作模式也分为几个阶段，我们会与 Codex 团队一起投入到产品发布的准备工作中，比如准备发布所需的素材，以及教开发者如何最大化地利用 Codex。发布之后，我们还会引导开发者探索 Codex 在不同场景中的应用。

另一个让我们感到非常有趣的地方是，如果你看整个 OpenAI 的平台，今天已经有数百万开发者在使用我们的 API，构建从图像到语音等各种模态的应用程序。

现在最好的开发方式已经变成了以 Codex 作为入口点。如果你回到一年前，或者甚至去年夏天我们刚刚推出 GPT-5 的时候，我们还需要编写很多指南，教大家如何为 GPT-5 编写 prompt。GPT-5 是一个推理能力非常强的模型，与 GPT-4 有很大的不同。而现在，我们尝试让开发者即使在这些用例中，也能通过 Codex 和 skills 来完成任务。

比如，如果你需要更新一个集成系统，我们会建议你使用 Codex 和它的技能功能。结果是 Codex 几乎可以完全帮助你完成任务。因此我们的团队也非常注重跨职能协作，并将 Codex 视为整个 OpenAI 开发者平台的基石。

Alex：

我觉得我们 Codex 团队在工作方式上有一个很有趣的特点——对我来说，最棒的部分就是和社区的互动。无论是在线上，还是在现实生活中的活动现场，我们都非常注重与社区的联系。

在产品发布时，我们的工作非常以发布为导向——明确什么时候发布什么内容；同时，我们也非常以反馈为导向——每当社区提供反馈时，我们会迅速采取行动，修复问题并与他们沟通。所以我们的团队一直保持高度的在线状态，我觉得这是非常重要的。

比如说，当我们发布 Codex app 的时候，我们和 Dom 以及他的团队合作得非常紧密。他们帮助我们组织了一次大规模的 alpha 测试，邀请了大量用户参与，共同开发产品。通过他们的反馈，我们不仅改进了应用程序，还完善了 skills 和文档等相关资源。

我觉得这正是我们 Codex 团队的独特优势所在：因为我们是开源的，我们对自己所做的一切都保持高度的透明，而社区也对这种做法给予了巨大的支持和回馈。

主持人 Peter：我们来聊聊 Peter（OpenClaw 的创始人），我是 OpenClaw 的早期用户。你们是如何将 Peter 整合到团队中的？这个个人智能体 (personal agent) 的愿景，是不是和他目前的工作有关？你们是怎么规划的？

Alex：

有两方面可以说。首先，Peter 是 Codex 非常重度的用户。实际上，OpenClaw 很大程度上是用 Codex 构建的。他通过自己的使用体验向团队提供了大量反馈，这些反馈极大地帮助我们改进了 Codex，虽然这只是他的“兼职”，但他真的非常投入，我们对此感到特别兴奋。

其次，我现在不能透露太多细节，但可以说的是，他正在帮助我们构建下一代个人智能体 (personal agent)，并将其直接集成到 ChatGPT 中。

Romain：

我觉得 Peter 的工作中最让我着迷的一点是，当大家在使用 OpenClaw 的时候，可能已经隐约看到了未来的可能性，但让我感到震撼的是 Peter 很早以前就看到了这个愿景。

如果你回顾整个 2025 年，他在去年开发了 40 多个开源项目，而这些项目都围绕着一个核心愿景：通过命令行界面访问他的日历、推文和 Gmail 等个人工具。他通过这些项目，实际上将 skills 和命令行工具的愿景变成了现实。而我们今天使用的编程智能代理 (coding agent) 正是基于这个愿景构建的。

未来，这个智能代理将不仅仅是一个编程工具，它会变成任何类型的个人智能体 (personal agent)。因此，Peter 在这个过程中为我们提供了非常宝贵的反馈，因为他已经开发了许多现在成为开源生态系统核心部分的工具。

主持人 Peter：

我觉得像 Peter 这样的人，能够构建出如此出色的开源社区，真的令人钦佩。他的工具非常好用，以至于让我都不想打开其他任何应用程序了。我只想和我的小机器人聊天。

Alex：

你把它连接到什么系统上了？你是把它连接到所有东西上了吗？

主持人 Peter：

没错，我把它连接到了很多服务上。比如它可以访问我的银行信息、YouTube 账户、语音助手、日历以及 Google 服务。当我躺在床上的时候，我的妻子会问我：“你在和谁说话？”我会回答：“我在和我的 OpenClaw 机器人聊天。”

不过，现在有很多“投机者”会收取高达 5000 美元的费用来帮助别人设置 OpenClaw。所以如果你们能让它变得更大众化、更容易上手，那将是一个巨大的突破，你们确实在朝着正确的方向努力。

传统的职业晋升阶梯已经不再适用

主持人 Peter：我记得你们曾说过类似“现在大多数团队已经不需要那么多 PM 了”这样的话？

Romain：

我觉得这些工具最让我感到惊叹的一点是，这不仅仅是关于 PM 或者是否需要 PM 的问题。这几乎让每一条传统的职业晋升阶梯都开始变得模糊了。以前我们有明确的分工：设计师负责设计，工程师负责开发，PM 负责管理，可能还有一个特定的比例，就像某种“黄金比例”。

但是现在，如果你是一个工程师，你的生产力显著提高了。如果你是一个设计师，你能够通过这些工具获得超能力，变得更加技术化。如果你是一个 PM，以前只能写策略文档，而现在你可以直接原型化。这并不意味着你需要为数十亿用户负责某个功能，但你确实可以用这些工具真正去构建一些东西，向团队展示你的愿景。

所以，我觉得最让我着迷的是，现在所有职业阶梯之间的界限都在模糊。我们每个人其实都是“构建者 (builder)”，大家共同协作完成构建。

Alex：

我记得我在网上某个地方说过，如果一个初创公司有 PM，而工程师少于 20 人左右，那可能是一个危险信号，也许我确实说过类似的话。

我觉得就像你说的，现在所有这些角色都在逐渐融合。设计师可以做更多的工程工作，工程师可以涉足设计，PM 也可以参与构建。但工程师通常需要专注于写代码，因此他们以前不会处理任务分拣或其他 PM 的项目管理部分。

不过现在，这些事情变得非常容易了。你可以直接让 agent，比如 Codex，去分析反馈和优先级，这样工程师就能腾出更多时间专注于自己的工作。我觉得现在每个人都能做其他人的工作。

Scott Belsky 提出过一个想法，叫“人才栈的坍缩 (collapse the talent stack)”。我喜欢这个观点，我觉得这确实正在发生。房间里需要的人越少，事情就会进展得越顺利，每个决策也会更加清晰。

所以问题就变成了：PM 还能做什么？我觉得有很多 PM 其实应该考虑转岗。比如说如果你是一个 PM，一直想成为工程师，但你更擅长管理人，而工程能力不强，那么现在也许你可以成为一名工程经理 (engineering manager)。有了智能代理，对你来说这可能是一个更加明确的角色。类似地有些 PM 可能更倾向于成为设计师，更接近实际的构建工作。

我认为最终还是取决于个人的兴趣。对于我来说，兴趣和自主性是 AGI 时代人类最核心、最重要的品质。所以，如果你更感兴趣的是写代码，而你之前只是因为需要有人做 PM 的工作才从事这个角色，那么现在你完全可以转型为工程师，从工程的角度继续完成同样的事情。设计领域也是一样。

但如果你真正感兴趣的是和用户互动，即使这会让你远离实际的构建工作，比如尝试理解用户需求、洞察市场趋势等，那么在一个团队足够大的情况下，PM 仍然有发挥作用的空间。

Romain：

我再补充一点，我仍然认为每个问题都需要一个人类来负责这个问题领域，但我不认为这个人必须是 PM，我觉得这很大程度上取决于产品的性质。

我们在这里非常幸运，因为我们在为 Codex 工作，这是一个面向开发者的工具。我们自己就是最好的用户。而且因为它是开源的，我们可以直接与社区互动，进行联合开发。

但如果你回到十年前，比如我在 Stripe 工作的时候，当时公司有 250 人，却没有一个 PM，甚至没有任何 AI 工具。为什么？因为 Stripe 是一个 API 产品，我们所有人都是工程师，对什么是一个优秀的 API 有着非常直觉的理解。我们当时构建的正是我们梦想中的 API，一个只需要几行代码就能实现的优雅解决方案。

但如果你所处的是一个不同的领域，比如工程师对用户的需求没有那么多直觉，那么你可能就需要更多的 PM 来与客户沟通，理解他们的需求。尤其是当你服务的行业或领域与工程师的直觉不完全匹配时，PM 的作用会更加重要。不过我们在 Codex 团队中非常幸运，因为我们正在构建的正是我们自己也想要使用的工具。

Alex：

在这种环境下，PM 的角色可能只是一个标签，指代的是那个对用户最感兴趣、最关心用户需求的人，这个人完全可以是一个非常贴近用户的工程师。所以，我觉得这些职业标签正在逐渐失去传统的意义，虽然有点混乱，但这并不是坏事。

主持人 Peter：

我在自己的团队中也有类似的发现。我觉得最好的工程师不会问我“接下来我们应该构建什么”，他们会主动去和用户交流，自己弄清楚需要开发什么，然后再跟我讨论，这种方式让大家的目标非常一致。

Romain：

这其实就是我们 Codex 团队的工作方式，今天在 Codex app 中使用的许多功能，实际上都是工程师从下到上 (bottom-up) 提出的绝妙创意，因为他们自己也需要这些功能。

Alex：

不过我想说的是，有一种工程师的类型是我非常喜欢合作的。他们喜欢和用户交流，思考应该构建什么功能。这些人通常在构建系统方面也非常出色，速度快、能力强，思路清晰，但也有一些工程师对与用户互动完全没有兴趣，他们只想专注于构建系统，我觉得这些人也有巨大的发展空间。

再次强调，这就是我对 AI 时代的看法——我们都可以更加“做自己”。AI 和团队会帮助你完成那些你不想做的事情，从而让你专注于自己的兴趣和优势。

主持人 Peter：

我确实觉得“构建者 (builder)”这个标签非常重要。我觉得很多 PM 都想成为领导者，但传统的职业晋升阶梯是，你成为 VP 之类的职位后，反而没有时间构建东西了。你每天都在产品评审中，只是给出一些反馈，而没有时间真正去开发，我觉得很多 PM 并不想这样，我希望自己能够一直贴近用户，真正发布产品。

Alex：

我完全同意。我其实并不认为 PM 是一个领导角色，我更倾向于把它看作是一个“填补空白的角色”。有时候，这个角色可能需要承担一定的领导责任，但即使如此领导力更多的作用是帮助团队达成一致，而不是单纯依赖某个人提出一个天才的解决方案。

有一点我可以肯定：在 OpenAI，最优秀的 PM 都会深入到具体的细节中去。而且我认为以高级领导职位加入 OpenAI 是一件非常具有挑战性的事情，因为这里的文化依然强调对细节的关注。因此，最好的方式是直接从一开始就深入到细节中去。

Codex 团队在招聘时看重什么？（答案并不是你的简历）

主持人 Peter：你当你们为 Codex 团队招聘时，除了要求候选人是 Codex 的重度用户以外，你们还看重哪些品质？

Alex：

我之前提到过，我非常看重候选人的“自主性 (agency)”。我们希望找到那些会主动做事的人，这是最重要的品质之一。

在 OpenAI，尤其是 Codex 团队，我们的文化并不是那种“你加入后，我们会给你列出 12 个逐步增加难度的任务”的类型。我们的风格更像是：“欢迎加入！现在，开始你的探索吧。”

因此，我们更倾向于寻找那些自我驱动的人——他们有行动力，有自己的想法，知道自己想要做什么，并且不害怕挑战现有的想法。因为说实话，有些现有的想法可能本身就是错误的，可能只是我们当初的一个偶然决定。

我理想中的队友是那种愿意主动承担额外责任的人，甚至愿意负责一些未知的领域。这些品质是我们特别看重的。至于具体的技能，我们通常会优先考虑那些技术能力强、与工程相关的候选人。

Romain：

我完全同意。在我的开发者体验 (DevX) 团队中，我通常会寻找那些拥有高自主性的人。他们需要在技术上非常强大，特别是在使用像 Codex 这样的工具时表现出色。但除此之外，我还特别看重那些对与开发者和构建者 (builders) 一起工作、分享知识充满热情的人。

比如，这周我们刚刚宣布，Thomas 将加入我的团队，他是那个开发了开源 Codex monitor 的人。他不仅非常有创造力，还是 Codex 的重度用户，并且热衷于分享自己如何利用 Codex 构建工具的经验。

我们需要这样的人才，因为我们正在努力将数百万开发者引领到 Codex 所代表的光明未来。我相信智能代理编程 (agentic coding) 正在彻底改变我们对软件开发、应用程序和产品构建的传统思维方式。我们的目标是向全世界展示这种可能性，并帮助开发者学习如何利用这些工具实现自己的创意。这就是我在寻找的品质。

Alex：

我补充一下，在我看来 DevX 团队的理想候选人可以简单描述为“非常优秀的工程师，同时擅长利用社交媒体与社区互动”。

Romain：

你说对了一部分。不过我想补充一点：我们希望候选人对社区有很强的责任感，而且还要考虑到全球范围内不同地区的社交媒体使用习惯。比如，在一些地方，开发者可能更倾向于使用 LinkedIn 或其他平台，而不是 Twitter。所以我们需要扩展这个定义：候选人需要在全球范围内的社交媒体上有良好的表现。我们特别看重那些喜欢与社区互动、热衷于教学和分享知识的人

主持人 Peter：

其实，一个人的自主性甚至在面试之前就能看出来。比如，他们是否在线上发布过作品？是否有自己的 side projects？

Alex：

当有人通过私信表示对加入我们团队感兴趣时，我的第一反应是：“有链接吗？”如果有链接，我几乎都会点开看。我会好奇地检查他们的作品，了解他们是否真的在构建东西。

当然有些人会附上一封申请信，说明他们为什么对这个职位感兴趣，甚至附上他们的简历，但我更愿意看他们的想法以及他们实际构建的东西。我前几天还意识到一个有趣的事情——我完全不知道这些人上的是什么大学。

主持人 Peter：谁在乎呢，谁会在意？我真的很高兴我们现在生活在一个这些愚蠢的学历不再那么重要的时代，只要让我看看你实际构建了什么就足够了。