推荐语
OpenAI产品经理揭秘：Codex爆发式增长背后的AI协作革命，人类打字速度竟成AGI最大瓶颈！核心内容： 1. Codex如何通过主动式编程助手实现20倍增长 2. 人类交互速度成为制约AI生产力的关键因素 3. OpenAI内部产品开发哲学与AGI发展路径
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
图片来源：Lenny's Podcast
Z Highlights
Codex是OpenAI推出的一款极其受欢迎且功能强大的Coding Agent，自今年8月ChatGPT5发布以来，该平台规模已增长20倍，目前每周处理数万亿个字符。2025年12月14日，Lenny邀请到Codex的产品负责人Alexander Embiricos做客他的播客，一起探讨Codex产品及AI发展瓶颈。
Lenny：今天我的嘉宾是Alexander Embiricos，Codex的产品负责人。
正如Nick Turley（VP, Head of ChatGPT）所说，Alexander是他合作过的所有人中最喜欢的人之一。Nick还表示，把Alex和他所创办的公司引入OpenAI，简直是OpenAI做过的最正确的决定之一。同样地，OpenAI的CPO Kevin Weil也评价说：Alex简直是最优秀的那种人。
在这次对话中，我们深入探讨了在OpenAI内部真正做产品到底是一种怎样的体验。我们谈到了Codex如何帮助Sora团队成功交付Sora app——这款应用在不到一个月的时间内，就成为App Store上排名第一的应用。我们还讨论了Codex目前正在经历的20倍增长，以及团队究竟做了哪些关键工作，才让Codex在代码编写能力上变得如此出色。
此外，Alexander也分享了他们团队当前的重点方向：不只是让AI更容易写代码，而是让人类和AI更容易审查代码，因为在真实的软件工程流程中，代码审查同样是至关重要的一环。我们还谈到了他对AGI时间线的判断，他对于AI Agents究竟何时才会真正变得实用的看法，以及更多相关话题。
Alexander，非常感谢你今天来参加节目，欢迎来到播客。
Alexander Embiricos：非常感谢，我已经关注这个节目很久了，能来这里真的很兴奋。
OpenAI的组织密码：自下而上
Lenny：我比你还激动，非常感谢你。我想从你在OpenAI的经历开始聊起。你大约一年前加入了OpenAI，在此之前，你有自己的创业公司，经营了大约五年。而在创业之前，你还曾在Dropbox担任产品经理。我想OpenAI和你之前工作过的地方肯定有很大不同。那OpenAI最不同的地方是什么？你在这里学到的东西是什么？无论你将来是否离开OpenAI，你在做其他事情时都会受益的东西是什么？
Alexander Embiricos：最显著的，我认为在OpenAI工作的速度和雄心远远超出了我曾经的想象。当然，我说这句话可能有点尴尬，因为每个创业公司创始人都会觉得自己的公司发展超快，人才很强，雄心也很大。但我必须说，在OpenAI工作让我重新定义了这些词的含义。
Lenny：我们经常听到这样的说法：“每一家AI公司都觉得他们的进展超快。” 请你举个例子说明，除了OpenAI，其他地方根本无法在这么短的时间内做到这一点？
Alexander Embiricos：最明显的例子就是Codex本身的爆炸式增长。我记得我们好像已经很久没对外公布过数据了，但实际上Codex的规模在几个月内增长了10倍，这一过程非常迅速，未来还会持续增长。一个人一旦经历过这种产品快速的成长，至少对我来说，会觉得无论以后我从事什么技术产品的工作，都会希望能够达到这种速度和规模。回想我在创业公司时的产品增长速度简直慢得多。而且，在创业公司中，总是有一个需要平衡的问题，就是你要多大程度上坚持自己的想法，是否要在发现想法不奏效时及时调整。而在OpenAI，我意识到，考虑到我们能产生的影响是如此之大，若真正想要做好工作，我必须在时间分配上变得更加果断和无情。
Lenny：在我们谈论Codex之前，我想知道OpenAI是如何组织和运营的才能让团队能够如此快速地推进产品的发展？每个人都希望能快速采取行动，我想这其中一定有某种结构性的方法来支持这种快速发展。
Alexander Embiricos：其中一个原因是，我们正在构建的技术已经彻底改变了很多事情，既包括我们构建技术的方式，也包括我们能为用户提供的功能种类。我们大多数时间都在讨论基础模型的改进，但我相信，即使今天模型不再有更多进展，我们在产品上的进展也远远不够。也就是说，我们还需要构建有很多产品。因此，可以说现在正是一个非常合适的时机。
但实际上，在我刚到OpenAI的时候，有很多反直觉的事情让我很吃惊，尤其是在组织结构方面。有一个例子让我印象深刻：在我之前做创业公司时，尤其是在Dropbox工作时，作为一个产品经理（PM），总是需要注意的一点是，我必须确保大家都朝着正确的方向前进，并且能加速朝着那个方向前进。但在这里，因为我们并不完全知道哪些能力会很快出现，也不确定哪些技术会有效，甚至即使是有效的技术也不一定能得到用户的认同，所以我们更需要的是灵活性——通过快速尝试来获得更多经验教训。因此，OpenAI的组织结构是非常强调自下而上的方式，这一点让我非常惊讶。很多公司都喜欢说自己是自下而上的，但OpenAI真正做到了这一点。这让我受到了很大的启发，我想如果我以后再有机会在非AI公司工作，或者假设我回到过去，我会完全以不同的方式来运营一个公司。
Lenny：我觉得你们的做法更像是“准备、开火、瞄准”而不是“准备、瞄准、开火”。这种方式听起来可能有点不太容易理解，但我其实在很多AI公司中都听过类似的说法。因为你们不知道人们会如何使用它，所以花大量时间去完善产品可能没有意义，相反，最好是先把产品推出，看看人们怎么使用，然后再根据使用情况扩展。你是怎么处理这个问题的？
Alexander Embiricos：是的，借用这个类比的话，我觉得这里确实有一个“瞄准”的环节，但“瞄准”的部分要模糊得多，我们只大概知道会发生什么。比如我在此工作时受益良多的研究主管常说：我们在OpenAI很擅长讨论一些将会发生在一年甚至更久之后的事情，尽管未来充满不确定性，但这种时间尺度恰到好处。而对于数月或数周内的事情，我们也能展开深度讨论。但真正棘手的是介于两者之间的尴尬地带，当时间接近却小于一年时，预测就变得极其困难。因此，在目标设定层面，我们需要明确： 我们究竟在构建怎样的未来图景？AI领域诸多核心难题，比如对齐问题（ZP注：Alignment，AI 与人类目标一致的技术难题），都需要我们着眼于遥远的未来进行思考，因此我们在未来层面采取模糊目标策略。但涉及更战术性的问题，比如具体要开发什么产品？用户将如何使用该产品？对于这种情况我们更倾向于通过实证探索来解决。
Lenny：这是一个很好的回答。当人们听到像你们这样的公司说：“我们要自下而上地推进。我们会尝试各种方案。我们不会制定未来几个月的具体计划。”时，会觉得最关键的是你们聘请了世界上最优秀的人才，才能让你们能够在自下而上的工作模式中如此成功，我很认同这个观点。
Alexander Embiricos：当我来到这里时，我也被每个人的个体驱动力和自主性震惊到了。OpenAI的运作方式让我再次感到惊讶，甚至是震惊。我认为OpenAI的运营模式无法简单复制，你不可能读完这段文字或听完播客就直接套用到自己公司。这话或许有些严苛，但确实很少有企业具备这样的精英人才储备。若要推行类似模式，恐怕需要进行较大的调整。
Codex为什么会呈现爆发式增长？
Lenny：好吧，让我们来谈谈Codex。你负责Codex的工作，那么Codex现在进展如何？你能分享一些数据吗？有什么信息是你可以分享的？此外，不是每个人都知道Codex到底是什么，可以给大家解释一下吗？
Alexander Embiricos：当然可以。是的，我非常幸运能在未来领先的Codex产品方面工作。Codex是OpenAI的Coding Agent。具体来说，你可以安装一个IDE扩展（比如VS Code扩展）或者终端工具。当你安装之后，你就可以将它与Codex配对，用来回答关于代码的问题，编写代码，运行测试，执行代码，并处理软件开发生命周期中的许多工作，尤其是写出最终要投入生产的代码。更广泛地说，我们认为Codex是软件工程团队成员的初始形态。我们用“团队成员”这样的大词，是因为我们想象的未来是，Codex不仅能够编写代码，还能在软件开发的早期阶段参与创意和规划，甚至在后期进行代码验证、部署和维护。为了在今天去更好理解Codex，我喜欢把它形象地比作一个非常聪明的实习生，他拒绝阅读Slack，除非你要求它去检查DataDog或Sentry。不管它多智能，如今大家用这类 AI 工具大多都是采用人机协同的方式。你到底能有多信任它独立写代码而不需要你一起协作呢？对吧？
但我们希望能够达到的目标是，它能像你新雇用的实习生一样工作，不仅仅让它写代码，还能让它参与到产品整个开发周期中去。而且你心里清楚，就算它一开始有些事没做好，最终也能通过不断迭代把问题解决。
Lenny：我之前以为，Codex不看Slack的好处就在于它不会分心，能一直保持专注、高效工作。但我现在懂你意思了，它其实并不掌握所有正在发生的事情的上下文信息。
Alexander Embiricos：是的，而且这不仅体现在执行任务的时候。对于那些优秀的团队成员，你不会事无巨细地指挥他们怎么做，对吧？刚招进来的时候，你可能会开几次会，让他们先学习一下，了解哪些提示有效、哪些不有效，如何与这个人沟通等。然后，你会给他们一些入门任务，再逐步委托更多工作。到最后，你就可以直接跟他说：“你现在和这几位同事协作，负责代码库的这个模块。要是你觉得有必要，也可以去对接代码库其他模块的同事。” 然后你会补充一句：“你自己判断该做哪些事才合理。” 所以，我们将这种方式称为主动性。
我们在Codex上的主要目标之一就是实现主动性。我认为这对实现OpenAI “让全人类都能受益于AI” 的使命至关重要。我现在总喜欢开玩笑说，AI产品其实是非常难用的，因为你得仔细琢磨它在什么时候能帮上忙；要是你不主动给模型发指令，它根本不会在那个时刻发挥作用。你想想，现在普通用户每天主动调用AI的次数大概也就几十次。但如果真有一个高度智能的助手，这个次数可能是每天成千上万次。所以，我们开发Codex的核心目标之一，就是搞清楚如何打造出一个能主动提供帮助、真正像团队成员一样的Agent。
Lenny：当人们想到Codex这类IDE和Cloud Code时，通常会觉得它们只能辅助编程、实现代码自动补全，或许还能完成一些Agent相关工作的开发环境。但是如你刚才所说的，你们的愿景有所不同，你们想让它成为一个协作伙伴，就像远程的同事一样。你可以和它交流、指派任务，它同时还具备IDE自动补全等基础功能。你认为这种“团队成员（Team mate）”的概念是Codex的核心差异化定位吗？
Alexander Embiricos：基本上我们希望是这样的。作为开发者，当你要完成某项工作时，我们希望你能拥有 “超能力”，开发效率得到质的飞跃。但我们并不认为，要获得这种效率提升，你必须得时刻想着“如何调用AI来帮你做某个任务”。我们希望AI能无缝融入你的工作流程，不用你刻意操作，就能主动帮你处理事务。
Lenny：明白了，关于这个方向我还有很多问题。不过先说说Codex目前进展如何吧？能分享一些相关数据吗？
Alexander Embiricos：自从今年8月ChatGPT5发布以来，Codex的使用量就呈现爆发式增长。要是你感兴趣，我可以跟你聊聊我们是如何实现这种增长的，其中有不少有意思的产品洞察。之前我们公布的数据是，自8月以来使用量增长超10倍，而实际上现在已经达到20倍了。此外，Codex模型目前每周处理的Token高达数万亿，它已是我们最核心的代码生成模型。
其中一个非常酷的点是，我们组建Codex团队时，特意打造了产品与研究深度融合的团队架构，让模型开发与工具应用能协同迭代。事实证明，这种模式能让我们开展更多实验，探索模型与工具协同的最佳方式。起初，这些模型主要适配我们自研的工具环境，我们对其应用场景有明确的规划。而最近我们发现，其他API代码开发客户也开始采用这些模型。如今，Codex模型在API端也成为使用量最高的代码生成模型了。
Lenny：你刚刚隐约提到了实现这种增长的关键，我对此非常感兴趣，想听听具体原因。我记得在以前，或许是在你加入团队之前，当时的Cloud Code可谓是独占市场，所有人都在基于这款工具进行开发，它无疑是当时最佳的编码工具。然而，Codex的横空出世彻底改变了这一局面。我记得Karpathy曾在Twitter上说，他从未见过如此强大的模型。他在推文中提到，他曾遇到的一些极其棘手的bug，自己花了好几个小时都没办法解决，什么方法都试过了都不行。然后他把这个问题交给Codex，让它运行了一个小时，结果竟然Codex成功解决了这个问题。你们究竟是如何做到的？
Alexander Embiricos：在OpenAI，我们始终秉持一个明确且坚定的使命，就是要构建AGI。因此，我们一直在深入思考如何设计产品，才能使其实现规模化发展。我之前也提到过，对于工程师而言，AI每天应该能为他们提供数千次帮助。基于这一理念，我们在推出Codex的首个版本——Codex Cloud时，就对实现这一目标的基础要素进行了大量探索。这款产品本质上是一个云端独立运行的产品，开发者可以将任务委托给它，其最突出的优势在于能够同时并行处理大量任务。
然而，我们也发现了它存在的一些问题。这款产品的部署和配置门槛相对较高，无论是为模型配置验证代码变更所需的运行环境，还是学习如何通过合理的Prompt与模型高效交互，都需要开发者投入不少精力。如果沿用之前 “团队伙伴” 的类比，假如你雇佣了一个新团队成员，却只能通过异步（asynchronously）方式与对方沟通协作，完全没有机会进行实时通话。这种协作模式或许适用于部分同事，甚至从长远来看，这会是我们未来主要的工作方式，但在初期推广阶段，它的接受门槛确实很高。
当然，我们依然没有放弃最初的愿景——打造一个能够接受任务委托、具备主动工作能力的团队伙伴式Agent，而且目前这一方向的发展势头也十分良好。但实现增长的关键突破口，其实在于我们首先要以更贴合用户直觉、更易为用户创造价值的方式，让产品真正走进用户的工作场景。如今，绝大多数用户认识并接触Codex，都是通过两种途径：要么下载安装对应的IDE扩展，要么在命令行界面（CLI）中运行它。通过这两种方式，Agent能够直接在用户的本地电脑上与之进行交互式协作，并且所有操作都在沙箱环境中完成（ZP注：Sandbox，一种虚拟隔离环境，可限制程序的运行权限，避免对主机系统造成安全威胁）。这项技术的巧妙之处在于，它既能保障操作的安全性，又能让产品获取到运行所需的所有依赖项。例如，当Agent需要执行某条命令时，它可以直接在沙箱环境中运行；如果该命令无法在沙箱中执行，它就会主动向用户寻求帮助。这样一来，用户与模型之间就能形成一个高效的反馈循环。而我们团队的核心工作，就是借助这个反馈循环，让用户在使用产品的过程中，不知不觉地完成对Agent的配置，为后续将更多任务委托给它打下基础。
还是用之前“团队成员”的类比来解释：如果你刚招到一位新员工，就直接给他一台全新的、未配置任何软件的电脑，让他开始工作，那么他必然会寸步难行；但如果你们并肩协作，你可以随时告诉他：“哦，你还没有我们常用服务的登录密码，我现在发给你” “没关系，放心执行这条命令就行”。有了这些基础配置和指导，他之后就能独立工作数小时，不再需要你的实时协助。
Lenny：所以，我理解的是，Codex的初代版本理念其实有些过于超前了，它就像一个远程云端Agent，以异步模式为开发者编写代码。而你们后续的调整思路，就是适当 “下沉”，将产品与工程师们日常使用的IDE进行深度整合，让Agent在本地环境中为他们提供帮助，从而引导他们逐步适应并进入这个全新的AI辅助开发时代，对吗？
Alexander Embiricos：完全正确。这一调整的过程其实非常有意思，因为在OpenAI，我们一直大量进行内部试用的传统（ZP注：Dog Fooding，指公司员工使用自家研发的产品，通过实际体验发现并改进产品问题）。过去一整年里，Codex一直在为OpenAI的研发工作提速增效，而Codex Cloud这款产品也确实为公司的发展提供了强大的助力。
但我们发现，内部试用得到的反馈信号，与从普通市场用户那里得到的反馈信号存在一定差异。这是因为在OpenAI内部，我们每天都在训练推理模型（指具备逻辑推理能力，能够基于已有信息进行分析、推导并得出结论的AI模型），团队成员早已习惯了通过撰写Prompt与模型交互的工作模式，也擅长提前规划任务流程，通过大规模并行处理的方式执行任务，然后等待一段时间，再以异步模式查看任务结果。因此，如今我们在进行产品开发时，虽然依然会高度重视内部试用带来的反馈，但同时也会充分承认并关注不同用户群体使用产品的差异化方式。
Lenny：这确实很有意思。就像是立足未来开展研发，但又不会过于超前，脱离当下的实际需求。我能理解，OpenAI的所有人仿佛都置身于遥远的未来，但有时候这种过于超前的理念并不适用于所有用户。好的，那我再问问关于AI训练数据的问题。不知是否还有其他因素助力Codex提升了实际编码能力？是得益于质量更优、格式更规范的数据集，还是模型本身的迭代进步，亦或是存在其他关键的推动因素？
Alexander Embiricos：是的，这背后其实是多个因素共同作用的结果。你刚才提到了模型，我们的模型确实已经取得了巨大的改进。就在上周三，我们正式推出了GPT 5.11CodexMax，这个命名非常精准。这款模型的表现十分出色，原因有两点：一是对于所有原本可以用GPT 5.1 Codex完成的任务，它的执行效率提升了约30%；二是它还解锁了更强的智能能力。当你将它调至更高的推理级别时，它的表现会更加智能。你之前提到Karpathy发布的那条推文，也就是让模型攻克那些最难解决的漏洞，显然目前市场上有很多同类产品，但Codex Max无疑是扛起了攻克这类棘手漏洞大旗的佼佼者。这一点确实非常令人振奋。
不过我想说的是，我们对这个问题的思考方式也在逐渐演变。过去，我们的思路局限于研发最优模型、专注于模型本身的训练优化，但现在我们开始更多地思考一个Agent的整体架构究竟应该是什么样的。我不会试图给智Agent下一个精准的定义，但至少在我们的认知里，一个Agent的技术栈（Stack）应当包含以下部分：首先需要一个具备强大推理能力的模型，且这个模型要精通某一类特定任务。我们可以后续探讨如何实现这一点。但除此之外，我们还需要通过API将这个模型部署到对应的工具环境（ZP注：Harness，指支撑模型运行的配套工具与系统）中。而这两个环节在整个体系里同样发挥着至关重要的作用。
举个例子，有一项成果是我们非常引以为傲的——GPT 5.11Codex Max能够长时间持续运行。这并非模型的常规能力，但你可以通过相关设置实现这一功能，而且这种长时间运行的情况如今也时有发生。现在我们经常会听到用户反馈，说这款模型可以通宵运行，甚至持续运转24小时。要知道，模型要实现如此长时间的连续运行，必然会超出自身的上下文窗口（ZP注：Context Window，指大语言模型在生成内容时所能参考的前文文本长度上限），针对这个问题，我们研发出了一项名为 “上下文压缩”（ZP注：Compaction，指对模型已处理的上下文信息进行压缩，从而节省空间以支持更长时间运行的技术）的解决方案。而这项技术的实现，实际上需要同时调动技术栈（Stack）的三个层面协同运作。首先，模型本身要具备上下文压缩的能力，并且能够预判：当自身即将达到上下文窗口上限时，需要做好准备，以便在新的上下文窗口中继续运行。其次，在API层面，需要有一个能够理解上下文压缩概念的接口，并且要设置对应的终端节点来执行这一操作。最后，在工具环境（Harness）层面，则需要有一个能够为实现上下文压缩准备好对应数据负载的工具。由此可见，要让所有Codex用户都能用上上下文压缩这项功能，就必须确保技术栈（Stack）的三个层面同步推进、协同工作。我认为，未来这种多环节协同优化的模式会成为常态。
还有一个可能未被充分重视的点，那就是市面上现有的各类代码生成产品，都配备了截然不同的工具环境，并且对于模型应该如何运作，这些产品也有着各自迥异的理念。所以，如果你想要训练一个能够适配所有运作模式的模型，难度是非常大的。比如，有的产品坚信模型应该基于语义搜索（ZP注：Semantic Search，指通过理解文本语义而非关键词进行检索的技术）来运作；有的则认为模型应该调用定制化工具；而在我们的理念里，模型应该直接借助终端的命令行界面来工作。很明显，如果你只针对其中一种模式进行优化，那么研发进度会快得多。我们打造 Codex的思路正是如此——让它直接通过命令行界面运行。但为了保障这种运行方式的安全性，我们为模型搭建了一个专用的沙箱环境（Sandbox），模型也已习惯在这个环境中运行。
所以，回到你最开始的问题，总结来说，推动Codex能力提升的最大助力，就是我们同时并行推进技术栈三个层面的研发工作，不断对每个环节进行调试优化，并且依托高度协同的产品团队与研究团队，持续开展各类实验，探索各环节之间的最佳协作模式。
Coding Agent的理想愿景：不止于写代码，更是主动协作的Teammate
Lenny：你认为要如何在这一领域脱颖而出 ？你觉得这场竞赛会一直持续下去吗？各家的模型会不断交替领先？有没有可能出现这样一种局面？
Alexander Embiricos：这个问题的答案，其实还是要回归我们最初的理念——打造一个团队协作伙伴（Teammate）。而且这个伙伴的能力不能只局限于参与团队规划、确定任务优先级，也不能只停留在代码测试、协助维护与部署的层面。你可以把它想象成一位真正的工程师同事，这样的同事除了本职工作，还能帮你安排日程邀约、调整站会时间，或是处理其他各类事务，我们要打造的就是这样的Agent。
在我看来，如果科研实验室每隔几天或几周就推出一项突破性的新功能，作为普通人，我们根本没有精力去跟上所有技术的迭代步伐，更谈不上熟练运用。所以我们需要构建这样一个未来场景：每个人都拥有一个AI Agent协作伙伴或是超级助手，你只需要和它沟通，它就能主动提供恰到好处的帮助。你不必费心去查阅最新的使用技巧，只需要将它接入你的工作流，它就能随时伸出援手。我认为这正是我们当前的研发方向，只要能实现这一目标，我们就能打造出一款极具用户粘性的爆款产品。
至少在我构想中，有一个值得探讨的有趣话题：聊天界面是否是AI的最佳交互界面？我个人认为，当用户还不清楚该如何使用一款工具时，聊天界面是非常友好的选择。这就像你在Teams或者Slack上和同事沟通一样，聊天功能简单直接，你可以提出任何需求，它就像是所有交互场景的通用载体。基于这一点，你可以就任何话题与超级助手展开对话，无论话题是否与编程相关。而当你作为某个特定领域（比如编程领域）的专业人士时，你还可以调出一个图形用户界面（ZP注：GUI，指采用图形方式显示的计算机操作用户界面），深入查看代码、开展编程工作。
所以在我看来，OpenAI需要打造的产品形态应该是这样的：首先推出ChatGPT这样一款全民可用的聊天工具，人们甚至可以在工作之外的场景使用它来获取帮助。当用户逐渐习惯了AI带来的效率提升后，再将这种体验延伸到工作场景中。到那个时候，用户只需要自然地向它提出需求，不必了解各种复杂的接口或功能细节，它就会在当下的场景中，以最优的方式提供帮助，甚至在你没有主动求助时，也能适时给出建议。我认为，做到这一点，才是我们打造成功产品的核心关键。
Lenny：这太有意思了。我之前和ChatGPT负责人Nick Turley聊过，他提到ChatGPT最初的命名其实是 “超级助手” 之类的想法。这就很有意思了，一边是超级助手的产品定位，另一边是Codex的发展路径，这两者几乎就像是B2C和B2B的两个版本。按我的理解，你们的思路是先从编程领域切入，逐步拓展能力边界，让它能帮你处理更多事务，比如安排会议、在Slack上发布消息、提交设计方案等等，是这样的吗？从某种意义上说，Codex是不是相当于ChatGPT的商用版本？或者说，你们还有其他的规划？
Alexander Embiricos：没错。我们现在探讨的其实是未来一年左右的发展蓝图，很多规划或许会提前落地，但目前来看，这个时间范围是比较合理的。我可以提出一个有争议的观点，来描绘一条可行的实现路径，但具体的发展过程，谁也无法准确预测。
要打造一个超级助手，它必须具备实际执行任务的能力，也就是能够对现实世界产生影响。过去一年多来，我们得到的一个重要经验是：如果AI模型能够借助计算机开展工作，它的效能会得到极大提升。基于这一点，我们的目标就很明确了——打造一个能使用计算机，甚至能同时操控多台计算机的超级助手。但新的问题随之而来：它应该以何种方式使用计算机？
操控计算机的方式有很多种，比如可以利用辅助功能的API，或者采用更简单的鼠标点击操作。但这些方式的未来发展路径其实很难规划，因为打造Agent的核心问题，早已不是 “Agent能否完成任务”，而是 “我们如何帮助Agent理解其工作环境”。要知道，每个使用Agent的团队都有自己的工作方式和准则，他们往往需要Agent的行为具有确定性，明确知道Agent能做什么、不能做什么，同时也希望Agent能理解工作中的各种细节。
举个例子，假设有一个崩溃报告工具（Crash Reporting Tool），不同的子团队在对接这个工具的接口时，可能会为Agent设置不同的元提示词（Meta Prompt），来指导它如何分析崩溃报告。由此可见，我们需要让Agent不仅能操控计算机，还能根据不同团队或用户的需求进行定制化配置。对于Agent经常执行的任务，我们应该将其转化为它固有的核心能力。所以最终，我们会打造出一个具备通用能力的Agent，它可以为任何任务编写专属的脚本程序。
但这里有一个非常关键的要点：我们能否让Agent记住并存储它经常执行、且能高效完成的所有任务？这样它就不必每次都重新编写脚本。再比如，当我加入一个新团队时，如果你们已经在使用这款Agent，我就可以直接复用它之前编写好的所有脚本。
Lenny：没错。如果它真的是我们的团队协作伙伴，就应该能分享它在公司里和其他人协作时学到的经验。这个比喻确实很贴切。感觉你和Karpathy的观点一致，认为当下的Agent还不够完善，整体表现比较粗糙，或许未来它们才会发展得足够出色。你认同这个看法吗？
Alexander Embiricos：我基本认同。不过我觉得Coding Agent现在已经相当不错了，它们能创造巨大的价值。至于非编程领域的Agent，目前还处于非常早期的阶段。在我看来，一旦这些Agent也能以可组合的方式运用编程能力，它们的性能将会得到极大的提升。为软件工程师打造工具其实是一件很有意思的事。我之前创办的公司，也有很长一段时间在为软件工程师开发产品。这个群体其实非常适合作为产品受众，因为他们本身也喜欢为自己开发工具，而且在思考技术应用方式时，往往比我们这些开发者更具创造力。正因为如此，为他们打造产品的过程中，我们能观察到大量的新兴行为（ZP注：Emergent Behaviors，指Agent在交互中表现出的设计之外的行为模式），并从中提炼出产品需要新增或优化的功能点。
Lenny：你这个观点我很喜欢。很多人为工程师开发产品时都会感到头疼，因为工程师总爱抱怨各种问题，他们会说 “这东西太差劲了” “为什么要这么设计”。你能乐在其中真的很难得，不过这可能是因为你们打造的工具确实很出色，能切实帮工程师解决问题、编写代码。说到这里，一直有个话题被频繁讨论：AI会对工程师的工作、编程这项技能，以及人们是否还需要学习编程带来什么影响？显然，按照你描述的定位，它不是取代者，而是协作伙伴，会和人类并肩工作，让工程师的能力得到强化，变得更高效。你如何看待这种超高智能的工程协作伙伴，会对整个工程领域产生怎样的影响？
Alexander Embiricos：我认为这件事有两面性，但我们刚才讨论的核心观点是，或许所有Agent本质上都应该具备编程能力，成为Coding Agent。在我看来，这只是一个更宏大理念的一小部分——随着代码的普及程度不断提升，它的应用场景也会变得更加广泛。要知道，即便是在AI普及之前，代码的应用其实就已经很普遍了。未来，社会对具备编程能力的人才需求只会越来越旺盛，至少这是我的看法。当然，这个话题本身相当复杂，我们内部也经常讨论，最终的发展态势还需要时间来验证。但作为深耕这个领域的产品团队，我们能做的就是始终思考如何打造工具，最大限度地提升人们的工作效率，而不是制造一款让人类不知所措、不知道该如何决策的工具。
举个例子，现在工程师和Coding Agent协作时，Agent往往会生成大量代码。但事实上，编写代码本身对很多软件工程师来说，是这份工作中最有趣的部分之一。结果现在工程师反而要花时间去审核AI生成的代码，而审核代码对很多工程师来说，恰恰是工作中不那么有趣的环节。我们发现这种情况会体现在大量的细微决策中。因此，我们产品团队一直在思考，如何让这个过程变得更有趣，如何让工程师在使用工具时更有掌控感，同时改进那些体验不佳的环节。我认为，如今审核Agent生成的代码就是一个体验有待优化的痛点。针对这个问题，我们可以推出代码审查功能，帮助工程师增强对已生成代码的信心。此外，我们还可以优化Agent的能力，让它能更好地自行验证工作成果。
这种优化还会延伸到很多细微的决策上，比如就拿Codex Web来说，它有一个面板专门展示Agent完成的工作内容。用户打开面板时，第一眼应该看到什么？是代码的差异对比（ZP注：Diff，指不同版本代码之间的改动内容），还是Agent编写代码的预览界面？如果我们的出发点是 “如何赋予人类更多主动权” “如何最大限度提升人类的工作效率”，那么答案显然是让用户先看到预览界面。除非代码已经经过AI的初步审核，需要人类进一步查看，否则没必要直接展示代码差异。
AGI的真正瓶颈：不是模型，是人类的打字速度与认知局限
Lenny：我之前在播客节目里采访过Cursor的首席执行官Michael Charel，他提出了一个愿景，认为我们未来会迈向一个超越代码的新阶段。我也注意到，一种名为 “规格驱动开发”（ZP注：Spec Driven Development，一种先定义产品规格再进行开发的模式）的理念正在兴起——开发者只需要编写产品规格说明，AI就会根据规格自动生成代码。这意味着工程师可以在更高的抽象层面开展工作。你认为这会是未来的发展方向吗？也就是工程师不再需要亲自编写或查看代码，转而专注于更高层次的抽象设计？
Alexander Embiricos：是的，我觉得抽象层级的不断提升是一个持续的过程，而且这种趋势其实现在就已经显现了。比如当下的Coding Agent，大多还是基于 “提示词生成代码补丁”（ZP注：Prompt to Patch，指输入Prompt后Agent生成针对性的代码修改补丁）的模式。不过我们确实已经看到，越来越多的人开始尝试规格驱动开发或计划驱动开发。很多人会问，如何让Codex处理超长时间的任务，其中一种常用方法就是先和它协作编写一份计划文档，比如一个Markdown格式的计划文件，等计划确定后，再让它去执行具体工作。如果这份计划包含可验证的步骤，那么Agent就能持续运行更长时间。
所以我们确实观察到了你说的这种趋势。我认为规格驱动开发是个很有意思的理念，但不确定它是否会成为主流模式，因为很多人其实也不喜欢写规格说明。不过确实有可能会有一部分人选择这种工作方式。还有一个有点玩笑性质的想法：现在很多团队的工作模式其实并没有明确的规格说明，而是依靠团队的自主能动性推进工作，事情照样能完成。由此我突然想到一个概念——虽然这个名字起得不太好，姑且叫它 “交流驱动开发”（chatter driven development）吧。意思就是团队通过社交媒体、沟通工具不断交流，在这个过程中，代码自然而然地被编写出来并完成部署。
所以我个人其实更倾向于这种灵活的模式。我不一定非要写规格说明，只有在我愿意写的时候才会去写。其他时候，我可能会直接说 “这是客户服务渠道的相关信息，帮我梳理出有价值的内容；如果只是小漏洞的话，直接修复就行，没必要专门写规格说明”。我经常会和别人分享一个假想的未来场景，用来引发大家的思考：如果我们拥有了真正强大的Agent，那么个人创业者的工作模式会变成什么样？
一个听起来有些离谱的设想是：未来会有一款手机应用，Agent所有的工作构想都会以竖屏视频的形式呈现在手机上。你觉得这个想法不好，就向左滑动；觉得不错，就向右滑动；如果想在滑动前进一步了解这个想法，还可以长按屏幕和手机语音交流。在这个场景里，你的核心工作就是把这款应用接入所有的信息系统和业务记录系统，然后就可以坐下来，通过滑动屏幕来决策。
Lenny：这简直就像是TikTok和Codex的结合体，太有意思了。也就是说，这个Agent会时刻观察、倾听你的需求，密切关注市场和用户的动态，然后主动提出建议，比如 “这个功能应该开发” “这个问题需要修复”，就像一个积极主动的工程师一样。
Alexander Embiricos：完全正确。我认为它和人类的沟通方式，会是那种最低门槛、最高效的方式。
Lenny：就像现在最流行的沟通方式一样——滑动屏幕、竖屏信息流，再加上Sora生成的视频。我现在完全明白这些构想之间的关联了。
Alexander Embiricos：没错。不过要说明的是，我们目前并没有在开发这样一款应用，这只是一个有趣的设想。但从这个设想中可以看出，Agent其实是在整合外部的各类信号。还有一件事我觉得很有意思：如果要评选迄今为止最成功的AI产品，你猜会是什么？其实说出来可能有点容易混淆，OpenAI最早使用Codex这个品牌，是将其作为支撑 GitHub Copilot的底层模型，那是很多年前的事了。我们最近决定重新启用这个品牌，正是因为它的口碑一直很好，毕竟Codex的核心就是代码执行。
但在我看来，集成在IDE中的代码自动补全功能，才是迄今为止最成功的AI产品之一。它的神奇之处在于，能够快速为用户提供实用的代码建议。当建议准确时，能显著提升开发效率；即便建议出错了，也不会带来太大的困扰。这种人机混合主动系统（ZP注：Mixed Initiative System，指人类和Agent共同主导任务流程的协作模式），能根据用户的操作上下文实时做出响应。在我看来，这是OpenAI在产品开发过程中一个非常值得借鉴的思路。
比如我们之前推出的Atlas浏览器，基于这个思路，我们可以做一件很有意思的事：在用户日常使用浏览器的过程中，根据上下文主动提供帮助。这样一来，我们就能突破 “只关注代码” “只局限在终端” 的局限，真正实现像一个真实的团队伙伴那样工作——毕竟现实中的同事要处理的远不止代码，还有大量和网页内容相关的事务。那么，我们该如何在这方面为用户提供帮助呢？
Lenny：这里面的信息量太大了，我太感兴趣了。原来如此，在浏览器中也能实现网页内容的自动补全功能，这个想法太有意思了。也就是说，在你浏览网页、处理日常事务的过程中，它能随时为你提供各类帮助。我想谈谈Atlas，稍后再回来讨论。Codex的代码执行功能，我之前竟然完全不知道，这个设计真是太巧妙了。我现在彻底明白了。然后是关于什么是Chatter Driven Development，我觉得这个点非常好，它让我想起了之前我和Block的CTO John Gon在播客上的对话，他们有一个叫做Goose的产品，是他们自己内部的Agent。John讲过，Block的一名工程师让Goose监视他，观察他的屏幕，听他的每一次会议，主动做一些他可能会需要做的工作。于是Goose就会发PR、发送邮件、草拟Slack信息。所以他实际上在做的正是你所描述的模式，只不过目前还处于非常早期的阶段。
Alexander Embiricos：是的，这真是非常有趣。我很好奇，如果我们去问他们，生产力的瓶颈是什么，他们会怎么回答呢？
Lenny：可能就是需要人工审核，确保Agent做的是正确的事。
Alexander Embiricos：确实如此。其实我们现在也遇到了类似的情况。我们为Codex开发了Slack集成功能，用户们的反馈非常好。比如当你需要快速解决某个问题时，直接在Slack里@Codex就行，比如问 “你觉得这个漏洞是什么原因导致的”。而且使用它的人不一定是工程师，就连数据科学家也经常用Codex来解答问题，比如 “这个指标为什么会出现波动” “到底发生了什么状况”。这些问题都能在Slack里直接得到答案，非常方便实用。但如果是涉及编写代码的场景，用户还是得回过头去查看生成的代码。所以在我看来，目前真正的效率瓶颈在于验证代码的有效性，以及撰写代码审核意见。如果我们想要实现你刚才提到的那种理想状态，就必须想办法让用户能够对Coding Agent进行配置，让它在工作流程的后续阶段具备更强的自主性。
Lenny：确实有道理。就像你说的，编写代码这件事，我以前当过十年的工程师，我太清楚了。编写代码的过程非常有趣，全身心投入其中，构建架构、测试功能，那种沉浸感太棒了。但反过来，去审核别人写的代码就没那么有意思了，而且还要承担责任——万一代码里有漏洞，导致生产环境崩溃，后果不堪设想。现在，代码编写的过程已经变得越来越容易了，我总是听那些处于技术前沿的公司说，如今的瓶颈已经变成了 “确定要开发什么功能”，以及项目收尾阶段的代码审核工作，比如 “我们有个需要用时100个小时的代码审核工作，谁来负责完成呢？”
作为一名产品经理（PM），Codex对你的工作方式产生了什么样的影响？显然，它对工程师的工作产生了巨大的改变，代码可以由Agent代劳。那么它对你，以及对 OpenAI所有产品经理的工作方式，带来了哪些变化？
Alexander Embiricos：对我而言，最直观的感受就是工作能力得到了极大的增强。我一直算是技术背景比较强的产品经理，尤其是在开发面向工程师的产品时，我认为亲自试用自家产品是必不可少的环节。但除此之外，Codex还让我作为产品经理的工作效率提升了不止一个档次。Scott Beltski曾经提出过一个 “压缩人才层级”（Compressing the Talent Stack）的理念，我不确定我表述得是否准确。这个理念的核心是，不同岗位之间的界限可能不再像以前那样泾渭分明，因为人们现在可以凭借工具完成更多跨领域的工作。每当一个人能承担更多职责时，就可以减少一道沟通壁垒，从而让整个团队的效率变得更高。现在，我们在很多职能岗位上都看到了这种变化。不过既然你专门问到了产品经理的工作，那我就具体说说。现在，回答各类问题变得容易多了，你可以直接向Codex咨询相关思路；很多产品经理的日常工作，比如分析市场变化趋势，也可以寻求Codex的帮助；而且原型开发的速度往往比编写产品规格说明还要快，这一点很多人都提到过。
还有一个现象，虽然不算特别令人意外，但多少还是有点出乎意料：我们开发Codex的初衷，主要是让它编写可以部署到生产环境的代码，但现在发现，很多用户会用它编写一次性代码（ZP注：Throwaway Code，指为临时需求编写的、用完即弃的代码）。这其实又回到了我们之前提到的代码普及化的理念。比如有人需要做数据分析，他只需要把一堆数据交给Codex，然后要求它构建一个交互式的数据查看器。在过去，做这件事会非常麻烦，但现在，让Agent来完成这项工作，完全值得投入时间。无独有偶，我看到我们设计团队也用Codex做出了一些非常棒的原型。比如有一位设计师想要制作一个动画效果，也就是Codex里的硬币动画。通常来说，编写动画程序会很繁琐，于是他们先即兴编写了一个动画编辑器，然后用这个编辑器制作出了想要的动画，最后将动画文件提交到代码仓库。事实上，我们的设计师团队也通过Codex实现了效率的大幅提升。说到压缩人才层级，我觉得我们的设计师都很有产品经理的思维，他们也承担了大量的产品相关工作。而且他们还基于Codex应用，独立开发了一个完整的即兴原型版本。
产品开发的节奏其实非常快，因为同时有无数件事情在推进。设计师们会先思考某个功能的实现逻辑，然后不会再花时间反复讨论，而是直接在他们的独立原型工具里即兴编写一个原型。我们会试用这个原型，如果觉得效果不错，设计师就会把这个原型进一步完善，最终转化为可以提交的代码合并请求。根据他们对代码库的熟悉程度不同——毕竟Codex的命令行界面（CLI）和Rust编程语言的使用门槛相对较高——他们可能会自己完成代码的最终提交，也可能会先完成大部分工作，再由工程师协助完成合并。
我们最近还推出了Sora安卓应用，这个项目可以说是Codex提升工作效率的最令人惊叹的案例之一。显然，Codex在OpenAI内部的使用率本来就非常高，而且在过去一年里还在持续增长。现在，几乎所有技术人员都在使用它，同时大家对如何最大化发挥Coding Agent价值的认知和技巧也有了极大的提升。正是在这样的背景下，我们仅用18天就完成了Sora安卓应用从0到1的开发，并正式上线供公司员工使用。10天后，也就是总共28天，这款应用就正式面向公众发布了。这个项目的完成全程都得到了Codex的助力，这样的开发速度简直快得离谱。
我不想说这是 “走捷径”，但有一点是肯定的：如果一家公司需要跨多个平台开发软件，而且已经搭建好了底层的API或相关系统，那么让Codex来负责代码的跨平台移植工作，会是非常高效的选择，因为它有现成的代码可以参考。这个安卓应用项目的工程师们，就是让Codex先参考Sora iOS应用的代码，生成详细的开发计划，然后再按照计划完成安卓版本的开发工作。开发过程中，Codex会同时对比参考iOS和安卓两个平台的特性。所以最终，我们只用了两周时间就完成了员工内测版，四周时间就实现了全面上线，速度快得惊人。
Lenny：这太疯狂了，最令人震惊的是它最终成为了App Store中的第一款应用。我简直不敢相信。
Alexander Embiricos：没错。想象一下，一个只有两三名工程师的小团队，在短短几周内就开发出一款登顶App Store的产品，确实很震撼。
Lenny：这太离谱了。
Alexander Embiricos：是啊，这正是Codex提升研发效率的绝佳案例。另外还有Atlas浏览器这个项目，我记得Ben在播客里分享过Atlas的底层技术架构，也提到了一些开发细节。实际上，Atlas本质上是一款浏览器，而开发浏览器的难度极高，我们需要搭建大量复杂的系统才能实现相关功能。现在，Atlas团队已经成了Codex的重度用户。我之所以会关注这个团队，是因为里面很多工程师都是我之前创业公司的老同事。他们告诉我，以前需要两三名工程师花两三周才能完成的任务，现在一名工程师一周就能搞定，效率提升得非常显著。
更值得一提的是，Atlas最初是先在Mac系统上线的，现在我们正在开发Windows版本。团队在适配Windows系统的过程中，也在帮助我们优化Codex在Windows平台的表现。值得一提的是，我们上周发布的最新模型，是首个原生支持PowerShell的版本——PowerShell可是Windows系统的原生命令行脚本语言。所以，看到公司各个部门都在Codex的助力下提升效率，真的很令人振奋。这种提升不仅体现在工程研发上，也包括模型训练的速度和质量优化；而且就像我们之前聊到的，设计部门也从中受益，甚至市场部门也是如此。现在，我们的产品营销人员甚至可以直接在Slack上修改文案、更新文档。
Lenny：这些案例都太精彩了。你们正站在技术的最前沿，探索着各种可能性，而你们的工作模式也将成为其他公司的标杆。毕竟这款28天就开发完成的应用，不仅登上了App Store榜首，还收获了全球用户的喜爱，火遍全网至少整整一周。你说核心功能的开发只用了 18 天？
Alexander Embiricos：对，18天就做出了可供公司员工试用的版本，10天后就正式对外发布了。
Lenny：而且团队只有两三名工程师。那你刚才说Atlas相关的任务现在一周就能完成？
Alexander Embiricos：不不，我不是说整个Atlas项目一周就能做完。Atlas其实是一个体量很大的项目。我和Atlas团队的一位工程师聊过他们使用Codex的情况，他说 “我们现在做任何事都离不开Codex”。我接着问他，具体效率提升了多少？他就给了我刚才那个答案：以前两三名工程师要花两三周的工作量，现在一名工程师一周就能完成。
Lenny：你认为这种模式最终会普及到非工程师岗位吗？比如，开发这类产品一定要工程师来做吗？有没有可能由产品经理或者设计师来完成？
Alexander Embiricos：我认为未来岗位之间的界限会变得越来越模糊。产品开发确实需要有人能把控细节，但需要把控的细节内容会不断演变。这就像现在开发者写Swift代码时，完全不需要懂汇编语言一样。当然，世界上还是有一小部分人掌握着汇编语言，而且这些专业人才的存在也很重要，可能掌握的人还不止一小部分，但汇编语言编程已经成了大多数公司都不需要的专业技能。
所以我认为，技术的抽象层级会自然而然地不断提升。而现在，我们正进入一个全新的抽象层级——自然语言层。自然语言的优势在于它的灵活性极高，工程师既可以用它来讨论开发计划，也可以撰写产品规格说明，甚至还能描述一个产品构想。所以我们也可以借助自然语言，不断向更高的抽象层级迈进。
不过我觉得这个过程会是循序渐进的，不会一蹴而就。不会突然就出现所有人都不用写代码、只靠规格说明就能开发产品的情况。这个演进过程更可能是这样的：首先，人们会把Codex配置成擅长构建预览版本、运行测试用例的工具——这可能是大多数人最先实现的功能；接着，再优化它的能力，让它能执行编译构建、查看自身修改结果的任务。当然，要实现这些功能，还需要搭建完善的集成工具环境。
拿Atlas项目举例，我不确定他们是否已经实现了这些功能，但我觉得他们应该已经做了不少相关工作，或许下一步就是让Codex加载一些测试网页，验证功能的运行效果。然后我们再继续优化配置，实现更多功能。至少在未来一段时间内，还需要人类来筛选和配置Agent（agent，指能自主感知环境、做出决策并执行任务的 AI 实体）需要对接的接口、系统和组件。而在更遥远的未来，我们会实现更大的突破：Codex或许能自主给出配置方案，甚至直接在代码仓库中完成自我配置。
Lenny：这是一个非常疯狂的时代。我很好奇，这种研发效率的大幅提升会带来哪些间接影响？比如，产品开发速度变得这么快，是不是意味着市场推广会变得更加重要？是不是好的创意会变得更有价值？思考这些变化的影响真的很有意思。
Alexander Embiricos：我也很想听听你的看法。不过在我看来，创意的价值或许并不像很多人想象的那么高。我依然认为，高效的执行能力才是最难能可贵的。毕竟，你可以快速开发出一款产品，但要把它运营好，让它具备清晰的定位和完整的功能，依然需要付出很大的努力。当然，市场推广的重要性确实是毋庸置疑的。
Lenny：是的，感觉现在除了构建部分，其他所有环节都变得更重要了，包括创意、上市、获利等。
Alexander Embiricos：我觉得我们之前可能处于一个特殊的过渡阶段。在那个阶段，产品开发的门槛极高，所以公司只要专注于提升研发能力就够了，甚至不需要对目标用户有太深入的了解。但现在，情况已经变了。如果让我只选一个核心竞争力，我会选择对目标用户需求的深度洞察。我认为，这才是企业最根本的立足之本。
所以，如果你现在创业，并且对特定用户群体的痛点有着深刻的理解，那你就已经成功了一半；但如果你只是擅长搭建网站这类技术开发工作，却没有明确的目标用户，那创业之路可能会走得非常艰难。
Lenny：听你这么说，你是看好垂直领域AI创业公司的发展前景。没错，我完全同意这个观点。市场上确实存在两类产品：一类是能解决多种问题的通用型工具，另一类则是深耕某一细分领域的垂直产品——比如专注于优化演示文稿制作，比任何人都更懂演示文稿相关的痛点，并且能无缝融入用户的工作流程，针对性地解决这类特定需求。这个方向真的很有前景。
说到Codex的研发进展，我猜想你们内部应该有很多评估指标（ZP注：Evals，指对模型性能进行的评估测试），同时也会参考各类公开基准测试（ZP注：Benchmarks，指用于对比模型性能的标准测试集）。你们是通过哪些指标来判断产品是否取得了显著进展的？我知道肯定不会只看单一指标，所以想了解一下你们重点关注的方向，以及正在努力推进的KPI有哪些？
Lenny：当你考虑Codex的进展时，我猜你们应该有很多评估和公共基准。你会关注哪些方面来告诉自己，“好，我们正在取得非常好的进展”？我想这不可能是一个单一的因素，但你们最关注的是什么？你们在推动什么？有什么关键绩效指标（KPI）？
Alexander Embiricos：我时常提醒自己，Codex这类工具，用户很容易发展成重度用户。这就意味着，我们很容易不自觉地把大量精力投入到开发那些深度功能上——也就是那些只有用户深度使用产品后才会用到的功能，最终可能会在这方面过度投入资源。因此，我认为关注7日留存率（ZP注：D7 retention，产品运营术语，指用户注册7天后仍会使用产品的比例） 这类指标至关重要。我们还会以全新用户的身份重新体验产品，从注册开始一步步操作。为了能以最真实的方式进行内部试用，我用自己的谷歌邮箱注册了好几个ChatGPT Pro账号，这些账号每个月要花掉我差不多200美元，我得走报销流程才行。但在我看来，亲身体验普通用户的使用感受，同时密切关注早期留存数据，对我们来说依然是重中之重。毕竟，尽管这个赛道现在发展得如火如荼，但整体而言，Agent工具的用户普及度仍处于非常早期的阶段。
另外，我们团队可能是这个领域里最热衷于收集用户反馈、关注社交媒体舆情的团队之一。我们有几位同事会时刻关注Reddit和Twitter上的相关讨论，平台上既有对产品的赞扬，也充斥着大量的吐槽和抱怨。而我们会高度重视这些负面反馈，认真研究和分析。因为Coding Agent的应用场景非常广泛，往往会在某些特定功能上暴露出问题。所以我们会经常监测社交媒体上的用户舆论倾向。特别是 Twitter的氛围会更偏向炒作，而Reddit上的评价虽然更尖锐，但也更真实客观。因此，我现在越来越关注Reddit上用户对Codex实际使用体验的讨论。
Lenny：这对大家来说非常重要，能告诉我你们常关注哪些subreddits吗？是不是有像r/Codex这样的板块？
Alexander Embiricos：嗯，算法其实很擅长推荐相关内容，但r/codex确实存在。
Lenny：这点对很多人来说都很有参考价值。你们最常关注哪些SubReddit？有没有专门讨论Codex的r/Codex版块？
Alexander Embiricos：平台的算法其实很智能，会主动推送相关内容。不过确实是有r/Codex这个子版块的。没错。Twitter的互动模式更偏向一对一交流，哪怕是公开推文也是如此；而Reddit有一套完善的投票机制，而且上面的用户大概率还是真人——虽然也不能完全确定没有机器人账号。所以从Reddit上，我们能更清晰地捕捉到哪些内容是用户真正关心的，以及大家对产品的真实看法。
Lenny：那我想简单聊聊Atlas浏览器。你们推出这款产品的时候，我还发过一条推文，说我试用了Atlas，但不太喜欢它那种纯AI驱动的搜索体验。有时候我就是想直接用谷歌搜索，而不是等着AI生成答案。而且当时的版本还没有切换搜索模式的选项，所以我就发推文说 “我还是换回原来的浏览器吧，这款体验不太好”。我感觉这条推文可能让OpenAI的一些产品经理有点难过。不过后来我看到有人发推文说，Atlas已经新增了相关功能。我猜想这个功能其实早就规划好了，这或许就是你们的产品迭代策略——先把产品推向市场，观察用户的实际使用情况，然后再针对性地优化调整。所以我想问两个问题：第一，这件事背后有没有什么值得分享的细节？第二，我很好奇，你们为什么要研发一款网页浏览器呢？
Alexander Embiricos：我之前参与过一段时间的Atlas项目，但现在已经不负责相关工作了。不过我可以从个人角度聊聊这个项目的初衷。我之前创办过一家做屏幕共享和结对编程（ZP注：Pair Programming，指两名程序员共用一台电脑协作开发的模式）的创业公司，后来我们团队加入了OpenAI。当时我们的核心想法是打造一款情境感知桌面助手（ZP注：Contextual Desktop Assistant，指能感知用户当前操作场景并提供针对性帮助的智能工具）。我之所以认为这个方向很重要，是因为我发现，用户要先向智能助手提供大量上下文信息，才能让它提供有效的帮助，这个过程其实非常繁琐。但如果智能助手能主动理解用户当下的操作意图，就能最大限度地提升用户的工作效率。
其实在我看来，Codex本质上也算是一种情境感知助手，只不过它是从代码开发这个垂直领域切入的。至少就我个人的想法而言，很多工作都是在网页端完成的，如果我们能打造一款浏览器，就能以一种更原生、更优质的方式实现情境感知功能。我们不用再去适配其他桌面软件——这些软件对辅助功能树（ZP注：Accessibility Tree，指用于辅助技术解析网页内容的树形结构）的支持程度参差不齐；也不用依赖截图技术，毕竟截图不仅速度慢，而且可靠性不高。相反，我们可以直接深入浏览器的渲染引擎（ZP注：Rendering Engine，浏览器核心组件，负责解析和显示网页内容），提取我们需要的各类信息来为用户提供帮助。
我还喜欢用电子游戏来打比方，不知道你有没有玩过《光环》（Halo）这类游戏？当你走到某个物体旁边时——很多游戏其实都是这样的，我都有点不好意思说，毕竟已经过去很久了——按下X键，游戏角色就会做出相应的正确操作。我以前买每一款电子游戏，都会认真阅读说明书。我还记得第一次在说明书上看到 “情境交互”（ZP注：Contextual Action，指根据玩家所处场景触发的对应操作）这个概念时，就觉得这是个非常酷的设计。而情境交互的核心在于，首先要理解用户当下的操作意图，掌握一定的上下文信息，然后才能提供恰到好处的帮助。
我认为这一点至关重要，因为我们可以设想这样一个未来场景：Agent每天要为用户提供数千次帮助，如果它只能通过推送通知的方式告知用户 “我帮你完成了这件事，你觉得怎么样”，那用户每天就要收到上千条推送，这显然会让人不胜其烦。但换个角度想，回到软件工程的工作场景：假设我正在查看数据仪表盘，发现某个核心指标出现了下滑，这时AI可以主动介入分析，然后在我查看仪表盘的当下，直接给出它对指标下滑原因的判断，甚至提供对应的解决方案。这种方式不仅能让我保持工作的沉浸感，还能让Agent处理更多事务。
所以在我看来，我们研发浏览器的部分原因就在于，通过浏览器，我们能更精准地捕捉用户的上下文信息，从而明确应该在哪些场景下提供帮助。同时，用户也能更好地掌控哪些内容愿意让我们的工具访问——比如，如果你希望Agent处理某项任务，就可以在这款AI浏览器中打开相关内容；如果不想，那就用其他浏览器。这样一来，用户的控制权和使用边界就非常清晰了。此外，我们还能在浏览器中设计人机混合主动交互（ZP注：Mixed Initiative，指人类和Agent共同主导交互流程的模式） 的用户体验，让Agent在合适的时机主动提供情境化操作建议，而不是随意推送通知打扰用户。
Lenny：听你这么说，Codex的愿景是成为一款超级助手，它的作用不只是帮人写代码，而是像一个超能搭档一样，在工作中为你提供各种各样的帮助，让你在工作中表现得更加出色。我现在完全明白了。说到这里，Codex有没有什么非工程领域的常见应用场景呢？我们之前聊过设计师用它来制作原型和开发功能。除此之外，有没有什么非工程师群体使用Codex的有趣或者出人意料的方式呢？
Alexander Embiricos：其实这类用法有很多，都挺出人意料的。不过目前来看，真正能让用户产生高粘性的场景，大多还是和编程相关，或者是偏技术导向的领域——这些领域往往已经形成了成熟的生态系统，比如数据分析这类工作。我个人预计，未来这类跨领域的应用场景会越来越多，但就现阶段而言，我们团队的精力还是高度集中在编程相关的功能上，毕竟这个方向还有大量的工作要做。
Lenny：对于那些想尝试使用Codex的人来说，它是否适用于所有类型的代码库？它支持哪些编程语言？比如如果是做SAP相关的开发，能不能接入Codex来开展工作？它的优势应用场景是什么？又有哪些场景目前的表现还不够理想？
Alexander Embiricos：你问的这个问题其实非常关键。尝试使用Codex的最佳方式，就是把你最棘手的任务交给它，这一点和其他一些Coding Agent不太一样。有些工具可能会建议你从简单的任务入手，或者随意写点代码来判断自己是否喜欢这款工具。但我们打造Codex的定位，是让它成为一款专业级工具，你可以放心地把最难解决的问题交给它，让它在庞大的代码库中生成高质量的代码。当然，它现在的表现还谈不上尽善尽美。
所以，如果你打算尝试Codex，最好用一个真实的工作任务来测试它，不必特意把任务简化成无关紧要的小事。比如，你遇到了一个很难排查的bug，不知道问题出在哪里，就可以让Codex帮忙分析原因，或者直接编写修复代码。
Lenny：这个回答我太喜欢了，直接把最难的问题交给它就行。
Alexander Embiricos：不过我得补充一句，如果你说 “我现在最难的问题是要打造一个能估值超10亿美元的独角兽企业”，那显然Codex目前还做不到，至少现在还不行。所以我的建议是，交给它的任务得是那种最难，但本质上还是一个独立的问题或单一任务的工作。刚开始试用的时候可以这样操作，之后再慢慢摸索，学着用它来处理更大型的项目。
Lenny：好的。那它支持哪些编程语言呢？
Alexander Embiricos：我们训练Codex的方式，决定了它支持的编程语言分布，和这些语言在现实世界中的使用频率是基本一致的。所以除非你用的是那种非常冷门的编程语言，或者是某些企业内部的私有编程语言，否则Codex在你使用的语言上应该都能有不错的表现。
Lenny：如果是新手刚开始使用Codex，你有没有什么小技巧可以分享，帮助他们更好地使用这款工具？比如，要是你能悄悄给第一次配置Codex的用户一个建议，让他们获得良好的使用体验，你会说些什么？
Alexander Embiricos：我可能会建议他们并行尝试几件事。比如，既可以把一个难题交给它，也可以让它帮忙理解某个代码库的结构，还可以和它一起围绕某个想法制定开发计划，然后循序渐进地深入使用。这里面的核心思路是，你其实是在和一个新的团队伙伴建立信任。你不会刚认识一个同事，就毫无铺垫地丢给他一个任务。你应该先让他熟悉代码库，然后和他对齐工作思路，再让他一步步推进工作。
如果你用这种方式来使用Codex，就会自然而然地摸索出和它交互的不同Prompt技巧。因为它确实是一款功能极其强大的Agent和模型，但给Codex写Prompt的方式，和给其他模型写Prompt还是有点不一样的。
Lenny：我还有几个问题想问。第一个问题，随着AI在代码编写方面的参与度越来越高，一个老生常谈的问题也随之而来：我们还应该学习编程吗？为什么要花时间做这件事？对于那些正在规划职业方向的人，尤其是有志于从事软件工程、计算机科学领域工作的人，你觉得计算机科学领域有哪些知识板块会变得越来越重要？又有哪些内容其实已经没必要再花太多精力去关注了？在AI日益融入工作场景的趋势下，大家应该着重培养哪些技能？
Alexander Embiricos：这个问题可以从几个角度来分析。首先，最容易想到的一点是，要做一个实干派。随着Coding Agent的能力不断提升，即便是大学生或者刚毕业的新人，能完成的工作也远比以前多得多。所以我认为，大家应该充分利用这个优势。
说实话，在招聘职场新人的时候，我很看重的一点就是，他们能不能熟练运用最新的工具来提高工作效率。他们本该如此，而且从这个角度来看，新人相比资深从业者的劣势其实变小了——因为这些强大的Coding Agent，正在缩小不同资历人员之间的能力差距。所以这方面的建议就是：你可以学习任何自己感兴趣的内容，但一定要花时间去实践，而不只是完成课后作业。
不过从另一个角度来看，理解一个优秀的软件系统是如何构建的，这一点依然至关重要。我认为，像扎实的系统工程能力，以及高效的团队沟通协作能力这类技能，在未来很长一段时间内都会很重要。我并不认为，AI Coding Agent很快就能在没有人类协助的情况下，独立构建出完美的系统。这个过程会是循序渐进的。
就拿我们之前聊到的Atlas项目来说，有一位工程师就为Codex搭建了一套能让它自我验证工作成果的机制。考虑到Atlas项目的特性，这件事其实并不简单。他的做法是，不断给Codex发送Prompt：“你为什么无法验证自己的工作成果？赶紧修复这个问题。” 通过这种循环优化的方式，最终实现了这个功能。由此可见，在Agent工作的不同阶段，依然需要人类参与其中，帮助配置Agent，使其更高效地工作。所以，人类依然需要具备对系统进行逻辑推理的能力。这么说吧，或许快速敲代码的能力，或者精准掌握如何编写某个循环语句、如何实现某个特定算法这类技能，已经没那么重要了。但你必须能够理解不同的系统架构，知道怎样才能打造一个高效的软件工程团队。我认为这才是另一个非常重要的能力。
最后，还有一个可以切入的角度：如果你能深耕某个领域的前沿知识，我觉得这也是一件非常有意义的事。一方面是因为，Agent在这类前沿领域的表现还不够好；另一方面是因为，当你试图推进某个领域的技术边界时，会自然而然地倒逼自己去充分利用Coding Agent，借助它们来加速自己的工作流程。
Lenny：你说的深耕前沿领域，能不能举个例子？
Alexander Embiricos：比如，Codex会编写大量代码，用于辅助管理自身的训练过程和核心基础设施。我们的工作节奏很快，Codex的代码审查功能帮我们发现了很多错误，其中还包括一些非常有意思的配置错误。而且我们已经看到了一些未来的雏形：我们开始让Codex参与到自身训练的应急值守（ZP注：on call，IT运维术语，指负责处理突发故障的值班工作）中，这个应用场景其实非常有意思，里面大有文章可做。
Lenny：等等，让Codex参与自身训练的应急值守是什么意思？是不是说，当它在进行训练的过程中出现故障，需要人工介入的时候，它会主动发出警报，还是会直接自行修复问题，然后重启训练？
Alexander Embiricos：这其实是我们正在探索的一个早期想法。它的基本思路是这样的：在模型训练过程中，会产生大量的数据图表，目前这些图表都是由人工来监控的，这项工作非常关键，我们把这个过程叫做 “人工盯控”（babysitting）。
Lenny：我猜这是因为模型训练的成本非常高昂，而且快速推进项目进度也很重要。
Alexander Embiricos：没错。模型训练的背后涉及大量的系统，任何一个系统都有可能出现故障，或者在某个环节引入错误。这时候我们可能需要修复问题、暂停训练，或者采取其他应对措施。所以我们的想法是，让Codex持续运行一个监控循环，评估这些数据图表的实时变化趋势。通过这种方式，我们就能大幅提升模型训练的效率。
Lenny：这个想法太赞了，这绝对是Agent未来的发展方向。Codex的作用不只是编写代码，它能做的事情还有很多很多。好了，最后一个问题。既然你在 OpenAI工作，我必须得问问你对通用AI实现时间线的看法，你觉得我们离实现通用AI还有多远？我知道这不是你负责的领域，但现在关于这个话题有很多不同的观点和时间预测。在你看来，我们距离实现具备人类智能水平的AI——无论你如何定义这种智能——还有多久？
Alexander Embiricos：在我看来，这件事的关键在于，我们什么时候能看到技术发展的增长曲线出现指数级跃升，也就是我们常说的 “曲棍球杆式增长”（Hockey Stick）。目前制约技术发展的因素有很多，但我认为有一个因素没有得到足够的重视，那就是人类的打字速度，或者说人类编写Prompt时的多任务处理速度。
就像我们之前聊到的，Agent可以实时监控你的所有工作，但如果它无法自主验证工作成果，那么人类就依然会是效率瓶颈。所以我的观点是，我们需要打破这种由人类手动编写Prompt、手动验证所有工作成果所造成的效率限制。如果我们能够重构系统，让Agent默认就能主动提供有效的帮助，那么技术发展的指数级增长就会随之而来。
不过，我认为这个过程不会是一蹴而就的，它会高度依赖具体的应用场景。比如，我可以预见，到明年，如果一家创业公司要开发一款新的应用程序，它完全可以搭建一套技术架构，让Agent在其中发挥高度自主的作用。但反过来，如果是像SAP这样的企业，它们拥有大量复杂的系统，显然不可能在一夜之间就让Agent完全自主地处理这些系统的相关工作。它们必须循序渐进，或许要逐步替换或升级现有系统，才能让Agent端到端地处理更多工作。
所以，回到你的问题，我的详细回答——可能听起来有点枯燥——是：从明年开始，我们会看到一些早期采用者的工作效率出现指数级提升。在接下来的几年里，越来越多的大公司也会迎来效率的爆发式增长。而在这个过程中的某个模糊的时间点上，这种效率的提升会反过来推动AI实验室的技术突破，届时我们基本上就可以认为通用AI的时代到来了。
AI时代别死磕写代码！这3项能力才是未来硬通货
Lenny：这个回答太务实了，这个话题也是我的播客经常会聊到的——审核AI生成的所有内容，这件事实在是太麻烦了，而且已经成为了一个巨大的效率瓶颈。你们正在攻克这个难题，我觉得非常棒。让编程变得更高效是一回事，而解决最后那个关键问题——验证AI生成的内容是否真的可靠——则是另一回事。你认为人类的打字速度是制约技术发展的关键因素，这个观点真的很独特，我以前从来没有听过这种说法。这其实也印证了你之前提到的一个观点：即便AI的技术水平不再提升，只要我们能学会更高效地使用现有的工具，依然可以释放出巨大的潜力。Alexander，我们今天聊了很多内容。有没有什么我们没谈到，但你想补充或者强调的事情？在进入激动人心的快问快答环节之前，你还有什么想说的吗？
Alexander Embiricos：我想提一件事，Codex团队目前正在扩招。正如我刚才所说，我们现在的工作效率，在一定程度上还是受到人类思考速度和打字速度的限制，我们正在努力解决这个问题。所以，如果你是工程师、销售人员，或者是想从事产品相关工作的产品人，都欢迎联系我们。我不太确定提供联系方式的最佳方式，不过大家可以去查看我们的招聘页面，或者通过你进行联系？你的听众有什么方式可以联系到你吗？
Lenny：如果他们想通过我联系你，说 “我想申请加入Codex团队”，我的个人网站上有一个联系表单。不过我有点担心，到时候会有太多优秀的人才来找我。不过没关系，大家可以试试这个方式，看看效果如何。
Alexander Embiricos：好的。或者——当然这段内容之后可以剪辑掉，取决于你的安排——大家也可以直接给我发私信。比如，我在Twitter上的账号是Embiricos，如果你有兴趣加入我们的团队，欢迎随时私信我。
Lenny：这绝对是很多人梦寐以求的工作机会。你有没有什么筛选应聘者的小妙招，避免自己的收件箱被求职信淹没？
Alexander Embiricos：具体来说，如果有人想加入Codex团队，那么他首先得是一名技术从业者，并且正在使用这类AI工具。我建议每个人都先问自己一个问题：“假设我加入 OpenAI，在未来六个月里全身心投入Codex的相关工作，并且做出了出色的成绩。那么到那个时候，软件工程师的工作状态会变成什么样？” 在我看来，如果你能对这个问题有自己的见解，就可以提交申请了；如果你对此没有想法，需要先花时间思考一下，那么这个思考的过程，其实就是一种筛选机制。
现在有很多人都在关注这个领域的发展，我们非常希望能吸引到那些已经深入思考过Agent未来发展形态的人才。当然，我们不一定非要在未来的发展方向上达成共识，但我们希望找到那些对这个领域抱有极大热情的人。
关于Embiricos本人的五个问题
Lenny：能参与一款影响力如此巨大、且处于技术前沿的产品研发，这样的机会非常难得。对于合适的人来说，这绝对是一份超棒的工作。你们现在有岗位空缺，而我的听众群体恰好可能非常契合这个岗位的需求，这真是太好了。希望我们能帮你们找到一位极其优秀的人才。好了，接下来我们进入激动人心的快问快答环节。Alexander，我准备了五个问题，你准备好了吗？
Alexander Embiricos：虽然不知道会问什么，但我已经迫不及待了，开始吧。
Lenny：这些问题除了最后一个，其他的我都会问每位嘉宾。所以可能没什么惊喜，或许我以后该多准备些不一样的问题。好的，第一个问题：你最想推荐给大家的两三本书是什么？
Alexander Embiricos：我最近读了很多科幻小说。我知道这本书应该已经被推荐过很多次了，就是《文明》系列，作者应该是伊恩・班克斯。我喜欢这套书的原因是，它描绘了一个AI共存的未来世界，而且是一个充满希望的未来。要知道，很多科幻作品的基调都比较反乌托邦。我觉得用这个虚构的文明世界作为参照，去思考我们能开创怎样的未来，以及当下应该做出哪些决策来推动这样的未来到来，是一件很有意思的事。
Lenny：哇，我好像从没听过有人推荐这本书。我记得你在录制开始前提过，你最近在看《指环王》。如果你还想读一些和AI相关的科幻小说，有没有读过《深渊上的火》？
Alexander Embiricos：没有，我没读过。
Lenny：这本书非常精彩，算是一部太空歌剧式的宏大科幻史诗，里面还涉及到了超级智能的设定。
Alexander Embiricos：听起来不错。
Lenny：这本书的基调不算完全乐观，但也带有一定的希望色彩。好的，下一个问题：最近有没有什么特别喜欢的电影或者电视剧？
Alexander Embiricos：有一部叫《咒术回战》的动漫，我特别喜欢。这部作品的题材有点暗黑，和咒灵有关，但我喜欢它的点在于，主角是个非常善良的人。我发现现在动漫和动画领域出现了一种新趋势，主角不再是过去那种形象，而是变得非常友善，心怀天下。你看以前那些开创了这类题材的经典动漫，比如《新世纪福音战士》或者《阿基拉》，里面的主角都有着明显的性格缺陷，活得很痛苦。当然，这些作品算不上是题材开创者，但曾经有很长一段时间，动漫界都在调侃一个设定：让一个十几岁的少年背负起拯救世界的重任。所以当时出现了一批作品，通过刻画主角在剧情中遭遇严重的精神危机，来批判这种不合理的设定。我并不是说现在的新趋势就一定更好，但看到这些充满正能量的主角，一心一意想帮助身边的人，真的会觉得很有意思。
Lenny：从这些推荐里，我好像更了解你的性格了，喜欢善良的主角，喜欢乐观的未来。
Alexander Embiricos：我觉得吧，如果你自己都不相信一件事能实现，那你就不可能真正把它变成现实。这其中需要一种平衡。
Lenny：你最近有没有发现什么特别喜欢的产品？可以是一款应用、一件衣服、一个厨房用具、一个数码产品，甚至是一顶帽子都行。
Alexander Embiricos：我其实对内燃机和汽车很感兴趣。我当初来美国的初衷，就是想从事和美国航空飞行器相关的工作，但现在却投身于软件行业。在很长一段时间里，我开的都是一些很老旧的跑车，选择老车主要是因为价格更实惠。不过最近我换了一辆特斯拉，说实话，特斯拉的车机系统让我很受启发，尤其是它的自动驾驶功能。今天我也多次提到，我认为打造人机协同型软件（Mixed Initiative Software） 是一件很值得探索的事——这类软件既能最大限度地赋能人类，让用户掌控主动权，又能为用户提供强大的助力。我觉得特斯拉在这方面做得非常好：它允许车辆自动驾驶，但用户不需要关闭自动驾驶功能，就能通过多种方式干预车辆的行驶状态。比如你可以踩油门加速，车辆会响应你的操作；你可以转动旋钮调整车速，也可以轻轻转动方向盘改变方向。我认为特斯拉打造的这种智能驾驶系统，堪称是Agent设计的典范，既实现了自动化功能，又保留了人类的控制权。
Lenny：这让我想到了Nick Turley的那句口头禅 ——“我们是否实现了效率的最大化提升？” 这句话似乎已经渗透到了OpenAI的方方面面，这也合情合理。好了，还有两个问题。你有没有什么人生格言，会经常在工作和生活中想起，并且从中获得力量。
Alexander Embiricos：我不确定自己有没有人生格言，但我可以和你分享我之前创业公司的核心价值观。这个价值观直到现在依然影响着我，那就是友善且坦诚（be kind and candid）。我们之所以把这两个品质放在一起，是因为作为创始人，我们意识到，有时候我们会过于追求表面的和气，但这其实并不是正确的做法。我们会刻意拖延那些棘手的对话，做不到坦诚沟通。所以每当我们想起这个价值观，就会提醒自己要更加坦诚。但过了六个月，我们又会发现，自己在过去的这段时间里还是不够坦诚，需要做得更好。于是我们就会思考：到底该如何做到坦诚？答案就是，要把坦诚看作是一种善意的行为。而且不仅要在行动上主动践行，在向他人表达观点时，也要注意表达方式。
Lenny：这真是对优秀领导力的绝佳诠释。这让我想到了一本书 ——《敢挑战，才关怀》，讲的就是 “彻底坦诚” 的理念。你的这个价值观，其实就是 “彻底坦诚” 的另一种表述。好的，最后一个问题：我之前特意查了你的姓氏，想了解一下背后的故事。你的姓氏是恩比里科斯，我问过ChatGPT，它告诉我这个姓氏最有名的人物，是希腊有影响力的诗人兼精神分析学家安德烈亚斯・埃米罗斯，以及他的亲戚——富有的船运大亨、艺术收藏家乔治・穆雷奥斯。所以我的问题是：你更认同这两个人中的哪一个？是那位希腊诗人兼精神分析学家，还是那位船运大亨兼艺术收藏家？
Alexander Embiricos：我想我应该更认同那位诗人，因为他热爱我们家族的故乡——一座希腊小岛。我们家族是个大家族，你知道的，希腊的家族都很大，几乎每个人都能扯上亲戚关系，感觉所有人都是你的叔叔。我母亲是马来西亚人，在马来西亚那边，也差不多是这种情况，每个人都像是我的叔叔阿姨。言归正传，那位诗人深爱着我们家族的发源地——安德罗斯岛。我不太清楚那位船运大亨住在哪里，应该是在纽约吧。总之，我们的祖籍都在安德罗斯岛，那是一个非常美丽的地方，岛上的牲畜比人还多，也没有太多游客打扰。我觉得特别酷的一点是，那位诗人发表了很多作品，其中很大一部分都在描绘这座小岛的美，这一点让我很有共鸣。
Lenny：这个回答太棒了。我再追加两个问题：如果大家想在网上关注你，或者联系你，应该去哪里找你？另外，听众们可以通过哪些方式帮到你们？
Alexander Embiricos：我属于那种只把社交媒体当作工作工具的人。我的手机晚上九点之后，屏幕就会变成黑白色，以此减少使用时间。不过大家可以在Twitter（X）上找到我，账号是Embiricos。另外，如果大家在Reddit的r/Codex子版块发帖，我大概率也能看到。至于听众们能提供什么帮助，我想说：请大家一定要试试Codex，并且踊跃分享使用反馈，告诉我们需要改进的地方。我们非常重视用户的反馈。说实话，Codex目前的发展势头虽然很好，但整体还处于非常早期的阶段，所以我们会一直重视用户反馈，并且希望能一直坚持下去。另外，如果有人有志于投身Coding Agent乃至通用Agent的未来发展事业，欢迎大家通过我们的招聘网站投递简历，或者通过刚才提到的社交媒体渠道联系我。
Lenny：Alexander，今天的访谈太精彩了。我一直很喜欢和AI领域的从业者交流，因为在这之前，AI给人的感觉总是有点冰冷、可怕，还带着一丝神秘色彩。但当你真正认识了这些打造AI工具的人之后，就会发现他们都非常棒。尤其是你，为人特别友善，从你分享的内容里也能感受到你的乐观和善意。这正是我们希望看到的——由这样一群人来打造驱动未来的工具。非常感谢你今天做客我的节目，也很荣幸能认识你，真的太感谢了。
Alexander Embiricos：也谢谢你的邀请，今天聊得很开心。
原文：Why humans (not compute) are AI’s biggest bottleneck | Alexander Embiricos (OpenAI)
https://www.youtube.com/watch?v=z1ISq9Ty4Cg
编译：Yihan Bi
请注意，本文编译自文末载明的原始链接，不代表Z Potentials立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。
Z Potentials将继续提供更多关于AI、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。
-----------END-----------
粤ICP备14082021号
免费POC，
零成本试错
