在 Codex 团队，spec 这件事已经变得很轻了。很多时候，文档里只有 10 条要点，后面就直接进入开发。
这种变化，和模型能力抬升有很大关系。前几年，大家还在反复研究 Prompt，也在努力把 spec 写得更完整、更结构化，希望模型能更稳定地照着执行。现在，Codex 团队讨论得更多的是 skills。他们开始把常见任务整理成一组组可以直接调用的能力，再交给模型去跑。
于是，spec 不再占据最前排的位置，skill 正在变成新的入口，开发这件事本身，也在从“描述过程”转向“组织能力”。
我们翻译了这期最新播客，里面聊到的不只是他们怎么做产品，更重要的是，OpenAI 内部对 coding agent、skills 和开发方式的理解，已经在跟着模型能力一起变化。
以下是播客翻译，内容略有删节：
写 spec？我们大概写 10 个 bullet 就结束了
Peter Yang：大家好，欢迎来到今天的节目。我今天很高兴邀请到 OpenAI Codex 团队的 Alex 和 Romain。Alex 是 Codex 的产品负责人，Romain 负责开发者体验。
Alex / Romain：谢谢邀请，很高兴来聊。
Peter Yang：我其实很好奇，你们团队内部到底是怎么用 Codex 做产品开发的。Alex，你们现在还写 spec 吗？还是说已经让 GPT 来帮你写 spec 了？一般会怎么做，用什么模型？
嘉宾（Alex）：我觉得，在 Codex 团队里，我们现在写的 spec 已经非常非常少了。实际上，我们有一个很核心的想法，就是尽量让那些“最接近底层实现的人”自己做尽可能多的决策。
所以，只有在一种情况下我们才会写 spec，那就是这个问题已经复杂到很难装进一个人的脑子里。因为说实话，现在一个人其实已经能在脑子里装下很多东西了，毕竟他可以把大部分编码工作委托出去。所以单个人现在能完成的事情，比以前大得多。
但如果这件事发展到需要几个人一起协调，或者它牵涉到某个特别棘手、特别复杂的决策，那我们才有可能写一个 spec。不过即便真的写，这种文档通常也会非常短。你可以想象一下，大概就是 10 个 bullet（要点） 左右，然后就结束了。
主持人：那你们能不能具体演示一下？比如说，你们先给 Codex 几个 bullet，然后它再去写更完整的需求，或者先写成一个 markdown 文件之类的？
嘉宾（Romain）：可以这么做。不过我还想顺便给你看一个特别简单但很能说明问题的场景。比如现在开发的一个 iOS 应用，只需要语音输入一句话，比如：“帮我加一个关于 NASA 阿尔忒弥斯登月任务的新页面”，然后把这个 prompt 发给 GPT-5.4。模型就会直接帮我生成这个 iPhone 应用的新页面。
假设现在已经快完成一个任务了，然后你脑子里开始冒出一些新功能的想法，但你自己也不完全确定下一步应该往哪里走。
这个时候，用 Codex 很有意思的一点在于，如果我现在开始说“我们来规划接下来的步骤吧”，你会发现 Codex 能自动理解，我现在是在试图为接下来要构建的内容做计划。如果我按一下 Shift+Tab，它就会进入 plan mode。然后如果我说，“我们接下来应该做什么？”我就可以把 Codex 当成一个 brainstorming partner，一起规划下一步。
在这个模式下，它会看当前代码，看项目目前的状态，然后自己提出一些想法。我也可以把自己的想法加进去，慢慢把模型往一个更好的计划方向引导过去。
所以你现在可以看到，它已经开始基于项目现状、代码和文件内容，自己生成一些主意。
所以我就会像这样去使用 Codex。当然，在这个演示里，我一开始没有给太多输入。如果是 Alex 这种产品负责人，肯定会在前面给更多指导。但在这里，我是故意先让 Codex 自己去提出一些思路。
嘉宾（Alex）：很多改动其实可以分成几种类型。有一种是特别简单的，那你就直接进去 prompt 一下，立刻改。还有一种是中等复杂度的，这时你可能会先想一想该怎么做，或者让它先输出一个具体计划。
但我自己还有一种很常见的做法，和刚才这个例子很像。就是当我脑子里只有一个很模糊的念头时，我会直接打开 Codex，让它先开始思考“这个问题可能怎么解决”。这时候我甚至还没有一个明确的 feature 定义。然后它会自己去探索，回来问我一些问题。
而且很多时候，我最后甚至不会真的采用那套方案。因为有些改动可能最后证明会非常复杂。这里稍微岔开一下，其实“PM 应该写什么代码”这个问题本身就挺值得讨论的。对我来说，如果是一个复杂改动，我并不一定想亲自负责把它合进去并长期维护，但我还是会走一遍这种 plan mode 和探索过程。这样一来，我对这个问题需要怎么做，就会形成一个更好的 mental model。
最后，我会把这种“思考结果”而不是那个 plan 本身交给工程师。我觉得真正有价值的，常常不是那份计划文档，而是我通过这个过程形成的理解。
既然刚才岔到了这个话题，那我就顺着说一句。我们 Codex 团队里的设计师，现在写的代码，比大概 6 个月前很多工程师写的还多。我们自己有时会开玩笑说，他们现在真的猛得离谱。当然，这里面工具起了非常大的作用。
而且团队里之前还会拿我开玩笑，说我过去一年合进去的 PR 实在太少了。具体数字我就不说了，但我自己也承认，确实应该更多一点。尤其你再考虑到，其中很多 PR 其实都只是一些很小的改动。”
不过我觉得现在整个问题已经变了。重点不再是“你能不能把代码生成出来”，因为 agent 在这方面已经非常厉害了，你完全可以把任务委托给它。真正越来越重要的，其实是你决定去做什么。也就是说，我们到底有没有在方向上对齐，我们是否真的清楚这个产品正在变成什么。
而在这之后，另一个同样关键的问题就是，我们怎么确保最后出来的东西是高质量的。现在有些人会很骄傲地说，整个 app 都是 vibe coded 出来的。对 Codex 来说，其实绝大多数代码也确实是 agent 生成的。但即便如此，我们仍然花了很多精力和注意力去思考系统本身，去确保它真的有很高的质量。
所以这也是为什么，如果碰到一个特别复杂的功能，我通常会确保它有一个更稳、更长期的 owner 去负责。我不太觉得 PM 应该去拥有这种系统的一部分，因为 PM 的价值很大程度上恰恰在于他们会被各种事情打断，他们会四处游走、填补空白。所以你未必希望由 PM 来长期维护这些系统。
Peter Yang：对，你肯定不希望一个 PM 去维护某个功能的代码吧。听起来就不像个好主意。我觉得我们一定会把这事搞砸。说得很真实。不过说到产品本身，我也确实挺喜欢 Codex 这种感觉的。外面其实也有其他很强的产品，我也挺喜欢，但很多工具真的要花很多时间去学。我甚至感觉，如果我平时不刷 Twitter，我可能根本不知道那些别的 Pro 产品到底该怎么用。但 Codex 有一点我特别喜欢，就是它上手非常简单。整个 app 非常直觉化，很简单。但与此同时，它又有一些很高级的能力，比如 skills 和 automations。你们内部会大量使用这些吗？
嘉宾（Romain）：会，非常多。真的非常多。实际上，我觉得 skills 可能是 Codex app 这个产品界面里最有意思的一类能力。
比如说，你正在和设计师一起工作，他们用的是 Figma。那现在特别棒的一点是，你可以打开 Figma skill，它会直接把 Figma 文件里的细节拉进来，包括 React 组件、变量等等，然后 Codex 会按照这些内容直接把实现写出来。
再比如说，你正在做一个 app，做完之后你想分享给别人，或者部署到 Vercel、Cloudflare、Render 上。这些 skills 都已经在那里了。你只要直接告诉 Codex 你想做什么，它基本上就能接进这一整套任务生态里。
前几天我和一个朋友聊天，他跟我说，自己脑子里有一大堆想法，想改进产品。他就直接跟 Codex 说，用那个 skill 把这些任务全都写进 Linear，这样我就能一路跟踪。然后等所有任务都列出来以后，他又说，那我现在要去睡觉了，你继续把我们刚才讨论的这些任务一个个实现并划掉吧。结果第二天醒来，所有事情真的都做完了。
OpenAI 对 Codex 的判断变了：开放 Harness，把舞台交给模型
嘉宾（Alex）：回到 Codex 的简单性问题，我觉得分享一下我们的设计思路可能会很有意思。
我觉得在这个领域做产品，有一件特别有意思的事，就是开发者天然就很喜欢给自己造工具，喜欢自动化工作流程。所以对我们来说，一个非常重要的原则就是，产品必须足够可配置。
比如 Codex 的 harness 是开源的。用户真的可以一路往下钻，改得非常深。甚至经常会出现一种情况，就是我们在做某个功能时，这个功能明明还没在正式环境里打开，Twitter 上却已经有人在抱怨这个功能坏了。原因是这些人自己跑去改代码，或者 fork 了项目，硬是把功能提前弄出来用了。但对我来说，这恰恰是产品最棒的一部分。因为这意味着，最前沿的用户其实已经在和我们一起生活在未来，他们一边探索，一边把我们往那个未来拉过去。
不过另一方面，如果你只为这群人设计产品，最后做出来的东西就会变得几乎无法理解，用户真的会像你刚才说的那样，整天都得泡在 Twitter 里才能知道怎么用。
所以我们的想法一直是，我们会非常谨慎地去定义那些核心原语，也就是产品最基础、最关键的部分。那些地方是需要真正写下来、认真想清楚的，而不是随便 vibe coding 一下就算了。
我们会很认真地思考，怎样让整个产品尽可能“隐形”，尽量不要挡在模型前面，而是给模型让路。这样每当模型变得更强一点，它就能自然地做更多事情。然后在这个基础上，我们再考虑怎么把它包装成一个尽可能可配置的系统，交给高阶用户去探索。
比如说，现在社区里其实已经有人在实验 sub-agents 的实现了。这个东西已经在外面跑起来了，大家在用、在折腾，而且我们也从他们的使用方式中学到了很多。虽然这个功能并不是我们现在在产品里主动推给所有人的，但用户已经自己发现并开始用了。
然后下一步，我们就会思考，怎么把这些东西进一步做得对其他人也非常简单。所以 Codex app 本身其实就是这样一个例子。大概是在 GPT-5.2 Codex 那个时间点，我记得是 12 月左右，模型能力本来一直在稳步提升，但突然之间我们跨过了一个阈值。到那个时候，你已经可以把更长、更复杂的任务委托给模型了，而且它往往还能直接一次做出来。
于是我们开始看到，很多人其实已经在用 tmux 了。对不了解这个词的人来说，tmux 本质上是一个“终端复用器”，可以在一个终端里同时管理多个会话、窗口和分屏，让你并行跑很多任务。
然后我们开始在社交媒体上看到一些很疯狂的画面，比如 Peter Steinberger 的那张图——十几个终端 pane 铺满三块显示器，用 Codex 同时跑一堆事情。
我们当时一方面很兴奋，一方面也继续确保这种“委托执行”的能力在最基础的 CLI 产品里是可靠的。但后来我们意识到，这可能是最顶尖那 1% 工程师的工作方式。问题变成了，我们怎么把这种体验做得足够直观？
于是 Codex app 就出现了。你打开它时，感觉非常简单，像一个聊天窗口。它能帮你做事情。接着你慢慢开始发现，原来还有一个侧边栏，原来我可以同时跑多个任务，原来我切换这些任务特别容易。然后你会开始觉得，自己变得特别高效。接下来你又会发现，啊，原来这里还有一个 skills 标签。我们希望把这个体验做得有点像玩游戏一样，你是在一步一步发现下一个能力。
嘉宾（Romain）：完全是这样。而且我觉得，从一开始我们就一直有一个很清晰的愿景，那就是未来的 coding，会越来越变成一种“把任务交给 agent 去完成”的模式。
哪怕是一年前我们刚开始做 Codex 的时候，我们其实就在设想这样一个未来：工程师会同时并行处理很多事情。
只是那时候，模型的能力还没有真正到位。后来我们看到了 GPT-5.2 Codex 以及之后的模型拐点，模型开始能够非常细致、非常可靠地连续工作好几个小时，甚至几天。到了那个阶段，你再回头看，发现如果还只是让用户在终端里开一堆 tab，然后让它们跑上几个小时，那其实是个挺奇怪的交互方式。
所以我们才需要一个新的产品形态。而我觉得，后来变成 Codex app 的这个界面，恰好就在那个时间点成熟了，时机刚刚好。
嘉宾（Alex）：对，Codex 的历史里其实有过两次很明显的“氛围切换”。
第一次大概是在 8 月。当时我们推出了 Codex 的云端产品。这个想法本身非常好，大家当时很兴奋，现在其实也还是很兴奋。不过从时间点上看，它有点偏早了。
大概也是在 8 月前后，我们发布了 GPT-5 的交互式编程模型。我们当时的想法是，好，那就先去解决“模型现在已经能解决的问题”。于是我们推出了 Codex CLI 和 IDE 扩展，之后增长就开始爆发。我记得那几个月里，规模大概涨了 20 到 30 倍，这当然非常棒。
第二次变化则发生在 12 月到 1 月左右。到了那个时候，我们终于可以重新回到最初那个愿景，也就是把工作真正委托给模型去做。
我们只做短期和长期规划，从不做中期规划
Peter Yang：我们不妨再深入一点聊聊 Codex app 的开发过程。你们当时有没有那种年度路线图？比如一年前就已经写好，“到某个时间点我们要发布 Codex app”？还是说你们更多是看到市场开始往这个方向走，然后做了一堆原型？这个产品到底是怎么做出来的？
嘉宾（Alex）：都不是。其实我之前从 OpenAI 一位研究员 Andre 那里听到过一个特别好的建议。他跟我说，在 OpenAI，你要么做短期规划，要么做长期规划，但不要做中期规划。
因为中期规划太难了。所谓短期，通常就是从现在开始到未来八周以内，八周基本已经是上限了。你要想的是，有没有一个足够具体的目标，能让团队围绕它真正集结起来，把它做出来。这一点我们在 OpenAI 其实很擅长，就是围绕一个明确目标把团队组织起来。
而另一种规划方式，就是去把握一种更长期的“感觉”。比如你会想，一年以后，模型一定会聪明得多。现在我这么说听起来已经很显然了，而且事实上这个变化甚至没用到一年，但如果回到当时，你可能会这样想：
未来我们会有非常强的模型，我们不会再想把自己的电脑“借给它们”去做事，因为那样一次只能做一件事。我们真正想要的，是几乎无限多个模型同时独立工作，它们自己验证结果，甚至自己部署代码、自己监控运行状态，可能到最后我们甚至都不需要再一条条去 prompt 它们。
所以你会先去想象这样一种未来的整体气质和方向。至于夹在中间的那一层，反而很尴尬。所谓中间层，通常就是产品路线图，而我们基本上并没有那种传统意义上的 roadmap。
我们真正拥有的，是长期方向，以及一些我们认为能把我们推向那个方向的具体事情。比如就 Codex app 来说，我们当时有一个战略目标，就是让自己从某个“特定工作区”里解耦出来。
这个说法有点抽象。我具体解释一下。假设你在用 IDE，比如 VS Code，那也是我最喜欢的 IDE。你打开 VS Code 的时候，通常只能对应一个特定 workspace，也就是某一份具体 checkout 出来的代码，一整个具体的文件夹。
即便你在用 git worktree，本质上你一次也只能打开其中一个 worktree。所以归根结底，你一次基本上只能处理一件事。CLI 也是一样。但因为我们从一开始就有那个愿景，我们希望用户是和云端那些被他们委托出去、独立运行的 agents 一起工作的，所以我们知道，产品最终必须走到这样一个状态：你同时和多个 agent 对话，甚至只和一个 agent 对话，但这个 agent 背后其实正在替你编排多个 agent，这件事要变得非常自然。
不过我们也学到了一件事：如果你一开始就从云端切入，对开发者来说其实不太容易获得价值。因为他们常用的工具不在那里，你还得先做环境配置。而且一个任务如果模型只完成了一半，你很难拿到“部分成果”。很多时候，模型做到一半时，你是需要插手去修正方向的，或者稍微拨一拨它。
所以我们就在想，我们需要一种本地体验，这种体验要脱离某个特定文件夹的束缚，但同时又要让你在自己电脑上的各个文件夹之间工作时感觉非常自然。
于是，当我们开始做这个 app 的时候，上面先有一层这种比较抽象、甚至有点玄的方向思考。同时，工程师那边其实已经有很多原型了，都是各种“我真希望我们已经有个 app 了”的实现。有人做这种版本，有人做那种版本。我们甚至还办过一次黑客周，当时有好几个人各自独立做了不同版本的 app。你可能当时也做过一个，我有点记不清了。
所以，这个项目真正开始的时候，唯一真正需要写下来的，其实只是我们为什么认为“做一个 app 是个好主意”。至于 app 本身并没有一份非常具体的 spec。后来当然也逐渐在开发过程中生成了一些文档，但一开始其实争议还挺大。
当时大家真的在争论：我们到底该不该做一个 app？毕竟 IDE 扩展已经非常受欢迎了，我们是不是应该只专注把 IDE 扩展继续做好？CLI 也很重要，CLI 看起来就是这个领域很核心的东西。那如果我们真的要做 app，意义到底在哪里？它应该走向哪里？这些问题一开始其实都没有标准答案。
嘉宾（Romain）：不过幸运的是，当时我们的 IDE 扩展已经做得相当成熟了，打磨得很多。你可以在 VS Code、Cursor、Windsurf 等环境里使用它。所以我们其实把 IDE 扩展代码库里很多成熟经验带了过来，作为一个已经很稳固的起点。
嘉宾（Alex）：对。实际上，app 和 IDE 扩展共享了不少代码。更准确地说，它就是直接和 IDE 扩展共享同一部分代码。
而在底层，不管是 app 还是 IDE 扩展，调用的都是同一个 Codex 核心 harness。这个 harness 是用 Rust 写的，是开源的，CLI 也是基于它。所以这里面有大量共享，也有非常刻意设计过的分层结构。
Peter Yang：不过话说回来，现在回头看，做 app 这件事好像已经很显然了。毕竟直接用 Codex app，肯定比开一堆终端窗口轻松得多。但在当时，决定去做这个 app，背后的核心理由其实是：它对新手更友好，而且你真的可以像玩一样去上手。它是同时管理多个 agent 的最佳界面？
嘉宾（Romain）：对。我觉得我们的思考方式一直都非常“AGI 导向”。我们一直在想，我们正朝着什么样的未来滑过去。
不过如果调整一下顺序，其实更准确的说法是：我们先知道自己必须做出一种界面，让“把任务委托给多个 agent”这件事显得非常自然。因为我们知道，模型迟早会准备好支撑这种方式。事实上，我们已经看到有人开始在不同 agent 之间做任务委托了。
所以我们需要一个界面，在里面这种事情必须很自然，而且未来扩展到云端时也要非常顺畅。同时整个体验必须符合人机工学，不能让用户觉得自己是在很别扭、很费劲地折腾“如何同时委托多个 agent”，而应该让人感觉，这本来就该是最自然的工作方式。
嘉宾（Romain）：而且顺便说一句，这种体验吸引的绝不只是初级开发者。恰恰相反，哪怕是在 OpenAI 内部，那些最高产、最资深的工程师，现在也在把 app 当成主要工作方式。比如 Peter，从 OpenClaw 来的，还有 Greg Brockman，他们现在都在主要用这个 app 来构建东西。
所以这件事本质上真的是“agent 式委托”愿景在落地。并不是说最厉害的工程师都会永远留在终端里，事实上他们也在转向 app。
嘉宾（Alex）：对，希望如此。我们一直提 Peter，是因为他刚加入 OpenAI，我们真的特别兴奋。毕竟他做过 OpenClaw，创造力也非常强。我不知道我之前有没有跟你说过，去年 10 月的时候，我曾经在旧金山跟他一起散步。
当时我没有直接告诉他我们在考虑做 app，但我已经开始试探性地聊这种新界面的想法，也就是让“任务委托”变得更自然的界面。他当时的态度基本上是，他绝对不会用这种东西。
结果到了上周末，他居然在 Twitter 上发，说这个 app 其实挺不错的。简直太阳打西边出来了。他现在居然开始喜欢了。
Peter Yang：我也和 Peter 聊过。如果你们真的让他开始用 app，那绝对是一个重大成就，因为他平时可是会同时开二十个终端窗口的人。这真的很夸张。Alex，你之前有很长一段时间好像一直是 Codex 唯一的 PM，对吧？那 Codex 团队现在大概多少人？五十？一百？
嘉宾（Alex）：差不多就在那个范围吧。大概是这样。我们去年 5 月的时候好像才八个人左右，是吧？
嘉宾（Romain）：对，差不多。
嘉宾（Alex）：具体数字我现在也记不太清了，但从那之后我们确实增长得非常快。所以现在大概在五十到一百人之间。
模型变强之后，Codex 用 Skill 接管一切
Peter Yang：那你平时一天到底怎么过？你典型的一天是什么样？还是说根本没有什么“典型的一天”？
嘉宾（Alex）：有意思的是，我最近也在想这个问题，因为我发现自己其实不太会回答。我后来意识到，我的工作状态其实会切换到不同模式里。
先说明，这不是给别人的建议，只是我个人的工作方式。比如，在我们发布 app 之前，我就处在一种非常纯粹的执行模式里。那种状态下就是全力盯执行， obsess 质量，确保我们没有漏看任何角落，把每一个小细节都落下来。
在这种模式里，我其实会花很多时间待在 Codex 里。一方面是因为我们确实会大量用 Codex 来理解当前发生了什么。比如我会用 Codex 去看 Slack，到底大家反馈了什么；我会让 Codex 把这些内容总结出来，接着跟进，再发到 Linear 里。所以，光是理解当前质量状态这件事，我们就会大量用 Codex。
另一方面，我也会用 Codex 去理解代码层面的事情，然后直接用 Codex 做修改。因为现在如果只是一个小改动，而不是重新造一个系统，通常直接让它帮我做完、我再测试、发一个 PR，往往比我去找别人沟通、再让对方从一万件事里给这个任务排优先级要更快。尤其是在我们当时目标是两周内把 app 发出去的情况下，更是如此。
除了这些之外，当然还有很多非常“人”的部分，比如打气、动员大家，但同时也要对我们正在做的东西保持批判。所以这是一种我很明确能感知到的工作模式。很有趣的是，如果我处在这种模式里，你会发现我会更常上 Twitter。我也不知道为什么，但只要你问我这种偏社交层面的事情，我通常就会在那段时间更常刷 Twitter。
但我还有另一种模式。比如现在，对我来说一个特别强的感受是，我们已经到了这样一个阶段：模型非常强，GPT-5.4 非常惊人；与此同时，app 这个产品形态也比我们预期的更受欢迎，而且现在我们已经覆盖了包括 Windows 在内的所有平台。
所以现在我脑子里的重点就变成，好，该重新回到云端了，我们应该在那边投入更多。这种阶段下，我就会花更多时间去思考“下一步到底该做什么”，去理解整个局面现在是什么状态。
这更像是一种协调模式。在这种模式里，我反而会少花一些时间在 Codex 里写代码，而更多把 Codex 用在沟通上。所以至少对我来说，我能明显感觉到自己有这两种模式。可能还不止两种，但最明显的至少是这两类。
Peter Yang：那你平时需要做多少跨职能对齐？
嘉宾（Alex）：Codex 团队本身非常棒。我们在团队内部其实做得很少这种跨职能对齐。我们多少有点故意把自己当成一艘“海盗船”式团队。
哪怕在 Codex 团队内部，现在也只是我，再加上最近刚加入的两位 PM，还有几个 lead。其实直到不久之前，大家基本都是什么都一起扛。我们的工作方式更像是一群人混在一起快速推进，而不是做很多正式对齐。
所以在团队内部，这种对齐并不多。但现在越来越明显的一点是，构建 Codex，很大一部分其实是在构建一个 coding agent。而现在大家都已经能看出来了，或者说这件事对所有人来说应该已经很明显了，coding agent 不只是对写代码有用，它对很多其他类型的工作也同样有用。
我们已经看到很多人用 Codex app 做的不只是写代码。他们在整个软件开发生命周期里的各类任务上都在用。再进一步，现在 OpenAI 里其实绝大多数人都在用 Codex app，甚至不只是技术岗位的人。我在公司里到处都能看到这个 app。
所以，当你意识到 Codex 不只是服务于写代码的人，而是要在更广泛场景里变得有用时，就确实需要更多跨职能对齐了。因为 OpenAI 还有 ChatGPT，而且那是一个被非常非常多人使用的产品，所以我们必须认真思考这件事该怎么做。
嘉宾（Romain）：而从开发者体验这边看，我们现在也几乎已经成了 Codex 团队的延伸。我们现在大部分精力都放在 Codex 上，但原因有几个。
一方面当然是因为这是个很令人兴奋的产品，而且开发者真的很喜欢用 Codex，我们也会继续把它做得更好。另一方面，像 Alex 说的那样，我们自己其实也有不同模式。比如在准备发布的时候，我们会和 Codex 团队一起冲到最前线，准备发布资产、准备各种材料、思考怎么把 Codex 的价值最大化地呈现出来。等到产品发出去之后，我们又会进入另一种状态，去教育开发者如何以各种不同方式使用 Codex。
但还有另一层原因，让这件事对我们来说特别重要。那就是当你把视角放到更大的 OpenAI 平台上时，你会发现，现在已经有数百万开发者在基于 OpenAI API 构建东西了。他们在使用模型，也在使用各种不同模态的能力，从图像生成到 Sora，再到 speech to speech。
而且你知道吗？现在对开发者来说，最好的构建入口已经变成 Codex 了。如果你把时间拨回到一年前，甚至只是回到去年夏天我们刚推出 GPT-5 的时候，当时我们还需要写很多很多指南，去教大家怎么 prompt GPT-5。因为它是一个推理模型，和 GPT-4 那种模型差别挺大。
但现在我们的做法已经变了。哪怕是这些使用场景，我们也会尽量教开发者直接使用 Codex 和 skills。比如说，如果你有一个集成需要更新，那你大概率就应该直接用 Codex 配合相应的 skill，而 Codex 通常也确实能帮你把这件事处理掉。
所以从这个角度说，我们的工作也变得非常跨职能，因为我们已经把 Codex 看成整个开发者平台的基石。
嘉宾（Alex）：还有一点我觉得很有意思，就是我们彼此协作的方式。说真的，我觉得在 Codex 工作最棒的一部分，其实就是社区。包括线上互联网社区，也包括线下活动里遇到的人。很多事情我们其实都是围绕这个核心来组织的。
比如我们非常看重发布节奏，什么时候发新东西；也非常看重反馈，社区什么时候开始给出反馈，我们就尽快修、尽快沟通。所以我们整个团队都非常“在线”，一直在紧盯社区动向。
就拿 Codex app 的发布来说，当时我们和 Dom 团队合作得非常紧密。他基本上是在帮我们协调一个范围相当广的 alpha 测试，覆盖了很多用户。我们是和这些用户一起做产品，一边拿反馈，一边补 skills，一边完善 app 用到的能力，同时还要准备文档等等。
所以我觉得，这其实是 Codex 团队一个很独特的优势。归根结底，还是因为我们是开源的。正因为我们是开源的，很多事情最后就自然演变成，我们对自己在做的事情非常开放。而社区也确实会回报这种开放。
现在我们甚至已经有 Codex ambassadors，分布在很多很多城市和国家，他们会自己组织本地活动，去教各自社区的人怎么用这些东西。我当然很希望自己能去每一座城市，但这显然不现实。所以看到社区自己这么有能量、这么有热情，主动去办活动、办 hackathon、一起构建东西，真的特别棒。
“龙虾”将被整合进 ChatGPT
Peter Yang：接下来我们聊聊 Peter。我算是 OpenClaw 的早期用户。它确实有点糙，有点小毛病，但它真的已经帮我做了很多事情。比如前几天，因为它会记住我们之前的对话，它居然给了我一段大概三分钟、非常粗鲁但又特别提气的“精神喊话”。说实话，那可能是我从 AI 那里听过最有洞见的一段话。所以我很好奇，你们现在是怎么把 Peter 整合进团队里的？还有，这种“个人 agent”的愿景，是不是也属于他现在在做的事情？你们是怎么理解这件事的？
嘉宾（Alex）：这里面其实有两层。我能讲的范围有限，不过第一点是，他本身就是 Codex 的超级、超级重度用户。OpenClaw 本来就是大量基于 Codex 做出来的，所以他现在会不断给团队带来反馈，也会实际上参与很多帮助 Codex 变得更好的工作。某种程度上，这是他的“副业”，但他确实在做，我们也非常兴奋。
至于另一部分，我现在还不能说太多。但大方向上，确实是在帮助我们构建下一代个人 agent，而且是把它做进 ChatGPT 里。
嘉宾（Romain）：我觉得 Peter 最让我着迷的一点是，当然，我认识他已经有一段时间了，而且很多人在第一次玩 OpenClaw 的时候，都已经看到了一点“未来的样子”。
但真正厉害的地方在于，Peter 很早就看到了这个愿景。如果你回头看整个 2025 年，他去年做了 40 多个开源项目，但这些项目其实都围绕同一个愿景展开：我需要一个命令行接口来访问我的日历，我需要一个命令行接口来访问我的推文和 Gmail。
他通过持续做这些项目，实际上把一种愿景具体化了。这个愿景就是围绕 skills 和命令行工具，把今天我们用于 coding agent 的这套东西搭起来。而未来它显然不会只停留在 coding agent，它会变成各种类型的个人 agent。
所以，Peter 会非常适合在这个过程中持续给我们反馈，因为这些今天已经进入 open core 生态的工具，本身很多就是他一路亲手搭起来的。
Peter Yang：我的感受也是这样。Romain 说得对，他就一个人，却搭起了这么一个很棒的开源社区。而且说真的，它已经让我越来越不想打开别的 app 了。我现在就是直接和我那个小 bot 说话就行，这完全不一样。
嘉宾（Alex）：等等，你都把它连到什么上了？你是全都接上了吗？
Peter Yang：差不多吧，我接了很多很多东西。它能看到我的银行信息、YouTube 信息，还接了语音、日历、Google 的各种东西。有时候我躺在床上跟它说话，我老婆还会问我你在跟谁讲话，我就说，我在跟我的 OpenClaw bot 讲话。它会一直给我想法。不过确实，外面现在也有很多人在靠“帮人搭 OpenClaw”收费，开价甚至到 5000 美元。所以如果你们真能把这件事做成面向大众市场、普通人也能顺畅用的产品，那会非常非常大。
嘉宾（Alex）：对，我们正在做。之后再向你汇报。
传统职业阶梯，已经越来越说不通了
Peter Yang：好。那我们差不多收个尾，聊点更有火药味的话题吧，Alex。也许是我记错了，但我好像见过你说，很多团队现在其实已经不需要那么多 PM 了。我们把这个问题说得更刺激一点。你怎么看，兄弟？我们到底还需要 PM 吗？
嘉宾（Romain）：我觉得这些工具最惊人的地方在于，它带来的变化甚至不只是“需要 PM 还是不需要 PM”这么简单。
在我看来，几乎所有职业阶梯之间的边界都开始模糊了。以前会觉得，设计师在这边，工程师在那边，PM 在另一边，然后它们之间可能有某种人数配比，像一种理想结构。
但现在，如果你是工程师，当然你会变得更高效；如果你是设计师，你也突然获得了一些“超能力”，可以变得更技术化；如果你是 PM，而你以前主要做的是写战略文档，那现在你已经可以直接做原型了。
这并不意味着你一定要负责那个面向十亿用户的功能，但你完全可以通过“亲手做出来”的方式，把那个愿景的一个切片展示给团队看。所以我觉得最迷人的地方就在这里，所有职业阶梯之间的线都在变模糊，而我们都正在变成 builder。
嘉宾（Alex）：这个我很有共鸣。我试着回忆一下我到底说过什么。我印象里，好像我在网上说过一句，大意是如果一家创业公司工程师还不到 20 个，却已经配了 PM，那可能是个危险信号。
但我想表达的，其实和你刚才说的很像。现在所有角色的边界都在混在一起。设计师可以做更多工程工作，工程师可以做更多设计，PM 也可以做更多构建工作。
而且过去很多工程师之所以不去做任务分诊、项目管理这类 PM 工作，很大程度上只是因为他们必须把时间花在写代码上。可现在写代码已经容易多了，你完全可以让像 Codex 这样的 agent 去分析反馈、做优先级排序，这样一来，每个人都会多出更多时间。
所以我觉得，现在大家某种程度上都能做彼此的一部分工作。Scott Belsky 不是有个说法叫“人才栈坍缩”吗？我很喜欢这个说法，我觉得它确实正在发生。
我一直有一个很强的看法，就是做任何事情时，房间里需要的人越少，事情通常就做得越好，决策也越纯粹。
那接下来的问题就是，既然如此，PM 还剩下什么？我觉得，很多 PM 其实应该转型。比如说，如果你是个 PM，但你骨子里一直更想当工程师，只是以前也许你很擅长协调人，但工程能力还不够强，那现在也许你就该直接去做工程经理。因为有 coding agent 在，这件事完全可以成立，而且对你来说，这可能反而是一个更干净、更自然的角色。
同样的逻辑也适用于另外一种 PM，也许他其实更想做设计，那现在也许就该更靠近设计、更靠近构建。但说到底，我觉得最关键的还是兴趣。兴趣和主动性，可能是 AGI 时代对人来说最根本、最重要的两种品质。
所以我最后其实会把问题想得很简单。如果你骨子里就是更喜欢写代码，只是因为“总得有人做 PM”你才做了 PM，那现在你就应该把原来的自己删掉，直接变成工程师，用工程师的方式做同样的事。设计也一样。
但如果你真正最感兴趣的，是大量和用户待在一起，哪怕这会让你离构建稍微远一点，或者你特别喜欢去提前观察市场、看未来会往哪走，那在一个足够大的团队里，如果工程师已经够多了，我觉得 PM 这个角色依然可能有空间。不过归根结底，还是要看你到底最想做什么。
再补一句，我仍然认为每个问题域都需要一个真正对它负责的人类，但我不再认为那个人一定非得是 PM。
Peter Yang：我在自己团队里也有同样感受。我觉得最好的工程师，从来不会跑来问我“Peter，我们下一步做什么”，他们会自己去和用户聊天，自己搞清楚该做什么，然后再回来跟我讨论。感觉现在很多团队都在往这个方向走，大家其实都在同一页上。Codex 团队应该也很像这样吧？
嘉宾（Romain&Alex）：今天大家在 Codex app 里用到的很多功能，应该都是工程师自己从下往上提出来的，因为他们自己就想要这个功能。确实有很多是这样来的。不过我也想说，我非常喜欢合作的一种工程师画像，是那种特别喜欢和用户待在一起、喜欢思考该做什么的人。
但与此同时，也有另外一种同样极其强的工程师画像，他们快得惊人，搭系统特别强，思考也特别透彻，但对和用户聊天这件事完全没兴趣。我觉得这种人当然也同样有很大空间。
这也正是我对 AI 世界的一个基本看法。我们每个人都可以变得更“彻底做自己”。你明白我的意思吗？就是，你就做你自己。AI 和你身边的团队，会把那些你不想做的部分补上。
Peter Yang：这个说法真好。不过我还是觉得，“builder”这个标签非常重要。因为我感觉每个 PM 都被默认期待去当 leader，而传统职业阶梯的逻辑就是，你最后要变成 VP 之类的人，然后你就再也没有时间亲手做东西了。你每天都在参加产品评审，一整天只是给一点这个反馈、给一点那个反馈。我觉得很多 PM 其实并不想变成那样。至少我自己不想。我更想在产品真的发布的时候，依然离用户很近。
嘉宾（Alex）：完全同意。说实话，我其实从来不把 PM 看成一个领导岗位。我更愿意把它理解成一个“填补空白”的岗位。有时候这个角色确实会需要一些领导力，但即便如此，那种领导力更多也只是帮助大家对齐，而不是说你是那个天才战略家，提出了唯一正确的方向。
不过有一件事我可以很确定地说，OpenAI 最好的 PM 都非常非常深入一线。也正因为如此，如果你是以一个资深领导岗位的身份加入 OpenAI，其实会很有挑战，因为这里依然非常需要你深入细节。
所以你得同时找到一种方式，一边承担高层职责，一边还能真的下沉到一线。我个人会觉得，在这里最好的加入方式，永远还是直接下到一线。
Codex 团队招人时到底看什么？看的不是你的简历
Peter Yang：最后最后一个问题。你们终于又招了一个 PM，那你们在招 Codex 团队成员的时候，除了要求他本身就是 Codex 的重度用户之外，还会看重哪些特质？你们到底在找什么样的人？
嘉宾（Alex）：这个问题我们俩都可以答。我先说吧。其实我前面已经讲过一次了，我还是会回到那个词上：主动性。
说到底，“会主动做事的人”就是最重要的，放在 OpenAI 是这样，放在 Codex 团队尤其如此。我们是有意不把团队做成那种你一加入，就有人跟你说：“来，这是 12 个任务，难度逐级递增，你按顺序做吧”的地方。在这里更像是，你来了。好，欢迎加入。就这样，结束了。接下来就看你自己了。
所以我特别看重那种会自我启动、会主动做事、有能量、脑子里有想法，知道哪些事情值得推进的人。还有一种特质也很重要，就是他们不会因为现有想法已经存在，就不敢提出不同意见。因为说实话，我们现在很多已有决策，可能本来就是在某些偶然情况下做出来的，它们大概率本来也未必是对的。
再往理想化一点说，如果一个人能够主动吸收那些额外出现的职责范围，能够愿意去接那些本来还不明确、还没定义清楚的责任，我会觉得这几乎就是完美队友了。
所以这大概是我认为最核心、最上层的一些标准。如果你只是问，什么角色在这里最合适，那我的回答基本还是，任何偏技术的角色，尤其工程方向。
嘉宾（Romain）：我同意。对我这边，也就是 developer experience 这块来说，我通常在找的也是高主动性的人，当然还得非常技术化，最好本身就很会用像 Codex 这样的工具。
但除此之外，我还特别看重一种热情，就是你是不是发自内心地愿意花时间和开发者、和 builder 待在一起，并且愿意分享自己的知识和经验。
比如这周我们刚刚宣布，Thomas 要在这个月加入我的团队。他就是那个做了开源 Codex Monitor 的人。这件事让我很高兴，因为他是那种非常有创造力、非常高产、也特别会用 Codex 的人，但同时他也很喜欢分享自己到底是怎么用 Codex 构建东西的。
而我们真正想做的，其实是把数百万开发者一起带进 Codex 所代表的这个新未来。我觉得，agentic coding 正在彻底改变我们过去一直以来对软件、应用和产品构建方式的理解。
这里面有太多潜力，可以向全世界展示一件事：任何人都可以构建任何东西，而且我们可以一路教他们怎么做到。所以，这大概就是我在找的人。
嘉宾（Alex）：你看看我理解得对不对。在我脑子里，DevX 这个岗位的定义差不多就是：一个非常强的工程师，同时还特别会玩 Twitter。
嘉宾（Romain）：你说对了一半，另一半我得加个星号。这里所谓“会玩 Twitter”，更准确地说，其实是“擅长和我们的社区沟通”。
因为你如果去世界上一些地方，就会发现很多开发者根本没那么常用 Twitter。比如在欧洲，还有一些其他地区，大家更多用 LinkedIn，或者别的平台。所以我们得稍微补充一句，这里真正重要的是，你得在全球范围内都能把社交沟通这件事做好。
所以可以概括成：一定得擅长社交媒体。这点肯定是重要的。我自己也真的很喜欢花时间去教学、去做教育性的事情。
Peter Yang：而且我感觉，一个人有没有主动性，其实在正式面试之前就已经能看出来了，对吧？比如他有没有一直在网上发布东西，有没有 side project。
嘉宾（Alex）：完全是这样。所以如果有人私信我，说有兴趣一起合作，我第一反应其实是：里面有没有链接？只要有链接，我基本都会点。
当然，我可能会先看一眼这链接是不是很离谱，但说实话，我几乎都会点。我就是会很好奇。然后如果他在消息里顺手附了一段自己的想法，我通常也都会认真看。
至于接下来这句话听起来会不会有点刻薄，我也不确定，但如果对方发来的是一大段“为什么我对这个岗位感兴趣”的说明，再附上一份简历，那这种内容我反而比起“他的想法”和“他做过什么”要少看得多。我真正更想看的，是你想了什么，你做了什么。
而且前几天还有人问我这个问题，我那时候才突然意识到，我根本不知道很多人是从哪所大学毕业的。
Peter Yang：谁在乎啊，真的。谁在乎这些。我其实很高兴我们活在这样一个时代，很多过去那种很蠢的 credential 已经没那么重要了。谁在乎名校，谁在乎学历。你直接给我看你做了什么就行。
原文链接：
https://www.youtube.com/watch?v=9qXc-THAvc0
