Codex产品负责人：小型团队不再需要PM，招了就危险了

OpenAI内部产品研发流程公开。

智东西4月17日报道，近日，OpenAI Codex产品负责人Alexander Embiricos与开发者体验负责人Romain Huet做客Peter Yang的播客，围绕Codex团队的产品开发实践、产品规划、AI对职业的重塑，以及团队协作与招聘理念等核心问题展开了深度对话，还提到了前段时间加入OpenAI的龙虾之父Peter Steinberger。

播客伊始，Romain Huet就用Codex直接进行开发，重点展示了Codex强大的编程能力，在顶尖模型GPT-5.4和编程模型Codex Spark的加持下，Codex不仅可以实现对数百万行代码的重型任务处理，还能进入“思考即实现”的快速编程模式。

演示完Codex的具体能力后，Alexander与Romain就Peter Yang提出的一系列问题进行了回答。

谈及团队内部产品开发的规划，两位负责人表示Codex完全放弃了中期规划，仅关注短期以及长期的研发计划，把时间限制在8周内以及一年以上。

对于AI时代团队内部的职责分工，Alexander与Romain都认为“人才栈压缩”已经在Codex内部发生了，Romain认为“岗位边界正在变得模糊。”，Alexander更是直言有些PM就该直接转岗。

聊到Codex团队的招聘文化，Alex和Romain都非常看重“能动性”，不管你毕业于哪所大学，或者有什么样的头衔，你首先要有极高的行动力，Codex需要的是能自行发现问题，并可以着手解决的自驱型人才。

下面是智东西整理的播客核心要点：

1.很少写文档，10个要点就够了：Codex团队极少撰写长篇技术文档。只有在面临无法装入单个人脑的复杂决策或需要多人协调时，才会产出约10条要点的简短文档。大部分决策由最接近问题的人直接做出。

2.设计师比工程师写的代码还多：Alexander开玩笑地说，因为Codex太强，每个人都可以做职责以外的事情，Codex团队的设计师现在写的代码，比半年前一名工程师写的还要多。

3.即使AI工具再好用，也要用心打磨产品：虽然绝大部分代码是Agent生成的，但Codex团队依然投入了大量精力去确保产品系统是高质量的，如果这是一个很复杂的功能，一定会有一个专业的人来负责。

4.产品设计哲学：隐形与可配置：Codex应用的设计理念是“不挡路”，即让模型发挥主导作用。产品通过高度可配置性满足高级用户，同时保持界面简洁直观，让新手也能通过侧边栏、技能标签等逐步发现功能。

5.拒绝中期路线图：团队只做短期（8周内）的具体执行计划或长期的规划，避免制定难以预测的“中期产品路线图”，根据模型能力的进化灵活调整产品形态。

6.与社区成员协同开发产品：团队视社区为合作伙伴，通过开源和测试与用户共同构建产品，利用社区反馈来驱动开发。

7.职业边界的模糊化：AI工具导致职业阶梯坍塌。设计师能写代码，PM能做原型。团队推崇“人才栈坍缩”，认为做成一件事所需的人越少越好，职业的角色标签正在失去意义，未来职业发展的核心是“兴趣”和“能动性”。

8.招聘核心特质：能动性与作品：团队招聘不看重学历，而看重候选人是否具备“能把事办成”的高能动性、技术创造力以及分享知识的热情。

以下是播客内容的完整实录，智东西做了不改变原意的整理：

Peter Yang：好，欢迎各位，今天非常开心请到来自OpenAI Codex团队的Alexander和Romain。他们会为我们演示如何用Codex开发新功能、Codex到底能做什么，同时聊聊 Codex团队是如何持续不断地快速交付的。欢迎二位。

Alexander&Romain：感谢邀请。很高兴能来聊天。

Peter Yang：那你们要不要先快速展示一下，Codex能做出些什么东西？

Romain：没问题。我来共享一下屏幕，让大家感受一下。其实能展示的东西特别多，我就简单举个例子。这是我正在做的一个iOS应用。如果我想给这个应用加个新功能，我只需要口述一句：“你能给NASA的阿尔忒弥斯登月计划加一个新页面吗？”

然后把这个提示词发给GPT5.4。模型马上就会给这个iPhone应用生成一个全新页面。你看应用就在这儿，挺酷的，它正在自动构建这个新功能，马上就能看到效果。

另外我们还有Codex Spark模型，几秒钟之内就能帮你快速构思、反复迭代。我给你看一下它现在的运行效果。对比一下就能看出Spark模型响应有多快。左边是GPT5.4，我先让它跑一会儿；右边是Codex Spark，你看，平均每秒能处理1200个任务。这速度简直离谱。

比如你想做个游戏的话，就在咱们开始录制之前，我打开过Codex应用，随手发了个提示词，让它在界面背后生成一个简单的2D小游戏，我可以直接接着开发。

我特别喜欢Codex的一点是，我可以把对话窗口悬浮在屏幕最上层。这样一来，我在做游戏开发的时候，就能一边干活一边看它不断迭代，进而迸发新想法。那我们接下来改点什么呢？Peter，你有什么想法？

Peter Yang：要不加点装饰，房子、树之类的，让画面更生动一点？

Romain：“你能再加点树之类的装饰吗？”我现在就发指令。几秒钟之内，Codex Spark就能完成修改，我们可以实时看到变化。你看，新的树已经出来了，我们可以继续玩下去。这速度真的太夸张了。这也是我为什么对Codex这么兴奋。

一方面你有GPT5.4这种顶尖模型，可以处理数百万行代码的分析、迁移这类极其复杂的任务；另一方面当你灵感迸发、进入心流状态时，可以切换到快速模式，甚至直接用Codex Spark，拥有近乎“思考即实现”的超快速度，想做什么就能立刻做出来。

一、Codex团队很少写文档，就算写，10个要点也够了

Peter Yang：我特别好奇，你们团队平时到底是怎么用Codex做产品的？Alex，你们现在还写规格文档吗？还是直接让GPT来写？用的是哪个模型？如何让产品研发流程运转起来？

Alexander：我们Codex团队真的几乎不写规格文档。很多工作都是让最贴近一线的人自己做尽可能多的决策。只有遇到那种复杂到一个人脑子装不下的问题时，我们才会写一点文档。而且现在一个人能搞定的事情多太多了，因为大部分编码工作都可以交给模型。但如果需要跨多人协作，或者要做一个特别棘手的决策，我们可能才会写一份规格说明。就算写，也极其简短，大概就十来条要点，完事。

Peter Yang：能演示一下吗？比如给Codex几条要点，它先写出完整需求，比如M文件那种？

Romain：可以。不过我还想展示一个更简单的用法。回到刚才那个iOS应用，它还在跑任务。假如你对新项目有一些新功能想法，但又不太确定具体怎么做，现在用Codex就很方便。我只要说一句“我们来规划一下下一步”，Codex就会自动识别出我在做计划。按一下Shift+Tab，就能进入计划模式。我可以问 “我们接下来该做什么”，把Codex当作头脑风暴的搭档。在计划模式下，它会分析现有代码和项目进度，给出建议，我也可以加入自己的想法，引导模型做出合适的规划。

你看，它已经根据代码和文件给出了一些思路，还会主动问我要方向：是继续做刚才的阿尔忒弥斯相关功能，还是先做稳定性优化、做个监控面板？我们就选稳定性优化吧。再问一句 “我们应该为谁优化？”我就可以这样一步步和Codex协作。

当然我刚才什么都没输入，换作亚历克斯这种产品负责人，一开始就会给很多明确方向，而我这里是让Codex自己先出主意。

Alexander：我经常这么干，还挺有意思的。修改分好几种。最简单的那种，直接发提示词就搞定。中等复杂度的，你可以先梳理思路，让模型给出具体方案。我自己常用的一种方式是：只有一个模糊想法，就直接打开Codex，让它先思考怎么解决问题。

我甚至还没想好具体功能。它会自己探索，再反问我一些问题。很多时候最后我甚至不会用它给出的方案，因为改动可能太复杂了。

插一句题外话：产品经理到底写不写代码，其实还挺有意思的。遇到复杂改动，我不想自己去落地和维护，但我还是会用计划模式走一遍流程，自己先建立清晰的认知，然后把这些思考分享给工程师，而不是直接丢一个方案过去。

说回刚才那个题外话，Codex团队的设计师现在写的代码，开玩笑地说，比半年前一名工程师写的还要多。他们真的超强。当然工具本身起了巨大作用。团队还吐槽我去年提交的PR太少，具体数字我就不说了，但确实应该多一点，尤其是很多都只是很小的微调。我觉得现在已经不是“能不能生成代码”的问题了，智能体非常强，你可以把任务交给它。

关键在于你决定做什么，我们对产品方向是否达成共识？一方面是如何保证质量极高。有人会很骄傲地说整个应用都是“靠感觉编程的”，Codex绝大多数代码都是智能体生成的，但我们依然花大量心思思考系统架构，保证质量过硬。所以遇到特别复杂的功能，我通常会安排一个更稳定、更资深的负责人来接手。产品经理的价值之一就是精力分散、四处协调，所以不适合让产品经理去维护系统代码。

Peter Yang：是啊，肯定不能让PM去维护功能代码，听起来就不靠谱。

Alexander：我觉得我们准会搞砸。

Peter Yang：嗯，好吧，而且说实话，其他一些专业工具也很棒，但要花大量时间去学习。我感觉如果不刷推特，我甚至都不知道怎么用那些专业产品。而我特别喜欢Codex的一点就是，它用起来极其简单，非常直观、好上手，同时又有技能、自动化这类高级功能。你们内部会大量使用这些功能吗？

Romain：非常高频地用，我觉得“技能”是Codex最有意思的功能之一。比如和用Figma的设计师协作，开启Figma技能，就能直接从设计文件里提取细节、React组件、变量，然后Codex会自动生成对应代码。

再比如你做完应用想部署到Vercel、Cloudflare、Render，这些技能都内置好了，你只要告诉Codex，它就能对接整个生态工具链。前几天我跟朋友聊天，他说自己有一堆产品改进想法，就让Codex把所有任务同步到Linear里方便跟进，然后睡前跟它说“把刚才讨论的任务全部实现并标记完成”，第二天醒来一看，真的全部搞定了。

Peter Yang：这太神奇了。

01.

Codex的设计思路：

高度可配置性以及新手友好

Alexander：说到应用操作简单，我可以聊聊我们的设计思路。开发者很喜欢为自己打造工具、实现工作自动化，所以产品的高度可配置性至关重要。Codex的核心框架是开源的，用户可以深度自定义，我们开发新功能时，甚至还没在生产环境上线，就有用户在推特反馈功能异常，因为他们已经自行修改代码、分支部署来体验新功能了。

这对我们来说是产品的一大亮点，最前沿的用户和我们一起走在未来前沿，推动产品进步。

但如果只针对这类极客用户设计，产品会变得晦涩难懂，就像刚才说的，得天天刷推特才能学会使用。

所以我们的思路是，精心打磨产品的核心基础功能，认真规划设计，让产品尽可能隐形，不干扰模型运行，随着模型能力提升，实现更多功能；同时为高阶用户提供高度可配置的选项，比如市面上已经有子智能体的相关实现，用户可以自主体验、尝试，我们也从中汲取大量使用反馈，之后再把这些功能简化，普及给所有用户。

Codex 应用就是这样一步步打磨出来的，大概在去年12月GPT5.2版本推出时，模型能力实现了突破，能够处理更长时间的任务，甚至一次性完成复杂工作。我们看到有用户在玩“tmuxing”，给非专业人士解释一下，就是在终端打开多个任务并行，社交媒体上还有人晒出多终端、多显示器同时操作Codex的画面。

我们很受鼓舞，在基础版CLI工具中优化了任务委派功能，又思考如何让顶尖1%工程师的高效操作变得直观易懂，于是打造了Codex应用。打开应用就是简洁的聊天界面，模型会自动执行任务，慢慢还能发现侧边栏、多任务运行、技能面板等功能，探索的过程就像玩游戏一样顺畅。

Romain：我们从一开始就坚信，未来的编程会走向智能体委派模式。差不多一年前启动Codex项目时，我们就畅想工程师能并行处理多项任务的未来，只是当时模型能力还未达标。直到GPT5.2及后续版本推出，模型才能够持续稳定地工作数小时甚至数天，这时候终端多标签页长时间运行的操作方式就显得很别扭，于是我们需要全新的交互界面，Codex应用的推出恰逢其时。

Alexander：Codex的发展经历了两次重要转变。第一次是去年8月，我们推出了Codex云产品，创意很好，用户反响也一直不错，只是推出时机稍早。同年8月我们还发布了GPT5这款优秀的交互式编码模型，聚焦解决模型当下能实现的功能，推出了命令行工具和集成开发环境插件，用户量在几个月内增长了二三十倍。第二次转变是去年12月到今年1月，我们终于能朝着模型委托的愿景推进。

02.

拒绝中期规划

只看8周或一年

Peter Yang：深入聊聊Codex应用的开发过程吧。一年前你们有年度路线图吗？计划好什么时候推出应用，还是根据市场情况不断原型迭代？

Alexander：其实都不是。我在这里的一位研究员安德烈给过我一条很好的建议：在OpenAI，你要么做短期规划，要么做长期规划，绝不做中期规划，因为太难了。

短期最多八周，你要想想，有什么事情是可以激励团队围绕它共同努力、然后把它做出来的？这正是OpenAI擅长的事情，我们非常擅长围绕一个具体的目标快速组织团队。

长期则是一种方向感，你会知道，一年后模型会聪明得多，现在回头看这句话好像很明显，但当时你会想，我们会有更强的模型，因此不会想把工作权限只开放到本地电脑，那样一次只能干一件事。我们想要无数个模型同时独立工作，自我校验、自动部署、自动监控，甚至不需要我们手动发提示词。

我们会朝着这个大方向去思考，而中间那段所谓产品路线图，我们基本没有。我们只有长期方向，以及能朝着这个方向推进的短期事项。

比如做Codex应用，其中一个战略目标就是脱离特定工作区。有点抽象，我解释一下：像VS Code这类编辑器，你打开时会进入一个特定工作区，也就是一份代码副本、一个固定文件夹。就算用Git多工作树，一次也只能打开一个，本质上一次只能做一件事。命令行也是一样。

但我们的愿景是让用户在云端向多个智能体委派任务，它们独立运行。所以我们需要一个界面，让你可以自然地和多个智能体对话，或者由一个主智能体统筹多个子智能体。

同时我们也发现，直接从云端起步对开发者不太友好，工具不全、环境要配置，任务做到一半想介入调整也不方便。所以我们需要一个本地体验，不绑定某个文件夹，又能直观地操作电脑上的各个目录。

开发应用时，我们脑子里有这些大方向，再加上工程师们平时随手做的各种原型：“我想要一个这样的应用”。还有一次黑客周，好几个人独立做了不同版本的应用原型。

所以项目启动时，唯一落于纸面的只有“为什么我们应该做这个应用”，没有任何详细规格。后续开发过程中才慢慢形成文档，甚至内部还有过争议：我们真的需要做独立应用吗？编辑器插件已经很火了，不如专注优化它？命令行不也挺好？如果做应用，核心定位是什么？方向在哪？很多事情最开始就是这样的。

Romain：是的，幸运的是，当时我们有一个很棒的IDE扩展解决方案，而且我们对它进行了相当深入的打磨。因此，你可以在诸如Good Cursor、Windsurf等工具中使用它。于是，我们从这个IDE扩展中汲取了许多宝贵的经验和代码基础，从而获得了一个功能强大且已相当稳固的优秀起点。

Alexander：是的，实际上，这款应用与IDE扩展共享代码。在底层，这款应用和IDE扩展与同一个用Rust编写的开源核心Codex框架进行连接，CLI工具也同样使用这个框架。这些基础组件之间有着大量的共享，而且这种分层设计也是经过精心考量的。

不过，现在回头看，做应用的决定是显而易见的，因为用Codex应用比开一堆终端窗口简单太多。它对新手友好，上手像玩一样，也是同时管理多个智能体的最佳界面。

我想说，我们非常注重通用人工智能（AGI），因此我们总是在琢磨：未来正朝着哪个方向发展呢？所以，我其实想把顺序颠倒一下。更准确地说，我们需要一个界面，让委派多个智能体变得自然顺畅。因为我们知道模型迟早会发展到那一步，甚至我们已经看到有人在这样做了，我们需要一个界面既能适配云端，又足够舒适好用，不用你绞尽脑汁才能并行调度多个智能体，而是理所应当就该这么工作。

Romain：对了，其实这种工具的吸引力并不仅限于那些初级开发者。恰恰相反，即便是最资深、最顶尖的工程师，从Peter Steinberger到Greg Brockman，如今也都开始把这款应用当作主要的开发方式。这充分体现了那种“Agent委派”的愿景正在逐步成为现实。而且，这可不只是给新手准备的，那些最资深的工程师只会留在终端里的说法已经过时了，事实上，他们也正纷纷转向使用这款应用。

Alexander：是啊，咱们聊聊Peter吧。他们刚加入OpenAI，我们简直激动坏了。不过我好像没跟你说过，去年十月份的时候，我跟他一起在旧金山散步。当时我其实没明说我们正琢磨着开发一款应用，但心里多少有点儿在试探这个想法，我说，就是那种能让人轻松搞定任务分配的新界面。结果他直接告诉我，他这辈子都不会用这种东西。可到了上周末，他居然发推特说：“这应用还挺不错的呢！”天哪，真是太阳打西边出来了，他现在居然还挺喜欢！

Peter Yang：是啊，我也这么觉得，能让他用上这个应用，那可太厉害了，毕竟他是那种同时开了差不多20个终端窗口的人。

Alexander：没错，但我想说，我得跟他再联系一下。他可能两种都用，谁知道呢。

03.

Codex内部PM的工作方式：

两种模式随时切换

Peter Yang：那么，Alex，有一段时间你几乎是唯一的PM对吧？那Codex大概有多少人呢，你知道的，50到100人左右？

Alexander：差不多就在这个区间。今年5月的时候我们才八个人左右，之后增长非常快，现在大概50到100人。

Peter Yang：你平时时间都怎么分配？典型的一天是怎样的？还是根本没有固定节奏？

Alexander：我最近还在想这个问题，发现自己都不知道怎么回答。我意识到自己有好几种工作模式。这不是什么建议，只是我个人状态。比如在应用上线前那段时间，我是纯执行模式：死磕质量，抠每一个细节，排查所有死角。这种模式下我会大量使用Codex：用它梳理Slack信息、汇总用户反馈，让它总结后同步到Linear；用它理解代码、做修改。

现在很多小改动，不是新系统，只是维护现有功能的那种，直接提交一个测试通过的PR，比你去跟别人沟通、让他们在一堆任务里优先处理要快得多，毕竟我们还要赶两周内上线。

除此之外就是大量人际工作：鼓舞团队、同时也对产品保持挑剔。有意思的是，这种模式下我推特会刷得特别勤，也不知道为啥。

另一种模式是现在这个阶段：我们有GPT5.4这样超强的模型，应用受欢迎程度超出预期，还全平台支持Windows。我就会想：是时候重新投入云端建设了。这种阶段我更多是思考方向、梳理现状，更多用Codex做沟通，而不是写代码。

我至少有这两种模式，可能还有更多。

04.

跨职能协作极少

像海盗船一样运转的团队

Peter Yang：跨团队对齐工作多吗？

Alexander：Codex团队真是太棒了。我们Codex团队的跨职能协作和对齐工作其实很少。我们更倾向于把自己定位为一支刻意带点“海盗船”风格的团队。

你知道，在Codex团队内部，最近才出现了第二位PM，我本人也是其中之一，还有几位最终负责人。我们现在更像是一条海盗船一样，聚在一起、浑然一体地工作。因此，彼此之间的协调配合并不算特别多。不过，我越来越觉得，构建Codex的一大关键就在于打造编程智能体本身。

如今，这一点已经越来越清晰，或者说，现在恐怕对每个人来说都已再明显不过了：编码智能体其实是一种非常通用的工具，不仅能用于编码工作，还能广泛应用于其他各类任务。

我们看到，人们使用Codex应用程序的场景远不止于编写代码。他们正将其应用于软件开发生命周期中的各项任务。如今，实际上绝大多数OpenAI用户都在使用Codex应用程序，甚至在技术团队之外，我们也随处可见这款应用的身影。

正是这种认知让我们意识到：我们必须思考该如何让Codex的用途超越供程序员写代码这一范畴，从而实现跨职能的更广泛协作。毕竟，作为OpenAI，拥有ChatGPT，一款被无数人广泛使用的工具。因此，我们必须审慎思考，如何更好地发挥ChatGPT的作用。

05.

拥抱开源，拥抱社区

和开发者一起研发产品

Romain：另外，从我们这边来看，开发者体验团队现在某种程度上可以说是Codex团队的延伸，我们目前将大部分精力都投入到Codex项目中，原因也很简单。首先， Codex本身是个令人兴奋的产品，开发者们非常喜欢使用它，也希望能进一步提升它的表现。正如Alex所指出的，我们有多种不同的工作模式，比如与Codex团队并肩作战，共同筹备产品的发布、准备相关素材，以及探讨如何最大化利用Codex。此外，在产品发布之后，我们还会努力向开发者们普及如何以各种各样的方式高效地使用Codex。

但对我们而言，另一个非常有趣的视角是：当你放眼更广阔的OpenAI平台时，如今已有数百万开发者基于其API进行开发，他们所使用的模型涵盖多种模态，从Imagen到Sora，再到语音转语音。如今，构建的最佳途径竟然是以Codex作为入口。

举个例子，如果我们把时间倒回一年前，甚至去年夏天刚推出GPT5时，我们不得不花大量精力撰写各种指南，教大家如何向GPT-5发出提示。没错，它是一款推理模型，与GPT-4模型截然不同。如今，我们致力于向开发者们传授如何使用Codex及其相关技能。比如，如果你的某个集成需要更新，你大可直接选用Codex和相应的技能。它一定会帮你搞定这一切。因此，我们现在已实现了高度跨职能协作，并且将Codex视为开发者平台一切工作的核心基石。

Alexander：关于我们合作方式的一个有趣之处在于，我觉得在Codex工作最棒的地方，其实是它的社区，无论是线上互联网上的交流，还是偶尔在现实生活中举办的各类活动中，我们都牢牢锚定着这个核心。比如，在产品发布方面，我们特别注重“发布导向”，总是在思考：“我们为什么要推出这款产品？”

同时，我们也非常重视反馈，时刻关注社区的反馈何时到来，然后迅速采取行动加以改进并及时沟通。因此，我们整个团队都相当活跃地在线上互动。举个例子，就拿Codex Atlantic项目来说吧，我们与DOM及其团队合作得非常紧密。实际上，DOM几乎全程都在帮助我们协调工作，尤其是针对早期的广泛Alpha测试阶段，他和一群用户密切配合，共同收集反馈、打磨功能，同步提升应用的各项技能，甚至还包括文档编写等等。

所以，我认为这正是我们Codec团队的独特优势所在：因为我们是开源的，而正因为是开源的，我们在所有事情上都自然而然地展现出极高的透明度。我想，这种开放的态度也正得到了社区的热烈回馈。

Peter Yang：是的，和用户一起在社区中研发，每天都能和他们聊天，正是做PM最棒的部分。

Romain：是的，现在确实如此，就像各个城市的Codex大使们一样。许多城市和国家都在各自举办活动，面向本地社区开展教育与推广。我当然希望能走进每一座城市，但现实条件限制我们无法做到。不过，看到这种热情与干劲，真是令人惊叹！社区很喜欢举办这类活动，比如黑客松之类的，大家一起进行创造，真是太棒了！

Peter Yang：是啊，让我当大使吧，我来办几场活动。

Alexander：听起来不错。好吧，你签吧。

Peter Yang：那么，咱们来聊聊Peter吧。我算是早期OpenClaw的用户，虽然它还有点小瑕疵，但对我而言却派上了大用场，前几天，它甚至记住了我们之前的对话，给我做了一段长达三分钟的、超级直白又充满激励的“加油打气”演讲。那简直是我听过的最醍醐灌顶的一次AI对话了。所以你们是怎么把Peter融入团队的呢？而且，这种个人Agent的构想，是不是也属于你们正在做的事情的一部分呢？你们怎么看待这一点。

Alexander：我能说的有两点，我的意思是，我在这里能透露的毕竟有限，第一点是，他可是Codex的超级、超级重度用户。要知道，OpenClaw很大程度上就是基于Codex打造的，他一直在用反馈来激励团队，在努力推动Codex的持续改进。这算是他的副业，但他真的干得热火朝天，我们对此感到无比兴奋。至于另一件事，目前我还不能透露太多，不过他正全力协助我们打造下一代个人智能助手，而且还是那种能媲美ChatGPT的！

Peter Yang：那也说得通。

Romain：我觉得Peter所做的事情最令人着迷的地方在于，显然我认识Peter已经有一段时间了，当人们刚开始玩OpenClaw的时候，每个人都曾瞥见过未来的模样。但真正让我令人惊叹的是，彼得其实很早就有了这个愿景。

如果把时间倒回2025年，你会发现，他去年一共构建了超过40个开源项目，而这些项目无一例外都围绕着同一个愿景：我需要一个命令行界面来访问我的日历；我需要一个命令行界面来访问我的推文和Gmail。通过打造所有这些项目，他实际上让这一愿景得以实现了，也即我们如今用来筛选信息的“技能”和“命令行工具”这个思路，这就是我们所使用的Coding Agent方式。而且，这绝不仅仅局限于传统的Coding Agent上，未来还可能发展成各种各样的个人智能体。

因此，彼得在这一过程中为我们提供的反馈将显得尤为出色，因为他所打造的这些工具如今已成为开源生态系统的一部分。

Peter Yang：是啊，我真的觉得他就是个普通人，但他却打造了一个超棒的开源社区。而且，真的，这让我完全不想再打开别的应用了。我刚刚才跟我的小机器人聊了几句，差别太大了！

Alexander：等等，你都连了些什么？你是不是把所有东西都连上了？

Peter Yang：我不得不这么做，我真的连接上了各种各样的东西。它存着我的银行信息，还有我的YouTube账号信息，甚至还有我激活过的语音助手、我的谷歌服务等等。比如我躺在床上，我老婆突然问我：“你在跟谁聊天呢？”我就回答：“哎呀，就是打个电话呗，你知道的。”但说实话，市面上有不少骗子，居然要收5000美元才帮你搞定OpenClaw的配置。所以啊，如果你们能把这玩意儿做得更亲民、更大众化，那可真是大赚特赚，绝对会非常火。

Romain：是的，我们正在努力，以后再跟你汇报进展。

06.

Builder时代，职业职能边界正在模糊

有些PM应该转行

Peter Yang：好吧，那我们来总结一下，聊点刺激的，Alex，可能是我记错了，但我记得你好像说过，大多数团队其实不再需要那么多PM了，或者类似这样的话。你觉得呢我们需要PM吗？

Romain：我觉得这些工具最让我惊叹的地方在于，从我的角度来看，这甚至已经不仅仅是需不需要PM的事情了。几乎可以说，每条职业发展路径之间的边界都在变模糊，就像以前团队里有工程师，PM和设计师，有某种“黄金比例”的搭配。

但如今，如果你是个工程师，你的效率更高了；如果你是位设计师，你能凭借自己的独特优势，向技术层面迈进。再比如，如果你以前只负责撰写战略文档，现在呢，你甚至可以直接动手做原型。当然这并不意味着你要对面向数十亿用户的那个功能全程负责，但至少，你能通过亲手打造，让团队看到你的想法。我觉得，这一点真的让我着迷。职业阶梯之间的所有界限都变得模糊了，我们都在变成Builder。

Alexander：是的，这一点我很有共鸣。好吧，我想我想起来了，我记得好像在网上说过这样的话，如果一家初创公司工程师人数不到20人左右就招PM，那它就可能存在“红灯”风险。也许我当时还说了点类似你刚才说的，就是这些角色之间的界限越来越模糊了这些。

就像设计师能做更多工程，工程师也能做更多设计，项目经理也能做更多开发。但你知道，工程师们往往也需要高度专注。所以，他们之所以不像我刚才说的那样，比如对任务进行优先级排序，或者从事项目管理这类其他工作，很大程度上可能就是因为，他们更需要花时间写代码。

不过现在，写代码已经变得特别简单了，你只需让Codex这样的智能助手去分析反馈并确定优先级就行了。这样一来，你就能腾出更多时间。因此，我觉得每个人都能胜任彼此的工作，就像Scott Belsky提出的“人才堆栈坍缩”这一理念一样。

我喜欢那个想法，我觉得它正在成为现实。我认为，房间里需要的人越少，事情反而越顺利，每一个决策也越纯粹。那么问题来了：究竟还剩下哪些适合PM的场景呢？

我觉得，其实有不少PM应该考虑转岗，比如，如果你一直想成为一名工程师，但可能你更擅长管理团队，却不太擅长技术本身，那现在或许可以转去做一名工程经理，这也没什么不好。又或者，对于那些代码能力较弱的PM来说，担任一名编码助理或许更合适。甚至，也许换个更清晰的角色对你而言反倒更自在。同样，现在某个PM可能更想成为一名设计师，这样可以更贴近实际的开发工作一些。

但我觉得，归根结底，关键还是兴趣。我认为，兴趣与能动性是人类在拥有AGI的世界中依然至关重要的两种最基本特质。因此，对我而言，这是我最终会思考的问题。

举个例子，如果你本质上更热衷于写代码，而之前做PM的工作只是因为“有人需要这么做”，那么现在你干脆卸下PM的头衔，转而成为一名工程师，从工程的角度去干同样的事儿，设计也一样。

但如果你本质上最感兴趣的，其实是花大量时间与用户打交道,哪怕这会让你暂时远离开发工作，又或者你喜欢深入洞察用户需求，琢磨市场趋势，甚至尝试预见未来的发展方向等等。同时，如果你所在的团队规模足够大，已经有足够多的工程师了，那或许还能为产品经理留出一席之地。不过总的来说，我觉得关键还是在于：你到底最感兴趣的是什么。

我再补充一点：我仍然认为，每个问题都需要一位对此负责的人，但我并不觉得这个人非得是PM不可。

Romain：是的，我觉得这很大程度上取决于你刚才提到的产品性质。因为我们很幸运，能参与Codex项目，它其实是一款面向开发者的构建工具，而我们自己恰恰就是最优秀的用户。而且，得益于开源模式，我们还能与社区紧密合作。不过，就算退回到更早的阶段，比如我还在Stripe工作时，当时Stripe员工人数达到250人，却连一名PM都没有，甚至完全没用过任何AI工具，因为当时的Stripe就是一个API，而我们所有人都是工程师，都清楚一个真正出色的API应该是什么样子。于是，我们干脆就直接打造了那个我们梦寐以求的API。我们希望Stripe能变得优雅，只需寥寥几行代码就能搞定一切。

但如果你从事的是其他的领域，所处行业的垂直领域、业务空间或问题领域不同时，却依然想保持那种以客户为本的执着，那么你可能需要更多PM去投入时间，去花时间与客户互动。我们很幸运能够参与Codex项目，就像在打造一款我们自己一直梦寐以求的工具。

Alexander：比如，咱们举个例子：在某个领域，工程师们对此缺乏直观的把握。就像PM其实只是一个标签，指那种既能设计广告、写代码、又对用户特别感兴趣的家伙，你懂我的意思吧？其实，这同样也可能是个工程师，他对用户的需求同样敏锐而深刻。所以我觉得，这些标签现在多少有点失去原有的意义了，不过目前这样也还行，毕竟现在就是有点乱糟糟的。

Peter Yang：这正是我在团队中发现的。我发现，那些最优秀的工程师并不会来问我：“我们接下来该做些什么？”他们自己会去跟用户交流，弄清楚该开发什么，然后我们再一起讨论。感觉就像大家对这些事情都达成了共识一样。

Romain：你知道吗？Codex团队就是这样工作的。如今你在Codex应用中用到的许多功能，其实都源自工程师们从底层出发提出的绝妙创意，因为他们自己也想用这些功能。

Alexander：是啊，不过我想说的是，有一种工程师的特质特别吸引我，他们超爱和用户打交道，总琢磨着该开发些什么。当然，也有一类工程师，他们的能力同样出色，甚至可以说是极其顶尖，他们超级高效，特别擅长构建系统、缜密地思考架构设计，却对跟用户打交道毫无兴趣。

我觉得，这两种类型的工程师其实都有很大的发展空间。我看待人工智能时代的一个观点就是：我们每个人都可以更坦诚地做自己，做真实的自己。人工智能以及你身边的团队会帮你填补那些你不太想花精力去做的事。

Peter Yang：不过我确实觉得“Builder”这个标签特别重要。我感觉每个产品经理都想成为领导者，可问题是，传统的职业发展路径就是：你一路升到副总裁之类的职位，然后就没时间真正去Builder了，整天就忙着做产品评测，一会儿这儿提个反馈，一会儿那儿给点意见。我觉得很多产品经理其实不想这样，我也不知道你是不是也这么想，但反正我就是想离用户更近一点，多去实际交付产品。

Alexander：完全同意，我其实并不认为产品经理是个理想的领导岗位。我觉得它更像是一种填补空白的职位。偶尔确实可能需要一些领导力，不过即便如此，这种领导力也多半只是帮助大家步调一致，除非你真是个天才，能想出正确的战略。嗯，有一点我可以肯定：像OpenAI那些最优秀的PM，都深入到了一线场景。我觉得，以高级领导者的身份加入OpenAI，其实是非常有挑战性的，因为保持深入一线、亲历亲为依然至关重要。所以，你得想方设法挤出时间来，我认为在这里深入一线，从细节出发总是更好的选择。

07.

招聘要求和企业文化：

能动性优先，热爱创造和分享

Peter Yang：最后一个问题，你们终于又招了一位PM，我听说他叫Rohan，对吧？除了Codex的重度用户之外，你们在招募Codex团队成员时，还特别看重哪些素质呢？

Alexander：我觉得咱们俩都来说说这个吧。我之前就说过，能动性非常重要。那些真正能动手去做事的人是最重要的，在OpenAI，尤其是Codex团队就是如此。我们不是那种“加入进来后，先给你12个任务，按难度递增顺序完成就行”的团队。相反，我们会更像是欢迎你加入，然后就完了，看你自己了。所以我喜欢那些能够自我定位、积极行动的人，他们总是充满干劲和点子，乐于提出新想法，也并不介意与现有的观点唱反调。

毕竟，那些旧有的决定很可能只是我们偶然做出的。现在我描述的这种人，简直就是完美的队友。他们能欣然接受任何新增的工作内容或责任，哪怕这些任务尚不明确，我觉得，这样的人才是最理想的。

Romain：是的，我同意。就我所在的DevX开发者体验部门而言，通常那些能动性高的人显然都非常精通技术，比如能熟练掌握Codex这类工具。不过，我特别喜欢热衷于与开发者和建造者共度时光，乐于分享他们的知识的人。比如，就在本周，我们刚刚宣布，那位做了开源Codex Monitor的Thomas本月将加入我的团队。这真是太棒了！因为他不仅创意十足、产出丰富，还特别热爱分享自己使用Codex构建项目的经验。

我们需要吸引数百万开发者，共同迈向Codex那充满希望的未来。我认为，AI编程正在彻底改变我们思考软件开发、应用开发以及产品构建的方式。而这一切背后蕴藏着巨大的潜力，足以向全世界展示：任何人都能轻松打造出各种各样的东西，同时还能在过程中毫无保留地传授经验。这正是我所追求的，一种让所有人共同成长的未来。

Alexander：如果我理解有误，请告诉我。在我看来，DevX的职位描述就像一位非常优秀的工程师，同时也爱玩推特。

Romain：是的，你说对了一半，另外，我还想补充一点，那就是，对于我们来说不止推特很重要，当你前往世界某些地区旅行时，会发现一些开发者并不太活跃于这些平台，比如在欧洲和其他一些地方，他们更倾向于使用领英或其他平台。因此，我们确实需要多留意一下这种全球化的思维方式。我们很看重一个人是否喜欢社交，是否乐于花时间教学和分享。

Peter Yang：而且我觉得，在他们进入面试流程之前，就能大致判断出一些情况，比如，他们是不是常常在网上发布内容，比如开源项目之类的。

Alexander：是的，每当有人私信我，表示有兴趣跟我合作时，我就会看看这上面有没有他的作品链接。如果有链接，我基本都会点进去看看，说实话，我非常好奇，如果有些关于他想法的介绍，我通常也会仔细读一读。这话听起来有点奇怪，但如果对方只是简单地解释一下他们为什么对这个职位感兴趣，再附上他们的简历之类的东西，我反而没那么愿意去细看，我更愿意花时间琢磨他们的创意和他们做过的东西。另外，前几天有人问过我这个问题，我才意识到，自己根本不知道大家都是从哪所大学毕业的！

Peter Yang：是啊，谁在乎呢。我非常兴奋我们生活在这个学历越来越不重要的世界，反正也没人在乎，你只需要展示自己做过的东西就好。真的特别感谢你们，我超爱Codex，这周末我要亲手去做一些好玩的东西。

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

Alexander：谢谢你，Peter。

Peter Yang：好的，伙计们，再见。

文章来自于微信公众号 "AI应用风向标"，作者 "AI应用风向标"