OpenAI最强产品负责人：AGI限制在于人，不在LLM！Codex已能待命自我训练，曝内部压缩机制，18天3人上线安卓Sora

从 0 到上线，在OpenAI内部，安卓版 Sora经历的时间只有 28 天，而且期间只用了 2-3 名员工。

更震惊的是，即便是OpenAI内部的人都没想到，很快这款App就冲到应用商店榜首。

两天前，OpenAI 中被首席产品官Kevin Weil盛赞“简直是最强”的产品负责人，也是OpenAI 目前最受欢迎、最强大的编程智能体背后的人：Codex产品负责人 Alexander Embiricos 受邀接受了播客采访。

播客来源：Lenny's Podcast

在这期最新的采访中，Alexander 分享了很多有价值的模型、智能体的洞察结果与判断。

他认为，在智能体领域，如果要赢，就必须要走向“主动性”，即让模型真正的去做事。而过去一年里，一个重要的经验是：模型在“做事”时，如果能够使用计算机，效果会好得多。而事实证明，让模型使用计算机的最佳方式，就是让它写代码。

于是我们逐渐形成了这样一种想法：如果你想构建任何智能体，也许你应该从“编程智能体”开始。

另外，对于AGI的时间线，他也给出了非常独特的答案。

他认为“加速曲线”之所以还没有出现，瓶颈已经不在大模型的能力，而在于人类的速度。

当前的限制因素有很多，但一个常被低估的瓶颈，其实是人类本身的输入速度——打字速度、多任务切换速度，以及写提示词的速度。

一个最明显的例子就是，当代码生成的速度被指数级拉高，新的问题迅速浮现——谁来审？谁来验？谁来为线上结果负责？

如果智能体不能自己验证结果，那瓶颈就变成了：你有没有时间去审所有代码。

Codex 可以说是除了ChatGPT之外，OpenAI最为引以为傲的产品。作为负责人，Alexander 还提到了内部的构建思考。

虽然表面上是聊 Codex，但其实指向了更大的话题：当构建变得极其廉价，什么才是软件工程和产品真正的价值？

Alexander 表示：Codex 的真实定位，并不是“自动写代码的机器”，而更像一个能力极强、但仍需要被授权和校验的工程队友，工程重心早已从编码迁移到了评审。

因此，作为产品团队，“我们能做的，就是不断问自己：我们是不是在打造一款真正‘最大化加速人类’的工具，而不是一款让人类更困惑、不知道自己该做什么的工具。”

为此，OpenAI 内部发明了一种“压缩”的机制方法来应对长时程负责任务的情况。同时认为，智能体应该在直接在shell中干活。

他还自曝表示，几乎所有产品开发，本身是一个“吃自家狗粮”的Dogfooding的过程。并指出，产品迭代过程时会避免因重度用户绑架而造成过度优化，更关注新用户体验和Day7留存指标。

此外，他也参与了OpenAI的首款AI浏览器Atlas，并表示对于它的定位是“有上下文的桌面超级助手”。

提及智能体的未来，他对于“混合主动体验”十分推崇。

访谈时长80多分钟，干货非常足，逻辑性很强。这里先简单列一些：

• 在 OpenAI 做产品究竟是什么体验；

• Codex 如何帮助 Sora 团队快速交付 Sora 应用，并在不到一个月内登顶 App Store；

• Codex 当前 20 倍的增长，以及他们是如何把编程能力做到这么强的；

• 为什么团队现在开始把重心放在“更好地审代码”，而不仅仅是“写代码”；

• AGI 时间线的判断；

• AI 智能体什么时候才会真正变得有用。

• 以下是整理的全文内容，希望能帮助到大家吸收。

OpenAI 的速度与野心：先开火，再瞄准

主持人：

我想先从你在 OpenAI 的经历聊起。你大概是一年前加入 OpenAI 的。在那之前，你做了大约 5 年自己的创业公司，再之前，你在 Dropbox 做产品经理。我可以想象，OpenAI 和你过去待过的任何地方都很不一样。

我直接问一个问题吧：OpenAI 在运作方式上，最不同的地方是什么？有没有什么是你在这里学到的、未来无论走到哪里都会带走的东西——假设你哪天真的会离开的话。

Alexander Embiricos：

到目前为止，最突出的感受就是——OpenAI 的速度和野心，都远远超出我以往的任何想象。

说实话，这样讲有点“尴尬”，因为几乎每个创业者都会觉得：“我们公司动作很快、人才标准很高、目标也很宏大。”但我必须说，在 OpenAI 工作，真的让我重新理解了“快”和“有野心”到底意味着什么。

主持人：

我们经常听到这种说法：几乎所有 AI 公司都在说，“天哪，那家公司怎么能跑这么快。”有没有某个具体例子，让你觉得“这件事在别的地方不可能这么快发生”？

Alexander Embiricos：

最直观的例子，就是 Codex 本身的爆发式增长。

我们已经有一段时间没对外更新具体数据了，但可以说，Codex 的规模在短短几个月内就实现了 10 倍增长，而且之后还在持续放大。

经历过这种速度之后，至少对我个人来说，未来只要我还在做技术产品，就会下意识地用这种“速度和规模”作为基本门槛来要求自己。

回头看我之前的创业公司，节奏真的慢太多了。创业时，你总是在权衡：到底要在一个想法上投入多久，还是尽快发现不行就转向。但在 OpenAI，我意识到一件事——我们能够、也必须产生的影响力是如此之大，以至于我不得不对“时间怎么用”这件事变得极其残酷。

主持人：

在聊 Codex 之前，我想再追问一下：OpenAI 有没有在组织结构或运作方式上做了什么，让团队可以这么快？因为说实话，谁都想跑得快。

Alexander Embiricos：

其中一个原因是，我们所构建的这项技术，本身就彻底改变了很多事情——包括我们如何做产品，也包括我们能为用户开启什么样的可能性。

我们经常讨论基础模型本身的进展，但我个人其实觉得：哪怕从今天开始模型完全不再进步（当然现实不是这样），我们在产品层面仍然严重落后。还有太多产品可以做。

所以某种意义上，这是一个“时机已经成熟”的阶段。

但真正让我意外的，是组织方式上一些非常反直觉的地方。举个例子：在我创业时，或者在 Dropbox，当产品经理很重要的一件事，是“稳住船头”，确保方向正确，然后沿着这个方向加速前进。

但在 OpenAI，我们根本不知道接下来会出现什么能力，也不知道哪些在技术上能跑通，更不知道即便技术跑通了，用户会不会买账。在这种情况下，更重要的不是“笃定方向”，而是保持谦逊，用大量的实证方式快速学习、快速尝试。

组织本身就是为这种“自下而上”的探索方式设计的。

大家都爱说自己是 bottom-up，或者至少喜欢这么说，但 OpenAI 是真正意义上的 bottom-up。这对我来说是一次很大的学习，也让我意识到：如果未来有一天我不在 OpenAI 了，我可能会用完全不同的方式去做事。

说实话，我现在甚至很难想象再去一家“非 AI 公司”工作意味着什么。

主持人：

我听下来有点像是“先开火，再瞄准”，而不是“先瞄准，再开火”。我知道这个说法可能不太好听，但我确实在很多 AI 公司听过类似观点。因为你根本不知道用户会怎么用，所以没必要一开始就把东西做得特别完美，不如先丢出去，看真实使用，再围绕真正成立的场景全力投入。

Alexander Embiricos：

这个比喻在一定程度上是成立的，不过我会说，“瞄准”这件事变得更模糊了。

我们确实还是在“瞄准”，只是这个瞄准更像是：我们大致认为未来可能会出现哪些走向。我在这里学到很多的一位研究负责人常说，在 OpenAI，我们可以对一年甚至更久之后的事情进行很好的讨论，虽然充满不确定性，但这个时间尺度是对的。

我们也可以对接下来几个月、甚至几周会发生什么，有很清晰的判断。真正难的是中间那一段：快接近一年、但又没到一年，反而最难推理。

所以在更宏观的层面，比如我们要走向哪些未来、对齐（alignment）这类必须长期思考的问题，我们是在“模糊地瞄准”。但在更战术层面的事情上，比如具体做什么产品、用户会如何使用，我们更倾向于：用实验来回答问题。

主持人：

很多人听到你们说“自下而上、不断试错、没有一个几个月后的明确计划”，会忽略一个关键前提：你们招的是世界上最顶尖的人才。这听起来几乎是这种工作方式能成立的必要条件。

Alexander Embiricos：

完全是这样。我刚来的时候，对这里每个人的个人驱动力和自主性，感到非常震惊。

所以我并不认为 OpenAI 的运作方式，是你听一期播客、读一篇文章，就能直接复制到自己公司的东西。说得现实一点，绝大多数公司并不具备这样的整体人才密度。如果要借鉴，也一定需要做大量调整。

Codex的内部定位：真实队友

主持人：

那我们来聊聊 Codex。你负责 Codex 的产品进展，现在进展如何？有没有什么数据可以分享？另外，也不是所有人都清楚 Codex 到底是什么，你能不能介绍一下？

Alexander Embiricos：

当然。我算是一个非常幸运的人，能“生活在未来”，负责 Codex 的产品。

非常具体地说，Codex 是一个编程智能体。你可以把它理解为一个 VS Code 的 IDE 插件，或者一个可以安装在终端里的工具。安装之后，你就可以和 Codex 搭档协作：向它提问、让它写代码、跑测试、执行代码，完成软件开发生命周期中那一大段“厚重的中间地带”——也就是最终会进入生产环境的那部分工作。

更广义地说，我们认为 Codex 现在的形态，只是“软件工程队友”的起点。当我们用“队友”这个词时，设想的是：它不仅能写代码，还能参与更早期的构思和规划阶段；在后期，它也能参与验证、部署和维护。

如果说得更形象一点：今天的 Codex，有点像一个非常聪明的实习生，但它拒绝看 Slack，也不会主动去看 Datadog 或 Sentry，除非你明确让它去看。所以不管它多聪明，在你完全不参与的情况下，你其实也不太敢把代码全权交给它。

这也是为什么目前大多数人使用 Codex 的方式，还是“结对编程”。

但我们的目标是，让它更像一个真正的新同事。你招一个实习生，不只是让他写代码，你会让他参与整个流程。即便一开始做得不对，他也能通过不断迭代慢慢接近正确答案。

主持人：

你刚才那个“不看 Slack 和 Datadog”的比喻，我一开始还觉得挺好——它完全不分心，始终处在心流里。但我明白你的意思了：它并不掌握所有上下文。其实优秀的人类队友也是这样，你不会一开始就事无巨细地告诉他们怎么做。最开始你会摸索：哪些沟通方式有效，哪些无效；给一些启动任务，慢慢授权。最终，你可以直接对他说：“这块你负责就好。”

Alexander Embiricos：

对，正是这个方向。

Alexander Embiricos：

很好。比如你可以这样跟它说：“你现在主要和这几位同事一起，负责代码库的这一块。当然，如果你觉得有必要，也可以去看看代码库的其他部分。”然后你再补一句：“你自己判断，哪些事情现在做最合适。”

这正是我们所说的“主动性”。也是 Codex 的一个核心目标：走向主动。

我认为这点对 OpenAI 的使命至关重要——也就是把 AI 的价值真正交付给全人类。

我现在常开玩笑说一句话，当然只是一半玩笑：今天的 AI 产品其实都很难用。因为你必须非常清楚什么时候它能帮到你；如果你没有主动去 prompt 它，那它基本就帮不上你。

你想想看，现在一个普通用户每天主动调用 AI 的次数，大概也就是几十次。但如果你真的有一个高度智能的实体，它每天能帮到你的次数，可能是成千上万次。

所以，Codex 的一个重要目标，就是去搞清楚：一个“默认就有帮助”的真实队友型智能体，应该长什么样。

主持人：

当人们想到 Cursor，或者 Claude Code 时，更多会把它们理解为：一个能帮你写代码的 IDE，能自动补全，也做一点智能体式的工作。但我听你描述的愿景，好像不太一样——你说的是一个“队友”，一个远程的工程师式存在，帮你写代码、执行任务，你通过对话来协作，同时它也具备 IDE 自动补全这些能力。

这是你们理解中的差异点吗？

Alexander Embiricos：

核心想法是：当你作为开发者想把一件事做成时，我们希望你有一种“自己开了外挂”的感觉，整体效率被大幅放大。

但我们并不认为，要获得这种提升，你必须时刻停下来想：“我现在该怎么调用 AI？”

我们希望它能自然嵌入你原本的工作方式里，在你几乎不需要刻意思考的情况下，就开始替你做事。

主持人：

我接下来有很多问题想围绕这个展开。但在那之前，先问个简单的：现在进展怎么样？

近20倍增长，Codex 是怎样爆发的？

先“吃自己的狗粮”

主持人：

有没有什么数据可以分享？Codex 最近的表现如何？

Alexander Embiricos：

可以说，Codex 的增长非常、非常夸张。

从去年 8 月 GPT-5 发布之后，Codex 的增长就开始全面加速。

如果你感兴趣，我们其实可以聊不少“产品层面的洞察”，比如这些增长是怎么被释放出来的。上一次我们对外披露的数据是：相比 8 月，Codex 的规模已经超过 10 倍。而现在，实际上已经接近 20 倍。

另外，Codex 模型现在每周要处理数万亿级别的 token，已经是我们服务量最高的编程模型了。

有一件事我自己觉得特别酷：Codex 团队一开始的搭建方式，就是把产品团队和研究团队高度绑定在一起，同时迭代模型和运行环境（harness）。结果就是，你可以尝试更多东西，做更多实验，看看模型和产品到底该如何配合。

最早，我们只是在为自家的第一方产品环境训练 Codex 模型，而且这个环境本身带着很强的产品判断。但最近我们开始看到：越来越多大型 API 编程客户，也开始采用这些模型。现在，Codex 模型已经成了 API 里调用量最高的编程模型。

主持人：

你刚才埋了个钩子，说“是什么解锁了这波增长”。我非常想听这个。

在 Codex 出来之前，说实话，感觉 Claude Code 简直是碾压级的存在，大家几乎都在用它。然后 Codex 突然出现了。我记得 Karpathy 发过一条推文，说他从没见过这样的模型——他遇到的那些最棘手的 bug，自己能卡上好几个小时，别的工具都解决不了，交给 Codex 跑一个小时，问题就解了。

你们到底做了什么？

Alexander Embiricos：

在 OpenAI，我们有一个非常明确的使命：构建 AGI。

因此我们在思考产品时，会不断问一个问题：它能不能规模化？

我前面提过，如果你是工程师，AI 每天应该帮你上千次。于是，在推出第一版 Codex 产品（也就是 Codex Cloud）时，我们围绕这个问题设计了一些基础能力。那是一个运行在云端、拥有自己“电脑”的产品，你可以把任务直接委托给它。它最酷的一点，是可以并行跑大量任务。

但我们也发现了一些问题：这个模式在初期其实不太好上手。无论是环境配置、给模型配齐验证工具，还是学习如何正确地 prompt，它的门槛都不低。

我常用的比喻是：你雇了一个队友，但你永远不能跟他开会，只能异步来回沟通。这种方式对某些人是可以的，长期来看甚至是理想状态，但一开始真的很难适应。

所以我们的长期愿景依然是：你可以把事情交给它，它会主动推进。但真正的关键解锁点在于——先要以一种极其直观、几乎零门槛的方式，让用户快速获得价值。

现在，大多数用户认识 Codex 的方式，是下载 IDE 插件，或者在 CLI 里运行它。它直接在你的电脑上和你交互式地工作，而且运行在一个安全的 sandbox 里，这让很多事情变得很简单：它能访问依赖、运行命令，如果有命令在 sandbox 里跑不了，它会直接问你。

这会形成一个非常强的反馈闭环。随着你不断使用，产品会“顺带着”被配置得越来越完善，最终你就能在后续把任务真正委托给它。

还是用那个队友的类比：你刚招一个人，给他一台全新的电脑，他什么都干不了。但如果你和他并肩工作一段时间，告诉他：“这个服务的账号在这儿，这个命令可以随便跑”，很快他就能独立工作好几个小时。

主持人：

听起来，最初版本的 Codex 有点“太未来了”——一个云端、异步、远程帮你写代码的智能体。而你们后来选择退一步，回到工程师最熟悉的 IDE 和本地环境里，帮他们逐步进入这个新世界。

Alexander Embiricos：

完全是这样。这其实也挺有意思的，因为 OpenAI 内部非常大量地“吃自己的狗粮”，也就是深度使用自家产品。Codex 在过去一年里，持续加速着 OpenAI 本身，云端版本对公司内部也确实是一个巨大的加速器。

但有些时候，内部使用的信号，和外部市场给你的信号是不一样的。因为在 OpenAI，我们每天都在训练推理模型，非常习惯那种复杂 prompt、并行跑任务、隔一段时间再回来看结果的工作方式。

所以现在我们在继续高度重视内部 dogfooding 的同时，也会非常刻意地区分不同用户群体的使用习惯。

主持人：

这听起来有点像：活在未来，但不能活得太远。我完全可以想象，在 OpenAI 里，大家的“未来感”都拉得很远，但那并不一定适合所有人。

Alexander Embiricos：

对。

一个真正的智能体该有的三层架构

主持人：

那在“智能本身”上呢？训练数据、方法这些，有没有什么关键因素推动了 Codex 编程能力的飞跃？是更好的数据？还是纯粹模型进步？还是别的什么？

Alexander Embiricos：

这里面有几个因素。

首先，模型本身确实进步巨大。就在上周三，我们发布了GPT-5.11 Codex Max ——名字虽然非常“实至名归”，但模型真的很强。

在同样的任务上，它相比之前的 GPT-5.1 Codex，大概能快 30% 完成任务，而且解锁了更多智能。如果你把推理级别调高，它会明显更聪明。

你提到 Karpathy 那条推文，说“把最棘手的 bug 交给它”，在现在这个阶段，Codex Max 确实在承担这种角色：解决最难的 bug。

但我们的思路也在发生变化——不再只是“训练一个最强的模型”，而是去思考：一个真正的智能体整体应该长什么样。

我们不严格定义“智能体”，但在我们的理解里，它是一个完整的技术栈：

最底层，是一个非常擅长特定任务的强推理模型；其上，是通过 API 把模型接入到一个运行环境（harness）里；

而这两层，对最终效果同样重要。

举个例子，我们非常自豪的一点是：你可以让 GPT-5.1 Codex Max 连续工作非常长的时间。现在已经很常听到用户说：“它跑了一整夜”或者“连续跑了 24 小时”。

这对模型来说并不常见，因为它一定会超过上下文窗口。为了解决这个问题，我们引入了一个叫Compaction（压缩） 的机制，而这其实涉及整个技术栈的协同。

模型本身需要理解“压缩”这个概念：当它接近上下文上限时，要知道自己即将进入一个新的上下文窗口，并提前为此做好准备。

在 API 层，你需要一个真正理解这个概念的 API，并且提供对应的接口，让你可以触发这种切换。

在 harness（执行框架）层，你还需要一个机制，能够提前准备好 payload，来完成这次切换。

所以我们把这个 compaction 特性真正交付出去，让所有使用 Codex 的人都能用上，其实是同时在改三层东西。我觉得这种情况以后会越来越常见。

直接在终端里干活

Alexander Embiricos：

另一个经常被低估的点是：如果你看看市面上所有不同的编程产品，它们的工具封装（tool harness）差异非常大，每一套对“模型应该怎么工作”都有完全不同的主张。

如果你想把一个模型训练到“在所有这些不同方式下都表现得很好”，其实是非常难的。

比如，有的人强烈认为模型就该用语义搜索；有的人认为它应该调用定制工具；而我们这边的强烈主张是：它就该直接用 shell，在终端里干活。

如果你只针对其中一种世界去优化，速度会快得多。Codex 的设计就是：只用 shell。

但为了让这件事安全、可控，我们给模型提供了一个它已经非常熟悉的 sandbox。

所以回到你刚才的问题，我认为最大的加速器之一，就是我们在同时并行构建这三层系统，并且不断对每一层做调优，让产品团队和研究团队高度一体化、快速实验。

主持人：

你怎么看“在 AI 和编程代理这个赛道里，怎么才能赢”？这会不会永远是一场模型之间你追我赶、不断被反超的竞赛？

有没有可能出现一个“赢家通吃”，其他人再也追不上的局面？有没有一条明确的“我们就是能赢”的路径？

Alexander Embiricos：

这又回到了“我们在构建的是一个队友，而不是一个工具”的问题。

不是那种只参与规划、排优先级的队友；不是只负责测试代码、帮你维护和部署的队友；而是像真实的工程同事一样，他还能帮你发日历邀请、改 standup 时间、处理各种杂事。

如果我们假设：每天、每周，研究实验室都会丢出来一些“疯狂的新能力”，那作为人类，你根本不可能跟上，更不可能把这些技术都用好。

所以我觉得，我们必须走向这样一个世界：你拥有一个 AI 队友，或者一个“超级助手”，你只需要和它对话，它就能主动地、自然地提供帮助。你不需要天天去看“最新的使用技巧”，你只要把它接进来，它就会开始工作。

这就是我心里我们正在构建的产品形态。如果能做到这一点，它会非常“粘”，也会是一个真正能赢的产品。

在我脑海里的形态是这样的：

很多人会问，“Chat 是不是 AI 的最佳界面？”

我其实觉得，Chat 在你还不知道自己该用 AI 干嘛的时候，是一个非常好的界面。

就像我在 Slack 或 Teams 里和同事聊天一样，我可以随时提任何需求，它是所有需求的“最大公约数”。

所以，你可以用聊天的方式和超级助手讨论任何事情，不管是不是编程。

而当你在某个领域是功能型专家，比如写代码，你再拉起一个 GUI，深入到代码里去操作。

所以我认为，OpenAI 要构建的，本质上是这样一套体系：

ChatGPT 是一个对所有人随处可用的工具，你在工作之外也会用它，慢慢习惯“被 AI 加速”。

等你回到工作场景，你会很自然地说：“我就直接问它吧。”

你不需要了解所有 connector，也不需要知道所有功能。你只管求助，它会在当下，用它能做到的最好方式来帮你，甚至在你没开口的时候，主动插话帮你一把。如果能走到这一步，我觉得，这就是我们真正赢下来的方式。

Codex是企业版的ChatGPT？否

主持人：

这很有意思。我之前和 Nick Turley（ChatGPT 负责人）聊天时，他提到过，ChatGPT 的最初名字其实就是 “Super Assistant” 之类的。

现在一边是这个“超级助手”的路线，一边是 Codex 的路线。听起来很像是一个偏 B2C，一个偏 B2B。我理解的是：你们从“写代码”开始，然后慢慢扩展到帮你安排会议、发 Slack、交付设计稿……

这是一个“企业版 ChatGPT”吗？还是说，你心里其实是另一种结构？

Alexander Embiricos：

这就进入“一年时间尺度”的话题了。

很多事情可能更快发生，但在不确定性上，我觉得是一年左右。我先说一个我认为“合理”的路径，至于最终怎么发生，没人知道。

如果我们要做一个超级助手，它必须真的“能做事”。也就是说，这个模型要能对你的真实世界产生影响。

过去一年里，一个很重要的认知是：模型在“做事”这件事上，当它能使用计算机时，效果会好很多。那问题就来了：超级助手要怎么用计算机？

你可以试图 hack 操作系统，用无障碍 API；你也可以让它点来点去，但那又慢又不稳定；

结果发现，对模型来说，使用计算机的最好方式，其实就是写代码。

于是我们慢慢走向一个结论：

如果你想做任何 agent，可能你就该从“编程 agent”做起。

对非技术用户来说，他们甚至不会意识到自己在用一个 coding agent。就像没人会去想“我现在是不是在用互联网”，大家只关心：Wi-Fi 有没有连上。

所以 Codex 的定位是：一个软件工程队友。而作为这个队友的一部分能力，它通过写代码来使用计算机。

现在已经开始出现一些“拉力”：虽然还很早，但已经有人用 Codex 来做“写代码之外、但又和代码相邻的事情”。

我认为接下来会很自然地发展成：只要一个问题能用代码解决，那 agent 就该写代码。哪怕你在做的是财务分析，也可能先写一段代码。

所以你刚才问，这是不是 ChatGPT 的另一端？在我看来，写代码是任何 agent 的核心能力之一，包括 ChatGPT。

Codex 做的，是把这项能力打磨到极致。

而这里最酷的一点是：代码是可组合、可复用、可互操作的。如果我们走一条“给 agent 一台电脑，让它到处点”的路线，那未来会发生什么，其实很难规划。

真正难的问题不在于“agent 能不能做”，而在于：

它怎么理解自己所处的上下文？怎么理解团队的工作方式、规范、边界和确定性要求？

比如，同样是分析 crash report，不同子团队可能有完全不同的分析偏好和提示词。于是我们就会走向这样一种状态：agent 坐在电脑前，但它必须是可配置的、可适配团队的。

那些 agent 经常要做、而且已经做得很好的事情，我们应该把它们直接内化成 agent 的能力，而不是每次重写脚本。

甚至，当我加入一个新团队时，我可以直接复用这个团队里 agent 之前写好的所有脚本。

如果把 agent 当成队友，这个隐喻是完全说得通的：它可以共享在公司里和其他人协作时学到的东西。

Agent很糊怎么破？

每个Agent都应该学会写代码

主持人：

听你这么说，你好像更接近 Karpathy 的观点：现在的 agent 还不太行，有点“糊”，但未来会很强。你认同吗？

Alexander Embiricos：

我觉得编程 agent 已经相当强了，价值非常实在。而非编程领域的 agent，确实还很早。

这是我个人的看法：

一旦这些 agent 也能以“写代码、可组合”的方式工作，它们会好得非常快。这也是“为软件工程师做产品”最有意思的地方。

我之前创业时也是面向工程师，他们是一群非常有趣的用户。因为他们会为自己构建工具，而且在使用技术的方式上，往往比产品团队还更有创造力。

你只要观察他们，就能看到大量涌现出来的用法，这些都会反过来告诉你：哪些能力应该直接做进产品里。

主持人：

我很喜欢你这个视角。很多做工程师产品的人，其实会被工程师“永远在吐槽”搞到很烦。“这也不行，那也不对，为什么要这么做？”

你反而享受这个过程。可能正是因为你们真的在做一个能解决问题、能替工程师写代码的工具。

主持人：

顺着这个说，其实大家一直在讨论：工作会怎样变化？工程师会不会被取代？还要不要学编程？

但你描述的更像是一个队友，一个让人变得更“超人”的存在。你怎么看这样一个超级智能工程队友，会给工程领域带来什么影响？

Alexander Embiricos：

我觉得这里有两个层面。刚才我们聊到的一个核心想法是：也许每一个 agent 最终都应该会写代码，甚至本身就是一个 coding agent。

在我看来，这只是更大趋势的一小部分——代码会变得更加无处不在。即便在“真正的 AI”之前，代码其实已经很普遍了；而当代码变得更普遍，它就会被用于更多目的。

Alexander Embiricos：

这意味着，对具备这种能力的人类的需求只会更多，而不是更少。

这是一个非常复杂的话题，我们内部也经常讨论，最后只能看它如何演进。但作为产品团队，我们能做的，是不断问自己：我们是在最大程度上加速人，还是在让“人该做什么”变得更模糊？

举个例子，现在用 coding agent 时，它会写大量代码，但写代码恰恰是很多工程师最享受的部分；结果人反而要去做代码审查，而那通常是更不有趣的工作。

所以我们在无数微小的决策里反复思考：怎么让这个过程更有趣？怎么让人感觉更有掌控感？比如，代码审查就是一个目前体验不太好的地方，那我们能不能通过产品能力来帮你建立对 agent 代码的信心？或者让 agent 更好地自我验证？

甚至细到界面层面：当 agent 完成一项工作，你第一眼该看到什么？是 diff，还是它生成结果的可视化预览？如果目标是赋能人，那显然应该先看到结果，而不是直接陷入代码细节，让他们感觉到自己真的被加速了。

未来设想

Tiktok式聊天驱动开发：左滑否，右滑可

主持人：

我之前和 Cursor 的 CEO Michael 聊天时，他提到一个“超越代码本身”的愿景。最近也有人在谈 spec-driven development：你只写规格说明，代码由 AI 来完成，人类开始在更高的抽象层工作。

你觉得未来会走向这种方向吗？工程师不再写代码、不再看代码，而是专注在更高层的抽象上？

Alexander Embiricos：

我觉得抽象层级一直在变化，而且今天已经在发生了。现在的 coding agent，大多还是“prompt 到 patch”；但我们已经看到有人在用 spec-driven 或 plan-driven 的方式。

实际上，当有人问我“怎么让 Codex 跑很长的任务”，我的常见建议就是：先一起写一个 plan，用 Markdown 描述清楚步骤，确认没问题后再让它执行。只要这个计划是可验证的，它就能稳定工作很久。

Spec-driven development 很有意思，但我不确定会不会成为主流，因为很多人其实也不喜欢写 spec。不过，很可能一部分人会采用这种方式。

有个半开玩笑的想法是：很多团队今天其实也没什么正式的 spec，但事情照样推进，因为团队足够自驱。某种程度上，这更像一种“chatter-driven development”——事情在社交媒体、团队沟通工具里不断发生，然后代码就被写出来、被部署了。

所以我个人反而更倾向于：有时候我想写 spec，有时候我不想。如果只是一个小 bug，我只想说“这是客服渠道的反馈，看看有没有什么值得注意的，小问题直接修掉就好”，而不是先写一份规格说明。

我有一个用来“挑衅”的未来假设：如果 agent 真得非常强，那一个独立开发者会怎么工作？

一个很糟糕但也很好玩的设想是：有个手机 App，agent 的每个想法都以竖屏视频的形式出现，你左滑否决，右滑通过；如果想了解更多，就长按说两句再决定。

在这个世界里，你的工作就是把这个 App 接入所有信号系统，然后坐在那里不断滑动。

主持人：

我太喜欢这个了，这简直是 Tinder + TikTok + Codex。所以 agent 在持续观察市场、用户和你本人，然后主动告诉你：该修这个 bug，该做那个功能？

Alexander Embiricos：

对，它用的是一种最低摩擦、最现代的沟通方式。

当然我们不会真的去做这个，但这个想法本身很有启发性。关键在于：agent 在持续消费外部信号。

如果回看最成功的 AI 产品之一，其实自动补全和 IDE 是非常典型的例子。顺便说一句，Codex 这个名字最早就是用在 GitHub Copilot 背后的模型上，我们后来重新启用了这个品牌。

IDE 里的自动补全之所以神奇，是因为它能非常快地给出建议：对的时候，你被明显加速；错的时候，也没那么烦。这就形成了一种“混合主动”的系统，它能根据你正在做的事，随时提供帮助。

这也是我们在 OpenAI 构建产品时很感兴趣的方向。比如我们推出 Atlas 浏览器后，就可以在你浏览网页、处理日常事务时，情境化地提示我们能帮你做什么。

真正的队友，处理的不只是代码，还有大量与 Web 内容相关的工作。

主持人：

这太有意思了——浏览器里的自动补全，随着你上网就不断提示能帮你的事情。我想回头聊 Atlas。

还有一个我刚知道的点：Codex 这个名字最早来自 code execution，这一下就说通了。

你刚才说的 chatter-driven development，也让我想到 Block 的 CTO 跟我聊过的 Goose：一个内部 agent，看你的屏幕、听你的会议，主动帮你写 PR、发邮件、起草 Slack。你描述的，正是一个早期版本的同一件事。

Alexander Embiricos：

那很有意思。我猜你们如果去问他们，现在最大的瓶颈是什么，多半是“确认这件事值不值得做、是不是做对了”。

我们在 Codex 里也看到了类似情况。比如 Slack 集成，大家很爱用，直接 @Codex 问：“你觉得这个 bug 为什么会发生？”甚至不一定是工程师，数据科学家也常用它来问：“这个指标为什么变了？”

但一旦涉及到写代码，最终还是要回头去验证、去审查。所以我觉得现在真正的瓶颈在于：验证代码是否正确、以及代码审查本身。

如果要走向那种更自动化的未来，我们必须让 coding agent 在工作后半段更自治、更可信。

写代码本身很有乐趣，我做了十年工程师，很清楚那种心流；但审别人代码、还要为线上事故负责，就没那么好玩了。

而现在构建变快了，新的瓶颈反而变成：到底该做什么，以及谁来审这堆代码。

OpenAI内部：压缩人才栈

主持人：

Codex 对你作为产品经理的工作方式产生了哪些影响？工程侧的变化很明显，代码可以直接帮你写。那它对你个人、以及 OpenAI 的 PM 们来说，改变了什么？

Alexander Embiricos：

整体感受只有一个：更有掌控感了。我一直算是技术取向比较强的 PM，尤其是在给工程师做产品时，“吃自家狗粮”几乎是必需的。但现在不只是理解产品，我是真正能把事情做得更多。

Scott Belsky 提过一个概念，大概叫“压缩人才栈”。意思是，很多角色之间原本清晰的边界，正在变得没那么必要了。因为每个人都能做更多事，而一旦你能少跨一道沟通边界，整个团队的效率就会明显提升。

具体到产品工作，很多事情都变得更快了：回答问题更容易，直接问 Codex；理解变化更轻松，让它帮你一起分析；原型往往比写规格文档还快。一个有点出乎意料的现象是：我们原本主要是用 Codex 写最终会进生产环境的代码，但现在，大家用它写了大量“一次性代码”。这又回到了“无处不在的编码”这个话题。

Alexander Embiricos：

继续说“一次性代码”和“无处不在的编码”这个概念。现在你会看到这样的场景：有人想做分析，想理解某个问题，就直接把一堆数据丢给 Codex，让它顺手做一个交互式的数据查看器。过去这件事太麻烦，不值得花时间，现在反而变得非常值得，直接让一个智能体去做就好。

设计团队这边也有很多很酷的例子。有位设计师想做一个动画，比如硬币动画，以前写这个动画本身就很劝退，现在他们直接用 Codex“随手写”了一个动画编辑器，再用这个编辑器把动画做出来，最后把结果提交进代码仓库。设计侧的加速非常明显。

这也呼应了“压缩人才栈”的趋势。我们的设计师本身就非常偏 PM，他们做大量产品层面的工作，甚至还有一个完全用 vibe coding 做出来的 Codex App 侧向原型。

现在很多讨论方式变成了：先快速 jam 一下，因为事情太多了；然后设计师不再反复讨论，而是直接把想法做成一个可玩的原型。大家一起试玩，觉得行，就把这个原型继续 vibe engineering 成一个正式的 PR。至于是否亲自合并，就看他们对代码库的熟悉程度了，Rust + Codex CLI 会更难一点，有时工程师会协助一起落地。

两三名工程师，18天搞定现象级应用：安卓版Sora

Alexander Embiricos：

最近我们上线了 Sora 的 Android 应用，这是我见过最震撼的加速案例之一。内部对 Codex 的使用本来就很高，而且这一年里，不只是覆盖面扩大到几乎所有技术人员，大家“如何把编码智能体用到极致”的强度和熟练度也大幅提升。

Sora Android 是一个全新的应用，从零到给员工内测只用了 18 天，再过 10 天就直接对公众 GA，总共 28 天。整个过程高度依赖 Codex，这个速度非常夸张。

有一点 Codex 特别擅长：如果一家公司已经在多平台上构建软件，底层 API 和系统已经理清，让 Codex 去做“移植”效率极高。这个团队就是让 Codex 去读 iOS 应用，产出工作计划，然后直接实现，同时对照 iOS 和 Android 两边。结果是两周员工可用，四周全面发布。更夸张的是，它后来直接成了 App Store 排名第一的应用，这真的很难不被震住。

主持人：

也就是说，用两三名工程师，几周时间，就做出了 App Store 第一的应用？

Alexander Embiricos：

是的，两到三个人。这真的有点荒谬。所以这是一个非常有代表性的加速案例。

另一个是 Atlas。Ben 在播客里聊过 Atlas 浏览器的引擎。浏览器本身是一个极其复杂的工程，我们为此搭了很多高难度系统。现在 Atlas 团队里有大量 Codex 的重度用户。

我和那里的工程师聊过：过去两到三名工程师需要两到三周的工作，现在变成了一名工程师一周。这种加速同样非常明显。更有意思的是，我们先发布了 Mac 版，现在在做 Windows 版，这也在反向推动 Codex 在 Windows 上变得更强。我们上周刚发布的模型，是第一个原生理解 PowerShell 的版本。

Alexander Embiricos：

现在整个公司几乎都在被 Codex 加速：研究侧，加快模型训练；设计侧；甚至市场和文档。我现在的产品市场同事，经常直接在 Slack 里改字符串、更新文档。

这些例子都说明，你们正处在“可能性的最前沿”，这也会成为其他公司未来的工作方式。28 天上线一个现象级应用，其中 18 天就跑起来核心版本，用两三个人完成，这已经重新定义了“交付”的含义。

程序员不会一夜之间不写代码

主持人：

你觉得这种能力，最终会扩展到非工程师吗？一定要工程师来做这些事吗？PM 或设计师有没有可能独立完成？

Alexander Embiricos：

我认为边界一定会继续模糊。你仍然需要一个真正理解自己在做什么的人，但“需要理解哪些细节”本身会发生变化。就像今天写 Swift，不需要再懂汇编。确实仍然需要懂汇编的专家，但那已经是高度专业化的角色，大多数公司并不需要。

我们会自然地看到抽象层不断增加，而现在我们正在进入“语言”这一层抽象——自然语言。而自然语言本身极其灵活：你可以用它讨论计划、规格，甚至只是产品或想法。人们会逐步向更高层的抽象移动。

但这个过程会是渐进的，不会一夜之间变成“没人写代码，只写规格”。更可能的路径是：先把编码智能体用在构建预览、跑测试；再让它执行构建、观察自己改动的结果；接着为它接入更完整的集成环境，比如加载真实页面来验证效果。

在相当长一段时间里，人类仍然会负责“策展”，决定智能体需要接哪些系统、具备哪些能力。再往后，才可能出现更大的解锁——比如 Codex 直接告诉你如何配置，甚至自己在仓库里完成初始化。

二次影响：对客户的理解至关重要

主持人：

真是个疯狂的时代。构建东西的速度快成这样，二阶影响会是什么？是不是意味着分发变得更重要？是不是意味着想法本身更值钱了？这种变化很耐人寻味，你怎么看？

Alexander Embiricos：

我依然不太认同“想法本身很值钱”这个说法。执行仍然很难。你可以很快把东西做出来，但要把它真正做好、做成一个整体自洽、对市场有意义的产品，依然不容易。

分发当然变得极其重要。整体感觉是，除了“把东西做出来”以外的所有事情，现在都更重要了：理解需求、走向市场、商业化等等。

我们可能刚走出一个有点奇怪的阶段。过去一段时间，做产品本身太难了，以至于只要你特别会做产品，好像就够了，哪怕你对某个具体客户并没有非常深入的理解。现在情况正在反过来。如果我只能选一个核心能力，那一定是对某一类客户问题的深刻理解。

所以，如果你今天要创业，手里有一群被现有 AI 工具严重忽视的客户，对他们的需求理解得非常透彻，那你已经站在很好的起跑线上了。反过来，如果你只是很会做网站，却没有明确的用户对象，路会难走得多。

主持人：

听起来你对垂直领域的 AI 创业公司非常看好。

Alexander Embiricos：

完全同意。通用型工具能解决很多问题，但真正有爆发力的，是那种把一个具体问题做到极致的产品。比如专注于“把演示文稿这件事做到最好”，比任何人都更懂这个场景，深度嵌入你的工作流，解决一整套围绕这个问题的真实摩擦。

关键指标：新用户体验、7日留存

不要被重度用户绑架

主持人：

说到 Codex 的进展评估，我猜你们有一整套内部评测，也有很多公开基准。但在你看来，什么信号能告诉你们：我们真的在持续进步？有没有几个关键指标？

Alexander Embiricos：

我经常提醒自己的一点是：Codex 这种工具，很容易被“重度用户视角”绑架。我们很容易把大量时间花在用户旅程后半段、非常深度的功能上，然后不知不觉为那部分过度优化。

所以我觉得一个非常关键的事情，是盯住 D7 留存，重新以“新用户”的身份去体验产品，从零注册、从头开始用。我自己甚至为了真正“吃自家狗粮”，用 Gmail 注册了好几个付费账号，每个月被扣两百美元，这些我还得去报销。

认真说，作为一个用户的直觉体验，以及早期留存数据，对我们依然极其重要。这个品类虽然在快速起飞，但人们真正把它融入日常工作的阶段，其实还很早。

Alexander Embiricos：

还有一件我们做得非常多的事，可能在这个领域算是最“用户反馈驱动、社交媒体驱动”的团队之一了。我们几个人几乎长期泡在 Reddit 和 Twitter 上。那里既有夸赞，也有大量吐槽，我们会非常认真地看这些吐槽。

因为编码智能体的使用场景太多了，它在某些特定行为上“坏掉”的方式也非常多。所以我们会频繁观察社交平台上的整体“氛围”，尤其是 Twitter 和 Reddit。Twitter 更偏热闹、偏 hype，Reddit 则更负面一些，但也更真实。

最近我越来越重视 Reddit 上大家是怎么讨论 Codex 的，这点其实挺重要的。

主持人：

你主要看哪些 subreddit？有 r/codex 吗？

Alexander Embiricos：

有的，算法本身也会推相关内容，但 r/codex 确实是一个重要来源。Twitter 上如果有人直接 @ 你，你也能看到，但那种一对一的反馈，信号强度不如 Reddit。

Reddit 有很好的点赞机制，至少目前看起来，可能大多数还不是机器人，所以你能比较清楚地看到哪些问题是大家真正关心的。基于这些信号，我们能得到很不错的方向判断。

说到这里，其实我想顺带聊一下 Atlas。

OpenAI 最初的AI浏览器定位

有上下文的桌面助手

主持人：

你们发布了 Atlas。我其实在推特上发过一条，说我试用了 Atlas，但我个人不太喜欢“纯 AI 搜索”的体验。有时候我就是想用 Google，不想等 AI 给我一个总结答案，而且当时还没法切换。我就发了条推，说我先换回去了。

后来我看到有人发推说“现在可以切换了”，我猜你们本来就打算这么做。这可能就是那种“先发，再看大家怎么用，再调整”的典型例子。

所以我有两个问题：第一，这件事你怎么看？第二，更根本的，你们为什么要自己做一个浏览器？

Alexander Embiricos：

我之前参与过一段时间 Atlas 的开发，现在已经不在那个项目里了。就从我自己的视角讲一下背景。

在加入 OpenAI 之前，我在做一个屏幕共享、结对编程的创业项目。后来我们并入 OpenAI，最初的愿景其实是做一个“有上下文的桌面助手”。我一直觉得，让用户不断把上下文喂给助手，再让它想办法帮你，是一件非常烦人的事。

如果助手能直接理解你正在做什么，它就能真正把效率拉满。从这个角度看，我现在仍然把 Codex 视为一种“有上下文的助手”，只是它是从编码任务切入的。

Alexander Embiricos：

就 Atlas 而言，至少对我个人来说，核心想法是：大量工作其实发生在 Web 上。如果我们拥有一个浏览器，就能以一种更一等公民的方式理解上下文。

我们不用像其他桌面软件那样进行“黑客攻击”，不用面对它们对可访问性树支持参差不齐的问题，也不用依赖截图这种慢又不稳定的方式。相反，我们可以直接在渲染引擎里，提取任何需要的信息来帮你。

我常用一个游戏的类比。很多游戏里，你走到一个物体前，按一个键，它就会“做对的事”。这就是“上下文动作”。要做到这一点，系统必须知道你正在尝试做什么，然后才能在恰当的时机出手。

混合主动体验：不要打断用户心流

Alexander Embiricos：

这一点非常关键。想象一个未来，AI 代理每天帮你做成千上万次事情。如果它每次帮你，都靠推送通知来告诉你，“我刚帮你做了这个，要不要？”，那一天你会收到上千条通知，完全不可接受。

更理想的状态是：比如我在看一个工程仪表盘，某个关键指标突然下滑。这个时候，AI 在不打断我的前提下，已经去看了问题，并在我正盯着这个指标时，顺手告诉我它的判断，甚至给出一个修复方案。这会极大地保持我的心流，也让代理能介入更多事情。

所以，从我的角度看，浏览器的意义在于：我们能获得更丰富的上下文，用户也能清楚地控制“哪些事情希望 AI 介入”。你想让它动手，就在 AI 浏览器里打开；不想，就用你原来的浏览器。边界非常清晰。

Alexander Embiricos：

在这种前提下，我们才能做“混合主动”的体验，在真正有帮助的时刻，把合适的上下文操作呈现给你，而不是随机打断你。

当你听到 Codex 被描述为一个“超级助手”时，它并不只是帮你写代码，而是作为一个队友，试图在工作中全面放大你的能力。

技术导向场景的使用势能最明显

主持人：

那顺着这个说，除了工程相关，还有没有一些非工程师在使用 Codex 的常见场景？我们刚才提到过设计师做原型、做构建。有没有什么更有意思、甚至有点出乎意料的用法，是来自非工程背景的人？

Alexander Embiricos：

确实有很多出乎意料的用法，但如果说“真正已经形成明显使用势能的地方”，目前还是偏向编码相关或技术导向的场景。

比如有比较成熟的技术生态，或者你在做数据分析之类的工作。这些地方现在跑得最快。

我个人是预期，随着时间推移，非工程用例会明显变多。但现阶段，我们还是刻意让团队高度聚焦在编码上，因为这里还有太多事情要做。

秘诀：把最难的问题丢给Codex！

主持人：

那对于正在考虑尝试 Codex 的人来说，它的能力边界大概在哪里？

它适用于所有类型的代码库吗？支持哪些语言？比如你在用 SAP 这种体系，把 Codex 接进来就能直接开始干活吗？有没有一个“甜蜜点”，或者说目前还不太适合的情况？

Alexander Embiricos：

我很高兴你问了这个问题。因为我一直觉得，体验 Codex 的最好方式，是把你最难的问题直接丢给它。

这点和一些其他编码代理不太一样。很多工具你会想先从简单的、随便玩玩的任务开始，看看顺不顺手。但我们做 Codex，就是希望它成为一个专业级工具，能接住你最硬的任务，在你庞大而且并不完美的代码库里写出高质量代码。

所以如果你要试 Codex，别用那种刻意“降级”的简单例子。一个很好的起点，是一个你卡住的复杂 bug，不知道根因在哪，让 Codex 帮你一起定位并实现修复。

主持人：

这个回答我很喜欢：直接把最难的问题给它。当然，如果你说“我现在最难的问题是打造一家新的独角兽公司”，那显然还不行，至少现在不行。

所以更现实的是：给它一个足够难、但仍然是一个明确问题或任务的事情，从这里开始测试，然后再逐步扩展。

那它支持哪些语言？

Alexander Embiricos：

我们训练 Codex 的方式，本质上是覆盖了一条“语言分布曲线”，基本和现实世界里各类语言的使用频率相匹配。

所以只要你不是在写那种非常冷门、或者完全私有的语言，Codex 在你的语言上一般都会表现得不错。

上手示例：并行试几件事

主持人：

如果一个人是第一次上手 Codex，你有没有一个小建议？如果只能在他第一次配置 Codex 时，悄悄说一句“秘诀”，让他更容易获得好的体验，你会说什么？

Alexander Embiricos：

我可能会说：并行试几件事。比如，一边给它一个难题；一边让它先理解代码库；再让它围绕你的某个想法，和你一起制定一个计划，然后一步步推进。

从更高层看，这其实是在和一个新队友建立信任。你不会一上来就对新同事说“给你零上下文，直接把这件事搞定”。你会先确认他理解系统，再对齐思路，然后让他逐步推进。用 Codex 也是一样，这样你会自然摸清该怎么“和它说话”。

多做真实事情、理解什么是好系统、站在前沿

主持人：

再问一个方向性的问题。随着 AI 承担越来越多的编码工作，很多人都会纠结：那我还要不要学写代码？为什么还值得在这上面投入时间？

对正在思考职业方向的人来说，尤其是软件工程、计算机科学背景的，你觉得有哪些能力正在变得更重要？又有哪些可能不用再那么焦虑？在 AI 越来越深度进入工作场景的情况下，大家到底应该往哪些技能上倾斜？

Alexander Embiricos：

这个问题可以从几个角度来看。最直观的一点是：成为一个“能把事情做出来的人”。

随着编码智能体越来越强，一个在校生或刚毕业的人，今天能做的事情已经远远超过过去。你应该主动利用这一点。我在看早期职业阶段候选人时，很看重他们使用最新工具的生产力。他们本来就应该非常高效。某种程度上，他们相对于资深工程师的劣势正在缩小，因为他们一开始就站在这些强大工具之上。

所以我的第一个建议是：学什么都可以，但一定要多做真实的事情，而不只是完成作业。

Alexander Embiricos：

另一面依然非常重要：理解什么样的软件系统才是“好系统”。

系统工程能力、以及与团队进行高效沟通和协作的能力，在很长一段时间内都会持续重要。AI 编码智能体并不会突然就能在没有人类帮助的情况下构建完美系统。这个过程会是渐进的。

在很多阶段，人仍然需要介入，去配置、引导和约束这些编码智能体，让它们真正高效运作。所以，打字快、记住具体算法的重要性在下降，但理解系统如何协同、一个软件工程团队为何能高效运转，这件事反而更关键。

Alexander Embiricos：

还有最后一个角度：如果你站在某个领域的知识前沿，这依然非常值得投入。

一方面，智能体在这些前沿问题上暂时还不擅长；另一方面，当你试图推动某个领域的边界时，会被迫大量使用编码智能体，加速自己的工作流，这本身就是一种优势。

智能体下一步：Agent随时待命自我训练

主持人：

你说的“站在前沿”，能举个具体例子吗？

Alexander Embiricos：

比如 Codex 本身，就写了大量用于管理训练任务和核心基础设施的代码。我们节奏很快，Codex 的代码审查已经捕捉到了不少错误，包括一些很有意思的配置问题。

我们甚至开始看到一些未来的影子：让 Codex 参与它自己训练过程的 on-call。这听起来有点疯狂，但确实在探索中。

主持人：

等一下，什么叫“对自己的训练 on-call”？是说训练过程中出问题，它会提醒人，还是自己修、自己重启？

Alexander Embiricos：

这是一个还在探索中的早期想法。基本思路是：训练过程中有大量指标和图表，现在都是人盯着看的。因为训练成本极高、节奏又快，这种“看护”非常重要。

训练底层涉及很多系统，任何一个环节出问题，都可能需要修复、暂停或调整。我们的设想是，让 Codex 循环分析这些指标变化，帮助我们更高效地完成训练。

主持人：

我太喜欢这个方向了。这几乎就是智能体的未来。Codex 不只是写代码，它能做的事情远不止于此。

Alexander Embiricos：

是的。

AGI时间线：

明年，小型AI公司会生产力爆棚

主持人：

最后一个问题。既然你在 OpenAI，我不得不问：我们离“人类级别的 AI”还有多远？你对 AGI 的时间线怎么看？

虽然这不是你直接负责的方向，但关于 AGI 的看法和预测实在太多了。你觉得我们离“像人一样的 AI”还有多远？不管你怎么定义这个概念。

Alexander Embiricos：

对我来说，关键在于什么时候能看到那条真正的“加速曲线”，也就是所谓的 hockey stick。当前的限制因素有很多，但一个常被低估的瓶颈，其实是人类本身的输入速度——打字速度、多任务切换速度，以及写提示词的速度。

你刚才提到，让智能体盯着你所有的工作是可以的，但如果智能体不能自己验证结果，那瓶颈就变成了：你有没有时间去审所有代码。我的看法是，我们需要打通这些生产力闭环，不再依赖人类不断提示、不断人工校验。如果我们能重构系统，让智能体在默认状态下就“有用”，hockey stick 才会真正出现。

Alexander Embiricos：

不过，这个过程不会是一刀切的，而是高度依赖具体场景。比如，明年一家初创公司在做全新的应用，完全有可能从一开始就搭建一个以高度自给自足的智能体为核心的技术栈。但如果你是在 SAP 这样的大公司，面对的是大量复杂、历史悠久的系统，就不可能一夜之间让智能体端到端接管，只能逐步替换或升级系统。

所以一个可能有点无聊、但更真实的答案是：从明年开始，早期采用者会率先看到生产力的指数级提升；接下来几年，越来越大的公司会陆续进入这个阶段；而当这种“hockey stick”效应反向流入 AI 实验室本身时，我们大概就站在 AGI 的门槛上了。

AGI的真实瓶颈：不在于模型能力，

而在于人类评审的速度

主持人：

我很喜欢这个回答，特别务实。这个话题在节目里反复出现：审查 AI 做出来的东西，本身已经成了巨大的瓶颈。

做出更高效的编码工具是一回事，帮你完成最后一步——判断“这到底好不好”——是另一回事。而你认为真正的限制在这里，这一点非常有意思。也呼应了你前面说的：即便 AI 不再进步，我们仅仅通过更好地使用它，也还有巨大潜力可以释放。

主持人：

这是一个很少听到的视角：真正的瓶颈不是模型能力，而是人类审核 AI 输出的速度。

筛选人才标准：

对智能体有热情的人

主持人：

好，我们继续。Alexander，我们聊了很多。进入激动人心的快问快答之前，有没有什么还没覆盖、但你特别想补充的？

Alexander Embiricos：

有一点想强调：Codex 团队正在扩张。正如我刚才说的，我们现在仍然受限于人类的思考速度和输入速度，但我们正在解决这个问题。

如果你是工程师、销售，或者产品经理，我们都在招人。最简单的方式是去 OpenAI 的招聘页面，或者直接私信我。我在 Twitter 上的账号是 Emir Rico，有兴趣可以直接联系。

主持人：

对很多人来说，这简直是梦想工作。有没有一个简单的筛选标准，帮你避免邮箱被淹没？

Alexander Embiricos：

如果你想加入 Codex 团队，你首先得是一个真正使用这些工具的技术型人才。

你可以问自己一个问题：假设接下来六个月你加入 OpenAI，参与 Codex 并且把事情做到极致，那时软件工程师的日常会变成什么样？如果你对这个问题已经有自己的判断，那你应该来试试。如果你完全没想过，需要想很久，那可能这就是一道自然的筛选。

我们对那些已经认真思考过“智能体时代该长什么样”的人非常感兴趣，不一定要和我们观点一致，但一定要有热情。

主持人：

能在这样一个影响巨大、又站在技术最前沿的产品上工作，确实非常罕见。对合适的人来说，这是一个了不起的机会。

希望我们能通过这期节目，帮你找到那个对的人。

参考链接：

https://www.youtube.com/watch?v=z1ISq9Ty4Cg&t=12s

文章来自于“51CTO技术栈”，作者 “云昭”。