Codex革命：OpenAI如何以智能体重塑软件开发格局

自GPT-5于八月推出以来，Codex展现出爆炸性增长，用户规模飙升20倍，每周处理数万亿令牌，一跃成为OpenAI最受欢迎的编程智能体。

“Codex实现20倍增长，不仅源于模型强化，更因我们领悟到智能体是模型、API与框架协同的产物。” 在最新播客中，OpenAI Codex产品负责人Alexander Embiricos揭秘其成功之道。

例如，Codex在长时任务上的突破。为支持连续工作数十小时，团队设计“压缩”机制——模型提炼关键信息，API衔接任务链，框架保障运行稳定。三者咬合，使Codex能处理传统大模型难以胜任的持久编程任务。

此底层逻辑让Codex在实战中表现惊人。Andrej Karpathy曾分享，他被一个bug困扰数小时，Codex却在一小时内修复。Sora团队依赖Codex，仅用28天从零开发Android应用，并登顶App Store。

回顾历程，Alexander Embiricos坦言Codex路径并非最初就清晰。早期版本“过于未来”，采用远程异步交互，虽契合资深工程师却对大众不友好。转折点在于将Codex迁回本地IDE，让它直接在工程师环境中工作，这才更接地气。

当前Codex，在Alexander眼中，像“聪明但被动的实习生，编码迅捷”。它持续自我监督与训练，不断进化。Alexander期待Codex未来参与软件开发全流程，成为工程师的真正队友。

Alexander还谈及OpenAI文化，惊叹其速度与野心，迭代之快前所未闻。相比其他组织“先瞄准再射击”，OpenAI独特之处在于“先射击再瞄准”，即先发布，再依真实反馈优化。汇聚顶尖人才与自下而上文化，让高速迭代成为日常。

对于AGI何时到来，Alexander给出有趣视角：当前限制AGI的因素非模型能力，而是人类——我们输入与审查速度有限，正拖累其发展。他预测首批生产力陡增用户明年出现，随后变化加速扩散。“当增长曲线异常陡峭时，”他说，“我们或已站在AGI门口。”

播客还分享更多Codex细节与Alex观点，我们翻译并整理内容，以飨读者。

播客精彩观点汇集：

1. Codex助OpenAI以两三位工程师数周协作，打造Sora安卓应用并登顶App Store。应用从零到员工测试仅18天，10天后发布。Codex通过分析iOS应用、制定计划及跨平台比对，提供巨大助力。
2. 即便AI模型明日停止改进，我们仍需数年产品开发以充分发挥潜力。技术发展速度超出现有利用能力。
3. 充分利用Codex的关键是选择最棘手问题，而非最简单任务。工具旨在解决复杂bug与任务，从耗时数小时的问题入手。
4. OpenAI早期Codex产品“过于超前”。它以云端异步运行，对高级用户佳但对新手难。当迁回工程师本地代码编辑器，增长爆发式提升。过去6个月使用量增长20倍。
5. 编写代码或成AI完成任务的通用方式。AI即时编写小型程序，而非点击界面或单独集成，才能发挥最佳性能。这意味着每AI助手都应内置编码能力。
6. OpenAI设计师现在编写并发布自有代码。设计团队维护由AI辅助构建的功能原型，直接编码、测试并常自行提交生产环境，仅复杂代码库需工程师介入。
7. AI生产力最大瓶颈非AI自身，而是人类打字速度。限制在于输入提示与审查AI输出的速度。在AI能更可靠验证自身输出并主动帮助前，无法见全生产力提升。
8. 编写代码的乐趣正逐渐被审查AI生成代码取代。工程师曾热爱构建代码的创造性过程，现花更多时间阅读AI生成代码。下一挑战是让代码审查更快、更令人满意。
9. 新型AI模型可连续工作24至60多小时完成单任务。“压缩”技术让AI在内存耗尽前总结所学，于新会话中继续工作，实现通宵或多天自主工作。
10. 若现在创办公司，深入了解特定客户比擅长产品开发更重要。产品开发变易，真正优势在于知悉开发何产品及为谁开发。

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

Lenny：先从你在OpenAI经历谈起。你约一年前加入，此前创业五年，再之前在Dropbox任产品经理。OpenAI与你过往公司截然不同。最特别运作方式是什么？你学到什么会未来带走？

Alex：OpenAI工作节奏与雄心超乎想象。以前创业圈都自认速度快、目标宏，但这里重新定义“速度”与“雄心”。AI公司发展快，例模型爆炸式增长，Codex十倍级增长仅数月完成并加速。这让我在打造科技产品时，自然设定达此速度规模的目标。创业公司节奏相形慢。

创业常权衡投入与失败可能：先尝试、再转型。但在OpenAI，我意识到影响力巨大，需极高精力投入做好工作，迫使我更果断安排时间。

Lenny：追问：像Codex快速推进的团队，是否有特别组织架构或结构性原因？

Alex：一方面，所用技术彻底改变产品构建与用户功能实现。即便停止模型进展，产品开发仍落后大量。但意外处多，如OpenAI组织设计为高度自下而上，每人都渴望快速推进。许多公司声称自下而上，但OpenAI真正如此。这让我学习到，未来或难回非AI公司工作。

Lenny：听起来更像“预备、射击、瞄准”，而非“预备、瞄准、射击”。AI公司思路似因不知用户如何用产品，故尽快发布、观察使用、快速迭代。

Alex：比喻有道理，但目标成分模糊。我们预测未来可能发生什么，但大量不确定性。研究主管常言，在OpenAI可展开一年后高质量对话，但越近时间点越难理性规划。构想远期未来，尤其AI对齐议题，但产品阶段更依赖实证研究验证。

Lenny：人们听此做法，觉得像你公司可大胆尝试，未来几月无严格计划。但关键是聘用世界最优秀人才，此似让此公司成功关键。

Alex：此点让我共鸣。初加入时，对每人展现个人动力与自主性震惊。OpenAI运作方式难靠文章或播客复制到他公司。少公司拥能以此方式运作的人才，若要别处出现，大概率需多调整。

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

Lenny：聊聊Codex。你是Codex负责人。Codex现进展如何？能分享数据吗？解释Codex是什么？

Alex：Codex是开源编码智能体，具体是VS Code IDE扩展，可安装扩展或终端工具。安装后，可与Codex互动，回答代码问题、编写代码、运行测试、执行代码等，处理软件开发生命周期最繁重部分——实际编写将部署到生产环境的代码。

更广而言，我们认为Codex是软件工程团队成员的起点。谈到“队友”时，我们设想它不止编写代码，而是参与软件编写全流程，从构思、规划到下游验证、部署与维护。

我喜欢把今天Codex想象成：非常聪明实习生，但不会查看Slack或主动检查监控系统，除非你要求。因此，即使它聪明，你不会完全放手让它无人监督编写代码。现大多数人使用方式仍是与它结对编程。

但我们希望未来达到：像雇佣新实习生，不止写代码，还参与全流程。即使首次尝试不完全正确，他们会持续参与并通过迭代最终实现目标。

Lenny：你提到“不会看Slack”意思是不分心，全神贯注工作。但你的意思是它无法掌握完整背景，对吧？对团队最优成员，你不会告诉每一步，只最初几次会议让他们了解沟通方式，然后他们就能独立工作，甚至主动协作。

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

当下AI产品实际难使用，因用户必须明确思考何时向模型求助。如果你不主动发出请求，模型就无法帮助。如今，普通用户或每天只向AI发出几十次指令。但如果系统真正智能，人类每天能从它获数千次帮助。

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

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

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

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

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

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

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

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

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

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

当我们推出第一版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的内容。另外，你刚刚提到代码执行能力也很巧妙，我觉得我现在开始看到整个体系是怎么串联起来的了。

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

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

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

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

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在编码上做到极致，因为这里还有大量基础工作要完善。

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

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

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

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

AI时代的技能、职业影响、 未来AGI时间表与团队扩张

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