为什么人类才是 AI 的最大瓶颈（以及 2026 年将发生什么）

我们经常听到这类说法，感觉每家 AI 公司都在说，"天哪，我不敢相信他们发展速度有多快。"有没有一个例子让你不禁感叹，"哇，这在别的任何地方都不可能发生得这么快"？

我想到最明显的例子就是 Codex 本身的爆发式增长。我觉得这太疯狂了，自从我们上调了它的 thermal number 以来，你知道，Codex 规模的那次 10 倍增长在短短几个月内就发生了。而且从那时候到现在，规模又远不止于此了。

你知道，一旦经历过这些——至少就我个人而言，在经历过后——我觉得只要我要花时间做科技产品，就必须达到那种速度和规模。回想我在创业公司的日子，进展要慢得多。而且创业公司总是面临一种权衡：你要在多大程度上坚持已有的想法， versus 发现它行不通然后转型。但我在 OpenAI 意识到的一点是，我们能产生的影响，以及事实上要做好工作所必须产生的影响，是如此之大，以至于我现在必须更加不留情面地分配自己的时间。

在聊到 Codex 之前，我想问：他们在组织架构上，或者说 OpenAI 的运作方式上，有没有什么做法能让团队移动得这么快？因为每个人都想极速前进。我猜这背后有某种结构性的方法来促成这一点。

我是说，一方面，我们正在构建的技术本身已经改变了很多东西，既包括我们构建产品的方式，也包括我们能为用户实现的功能。你知道，我们大部分时间都在讨论 foundation models 的改进，但我相信，即使模型今天不再进步——当然事实绝非如此——但即使不再进步，我们在产品方面也远远落后。还有太多产品要做。所以我觉得时机就是对了，如果你明白我的意思。

嗯。

但说到组织架构，有很多反直觉的事情让我入职时感到惊讶。我想到的一个例子是，当我在自己的创业公司工作，以及之前在 Dropbox 的时候，作为 PM 非常重要的一点是要始终稳住团队方向，确保大家指向正确的方向，然后才能朝那个方向加速。但在这里，我觉得因为我们并不确切知道接下来会出现什么能力，也不知道技术上什么能行得通，而且即便技术上可行，我们也不知道市场会不会接受，所以对我们来说，更重要的是保持谦逊，更多地通过实证去学习，快速尝试。

而且整个组织架构就是这样设置的，非常 bottoms up。你知道，这又回到了你说的那个点：每个人都想快速行动。我觉得每个人都喜欢说自己是 bottoms up，至少很多人都这么说，但 OpenAI 是真的、彻彻底底的 bottoms up，这对我来说是一次学习经历。现在我觉得，如果我将来去——我甚至觉得将来去非 AI 公司工作都没有意义了。我都不知道那意味着什么。但如果我想象一下，或者回到过去，我觉得我会用完全不同的方式来管理。

我听到的意思更像是 ready fire aim（先开枪再瞄准），而不是 ready aim fire（先瞄准再开枪）。而且——你慢慢体会这句话，因为这听起来可能不太好——但我确实在很多 AI 公司听到过同样的逻辑：因为你不知道人们会怎么用，所以花大量时间把它做到完美是没有意义的。更好的做法是先用一种原始的方式把它推出去，看看人们怎么用，然后再在那个使用场景上大力投入。

对。是这样——好吧，稍微借用一下这个比喻——我觉得瞄准的成分是存在的，但那个瞄准要模糊得多。你知道，有点像“我们大致觉得可能会发生什么？”我在这里工作学到很多的一位研究负责人喜欢说，在 OpenAI，你可以对一年多以后的事情进行很好的对话。你知道，未来会发生什么有很多不确定性，但那是一个合适的时间尺度。然后我们也可以对几个月或几周后发生的事进行很好的对话。但中间有一个比较尴尬的灰色地带，就是当你接近一年但又不到一年的时候，很难进行有效的推理，对吧？

所以说到瞄准，我觉得我们要知道的是：我们正在努力构建的是哪些未来？我们在 AI 中面对的很多问题，比如 alignment，都是需要看得很远很远的问题。所以我们在那里是模糊地瞄准。但一旦落到更战术的层面，比如我们要做什么产品，以及人们会怎么使用这个产品？在那个层面，我们更倾向于说：让我们通过实证去发现。

这个说法很好。另外，当人们听到这些时，他们有时会听到你们这样的公司说：我们要 bottoms up，我们要尝试很多东西，我们不会对未来几个月的走向有精确的计划。关键是你们要雇全世界最优秀的人。所以这感觉像是 bottoms-up 能如此成功的一个非常关键的因素。基本上只需要做好监督。

嗯，我刚来的时候，对这里每个人的个人驱动力和自主性感到惊讶，甚至是震惊。所以我觉得 OpenAI 的运作方式——很多人听了这个或者听了播客之后可能会想，我也要在自己的公司推行这套。但你知道，这么说可能有点刺耳，但我觉得确实很少有公司具备这样的人才水准来做到这一点。所以如果你要推行的话，可能需要做一些调整。

好，那我们聊聊 Codex。你负责 Codex 的工作。Codex 进展如何？你能分享什么数据吗？有什么可以透露的吗？另外，不是所有人都清楚 Codex 到底是什么。解释一下 Codex 是什么。

当然，没问题。我很幸运能身处未来，并负责领导 Codex 的产品工作。Codex 是 Open AI 的 coding agent。具体来说，它是一个 IDE 扩展，比如 VS Code 扩展，你可以安装，也可以是一个终端工具。安装之后，你就可以和 Codex 结对工作，回答代码问题、写代码、运行测试、执行代码，以及处理软件开发生命周期中那个庞大的中间环节——也就是把代码写进生产环境。更广泛地说，我们认为 Codex 目前的样子只是一个软件工程队友的起点。

所以，当我们用“队友”这种大词时，我们想象的是：它不仅能写代码，还能在软件开发的早期就参与到构思和规划阶段，然后在更下游的验证、部署和维护代码阶段也参与进来。说得更生动一点，我喜欢这样想象：如果你看今天的 Codex，它有点像一个非常聪明的实习生，但拒绝看 Slack，除非你要求，否则不会查 DataDog 或 Sentry。所以不管它多聪明，如果它不和你一起工作，你能在多大程度上放心让它写代码呢？

对吧？这就是现在人们主要的使用方式：和它结对。但我们希望达到一个状态：它能像你新招的实习生一样工作，你不仅让它写代码，还让它参与整个周期。

所以你知道，即使它们第一次没有做对，最终也能够通过迭代达到目标。我对于不看 Slack 和 DataDog 这一点的理解是，它不会被分散注意力，而是始终保持专注，一直处于心流状态。但我明白你的意思，它确实无法掌握所有正在发生的事情的全貌。而且这不仅适用于它执行任务的时候，再者，如果你想想最优秀的人类队友，你并不会去告诉他们该做什么，对吧？也许在你刚雇佣他们的时候，你会开几次会，然后逐渐了解到，好吧，这些提示对这个队友有效，那些无效，对吧？

这就是与这个人沟通的方式。然后最终你会给他们一些入门任务，委派几项工作。但后来你最终只会说，嘿，很好，你和这群人一起负责代码库的这个区域。你甚至也可以自由地和代码库其他部分的同事合作。然后你告诉我你认为该做什么，对吧？所以，我们认为这就是主动性，而 Codex 的主要目标之一就是实现这种主动性。我认为这对于实现 OpenAI 的使命——将 AGI 的益处带给全人类——至关重要。你知道吗，我今天喜欢开玩笑说，AI 产品——这只能算半个玩笑——其实非常难用，因为你必须非常仔细地思考它什么时候能帮到你。

而如果你没有主动提示模型来帮你，它很可能在那个时刻帮不到你。如果你想想现在普通用户一天会提示 AI 多少次，大概也就十几次。但如果你想人们本可以从一个真正智能的实体那里获得多少次帮助，那应该是每天数千次。因此，Codex 的一大目标就是弄清楚，一个真正能默认提供帮助的队友型 agent 应该是什么样子的。

当人们想到 Cursor 甚至 Cloud Code 时，会觉得它们是帮你写代码、自动补全代码、或许还能做一些 agentic 工作的 IDE。但我从你这里听到的愿景似乎不同，它是一个队友。就像一个远程队友，为你写代码，你可以和它交流，吩咐它做事。而且它也具备 IDE 自动补全之类的功能。这是否是你们看待 Codex 的一种差异化之处？

这基本上是说，如果你是一个开发者，正试图完成某件事，我们希望你的感觉就像是拥有了超能力，能够以快得多的速度推进。但我们并不认为，为了获得这些好处，你就得一直坐在那里琢磨，此刻我该如何调用 AI 来做这件事。我们希望你能够将它无缝接入你的工作方式，让它自动开始做事，而无需你刻意思考。

好的，我有很多相关问题想问，但先问一句，目前进展如何？你能分享一些关于 Codex 表现的数据或数字吗？

是的，自八月 GPT-5 发布以来，Codex 的增长绝对是爆发式的。嗯，说实话，关于我们如何解锁这种增长，确实有一些有趣的产品洞察可以聊，如果你感兴趣的话。但再说一遍，我们上次分享的观点是，自八月以来我们已经增长了超过 10 倍。事实上，自那以来已经翻了大约 20 倍。此外，Codex 模型现在每周要处理数万亿 token，它基本上是我们服务量最大的编程模型。我们看到的一个非常酷的事情是，我们决定组建 Codex 团队的方式，是建立一个产品与研究紧密结合的团队，双方围绕模型和 harness 共同迭代。

事实证明，这让你能做更多事情，尝试更多关于它们如何协同工作的实验。因此，我们之前只是在训练这些模型，用于我们自己非常重视的第一方 harness。而直到最近，我们开始看到其他主要的 API 编程客户也开始采用这些模型。所以我们已经到了这样一个阶段：Codex 模型实际上也是 API 中服务量最大的编程模型。

你刚才暗示了是什么解锁了这种增长。我非常想听听。感觉在那之前，我不知道，也许是在你加入团队之前，Cloud Code 简直是所向披靡。所有人都依赖 Cloud Code。它绝对是最好的编程方式。然后 Codex 突然出现了。我记得 Karpathy 发推文说，他从未见过这样的模型。我记得推文说的是，他遇到了一些极其棘手的 bug，花了好几个小时都搞不定，其他工具都解决不了。他交给 Codex，让它运行一个小时，它就解决了。你们做了什么？

我们在 OpenAI 有着非常坚定的使命，基本上就是要构建 AGI。所以我们花了很多心思思考，如何设计产品才能让它具备可扩展性，对吧？你知道，前面我提到，如果你是一个工程师，你应该每天从 AI 那里获得数千次帮助，对吧？所以我们在推出 Codex 的第一个版本 Codex Cloud 时，就深入思考了实现这一目标的基本要素。它基本上是一个拥有自己计算机、运行在云端的产品，你可以把任务委派给它。你知道，最酷的一点是你可以并行运行很多很多任务。

但我们看到的一些挑战在于，它的设置有点困难，无论是环境配置，比如给模型提供验证其更改所需的工具，还是学习如何以那种方式提示。对此我的比喻是回到这个队友的类比。这就像你雇佣了一个队友，但你永远不被允许和他们通话，只能随着时间异步地来回沟通。对某些队友来说这没问题。而且最终你其实希望大部分时间都这样工作，所以这仍然是未来方向。但一开始很难采用。所以我们仍然有这样的愿景，那就是我们试图让你达到的状态：一个你委派任务后能够主动行动的队友。

我们看到这方面在增长，但关键突破口其实在于，你首先需要用一种更直观、更容易获得价值的方式打动用户。所以今天大多数用户发现 Codex 的方式是，他们要么下载一个 IDE 插件，要么在 CLI 中运行它，然后这个 agent 就在你的电脑上与你交互式地协作。而且它在 sandbox 中运行，这其实是一项非常酷的技术，有助于保障安全。但它可以访问所有那些依赖。所以如果 agent 需要做什么，比如运行一个命令，它可以在 sandbox 内完成，我们不必设置任何环境。

如果某个命令在 sandbox 里运行不了，它可以直接问你。这样你就能与模型形成非常紧密的反馈循环。然后随着时间的推移，我们团队的工作就是帮助将这个反馈循环转化为一种副产品——随着你使用产品进行配置，日后你就能把任务委派给它了。再说一次，还是那个比喻，如果你雇佣了一个队友，让他们干活，却只给他们一台从商店买来的全新电脑，他们很难开展工作，对吧？

但如果你和它们并肩工作，你可以随口说：“哦，你登录这个服务没有密码。这是这个服务的密码。没事，放心运行这条命令。”这样它们就更容易在你不在的情况下连续工作好几个小时。所以，我的理解是，Codex 的最初版本几乎有点过于超前了。它就像是云端的远程异步编程代理。而你们做的是，好吧，让我们稍微回退一点。把它集成进工程师已经在使用的 IDE 和本地环境中，帮助他们逐步进入这个新世界。

完全正确。这还挺有意思的，因为我们在 OpenAI 非常注重 dogfooding——也就是使用我们自己的产品。所以，Codex 这一整年都在加速 OpenAI 的发展，而且云端产品对公司来说也是一个巨大的加速器。只不过，在这个方面，我们从 dogfooding 中得到的信号，和从整个市场得到的信号有些不同。因为在 OpenAI，我们整天都在训练推理模型，所以我们已经非常习惯这种 prompting，比如先想清楚，然后大规模并行运行，过段时间再异步返回结果。所以现在，我们在开发时仍然从内部使用中获得大量信号，但我们也非常清楚不同受众使用产品的方式各不相同。

这真的很有趣。就像是活在未来，但也许不要活得太超前。我能理解 OpenAI 的每个人都活得很超前，有时候那并不适用于所有人。

是啊。那光是智能、训练数据这些，还有别的什么帮助 Codex 加速了实际编程能力吗？是更好、更干净的数据吗？还是单纯是模型进步了？有没有其他真正推动它加速的因素？

有的，这里涉及几个因素。你刚才提到了模型，模型确实进步了很多。实际上，就在上周三，我们发布了 GPT-5.1 Codex Max。一个非常名副其实的名字。它很棒，一方面，对于任何你之前用 GPT-5.1 Codex 完成的任务，它完成速度大约快了 30%。另一方面，它还解锁了大量的智能。所以如果你使用我们更高的推理级别，它就更聪明了。你提到的那条推文，就是 Karpathy 说的“嘿，把你最棘手的 bug 交给它”，显然现在市场上有很多事情在发生，但 Codex Max 绝对接过了处理最难 bug 这一棒。

所以，这非常酷。不过我想说，我们对此的一些思考正在从“只想着模型，训练出最好的模型”稍微演变，去真正思考一个 agent 整体到底是什么。我不想精确地定义 agent，但至少在我们看来，它的技术栈是这样的：你有一个模型，一个非常聪明的推理模型，很擅长做好某种特定任务，这个我们可以后面细说如何做到。但实际上，接下来我们需要通过 API 把这个模型接入到一个 harness 中，而这两者也扮演着非常重要的角色。

比如，我们非常自豪的一点是你能让 GPT-5.1 Codex Max 工作很长时间。这不算常见，但你可以设置它这么做，或者这种情况也可能发生。现在我们会经常听到有人说：“是啊，它跑了一整晚。”或者它跑了 24 小时。一个模型要连续工作那么长时间，肯定会超出它的上下文窗口。所以我们有一个解决方案，叫做 compaction。这个 compaction 实际上是一个使用了这整个技术栈全部三层的功能。首先，模型本身要有 compaction 的概念，知道“当我开始接近上下文窗口上限时，我可能会被要求准备好在一个新的上下文窗口里继续运行”。

然后在 API 层，你需要一个理解这个概念、有一个可以调用的端点来完成这种切换的 API。在 harness 层，你需要一个能准备好 payload 来完成这个操作的 harness。所以，推出这个 compaction 功能，让它现在对所有使用 Codex 的人都成为可能，实际上意味着要跨这三个层面协同工作，而且我认为这种情况会越来越多。另一个可能被低估的方面是，如果你想想市面上所有不同的编程产品，它们都有非常不同的工具 harness，对模型应该如何工作有着非常不同的看法。

所以，如果你想训练一个模型擅长所有不同的运行方式——比如，你可能强烈认为它应该用语义搜索来工作，或者你认为它应该调用 spoke tools，或者像我们的情况，你强烈认为它应该直接用 shell、在终端里工作——如果你只针对其中一种场景去优化，你能走得快得多。所以我们构建 Codex 的方式就是让它直接用 shell，但为了让它更安全、更可靠，我们有一个沙箱，让模型习惯在里面运行。所以，回到你的问题，我认为最大的加速器之一就是我们在并行构建这三个东西，不断调试每一个，并且让产品和研究团队紧密配合，持续实验它们如何协同工作。

你觉得在这个领域要怎么赢？你认为这会一直是一场各家模型不断互相超越的竞赛吗？有没有可能出现某一家直接甩开所有人、别人再也追不上的局面？有没有一条明确的路通向“我们赢了”？

还是那句话，回到“打造一个队友”这个理念上。不只是一个参与团队规划和排期的队友，不只是一个认真测试代码、帮你维护和部署代码的队友，而是一个甚至能帮你发日历邀请、调整站会时间之类事情的队友。在我看来，如果我们假设每天或每周都会有研究实验室发布什么惊人的新能力，那我们人类是不可能跟得上、学会使用所有这些技术的。所以我觉得我们需要进入这样一个世界：你拥有一个 AI 队友，或者说一个超级助理，你跟它说话，它就知道怎么主动帮到你。

所以你不需要去读最新的使用技巧，你把它接进来，它就能提供帮助。所以，这就是我认为我们在构建的东西的形态，而且如果我们能做到，这会是一个非常有粘性、能赢的产品。所以，至少在我脑子里，我们构建的东西大概是这样的——也许一个有趣的话题是，聊天是不是 AI 的正确交互界面？我认为当你不知道自己该用它来做什么的时候，聊天是一个很好的界面。就像如果我想象自己在 Teams 或者 Slack 里和一个队友交流，聊天就挺好。

我可以问任何我想问的，对吧？这有点像是最底层的共性。你可以和超级助手聊任何话题，不管是编程还是别的。而如果你是某个特定领域的职能专家，比如编程，你就可以调出一个 GUI，深入进去查看代码、和代码打交道。所以我觉得，OpenAI 需要打造的产品理念是：你有一个聊天工具，ChatGPT，它无处不在，人人可用。你甚至会在工作之外开始使用它，对吧？就是让它帮你。你会非常习惯被 AI 加速这件事。然后当你开始工作时，就会很自然地觉得，没错，我就该问它这个，我不需要了解所有连接器或者各种不同的功能。我只需要向它求助，它就会在这个时刻把最能帮到我的方式呈现出来。甚至有时候我没求助，它也会主动插话。所以在我看来，如果我们能做到这一点，那就是我们真正打造出制胜产品的方式。

这太有意思了，因为在我和 Nick Charney——ChatGPT 的负责人——聊天时，他说 ChatGPT 最初的名字好像就是超级助手之类的。

对。

有趣的是，那边有一种超级助手的思路，然后这边又有一种 Codex 的思路。这几乎就像是 B2C 版本和 B2B 版本。而我听到的意思是，好吧，你们从编程和构建开始，然后它再帮你做其他所有事情，安排会议，我不知道，也许是在 Slack 里发帖、发设计稿之类的。我不知道。这意思是不是说，在某种程度上，这就是 ChatGPT 的商业版？还是说另有其他方向？

是的，你知道，我们现在进入的是一年时间维度的讨论。其中很多事情可能更早发生，但如果按模糊程度来说，我觉得我们现在处于一年期这个节点。所以我可以给你一个判断和一个可能的路径，但具体怎么发生，谁知道呢。基本上，如果我们要打造超级助手，它必须能做事，对吧？我们会拥有一个模型，它能对你的现实世界产生影响、做各种事情。而我认为过去一年左右我们学到的一点是，模型要做事，如果它们能使用计算机，效果会好得多。对吧？

好的。

所以现在我们想，"好吧，我们需要一个能使用计算机的超级助手。"对吧？或者说很多台计算机。那现在问题来了，好吧，它该怎么使用计算机呢？对吧？使用计算机的方式有很多。你可以试着破解 OS，用 accessibility API。也许简单一点的是点击鼠标。但这有点慢，而且有时候不可预测。另一种方式，事实证明，模型使用计算机的最佳方式就是直接写代码。对吧？所以我们逐渐得出这样一个想法：如果你想构建任何 agent，也许你应该先构建一个编程 agent。

而对用户来说，非技术用户甚至可能不会意识到自己在用一个编程 agent，就像没人会去想自己是不是在用互联网一样。大家只会想，"Wi-Fi 开了吗？"对吧？所以我觉得，我们现在做 Codex，就是在打造一个软件工程队友，而在这个过程中，我们其实在构建一个能通过写代码来使用计算机的 agent。所以我们已经看到了一些这方面的需求。虽然还很早期，但我们开始看到有人用 Codex 来做与编程相关的产品用途。

随着这发展下去，我想我们自然会意识到，"哦，原来如果有能用代码解决的问题，我们就应该一直让 agent 写代码来解决"，即使你在做财务分析，对吧？也许也可以写点代码来做。所以，你刚才问，这是不是超级助手这款产品的两端，对吧？ChatGPT 的两端。在我看来，编程只是任何 agent——包括 ChatGPT——的核心能力之一。所以我们认为我们真正在构建的就是这种能力。

但 agent 写代码有一个非常酷的地方，就是你可以导入代码。代码是可组合的、可互操作的。对吧？因为对 agent 的一种非常简化的看法是，给它一台计算机，它就会点点鼠标、到处转转。但你知道，那是未来，而如何到达那里却很难找到路径，因为构建 agent 面临的很多问题不在于 agent 能不能做，而更多在于我们如何帮助 agent 理解它所处的工作环境，以及使用它的团队，对吧？团队可能有自己的做事方式，有规范指南。

他们可能希望某些事情上 agent 能做什么、不能做什么是有确定性保证的。或者他们希望 agent 能理解某些细节。举个例子，如果我们在看一个崩溃报告工具，要给它接一个连接器，每个子团队可能对如何分析崩溃都有自己的 meta prompt。对吧？所以我们就面临这样一个情况：没错，我们有一个 agent 坐在计算机前，但我们需要让它对团队或用户来说是可配置的，对吧？agent 经常做的那些事情，我们可能只想把它内化为 agent 的一种能力，让它直接掌握。

所以我觉得我们最终会落到你说的那种可泛化的形态：一个 agent 可以为自己想做的任何事情写脚本。但我认为这里真正关键的部分是，我们能不能做到：agent 经常做的、或者做得好的每一件事，我们都能记住并存储下来，这样 agent 就不需要再为这件事写一遍脚本了，对吧？或者比如说，如果我刚加入一个团队，而你已经在同一个团队了，我就可以直接用 agent 已经写好的那些脚本。

对，就好像如果这是咱们的队友，它就能把跟公司其他人一起工作中学到的东西分享出来。这个比喻很合理。

是的。

感觉你属于 Karpathy 那个阵营，认为现在的 agent 还不太行，大多只是 slop，也许未来会很厉害。你有同感吗？

我觉得……我觉得编程 agent 还是挺不错的。我觉得……是的，没错。

嗯。

然后我觉得，编程之外的 agent，现在仍然非常早期。你知道，这只是我的观点，但我认为一旦它们能以可组合的方式使用代码，它们会变得好得多。

嗯。

这其实就是为软件工程师做产品时比较有趣的地方。我在之前的经历里，很多时候也是为软件工程师做产品，他们真的是一群特别有趣的受众，因为你知道，他们也喜欢为自己做东西，而且在思考如何使用技术方面，他们往往比我们更有创意。所以通过为软件工程师做产品，你能观察到大量涌现的行为，以及你应该做、应该做到产品里的东西。

我喜欢你这么说，因为很多为工程师做产品的人其实很恼火，因为工程师总是爱抱怨。他们会说，啊，这太烂了，你们为什么做成这样？

我很欣赏你的热情，但我想这可能是因为你在为工程师打造一款极其出色的工具，它真的能解决问题，而且能直接帮他们写代码。

顺着这个思路，人们总是在讨论工作会变成什么样、编程会怎样、是否还需要学编程之类的问题。显然，按你的描述，它是一个队友。它会与你协作，让你变得更像超人。它不会取代你。对于拥有这种超级智能的工程队友，你怎么看它对工程领域的影响？

我认为这有两面性，但我们刚才聊的是，也许每个 agent 都应该使用代码，都应该是一个编程 agent。而在我看来，这只是更宏大理念中的一小部分——就是说，随着代码变得越来越无处不在。其实哪怕在 AI 出现之前，你也可以说代码已经无处不在了，对吧？随着代码进一步普及，它实际上会被用于更多用途。因此，具备这种能力的人将会面临巨大的需求。这是我的看法。

我认为这是一个相当复杂的话题。我们内部也经常讨论，而且需要看看事态如何发展。但作为一个在这个领域打造产品的团队，我们基本上能做的就是始终思考：我们要如何打造工具，才能让人感觉我们在最大程度地加速人的能力？而不是做一个工具，反而让人类更不清楚自己该做什么。对吧？

比如说，举个眼前的例子：如今当你与一个编程 agent 协作时，它会写大量代码，但对许多软件工程师来说，写代码其实是软件开发中最有趣的部分之一。结果到头来你却变成了审阅 AI 代码的人。对吧？而对许多软件工程师来说，那往往是工作中较无趣的部分。

所以我其实觉得，这种现象体现在无数微观决策中。作为产品团队，我们一直在思考：好的，我们怎么让这件事变得更有趣？怎么让你感觉更有掌控力？哪里做得不够好？我认为，审阅 agent 写的代码就是目前一个比较无趣的环节。于是我就想，我们能做些什么来改善？

嗯，我们可以推出代码审查功能，帮助你对 AI 写的代码更有信心。好的，这很酷。另外，我们也可以让 agent 更好地验证自己的工作。这甚至会细化到非常微观的决策。比如，如果你要让 agent 具备验证工作的能力，假设你现在用的是 Codex Web，你会看到一个面板展示 agent 完成的工作。你第一眼看到的是什么？是 diff，还是代码运行后的图像预览？

对吧？我觉得如果你从“如何赋能人类”的角度思考，如何让他们感觉自己的效率被最大限度地提升？那你显然应该先看到图像，对吧？除非 AI 已经审阅过，现在轮到你把关，否则你不应该在还没看到图像的情况下就去审阅代码。

之前我在播客里采访过 Cursor 的 CEO Michael Turalda，他对我们走向“超越代码”的某种未来有过类似的愿景。我也看到一种叫做 spec driven development 的兴起，就是你只需写 spec，然后 AI 帮你写代码，这样你就开始在更高的抽象层次上工作。你如何看待这个趋势？工程师是否将不必亲自写代码或看代码，而我们会聚焦于更高层次的抽象？

是的，我认为抽象层次一直在不断演进，而且今天其实已经有所体现。对吧？现在的编程 agent 大多还是 prompt to patch 的模式。但我们开始看到有人在做 spec driven development 或者 plan driven development。实际上，当人们问“如何让 Codex 处理非常长的任务”时，一种方法就是先与它协作写一个 plan.md，一个作为计划的 markdown 文件。等你满意了，再让它去执行。如果这个计划包含可验证的步骤，它就能工作更长时间。

所以我们确实看到了这种趋势。我觉得 spec driven development 是个有趣的想法。但我还不确定它最终会不会成为主流，因为很多人也不喜欢写 spec。不过，有些人可能会以这种方式工作，这似乎是合理的。

不过，开个玩笑，如果你想想现在许多团队的工作方式，他们通常不一定有 spec，但团队自驱力很强，事情自然就完成了。所以几乎可以说是——这是我临时想的，所以名字不太好——chatter driven development。就是各种事情在社交媒体上、在团队沟通工具里自然发生，结果代码就被写出来并部署了。对吧？

所以，我觉得我更倾向于这种方式——我甚至不一定想写 spec。有时候我只在喜欢写 spec 的时候才写。对吧？其他时候我可能只想说：嘿，这是客服渠道，告诉我有什么值得关注的信息；但如果只是个小 bug，直接修掉就好。我不想为此写一份规范，

我有时会跟人分享一个假想的未来场景，带点挑衅意味：在一个真正拥有出色 agent 的世界里，个体创业者会是什么样子？嗯，一个挺荒唐的设想是，它其实是一款手机应用。智能体要做的每件事都以竖屏视频的形式出现在你手机上。如果你觉得某个想法不好，可以向左滑；如果觉得好，就向右滑。如果你想在滑动前对这个想法提反馈，可以长按并对着手机说话。

在这个世界里，你的工作基本上就是把这款应用接入每一个信号系统、每一个记录系统，然后你就可以坐下来划手机了。

我不知道怎么说，但我太喜欢这个设想了。所以这就是 Tinder 遇上 TikTok 再遇上 Codex。挺荒唐的。

不，这很棒。所以这个设想的核心是，这个 agent 在观察你、倾听你，关注市场和你的用户，然后它会说：嗯，我听到点事情，我应该做点什么。它就像一个主动的工程师，直接告诉你：来，我们该做这个功能，或者修这个问题。没错。

我觉得这是个很好的想法。以最低成本的方式与你沟通。

没错，这就像是我们现代人的沟通方式。

对，左滑右滑，竖屏信息流。然后还有 Sora 视频。好吧，我明白这些东西是怎么串起来的了。我懂了。

是的，澄清一下，我们并没有在做这个产品，但这是个有趣的设想。

我的意思是，从这个例子中你能看到，它正在做的一件事就是消费外部信号，对吧？我觉得另一件非常有趣的事是，如果我们想想迄今为止最成功的 AI 产品是什么？我会说——其实挺有意思的，完全不是为了混淆视听——我们第一次在 OpenAI 使用 Codex 这个品牌名时，它其实指的是驱动 GitHub Copilot 的那个模型。

这大概是很多年前的事了。所以我们最近决定重新启用那个品牌，因为它实在太好了。Codex，代码执行。但我实际上认为，IDE 里的自动补全可能是当今最成功的 AI 产品之一。它的部分魔力在于，当你需要时，它能非常快速地浮现出帮助你的点子。当它对了，你的效率就会提升；当它错了，也不会那么烦人。确实可能有点烦，但没那么烦。对吧？于是你就能创建这种混合主动的系统，它能根据你正在尝试做的事进行情境化的响应。所以在我看来，这对正在建设的 OpenAI 来说是一件非常有趣的事。

比如，当我想到推出一款浏览器——我们确实用 Atlas 做了这件事——我觉得，我们能做的一件非常有趣的事，就是在你度过一天的过程中，情境化地浮现出我们能帮到你的方式。对吧？于是我们就突破了那种仅限于看代码或者仅限于终端的局面，进入到这样一种理念："嘿，一个真正的队友处理的远不止代码，对吧？他们还要处理很多网页内容。"所以，你知道，我们怎么在这方面帮到你呢？

天啊，这里面可讲的太多了。我喜欢这个方向。好的，浏览器上的网页自动补全，这太有意思了。就像是，在你浏览网页、度过一天的时候，我们可以帮到你所有这些事。我想聊聊 Atlas，等会儿再回来谈这个。Codex、代码执行，我之前不知道还有这层联系，真的很巧妙。我现在明白了。对了，还有这个"chatter"。什么是 chatter driven development？啊，不不，这主意真的很棒。但这让我想起，我之前请过 Block 的 CTO John G Donji 来播客，他们有一款叫 Goose 的产品，是他们内部的 agent 工具。

他提到 Block 的一位工程师让 Goose 看着他的屏幕、听每一场会议，然后主动去做他可能想做的事。比如提交一个 PR、发一封邮件、起草一条 Slack 消息。所以他做的基本上就是你描述的那种事，只是还处于非常早期的阶段。

是啊，这太有意思了。而且我敢打赌，如果我们去问他们，这种生产力的瓶颈是什么，他们有没有说是什么？

嗯，可能就是得去查看，确保这是正确的做法。

对。所以我们现在也观察到这一点。比如我们给 Codex 做了 Slack 集成。人们很喜欢——如果有什么需要快速处理的事，他们就会 at 提到 Codex，比如"你觉得这个 bug 是怎么回事？"对吧？不一定非得是工程师。甚至数据科学家也经常大量用 Codex 来回答问题，比如"你觉得这个指标为什么变了？发生了什么？"这些问题，你能立刻在 Slack 里得到答案，这太棒了，非常有用。但当它开始写代码时，你就得回去看代码了，对吧？所以我认为目前真正的瓶颈在于验证代码是否能运行，以及撰写代码审查。因此在我看来，如果我们想要达到你刚才说的那位朋友所处的世界，我们真的需要想办法让人们把他们的 coding agent 配置得更加自主，尤其是在工作的后期阶段。

说得通。就像你说的，写代码——我以前也是工程师，做了十年工程师。写代码真的很有趣，沉浸在心流里、搭建、架构、测试都非常有趣。但看别人的代码就没那么有趣了，还得逐一检查，万一它做了什么蠢事把生产环境搞崩了，责任还在你。现在构建变得越来越容易了，我从那些真正走在前沿的公司那里听到的始终是，瓶颈现在变成了弄清楚要构建什么，然后在最后——好了，我们有这 100 个 PR 要审查，谁来逐一过一遍？对吧。

没错。本期节目由 Jira Product Discovery 赞助。构建产品最难的部分其实不是构建产品本身，而是其他所有事。是证明这项工作的价值、管理利益相关者、试图提前规划。大多数团队花在学习上的时间还不如花在被动反应上的时间多：追赶进度更新、为路线图辩护、不断扫清障碍以维持运转。Jira Product Discovery 让你重新掌控局面。通过 Jira Product Discovery，你可以捕捉洞察并优先处理高影响力的想法。

它很灵活，能适应团队的工作方式，帮助你建立推动共识而非引发质疑的路线图。而且由于它构建在 Jira 之上，你可以在一个地方追踪从战略到交付的所有想法。少些追赶，多些思考、学习和构建正确事物的时间。免费获取 Jira Product Discovery，请访问 atlassian.com/lenny。没错，就是 atlassian.com/lenny。

Codex 对你作为产品人员、作为 PM 的工作方式产生了什么影响？工程方面受到的影响很清楚——代码能自动为你写好。它对你以及 OpenAI 的 PM 们的工作方式有什么改变？

是的，我的意思是，我觉得主要是感觉自己更有能力了。我一直算是偏技术型的 PM。尤其是在为工程师做产品时，我觉得有必要亲自 dogfood 这个产品。但除此之外，我只是觉得作为 PM 能做很多很多更多的事。你知道，Scott Belsky 谈到过 compressing the talent stack 这个概念。我不确定我是不是表述对了。但基本意思就是，也许这些角色之间的边界不再像以前那么必要了，因为人们能做的事情变多了。

每当有人能多做一点，你就能跳过一层沟通边界，让团队的效率提高那么多。对吧？所以我觉得，现在我们已经在很多职能中看到了这一点，不过既然你专门问到产品，你知道，现在回答问题变得容易太多了。你直接问 Codex 对这件事的看法就行。很多 PM 类型的工作，比如理解发生了什么变化，同样，直接让 Codex 帮忙就行。原型设计往往比写需求文档还快。这是很多人已经谈过的事。我觉得有一点不算特别意外，但稍微有点意外的是，我们打造 Codex 主要是为了写要部署到生产环境的代码，但实际上现在我们看到大量用 Codex 写的用完即弃的代码。

这有点像回到了那种 ubiquitous code 的想法。所以你会看到，有人想做分析。比如我想理解某件事，就会说："好吧，给 Codex 一堆数据，然后让它为这个数据构建一个交互式的数据查看器。"对吧？这在以前太麻烦了，但现在完全值得花点时间让 agent 去跑一趟。同样地，我在我们的设计团队看到一些很酷的原型，比如有位设计师想做动画。就是 Codex 里的那个硬币动画。正常来说，写这个动画太麻烦了，所以他们就 vibe coded 了一个动画编辑器。

然后用这个动画编辑器来制作动画，最后再把它提交到代码仓库里。实际上，我们的设计师在这方面也有很大的效率提升，说到 compressing the talent stack，我觉得我们的设计师很有 PM 的特质。所以他们做了大量的产品工作，而且实际上他们用 vibe coding 的方式做了一个完整的 Codex app 的 side prototype。

因此，我们讨论事情的方式通常是先快速碰个头，因为有太多事情在同时进行。然后设计师会去思考这个功能应该如何运作，但不会反复讨论，而是直接 vibe code 一个原型，在他们独立的原型环境里做出来。我们会试用，如果觉得不错，他们就会把那个原型 vibe code——或者说 vibe engineer——成一个实际的 PR 来合入代码库。接着根据他们对代码库的熟悉程度——比如 Codex 的 UI 是用 Rust 写的，这就有一定难度——他们可能会自己合入，或者做到差不多再由工程师帮忙把 PR 合入。

你知道，我们最近发布了 Sora 的 Android 应用。这其实是最令人惊叹的加速案例之一，因为 Codex 在 OpenAI 内部的使用量本来就非常高，而且这一整年还在持续增长，现在基本上所有技术人员都在用它。而且不仅是使用强度在提升，大家充分利用 coding agent 的经验和技巧也大幅增长。就拿 Sora Android 应用来说，这是一个全新的应用，我们 18 天就搭出来了，从零开始做到向员工发布。然后 10 天后，也就是总共 28 天，我们就向公众 GA 了。这完全是在 Codex 的帮助下完成的，速度相当惊人。

我觉得这有点像是——我不想说那是简单模式——但如果你是做多平台软件的公司，Codex 确实特别擅长一件事：就是你已经搞定了底层的 API 或系统。让 Codex 去做移植工作会非常有效，因为它有现成的代码可以参考。所以那个团队的工程师基本上就是让 Codex 去看 iOS 应用的代码，生成需要完成的工作计划，然后执行这些计划。它基本上是同时对照 iOS 和 Android 两边的代码。所以基本上就是两周向员工发布，总共四周。快得离谱。

更疯狂的是，它直接冲到了 App Store 的第一名。我简直无法理解。好吧，所以——

对，想象一下，App Store 排名第一的应用，只动用了寥寥几个工程师，大概就两三个吧，在短短几周内完成。是的，这太荒唐了。

所以，这是一个非常有趣的加速案例。另一个例子是 Atlas，我记得 Ben 做过一期播客，讲了 Atlas 的引擎，分享了一些我们是怎么搭建它的。你知道，Atlas 其实是一款浏览器，对吧？而做浏览器是非常难的。所以我们不得不搭建很多复杂的系统才能实现。基本上，那个团队现在已经是 Codex 的重度用户了。而且已经到了这样一个程度——我们跟他们聊过这个话题，因为很多工程师都是我之前在创业公司一起共事过的人。他们会说，以前这种活需要两到三个工程师干两到三周，现在一个工程师一周就能搞定。

所以那边的效率提升也非常巨大。而且挺酷的是，我们先把 Atlas 发布了 Mac 版，现在在做 Windows 版。所以那个团队现在正在熟悉 Windows 环境，同时也在帮我们优化 Codex 在 Windows 上的表现。这确实还处在比较早期的阶段。比如我们上周发布的模型，才是第一个原生理解 PowerShell 的模型。因为 PowerShell 是 Windows 上原生的 shell 语言。所以，能看到全公司都被 Codex 加速，这真的很棒——

而且最明显的是研究环节，比如提升我们训练模型的速度和质量，甚至还包括设计——我们刚才聊到的——以及市场。实际上，我们现在已经到了这样一个阶段：我的产品市场同事经常直接在 Slack 里修改文案字符串，或者直接通过 Slack 更新文档。这些都是很惊人的例子。

你们正生活在技术可能性的最前沿，而其他公司未来也会这样工作。

刚刚发布就冲到 App Store 第一，而且广受喜爱，至少在那一周里可以说是席卷了全世界。你说是 28 天做出来的，18 天就让核心功能跑起来了？

对，就是 18 天的时候我们有了一个员工在试用的版本，然后 10 天后就对外发布了。你说只动用了几个工程师。对，两三个吧。

然后 Atlas，你说只用了一周就搭好了？

不不不。Atlas 不是整个项目只花了一周，但它确实是一个非常扎实的项目。

我跟 Atlas 团队的一位工程师聊过，问他们到底用 Codex 做什么。他说基本上我们所有事都用 Codex。我说好吧，那你们怎么衡量这种加速效果呢？然后我得到的回答基本上是：以前需要两到三个工程师干两到三周，现在一个工程师一周搞定。

你觉得最终这会变成非工程师也能做的事吗？就是说，必须要是工程师来搭建吗？能不能由 PM 或者设计师来做？

我觉得我们肯定会走到那个阶段，到时候边界会变得有点模糊。我认为你还是需要一个理解所做产品细节的人，但具体需要理解哪些细节会不断演变。就像现在写 Swift 的人不需要懂汇编一样。世界上有一小部分人——可能不止一小部分——懂汇编，这很重要，但那是大多数公司不需要配备的专门职能。所以，我觉得我们会自然地看到抽象层不断增加。而且酷的是，我们现在正进入语言抽象层，也就是自然语言。自然语言本身非常灵活。工程师可以谈论计划，可以谈论技术规格，也可以只谈论一个产品或一个想法。所以我觉得我们也可以开始往更高的抽象层走。但我认为这会是一个渐进的过程。我不觉得会突然变成没人写任何代码、只有需求文档的情况。

我觉得更像是：我们先配置好 coding agent，让它很擅长预览构建结果或者运行测试。也许这是第一阶段，大多数人已经做到这一点了。然后是：现在我们已经配置好，让它能执行构建，能看到自己修改的结果，但我们还没有搭好完善的集成 harness，让它能够——比如在 Atlas 这个项目里——

顺便说一句，我不知道他们到底做了这些没有。我觉得他们已经做了不少，但也许下一阶段就是让它能加载几个示例页面，看看运行效果如何。然后我们就把这个环节也配置好。我觉得至少在相当长一段时间内，还需要由人类来筛选和配置：agent 需要对接哪些连接器、系统或组件。

而且，你知道，未来还会有更大的突破：Codex 会告诉你如何配置它，或者它自己在代码仓库里完成配置。能活在这个时代真是太疯狂了。哇。

我很好奇这类事情的二阶效应，也就是现在搭建东西的速度有多快。这意味着什么？这是否意味着分发变得无比重要？是否意味着想法变得值钱多了？想想这种变化有多快就很有意思。我很好奇你怎么看。

我还是觉得想法不像很多人想的那么值钱。我仍然认为执行非常难，对吧？你可以很快做出一个东西，但你仍然需要把它执行好。它仍然需要有道理，整体上要连贯一致。嗯，是的，而且分发至关重要。是啊。感觉就是现在其他所有事情都变得更重要了。所有不属于“搭建”这个环节的事情——比如想出点子、推向市场、盈利，诸如此类。

是的。我觉得我们可能曾经处于一个奇怪的临时阶段，你知道，有一段时间，做产品太难了，所以你只要特别擅长做产品就行，至于你是否深入了解某个特定客户，可能并不重要。嗯，但现在我觉得我们正在进入这样一个阶段：实际上，如果我只能选择掌握一样东西，那我会选择深入理解某个客户面临的问题。对吧？如果我只能带着一项核心能力入场。所以，我认为这最终仍然是最重要的，对吧？就是说，如果你今天创办一家新公司，而且你对客户有着深刻的理解，还掌握着一批目前 AI 工具未能充分服务的客户网络，那我觉得你就稳了。对吧？相反，如果你擅长搭建，比如说，网站，但你并没有特定的客户要服务，那我觉得你的日子会难过得多。

我听你的意思是，看好垂直领域的 AI 创业公司。

是的，我完全同意。你知道，有一种通用型的东西能解决很多问题，然后还有一种，就是我们把演示文稿这件事做得极好，我们对演示文稿问题的理解比任何人都深，我们还会接入你的工作流，以及做所有其他对某个非常具体的问题来说重要的事情。

好的。太不可思议了。说到 Codex 的进展，我猜你们有一堆 eval，还有各种公开的 benchmark。你会看什么指标来告诉自己，好吧，我们进展很不错？我猜不会只看单一指标，但你关注什么？你在努力推动的是什么？有哪一两个 KPI？

我一直在提醒自己的一点是，像 Codex 这样的工具，本质上是一种你会自然而然成为重度用户的工具。对吧？所以，我们可能会不小心把大量时间花在思考那些位于用户采用旅程非常深处的一些功能上。于是，我们最后可能会过度优化那部分。因此，我觉得非常关键的一点是去看你的 D7 留存率。对吧？亲自去试试这个产品。从零开始再注册一遍。嗯，我注册了太多 ChatGPT Pro 账号，就为了最大限度地正确吃自己的狗粮，用 Gmail 注册的，他们每月收我大概 200 美元。我得去报销这些。呃，你知道，我觉得作为用户的体感，以及早期的留存数据，对我们来说仍然极其重要，因为尽管这个品类正在起飞，但我觉得人们使用它们仍处于非常早期的阶段。

嗯，我们做的另一件事——我觉得我们可能是这个领域里最沉迷用户反馈和社交媒体的团队——就是我们中有几个人一直在刷 Reddit 和 Twitter。你知道，那上面既有赞美，也有很多抱怨，但我们会非常认真地对待这些抱怨并加以分析。而且我觉得，同样因为你可以用编程 agent 做很多不同的事情，它往往在很多特定行为上都有点问题。所以，我们其实经常大量监测社交媒体上的氛围。尤其是 Twitter/X，它多少有点炒作性质。而 Reddit 则更负面一点，但实际上更真实。所以，我实际上开始越来越关注人们在 Reddit 上如何讨论 Codex 的使用体验。

呃，这点值得让大家知道。你最常看哪些 subreddit？有 r/Codex 这样的吗？

我的意思是，算法很擅长推送内容，不过 r/Codex 确实存在。好的。我记下了。非常有趣。然后，如果有人在 Twitter 上 @ 你，你也能看到，但效果可能不如在 Reddit 上看到的有用。

嗯，是的，有趣的是，Twitter 上的互动即便公开，也更偏向一对一。而 Reddit 有很好的投票机制，而且可能大部分人还不是机器人。不清楚。所以，你能获得关于什么重要、其他人怎么想的有效信号。

对了，有趣的是 Atlas，我想简要聊聊这个。你们推出了 Atlas。我其实在 Twitter 上说，我试用了 Atlas，然后我不太喜欢纯 AI 的搜索体验。我只是有时候就想用 Google 什么的。就是干等着 AI 给我答案，我会想，我不想这样。而且当时没法切换，所以我就发了条推：“嘿，我要换回去了。我不觉得这是什么很棒的体验。” 我感觉我让 OpenAI 的一些 PM 难过了。然后我看到有人发推说：“好了，我们现在有这个功能了。” 我猜这原本就在计划之中。这大概就是一个例子：我们先发，我们必须发东西。看看人们怎么用，然后再想办法。所以，我想一是，我不知道，这里面有什么值得一提的吗？二是，我很好奇，你们为什么要做一个网页浏览器？

是这样的，我在 Atlas 上工作过一段时间。嗯，我现在不在那个团队了。不过你知道，这里面的叙事脉络，稍微讲点我的故事的话，就是我当时在做一家屏幕共享/结对编程的创业公司。对吧？然后我们加入了 OpenAI。所以当时的想法其实是打造一个上下文感知的桌面助手。我认为这如此重要的原因在于，我觉得你必须把所有上下文都交给助手，然后还得琢磨它怎么能帮到你，这真的很烦人。对吧？所以，如果它能直接理解你正在做的事，那它就能最大程度地加速你的工作。

嗯，所以，你知道，我其实仍然把 Codex 看作一种上下文感知的助手。只是从一个稍微不同的角度切入，比如从编程任务开始。但呃，至少对我个人来说——我不能代表整个产品——部分想法是，很多工作是在网页上完成的，而如果我们能做一个浏览器，那我们就能以一种更加原生的方式为你提供上下文感知。我们不用去 hack 其他桌面软件，那些软件对把内容渲染到无障碍树的支持程度参差不齐。我们也不用依赖截图，截图又慢又不可靠。

相反，我们可以直接进入渲染引擎，对吧？然后提取我们需要的任何信息来帮助你。嗯，还有，我喜欢这样想，你知道，在电子游戏里，比如，不知道你玩过没有，比如说 Halo，对吧？你走到一个物体旁边。我是说，很多游戏都这样。你按……现在我已经很久没玩了。这挺尴尬的。

按下X键，它就会自动做出正确的动作，对吧？我以前就是那种买了每款电子游戏都会去读说明书的人。我还记得第一次读到“情境动作”时，我觉得这是一个特别酷的想法。情境动作的关键在于，我们需要知道你想要做什么。只要掌握一点上下文，我们就能提供帮助。我认为这一点至关重要，因为想想看，假如我们进入了这样一个世界：agent 每天帮你处理成千上万件事。想象一下，如果我们唯一能告知你“帮了你忙”的方式，就是给你发推送通知。

那你一天会收到一千条AI推送，上面写着：“嘿，我做了这件事，你觉得怎么样？”这简直烦死人，对吧？但反过来想，回到软件工程的场景，比如我正在看一个 dashboard，发现某个关键指标下降了。在那一刻，AI 可以去看一眼，然后在我正盯着 dashboard 的时候，直接呈现它对这个指标下降原因的判断，以及可能的修复方案。对吧？这样一来，我更能保持心流状态，也能让 agent 在更多事情上采取行动。所以在我看来，我对我们即将拥有一款浏览器感到兴奋的部分原因在于，这样我们就能获得更多关于“应该在哪些方面提供帮助”的上下文。

用户也能更好地控制他们希望我们看什么内容。就像是在说：“嘿，如果你想让我们对某件事采取行动，你可以在你的 AI 浏览器里打开它；如果不想，那就用你的其他浏览器打开。”对吧？这样就形成了非常清晰的控制权和边界。然后，我们就能打造一种 mixed initiative 的 UX，在恰到好处的时刻向你呈现情境动作，而不是随机地给你发通知。

听下来，Codex 的愿景是成为超级助手。它不只是帮你写代码，而是试图作为队友、作为这种超级队友，在工作上为你做很多事，让你变得更厉害。所以我理解这点。说到这个，Codex 还有其他非工程师的常用场景吗？就是非工程师也能用的方式。我们聊过，比如设计师做原型、搭建东西。还有没有其他非工程师使用 Codex 的出人意料的方式？

其实有很多出人意料的用法，但我认为目前我们看到真正产生实际进展的，大多仍然属于与编码密切相关的领域，或者说偏向技术导向、拥有成熟生态系统的地方。或者，你可能在做数据分析之类的事。我个人预计，随着时间推移，我们会看到越来越多这样的用法。但目前，我们让团队保持高度专注，只聚焦在编码上，因为还有很多工作要做。

对于那些想尝试 Codex 的人来说，它适用于所有类型的代码库吗？它支持什么代码？如果你在用 SAP 之类的东西，你能接入 Codex 并开始搭建吗？最佳切入点大概在哪里？它在哪些地方还没那么厉害？

其实我很高兴你问这个问题，因为尝试 Codex 的最佳方式就是给它最难的任务，这和其他一些编程 agent 略有不同。有些工具你可能会想：“好吧，我先从简单的开始，或者随便 vibe code 点东西，看看喜不喜欢这个工具。”而我们真正想把 Codex 打造成一个专业工具，你可以把最难的问题交给它，让它在你的大型代码库中写出高质量的代码，尽管它现在确实还不完美。所以，如果你要尝试 Codex，应该用你手头的一个真实任务来试，没必要刻意把任务降级成很 trivial 的事。实际上，一个好的例子是：你遇到了一个棘手的 bug，不知道是什么导致的，然后你让 Codex 帮你找出原因，或者实现修复方案。

我喜欢这个回答。直接给它最难的问题。

不过我要说，如果你说：“好吧，但我最难的问题是我需要打造一家新的独角兽企业。”那显然，这还不行。至少现在还不行。所以我觉得应该是给它最难的问题，但仍然是一个具体的问题，对吧？或者是一个任务，先从这里开始测试。然后随着时间推移，你可以学习如何用它处理更宏大的事情。

它支持哪些编程语言？

基本上，我们训练 Codex 的方式决定了我们支持的语言分布，这与这些语言在现实中的使用频率基本一致。所以，除非你在写某种非常冷门的语言，或者某种私有语言，否则它应该都能胜任。

如果是刚入门的人，你能分享一个帮助他们成功上手的小窍门吗？就像如果有人第一次设置 Codex，你能对着他耳语一句建议，帮助他获得很好的体验，你会说什么？

我可能会说：并行尝试几件事。对吧？你可以尝试给它一个难的任务，让它理解代码库，围绕你的想法和它一起制定计划，然后循序渐进地推进。这里的核心思想是，这又像是在和一个新队友建立信任。你不会走到一个新队友面前说：“嘿，做这件事，给你零上下文。”你会先确保他们理解代码库，然后可能就计划和方案达成一致，再让他们一步步去做。对吧？我觉得如果你这样使用 Codex，你自然就会开始理解不同的 prompting 方式，因为它虽然是一个非常强大的 agent 和模型，但 prompt Codex 的方式确实和其他模型有所不同。

再问几个问题。其一，我们稍微聊过这个。随着 AI 写代码越来越多，总有一个问题：我应该学编程吗？我应该花时间做这种事吗？对于那些正在规划职业生涯的人，尤其是对软件工程、计算机科学感兴趣的人，你认为计算机科学中有哪些特定元素是越来越重要、值得深入钻研的？也许有哪些东西不必太担心？你觉得在 AI 越来越成为职场常态的情况下，人们应该在技能上侧重哪些方面？

我觉得可以从几个角度来思考。至少最容易想到的一点就是：做一个实干家。随着 coding agent 越来越强大，哪怕是在校大学生或应届毕业生，他们能做的事情也远超以前。所以我认为你应该充分利用这一点。而且，当我在考虑招聘职业生涯早期的人才时，这绝对是我会关注的一点：他们使用最新工具的产出效率如何？对吧？他们应该非常高效。如果从这个角度来看，实际上他们与资深从业者之间的差距比以前更小了，因为他们现在拥有了这些强大的 coding agent。

Alexander嗯，这是一方面。我想给出的建议是，学什么都行，但一定要确保花时间去做实事，而不是仅仅完成作业。不过另一方面，深入理解什么造就了一个优秀的整体软件系统，仍然非常有价值。所以，我依然认为，扎实的系统工程能力，甚至包括与团队的高效沟通和协作，这些技能都很重要，在未来很长一段时间内仍会继续发挥关键作用。我不认为 AI coding agents 会突然之间就能在没有你参与的情况下构建出完美的系统。

我认为这个过程会渐进得多。比如，我们会先拥有这些 AI coding agents，它们能够验证自己的工作。但 human in the loop 仍然很重要。举个例子，想到一位正在做 Atlas 项目的工程师——既然我们聊到了它——他搭建了一套机制让 Codex 能够验证自己的工作，这本身并不容易，因为 Atlas 产品的特性使然。他的做法是直接给 Codex 发 prompt：“嘿，你为什么没法验证自己的工作？

把它修好。”然后如此循环。所以，在各个阶段，你仍然希望有人类在回路中，帮助配置 coding agent 使其有效运作。因此，你仍然需要具备这方面的推理能力。也许打字快不那么重要了，也不需要精通怎么写——其实也没人会手写 for each 循环之类的，对吧？或者说，你不需要知道如何实现某个具体算法。但你必须能够对不同系统进行推理，理解什么能让软件工程团队高效运转。这是我认为同样非常重要的一点。

然后，也许最后一个角度是，我认为如果你对某个领域的知识前沿有所涉猎，那仍然非常值得深入。部分原因是 agents 在这方面仍然没那么擅长，但还有一部分原因是，我觉得当你试图推进某个具体领域的前沿时，你实际上会被迫去利用 coding agents，用它们来加速你自己的工作流程。

Interviewer当你说身处某个领域的前沿时，能举个例子吗？

AlexanderCodex 写了很多用于管理自身 training runs 的代码，这些都是关键基础设施。我们的节奏很快，所以用 Codex 做 code review 能发现很多错误。它确实发现了一些相当有趣的配置错误。而且，我们开始瞥见未来的雏形：我们甚至开始让 Codex 为自己的 training on call，这非常有趣。

Interviewer这里面有很多可说。等等，为自己的 training on call 是什么意思？

就是说，它正在运行，正在 training，然后发现“哦，出故障了，得有人来处理”。那它是会报警通知人，还是说“我来修这个问题然后重新——”？

Alexander是的，这是我们正在探索的早期想法。但基本思路是，在 training run 期间，会有一堆图表，目前是由人类盯着看的，而且盯着这些图表非常重要。我们管这叫 babysitting。

Interviewer因为 training 非常昂贵，我猜，而且快速推进很重要——

Alexander没错。而且 training run 背后有很多底层系统。所以，某个系统可能宕机，或者某个地方引入了错误。我们可能需要修复它、暂停进程，或者采取各种措施。所以，基本思路是让 Codex 循环运行，评估这些图表随时间的变化，这一想法将使我们能够以高得多的效率开展 training。

Interviewer我太喜欢了。这非常符合我对 agents 未来的设想。Codex 不只是用来写代码的，对吧？它的意义远不止于此。

Alexander是的。

Interviewer好，最后一个问题。既然你在 OpenAI 工作，我忍不住要问问你对 AGI 时间线的看法，以及你觉得我们离 AGI 还有多远。我知道这不是你的研究领域，但有很多观点，很多我不知道，各种时间线。你觉得我们离某种像人类一样的人化版 AI 还有多远？随你怎么理解。

Alexander对我来说，这有点像是我们什么时候能看到加速曲线像这样陡然上升——我也不知道我这边的画面有没有被镜像。我们什么时候能看到 hockey stick？我认为当前的一个限制因素，我是说有很多，但目前一个被低估的限制因素， literally 是人类打字的速度，或者说人类在写 prompts 时的多任务处理速度。你之前也提到过，你可以让 agent 观察你做的所有工作，但如果 agent 不能同时验证自己的工作，那你就仍然受限于你能不能去 review 所有代码，对吧？

所以我的观点是，我们需要打通这些生产力循环，不再让人类必须去写 prompt、必须去手动评估所有工作。如果我们能重构系统，让 agent 默认就有用，那我们就会开始解锁 hockey stick。不幸的是，我不认为这会是一蹴而就的，而是非常取决于你在做什么。比如，我想象明年，如果你是一家初创公司，在做一些新的模块，比如某个新应用，你有可能基于一套技术栈搭建起来，让 agents 在很大程度上自给自足。

但如果你是在 SAP 工作，就像你说的，他们有很多复杂的系统，不可能一夜之间就让 agent 在这些系统里自给自足。他们必须慢慢替换或更新系统，才能让 agent 端到端地处理更多工作。所以，我对这个问题的大概回答，也许是个无聊的回答，是：我认为从明年开始，我们会看到早期采用者的生产力开始 hockey stick。在接下来的几年里，我们会看到越来越大型的公司出现生产力的 hockey stick。

而在那个模糊中间的某个点，这种 hockey stick 效应会回流到 AI 实验室，那时候我们就基本达到了 AGI 的层级。

Interviewer我喜欢这个回答。非常务实，而且这也是我们这个播客经常提到的一点：review AI 做的所有事情所需的时间真的很烦人，也是一个巨大的瓶颈。我很高兴你在做这件事，因为让 coding 更高效是一回事，但最后那一步——确保结果真的靠谱——是另一回事。你觉得这才是限制因素，这非常有意思。这也呼应了你之前的观点：即使 AI 不再进步，只要我们学会更有效地使用它，我们仍有巨大的潜力可以释放。

所以，这是一个非常独特的回答。我从未听过从这个角度来解释什么是最大的突破口。归根结底，竟然是人类去 review AI 为我们所做的全部工作的速度，甚至就是人类的打字速度。嗯，说得太好了。好，Alexander，我们聊了很多内容。有什么我们还没聊到的吗？在进入非常激动人心的 lightning round 之前，你有什么想分享或想再强调一下的吗？

我想说的其中一点是，Codex 团队正在扩张。而且正如我刚才所说，我们仍然在一定程度上受限于人类的思维速度和打字速度。我们正在努力解决这个问题。所以，如果你是一名工程师，或者销售人员，或者我正在招聘产品经理，请联系我们。

我不确定给出联系方式的最好方式是什么，但你们可以去招聘页面，还是他们有你的联系方式？实际上，听众们有你的联系方式吗？免得他们给我发消息说“嘿，我想申请加入 Codex”。

呃，我确实在 lennyrachitsky.com 上有一个联系表单。

我怕这里所有优秀的人都来联系我。

好吧。给我发消息吧，不过就这样，我们可以试试这个。看看效果怎么样。

对，或者另一个可能更简单的方式，我们可以把上面那段剪掉。或者由你决定。但呃，是的，或者我会说你可以给我们发私信。比如，我是 Twitter 上的 amber rico，如果你有兴趣加入团队，就联系我。

对很多人来说，这是一份梦寐以求的工作。有什么迹象表明他们……我不知道，有什么办法可以稍微筛选一下人选，免得他们挤爆你的收件箱？

所以，具体来说，如果你想加入 Codex 团队，你需要是一名使用这些工具的技术人员。我想我会让你问自己这样一个问题：嘿，假设我加入了 OpenAI，并在接下来的六个月里致力于 Codex 的工作，而且干得很出色，那么软件工程师的生活会是什么样子？我觉得如果你对这个问题有自己的见解，那就应该来申请。如果你没有见解，还得先想一想，那么取决于你需要想多久，我想这就是筛选标准，对吧？我觉得有很多人在思考这个领域，所以我们对那些已经在思考 agent 未来应该是什么样子的人非常感兴趣。至于我们要走向何方，我们不必意见一致。但我想我们需要的是对这个话题非常有热情的人。

能参与一个影响力如此之大、又处于技术最前沿的产品，这是非常难得的。对合适的人来说，这是一个多么棒的角色。

所以，你们有职位空缺太棒了，而且这群听众可能非常适合这个角色。所以我希望我们能在听众中找到合适的人，那将太不可思议了。

说到这里，我们进入了非常激动人心的闪电问答环节。我有五个问题要问你，Alexander。准备好了吗？

我不知道问题是什么，但我很期待。开始吧。

呃，这些问题除了最后一题之外，都是我问过每个人的。所以，大概不会太意外。也许我应该更经常地准备一些惊喜问题。好了，第一个问题，你最想推荐给别人的是哪几本书？想到的两三本就行。

最近我读了很多科幻小说。我相信这本之前也有人推荐过，就是 The Culture。作者是 Ian Banks。我喜欢它的部分原因在于，它基本上算是相对较新的关于 AI 未来的作品，而且是一个对 AI 持乐观态度的未来。我觉得，很多科幻小说都相当反乌托邦。但这部作品，至少在 The Culture 的 subreddit 上流传的笑话是——让我看看能不能说准确——它就像一个太空共产主义乌托邦。或者说，我觉得它是一个同性恋太空共产主义乌托邦。我只是觉得，把 The Culture 当作一种思考方式，来想想我们能引领一个什么样的世界，以及我们今天可以做出哪些决定来帮助实现那个世界，真的很有意思。

嗯，我觉得之前没人推荐过这本。我知道你现在在读——我们录制前你提到过——《指环王》。如果你想要另一本跟 AI 相关的科幻书，你读过 Fire Upon the Deep 吗？没有，我没读过。

好吧。这本书非常棒。它像是一部科幻太空歌剧式的史诗传奇，讲述了超级智能的故事。

酷。是的，总体来说不太乐观，但多少还是有点乐观的。

好的，下一个问题。最近有没有特别喜欢的一部电影或电视剧？

有，有一部叫 Jujutsu Kaisen 的动漫，我非常喜欢。再说一次，它的主题有点黑暗，是关于恶魔之类的。但我喜欢的一点是，主角人很好。我觉得现在有一股动漫和卡通的新潮流，里面的主角非常友善，是关心世界的人，而不是像你看一些开创了这类作品先河的 older anime，比如 Evangelion 或者 Akira。那些作品里的主角都有很深的缺陷，相当不开心。它们并不是开创了这个流派，但曾经有一阵子，流行过一种趋势，就是嘲讽这类卡通里的主角明明很年轻，却被赋予拯救世界的荒谬责任。所以当时出现了一波作品，通过让角色在剧中经历严重的精神问题来批判这一点。我并不是说新的就更好，但至少能有这样非常积极正面的主角，或者只是努力帮助身边所有人，是相当有趣的。

我很喜欢通过这些推荐了解到你的个性。是啊。正面的主角，乐观的未来。我觉得，如果你不相信它，你就不可能凭意志让它成为现实。嗯。你需要一种平衡。这就是你的训练数据。

有没有最近发现并且非常喜爱的产品？可以是应用，可以是衣服，可以是厨房小工具、科技小玩意，或者一顶帽子。

有，我一直以来对内燃机和汽车非常感兴趣。实际上，我最初来美国的原因是想从事美国飞机相关的工作。但现在我做的是软件。所以很长一段时间里，我基本上只拥有一些相当老旧的跑车。旧只是因为它们更便宜。然后最近我们换了一辆 Tesla。不得不说，我觉得 Tesla 的软件相当令人启发。尤其是它有自动驾驶功能，而且我今天已经提过几次，我觉得思考如何构建 mixed initiative 软件是一件非常有趣的事——那种让你作为人类感到最大程度赋权的软件，让你最大程度地掌控一切，同时又能获得大量帮助。

我觉得他们在这方面做得很好。他们让车能够自动驾驶，但又有各种不同的方式让你可以在不关闭自动驾驶的情况下调整它的行为。比如你可以加速，它会听从你的指令。你可以转动旋钮来改变车速。你可以轻微转动方向盘。我觉得这实际上是构建 agent 的同时仍让人类保持掌控的典范。

这让我想起 Nick Turley 的口头禅：我们是否实现了最大程度的加速？是的。

这好像已经完全渗透到了 OpenAI 的方方面面，这很合理。说得通。

嗯，还有两个问题。你有没有一句人生格言，经常在工作或生活中想起并从中受益？

我不知道自己有没有人生格言，但也许我可以告诉你我创业公司排名第一的价值观。太棒了。这个原则至今仍然影响着我，那就是 kind and candid。说得通。友善且坦诚。哇。是的，我们必须把这两个词放在一起，因为我们作为创始人意识到，我们过去常常表现得和善，但那实际上并不是正确的做法。我们会推迟艰难的对话，我们不够坦诚。所以每当我们提醒自己这句格言时，我们就会变得更坦诚一些，然后六个月后又意识到，其实六个月前的我们还是不够坦诚。

Alexander我们需要更加坦诚。那么问题就来了：我们应该如何做到坦诚？不妨将坦诚视为一种善意的举动，同时从两个层面来思考这件事：一是付诸行动并让自己愿意去这样做，二是思考我们如何向他人表达它。

Lenny这是一个非常精妙的总结，说明了如何做好领导。那本讲“敢于直接挑战，但又深切关怀”的书叫什么来着？《Radical Candor》。哦对，对，没错。是的，是的，所以这就是另一种思考彻底坦率的方式。

好，最后一个问题。我查了一下你的姓氏，就想问问这背后有什么故事。你的姓是 Imbrios。我当时正在和 ChatGPT 聊天，它告诉我这个姓氏最著名的人物包括：极具影响力的希腊诗人兼精神分析师 Andreas Imbrios，以及他的亲戚——富有的航运大亨兼艺术收藏家 George Imbrios。那么问题来了，这两个人中你更认同哪一位？是那位希腊诗人兼精神分析师，还是那位富有的航运大亨兼艺术收藏家？

Alexander我想我必须选那位诗人，因为嗯，他热爱我们家族来源的那座岛屿。

Lenny等等，你认识这些人？好吧，这对你来说已经不是新闻了。好吧。

Alexander嗯，我的意思是，这是一个庞大的家族，但毕竟是希腊人。你知道的，在这种大家族里，每个人都像是你叔叔。你明白我的意思吗？就像我母亲是马来西亚人，在马来西亚也是一样，每个人都是我的叔叔或阿姨，如果你懂我在说什么的话。是的。但是，是的，他热爱这座家族起源的岛屿。我相信——其实我也不知道那位航运大亨在哪里，我想是纽约之类的——但不管怎样，我们都来自一座名叫 Andros 的岛屿。那是一个非常美丽的地方，那里的牲畜好像比人还多。没有太多游客去那里。但我觉得特别酷的一点是，他出版了很多作品，而且他的很多写作都是关于那座岛屿的美，我觉得这超级酷。

Lenny哇，这个回答太棒了。还有两个问题。如果人们想在网上关注你，或者联系你，他们可以在哪里找到你？以及听众可以怎么帮到你？

Alexander我是那种只因为工作需要才用社交媒体的人。你知道，我的手机在晚上大约9点就会变成黑白模式。但是对的，Twitter 或 X 上的账号是 @nbrico。还有，如果你在 r/codex 发帖，我可能会看到。所以你可以去那里。听众可以怎么帮到我？我想说，请试试 Codex。请分享反馈。告诉我们哪些地方需要改进。我们极度重视反馈。我觉得，说实话，增长一直很惊人，但现在仍然是非常早期的阶段。所以我们仍然非常关注反馈，而且希望永远如此。另外我想说，如果你对未来编程 agent 以及更广泛的 agent 感兴趣，那么请去我们的招聘网站申请，或者在那些社交媒体上给我发消息。

LennyAlexander，这次访谈太棒了。我一直很喜欢结识从事 AI 工作的人，因为 AI 总给人一种说不清的感觉，很冰冷、很可怕、很神秘。但当你见到那些真正在构建这些工具的人时，他们总是那么棒。而你尤其亲切友善，而且就像你分享的例子一样，充满了乐观和善意。你知道，这就是我们希望成为的样子。这就是我们希望能去构建那些将驱动未来的工具的人。所以，我非常感谢你来做这期节目。很高兴认识你，非常感谢你来到这里。

Alexander是的，非常感谢你邀请我。这很有趣。

Lenny非常感谢各位的收听。如果你觉得这期节目有价值，可以在 Apple podcast、Spotify 或你喜欢的播客应用上订阅本节目。另外，请考虑给我们打个分或留条评论，因为这真的能帮助其他听众找到这个播客。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于本节目的信息。下期再见。