OpenAI Codex 产品经理：AI 不是让你做更快，是让你做以前不敢做的事

1

两个杠杆：产品经理的工作方式变了，甚至角色本身也变了

在OpenAI的办公室，从A点走到B点，你几乎不可能听不到“Codex”这个词被提起。这可不是一句玩笑话——据Rohan Varma的说法，如果Codex宕机，公司运营会立刻陷入相当棘手的境地。而Rohan，正是让这个工具变得不可或缺的人之一。

Rohan的职业生涯轨迹本身就很有意思。他是Cursor（那个让全球开发者爱不释手的AI编程工具）的联合创始人。2026年2月，他被OpenAI挖走，身份从“创始人”变成了“产品经理”。但按他自己的说法，这个转换几乎毫无违和感——因为OpenAI Codex内部的工作方式跟Cursor几乎一样：团队极小、速度极快，所有人都在用自己打造的产品来继续打磨这款产品。

Peter Yang的播客“Behind the Craft”最近请Rohan做了一期实操密集的访谈。Rohan在节目里进行了多次现场演示——从Slack自动触发工作流、到用Image Gen快速生成设计变体、再到把任何一段对话变成可复用的技能。这不是什么“AI时代PM应该怎么做”的理论课，而是一个真实AI原生团队的产品经理，把日常工作摊开给你看。

以下内容编译自Peter Yang的“Behind the Craft”播客第138期《OpenAI PM Reveals How He Uses Codex to Do Product Work | Rohan Varma》，2026年7月5日发布。以下是完整编译。

1

两个杠杆：PM的工作方式变了，角色也变了

Rohan把Codex对PM工作的影响拆成了两个层面。第一个层面很好理解——具体怎么做事的“how”变了。信息合成、上下文获取、文档撰写、跨工具协调——这些曾经占据PM大量时间的事情，现在可以大规模地交给Codex去完成。

“我们每天从企业客户、Twitter反馈、各种渠道，收到成百上千个数据点和问题，”他举例说，“我只需要20分钟，就能完全上手一个全新的项目。Codex会自动爬进我们所有的工具——Notion、Linear、Gmail、Google Drive——然后把我来之前所有发生过的事情汇总给我。”

但第二个层面更关键：

。当一个团队里的工程师、设计师、产品经理全都在用Codex，协作的拓扑结构也就跟着改变了。OpenAI Codex团队的典型配置是——一个产品线只有一两个工程师，产品经理的角色从“中间人”变成了“两端校准者”：前端做战略方向的护栏设定，后端做推向市场的临门一脚，中间的执行层面完全可以放手让工程师和Codex自行推进。

“以前产品开发是花大量前置时间做规划，确保工程师只做最重要的事，”他说，“现在完全反过来了——

”

2

没有PRD，只有“做了再说”

这种“倒置”在OpenAI已经渗透到日常工作中了。Rohan举了一个很具体的例子：Codex不久前来了一次产品更新，在应用里加入了一个内置浏览器。这个功能是怎么来的？团队里一位工程师Adam某天早上来上班，对Rohan说了一句“你看这个”，然后把东西亮了出来——因为在做前端迭代时来回切窗口太烦了，他自己用Codex做了一个。

“他没有写需求文档，没有开对齐会议，就是觉得烦，然后做了一个。我看了以后说，‘这太棒了，我们想办法发出去。’”一个可以合入产品主干的功能，出生证上连一行PRD都没有。

Rohan还提到了一个正在硅谷流传的段子——“计划是写给Agent看的，不是写给人类看的”。如果你用Codex的goal功能，它就会自己迭代、自己完成目标、自己做微调。人类看计划的时间，不如拿来看实际跑出来的东西。

这背后是一个更深的组织逻辑：

。传统模式下，一个项目堆五六个工程师，协调成本开始吃掉速度。而当每个人——尤其是工程师——都用Codex大幅提升了单兵作战能力，产品决策就变成了大量微型决策的集合。“比较理想的状态是，工程师能自己做出那些微决策，不需要等我。”

所以Rohan的日常工作重心也偏移了。他花更多时间跟企业客户和团队待在一起，花更少时间在“信息合成”和“文档维护”上。“Codex处理手动部分，PM就花更多时间跟用户在一起——这本来才应该是PM该做的事。”

3

做一次，然后让它自己去自动化自己

整场访谈最有冲击力的部分，是Rohan当场演示的几个工作流。核心模式可以概括为一句话：

他展示了自己是怎么处理用户反馈的。OpenAI用Slack非常重，大量反馈散落在各个频道里。Rohan的做法是——先在Codex里开一个线程，手动把“从Slack收集反馈→归类→录入Linear看板”这个流程走通。走通之后，他只说了一句话：“现在设定自动化，每周做一次。”

Codex不仅能设置自动化，还能

。“我可能会加一句——做完以后给我发一条Slack消息。Codex就会去更新那个自动化的配置。”Rohan说自己大概有五六套这样的自动化在运行，覆盖了信息收集、反馈归类、状态更新等各种循环性工作。

但更让人头皮发麻的是“一次性触发式自动化”。他演示了一个场景——他给同事Alex发了一条消息，然后在Codex里设定：“当Alex回复我最后那条私信时，草拟一封回复客户的邮件。”Codex会在后台持续监控那条Slack私信，一旦触发条件满足，自动草拟邮件，然后

。

“Codex知道怎么使用自己，”Rohan说，“你不需要把需求拆分得很细。你说‘当Alex回了消息，发封邮件’，它自己会用底层能力——每几分钟检查一次Slack、构建合适的触发条件、完成后自我清理。你不需要想它是怎么做到的。”

Peter Yang半开玩笑地说：“所以你可以设一个自动化，让Codex假装成Rohan在Slack长帖里回复？”Rohan笑了：“对，我们团队里有人在用 @Codex 标签触发自动化来冒充自己回复。”

4

Image Gen不是让你把头发染蓝的

“Image Gen给我带来了一种近似AGI时刻的感觉。”Rohan说这句话的时候可不是在开玩笑。

他的论点是：人们普遍把图像生成理解为“把我头发染成蓝色”或者“给我生成一张猫的图片”这类消费级应用。但在产品工作中，它的真正威力是

。

他现场演示了——截了一张Codex的“选择项目”界面的截图，然后告诉Image Gen：“基于这个UI，生成四五个不同的设计变体方案。”几秒钟内，Codex吐出了五套截然不同的交互方案。不是文字描述，是视觉上可以直接讨论的mockup。

“这比写五个React假页面来探索方案快太多了，”他说，“我越来越觉得，产品创意的第一轮迭代不应该用代码做，应该直接用Image Gen做。”

他通常会先用Image Gen跑一轮视觉探索，选出一两个方向，然后下一个指令：“把第一个方案做成真正的原型，放到Codex Sites上，这样我可以分享给团队。”

这套流程里还有一个被反复使用的魔法：

。在Codex里，你可以在任何对话线程结束后，调用skill creator，告诉它“把刚才整个交互过程变成一个可复用的技能，以后我提类似需求时你知道我的偏好”。Rohan用它来固化设计语言：“你跟Codex交互了二十分钟调出一个满意的设计，然后你对它说‘把这个线程变成技能，确保以后产出的设计保持一致’——然后它真的会记住你的审美偏好。”

Peter Yang提到一个担心——如果不加审查地让AI反复更新技能，会不会把技能文件“slop化”？Rohan承认这是一个需要解决的问题。目前的做法很原始——“跑一下看看效果，觉得还行就继续用”。但他透露团队正在探讨如何在不同版本迭代中自动评估技能产出的质量。

5

“一次性软件”和自我更新的文档

Rohan提出了一个概念——

。当用Codex创建一个软件的边际成本趋近于零，你就会开始做一些以前“不值得做”的东西。

“我经常会让Codex直接做一个一次性的小app，”他说。一个常见的例子是，Slack积压了太多消息，他就让Codex “扫描我所有未读的Slack消息，找出最重要的需要回复的，然后生成一个本地网页，按优先级排列展示给我看”——整个过程可能不超过一分钟，用完就扔。

如果某个一次性工具被反复用到，他会再加一个自动化——“每两小时更新一次这个页面”。于是这个临时生成的小工具就变成了一个动态仪表盘，维护成本是零。

这个思路在团队层面被放大成了更有趣的东西。OpenAI团队每个项目都有对应的Slack频道。Rohan开始为每个频道建一个

——一个自动从Slack对话中提取上下文、持续自我更新的项目全景页面。

“以前大家都知道一个铁律——任何文档从你发出的那一刻就过时了，”他说，“但现在我们可以做出真正保持实时更新的文档。来了一个新同事，打开那个Site就能看到项目当前的全部状态。我自己也用它来快速catch up。”

文档不再是人写的，而是AI从真实工作流里“蒸馏”出来的。

6

线程编排器：让Codex管理Codex

整场访谈中，Peter Yang反复追问Rohan一个边界问题：你到底能同时跑多少个Codex线程？有没有像Peter Steinberger（OpenClaw创始人）那样让Codex真正进入到“系统管理系统的系统”层面？

Rohan承认自己还没到那个级别。但他揭示了一个最近的重大功能更新：

。“你可以有一个高层的‘编排器线程’，它可以唤起、管理、等待其他子线程的结果。”这是一种新的编程范式——不是人写代码协调多个Agent，而是Agent之间的自组织。

他日常通常跑五六个Codex线程，但心态是“委托制”。“我不会坐在那里等Codex出结果。我在开会前丢给它一个任务——比如为明天跟某团队的会议准备一版slide deck——然后我就去开会了。开完会回来，打开Codex，看到结果已经在那里了。”

他拿Codex的“PR看护”功能做了一个更形象的类比：以前一个pull request从提交到合并，你需要盯十次——CI挂了改一下、同事评论了回一下、又挂了再修一下。现在你只需要说“看护好这个PR，CI过了、人类评论处理完了、一切就绪之后在Slack上ping我”。然后你只在最后一步介入——“好了，可以合并了。”

“如果一个人能管一个小团队，你不会要求这个人的每个动作你都要实时跟踪，”Rohan说，“Codex也一样——最好的委托就是，它做完了回到你面前，你在中间不需要想它。”

7

无关PM，关乎“杠杆感”

Peter Yang在结尾问了一个送分题：PM这个职业是不是会变得更好玩？

Rohan的答案比预期更普适。“不只是PM，是每一个角色。AI带来的不是‘把同一件事做快一点’，而是

。”他在OpenAI和Cursor两家公司都看到了同一个现象——不是“工作效率提升了50%”，而是“我们做了以前根本不可能去碰的事情”。

他用了一个词来描述自己的感受——“不受约束”。Codex连接了他所有的工具：Slack、Linear、Notion、Gmail、Drive、Figma插件、内部自定义插件。在这个信息密度和工具密度下，“我想不出上一次说‘这不可能’是什么时候了。现在的问题——不是能不能做，是做哪个。”

他给的一个最具体的建议也很简单：

第一次试可能不行，那就问第二个问题：“Codex缺了什么信息是我有而它没有的？”然后想办法把那个信息给它。“这个过程一旦形成闭环，你就在持续不断地把更多事情推给Codex，同时也让Codex在持续不断地变得更懂你的上下文。”

Peter Yang在结尾说了句大实话：“模型的能力早就超越了大多数人的野心。”

Rohan接得很快：“对。你应该把目标定得比合理的上限再荒谬10倍。它大概能完成90%。然后你重新设定——比刚才那个又荒谬10倍。”