OpenAI几乎不做中期项目，PM也不大需要了！Codex负责人：OpenClaw很大程度上是Codex开发的！设计师写的代码比半年前工程师写的还多！

近日，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里的时间变少了——我更多是用它来沟通，而不是写代码。

所以我至少有这两档模式，可能还有更多。

在Codex工作最棒的部分是社区

主持人：你需要做多少跨职能的对齐工作？

Alexander：Codex团队很棒。我们在团队内部很少做跨职能对齐。我们特意将自己视为一艘“海盗船”式的团队。

甚至在团队内部，直到最近才有了另外两名PM。还有几个负责人，虽然直到最近大家还都直接汇报给主管，但我们基本上就是聚在一起处理各种模糊的问题。所以内部对齐不算多。

但越来越多的是，我认为构建Codex的一大部分是构建这个“编程Agent”。现在对每个人来说都很明显：一个编程Agent对于非编程类的工作也是非常有用的。我们看到人们使用Codex App做的事情已经超出了写代码，他们用它处理软件开发生命周期中的各种任务。

而且现在，实际上OpenAI的绝大部分人都在用Codex App。甚至在技术部门之外，我也看到它在被使用。

无处不在。所以，你知道的，我们意识到：好，我们该如何让Codex在写代码之外也变得有用？这需要更多的跨职能协作，因为在OpenAI，我们有无数人使用的ChatGPT，所以我们必须深思熟虑该如何去做。

Romain：在我负责的开发者体验这边，我们现在有点像Codex团队的延伸。我们把大部分精力都花在Codex上，原因有几点：首先，它是个令人兴奋的产品，开发者非常喜欢它，我们要把它做得更好。接Alexander刚才说的，我们也有几种模式。我们和Codex团队并肩作战，准备发布、准备素材、研究如何充分利用Codex；发布后，我们尝试引导开发者了解Codex的各种用法。

但从另一个有趣的视角来看，当你观察更广泛的OpenAI平台时，现在有数百万开发者在API上利用从图像生成到Sora再到语音转语音的各种模态进行开发。你猜怎么着？Codex已经成了开发的最佳入口。回顾一年前，甚至去年夏天我们推出GPT-5时，我们还得写大量关于如何提示GPT-5的指南。是的，它是个推理模型，和GPT-4截然不同。而现在我们尝试做的是，即使针对这些用例，我们也教开发者使用Codex和各项“技能”。比如，如果你想更新某个集成，你大概应该使用Codex和对应的技能，Codex绝对能帮你搞定。所以我们也高度跨职能，并将Codex视为开发者平台一切的基石。

Alexander：明了。关于我们如何协作，有一点很有趣：我觉得在Codex工作最棒的部分就是社区，不管是线上的，还是活动中面对面的。我们以此为核心开展一切工作。我们非常注重发布，总在想什么时候能交付新东西；也非常注重反馈，一旦社区有反馈，我们就去修复并沟通。我们全员基本都“长”在网上。比如筹备CodexApp发布时，我们和Dom及其团队密切配合，他帮我们协调了一场规模相当大的Alpha测试。我们和用户一起构建，收集反馈来开发App所需的技能，同时搞定文档等一切。我觉得这是Codex团队独特的优势，因为我们是开源的，所以我们发现自己对所做的一切都表现得极其开放，而社区也确实给予了丰厚的回报。

主持人：没错，伙计。和用户、社区一起构建产品是当PM最爽的部分，没有之一。就是那种每天和他们交流的感觉。

Romain：是啊。现在我们在许多城市和国家甚至都有了Codex大使，他们自发组织活动，在当地社区传授知识。我很想去每一个城市，但分身乏术。能看到社区自发组织这些活动、黑客松并一起开发，那种活力和热情真的很棒，太赞了。

Openclaw创始人是Codex的顶级发烧友

主持人：行啊，给我也弄个大使当当，我也去办点活动。听起来不错，算我一个。好，聊聊Peter（注：此处指PeterSteinberger）。我是OpenClaw的早期用户，它现在还有点简陋，但帮了我大忙。前几天因为它记得我们的对话，给我来了段长达三分钟、言辞相当“粗犷”的励志演说，那简直是我听过来自AI的最深刻的见解。所以，你们是怎么把Peter整合进团队的？这种“私人代理”（PersonalAgent）的愿景是他正在做的吗？你们怎么看？

Romain：关于这个有两点。我能透露的有限，但首先，他是Codex的顶级发烧友，OpenClaw很大程度上就是用Codex开发的。他一直在用反馈和改进建议为团队注入活力，这是他的“副业”，但他干得非常起劲，我们也对此感到兴奋。另一件事我现在还不能说太多，但他确实在帮我们构建集成在ChatGPT中的下一代私人代理。

Alexander/Romain：是啊，这很有道理，伙计。没错。

Romain：我觉得Peter所做的事情最令我着迷的一点是——显然我认识他很久了，当大家开始玩OpenClaw时，都看到了未来的缩影——但让我惊叹的是，Peter预见这个愿景已经很久了。如果你回看整个2025年，他去年构建了40多个开源项目，但所有这些项目都指向一个愿景，即：“我需要一个命令行界面来访问我的日历，我需要一个命令行界面来访问我的推文和Gmail。”通过构建所有这些项目，他实际上让这个愿景变成了现实，围绕着“技能”和“命令行工具”这一构想，而这正是我们今天使用Coding Agents的方式。而且这不仅仅局限于Coding Agents，它将扩展到任何形式的私人代理。因此，Peter在这个过程中为我们提供的反馈将是非常棒的，因为他构建了所有这些现在已成为OpenClaw生态系统一部分的工具。

主持人：是啊，我觉得他就像个超人，凭一己之力构建了这么棒的开源社区。而且这让我现在根本不想再打开任何其他App了，我只跟我的小机器人聊天。这区别太大了。

Romain：等等，你把它连接到什么上了？你是连接了一切吗？

主持人：兄弟，我把它连接到了很多东西上。它有我的银行信息，有我的YouTube信息，它还有我激活的各种语音，我的日历，我的谷歌全家桶。甚至当我躺在床上聊天时，我老婆会问：“你在跟谁说话呢？”我会说：“我在跟我的OpenClaw机器人聊天呢。”它给了我很多灵感。

主持人：但说真的，现在外面有很多“割韭菜”的人，帮人安装个OpenClaw就要收5000美元。所以，如果你们能让它变得对大众市场更友好，那意义将非常重大。

Romain：没错，我们在努力了，回头向你汇报。

不需要太多PM了，大家都是构建者

主持人：好的。那我们来收个尾，聊聊你的一些“辛辣观点”，Alexander。可能是我记错了，但我记得你好像说过，大多数团队其实不再需要那么多PM（产品经理）了之类的话。让我们聊得更火爆点：你觉得我们真的需要PM吗？

Romain：在我看来，这些工具最奇妙的地方在于，这甚至不是“要不要PM”的问题，而是几乎每一个职业阶梯都在变得模糊。以前，你这里有个设计师，那里有个工程师，这边有个PM，大家维持着某种比例，就像某种“黄金比例”。但现在，如果你是工程师，你的生产力更高了；如果你是设计师，你拥有了变得更懂技术的神力；如果你是PM，以前你只写战略文档，那现在你可以直接做原型。这并不意味着你要负责那个面向数十亿用户的最终功能，但你绝对可以通过亲手把它“造出来”，让团队看到愿景的缩影。所以我觉得这才是最迷人的：职业阶梯之间的界限正在模糊，我们大家全都是“构建者”（builders）。

Alexander：没错，我很有共鸣。我在努力回忆我到底说过什么。我好像在互联网上某个地方说过，如果一个初创公司在工程师不到20人的时候就招PM，那是红旗警告（redflag）。

Alexander：就像你说的，所有角色都在融合。设计师可以做更多工程，工程师可以做更多设计，PM可以做更多构建。而且，以前工程师之所以不去做任务分类或项目管理之类的事，往往是因为他们需要专注写代码。但现在这些事变得非常容易，你只需让像Codex这样的代理去分析反馈并排优先级，你就有更多时间了。所以我觉得每个人都能做别人的工作。ScottBelsky有个观点叫“坍缩人才栈”，我很喜欢这个想法，它正在发生。在一个房间里，做成一件事所需的人越少，事情进展就越顺利，每个决策也就越纯粹。

Alexander：那么问题来了：PM还剩下什么？我认为很多PM实际上应该转型。如果你是一个一直想当工程师的PM，擅长管人但工程能力差点，也许现在你应该去当工程经理（EM），配合编程代理，这完全没问题，对你来说是个更清晰的角色。同理，有些PM可能现在只想当设计师，更接近构建过程。

但最终归结为“兴趣”。我认为在AGI时代，人类最根本且重要的品质是“兴趣”和“能动性”（agency）。如果你本质上更喜欢写代码，之前做PM只是因为没人做，那现在你应该“删掉”自己，变成一名工程师，站在工程角度做同样的事。设计也是如此。但如果你本质上最感兴趣的是花大量时间与用户在一起（即使这会让你远离构建过程），或者洞察先机、理解市场走向等等，而且你在一个工程师已经足够多的规模化团队中，那么PM依然有生存空间。但这真的取决于你对什么最感兴趣。

我再补充一点：我认为每个问题依然需要一个对其负责的人，但我只是不认为那个人必须挂着“PM”的头衔。

Romain：没错。而且我认为这很大程度上取决于你说的产品的性质。我们很幸运能开发Codex，因为它本身就是一个面向构建者和开发者的产品。我们自己就是它的重度用户，并且通过开源模式与社区紧密配合。但回看十年前我在Stripe的时候，Stripe在没有任何AI工具的情况下，员工达到250人时依然没有PM。为什么？因为Stripe只是一个API，我们全都是工程师，我们知道一个伟大的API应该是什么样的。我们就在构建自己梦寐以求的API。

如果你在不同的领域工作，想要保持对客户的痴迷，当垂直行业或问题空间不同时，你可能需要更多PM的时间去深入客户。

Alexander：没错。但就算在那个例子里，如果一个领域是工程师缺乏直觉的，所谓的“PM”其实只是一个能设计、能写代码，但对用户最感兴趣的人的标签。你懂我意思吗？你同样可以有一个对用户非常感兴趣的工程师。所以我觉得这些标签正在失去意义，虽然现在这有点混乱，但没关系。

主持人：没错，我的团队也是这样。最好的工程师不会问我：“嘿，下一步该造什么？”他们会自己跑去跟用户聊，弄清楚该造什么，然后我们再一起讨论。这就像大家对这些事都在同一个频道上。Codex团队也是这样运作的，对吧？你们今天在CodexApp里使用的很多功能，完全是工程师们自下而上提出的点子，因为他们自己想要那个功能。

Alexander：我得说，我非常喜欢的一类工程师是那种热爱跟用户待在一起、思考该造什么的。但也同样存在另一类极其强大的工程师，他们速度惊人，极其擅长构建和推敲系统，但对跟用户打交道毫无兴趣。我觉得这个世界也完全容得下这些人。在AI时代，我们都可以变得更像我们自己。AI和你周围的团队会填补你不想做的那些空白。

主持人：这个说法太棒了，伙计。但我确实认为“构建者”这个标签非常重要。我觉得每个PM都想当领导，但传统的职业阶梯就是让你变成VP之类的人物，然后你就没时间构建了。你整天都在参加产品评审，到处给点反馈。我觉得很多PM并不想要那种生活。我不知道你喜不喜欢，但我想要在实际交付产品的过程中保持与用户的接触。

Alexander：完全同意。我其实不把PM看作领导职位，我把它看作“填坑”职位。偶尔这需要领导力，但即便如此，这种领导力通常也只是帮助大家达成一致，而不是当一个想出正确战略的天才。

有一点可以肯定，OpenAI最好的PM都是深入一线、关注细节的。在OpenAI担任高级领导职位非常有挑战性，因为“深入一线”依然很重要。你必须在领导工作和关注细节之间找到平衡。所以我认为直接从一线细节做起总是更好的。

Codex团队招人时的重点：高能动性和作品

主持人：最后一个问题。你终于又雇了一名PM，叫Rohan对吧？除了是Codex的重度用户外，你们在为Codex团队招人时会看重什么样的特质？

Alexander：咱们都来说说吧。我之前说过，我会回到“能动性”（agency）这一点。那种“能把事办成”的人是OpenAI、尤其是Codex团队最重要的。我们特意不把团队搞成那种“你加入后，我们会按难度递增给你排12个任务让你去做”的形式。更像是“欢迎加入，剩下的看你了”。所以我看重那些自驱、能成事、有活力和想法的人，并且不介意反驳现有的想法，因为现有的想法很可能是错的，可能只是我们随手拍板定的。如果能吸收未知的领域并对此负责，那就完美了。

Romain：在开发者体验（DevX）这边，我寻找的是那种具有高能动性、技术极强、精通Codex工具，同时也热衷于与开发者待在一起并分享知识的人。比如我们这周刚宣布，构建了开源Codex监控器的Thomas本月将加入我的团队。这很棒，因为他非常有创造力，产出极高，同时也热爱分享他是如何构建的。我们需要带领数百万开发者走向Codex的光明未来。代理化编程正在改变我们对构建软件、App和产品的一切思考，展示“任何人都可以构建任何东西”并教导他们，这其中有巨大的潜力。

Alexander：如果我说错了请纠正我。在我脑子里，DevX职位的描述大概是：一个极其优秀的工程师，同时也非常擅长玩转推特。

Romain：你说对了一半。我要加个小小的星号：推特对我们的社区非常重要，但当你走遍世界，会发现有些地方的开发者不怎么玩推特。比如在欧洲等地，他们用LinkedIn或其他平台。所以我们要考虑的是在社交媒体上的全球影响力，并且热爱教学和科普。

主持人：这种能动性其实在面试之前就能看出来，对吧？看他们在网上有没有发布东西，有没有侧边项目。

Alexander：没错。当有人私信我想合作时，我会看有没有作品链接。如果有链接，我一定会点开（除非看起来像病毒）。我总是很好奇。如果有关于点子的长篇大论，我通常也会读。听起来可能有点毒舌，但如果只是在解释为什么对职位感兴趣并附上简历，我阅读的可能性远低于看他们的想法和作品。而且说实话，我根本不知道同事们是从哪所大学毕业的。

主持人：谁在乎呢，伙计！我很庆幸我们生活在一个这些愚蠢的凭证不再重要的世界。只要展示你构建了什么就行。

Alexander：没错。

主持人：好了伙计们，太感谢了。我超爱Codex，这个周末我要去亲手捣鼓一堆东西。

Romain：玩得开心，等你的反馈！

Alexander：谢谢你，彼得。

主持人：好的，伙计们，再见。

参考链接：

https://www.youtube.com/watch?v=9qXc-THAvc0

文章来自于"51CTO技术栈"，作者 "玉澄"。