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

如果你在 OpenAI 的办公室里从 A 点走到 B 点，不可能听不到"Codex"这个词被提及。这不是夸张——Rohan Varma 说，如果 Codex 宕机，OpenAI 公司运营会陷入相当困难的境地。而他就是让这个工具变得不可或缺的人之一。

Rohan Varma 的路径有点意思。他是 Cursor 的联合创始人，一手打造了那个让全球开发者上瘾的 AI 编程工具。2026 年 2 月，他被 OpenAI 挖过去，身份从"创始人"变成了"产品经理"。但他说这个转换毫无违和感——因为 OpenAI Codex 内部的运作方式跟 Cursor 几乎是一样的：团队极小、速度极快、每个人都在用同一款产品来构建这款产品。

Peter Yang 的 Behind the Craft 播客邀请 Rohan 做了一期实操密集的访谈。Rohan 在访谈中做了多次现场演示——从 Slack 自动触发自动化、到用 Image Gen 快速生成设计变体、到把任何对话线程变成可复用技能。这不是"AI 时代的 PM 应该怎么做"的理论课，而是一个真实的 AI-native 团队的产品经理，打开他的日常工作给你看。

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

1

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

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

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

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

"以前产品开发是花大量前置时间做规划，确保工程师只做最重要的事，"他说，"现在完全反过来了——先做一切，再决定哪些值得真正发布。"

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

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

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

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

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

整场访谈最有冲击力的部分，是 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 标签触发自动化来冒充自己回复。"

"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 承认这是一个需要解决的问题。目前的做法很原始——"跑一下看看效果，觉得还行就继续用"。但他透露团队正在探讨如何在不同版本迭代中自动评估技能产出的质量。

Rohan 提出了一个概念——disposable software。当用 Codex 创建一个软件的边际成本趋近于零，你就会开始做一些以前"不值得做"的东西。

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

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

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

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

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

整场访谈中，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 也一样——最好的委托就是，它做完了回到你面前，你在中间不需要想它。"

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

Rohan 的答案比预期更普适。"不只是 PM，是每一个角色。AI 带来的不是'把同一件事做快一点'，而是用同样的时间做更多完全不同的事。"他在 OpenAI 和 Cursor 两家公司都看到了同一个现象——不是"工作效率提升了 50%"，而是"我们做了以前根本不可能去碰的事情"。

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

他给的一个最具体的建议也很简单：每次遇到问题，先问自己——Codex 能不能做？ 第一次试可能不行，那就问第二个问题："Codex 缺了什么信息是我有而它没有的？"然后想办法把那个信息给它。"这个过程一旦形成闭环，你就在持续不断地把更多事情推给 Codex，同时也让 Codex 在持续不断变得更懂你的上下文。"

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

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

原文链接：https://www.youtube.com/watch?v=fAdFE7y6K2o

点击关注我哦