近日，OpenAI Codex 的负责人 Alexander Embiricos 接受了 20VC 的深度访谈。对话覆盖了 AI 编程的范式转移、软件工程师与产品经理的未来角色、通往 AGI 的真实瓶颈、OpenAI 研发 Atlas 浏览器的底层逻辑、AI Agent 的进化阶段，以及 OpenAI 独特的竞争与开源策略。
Alexander Embiricos 指出，尽管自动化程度不断提升，但五年后软件工程师的数量将不降反增。同时，他认为在高效的 AI 驱动团队中，传统意义上“补位型”的产品经理角色将逐渐被具备产品思维的工程负责人或设计师吸收。关于 AGI，他认为关键瓶颈并非模型或算力，而是“人类输入与验证的效率”。
01 真正激励创造者的是为人们构建有用工具的热爱
在职业生涯和初创公司经营中，你更多是被害怕失败的恐惧所驱动，还是被渴望获胜的刺激感所激励？这种驱动力如何影响你的决策？
Alexander Embiricos: 我是一个极大主义者。相比于对失败的恐惧，我显然更容易被获胜的愿景所驱动。但我得承认，在加入 OpenAI 之前，当我经营自己的初创公司时，我曾经历过很多至暗时刻。其中最让我清醒的一点是，我意识到自己在过去几个月里竟然一直在试图避免失败。那一刻我突然明白，这就是我不快乐的根源，也可能是公司进展不顺的原因。所以，我必须不时地自我检视，让自己重新回到追求获胜的状态。
但说到底，真正激励我的是对创造的热爱，为人们构建有用的东西。我对今年感到无比兴奋，因为许多尚未面世的奇妙事物将被创造出来，并送到千家万户。
02 为什么自动化反而会让工程师需求激增？
Elon Musk 曾表示编程是首批会被大规模自动化的职业之一。结合你在 OpenAI 的日常观察，你是否认同这一观点？这是否意味着五年后工程师的数量会大幅减少？
Alexander Embiricos: 我完全同意编程是大语言模型展现出极强能力的先锋领域。但关于编程被自动化的定义，其实是一个很深刻的话题。例如，当我们不再编写汇编语言，转而使用高级语言时，我们当时会说编程被自动化了吗？其实没有。我们只是变得能写更多代码了，结果反而导致了代码需求的激增，进而需要更多的软件工程师。
诚然，他们过去的一部分工作确实被自动化了。就像“计算机”这个词的起源，在布莱切利园时期，人类的工作是把穿孔卡片塞进机器进行计算，那时候工作是极度依赖人力的。甚至最早的电子表格软件也是基于这种模式，一间办公室里摆满了桌子，人们做完计算传给下一个人。
所以，每当这些特定的任务被自动化，产出的需求反而会迎来爆炸式增长。因此，即使具体的工作任务发生了变化，你实际上需要更多的人来从事相关工作。是的，我认为五年后工程师数量会增加。有些术语的含义会演变，计算机现在指代的是机器，而我们有了软件工程师这个新称谓。我坚信未来会有更多的创造者。
03 AI 时代还需要产品经理吗？
你提到了“人才栈压缩”的概念，并开玩笑说未来不再需要产品经理了，这背后的逻辑是什么？
Alexander Embiricos: 这只是我开的一个有趣的玩笑。首先，产品经理的定义本身就很模糊，我倾向于认为这个角色本就是未定义的，其核心目标是补位，根据团队或业务的需求灵活调整。
通常情况下，如果有一群人正在像我们这样全速推进研发，产品经理能做的就是退后一步，通过全局视角来预判风险，与市场推广部门协作，或者充当团队的啦啦队长和质量把控者。但我刚才描述的这些工作，也就是我目前的角色，其实完全可以由一个具备产品思维的工程负责人或设计师来承担。因此，虽然产品经理有其价值，但在团队规模真正变大之前，你可能并不需要太多产品经理。
观察到一个有趣的现象是，虽然现在仍需要软件工程师和设计师，但当你现在提到工程师时，你可能指的是比以前更加全栈的人才。几年前，后端工程师和前端工程师的界限非常分明，但现在，至少在我们的 Codex 团队中，这种分界已经模糊了，大家的工作都变得非常全栈化。所以，我认为人才栈会压缩，但创造者依然存在。
04 通往 AGI 的真正的瓶颈
你曾提到人类的打字速度和验证工作是通向 AGI 的关键瓶颈，而非模型、算力或架构。请解释这背后的逻辑。同时，你认为 AI 每天能在多少个环节帮助到人类？如果你的工作是将提示词和人类行为产品化，我们该如何消除这种瓶颈？
Alexander Embiricos: 瓶颈当然不止一个，但这个说法可能最具话题性。我们可以尝试用苏格拉底式的方式来探讨，你现在每天使用多少次 AI？如果假设你完全不需要消耗能量和体力，你认为 AI 每天能在多少个环节帮助到你？我认为未来推理任务将 24 小时运行在每一件事情上，这正是如此。我现在常听到 OpenAI 内部或外部的工程师说，我一直开着 Codex，从不合上电脑，如果开会时它没在后台跑任务，我就觉得自己虚度了时间。这很酷，但同时也意味着巨大的管理工作量，你要时刻确保这些 AI Agent 都在高效运转。
回到那个每天 30 次的话题。根据我们的数据，Codex 用户的使用频率通常在几十次这个量级。但我认为，在算力允许的情况下，AI 每天应该帮助我们数万次。问题在于，即使是我这种业内人士，虽然深知应该在所有事情上使用 AI，但我也会因为太懒而不想输入那么多提示词，或者因为缺乏创意而想不出更多的应用场景。所以我现在的频率其实和你差不多。当我偶尔用 AI 完成了一些酷炫的操作，比如为今天的对话做准备，我还会沾沾自喜，觉得自己挖掘了 AI 的新用法。对于像你我这样对这个领域充满热忱的人来说，这没什么，但对于普通大众，我们不能指望他们投入巨大的精力去钻研工具。AI 应该变得毫不费力。所以，我们理想中的未来是，你不再需要学习如何写提示词，AI 对你来说就是信手拈来。你甚至不需要意识到 AI 的存在，它天然就了解你，感知你的上下文，并适时提供帮助。
关于消除瓶颈，我们的职责是确保模型具备强大的能力，并最终将其高度产品化。未来的形式可能是一个神奇的文本框、语音输入，或者是直接把 AI 拉进群聊，它就能自动开始帮忙。但在那之前，有一个非常有意义的中间阶段，也是我认为目前价值最高的地方。与其针对特定市场把 AI 功能做死，不如先观察。我记得你之前的播客嘉宾提到过，企业如果没有全职员工就无法落地 AI，但我其实完全不同意那个观点。我认为我们应该为个人构建工具。正如 Fitzpatrick 所说，你可以利用全职员工来自动化工作流，但那样你会被自上而下的视角所局限，受限于你人力所能覆盖的范围。但对我来说，AI 最激动人心的未来是让每个人都成为超人。为此，我们需要打造面向个人用户的工具，让每个人都能运用自如。
05 AI Agent 的三个进阶阶段
将 AI 推广到编程以外的领域时，最重要的核心是什么？如果不预设任务，用户可能根本不知道该让 AI 做什么，这是否又把负担甩给了用户？
Alexander Embiricos: 这就是为什么我认为它是瓶颈。在我看来，进化分为三个阶段：第一阶段，让 AI Agent 在编程领域做到极致，因为大语言模型天然擅长于此。第二阶段，意识到 AI Agent 的通用价值在于操作计算机，而所有的 AI Agent 最终都会归结为编程 Agent，因为编程是 AI Agent 驱动计算机最高效的方式。我们要把这种灵活的工具交给那些爱钻研的人。我们已经在 Codex App 上看到了这种趋势，原本为开发者设计的工具正被用于各种非编程任务。第三阶段，在看清哪些模式行之有效后，再进行你所说的产品化，打造开箱即用的特定功能。我认为在接下来的几个月里，我们将以倍速完成这三个阶段。
（关于用户负担）目前最有趣的阶段是为那些愿意折腾、探索 AI 的人构建工具。这就是 Claude Code 最初发布时的天才之处，它极其易用，就在终端里，随取随用。于是人们开始疯狂实验它的应用边界。所以，在将 AI 推广到编程以外的领域时，最重要的不是急于把它做成财务专用或某个特定工作流专用，而是构建一个足够开放的工具，让人们能够发挥创意去解决任何任务。
06 OpenAI 为什么要跨界做 Atlas浏览器？
企业落地的挑战在于数据安全和权限控制，且大企业员工往往缺乏尝试新工具的自信，是否仍需要全职员工进行定制化适配？OpenAI 推出浏览器 Atlas 的核心战略动机是什么？
Alexander Embiricos: 如果你想构建一套宏大的自动化系统，你确实是对的。你必须处理那些实打实的安全和合规障碍，打通所有数据系统。这确实需要全职员工的介入。但我发现，这种自上而下的方式往往会限制 AI 释放潜能。如果你能并行推进，把 AI 直接交到一线员工手里，让他们建立起对 AI 的直觉，并主动将其拉入工作流，效果会好得多。
打个比方。如果你是一名客服人员，公司自上而下引入 AI 自动化了你的工作，但你从未用过 ChatGPT，你对这个东西会完全没有概念，甚至感到被威胁。但如果你平时就在工作中使用 ChatGPT，同时看着部分工作被模型自动化，你就会对它的原理有直觉。你会感到自己不仅没被淘汰，反而被加速了，因为你拥有控制权，可以引导自动化往哪个方向发展，而不是眼睁睁看着一个完全脱离掌控的东西夺走你的工作。所以，回到数据控制的问题。虽然问题真实存在，但归根结底，每个工具都是由人通过浏览器或文件系统来操作的。
这也是为什么 OpenAI 要做浏览器，也就是 Atlas。你可能会奇怪我们为什么要跨界，原因很多，但核心的一点是，通过构建浏览器，我们可以实现全链路的掌控。我们可以为企业提供安全的、具备 AI Agent 能力的浏览体验。这是一种无需等待全职员工开发，就能让 AI 智能访问各种企业系统的新路径。
07 OpenAI 正在多手段消除推理延迟
速度对开发者究竟有多重要？OpenAI 与 Cerebras 的合作是否会形成某种推理垄断？如何看待“推理就是新的销售与市场（PLG 的进化）”这一观点？
Alexander Embiricos: 简单来说，速度至关重要。这仅代表我个人观点，我不认为我们最终会进入某种垄断局面。目前的竞争压力巨大，这个问题会有多种解法。但我可以透露，我们很快就会发布关于这项合作的新动态，我非常期待这些成果能真正落地，那绝对会很酷。即便如此，GPT-5.2 Codex 模型本身的效率已经比前代高出许多。根据我们收到的反馈，用户现在确实能感觉到这是一款极具速度竞争力的模型。因此，仅在模型层面就有很大的优化空间。此外，改进推理执行方式也大有可为。比如我们最近推出了一项更新，API 侧的模型响应速度提升了 40%，而在 Codex 应用内部也提升了约 25%。所以速度非常关键，我们正在从硬件、推理优化以及模型架构全方位地解决这个问题。
（关于推理成本驱动增长）我不确定，我对此持保留意见。从根本上说，在这个人人都能构建产品，且构建门槛日益降低的新世界里，真正的难点在哪里？我认为，与客户建立良好的关系、洞察他们的需求，依然和过去一样困难，甚至由于市场上可选的产品激增，这件事变得更难了。其他的难点还包括如何构建正确的产品，以及保持极高的品质。回到销售和营销的话题，我不认为这些职能会消失，因为正如我所说，随着任何特定市场中软件数量的增加，竞争会更加激烈，营销工作只会变得更具挑战性。
08 内部范式转变：OpenAI 已经不再需要编辑器了？
据了解某些公司内部 AI 生成代码比例接近 100%，OpenAI 内部对 Codex 的真实使用率是多少？在 24 个月后，传统的 IDE（集成开发环境）是否还会是技术栈的一部分？
Alexander Embiricos: 我先代表我自己，再代表团队回答。我认识的大多数人基本上已经不再打开编辑器了。这是一种阶跃式的飞跃。虽然它是渐进发生的，但我想外部市场的转折点是 GPT-5.2 Codex 的发布。突然之间，模型在长时运行、端到端任务处理、上下文管理以及指令遵循方面表现得极其出色。这也是我们开发 Codex 独立应用的部分原因。在 GPT-5.2 Codex 之前，AI 编程功能更多是自动补全，或者是某种程度上的结对编程。在我的认知里，那时你还得坐在电脑前，手一直放在键盘附近，你必须全程主导，AI 只是在帮你处理琐事。
但在 12 月发布 GPT-5.2 Codex 之后，我们转向了一种新模式，即完全委派任务。我会和它一起制定计划，确认好执行规范，然后就放手让它自行处理。这是一种完全不同的工作范式，而且变革正发生在此时此刻。我们上周发布 Codex 应用，部分原因就是想打造一种交互形式或用户体验，让你觉得委派任务而不是与 AI Agent 结对是一件非常自然顺手的事情，甚至可以同时向多个 AI Agent 委派任务。即使在 OpenAI 内部，这种变化也是翻天覆地的。我没有精确的百分比，但我可以说绝大多数代码都是由 AI 编写的，而且现在大多数人甚至都不打开 IDE 了。即便打开 IDE，可能也是为了定义模块间的接口，然后由 AI 填充内容，或者是协作制定方案，再由 AI 执行编码。代码本身已经不再由人类亲手编写了。
（关于 IDE 的未来）这取决于你对集成开发环境的正式定义。这个词现在非常模糊，几乎任何工具都能自称 IDE，所以这种讨论意义不大。如果按宽泛定义，你甚至可以说 Codex 应用就是一个 IDE，但我并不这么认为。对我来说，IDE 本质上是一个功能强大的编辑器。我们明确没有在 Codex 应用里加入编辑功能，就是为了让用户明确它的定位。它提供了大量用于管理多个 AI Agent、任务委派和变更审查的功能。它还有非常显著的技能系统，这是一种开放标准，对于执行非编程任务，比如任务分拣、监控部署等非常有用，但它确实不具备文本编辑功能。
09 当 AI 编写一切，谁来负责监督？
如果大部分代码都是由 Codex 生成的，你们如何进行代码审查？AI 是否已经开始负责内部的代码审查？
Alexander Embiricos: 这里有几个核心点。首先，任务规范或计划变得比以往任何时候都重要。你需要从结构和架构的高度去思考，这段代码应该如何运行。所以我们最近推出了一个核心的计划模式，它的机制很独特，AI Agent 会先提议一套详尽的方案，然后询问你是否认可，或者是否有改进意见。这非常像是一个刚接触代码库的新员工，在动手写代码前，需要向团队提交一份征求意见稿。虽然这在形式上不完全等同于代码审查，但我认为计划审查正变得越来越重要，因为我们已经进入了与 AI Agent 协作的委派阶段。这一点常被外界低估。
（关于自动审查）当然，实际的代码审查也必不可少。我常听人提到一个问题，特别是在开源社区，就是充斥着大量的 AI 垃圾。很多人会直接向开源仓库提交低质量的 PR，甚至自己都没测试过，或者完全没审过代码，这确实是个大麻烦。在 Codex 的实践中，常见的做法是让 Codex 审查它自己生成的变更。Codex 在这方面表现惊人。我们专门针对代码审查训练了模型，确保它能提供高信号反馈，极少出现误报，这意味着一旦它给出建议，通常是非常值得信赖的。所以我们不仅鼓励团队使用 Codex 审查，还可以设置自动审查。目前在 OpenAI，只要你推送代码到仓库，几乎所有代码都会触发 Codex 的自动审查。还有个有趣的现象，很多还没用过 Codex 的人，往往是通过让它去审查其他模型的代码，才意识到我们的模型到底有多强。他们通常会感叹，自己干脆直接用 Codex 写代码得了。
10 OpenAI 的护城河
面对 Cursor、Claude Code 等强劲对手，Codex 如何看待用户粘性和留存？既然迁移成本如此低，你们如何确保用户留在 OpenAI 的生态内？
Alexander Embiricos: 我们在构建 Codex 时采取了一种反直觉的策略，即完全开放。Codex 的核心调度框架是开源的，我们一直在努力降低用户的迁移成本。例如去年发布时，我们建立了一个名为 agents.md 的规范。这只是一个存放 AI Agent 指令的文件，我们没有把它命名为 codex.md，就是希望它能成为通用的标准。现在除了 Claude 以外，几乎所有 AI Agent 都在支持 agents.md，这非常棒。上周我们还推动将技能存放在一个名为 .agents 的中性文件夹里，而不是放在 .codex 目录下。同样，除了那个老对手，大家都跟进了。我认为给开发者充分的选择权是件好事，我们正努力让人们更容易尝试不同的产品。话虽如此，我认为目前的编码任务是相对孤立且闭环的，这种过程的两端都是供应商中立的，所以目前很容易在不同工具间迁移。
（关于真正的粘性）但当 AI Agent 开始处理更通用的工作时，情况就会发生变化。当 AI Agent 需要与 Sentry 对接，或者读取你的 Google Docs 时，粘性就产生了。因为决定将 AI Agent 接入这些核心系统是一个重大的决策。对于企业来说，信任 AI Agent 访问这些工具，并确保拥有严格的安全护栏、沙箱以及对系统操作的管控机制，是至关重要的。这种信任和配置工作，你不会想在不同平台上来回重复。我们在开发 Codex 时就预见到了这一点。所以我们采用了极其稳健的沙箱方案，在操作系统层级对 AI Agent 的行为进行管控。
（关于商业逻辑）这确实会让很多听众费解，我们投入巨资训练模型，然后又把这些模型提供给我们的竞争对手。作为风投，我真的很难理解这种逻辑，你也意识到了这一点。OpenAI 是一个非常奇特的工作场所。但本质上，因为我们在玩一场极其长线的游戏，对我们来说，如果竞争对手变强能让我们学习，这对我们是有利的。当然，Codex 团队也有巨大优势。我们有 ChatGPT 带来的海量分发渠道，有自主训练模型与框架深度适配的能力优势，这些是别人拿不到的。所以，我们是在为胜利而战，且优势明显。但我们也坚持长期主义，通过提供 API 和推动开放标准，让所有人都能受益。
11 AI Agent 应成为处理一切任务的入口
你与 Sam Altman 或 Brad Lightcap 对齐时，衡量成功的北极星指标是什么？是营收吗？如果是为了取代 IDE，为什么目前仍在使用“周活跃”而非“日活跃”作为衡量标准？
Alexander Embiricos: 实际上营收并不是首要目标，核心指标是活跃用户。我们目前衡量周活跃用户，标准是用户是否在产品中完成了实际交互，比如是否发送过 Prompt。
（关于衡量标准）我认为日活跃很快会成为更核心的指标。我们目前采用周活跃是内部的通用标准，在项目起步阶段这种做法非常合理。但我接受这个批评，未来确实应该转向日活跃。我们需要进入这样一个世界，面对任何给定的任务，你的第一直觉都是寻求 AI Agent 的帮助。这就像 Google 搜索的演进，过去任何需求只需进入文本框就能导向正确的位置，接着是 ChatGPT，任何信息需求只需在文本框输入就能获取。今年我们将见证下一阶段：对于任何需要执行的任务，而不仅仅是获取信息，你通过这个输入框或输入入口，就能触发某些动作。即便无法完成全部任务，也能搞定其中一小部分。
12 对话界面是否是下一波 AI 互动中持久的 UI 形态？
对话界面是否是下一波 AI 互动中持久的 UI 形态？如何看待 AI Agent 之间的交互以及未来企业内部（如费用报销）的自动化范式？
Alexander Embiricos: 答案是肯定的，但这涉及两个层面。如果想象一下未来，科幻电影中的 AI 往往是一个可以随心所欲交谈的实体。我不应该为了写代码去专门打开一个编码 AI，再为了销售去打开另一个工具。我应该只需与一个实体交流，它就能直接提供帮助。因此，对话或语音界面将成为所有能力的支柱，它可以加入任何群聊，自动发现该如何协助你。但对于术业有专攻的高级用户，如果所有工作都必须通过口述转达给助理，效率反而会降低。所以我们会将对话与根据需求定制的功能性图形界面相结合。我可能会通过对话来准备播客，但在处理产品和代码时，我会进入专门的 Codex 应用进行深度操作。
（关于 Agent 间交互）我们在构建 Codex 时注意到，对 AI 最高的效交互界面往往也是对人类最高效的。当人们问如何优化代码库以便 AI Agent 处理时，答案通常是，你自己看这套代码顺眼吗，人类处理起来容易吗？举个具体的例子，在代码库中运行测试，如果你过滤到只剩失败的测试，对人类和 AI Agent 都会更好。因此，AI Agent 之间的交互点与有人工参与时非常相似，这意味着你可以原子化地替换单个系统。
13 下一代“知识工作”数据从何而来？
在编码领域是否存在数据护城河？你们如何处理与数据供应商的关系，未来会亲自下场采集数据吗？在消费者端，Codex 是否会与 Replit 或 Lovable 竞争？
Alexander Embiricos: 根据我们目前的研究，我觉得我们已经有足够的数据来构建极其优秀的编码模型。现在更有趣的数据获取点在于知识工作任务。这类数据在互联网上很难获取。我们需要头脑风暴如何帮助模型擅长此类任务，比如付费请人模拟执行任务以学习轨迹，或者收购那些拥有大量内部沟通数据（如 Slack 记录）但已停止运营的初创公司。这种知识工作的任务分布比编码要困难得多。
（关于数据采集）我们的核心逻辑是如何跑得最快。内部建立大规模数据采集体系在时间上非常昂贵，而我们团队很精干。目前的观察是，如果需要发起大规模的数据战役，寻求这些专业公司的帮助是更高效的选择。
（关于市场竞争）目前来看并没有直接竞争。但口号就是你可以直接构建一切。我们注意到，许多技术背景较低的人开始通过这个应用构建内容。上周的一个重大公告是我们现在向免费版 ChatGPT 用户及移动端用户开放了部分 Codex 能力。就普及程度而言，这是巨大的提升。我们肯定会看到免费用户进来构建简单的东西，而在过去他们可能会去使用专门的工具。
14 未来你创办公司的方式是先找一个 AI Agent，让它构建一切
过去 12 个月你改变主意最大的事是什么？你最尊重的、知名度较低的竞争对手是谁？做过最艰难的产品决策是什么？五年后，哪些我们现在习以为常的事会变得不可思议？
Alexander Embiricos: 改变主意最大的是加入 OpenAI 之初，我以为我们都会与 AI 屏幕共享或直接交谈。但我错了。多模态模型的进展比我预期的要慢。相反，我们发现通过代码与电脑协作的 AI Agent 才是正道。这彻底改变了我对 AI 普及路径的看法，它主要不是通过视频和音频实现的。
（关于竞争对手）我首先想到的是 Amp 团队。他们来自 Sourcegraph，产品声誉极佳。我也非常尊重他们发起的标准化工作，比如 agents.md。虽然是个小举动，但它发起了整个社区的标准化，这非常棒。
（关于产品决策）我可以告诉你最痛苦的决策。曾有一段时间，Codex Cloud 实际上是无限使用的。当我们缩减到合理的限制时，引发了用户的不少反弹。我学到的惨痛教训是，你不能让东西无限量太久。
（关于未来五年）一个是手工编辑代码。另一个更激进的想法是，甚至连手工管理系统的部署和监控也会变得不可思议。未来你创办公司的方式是先找一个 AI Agent，让它构建一切。接着你增加更多的 Agent，最后才把人类合伙人拉进这个协作系统。你主要的沟通工具就是 AI 通信工具。你不再需要亲手处理痛苦的 CI 和部署流程，而是直接让 AI Agent 处理。
这篇文章的深度讨论揭示了编程与软件开发领域的深刻变革。如果你对 AI 如何重塑软件开发流程、以及未来工程师的工作方式有更多思考，欢迎来 云栈社区 与更多同行交流探讨。
发表于 12 小时前
|
查看: 1|
回复: 0
