自 8 月 GPT-5 发布以来，Codex 展现出惊人的爆发力，用户增长 20 倍，每周处理数万亿 tokens，成为了 Open AI 最受欢迎的编程智能体。

“Codex 能快速实现 20 倍的增长，不只是因为模型变强了，还因为我们理解了，真正的智能体不是一个模型，而是模型、API 和框架共同努力的结果。”在最新播客中，OpenAI 的编程智能体 Codex 产品负责人 Alexander Embiricos 揭露背后的秘密。

比如，Codex 在长时任务能力上的突破。为了让它能够连续工作十几个小时甚至数天，团队设计了名为“压缩”的机制——模型负责提炼关键信息，API 承接任务链路，框架负责稳定运行。三层像齿轮般咬合，使 Codex 能够完成传统大模型难以支撑的长时编程任务。

正是这样的底层逻辑，让 Codex 在业务实战中有惊人表现。

Andrej Karpathy 曾公开分享，他被一个 bug 困住数小时，最终交给 Codex 处理，一小时内就完成了修复。

Sora 团队更是依靠 Codex，在短短 28 天时间，从 0 到 1 完成 Android 应用的上线，直接冲到 App Store 第一。

回顾过往，Alexander Embiricos 也坦言，Codex 的路径并非一开始就清晰。

早期的 Codex “太过未来”，采用远程异步交互方式，这符合资深工程师的习惯但对大部分工程师并不友好。而真正的拐点来自一个关键调整：团队将 Codex 从云端迁回本地，让它直接在工程师的 IDE 中工作，才更接地气起来。

目前的 Codex，在 Alexander Embiricos 看来，像一个“聪明但不会主动的实习生，写代码写的很快。”而 Codex 一直在自我监督，自我训练，不断进化。Alexander Embiricos 期待未来 Codex 可以真正参与软件开发的全流程，成为工程师的好队友。

Alexander Embiricos 还谈到 OpenAI 的组织文化，他惊叹于 OpenAI 的速度与野心，迭代速度之快闻所未闻。比起其他组织的“先瞄准，再射击”，他认为 OpenAI 的独特之处，正在于“先射击，再瞄准”，即先发布，再根据真实使用反馈优化路径。而搜集世界最优秀的人才与自下而上的文化，使这种高速迭代成为日常。

对于未来 AGI 会何时到来，Alexander Embiricos 也给出了一个有趣的视角，他认为当前真正的限制 AGI 的因素不是模型能力，而是人类——我们输入速度有限、审查速度有限，正在拖累其发展。

他做了一个预判，第一批生产力曲线出现陡增的用户将在明年出现，其后的变化会加速扩散。“当增长曲线突然变得异常陡峭时，”他说，“我们可能就已经站在 AGI 的门口。”

播客里还分享了更多关于 Codex 背后的细节和 Alexander Embiricos 的精彩观点，我们翻译了该内容，并在不改变原意基础上进行了删减和整理，以飨读者。

播客精彩观点汇集：

• 在 Codex 的帮助下，OpenAI 仅用了几周时间，就凭借两三位工程师的协作，打造出了 Sora 安卓应用，并使其在 App Store 排名第一。Sora 应用从零到员工测试仅用了 18 天，并在 10 天后正式发布。Codex 通过分析现有的 iOS 应用、制定工作计划以及同时比较两个平台来实现功能，从而提供了极大的帮助。

• 即使人工智能模型明天停止改进，我们仍然需要花费数年时间进行产品开发，才能充分发挥它们的潜力。这项技术的发展速度超过了我们目前能够最佳利用它的能力。

• 充分利用 Codex 的关键在于：选择最棘手的问题，而不是最简单的问题。这些工具旨在解决棘手的 bug 和复杂的任务，而不是简单的任务。从那些你平时需要花费数小时才能解决的问题入手。

• OpenAI 最初的 Codex 产品“过于超前”。它以异步方式在云端运行，这对高级用户来说很棒，但对新手来说却很困难。当它将 Codex 带回工程师们日常工作的地方——他们自己的电脑上的代码编辑器——时，其增长速度呈爆炸式增长。过去 6 个月里，Codex 的使用量增长了 20 倍。

• 编写代码可能成为人工智能完成任何任务的通用方式。人工智能与其点击界面或构建单独的集成，不如即时编写小型程序，这样才能发挥最佳性能。这意味着每个人工智能助手都应该内置编码能力，而不仅仅是专门的编程工具。

• OpenAI 的设计师现在编写并发布自己的代码。设计团队维护着一个由人工智能辅助构建的、功能齐全的原型。当他们有了想法，他们会直接编写代码、进行测试，并经常自行提交到生产环境。只有当代码库特别复杂时，工程师才会介入。

• 人工智能生产力的最大瓶颈不是人工智能本身，而是人类的打字速度。限制因素在于你输入提示的速度以及你审查人工智能生成工作的速度。在人工智能能够更可靠地验证自身输出并主动提供帮助之前，我们将无法看到这些工具所能带来的全部生产力提升。

• 编写代码的乐趣正在逐渐被审查人工智能生成的代码所取代。工程师们曾经热爱构建代码的创造性过程，而现在他们却花费更多时间阅读人工智能生成的代码。下一个挑战是如何让代码审查过程更快、更令人满意。

• 新型人工智能模型现在可以连续工作 24 到 60 多个小时来完成单个任务。一种名为“压缩”的技术可以让人工智能在内存耗尽之前总结其学习到的内容，然后在新的会话中继续工作。这使得人工智能能够实现以前无法实现的通宵或多天自主工作。

• 如果你现在要创办一家公司，深入了解特定客户比擅长产品开发更重要。产品开发变得越来越容易。如今，真正的优势在于知道该开发什么产品，以及为谁开发产品。

OpenAI 的速度、文化与用人方式

Lenny：我想先从你在 OpenAI 的经历谈起。你大约一年前加入 OpenAI。在那之前，你创办自己的公司大约五年，再之前你在 Dropbox 担任产品经理。OpenAI 显然是一家与你过去工作过的所有公司都截然不同的地方。我想问，在 OpenAI，最特别的运作方式是什么？你在那里学到了什么，是你认为无论未来走到哪里（假设你有一天会离开）都会带走的？

Alex：到目前为止，我觉得在 OpenAI 工作的节奏和雄心远远超出我的想象。说这句话时我会想到，以前在创业圈，每个人都认为自己的公司速度快、人才要求高、目标宏大，但来到 OpenAI 后，我意识到这些词在这里意味着完全不同的尺度。在 OpenAI，我重新理解了“速度”和“雄心”真正的含义。

我们常听到外界感叹人工智能公司的发展速度快，而我首先想到的例子就是模型本身的爆炸式增长。尽管我们扩大了外部数据规模，但像 Codex 这样十倍级别的模型增长只在几个月内完成，其后的进展又继续加速。至少对我而言，在经历那些阶段之后，我发现自己在打造科技产品时，会自然把目标设定为达到那种速度和规模，否则就会觉得不足。相比之下，我在创业公司所经历的节奏显得慢得多。

创业过程中往往需要权衡投入与失败的可能性：先尝试、再转型。不过在 OpenAI，我深刻意识到影响力之巨大，而要把工作做好，需要投入极高的精力。这种需求迫使我更加果断地安排时间。

Lenny：在继续往下之前，我想追问一件事：像 Codex 这样能迅速推进的团队，是否有某种特别的组织架构或结构性原因？还是因为我对开源软件的运作方式不够了解，所以才让团队能这样快速前进？一定存在一些结构让这一切发生。

Alex：一方面，我们所使用的技术本身就彻底改变了很多事情，包括我们构建产品的方式，以及能够为用户实现的功能。虽然我们经常讨论基础模型的改进，但即使我们停止模型层面的进展（虽然事实上并没有），我们在产品开发方面仍然落后很多，还有大量产品尚未实现。可以说，这个领域的成熟度远高于外界想象。

不过，也有很多让我意外的地方。刚到 OpenAI 时，我对组织架构了解不多。例如，以往在创业公司或在 Dropbox 担任产品经理时，鼓舞团队士气、确保团队朝正确方向前进，是极其重要的标配工作。但在 OpenAI，由于我们并不确切知道近期会出现哪些功能，也不知道哪些功能最终奏效，即便从技术层面可行，也无法确定最终结果，因此需要保持谦逊，通过不断尝试来学习。

这里的组织架构设计为高度自下而上运作，每个人都渴望快速推进。许多公司声称是自下而上，但 OpenAI 真正如此。这对我来说是宝贵的学习经验，也让我意识到未来可能很难再回到非人工智能公司工作。我甚至不确定那意味着什么。如果让我重新回到过去，我的做事方式一定会完全不同。

Lenny：我听到你的描述，感觉更像“预备、射击、瞄准”，而不是“预备、瞄准、射击”。许多人工智能公司的思路似乎是：因为不知道用户最终会怎样使用产品，所以花大量时间把产品做到完美毫无意义。最好的方式是尽快发布，观察人们如何使用，再快速迭代。

Alex：这个比喻有一定道理，但目标成分本身是模糊的。我们大致预测未来可能发生什么，但其中仍有大量不确定性。一位研究主管常说，在 OpenAI，我们可以就一年后的未来展开高质量对话，但越接近那个时间点，反而越难做出理性规划。我们会构想远期未来要实现什么，尤其在人工智能对齐等议题上，我们必须考虑非常长期的未来。但当真正进入产品阶段后，我们会开始关注战术层面的细节，例如具体要构建哪些产品、人们会如何实际使用。产品方面，我们更依赖实证研究来验证。

Lenny：当人们听到你们的做法，会觉得像你这样的公司可以大胆尝试许多事情，并且在未来几个月内不必制定严格计划。但关键是，你们聘用了世界上最优秀的人才，这似乎是让这样的公司取得成功的关键因素。

Alex：这点让我非常有共鸣。我刚加入时，对每个人展现出的个人动力与自主性感到震惊。我认为 OpenAI 的运作方式无法靠阅读一篇文章或听一档播客就复制到其他公司。这样说可能直白，但很少有公司拥有能够以这种方式运作的人才。如果要让这样的模式在别处出现，大概率必须做出许多调整。

Codex 的定位、核心哲学与产品愿景

Lenny：那我们来聊聊 Codex。你是 Codex 的负责人。Codex 现在进展如何？你能分享一些数据吗？另外，也不是所有人都清楚 Codex 是什么，你能解释一下吗？

Alex：Codex 是开源编码智能体，更具体来说，它是一款 VS Code 的 IDE 扩展，你可以安装扩展或终端工具。安装后，你可以与 Codex 互动，回答与代码相关的问题，编写代码，运行测试，执行代码等，也就是软件开发生命周期中最繁重的部分——实际编写将被部署到生产环境的代码。

更广泛来说，我们认为 Codex 是软件工程团队成员的起点。当我们谈到“队友”这样的词时，我们设想的并不仅是让它编写代码，而是让它参与软件编写的整个流程，从构思、规划，到下游的验证、部署与维护。

我喜欢把今天的 Codex 想象成：一个非常聪明的实习生，但不会查看 Slack，也不会主动检查像 Sentry 那样的监控系统，除非你要求它这么做。因此，即使它非常聪明，你也不会完全放手让它在无人监督的情况下编写代码。现在大多数人使用它的方式仍然是与它结对编程。

但我们希望未来能达到这样一种程度：就像你雇佣新实习生一样，不只是让他们写代码，还让他们参与整个流程。即使他们第一次尝试不完全正确，他们会持续参与并通过迭代最终实现目标。

Lenny：我理解你提到的 “不会看 Slack” 的意思，是说它不会分心，总是全神贯注在工作上。但你的意思是它无法掌握正在发生事情的完整背景，对吧？对于团队中最优秀的成员来说，你不会告诉他们每一步该怎么做，你只是在最初几次会议中让他们了解你的沟通方式，然后他们就能在团队中独立工作，甚至主动与代码库的其他部分协作。

Alex：是的，我们认为一个真正优秀的队友应该是积极主动的，而 Codex 的一个主要目标就是让智能体具备这种积极主动性。我认为这是实现 OpenAI 使命的重要部分——让人工智能真正造福全人类。

当下的人工智能产品实际上很难使用，因为用户必须非常明确地思考何时向模型寻求帮助。如果你不主动发出请求，模型就无法提供帮助。如今，一个普通用户可能每天只向人工智能发出几十次指令。但如果一个系统真正智能，人类每天能从它获得数千次帮助。

因此，我们与 Codex 合作的大部分目标，是弄清楚如何打造这样一种默认情况下就能提供帮助的“队友智能体”。

Lenny：当人们想到 Cursor 或云端代码工具时，它们像集成开发环境，能辅助写代码、自动补全等。我听出你描述的愿景不同，你指的是一个真正像远程队友一样为你构建代码的系统。你可以与它对话，让它执行操作，同时也拥有 IDE 自动补全等功能。你们对 Codex 的思考方式究竟有什么不同？

Alex：我们的目标是让开发者在完成任务时感觉拥有超能力，以更快的速度完成工作，同时不必处处停下来思考“我现在应该如何调用人工智能来完成这件事？”。它应当像系统的一部分一样与你协作，当你做出动作时，它就能自动开始工作，而不需要你为它操心。

Codex 的技术突破、增长动力与三层系统结构

Lenny：我还有很多类似的问题。不过我想先问一下：Codex 的进展如何？有没有一些可以分享的统计数据或数字？

Alex：Codex 自发布以来一直呈现爆炸式增长。GPT-5 在八月份发布，当时我们已经观察到一些非常有趣的产品洞察。如果你感兴趣，我可以详细说明这种增长是如何发生的。我们上次公开的数据是，自八月以来 Codex 的使用增长超过十倍，而现在已经达到二十倍。Codex 模型目前每周服务数万亿级的代币，是我们最受欢迎的编码模型。

我们做的一件重要事情是组建了一个紧密整合的团队，让产品与研究团队共同迭代模型与框架。这种方式让我们可以更快速地开展更多实验，理解模型与工具如何协作。我们训练模型时使用自己的框架，并对框架持有非常明确的观点。最近，我们开始看到其他大型 API 编码客户也采用类似方法，这些模型因此变得更加通用。

如今，Codex 已成为使用最广泛的编码模型，API 中也有相应的版本。

Lenny：你提到过“增长被解锁”，我对此很好奇。在你加入之前，我感觉云端代码几乎统治一切，每个人都在使用它，它是当时最好的代码生成方式。但后来 Codex 出现，我记得 Karpathy 发过一条推文，说他从未见过这样的模型。他遇到一个非常棘手的 bug，花了几个小时都无法解决，结果让 Codex 跑了一个小时，它就解决了。你们是怎么做到的？

Alex：OpenAI 一直有一个非常明确的使命，就是构建 AGI。因此我们持续思考如何让产品能够在更大规模中发挥作用。正如我之前提到的，一个工程师如果能够每天从人工智能那里获得数千次帮助，那才是真正的价值。所以我们不断反思模型与产品应该如何演进。

当我们推出第一版 Codex（Codex Cloud）时，它几乎相当于拥有一台属于你自己的云端计算机，你可以把任务委托给它，这本身就非常惊人。其中一个主要优势是你可以并行运行大量任务。但是，它也有一些挑战，例如环境配置复杂、设置麻烦，以及模型必须通过工具去验证更改、学习如何使用这种提示方式。

以我常用的类比来说，这就像你雇了一位队友，但你永远无法与他实时对话，只能远程、异步来回沟通。对某些人来说，这确实是一种有效的工作方式，也可能成为未来的重要方向。但在早期阶段，它对新用户的门槛非常高。

因此，我们仍然保持“可委派且主动”的愿景，但必须先以更直观的方式让用户从中获得价值。如今，大多数用户是通过 IDE 扩展或 CLI 使用 Codex，让智能体在本地与你协作。你的电脑提供环境，它在沙箱中操作，确保安全可靠，同时可以访问必要的依赖。如果某个命令无法在沙箱中运行，它会询问你，让你介入。这让模型能进入一个强大的“反馈循环”，而我们团队的任务就是让这种反馈循环逐渐成为产品使用的自然副产品。

如果把模型比喻为团队成员，给他一台刚从商店买来的全新电脑——没有密码、没有权限、没有工具——他很难发挥作用。但如果你和他并肩工作几小时，你会不断为他补齐各种权限、工具与操作方式，而在获得这些前提后，他就能独立工作数小时。

因此，我的理解是：最初版本的 Codex 太“未来”，像一个远程云端智能体，以异步方式工作；而你们所做的，是把它重新拉回开发者熟悉的环境，让它在 IDE 本地工作，使用户更容易习惯新的开发方式。

Alex：这很有意思。在 OpenAI 内部，我们长期依赖 dogfooding（自己用自己做的产品）来推进产品的发展。通过在真实环境中持续使用自己的产品，Codex 在过去一年里显著加速了公司的工程进程，不论是云端还是本地版本都让整体效率获得巨大提升。

不过，内部获得的反馈与市场反馈并不完全一致。因为 OpenAI 的工程文化本身就以提示驱动为中心：先通过提示规划任务，再依赖大规模并行执行，最后异步收集结果。这种工作流程对我们来说非常自然，但对大多数外部用户而言却并非直觉，他们并不会天然以模型为中心组织开发。

因此在构建产品时，我们依赖内部信号，但也必须清楚地意识到不同使用者之间存在巨大差异，需要同时为专家和新手提供可理解的工作路径。

Lenny：我很好奇，训练数据在其中是否也发挥了作用。Codex 的进步究竟来自更干净或更好的数据，还是更多来自模型本身的提升？有哪些因素真正推动了它的加速？

Alex：这确实是大家常见的疑问：Codex 的能力提升究竟是因为数据变得更好，还是来自模型本身？实际情况是多方面共同作用。

首先，模型本身确实有巨大提升。就在上周三，我们发布了 GPT-5.1.1 Codex Max，这个名称非常贴切。它之所以出色，是因为在你之前使用 GPT-5.1 Codex 处理的任何任务上，大约能快 30% 完成，同时它的推理能力也显著增强。在更高层次的任务中，它表现得更智能。

你提到 Karpathy 的推文，那类“给我你遇到的最棘手的 bug，我让模型试试”的例子现在明显增多，而 Codex Max 特别擅长处理这些困难问题。这本身就让我们觉得非常激动。

不过我们现在的思考方式有所变化。过去，我们更多认为“只要训练最好的模型就好了”，但现在我们意识到真正的智能体并不只是一种模型，而是由三层结构组成：一个非常智能的推理模型、一套 API，以及一个能让模型发挥能力的框架。

例如，我们非常自豪 Codex 能够连续长时间运行。有时我们甚至收到用户反馈，说模型连续运行了 24 小时或更久。这已经超过传统模型的上下文长度，因此我们必须为此设计出解决方案，也就是“压缩”。模型需要理解压缩的概念，API 必须能接收压缩指令，框架最终负责传递这些信息。三者缺一不可。

市场上各种编码工具各自拥有完全不同的工作方式，有的强调语义搜索，有的依赖自定义工具，有的像我们这样强调 shell 操作。如果想训练一个模型，让它在所有框架下都表现最佳，可能并非不可能，但速度一定会被拖慢。因此，我们在 Codex 中保持明确主张，让它只使用 shell，并在沙盒环境内运行。这让模型能够快速学习适合这一环境的操作行为，也让整个系统更加可靠。

因此，回到你提出的问题，真正的加速来源于我们同时构建这三层结构，并持续针对每一层进行调整，再观察它们如何协同作用。这种紧密整合的产品与研究合作方式，是 Codex 能快速成长的核心原因。

写代码是模型最好的方式与编码智能体的未来

Lenny：从你的描述来看，真正推动 Codex 的，不只是模型能力的提升，而是模型、API 和框架三者共同构成的整体系统。我很好奇，从更高层次来看，你认为人工智能和编码智能体的未来会走向什么方向？

Alex：我认为未来的人工智能智能体会逐渐摆脱“被动工具”的角色，转向“主动队友”的角色。今天，大多数人工智能工具仍然依赖用户提出明确指令，它们并不会主动参与你的工作流程。但一个真正智能的系统应该能够做到默认帮助你，而不是等待你下达命令。

回到软件工程的例子，如果你把人工智能视为队友，那么你不会希望每一个任务都必须以详细指令开始。你希望它能自动理解上下文、自动介入流程，并在你需要之前采取行动。我认为未来的智能体应该能够在软件开发的不同阶段参与，包括规划、构思、验证、部署和维护，不再局限于编写代码。

我们希望模型具备足够的判断能力，能够识别当前任务，理解它在整个开发生命周期中的位置，并根据情况主动采取行动。这不仅是提升效率，而是改变整个开发流程的思维方式。

从更广义的人工智能未来来看，我们的目标始终是构建真正能够造福所有人的人工智能。让智能系统成为世界上每一位使用者的队友，让每个人都能因为人工智能而拥有更高的生产力、更强的创造力，以及更公平的资源获取能力。这是 OpenAI 的使命，也是我们构建这些智能体系统的最终方向。

Lenny：听起来，智能体未来不只是工具，而是真正的团队成员。你刚刚提到 Codex 的构建方式与其他编码产品不同，因为它有非常明确的框架与主张。我想更深入理解这意味着什么。为什么保持这种“强主张”如此重要？

Alex：如果你观察市场上各种编码产品，会发现它们有完全不同的工具框架与非常不同的理念。例如，有些系统主张一切靠语义搜索，有些依赖定制工具，有些让用户自己设计输入方式，而 Codex 的核心主张是让智能体像一个在 shell 中工作的工程队友，并让整个系统围绕这个工作方式展开。

如果我们试图让模型同时适应所有不同的框架，速度会变得极慢。因为模型必须学会彼此冲突的行为方式，而训练过程会被分散、干扰，最终无法做到任何一个方向的最佳表现。保持明确主张，使我们能在一个清晰的环境下快速迭代，并利用沙盒确保安全可靠。

让智能体在 shell 环境中工作不仅是为了熟悉度，也因为它能最自然地与开发者的实际工作流程结合。模型会在一个稳定的环境中执行操作、验证结果、处理依赖，从而形成一个强大的反馈循环。我们再根据这个反馈循环调整模型、API 和框架，让三者形成紧密协作的结构。

因此，真正的加速来自于我们明确地构建模型、API 和框架三层结构，让它们成为一个完整的智能体系统，而不是分散的组件。

Lenny：你觉得在这个领域最终该如何取胜？人工智能是否会一直处在公司之间互相竞争、模型不断互相超越的状态？会不会出现某家公司能够独占鳌头，让其他人永远追不上？是否真的存在一条明确的通往胜利的道路？

Alex：这让我想到一个重要概念：人工智能的未来不仅是拥有几个你认识的队友来帮你写代码，而是拥有一种真正意义上的团队合作精神。工程团队的成员做的事情远远不止写代码，他们会安排日程、移动会议、主动修复问题、提出建议，甚至在你还没开口前就做出正确的行动。现在想象一个世界，几乎每天都有研究实验室发布匪夷所思的新技术，对人类来说要跟上这种节奏，必须依赖这样的团队力量。而人工智能将成为这种团队的一部分。

未来的超级助手应该是这样的存在：你只需要开口，它就知道该怎么帮助你。你不需要学习它的功能，也不需要阅读使用技巧，只要启用它，它就能立即发挥作用。如果我们能构建出这样一个系统，它就会成为一个极具竞争力、也极可能胜出的产品。

Alex：在我看来，聊天是一种非常好的人工智能使用界面，特别是在你不知道该怎么做的时候。就像我在 Teams 或 Slack 里和队友交流一样，聊天是一种自然且通用的方式。我可以提出任何问题，不论是否与编程有关，而一个超级助手应该在这种对话里表现得和队友一样。当你需要深入代码时，你会使用更专门的工具，例如一个深度集成代码环境的智能体。当你只需要表达任务时，聊天就够了。所以我们希望构建的人工智能既像 ChatGPT 这样的通用助手，也能在专业领域，例如编程里，发挥深度能力。就像 ChatGPT 已经成为很多人生活的一部分一样，你甚至在工作之外也会使用它。等你开始工作时，你自然会说：我直接问它就好了。我不需要了解所有功能连接器，它会告诉我它能做到什么，甚至会在我没提问时主动提供帮助。如果我们能达到这样的状态，我认为这就是一条构建成功产品的道路。

Lenny：我和 ChatGPT 负责人 Nick Charlie 聊过，他说 ChatGPT 的最初名字其实非常接近“超级助手”。看起来这一条超级助手的路线，与编码智能体的路线几乎像是 B2C 和 B2B 两种版本。一个更偏面向大众，一个更偏团队应用、编写代码、自动执行各种任务。这也是你们的设计理念吗？就像企业版的 ChatGPT？

Alex：我们现在讨论的内容横跨大约一年的产品演进时间，许多事情可能会发生得很快，也可能还需要时间。不过我可以解释其中的逻辑。要构建一个超级助手，它必须能够真正“做事”，并不是停留在生成文本的层面。

过去一年我们学到的一个核心经验是：模型要真正发挥作用，必须能够使用电脑，而且需要能够熟练使用。于是我们开始思考，模型应该以什么方式使用电脑。理论上可以尝试模拟操作系统或使用鼠标式的点击，但这些方式既慢又不稳定。事实证明，最强大、最可靠的方式，就是让模型通过编写代码来操作电脑。编码是人工智能最自然、最高效的行动方式。因此我们越来越明确地意识到，如果你想构建一个通用智能体，它其实一定会具备编写代码的能力。即使用户不是工程师，他们也可能不会意识到智能体正在通过写代码完成任务。就像人们不关心自己是否在使用互联网，只会问 Wi-Fi 有没有连上一样。

这也是我们在 Codex 上构建的核心：它是一个软件工程团队的助手，而它能做事情的方式，就是写代码。随着我们看到越来越多人用 Codex 做产品相关的任务，我们也更确信，几乎所有强大的智能体最终都会通过编写代码来完成工作。

Alex：这也是智能体真正强大的地方。通过写代码，智能体能够构建可组合、可重复使用的能力。代码可以被导入、被共享，就像团队成员之间共享脚本一样。否则，一个只能通过点击操作界面的智能体，其能力是无法积累、复用或共享的。因此，当我们问“通往胜利的道路是什么”，答案不是模型彼此比速度，而是构建一个能够写代码、能随着团队使用而成长的智能体体系。未来用户加入团队时，可以直接继承智能体此前写过的脚本和能力，就像新人入职时继承团队的内部工具一样。这会形成一个不断累积的系统，而不仅是模型单点的智能。

Lenny：Karpathy 曾说过，现在的智能体大多还很弱，但未来会非常强大。你对此怎么看？

Alex：我认为编码智能体现在已经非常有价值，而代码之外的智能体还在早期阶段。我的个人判断是，当所有智能体都能通过编程以可组合的方式行动时，他们才会真正变得强大。这也是为什么为软件工程师构建产品如此重要。软件工程师本身喜欢构建、喜欢创造，他们会用各种方式推动工具进化，而这些涌现行为非常值得观察。你能从工程师如何使用你的工具里学到巨量东西，也能更清楚应该把什么融入产品。

AI 对软件工程与产品开发的影响

Lenny：关于工程行业，你知道很多人一直在讨论未来是否还需要学习编程，工程师是否会被人工智能取代等问题。但你把人工智能描述成队友，一个与你并肩作战的存在，让你变得更强，而不是替代者。你认为，当人工智能像队友一样与工程师协作，会对整个工程行业产生怎样的影响？

Alex：这是一个非常复杂的问题，但可以从几个方向理解。我们刚才讨论过，每个智能体最终都可能需要通过编码的方式来完成任务，而这其实只是更大理念的一部分。随着代码变得越来越普及，它会被用于更多场景，而不是更少。即便在人工智能出现之前，代码已经无处不在，而人工智能只会让编程变得更加核心和普遍。因此，具备这种能力的人类工程师反而会更加重要，他们能够理解问题、设计系统、与人工智能协作、提出判断，而这些能力会变得越来越有价值。我认为人工智能并不会让工程岗位消失，而是会改变工程师的工作内容。现在我们要思考的是，作为产品团队，我们应该如何构建工具，让人类的成长速度最大化，而不是让他们因为工具太复杂而失去方向。

比如现在与编码智能体合作时，大量代码是由智能体写出的，但我们发现许多工程师真正感到乐趣的部分，是写代码本身，而不是审查他人写的代码。审查代码通常是软件工程中最枯燥也最耗费精神的部分之一。现在人工智能能写出大量代码，意味着工程师需要更多时间去审查，而不是创造。这让工作体验变得更乏味。所以我们开始思考怎样让产品变得更有趣，让用户感到拥有掌控感，而不是觉得自己被迫花时间检查人工智能写的东西。我们加入了代码审查功能，让用户能更快建立对人工智能输出的信心；我们让智能体在执行任务时更努力地验证自己的工作结果，让它先检查，再让用户检查；我们甚至会思考在界面上用户应该先看到什么，例如对于一个界面组件，如果智能体同时生成了代码和图像预览，我们会让用户先看到图像，因为那才是工程师真正关心的最终结果。只有当图像已经展示而且经过智能体审查后，才需要用户查看代码本身。

Lenny：我之前采访过 Cursor 的 CEO Michael，他提到一种趋势叫“规范驱动开发”，也就是你只需要写规范，由人工智能负责写全部代码。他认为未来工程师会在比现在更高的抽象层面上工作，而不再需要真正编写或查看大量代码。你认为工程未来会朝这个方向发展吗？

Alex：我认为抽象的层级一定会继续提升，而且其实已经在提升了。今天许多开发方式本质上就是一种提示驱动的改写，人们已经开始通过更高层的描述来让人工智能完成工作。像规范驱动开发、计划驱动开发等方式已经有人在使用，比如当人们问“如何让 Codex 在某个任务上持续工作更长时间”时，他们通常会先写一个类似 Markdown 的计划文档，确认步骤和目标，再让智能体执行。如果计划本身具有结构性和可验证性，智能体就能执行很久。但规范驱动开发是否适用于所有人，我不是很确定，因为不是每个人都喜欢写规范。确实有一些人天生使用规范来组织思想，但很多团队并不是这样工作。

我有一个更接近现实工作的比喻：许多团队最终完成任务的方式，其实更像“聊天驱动开发”。团队成员在聊天工具里不断讨论、同步、修改、决策，流程在对话中自然推进，任务在沟通中就完成了。并不是每件事都需要正式规范，而是有人提一个想法，有人再补充说明，有人提出下一步行动，然后工程师直接去做。这种方式其实比写规范更普遍，也更贴近日常行为模式。如果人工智能智能体要融入团队，它很可能也会遵循这种方式。对于小问题，人们不想写规范，只想说一句话，比如“这个小 bug 修一下”。对于客户反馈，人们只想把信息丢给它，让它自己去理解并处理。在我设想的未来，人工智能将能够完全融入这种日常沟通流中，以聊天作为主要工作方式，而不是依赖正式文档。

我甚至曾想象过一个极端版本的未来：智能体人像使用手机一样工作，它看到的一切都是竖屏视频流，用户可以像刷短视频那样快速浏览智能体提出的建议。如果不喜欢就左滑，如果觉得不错就右滑，也可以按住录音直接补充指令。这种形式听起来有点荒谬，但它抓住了一个关键点：智能体会持续观察外部信号、用户行为、市场动向和团队状态，并主动提出它认为重要的事项。就像一个特别积极主动的工程队友，会告诉你应该构建什么、应该修复什么，它会自己跟踪情况，随时把重要事推到你的面前。虽然我们没有在做这个“滑动式智能体应用”，但这种思路很好地展示了智能体可能的未来形态。

Alex：在这个未来智能体的设想里，它会持续吸收外部信号，而这点让我觉得特别重要。回顾一些成功的人工智能产品，像我们在 OpenAI 早期用过的 Branded Codebase，它最初就是 GitHub Copilot 背后的模型，后来我们又重新使用了这个品牌，因为它确实非常出色。虽然代码执行很强大，但我其实更喜欢自动补全功能。自动补全可能是迄今为止最成功的人工智能产品之一，它的神奇之处在于，它总是在你需要灵感的时候出现，而且能迅速提供帮助。如果它偶尔犯错，通常也不是太烦人，这种错误的代价很低。它让我意识到自动补全是一种混合主动性的交互方式，它会根据你正在做的事情提供情境化的响应，在你行动的瞬间与之配合。这种特性非常值得我们继续探索。

当我想到浏览器产品，比如我们之前发布的 Atlas，我觉得浏览器可能是人工智能下一步可以深度介入的位置。在浏览器里，人们每天处理的大量信息并不是代码，而是各种网页内容。如果人工智能能在这个空间里主动帮助你，它就能像队友一样处理许多与工作相关的事务。一个真正的队友不会只处理你给到的任务，而是会在你浏览网页、查资料、阅读文档的时候主动理解你在做什么，并快速提供协助。浏览器是一个天然的环境，因为它承载了大量情境信息，也包含多种形式的信号，而这些信号对智能体判断你真正需要什么至关重要。

Lenny：我真的很喜欢你刚才说的那段，因为它信息量非常大，非常丰富。浏览器里的自动补全也是很有意思的概念。想象人工智能可以在网页、草稿、研究资料等一切你正在浏览的内容中主动帮助你，这太迷人了。我之后还想问你更多关于 Atlas 的内容。另外，你刚刚提到代码执行能力也很巧妙，我觉得我现在开始看到整个体系是怎么串联起来的了。

我之前采访过 Block 的 CTO John。他们有一个内部智能体系统叫 Goose。他讲过一个例子，说有个工程师走进办公室，一只“鹅”就像队友一样盯着他，监听他的所有会议内容、关注项目进展，并主动帮他做正确的事情。它会提交 PR、写邮件、草拟 Slack 消息，就像一个主动的工程师队友一样，这和你描述的路线非常接近。

Alex：是的，这很有趣。如果我们问他们在生产力上遇到的瓶颈是什么，我敢猜可能就是那些需要不断查看的事物，而他们构建的 Goose 正是针对这种问题。在 Codex 里我们也看到类似情况，人们非常喜欢用 Codex 集成 Slack，特别是在需要快速处理问题的时候。比如在 Slack 里问它某个 bug 为什么出现，数据科学家会问某个指标为什么变化，它可以直接在 Slack 窗口中给出分析。这种体验非常自然，也很容易被团队接受。但一旦涉及真正写代码，人们还是需要回到代码环境里去看实现。

我认为现在真正的瓶颈已经不在于写代码本身，而在于验证代码是否正确。工程师能愿意写代码，但大型团队投入最多时间的活动往往是代码审查和验证，尤其是最后阶段的质量把控。如果我们想要让智能体真正融入工程团队，就必须让团队能够为智能体配置更多自主性，让智能体在后期流程中承担更多责任，而不是把大量验证任务重新推回给工程师。

写代码是愉快的，但检查别人写的代码往往不是。尤其当你需要负责最终上线质量时，任何微小的错误都可能导致生产环境崩溃，而你必须对这些问题负责。现在人工智能能写大量代码，但团队最终要花更多时间去验证它写的东西，这让工程的后期阶段成为新的瓶颈。这也是我们不断思考的一件事：如果我们希望智能体真正帮助人类，而不是把工程师推出流程之外，我们必须让智能体获得更多在后期阶段的自主性，并且让团队能够配置智能体，使它在验证、检查、审阅方面承担更多实际责任。否则工程师永远会卡在最后的审查阶段，被迫花大量时间做他们并不喜欢的部分，而不是构建与创造。

Lenny：你说的完全符合我从其他公司听到的情况。许多真正处在技术前沿的团队现在遇到最大的瓶颈并不是写代码，而是弄清楚要构建什么，然后在最后阶段花大量时间审查、确认、验证。如果一个项目需要一百个小时，有八十个小时可能都花在审查与验证上，而不是构建本身。你刚才提到的这种方向，确实非常接近许多公司正在思考的未来。

Codex 如何影响产品经理的运作方式

Lenny：Codex 对你作为产品经理的工作方式带来了哪些影响？我们已经知道它明显改变了工程部门，比如代码是 AI 帮写的。那么它对你以及 OpenAI 的项目经理带来了什么实际变化？

Alex：对我来说，我感受到的最大变化是“能力被大幅增强”的感觉。我一直都是偏技术型的产品经理，特别是在为工程师构建产品时，我总觉得必须深入理解产品本身，像吃自己的狗粮一样使用它。但现在的感觉是，你不仅能理解产品，还能做远比以前更多的事情。Scott Belsky 曾谈过“压缩人才阶层”的想法，也许我没有说得很准确，但意思是角色之间的界限变得模糊了，对某些角色的需求比以前少了，因为每个人能做的事情变多了。每当你做一件事，你就突破一次沟通障碍，于是整个团队的效率也被抬高了。

如果你问更具体的产品工作方式，现在我可以直接问 Codex 各种问题，获得意见，也能快速了解新的变化。原型设计也变得更快了。很多人谈到规范文档，不过在我看来，真正让我意外的是，我们原本构建 Codex 的核心目标，是让它编写能够被投入生产的代码。然而我们现在看到的大量实际用例，却是工程师用 Codex 来写“一次性代码”。这种现象让我感觉像是回归了“无处不在的代码”这个古老的想法。

许多人开始用 Codex 做信息分析，他们把一堆数据丢进去，让 Codex 帮他们构建一个交互式的数据查看器。这种事情以前做起来很麻烦，现在却完全值得让智能体去处理。同样的事情也发生在设计团队，如果设计师想制作一个动画，他们过去必须自己写程序，现在他们用 Codex 写了一个临时的动画编辑器，再用那个编辑器制作动画，然后提交到代码库里。我们的设计团队因为 Codex 获得了巨大的加速。他们甚至建立了类似 “Vibe-coded” 的分类体系，把自己的原型直接做成 Codex 使用的版本。

现在团队的讨论方式也发生了变化，因为成千上万的事情同时发生，设计师往往直接在自己的原型里表达想法，而不是在文档里讨论。我们会试用他们的原型，如果大家喜欢，他们就把这个原型实现为产品界面的 Vibe Code，工程师再负责把它转化为正式的 PR。如果代码库是 Rust 或 CLI 这样比较复杂的环境，他们会做到接近目标，然后工程师帮他们完成最后提交。

最近发布的 Sora 安卓应用就是一个最震撼的例子，内部因为使用 Codex 而产生了巨大的速度提升。OpenAI 的技术复杂度非常高，而过去一年我们看到全公司各类角色的使用技巧都大幅提升，而 Codex 的影响也随之增强。Sora 安卓版是一个全新应用，我们从零开发，只用了 18 天就做出员工可试用版本，又过了 10 天发布给公众。换句话说，从开始到正式上线只用了 28 天。而这个过程中，Codex 帮了非常大的忙，有一种“游戏开了简单模式”的感觉。

当你是一家必须在多个平台构建软件的公司时，Codex 会让这些事情变得容易许多。工程师让 Codex 去分析 iOS 应用，然后自动生成迁移到 Android 的工作计划，再根据计划执行。由于我们同时关注 iOS 与 Android，Codex 能提供很多可参考的部分，显著加速了开发。结果就是，团队只用了两周时间就完成上线准备，而整个四周流程包括投产上线。更夸张的是，应用上线后马上登顶应用商店排行榜。

Atlas 浏览器的开发也是类似的故事。Atlas 是一个很有分量的项目，因为构建浏览器本身就是非常困难的事情。我们必须构建许多底层系统，而现在的团队基本都是高级用户级别地使用 Codex。他们告诉我，过去需要 2～3 名工程师花 2～3 周才能完成的功能，现在只需要一个工程师一周时间。这是巨大的加速。目前团队正在全力构建 Windows 版本，同时改进 Windows 上的 Codex 支持。最近我们发布的模型已经开始原生支持 PowerShell，这是一种非常重要的 Windows 系统语言，这也让 Codex 在 Windows 平台上的表现提升许多。

整个公司因为 Codex 而加速，从研究到模型训练速度，再到设计与营销，我们经常看到产品营销人员直接在 Slack 里更新字符串或文案，这些都是变化的一部分。公司内部对 AI 的使用已经渗透到每个角色，速度之快让人惊叹。Sora 应用的成功也证明了这种变化的力量，你能想象只有两三个工程师，却发布了一款登顶全球应用商店的产品，这在以前几乎不可想象。

Atlas 的开发同样令人震撼。工程师们告诉我，他们几乎用 Codex 处理所有事情。当我问他们“你们怎么衡量加速”，他们说，过去需要两三周和两三名工程师的工作，现在一个人一周搞定。你问未来是否可能让非工程师完成这些工作？我认为这是可能的。角色边界正在模糊化。你仍然需要对自己构建的东西的本质有理解，但具体细节将越来越抽象，就像你不用懂汇编语言也能写 Swift，一样的道理。

随着时间推移，我们会看到越来越高的抽象层，接近自然语言本身的抽象。自然语言极其灵活，工程师可以用它讨论计划、规格、产品与想法，而智能体可以将这些自然语言直接转为可执行代码。未来不会突然变成没人再写代码，所有事情都用规范文档描述，而会是循序渐进的过渡。我们先为编码智能体设置完善的预览系统与测试系统，让它能看到自己修改后的结果。下一步可能让智能体加载示例页面、自动检查视觉效果。再进一步，人类负责筛选，智能体负责构建。未来 Codex 甚至能自动告诉你如何设置环境，甚至在代码库里自动设置。

Codex 对生产力的影响、创意与执行力的价值、垂直领域 AI 的未来

Lenny：生活在这样一个剧烈变化的时代真是令人惊叹。我很好奇这些变化会产生哪些次生影响，尤其是当构建速度变得如此之快时，会带来什么后果？这是否意味着分发会变得更重要？创意会变得更有价值？当变化如此迅速时，你觉得我们会走向什么方向？

Alex：我仍然认为，想法本身的价值没有很多人想象的那么高。真正困难的永远是执行，你可以在短时间内搭建一个东西，但要让它真正有意义、连贯、有生命力，需要极高的执行力。产品的分发依然极其重要，一切所有的前后环节都显得更关键了。除了构思、上市和盈利这些核心环节以外的许多部分，都因为开发变容易而变得不再那么稀缺。

过去我们处在一个奇怪的临时状态，构建产品太难，因此只有极擅长产品开发的人能够突破重围，你甚至不需要对某个客户群体有深度理解，也可能做出成功产品。而现在情况完全不同了，我认为如果只能选择一件必须掌握的能力，那就是对某个具体客户的问题拥有极其深入的理解。如果你创办一家初创公司，并且对行业有深度洞察，同时在领域里有人脉，尤其是面对被现有 AI 工具严重服务不足的客户，那么你已经掌握了成功的核心。如果你的能力很强，但没有明确的客户对象，情况反而会更困难。现在的时代对“深刻理解问题的人”更友好，对“只擅长构建东西的人”更不友好。

这也是为什么许多人看好垂直领域的 AI 初创公司。你可以用通用模型解决许多泛化问题，但如果你致力于把演示文稿制作做到极致，你会比任何人都更了解那类用户的问题。你会深刻融入他们的日常工作流，你会知道哪些细节真正重要。这些东西才是最终决定性的。

衡量 Codex 的进步：用户留存、真实反馈与社区信号

Lenny：当你们评估 Codex 的发展时，会关注什么指标？你们有很多基准测试，也做了许多内部评估，那么真正让你们判断“我们做得很好”的指标是什么？

Alex：一个我不断提醒自己的事情是，像 Codex 这样的产品，本质上是一种你必须真正使用的工具。这意味着我们作为团队，很容易变成“高级用户”，并在无意间过度关注一些对普通用户来说并不关键的功能。为了避免这种偏差，我们必须非常认真地看待用户留存数据，尤其是 D7，也就是用户使用后的第七天是否还会回来。

我甚至会注册许多新账号，只为了更真实地体验首次使用流程。我愿意花钱去购买其他产品，只为确保我们对比的是实情。因为这个领域仍处于早期，人们对这些工具的使用习惯还没有完全形成。

另一个特别重要的角度是社区反馈。我们有一个内部的反馈与社交媒体团队，他们非常深入地泡在 Reddit、Twitter 等社区里。Reddit 的内容更真实，Twitter 上的讨论往往更即时也更尖锐。我们非常关注这些渠道的氛围，因为一个编码智能体可以做很多事情，但往往会在某些细节上失败，而这些失败只有真实用户才会指出。Reddit 是我越来越关注的地方，因为那里的高赞评论通常反映真实用户的痛点与需求。

如果你问我常看哪些子版块，我不会特别说一个名字，因为 Reddit 的推荐机制已经能把最重要的内容推给我。我只需要观察人们真实表达的情绪，那比任何内部指标都更有价值。

为什么要做浏览器、Atlas 的由来、情境化助手的愿景

Lenny：你们发布了 Atlas。我在推特上说我试用了 Atlas，但我并不是很喜欢“纯 AI 搜索”的体验，有时候我就是想用 Google，不想等 AI 给我一个完整的回答，而且当时我感觉没有办法切换，所以我发推说我要切回去。我并不是觉得这有什么问题，但我看到好像有人因此有点受伤。我猜这其实是典型的“先发布产品、观察用户行为、再迭代”的例子吧。我想问的问题是：你们为什么要做一个网页浏览器？

Alex：我之前在 Atlas 上工作过一段时间，说一下我自己的故事。我在加入 OpenAI 之前做过一个关于屏幕共享与结对编程方向的创业项目，而我们当时的核心理念就是构建一个具备上下文理解能力的桌面助手，因为我觉得把所有背景告诉助手实在太麻烦了，你得花很多精力解释你在做什么，而如果助手能自己理解你的工作情境，它就能让你的操作速度快很多。所以从某种意义上说，Codex 就像一个从编码任务出发的“情境助手”。

对我个人来说，很多工作都发生在浏览器里，所以如果我们能自己做一个浏览器，让智能体在更完整的上下文中帮助你，而不是像传统桌面软件那样通过一种“黑客式”的方式抓取信息，那会极大改善助手的体验。浏览器能够直接访问渲染引擎，而不是依靠截图，也不需要依赖那些缓慢且不稳定的接口。它可以直接读取 DOM、辅助功能树等所有结构化信息，以更可靠的方式提供帮助。

我喜欢用电子游戏来类比，比如你走到某个对象旁边，按下 X 键，游戏就会自动执行正确的互动。在软件世界里，要做到这一点，系统必须知道你当前在做什么，需要什么帮助，并且必须有恰当的情境线索。想象我们要覆盖的所有世界范围的任务，智能体每天有可能帮助你成千上万次。如果它只能通过推送通知来告诉你“我帮你做了这个”，那么你每天会收到成千上万条 AI 通知，那一定令人崩溃。真正理想的方式是，当你专注于某个工作，比如查看仪表盘时指标突然下降，智能体可以在右侧出现，为你解释原因，并告诉你可能的解决方案，而且它只在你关心的那一刻出现。

浏览器让我们能够做到两件最重要的事情：第一，为智能体提供完整的情境，让它知道什么时候该帮忙；第二，让用户完全掌控哪些内容能被智能体看到。如果你愿意，你可以在 AI 浏览器中打开页面，让它对页面采取行动；如果不愿意，你可以在其他浏览器中打开，这种清晰的边界既保证安全又让体验顺畅。我们希望实现一种“混合主动性”，在你最需要的恰当时刻表现出智能，而不是以通知轰炸你。

Codex 适用哪些代码库、如何最好使用它、入门策略

Lenny：说到 Codex 作为超级助手，你提到它不仅能写代码，还能像队友一样帮助你工作。那么有没有哪些非工程师对 Codex 的使用方式让你觉得有趣或意想不到？

Alex：确实有很多意想不到的用法，但目前为止，最明显的仍然是那些偏向技术或与编程相关的领域，比如数据团队或做分析的人。然而我相信随着时间推移，非工程角色会出现更多创造性的用法。现在团队主要专注于让 Codex 在编码上做到极致，因为这里还有大量基础工作要完善。

Lenny：对于想使用 Codex 的人来说，Codex 是否能适用于所有类型的代码？它能支持哪些语言？比如有人说“我不懂 SAP，你能用 Codex 直接帮我写吗”？最佳实践是什么？

Alex：实际上，使用 Codex 的最佳方式不是给它简单任务，而是给它最困难、最真实的问题。有些工具适合从简单任务试用，而 Codex 的定位更像是一款专业工具，如果你想评估它的真实能力，应该让它处理大型代码库里的复杂任务，例如调试一个你自己也不确定原因的 bug，让它为你查找问题根源，再实现修复方案。

关于语言支持，我们的训练覆盖范围跟真实世界的使用分布接近，只要不是特别冷门或完全私有的小众语言，Codex 基本都能处理。对刚开始使用 Codex 的人来说，我会建议把它当成新队友一样，先让它理解代码库，再一起制定计划，然后让它逐步执行任务。以这种方式，你能更快建立信任，也更容易掌握如何与 Codex 有效协作。

AI 时代的技能、职业影响

Lenny：当 AI 逐渐能写代码后，很多人开始问：我还应该学习编程吗？如果我是学生，我应该学习什么？哪些计算机科学知识在未来更重要？

Alex：我认为学习编程依然非常重要，但理由正在发生变化。首先，随着编码智能体不断变强，学生和职涯早期的人反而能更快做出完整作品，这意味着他们与资深工程师之间的差距缩小了。使用最新工具的熟练度将成为重要优势。

另一面是，真正关键的不是“打字写程序”，而是理解软件系统结构、理解什么使系统高效、能够推理复杂架构，并具备团队沟通协作能力。AI 不会突然让所有人不用写代码，而是会逐步扩展抽象层，但系统设计与判断力仍然属于人类。工程师仍需能配置智能体，使其验证自己的工作。比如我们在 Atlas 工程中，有工程师专门要求 Codex 解释自己无法自我验证的原因，然后让 Codex 反复循环改进。

此外，如果一个人对某个领域拥有深厚知识，例如模型训练基础设施、数据系统或其他复杂领域，他们依然会极具价值，因为 AI 反而会迫使这些专家使用智能体来加速自己的工作。

Codex 自我训练、自动监控系统、未来智能体的形态

Alex：当你处于某个技术前沿领域时，会出现一种非常有趣的现象：你不仅需要深刻理解那个领域本身，还必须充分利用编码智能体，而智能体的存在反过来又加速你推进前沿本身的能力。Codex 在 OpenAI 内部已经编写了大量用于管理训练运行和关键基础设施的代码，我们的研究迭代速度极快，而 Codex 在审查过程中发现了许多真正有意义的错误，包括一些非常隐蔽的配置问题。这让我们看到了一种未来趋势的影子：我们甚至开始出现类似“Codex 委员会”这样的结构，使 Codex 帮助 Codex 自身服务训练系统。

Lenny ：Codex 的自我训练到底意味着什么

Alex：在训练过程中有大量图表，人们必须随时查看它们，因为训练成本极高且变化迅速。训练运行背后存在许多系统，其中一个系统出错就可能导致整个训练失效，所以 Codex 会在循环中持续检查这些图表的表现，并且逐渐学习如何从中推断问题。当某个系统需要修复或暂停时，Codex 会识别出异常，提出需要采取行动的建议，甚至可能有权直接修复并重启流程。我们仍在探索最有效的方式，但核心思路是让智能体持续监控和优化训练，使研究团队能以更高效的方式推进工作。

这种能力让我觉得未来的智能体绝不会只是一个“写代码工具”，它将成为一种具备持续监督能力、判断能力和行动能力的系统成员。它理解代码库，却不仅仅服务于代码本身，而是可以在整个复杂系统运行过程中发挥“智能监护人”的作用。

关于 AGI 的时间表：我们距离人类级智能有多近？

Lenny：AGI 的时间表众说纷纭，很难确定真正的进展。你怎么看？我们是否正在向更像人类的人工智能逐步进化？

Alex：对我来说，这个问题更像是在思考我们什么时候能看到真正意义上的加速曲线，也就是那种典型的曲棍球棒式增长。

现在有许多限制因素，但我认为最被低估的限制因素之一其实是人类本身，比如人的打字速度、提示写作速度、人类的多任务能力。就像你刚才提到的，你可以让智能体监督你做的所有工作，但如果你没有为智能体构建良好的自主机制，你仍然得不断验证它的工作是否正确。于是我们就遇到了新的瓶颈：你能不能审查它写出的所有代码？能不能验证所有它提出的修改？如果人类在这个环节仍然处于瓶颈位置，那么整个系统就无法真正加速。

所以我们需要把这些生产力循环中的人为阻塞解除掉，把那些不断提示与不断验证的步骤转移出去。如果我们能重建系统，让智能体能够默认发挥作用，而不是由人不断唤醒，那么我们就能真正解锁那条曲棍球棒曲线。

这并不是一个非此即彼的过程，很大程度取决于你在构建什么。如果你明年是一家创业公司，正在构建一个新应用，那么你完全可能把它搭建在一个比以往更自主的智能体堆栈上。相反，如果你在 SAP 这样的公司工作，它们有大量的旧系统，不可能一夜之间让智能体完全接管端到端流程，它们必须逐步替换、逐步更新，让智能体能处理越来越多的部分。

所以我对这个问题的回答可能有点无聊，但我确实认为，从明年开始我们会看到第一批早期 adopters 的生产力出现曲棍球式的跃升，而在接下来的几年里，这种加速会不断扩散。当曲线进一步变陡，真正进入模糊但高速的阶段，我们可能就已经靠近 AGI 了。

Lenny：我喜欢这个答案，它很现实，也很符合我们常谈的那一点：审查人工智能的输出真的很烦人，也是巨大的瓶颈。提升编码效率是一回事，但解决后期的验证问题是另外一件更关键的事情。你提出“人类打字速度是瓶颈”这个观点非常独特，我从未听过，但它非常有启发性。

参考链接：

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