1

双重杠杆变革：AI时代产品经理的工作方式与角色定位已彻底重塑

在OpenAI的办公环境中，从任意一点走到另一点，几乎无法避免听到“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工作的影响拆解为两个层次。第一个层次相对直观——具体做事的方法论变了。信息整合、上下文获取、文档撰写、跨工具协调——这些曾经大量消耗PM时间和精力的任务，如今可以大规模地交由Codex高效完成。

“我们每天从企业客户、推特反馈以及各类渠道，收到成百上千个数据点和待处理问题，”他举例说明，“我只需要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

先手动做一次，然后让Codex自行完成自动化

整场访谈中最具冲击力的部分，是Rohan当场演示的多个工作流。其核心模式可以概括为一句话：先手动执行一次，再让Codex自动完成整个流程。

他展示了自己是如何处理用户反馈的。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提出了一个概念——一次性软件（disposable software）。当用Codex创建一个软件的边际成本趋近于零，你就会开始做一些以前“不值得做”的东西。

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

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

这个思路在团队层面被放大成了更有趣的东西。OpenAI团队每个项目都有对应的Slack频道。Rohan开始为每个频道建一个Codex Site——一个自动从Slack对话中提取上下文、持续自我更新的项目全景页面。

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

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

6

线程编排器：让Codex管理Codex

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

Rohan承认自己还没到那个级别。但他揭示了一个最近的重大功能更新：Codex现在可以控制其他Codex线程。“你可以有一个高层的‘编排器线程’，它可以唤起、管理、等待其他子线程的结果。”这是一种新的编程范式——不是人写代码协调多个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，同时也让Codex在持续不断地变得更懂你的上下文。”

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

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