内容概要
Alexander Embiricos 负责 OpenAI 强大的编程智能体 Codex 的产品工作。自 8 月以来，Codex 增长了 20 倍，现在每周处理数万亿 token。在加入 OpenAI 之前，Alexander 花了五年时间为工程师构建结对编程产品。他现在工作在 AI 驱动软件开发的前沿，致力于构建他所描述的“软件工程队友”——一个旨在参与整个开发生命周期的 AI 智能体。
目录
-
介绍 Alexander Embiricos
-
OpenAI 的速度与雄心
-
Codex：OpenAI 的编程智能体
-
Codex 的爆炸式增长
-
AI 与编程智能体的未来
-
AI 对工程的影响
-
Codex 如何改变产品经理的工作方式
-
一次性代码与无处不在的编程
-
发布 Sora Android 应用
-
构建 Atlas 浏览器
-
Codex 对生产力的影响
-
衡量 Codex 的进展
-
为什么要构建网络浏览器
-
Codex 的非工程用例
-
Codex 的能力
-
上手 Codex 的建议
-
AI 时代需要掌握的技能
-
我们距离像人类一样的 AI 还有多远？
-
Codex 的招聘与团队成长
-
快问快答与结语
介绍 Alexander Embiricos
Alexander Embiricos： 我负责 Codex 的工作。Codex 是 OpenAI 的编程智能体（Agent）。我们认为 Codex 只是软件工程队友的开端。它有点像一个非常聪明的实习生，但他拒绝阅读 Slack，除非你要求，否则也不检查 DataDog。
我记得 Karpathy 发推特说过，他遇到那种最棘手的 bug，花了好几个小时试图弄清楚，其他方法都解决不了。他把 bug 丢给 Codex，让它运行一个小时，然后它就解决了。
我们开始看到未来的雏形，Codex 甚至开始为自己的训练过程值班（On-call）。Codex 编写了大量帮助管理其训练运行的代码，也就是关键的基础设施。所以我们让 Codex 进行代码审查，这实际上捕捉到了很多错误。它甚至发现了一些非常有趣的配置错误。
最令人震惊的加速案例之一是 Sora Android 应用。这是一个全新的应用，我们在 18 天内构建完成，然后 10 天后——总共 28 天——我们就向公众发布了。
Lenny Rachitsky： 你认为你们如何在这个领域获胜？
Alexander Embiricos： 我们对 Codex 的主要目标之一是实现主动性（Proactivity）。如果我们要构建一个超级助手，它必须能够做事。过去一年的一个教训是，为了让模型做事，当它们可以使用计算机时效率会高得多。事实证明，模型使用计算机的最佳方式仅仅是编写代码。所以我们要达到这样一个理念：如果你想构建任何智能体，也许你应该构建一个编程智能体。
Lenny Rachitsky： 当你考虑 Codex 的进展时，我想你们有一堆评估指标和公开基准。我们中的一些人经常逛 Reddit，那里有赞扬也有很多抱怨。
Alexander Embiricos： 作为一个产品团队，我们要做的就是始终思考，如何构建一个工具，让人们感觉我们在最大程度地加速他们，而不是构建一个让人类更加困惑该做什么的工具。
Lenny Rachitsky： 在 OpenAI，我不得不问你觉得我们距离通用人工智能（AGI）还有多远。
Alexander Embiricos： 目前被低估的限制因素实际上是人类的打字速度或人类的多任务处理速度。
Lenny Rachitsky： 今天我的嘉宾是 Alexander Embiricos，OpenAI 极其受欢迎且强大的编程智能体 Codex 的产品负责人。用 ChatGPT 负责人兼前播客嘉宾 Nick Turley 的话来说，“Alex 是我合作过的最喜欢的人之一，把他和他的公司带入 OpenAI 是我们做过的最好的决定之一。”
同样，OpenAI 的首席产品官（CPO）Kevin Weil 说，“Alex 简直是最棒的。”在我们的对话中，我们聊到了在 OpenAI 做产品究竟是什么样的体验，Codex 如何让 Sora 团队在不到一个月的时间内发布了 Sora 应用并使其成为 App Store 排名第一的应用。还有 Codex 目前看到的 20 倍增长，以及他们做了什么让它如此擅长编程。
为什么他的团队现在专注于让审查代码变得更容易，而不仅仅是编写代码。他对 AGI 的时间线预测，他对 AI 智能体何时会真正变得有用的看法，等等。非常感谢 Ed Bues、Nick Turley 和 Dennis Yang 为本次对话提供的话题建议。
如果你喜欢这个播客，别忘了订阅并在你喜欢的播客应用或 YouTube 上关注。如果你成为我时事通讯的年度订阅者，你将免费获得 19 款令人难以置信的产品的一年使用权，包括 Devin、Lovable、Replit、Bolt、Noda、Linear、Superhuman、Descript、WhisperFlow、Gamma、Perplexity、Warp、Granola、Magic Patterns、Raycast、Chamfer、Mobbin、PostHog 和 Stripe Atlas。前往 lennysnewsletter.com 点击 Product Pass。接下来请听我与 Alexander Embiricos 的对话。
OpenAI 的速度与雄心
Lenny Rachitsky： Alexander，非常感谢你的到来，欢迎来到播客。
Alexander Embiricos： 非常感谢。我关注很久了，很高兴能来到这里。
Lenny Rachitsky： 我更兴奋。我非常感激。我想从你在 OpenAI 的经历开始。大约一年前你加入了 OpenAI。在那之前，你经营了自己的创业公司大约五年。再之前，你是 Dropbox 的产品经理。我想 OpenAI 与你工作过的其他地方非常不同。
我想问的是：OpenAI 的运作方式有什么最大的不同？你在那里学到了什么，是你认为无论去哪里都会带在身上的？
Alexander Embiricos： 到目前为止，我会说在 OpenAI 工作的速度和雄心简直大大超出了我的想象。这说起来有点尴尬，因为每个创业者都认为“哦，是的，我的创业公司行动超快，人才门槛超高，我们非常有野心。”但我不得不说，在 OpenAI 工作让我重新定义了这意味着什么。
Lenny Rachitsky： 我们经常听到这种说法，感觉每家 AI 公司都在说，“天哪，我不敢相信他们行动有多快。”有没有什么例子让你觉得，“哇，这在其他任何地方都不会发生得这么快？”
Alexander Embiricos： 最明显的例子就是 Codex 本身的爆炸性增长。我想我们有一段时间没有更新外部数据了，但是 Codex 规模的 10 倍增长仅仅发生在几个月内。从那以后增长得更多。
既然经历过这些，或者至少对我个人而言，现在我觉得如果我要把时间花在构建技术产品上，我就需要达到那种速度和规模。
回想我在创业公司做的事情，行动要慢得多。创业公司总是有一种平衡，即你在多大程度上坚持你的想法，还是发现行不通后转型。但在 OpenAI 我意识到的一件事是，我们能够产生的影响力——实际上为了做好工作我们需要产生的影响力——是如此之高，以至于我必须更加无情地利用我的时间。
Lenny Rachitsky： 在我们谈论 Codex 之前，是不是他们的组织结构，或者 OpenAI 的运作方式允许团队如此快速地行动？因为每个人都想行动得超快。我想肯定有一种结构性的方法来实现这一点。
Alexander Embiricos： 其中一点是，我们构建产品的技术本身改变了很多事情，不仅是我们如何构建，也包括我们可以为用户启用什么样的功能。我们把大部分时间都花在讨论基础模型的改进上，但我相信即使今天模型没有更多进展——这绝对不是事实——即使没有进展，我们在产品方面也落后太多了。有太多的产品需要构建。
所以我认为时机已经成熟。至于结构，当我刚来的时候，有很多反直觉的事情让我感到惊讶。比如我在做创业公司时，以及之前在 Dropbox 时，作为产品经理非常重要的一点是总是要稳住大船。这有点像确保你指向正确的方向，并且可以在那个方向上加速。
但在这里，因为我们要么不知道接下来会出现什么能力，要么不知道技术上什么行得通，甚至不知道即使技术上行得通什么能落地，所以我们要更加谦逊，通过实证学习，快速尝试。
组织架构的设置是非常自下而上（Bottoms-up）的。这又是一件每个人都想说的事情。我认为每个人都喜欢说他们是自下而上的，或者至少很多人这样做。但 OpenAI 是真正、真正的自下而上。这对我来说是一个学习经历。如果我将来在一家非 AI 公司工作——我甚至不认为将来在非 AI 公司工作有意义，我都不知道那意味着什么——但如果我要想象或回到过去，我想我会以完全不同的方式运作。
Lenny Rachitsky： 我听到的是一种“准备、开火、瞄准”的方法，而不是“准备、瞄准、开火”。这是不是因为——正如 Nick Turley 分享的——你们不知道人们会如何使用它，所以花很多时间把它做得完美是没有意义的。最好是以一种原始的方式把它发布出去，看看人们如何使用，然后在这个用例上做大？
Alexander Embiricos： 是的。用这个比喻来说，我觉得有一个“瞄准”的成分，但这个瞄准的成分更加模糊。就像，我们大概认为会发生什么？我在这里从一位研究负责人那里学到了很多，他喜欢说在 OpenAI，我们可以针对一年以后的事情进行非常好的对话。虽然会发生什么有很多不确定性，但那是一个正确的时间线。
然后我们可以针对几周或几个月内发生的事情进行很好的对话。但有一种尴尬的中间地带，就是当你开始接近一年但还没到一年的时候，这很难推理。所以就“瞄准”而言，我认为我们想知道，我们在努力构建的未来是什么样的？
我们在 AI 中处理的许多问题，比如对齐（Alignment），是你需要思考非常遥远的未来的问题。我们在那里进行模糊的瞄准。但当涉及到更具战术性的问题，比如“我们要构建什么产品，人们将如何使用该产品？”在这个地方，我们要更加通过实证来找出答案。
Lenny Rachitsky： 这是一个很好的说法。当人们听到这些时，有时会听到像你们这样的公司说，“好吧，我们要自下而上，我们要尝试一堆东西，我们在接下来的几个月里没有确切的计划。”关键在于你们雇佣了世界上最优秀的人，这感觉是这种自下而上工作模式能够成功的关键因素。
Alexander Embiricos： 这非常有共鸣。基本上，我刚到这里时，对这里的个人驱动力和自主权水平感到惊讶甚至震惊。我认为 OpenAI 的运作方式，你不能仅仅通过阅读这个或者听播客然后说，“我就要在我的公司部署这个。”
这可能听起来很刺耳，但我认为很少有公司拥有这种人才水平能够做到这一点。所以如果你要实施这个，可能需要进行调整。
Codex：OpenAI 的编程智能体
Lenny Rachitsky： 好的，让我们谈谈 Codex。你负责 Codex 的工作。Codex 进展如何？有什么数据可以分享吗？也不是每个人都知道 Codex 具体是什么。解释一下 Codex 是什么。
Alexander Embiricos： 完全没问题。我很幸运能在未来工作并领导 Codex 的产品。Codex 是 OpenAI 的编程智能体。具体来说，它是一个 IDE 扩展、VS Code 扩展，或者是你可以安装的终端工具。当你安装后，你基本上可以与 Codex 结对，回答关于代码的问题、编写代码、运行测试、执行代码，并处理软件开发生命周期中那个“厚重的中间部分”，即编写要投入生产的代码。
更广泛地说，我们认为 Codex 只是软件工程队友的开端。所以，当我们使用“队友”这个大词时，我们要想象的是它不仅能写代码，还能参与早期的构思和规划阶段，以及下游的验证、部署和维护代码。
为了让这更有趣一点，我想象目前的 Codex 有点像一个非常聪明的实习生，但他拒绝阅读 Slack，也不检查 DataDog 或 Sentry，除非你要求他这么做。所以无论它有多聪明，如果不是你也和它一起工作，你会多大程度上信任它写的代码呢？这就是今天人们主要使用它的方式，就是与它结对。
但我们希望达到这样一个程度：你可以像雇佣一个新实习生一样。你不仅要求他们写代码，还要求他们参与整个周期。你知道即使他们第一次没做对，他们最终也能通过迭代达到目标。
Lenny Rachitsky： 我以为关于不阅读 Slack 和 DataDog 的意思是它不会分心，只是持续专注并在心流中。但我明白你的意思，它没有关于正在发生的所有事情的上下文。
Alexander Embiricos： 这不仅在执行任务时是真实的，如果你想想最好的人类队友，你不需要告诉他们做什么，对吧？也许当你第一次雇佣他们时，你会开几次会，你会了解，“哦，这些提示（Prompt）对这个队友有效，那些无效，这是与这个人沟通的方式。”然后你会给他们一些入门任务，委派一些任务。
但最终你只会说，“嘿，太好了。你正和这一群人在这个代码库的这个区域工作。你也可以去代码库的其他部分和其他人一起工作。你告诉我你认为应该做什么。”
我们认为这就是主动性（Proactivity），我们对 Codex 的主要目标之一就是实现主动性。我认为这对于实现 OpenAI 的使命——将 AI 的好处带给全人类——至关重要。
我现在喜欢开玩笑说，现在的 AI 产品实际上很难用，因为你必须非常深思熟虑地考虑它何时能帮助你。如果你没有提示模型来帮助你，它当时可能就没有在帮你。如果你想想普通用户今天提示 AI 多少次，可能是几十次。但如果你想想人们实际上可以从一个真正智能的实体那里获得多少次好处，那是每天数千次。
所以我们在 Codex 上的大部分目标是弄清楚一个真正的队友智能体的形态是什么，让它可以默认提供帮助。
Lenny Rachitsky： 这就像一个帮你写代码、自动补全代码甚至做一些智能体工作的 IDE。我在这里听到的是愿景不同，它是一个队友。它就像一个为你编写代码的远程队友，你与它交谈并要求它做事，它也会做 IDE 自动补全之类的事情。这是你们思考 Codex 的一种差异化方式吗？
Alexander Embiricos： 基本上是这个想法，如果你是一个开发人员并试图完成某件事，我们希望你感觉自己拥有超能力，能够行动得更快。但我们不认为为了让你获得这些好处，你需要坐在那里不断思考，“这个时候我该如何调用 AI 来做这件事？”我们希望你能够把它插入到你的工作方式中，让它在你不需要思考的情况下就开始做事。
Codex 的爆炸式增长
Lenny Rachitsky： 好的，关于这些我有很多问题，但是目前进展如何？有没有什么关于 Codex 的统计数据可以分享？
Alexander Embiricos： 自从 8 月份发布 GPT-5 以来，Codex 的增长绝对是爆炸性的。关于我们如何解锁这种增长，确实有一些有趣的产品见解可以谈谈。上次我们分享的数据是自 8 月以来增长了 10 倍以上。实际上，从那时起已经增长了 20 倍。
此外，Codex 模型现在每周服务数万亿个 token，它基本上是我们服务量最大的编程模型。我们看到的一个非常酷的事情是，我们决定建立 Codex 团队的方式是建立一个紧密集成的产品和研究团队，共同迭代模型和工具框架（Harness）。
事实证明，这让你能做得更多，并尝试更多关于这些东西如何协同工作的实验。我们只是为了在我们非常有主见的第一方框架中使用而训练这些模型。最近我们开始看到，其他主要的 API 编程客户现在也开始采用这些模型。所以我们已经达到了这样一个点，Codex 模型也是 API 中服务量最大的编程模型。
Lenny Rachitsky： 你暗示了这一点，是什么解锁了这种增长？我对这一点非常感兴趣。感觉以前——也许是在你加入团队之前——Cloud Code 占据统治地位。每个人都坐在 Cloud Code 之上。那是当时最好的编程方式。
然后突然间 Codex 出现了。我记得 Karpathy 发推特说他从未见过这样的模型。我想那条推文是：他遇到的最棘手的 bug，花了好几个小时试图弄清楚，其他方法都解决不了，他给 Codex，让它运行一个小时，它就解决了。你们做了什么？
Alexander Embiricos： 我们在 OpenAI 有一个强烈的使命，那就是构建 AGI。所以我们经常思考如何塑造产品使其能够扩展。之前我提到，如果你是一个工程师，你应该每天从 AI 那里获得数千次帮助，对吧？当我们推出第一个版本的 Codex，即 Codex Cloud 时，我们在很大程度上考虑了这一点。
那个产品基本上有自己的计算机，生活在云端，你可以委托给它，最酷的部分是你可以并行运行许多任务。但我们看到的一些挑战是，设置它有点难，无论是在环境配置方面——给模型验证变更所需的工具——还是学习如何以这种方式进行提示。
我的比喻是回到队友这个说法。这就像你雇了一个队友，但你不被允许和他们通话，你只能异步地来回沟通。这适用于某些队友，最终这也是你想花费大部分时间的方式，所以那仍然是未来。但最初采用很难。
所以我们仍然有那个愿景，那是我们要带你去的地方：一个你委托任务然后会主动工作的队友。我们看到这正在增长。但关键的解锁实际上是你首先需要以一种更加直观且能轻松获得价值的方式落地用户。
今天大多数用户发现 Codex 的方式，要么是下载 IDE 扩展，要么是在 CLI 中运行，智能体在你计算机上的交互式环境中与你一起工作。它在一个沙盒（Sandbox）中工作，这实际上是一个非常酷的技术，可以确保安全。但它可以访问所有那些依赖项。所以如果智能体需要做某事，比如它需要运行一个命令，它可以在沙盒中这样做；我们要做的不仅仅是设置环境。
如果这个命令在沙盒中不起作用，它可以直接问你。所以你可以进入这种使用模型的非常强的反馈循环。随着时间的推移，我们团队的工作是将这种反馈循环转化为你在使用产品的过程中对它进行配置，以便稍后你可以委托任务给它。
再打个比方，如果你雇了一个队友并要求他们工作，但你只给他们一台从商店买来的新电脑，他们很难开展工作，对吧？但是，如果你和他们并肩工作，你可以说，“哦，你没有我们要用的这个服务的密码。这是这个服务的密码。没关系，尽管运行这个命令。”那么他们以后就更容易在没有你的情况下工作几个小时了。
Lenny Rachitsky： 所以我听到的是，Codex 的最初版本几乎太超前了。它就像一个在云端的远程智能体，为你异步编写代码。你们做的是，好吧，让我们稍微退后一点。让我们集成到工程师已经集成的 IDE 和本地环境中，帮助他们过渡到这个新世界。
Alexander Embiricos： 完全正确。这很有趣，因为我们在 OpenAI 大量地进行内部试用（Dogfooding）。Codex 在这一整年里都在加速 OpenAI，云产品对公司来说也是一个巨大的加速器。
事实证明，这是从内部试用获得的信号与从一般市场获得的信号略有不同的地方之一。因为在 OpenAI，我们整天都在训练推理模型，所以我们非常习惯这种提示方式。比如预先思考，大规模并行运行，虽然需要一些时间，稍后再异步回来查看。所以现在当我们构建产品时，我们仍然从内部试用中获得大量信号，但我们也同样非常清楚不同受众使用产品的不同方式。
Lenny Rachitsky： 这真的很有趣。生活在未来，但也许不要太遥远的未来。我可以看到 OpenAI 的每个人都生活在非常遥远的未来，有时这并不适用于所有人。除了这个，比如智能、训练数据？还有什么帮助 Codex 加速了其实际编程能力吗？是更好、更干净的数据？还是仅仅是模型在进步？
Alexander Embiricos： 有几个组成部分。你提到了模型，模型确实进步很大。实际上，就在上周三，我们发布了 GPT-5.1 Codex Max，这是个非常贴切的名字，它很棒。它之所以棒，不仅是因为对于你使用 GPT-5.1 Codex 的任何给定任务，它的完成速度大约快了 30%，而且它还解锁了大量的智能。
所以如果你在更高的推理级别使用它，它甚至更聪明。正如你提到的 Karpathy 的推文，把最棘手的 bug 交给我们。Codex Max 绝对扛起了解决最难 bug 的大旗。
但我会说，我们思考这个问题的方式正在从“我们要只考虑模型，让我们训练最好的模型”演变为真正思考“到底什么是智能体？”。我们认为它的技术栈是：你有一个非常聪明的推理模型，知道如何很好地完成特定类型的任务，但实际上我们需要通过 API 将该模型服务到一个工具框架（Harness）中。
这三者在这里都扮演着非常大的角色。例如，我们要非常自豪的一件事是，你可以让 GPT-5.1 Codex Max 工作很长时间。这并不常见，但你可以设置它这样做。现在我们经常听到人们说，“是的，它跑了一整夜”，或者“它跑了 24 小时”。
如果要让一个模型持续工作这么长时间，它将超出其上下文窗口（Context Window）。我们对此有一个解决方案，叫做压缩（Compaction）。但压缩实际上是一个使用了该栈的所有三层的功能。你需要有一个理解压缩概念的模型，并且知道，“好的，当我开始接近这个上下文窗口时，我可能会被要求准备在一个新的上下文窗口中运行。”在 API 层，你需要一个理解这个概念的 API，并且有一个端点可以让你点击来进行此更改。在工具框架层，你需要一个可以为此准备有效负载的框架。
因此，发布这个压缩功能使这种行为成为可能，实际上需要跨越所有这三样东西进行工作。我认为这将越来越成为事实。
另一个可能被低估的版本是：如果你看看所有不同的编程产品，它们都有非常不同的工具框架，对于模型应该如何工作有着非常不同的看法。例如，也许你有强烈的观点认为它应该使用语义搜索工作，对吧？也许你有强烈的观点认为它应该调用定制工具。或者像我们一样，你有强烈的观点认为它应该只使用 Shell，在终端中工作。
如果你只针对其中一个世界进行优化，你可以行动得更快。所以 Codex 的构建方式是它只使用 Shell。但为了使其更安全，我们有一个沙盒供模型在其中操作。所以我认为最大的加速因素之一，回到你的问题，就是我们并行构建所有这三样东西，并调整每一个，通过紧密集成的产品和研究团队不断尝试这些东西如何协同工作。
AI 与编程智能体的未来
Lenny Rachitsky： 你认为你们如何在这个领域获胜？你认为这最终会总是这种与其他模型不断互相超越的竞赛吗？你认为是否有一个世界，有人一骑绝尘，其他人永远追不上？有没有一条“我们赢了”的路径？
Alexander Embiricos： 还是回到构建队友这个想法，不仅仅是一个参与团队规划和优先级的队友。不仅仅是一个真正测试代码并帮助你维护和部署的队友。甚至是一个能够安排日历邀请，或者移动站会时间，或者做任何事情的工程队友。
在我看来，如果我们只是想象每天或每周都有一些疯狂的新能力被研究实验室部署，我们作为人类根本无法跟上并使用所有这些技术。所以我认为我们需要达到这样一个世界：你只要有一个 AI 队友或超级助手，你只要和它交谈，它就知道如何依靠自己提供帮助。你不必阅读最新的提示技巧；你只要把它插进去，它就会提供帮助。
这就是我认为我们要构建的形态。如果我们要做到这一点，那将是一个非常有粘性的获胜产品。在我看来，比如一个有趣的话题是，聊天是 AI 的正确界面吗？我实际上认为，当你不知道应该用它做什么时，聊天是一个非常好的界面。
就像我在 Teams 或 Slack 上与队友在一起时，聊天很不错。我可以要求我想要的任何东西，它是所有事物的共同点。所以你可以与超级助手聊任何你想聊的话题，无论是编程还是其他。然后，如果你是特定领域（如编程）的功能专家，你可以调出一个 GUI 来深入查看代码并与代码一起工作。
所以我想我们需要作为 OpenAI 构建的是这样一个想法：你有 ChatGPT，这是一个对每个人都普遍可用的工具。你甚至在工作之外开始使用它来帮助你。你变得非常习惯于被 AI 加速。然后你去工作，你可以自然地说，“是的，我要让它做这个，我不需要知道所有的连接器或所有不同的功能。我只是要向它寻求帮助，它会向我展示它在这个时间点能提供的最佳帮助方式。”甚至在我没有寻求帮助时也会插话。
在我看来，如果我们能做到这一点，那我们真的就构建出了获胜的产品。
Lenny Rachitsky： 这太有趣了，因为在我与 ChatGPT 负责人 Nick Turley 的聊天中，他分享说 ChatGPT 原来的名字是“超级助手”之类的。有趣的是，有那种超级助手的方法，然后有这种 Codex 的方法。这几乎就像 B2C 版本和 B2B 版本。
我在这里听到的是：好的，你从编程和构建开始，然后它为你做所有其他事情——安排会议，也许在 Slack 上发帖，发布设计。我想知道，这是某种意义上 ChatGPT 的商业版本，还是有其他的含义？
Alexander Embiricos： 这是一个大约一年的时间线对话。很多这方面可能会更早发生，但在模糊性方面，我认为我们在一年左右。所以我给你一个关于我们如何到达那里的似是而非的论点，至于它是如何发生的，谁知道呢？
基本上，如果我们要构建一个超级助手，它必须能够做事。过去一年的一个教训是，为了让模型做事，当它们可以使用计算机时效率会高得多。
好了，现在我们想，好吧，我们需要这个可以使用计算机或多台计算机的超级助手。现在的问题是，好吧，它应该如何使用计算机？使用计算机有很多种方式。你可以尝试黑进操作系统并使用辅助功能 API。稍微简单一点的是你可以点击，但这有点慢而且有时不可预测。另一种方式，事实证明模型使用计算机的最佳方式仅仅是编写代码。
所以我们正在接近这个想法：如果你想构建任何智能体，也许你应该构建一个编程智能体。也许对于非技术用户来说，他们甚至不知道自己在使用一个编程智能体，就像没人会想“我是在使用互联网吗”，他们更关心的是“Wi-Fi 开了吗”。
所以我认为我们正在用 Codex 做的是构建一个软件工程队友。作为其中的一部分，我们在构建一个可以通过编写代码来使用计算机的智能体。我们已经看到了一些这方面的需求。虽然还很早，但我们开始看到人们将 Codex 用于编程相邻的产品目的。随着发展，我想我们会自然地看到，如果有编程的方式来解决问题，我们就应该总是让智能体编写代码，即使你是在做财务分析，也可以为此写一些代码。
基本上，你问“这是否是这个产品的两端？”在我看来，编程是任何智能体（包括 ChatGPT）的核心能力。所以实际上我们认为我们正在构建的是那种能力。
但这才是智能体编写代码真正酷的地方：你可以导入代码。代码是可组合的、可互操作的。如果我们对智能体持有一个非常简化的观点，那就是给它一台电脑，它只是指点和点击，那是未来。
我们要如何到达那里很难规划，因为围绕构建智能体的很多问题不是“智能体能不能做”，而是更多关于“我们要如何帮助智能体理解它工作的上下文？”以及使用它的团队可能有他们喜欢做事情的方式。他们有指导方针。他们可能想要关于智能体能做或不能做什么的确定性保证。
比如，如果我们看一个崩溃报告工具，每一个子团队可能都有一个不同的元提示（Meta-prompt），关于他们希望如何分析崩溃。所以我们要让这可以为团队或用户配置。让智能体经常做的事情，我们可能只想将其构建为智能体拥有的能力。
所以我认为我们最终会得到这个通用的东西，即一个智能体可以为它想做的任何事情编写自己的脚本。但我认为这里真正关键的部分是：我们能不能做到，对于智能体经常做的或做得很好的每件事，我们可以记住并存储，这样智能体就不必再次为此编写脚本了？或者也许如果我刚加入一个团队，而你已经在同一个团队，我就能直接使用智能体已经编写好的所有脚本。
Lenny Rachitsky： 是的，就像如果这是我们的队友，他们可以分享从与公司其他人合作中学到的东西。这作为一个隐喻很有意义。感觉你是 Karpathy 阵营的人，认为“今天的智能体不怎么好，主要是垃圾（Slop），也许将来它们会很棒”。这让你有共鸣吗？
Alexander Embiricos： 我想是的。我认为编程智能体非常棒。我认为这是巨大的价值。然后我认为编程之外的智能体仍然处于非常早期的阶段。这只是我的观点，但我认为一旦它们也能使用代码并且以可组合的方式使用，它们将会变得更好。
这就是为软件工程师构建产品的乐趣所在。我在我的创业公司也为软件工程师构建了很久的产品。他们是一群非常有趣的受众，因为他们也喜欢为自己构建工具，并且经常在使用技术方面比我们更有创造力。通过为软件工程师构建产品，你可以观察到大量涌现的行为，以及你应该做什么并构建到产品中。
Lenny Rachitsky： 我喜欢你这么说，因为很多为工程师构建产品的人真的很恼火，因为工程师总是抱怨。他们会说，“啊那个很烂，你为什么要这样构建？”我很高兴你喜欢它。但我认为这可能是因为你正在为工程师构建这样一个惊人的工具，实际上可以解决问题并为他们编程。
AI 对工程的影响
Lenny Rachitsky： 顺着这个思路，总是有人在讨论工作会发生什么，工程师编程，你必须学习编程吗，所有这些事情。很明显，你描述它的方式是它是一个队友。它将与你一起工作，让你变得更加超人。它不会取代你。你是怎么看待拥有这个超级智能工程队友对工程领域的影响的？
Alexander Embiricos： 我认为这有两面性。但我们刚才谈到的是这样一个想法，也许每个智能体实际上都应该使用代码并成为一个编程智能体。在我看来，这只是这个更广泛想法的一小部分，即随着我们让代码变得更加无处不在——你可能会说即使在 AI 之前它也是无处不在的——但随着我们让代码更加无处不在，它实际上将被用于更多的目的。所以我认为对于拥有这种能力的人类来说，需求将会大大增加。这是我的看法。
这是一个相当复杂的话题，所以我们需要看看它如何发展。但我认为我们作为一个在这个领域构建的产品团队能做的就是始终思考，我们要如何构建一个工具，让人感觉我们在最大程度地加速人们？而不是构建一个让人们更加困惑作为人类应该做什么的工具。
举个例子：现在当你与编程智能体一起工作时，它会写很多代码。但事实证明，对于许多软件工程师来说，写代码实际上是软件工程中最有趣的部分之一。所以最后你变成了审查 AI 的代码，这对许多软件工程师来说通常是工作中不那么有趣的部分。
我认为我们看到这在大量的微决策中体现出来。所以我们作为一个产品团队一直在思考，我们如何让这更有趣？我们如何让你感到更有力量？我认为审查智能体编写的代码在今天是不那么有趣的地方。所以我想，我们可以对此做些什么？
好吧，我们可以发布一个代码审查功能，帮助你建立对所写代码的信心。我们能做的另一件事是我们可以让智能体能够更好地验证其工作。这甚至涉及到微决策。比如如果你要让智能体有能力验证工作，假设我们在看 Codex Web，你有一个反映智能体所做工作的面板。你先看到什么？你是看到 diff（差异对比），还是看到它编写的代码的图像预览？
如果你从“我如何赋予人类权力，我如何让他们感觉尽可能被加速”的角度思考，你应该首先看到图像，对吧？除非你知道你已经看过了图像，或者这正被 AI 审查，现在轮到你看了，否则你不应该在审查代码。
Lenny Rachitsky： 当我在播客上采访 Cursor 的 CEO Michael Charel 时，他有一个愿景，就是我们正在走向超越代码的东西。我看到了所谓的“规格驱动开发（Spec-driven development）”的兴起，你只要写规格，然后 AI 就会为你写代码。所以你开始在这个更高的抽象层面上工作。这是你看到的未来吗？就像工程师不必实际编写代码或看代码，我们将专注于这个更高的抽象层次？
Alexander Embiricos： 是的，我认为一直都有这些抽象层级，它们实际上今天已经在发挥作用了。比如今天的编程智能体主要是“提示到补丁（Prompt to patch）”。我们开始看到人们做规格驱动开发或计划驱动开发。这实际上是人们问“如何在真正长的任务上运行 Codex”的方法之一。通常是先与它协作写一个 plan.md，一个 markdown 文件作为你的计划。一旦你对那个满意，你就要求它去做工作。如果那个计划有可验证的步骤，它将工作得更久。我们完全看到了这一点。
我认为规格驱动开发是一个有趣的想法。我不确定它是否会那样发展，因为很多人也不喜欢写规格。但这似乎是有些人的工作方式。
不过有一个玩笑的想法是：如果你想想今天许多团队的工作方式，他们通常不一定有规格，但团队非常自我驱动，所以事情就完成了。这几乎就像……我是当场想出来的，所以这不是一个好名字，但这就像“聊天驱动开发（Chatter-driven development）”，事情就在社交媒体上和团队沟通工具中发生，结果代码被编写和部署。
所以我认为我更倾向于那种方式，我不一定想写规格。有时我只想在喜欢写规格的时候写。其他时候我可能只想说，“嘿，这是客户服务频道，告诉我有什么值得注意的。如果是小 bug，就修复它。我不想为此写规格。”
我有一个假设的未来，我有时喜欢作为一个挑衅性的想法分享给人们：在一个拥有真正惊人的智能体的世界里，作为一个个体创业者（Solopreneur）是什么样子的？关于它可能是什么样子的一个糟糕的想法是：实际上有一个移动应用程序，智能体必须做的每一个想法都只是你手机上的竖屏视频。如果那是坏主意你可以向左滑，如果是好主意你可以向右滑。你可以按住并对着手机说话，如果你想在滑动之前获得关于这个想法的反馈。
在这个世界里，基本上你的工作就是把这个应用程序插入到每一个信号系统、记录系统中，然后你就坐下来滑动。
Lenny Rachitsky： 我喜欢这个。这就像 Tinder 遇上 TikTok 遇上 Codex。这太棒了。所以这里的想法是，这个东西，这个智能体在观察并倾听你，关注市场，你的用户，然后它就像，“酷，这是我应该做的事情。”就像一个主动的工程师，“我们要构建这个功能，修复这个东西。”
Alexander Embiricos： 没错。我想它们正以最低限度的方式与你沟通……就像现代沟通方式：在垂直信息流中向左或向右滑动，然后是 Sora 视频。
Lenny Rachitsky： 好的，我现在看到这一切是如何连接的了。
Alexander Embiricos： 澄清一下，我们没有在构建那个。但这是一个有趣的想法。在这个例子中，它正在做的一件事是消费外部信号。我想另一件非常有趣的事情是，如果我们思考迄今为止最成功的 AI 产品是什么？我会争辩说……有趣的是，不混淆视听，但我们在 OpenAI 第一次使用 Codex 品牌实际上是驱动 GitHub Copilot 的模型。这是很久以前的事了。所以我们最近决定重新使用那个品牌，因为它太好了：Codex，代码执行（Code Execution）。
但我认为实际上 IDE 中的自动补全也是迄今为止最成功的 AI 产品之一。它之所以如此神奇，部分原因在于它可以非常迅速地向你展示帮助你的想法，当它正确时你被加速了，当它错误时其实也没那么烦人。它可以很烦人，但没那么烦人。所以你可以创建这种混合主动系统（Mixed-initiative system），根据你试图做的事情上下文地做出响应。
在我看来，这对我们作为 OpenAI 来说是一个非常有趣的事情。例如，当我们考虑推出浏览器（也就是 Atlas）时，在我看来，我们能做的非常有趣的事情之一就是我们可以在你日常生活时上下文地展示我们可以帮助你的方式。所以我们打破了这种“我们只看代码”或“我们只在你的终端里”的界限，进入这样一个想法：嘿，一个真正的队友处理的不仅仅是代码，对吧？他们处理很多网络内容。所以我们如何在这方面帮助你？
Lenny Rachitsky： 天哪，这里面内容太多了，我喜欢这个。好的，浏览器上的自动补全，这太有趣了。就像在你浏览和日常生活时，这里有所有我们可以帮助你的事情。我想简单谈谈 Atlas，我会回来的。Codex 代码执行，我不知道这个。这真的很聪明。我现在懂了。
好的，然后这个聊天……什么是聊天驱动开发？我想起来我曾在播客上采访过 Block 的 CTO John Gon，他们有一个叫做 Goose 的产品，是他们自己的内部智能体。他谈到 Block 的一位工程师让 Goose 看着他的屏幕并听每一个会议，并主动做他可能会想做的工作。所以提交 PR，发邮件，起草 Slack 消息。所以他在做一个非常早期版本的你所描述的事情。
Alexander Embiricos： 这超级有趣。我敢打赌……如果我们去问他们生产力的瓶颈是什么……他们有分享是什么吗？
Lenny Rachitsky： 可能是看着它，确保这是正确的事情。
Alexander Embiricos： 是的，我们现在看到了这一点。比如我们有 Codex 的 Slack 集成。人们喜欢，如果有什么需要快速做的事情，人们就直接 @mention Codex 比如“你为什么认为会发生这个 bug？”甚至不一定是工程师，数据科学家经常使用 Codex 来回答像“为什么你认为这个指标变动了？发生了什么？”这样的问题。
你在 Slack 中就能得到答案，这太棒了，超级有用。但当它写代码时，你必须回去看代码。所以我认为现在的真正瓶颈是验证代码是否有效并编写代码审查。在我看来，如果我们想达到那种世界，我认为我们需要弄清楚如何让人们配置他们的编程智能体，以便在工作的后期阶段更加自主。
Codex 如何改变产品经理的工作方式
Lenny Rachitsky： Codex 对你作为产品人、作为 PM 的运作方式有什么影响？这显然影响了工程——代码是为你写的。它对你在 OpenAI 的运作方式、对 PM 的运作方式有什么影响？
Alexander Embiricos： 我想主要是我觉得更有力量了。我一直是一个更偏向技术型的 PM，尤其是在为工程师开发产品时，我觉得有必要进行内部试用。但即使在那之外，我只是觉得作为一个 PM 我能做得更多。
Scott Belsky 谈到了这种“压缩人才栈（Compressing the talent stack）”的想法。这基本上是这样一个想法：也许这些角色之间的界限不像以前那么需要了，因为人们可以做得更多。每当有人能做得更多时，你就可以跳过一个沟通边界，让团队效率更高。
我想我们现在在很多职能中都看到了这一点。既然你问到了产品，现在回答问题：容易多了。你可以直接问 Codex 它的想法。很多 PM 类型的工作，比如理解什么发生了变化，同样直接让 Codex 帮忙。原型设计通常比写规格更快。这是很多人都谈论过的事情。
一次性代码与无处不在的编程
Alexander Embiricos： 我认为有一点不那么令人惊讶，但又稍微有点令人惊讶的是：我们主要是构建 Codex 来编写将要部署到生产环境的代码，但实际上我们现在看到用 Codex 编写了很多一次性代码（Throwaway code）。这有点回到了“无处不在的代码”这个想法。
比如有人想做一个分析，我想了解某件事，好吧，给 Codex 一堆数据，然后让它为此数据构建一个交互式的数据查看器。以前这样做太麻烦了，但现在完全值得花时间让智能体去做这件事。
同样，我在我们的设计团队看到了一些非常酷的原型。比如一个设计师想做一个动画——这是 Codex 中的硬币动画——通常编程这个动画太麻烦了，所以他们只是“凭感觉编程（Vibe coded）”了一个动画编辑器，然后用那个动画编辑器制作了动画，并签入到代码库中。
实际上我们的设计师……那里有大量的加速，说到压缩人才栈，我认为我们的设计师非常像 PM。他们做了大量的产品工作，他们甚至有一个完整的“凭感觉编程”的 Codex 应用程序侧边原型。所以我们讨论事情的方式经常是我们会有一个非常快速的讨论，因为有 10,000 件事情正在发生，然后设计师会去思考这应该如何工作。但他们不会再谈论它，而是会在他们的独立原型中“凭感觉编程”那个原型。
我们会玩一下，如果我们喜欢，他们会把那个原型“凭感觉工程化（Vibe engineer）”成一个实际的 PR 来落地。然后根据他们对代码库的熟悉程度——比如 Codex CLI 和 Rust 有点难——也许他们会自己落地，或者他们会做得差不多，然后工程师可以帮助他们落地 PR。
发布 Sora Android 应用
Alexander Embiricos： 我们最近发布了 Sora Android 应用。那是加速最令人震惊的例子之一。因为在 OpenAI 内部使用 Codex 显然真的非常非常高。但在这一年里它一直在增长，不仅是在技术人员的使用上，而且在如何充分利用编程智能体的强度和技能方面也提高了非常多。
Sora Android 应用，一个全新的应用，我们在 18 天内构建完成。从零到向员工发布，然后 10 天后——总共 28 天——我们就向公众正式发布（GA）了。这完全是在 Codex 的帮助下完成的，速度快得惊人。
我想说这有点……我不想说简单模式，但如果你是一家在多个平台上构建软件的公司，Codex 确实非常擅长一件事。所以如果你已经弄清楚了一些底层的 API 或系统。要求 Codex 移植东西真的非常有效，因为它有东西可以参考。
那个团队的工程师基本上是让 Codex 去看 iOS 应用，制定需要完成的工作计划，然后去实施。它几乎是同时在看 iOS 和 Android。所以基本上两周向员工发布，总共四周。快得离谱。
Lenny Rachitsky： 更疯狂的是它成为了 App Store 排名第一的应用。我简直无法想象。只有几个工程师，我想可能是两三个，在几周内。这太荒谬了。
构建 Atlas 浏览器
Alexander Embiricos： Atlas 是另一个例子。Ben 做了一个播客，分享了我们是如何构建 Atlas 的。Atlas 实际上是一个浏览器，构建浏览器真的很难。所以我们必须构建很多困难的系统。基本上我们达到了那个团队拥有大量 Codex 高级用户的程度，我们和他们谈论这个，因为很多工程师是我以前在创业公司共事过的，他们会说，以前这需要两三个工程师两三周的时间，现在只需要一个工程师一周。
所以那里也有巨大的加速。很酷的是我们首先在 Mac 上发布了 Atlas，但现在我们正在开发 Windows 版本。那个团队现在正在 Windows 上加速，他们也在帮助我们在 Windows 上改进 Codex，这在早期确实更难，因为我们上周发布的模型是第一个原生理解 PowerShell 的模型。PowerShell 是 Windows 上的原生 Shell 语言。
这真的很棒，看到整个公司都在被 Codex 加速。最明显的是研究部门，改进了我们训练模型的速度和质量。甚至像设计和市场营销。现在我们的产品营销人员经常直接从 Slack 进行字符串更改或直接从 Slack 更新文档。
Codex 对生产力的影响
Lenny Rachitsky： 这些例子太惊人了。你们生活在可能性的最前沿，这是其他公司将会工作的方式。再次强调，发布成为 App Store 第一的应用，我想它至少在世界范围内流行了一周。你说在 28 天内构建，其中 18 天只是为了让核心功能工作。
你说只有几个工程师？两三个？好的，你说 Atlas 花了一周构建？
Alexander Embiricos： 不不，Atlas 不是整周，但 Atlas 是一个非常庞大的项目。我和 Atlas 的一位工程师聊天，问他们用 Codex 做什么，基本上答案是我们在所有事情上都使用 Codex。我说好吧，你怎么衡量加速？得到的回答是，以前这需要两三个工程师两三周，现在是一个工程师一周。
Lenny Rachitsky： 你认为这最终会转向非工程师做这类事情吗？比如这一定要是工程师构建吗？能不能由 PM 或设计师构建？
Alexander Embiricos： 我认为我们将很快达到界限有点模糊的程度。我认为你会想要有人理解他们正在构建的细节，但那些细节将会演变。就像现在如果你写 Swift，你不必会说汇编语言（Assembly）。世界上只有少数人需要会汇编，那是一个像大多数公司不需要拥有的专业职能。
所以我认为我们自然会看到抽象层级的增加。很酷的是现在我们正在进入语言抽象层，比如自然语言。自然语言本身非常灵活，对吧？你可以让工程师讨论计划，然后你可以让工程师讨论规格，然后你可以让工程师讨论产品或想法。所以我认为我们也可以开始向那些抽象层级移动。
但我认为这将是渐进的。我不认为会突然变成没人写任何代码，只有规格。我认为这更像是，好吧，我们将编程智能体设置得非常擅长预览构建或运行测试。也许那是大多数人设置的第一部分。好的，现在我们设置好了，它可以执行构建并且可以看到自己更改的结果。
但我认为至少在一段时间内，我们将需要人类参与来策划智能体需要擅长与之对话的连接器、系统或组件。然后将来会有更大的解锁，Codex 会告诉你如何设置它，或者可能在代码库中自行设置。
Lenny Rachitsky： 这是一个多么疯狂的时代。哇。我很好奇这种事情的二阶效应。只是构建东西变得如此之快。那意味着什么？分发变得更加重要了吗？这是否意味着想法更有价值？思考这如何变化很有趣。
Alexander Embiricos： 我仍然不认为想法像许多人想的那样有价值。我仍然认为执行真的很难。你可以快速构建东西，但你仍然需要很好地执行它，仍然需要让它有意义并且是一个连贯的整体。是的，分发是巨大的。
Lenny Rachitsky： 感觉其他一切现在都更重要了。除了构建部分之外的所有事情，比如想出想法、推向市场、盈利等等。
Alexander Embiricos： 我认为我们可能处于一个奇怪的暂时阶段，有一段时间……构建产品太难了，以至于你主要只需要非常擅长构建产品，也许你不一定要对特定客户有深刻的理解。但现在我认为我们到了这样一个点，如果我只能选择理解一件事，那就是对特定客户问题的真正有意义的理解。
所以我认为这最终仍然是最重要的。如果你今天创办一家新公司，并且你对目前 AI 工具服务不足的客户有非常好的理解和网络，我认为你就能成功。反之，如果你擅长构建网站，但你没有特定的客户要为其构建，我认为你的日子会难过得多。
Lenny Rachitsky： 我听到的是看好垂直 AI 创业公司。
Alexander Embiricos： 是的，我完全同意。有那种能解决很多问题的通用东西，也有那种“我们要把演示文稿做得极好，我们要比任何人都更了解演示文稿的问题，我们要插入你的工作流和所有其他对特定问题很重要的事情。”
衡量 Codex 的进展
Lenny Rachitsky： 好的，难以置信。当你考虑 Codex 的进展时，我想你有一堆评估指标和公开基准。你看什么来告诉你我们正在取得非常好的进展？我想这不会是唯一的一件事，但你关注什么？什么是你试图推动的 KPI？
Alexander Embiricos： 我不断提醒自己的一件事是，像 Codex 这样的工具自然是一个你会成为高级用户的工具。所以我们可能会不小心花很多时间思考那些在用户采用旅程中非常深层的功能。这样我们最终可能会过度解决那个问题。
所以我认为非常重要的是要去看看你的 D7 留存率。这就去试用产品，比如从头开始注册。我有太多为了最大程度正确地进行内部试用而在我的 Gmail 上注册的账户，它们每月收我 200 美元。我需要报销这些。
但我认为作为用户的感觉和早期留存统计数据对我们来说仍然非常重要，因为尽管这个类别正在起飞，我认为我们仍然处于人们使用的非常早期阶段。
我们做的另一件事可能……我认为我们可能是这个领域中最关注用户反馈/社交媒体的团队。我们中的一些人经常逛 Reddit 和 Twitter，那里有赞扬也有很多抱怨，但我们非常认真地对待抱怨并查看它们。我认为还是因为你可以将编程智能体用于许多不同的事情，所以它经常在特定行为上以某种方式坏掉。
我们实际上经常监控社交媒体上的氛围。特别是 Twitter (X) 有点炒作，而 Reddit 有点消极但实际上很真实。所以我开始越来越关注人们在 Reddit 上谈论使用 Codex 的情况。
Lenny Rachitsky： 这对人们知道很重要：你最常检查哪些 subreddit？有 r/codex 吗？
Alexander Embiricos： 算法非常擅长展示内容，但 r/codex 就在那里。
Lenny Rachitsky： 如果人们在 Twitter 上标记你，你仍然会看到，但也许不如在 Reddit 上看到那么有力？
Alexander Embiricos： Twitter 的有趣之处在于它有点像一对一，即使它是公开的，而在 Reddit 上有非常好的点赞机制，也许大多数人仍然不是机器人，不清楚。所以你可以得到关于什么重要以及其他人怎么想的良好信号。
为什么要构建网络浏览器
Lenny Rachitsky： 有趣的是 Atlas。我想简单谈谈这个。你们推出了 Atlas。我发推特说我试用了 Atlas，但我不太喜欢纯 AI 的搜索体验。我有时候就是想要 Google，不想等 AI 给我答案。而且无法切换。我发推特说我要换回去了，它不是很好。
我感觉我让 OpenAI 的一些 PM 难过了，我看到有人发推特说好的我们现在有这个功能了，我想这一直是计划的一部分。这可能是一个例子，就像我们只要发布，我们必须发布东西看看人们如何使用，然后我们再解决。我想一个是那里有什么？第二，我很好奇为什么你们要构建网络浏览器？
Alexander Embiricos： 我在 Atlas 工作过一段时间。我现在不在那个项目了。但这背后的叙事对我来说，讲讲我的故事，我在做这个屏幕共享结对编程创业公司。然后我们加入了 OpenAI，当时的想法真的是构建一个上下文桌面助手。我认为这之所以如此重要，是因为不得不把你所有的上下文给助手，然后弄清楚它如何能帮助你，这真的很烦人。如果它能直接理解你在试图做什么，那么它就可以最大程度地加速你。
我仍然把 Codex 看作是一个上下文助手，从一个稍微不同的角度，从编程任务开始。但至少对我个人而言——我不能代表整个项目——一些想法是大量的工作是在 Web 上完成的。如果我们能构建一个浏览器，我们就能以一种更加一流的方式为你提供上下文服务。我们不用破解其他桌面软件（它们对渲染内容的辅助功能树支持各不相同）。我们不用依赖截图（截图有点慢且不可靠）。相反，我们可以在渲染引擎中，提取我们需要的东西来帮助你。
我也喜欢想电子游戏，比如 Halo，你走到一个物体前，按 X 键，它就会做正确的事情。我记得我第一次读到关于上下文操作（Contextual action）时，我觉得这是一个非常酷的想法。
关于上下文操作的一点是我们需要知道你在试图做什么。我们需要有一点上下文，然后我们可以提供帮助。我认为这至关重要，因为想象我们到达的那个世界，我们有智能体每天帮助你数千次。想象一下，如果我们告诉你我们帮助了你的唯一方式是推送通知。那你每天会收到一千个 AI 的推送通知说“嘿，我做了这件事，你喜欢吗？”那会超级烦人。
如果是在软件工程中，我在看一个仪表盘，注意到一些关键指标下降了，在那个时间点，AI 也许可以去看看，并在我查看仪表盘时就在那里提出它关于为什么这个指标下降的看法以及可能的修复方案，对吧？那会让我更加保持在心流中，并使智能体能够对更多事情采取行动。
在我看来，我们要拥有一个浏览器的部分原因是，我认为我们对我们应该在什么方面提供帮助有更多的上下文。用户对他们希望我们看什么有更多的控制权。就像如果你想让我们对某事采取行动，你可以在你的 AI 浏览器中打开它；如果你不想，你可以在其他浏览器中打开。这就是清晰的控制和界限。然后我们要构建混合主动（Mixed-initiative）的用户体验，以便我们可以在有帮助的时候向你展示上下文操作，而不是仅仅随机通知你。
Codex 的非工程用例
Lenny Rachitsky： 听到 Codex 成为超级助手的愿景，不仅仅是为了为你编程。它是作为一个队友，作为一个让你在工作中变得很棒的超级队友为你做很多事情。说到这个，Codex 有其他非工程的常见用例吗？我们谈到了设计师原型设计和构建东西。有没有什么非工程师使用 Codex 的有趣或意想不到的方式？
Alexander Embiricos： 有很多意想不到的方式，但我认为我们看到真正有吸引力的地方目前仍然是非常编程相邻的，或者是那种有成熟生态系统的技术导向的地方，或者也许你在做数据分析之类的。我个人预计随着时间的推移我们会看到更多这样的情况。但目前我们让团队非常专注于编程，因为还有很多工作要做。
Codex 的能力
Lenny Rachitsky： 对于那些正在考虑尝试 Codex 的人来说，它适用于各种代码库吗？它支持什么代码？如果你是 SAP，你能添加 Codex 并开始构建东西吗？什么是最佳甜点，或者在哪里它还不那么惊人？
Alexander Embiricos： 我很高兴你问这个问题，因为尝试 Codex 的最佳方式是给它你最难的任务，这与其他一些编程智能体略有不同。其他工具你可能会想，好的让我从简单的开始，或者只是凭感觉编程一些随机的东西来决定我是否喜欢这个工具。而我们真的在构建 Codex 成为你可以把你最难的问题交给它的专业工具，它可以在你并不完美的大型代码库中编写高质量的代码。
所以我想如果你要尝试 Codex，你想在你有的一项真实任务上尝试，而不一定要把那个任务简化成微不足道的东西，而是像你有一个很难的 bug，你不知道是什么导致了那个 bug，你让 Codex 帮忙弄清楚或者实施修复。
Lenny Rachitsky： 我喜欢这个答案。只管给它你最难的问题。
Alexander Embiricos： 我会说，如果你说“嘿，好吧，我有最难的问题是如果不构建一个新的独角兽企业，那是行不通的”，那目前还不行。所以我认为给它最难的问题，但仍然是一个问题或一个任务来开始。如果你在测试，那是最好的，随着时间的推移你可以学习如何将它用于更大的事情。
Lenny Rachitsky： 是的。它支持什么语言？
Alexander Embiricos： 基本上我们训练 Codex 的方式是支持一系列语言分布，这与世界上这些语言的频率相当一致。除非你在写一些非常深奥的语言或者某种私有语言，否则它在你的语言中应该表现良好。
上手 Codex 的建议
Lenny Rachitsky： 如果有人刚开始使用，有没有什么建议可以帮助他们成功？就像如果能在某人第一次设置 Codex 时悄悄给他们一个建议，你会说什么？
Alexander Embiricos： 我可能会说尝试并行做几件事。你可以尝试给它一个困难的任务，也许让它理解代码库，围绕你的一个想法制定一个计划，然后从那里开始构建。这里的元想法是这又像是在与一个新队友建立信任，对吧？所以你不会去找一个新队友然后给他们“嘿，做这件事，零上下文”。你会先确保他们理解代码库，然后你们可能会就一种方法达成一致，然后你会让他们一点一点地去做。
我想如果你那样使用 Codex，你自然会开始理解提示它的不同方式，因为提示 Codex 和其他模型确实有点不同，它是一个超级强大的智能体和模型。
AI 时代需要掌握的技能
Lenny Rachitsky： 还有几个问题。随着 AI 做越来越多的编程，总是有这样的问题：我应该学习编程吗？如果人们试图弄清楚他们的职业生涯该做什么，特别是如果他们对软件工程、计算机科学感兴趣，你认为计算机科学中有哪些特定元素变得越来越重要？也许有些事情他们不需要担心，你认为在这个越来越多的工作场所中，人们应该在技能方面倾向于什么？
Alexander Embiricos： 我认为有几个角度。最容易想到的就是做一个行动者（Doer）。随着编程智能体随着时间的推移变得越来越好，甚至像大学生或应届毕业生能做的事情也比以前多得多。所以我认为你要利用这一点。
当我看招聘早期职业生涯的人时，我肯定会考虑他们使用最新工具的效率如何。他们应该超级高效。如果你这样想，实际上他们比以前更有优势，因为他们现在有了这些惊人的编程智能体。所以这是其一，建议就是学习任何你想学的，但要确保你花时间做事情，而不仅仅是完成作业。
另一方面是，深刻理解什么是好的整体软件系统仍然非常有价值。所以我仍然认为像真正强大的系统工程技能，或者像与团队进行有效沟通和协作这样的技能仍然很重要，并且会在相当长的一段时间内继续重要。
我不认为会突然变成 AI 编程智能体可以在没有你帮助的情况下构建完美的系统。我认为这看起来更像是渐进的，比如我们有这些 AI 编程智能体，它们能够验证它们的工作。这仍然很重要。比如我想到一位在 Atlas 工作的工程师，他设置 Codex 使其可以验证自己的工作，这有点不简单。他做这件事的方式实际上是提示 Codex：“嘿，你为什么不能验证你的工作？修复它。”并且在一个循环中这样做。
所以在各个阶段你仍然需要人在回路中（Human in the loop）来帮助配置编程智能体以使其有效。所以我认为你仍然需要能够推理这一点。也许你打字非常快或者你确切知道如何写 for 循环并不那么重要，但你需要能够推理不同的系统以及什么使软件工程团队有效。
最后一个角度是，如果你处于某件事的知识前沿，我仍然认为那是深入研究的有趣方向，部分是因为那些知识仍然是智能体不那么擅长的。但也部分是因为我认为通过试图推进特定事物的前沿，你实际上会被迫利用编程智能体并在过程中使用它们来加速你自己的工作流。
Lenny Rachitsky： 当你谈到处于前沿时，有什么例子吗？
Alexander Embiricos： Codex 编写了大量帮助管理其训练运行的代码，也就是关键的基础设施。我们行动非常快，所以我们让 Codex 进行代码审查，这捕捉到了很多错误。它实际上发现了一些非常有趣的配置错误。我们甚至开始看到未来的雏形，Codex 甚至开始为自己的训练过程值班（On-call），这非常有趣。
Lenny Rachitsky： 等等，为自己的训练值班是什么意思？所以它在运行训练，然后就像“哦，有什么东西坏了，需要人……”然后它就像“这儿，我要修复这个问题并重新启动？”
Alexander Embiricos： 这是一个我们在弄清楚的早期想法，但基本的想法是在训练运行期间有一堆图表，今天人类在看，看这些图表真的很重要。
Lenny Rachitsky： 我们称之为保姆式看护（Babysitting），因为我想训练非常昂贵，而且快速行动非常重要。
Alexander Embiricos： 没错。训练运行背后有很多系统，所以系统可能会宕机或者某处可能会引入错误，所以我们可能需要修复它或暂停事情。基本上让 Codex 在一个循环中运行来评估这些图表随时间的变化，这是我们让训练更加高效的一个想法。
Lenny Rachitsky： 我喜欢那个。这非常符合这不仅是编程，而是智能体的未来。Codex 不仅仅是为了构建代码，对吧？
我们距离像人类一样的 AI 还有多远？
Lenny Rachitsky： 好的，最后一个问题。在 OpenAI，我不得不问你的 AGI 时间线以及你认为我们距离 AGI 有多远。我知道这不是你的工作内容，但有很多观点。你认为我们距离人类版本的 AI 还有多远？
Alexander Embiricos： 对我来说，这有点关于我们什么时候看到加速曲线变成冰球棍曲线（Hockey stick，指急剧增长）。我认为目前的限制因素——有很多，但我认为目前被低估的限制因素——实际上是人类在编写提示时的打字速度或人类的多任务处理速度。就像你说的，你可以让智能体看着你做的所有工作，但如果你没有让智能体也验证它的工作，那么你仍然受限于你能否去审查所有那些代码。
所以我的看法是，我们需要通过让人类不必提示和不必手动验证所有工作来解锁那些生产力循环。如果我们能重建系统让智能体默认有用，我们将开始解锁指数级增长。
不幸的是，我不认为那将是二元的。我认为这将非常取决于你在构建什么。比如我想明年如果你是一家创业公司，正在构建一个新的应用，你将能够在智能体比以前更加自给自足的技术栈上设置它。但现在假设你在 SAP 工作。他们有许多复杂的系统，他们不可能在一夜之间让智能体在这些系统中自给自足。
所以他们将不得不慢慢替换系统或更新系统，以允许智能体端到端地处理更多工作。所以基本上我的长篇大论是，我认为从明年开始，我们将看到早期采用者的生产力开始指数级增长。接下来的几年里，我们将看到越来越大的公司生产力指数级增长。然后在那个模糊的中间地带，这种指数级增长将回流到 AI 实验室，那基本上就是我们将达到 AGI 的时候。
Lenny Rachitsky： 我喜欢这个答案。这非常务实，也是这个播客经常提到的一点，就是审查 AI 所做的一切的时间真的很烦人，是一个巨大的瓶颈。我很高兴你在研究这个问题，因为让编程更高效是一回事，解决“这真的很棒吗？”的最后一步是另一回事。这非常有趣，你认为那是限制因素。这回到了你之前的观点，即使 AI 不再进步，只要我们学会更有效地使用它，我们还有很多潜力可以解锁。这是一个非常独特的答案。我还没听过这种观点，即大的解锁是：人类审查 AI 为我们所做事情的打字速度。
Codex 的招聘与团队成长
Lenny Rachitsky： 好的 Alexander，我们涵盖了很多内容。在我们进行非常激动人心的快问快答之前，你还有什么想分享的吗？
Alexander Embiricos： 我想有一件事是 Codex 团队正在成长，正如我刚才所说，我们仍然在某种程度上受到人类思考速度和打字速度的限制。我们在努力解决这个问题。所以如果你是一个工程师、销售人员，或者我在招聘产品人员，请联系我们。你可以去我们的招聘页面，或者直接给我发私信，比如我在 Twitter 上是 Embirico，如果你有兴趣加入团队，请联系我。
Lenny Rachitsky： 对很多人来说这是梦想的工作。怎么过滤一下人选，以免淹没你的收件箱？
Alexander Embiricos： 具体来说，如果你想加入 Codex 团队，你需要是一个使用这些工具的技术人员。我想我会让你问自己一个问题：嘿，假设我加入 OpenAI 并在接下来的六个月里从事 Codex 工作并取得了巨大成功，那时软件工程师的生活会是什么样的？我想如果你对此有看法，你应该申请。如果你对此没有看法并且必须先思考一下，这就是过滤器。
因为有很多人在思考这个领域，所以我们对那些已经在思考智能体未来应该是什么样的人非常感兴趣。我们不必在去向上达成一致，但我想我们需要对这个话题充满激情的人。
Lenny Rachitsky： 开发这种具有如此大影响力且处于可能性最前沿的产品非常罕见。对于合适的人来说，这是一个多么酷的角色。
快问快答与结语
Lenny Rachitsky： 我们到了非常激动人心的快问快答环节。我有五个问题问你，Alexander。准备好了吗？
Alexander Embiricos： 我不知道这些是什么，但我很兴奋。来吧。
Lenny Rachitsky： 第一题：你最推荐给别人的几本书是什么？
Alexander Embiricos： 我最近一直在读很多科幻小说，我很确定这以前被推荐过，但是《文明》（The Culture）。作者是 Iain Banks。我之所以喜欢它，是因为它基本上是关于 AI 未来的相对近期的写作，但它是一个乐观的 AI 未来。很多科幻小说都相当反乌托邦，但这就像……我想这被描述为一个太空共产主义乌托邦。我觉得用这种文化来思考我们可以迎来什么样的世界以及我们今天可以做出什么决定来帮助迎来那个世界真的很有趣。
Lenny Rachitsky： 哇，我想以前没人推荐过这本。如果你想要另一本 AI 类的科幻书，你看过《深渊上的火》（A Fire Upon the Deep）吗？
Alexander Embiricos： 没看过。
Lenny Rachitsky： 好的，那本书好得难以置信。这是一个带有超级智能的史诗般的太空歌剧。有些乐观。
下一题：有没有你最近非常喜欢的电影或电视节目？
Alexander Embiricos： 有一部动漫叫《咒术回战》（Jujutsu Kaisen），我非常喜欢。它有一个稍微黑暗的主题，关于恶魔，但我喜欢它的是主角真的很好。我认为这一波新的动漫和卡通中，主角真的很友好，是关心世界的人，而不是像一些早期的动漫（如《EVA》或《阿基拉》）那样，主角有深深的缺陷，相当不快乐。甚至很有趣的是有这些非常积极的主角，他们只是想帮助周围的每个人。
Lenny Rachitsky： 我喜欢我们在这些推荐中了解到的你的个性。好的主角，乐观的未来。
Alexander Embiricos： 我想如果你不相信它，你就无法将它变成现实。
Lenny Rachitsky： 这是你的训练数据。有没有你最近发现并真正喜欢的产品？可以是 App，衣服，厨房小工具，科技产品？
Alexander Embiricos： 我一直很喜欢内燃机和汽车。实际上我最初来美国是因为我想从事美国飞机工作。但现在我在做软件。很长一段时间我基本上只有很旧的跑车，因为它们更实惠。最近我们买了一辆 Tesla，我不得不说我发现 Tesla 的软件非常有启发性。
特别是它的自动驾驶功能。我想思考如何构建混合主动软件真的很有趣，这让你感觉作为人类最大程度地被授权、最大程度地控制，但同时也获得了大量帮助。我认为他们在让汽车自动驾驶但你仍然可以通过多种方式调整它在做什么而不关闭自动驾驶方面做得非常好。你可以加速，它会听；你可以转动旋钮改变速度；你可以轻微转向。我认为这实际上是在构建一个仍然让人类控制的智能体方面的大师级课程。
Lenny Rachitsky： 这让我想起 Nick Turley 的整个口头禅是“我们被最大程度地加速了吗？”
Alexander Embiricos： 是的。
Lenny Rachitsky： 还有两个问题：你有没有经常思考并在工作或生活中对你有帮助的人生座右铭？
Alexander Embiricos： 我不知道我有没有人生座右铭，但也许我可以告诉你我那家创业公司的第一大价值观，那就是既要善良又要坦率（Kind and Candid）。
Lenny Rachitsky： 这很有道理。
Alexander Embiricos： 我们作为创始人意识到我们经常做老好人，但这实际上不是正确的事情。我们会推迟艰难的对话，我们并不坦率。所以每次我们都会提醒自己这个座右铭，然后我们会变得更加坦率。然后六个月后我们会意识到我们在六个月前其实并不坦率，我们需要更加坦率。那么问题是，好吧，我们应该如何坦率？就像，好吧，让我们把坦率看作是一种善良的行为，不仅在于做这件事，还在于我们如何向人们表达它。
Lenny Rachitsky： 那是对如何领导的一个美丽的总结。这就有点像《绝对坦率》（Radical Candor）那本书。
Alexander Embiricos： 哦是的。所以这就像思考绝对坦率的另一种方式。
Lenny Rachitsky： 最后一个问题。我查了你的姓 Embiricos，想看看有什么故事。我在问 ChatGPT，它告诉我姓这个的最著名的人是有影响力的希腊诗人和精神分析学家 Andreas Embiricos，以及他的亲戚，富有的航运巨头和艺术收藏家 George Embiricos。问题是，这两个人中你更认同哪一个：希腊诗人和精神分析学家，还是富有的航运巨头和艺术收藏家？
Alexander Embiricos： 我想必须是诗人，因为他热爱我们家族来自的那个岛屿。
Lenny Rachitsky： 等等，你认识这些人？这不仅是新闻。
Alexander Embiricos： 这是一个庞大的家族，这是希腊人，你知道这些大家族每个人都是你的叔叔。但他热爱那个家族发源的岛屿 Andros，那是一个非常美丽的地方，那里的牲畜比人多，游客不多。我认为很酷的是他发表了很多作品，很多作品都是关于那个岛屿的美丽，我认为这超级酷。
Lenny Rachitsky： 这是一个惊人的答案。最后：人们如果要关注你可以去哪里，以及听众如何对你有用？
Alexander Embiricos： 我是那种只有为了工作才有社交媒体的人。我的手机在晚上 9 点就变成黑白的了。Twitter 或 X 上我是 Embirico。如果你在 r/codex 发帖我可能会看到。
听众如何有用？我会说请尝试 Codex。请分享反馈，让我们知道该改进什么。我们非常关注反馈。我认为增长虽然惊人，但仍然是非常早期的时期。另外，如果你有兴趣致力于编程智能体的未来以及一般的智能体，请申请我们的工作，或者在那些社交媒体上给我发消息。
Lenny Rachitsky： Alexander，这太棒了。我总是喜欢认识致力于 AI 的人，因为它总是感觉像是一个非常无菌、可怕、神秘的东西，然后你遇到构建这些工具的人，他们总是那么棒，尤其是你，那么好。正如你分享的例子：乐观和善良。这是我们想要的人，这是我们想要构建这些将驱动未来的工具的人。所以我非常感谢你这样做。
Alexander Embiricos： 非常感谢邀请我。这很有趣。
Lenny Rachitsky： 非常感谢收听。如果你觉得这有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅该节目。也请考虑给我们评分或留下评论，因为这真的能帮助其他听众找到这个播客。你可以在 https://www.google.com/search?q=lennyspodcast.com 找到所有过去的剧集或了解更多关于节目的信息。下一集见。
