不怕你走，就怕你不用AI写代码！OpenAI Codex负责人亲口承认：内部已很少再打开IDE

整理｜冬梅

2 月初，OpenAI 正式发布了其最新一代编程智能体GPT-5.3-Codex，这是目前 OpenAI 在 AI 编程领域的最新旗舰模型，标志着该公司在“智能体变成实际协作者”这条路线上的一次重要升级。官方发布中指出，GPT-5.3-Codex 在原有 GPT-5.2-Codex 能力基础上进行了全面提升，包括更强的推理能力、更高的效率和更广的工作流支持，同时提升了用户交互体验和长期任务处理能力，目标是让智能体像人类同事一样在整个开发流程中协作。

在权威评测上，新版本在多个行业相关 benchmark 上表现卓越，例如在软件工程综合评测 SWE-Bench Pro 和系统操作评测 Terminal-Bench2.0 上大幅领先前代，在 OSWorld 和其他能力指标上也表现显著，更重要的是整体推理速度提升约 25%。官方强调，这些改进不仅体现在代码生成能力，还包括调试、审查、架构设计等工程师真实需要的工作流环节。

在 Reddit、技术论坛等开发者社区中，GPT-5.3-Codex 的反馈呈现出明显的两极分化。一部分开发者分享了正面的经验，例如模型在 CLI 与 IDE 插件中带来的更流畅操作、新版计划模式提供的更清晰步骤反馈等，这与官方提出的“交互式协作和实时指导”方向一致。

但也有不小比例的用户发出了批评：有用户指出目前 GPT-5.3-Codex尚未通过 API 向所有开发者开放，部分平台（如通过 API key）无法直接调用最新模型，这让许多开发者难以在自定义环境中集成。

另一些用户反映新模型在某些编辑器里表现尚不成熟，例如在 Zed 编辑器中体验不佳，偶尔中断或无法按预期编辑文件，甚至有人因此重新回退使用老版本。

还有开发者表示，他们并不总是能获得“官方宣传的强大师任务表现”，尤其在 Web 生成等任务上出现停滞，并认为其它竞争模型（如某些 Claude 系列）在某些日常任务上体验更顺畅。

近日，OpenAI Codex 的产品负责人 Alexander Embiricos 做客了一档访谈节目，谈及了 Codex 的产品方向，目标并不只是“让 AI 写得更好”，而是将 AI 打造成一种贯穿软件工程全生命周期的主动型工程队友——能够理解任务、制定计划、执行实现、完成交付，甚至参与审查。

与许多模型负责人不同，Alexander 的视角明显更偏向“工作流”和“真实使用场景”。

在加入 OpenAI 之前，Alexander 曾联合创立协作工具公司 Multi 并成功退出，长期关注的不是技术极限，而是工具是否真的被人全天候使用、是否改变了人的工作方式。也正因为如此，这场对话没有围绕参数规模或基准测试展开，而是反复回到一个更具现实冲击力的问题：当工程师开始把完整任务交给 AI，软件工程这件事，正在发生什么变化？

在对话中，Alexander 明确否定了“AI 会减少工程师数量”的判断。他认为，未来五年工程师和创造者只会更多，而不是更少。原因并不复杂：历史上，“计算机”“程序员”这些词本身就被多次重定义，而“软件工程师”也正站在下一次重定义的门槛上。

真正发生变化的，是人才栈的压缩。在 Codex 团队内部，传统的前端、后端、基础设施等分工正在迅速模糊，每个人都被要求具备更强的全栈能力，甚至同时参与设计与产品判断。在这样的背景下，“工程师”不再只是执行者，而更像是问题定义者与结果把关者。Alexander 甚至半开玩笑地表示，某些情况下，产品经理这个角色是否仍然必要，都是一个值得重新讨论的问题。

他的判断很清晰：分工会被压缩，但人类作为创造者的地位不会被削弱。

如果说对未来的判断仍带有主观色彩，那么 Alexander 描述的OpenAI 内部变化，则更像是一种已经发生的事实。

他反复提到一个关键节点：GPT-5.2 Codex 的发布。在那之前，AI 更多扮演的是“辅助工具”的角色——自动补全、结对编程，人仍然需要坐在编辑器前，驱动整个过程。但从 GPT-5.2 Codex 开始，工作方式发生了本质变化：工程师不再“和 AI 一起写代码”，而是把整个任务直接委托给 AI。

在 OpenAI 内部，许多工程师几乎不再打开传统 IDE，而是全天候运行Codex。会议期间如果没有让 Codex 同步处理任务，反而会被认为是在浪费时间。Alexander 没有给出一个精确比例，但他的判断非常明确：现在 OpenAI 内部，绝大多数代码都是由 AI 写出来的。这并不意味着工程师“无事可做”，而是他们的注意力，已经从实现细节，转移到任务拆解、计划评估和结果审查上。

在对话的最后，Alexander 回答了一位顶尖高校学生的提问：如何在未来五年成为 AI 生态中有价值的工程师？他的态度出人意料地乐观——这是一个前所未有适合做工程师的时代。工具极其强大，理解复杂系统和代码库的成本被大幅压缩。但正因为“构建变得容易”，真正稀缺的东西反而更加清晰：主动性、审美，以及对质量的执念。

他的建议只有一句话：去构建高质量的东西。一个有思想、有完成度的项目，比任何标准化简历都更有说服力。

以下为完整对话内容，经 AI 前线编辑整理：

主持人：我的第一个问题可能有点奇怪，但我还是想问下。我对人们的动机特别着迷：你行动的动力更多是来自对失败的恐惧，还是对胜利的兴奋与渴望？

Alexander：我是个追求极致的人。比起害怕失败，胜利的渴望绝对更能驱动我。不过我得跟你坦白一件事：在加入 OpenAI 之前经营创业公司时，曾经历过至暗时刻——实际上那段日子黑暗时刻比比皆是——我突然意识到过去几个月自己一直在拼命避免失败。那一刻恍然大悟：天啊，原来这就是我如此痛苦的原因，很可能也是公司止步不前的根源。所以我得不断自我调整，重新聚焦于争取胜利的初心。但说到底，比成功欲望更强烈的，大概是我天生热爱创造，特别是为人们打造新事物。想到今年就无比振奋，因为将有无数尚未存在的精彩之作被创造出来，交付到众人手中。

主持人：马斯克曾预言编程会成为首批被大规模自动化的职业之一。基于你的职位和日常观察，你认同这个观点吗？

Alexander：我完全认同编程会是最早被大语言模型深度渗透的领域之一。不过说到“编程被自动化”这个说法，其实值得细品——这就像当年我们不再写汇编语言，转向高级语言编程时，能说编程被自动化了吗？并非如此。

我们只是得以用更高效率编写更多代码，结果反而是市场对代码的需求激增，需要更多软件工程师来创造价值。这种自动化更像是工具进化带来的职能转变，就像“计算机”这个词的起源：据说在布莱切利公园破译德国恩尼格玛密码时，需要专人打孔卡、操作机器、做大量表格运算——这些繁琐的机械操作后来被自动化了。甚至最早的电子表格软件，灵感就源于办公室里格子间工位排成矩阵，人们各自计算后将表格传给下个人的场景。这些具体操作确实被技术取代了，但每次这样的变革后，对最终成果的需求都会呈指数级增长，即便具体的工作形态已彻底改变，整个行业反而需要更多从业者参与其中。

主持人：所以你认为五年后工程师数量会增加而非减少，对吗？

Alexander：没错，其实我们也在不断重新定义术语的内涵——比如“计算机”这个词现在指代的东西早已不同，而如今我们又有了“软件工程师”这个头衔。所以我坚信未来会有更多创造者。

现在有个很有趣的观察：人才栈正在发生压缩现象。虽然当前我们仍然需要软件工程师、软件设计师，以及像我这样的产品经理——关于 PM 这个角色你们可以尽情调侃，说实话我也觉得未必需要——但或许当人们谈论“工程师”时，脑海中浮现的已经是比过去更全能的形态。倒退几年，绝大多数团队还严格区分后端工程师和前端工程师；而现在至少在 Codex 团队，这种界限已经非常模糊，每个人都更趋向全栈。因此我认为人才栈确实会持续压缩，但人类作为创造者的本质不会改变。

主持人：为什么你认为在这个世界里我们不需要产品经理？你这是在吊人胃口啊。

Alexander：首先我觉得产品经理这个角色本身就极难定义——它本质上就是个没有固定范式的岗位，目标就是灵活适配团队或业务的需求。比如当一群人正全力冲刺开发时，产品经理的价值在于后退几步，用前瞻性视野预判方向，协调各方资源推进市场落地，同时担任团队的头号啦啦队长和质量把关人。

但仔细想想，这些我描述的（可能也是我当前做的）所有工作，完全可以由一位兼具产品思维的资深技术负责人或设计师来完成。所以产品经理这个角色确实常常能发挥作用，但在团队规模真正变得庞大之前，可能并不需要配置太多这样的岗位。

AGI 的瓶颈是什么？

主持人：过去几天我可没少狂扒你的“底裤”——把你的文章、推文、过往采访翻了个底朝天，这趟探索简直乐趣无穷。你曾在某处提到，人类验证工作的速度和输入效率才是制约 AGI 发展的关键瓶颈，而非模型算力或架构本身。然后这话就撂在那儿没下文了，快给我解解惑：为什么说人类打字速度和验证工作会成为核心瓶颈？你这句话到底藏着什么深意？

Alexander：确实如此。这个话题很有意思。我认为现在存在多个瓶颈，但这或许是最能吸引眼球的一个。如果不介意的话，我们不妨用苏格拉底式问答来探讨：你目前每天使用 AI 的频率大概是多少？

主持人：每天 30 多次吧。

Alexander：那假设你完全不需要耗费任何精力，你觉得 AI 每天能帮到你多少次？

主持人：我认为在所有事务中，AI 将会全天候覆盖每一件事。

Alexander：确实如此。现在无论是 OpenAI 内部还是外部的工程师都在告诉我：他们全天候开着 Codex，从不合上笔记本电脑。开会期间若没让它运行着，简直就是在浪费时间——必须确保 Codex 随时在为我处理工作。

这确实很酷也很令人兴奋，但反过来说，要管理这些智能体、确保它们持续运转本身也是个庞大的工作量。回到刚才说的每天 30 次使用频率，我们观察 Codex 用户的使用数据也大致在这个区间。但在我看来，AI 本应每天为我们提供上万次帮助——只要算力允许，这个目标终将实现。问题在于，即便像我这样专门研究这个领域的人，明知该用 AI 处理所有事务，但我实在太懒，懒得敲那么多提示词；也缺乏足够的创意去发掘 AI 能帮忙的所有场景。结果我的使用频率和你相差无几。

直到现在，当我用 AI 完成像准备这次对话这样有趣的任务时，还会暗自得意：“不错，又解锁了 AI 的新用法。”这对你我这样热衷此道的人倒无妨，但我们不能指望普通人为享受通用人工智能的红利而付出太多学习成本。

理想状态应该是：使用 AI 无需琢磨提示词技巧，它就该简单到不费吹灰之力；你甚至无需意识到需要 AI 帮助，它自会理解你的处境，适时给予贴心的协助。

主持人：这正是我认为 Claude 做得好的地方——他们针对法律、Excel 等场景推出了定制化版本，让用户能直接上手建立 DCF 模型（虽然我对模型不感冒，但不得不承认比过去的操作强多了）。那么你认为你的职责是否就是将提示词和人工操作产品化，从而消除这一瓶颈？

Alexander：没错，这正是我们要做的——既要确保模型具备卓越能力，最终更要让 AI 高度产品化，可能是神奇的对话框、语音输入，甚至直接加入群聊就能自动提供帮助。

不过中间阶段其实藏着更深的门道，我认为当前最大的价值恰恰就藏在这个过渡期。具体来说，你可以尝试针对特定市场将 AI 的某个功能产品化，虽然很多公司都在这么做，但真正找准有效形态并不容易。之前你播客有位嘉宾说得特别在理：企业没有付费门槛根本没法落地 AI。

主持人：对，就是 Invisible AI 的 Matt Fitzpatrick 提到的这个观点。

Alexander：确实，从财务角度看是这样，但我其实完全不同意企业级优先的自动化路径。

我认为当前最重要的是为真实用户打造工具。正如 Matt 在播客中提到的，通过全职员工构建自动化流程当然可行，但这会受制于自上而下的视角局限和人力配置的边界。

而我憧憬的 AI 未来，是让每个人都成为被 AI 赋能的超级个体。要实现这个愿景，我们需要打造面向个人用户、能让所有人轻松上手的工具。当前最有趣的阶段，恰恰是为那些热衷于探索 AI 应用场景的先行者构建工具。回想 Cognition 的 Code 工具初次发布时的精妙之处，正是提供了一个能在终端中无缝使用的开放工具，激发用户自发探索应用场景。这启示我们，在将 AI 拓展到编程之外的工作领域时，最重要的不是过度定制垂直场景工具，而是打造足够开放的创作平台，让用户能针对任何任务进行创造性应用。

智能体开发的三个阶段

主持人：但这不就把责任和精力又推回给用户了吗？这恰恰回到了你之前说的“人类行动瓶颈”问题——如果连任务都不定义，等于把定义权完全交给了人类，而人类既缺乏这种定义能力，也缺少这样做的意愿。

Alexander：是的，我是这么认为的，这也是我觉得它是瓶颈所在的原因。

在我看来，整个过程基本分为三个阶段：首先，先让智能体在软件工程和编码领域做到足够出色，因为大语言模型本身就擅长这方面；其次，我们会意识到，要让智能体在更广泛的场景中发挥作用，让它能够操作计算机是非常有价值的，同时我们也会发现，所有智能体本质上其实都是编码智能体，因为编码是智能体使用计算机的最佳方式。

所以我们可以沿用这个极具灵活性的思路，把它开放给所有乐于探索和尝试的人，我们已经看到有人开始通过类似 Codex 这类应用这么做了，这类应用原本是为开发者设计的，但开发者们却用它来完成各种非编码类的任务；最后，等我们验证出有效的方案后，就进行你所说的产品化，打造出功能高度专一、用户能够开箱即用的产品。我认为我们会在未来几个月里快速走完这一整个过程。

主持人：你刚才提到的关于企业内全职员工部署和实施的问题，关键还在于数据安全敏感性、权限配置和访问条款——这些实际操作难如登天，而大多数人其实并没有我们想象的那么聪明和自信。尤其是在大型企业环境中更是如此。我认为确实需要全职员工深入介入，为各种横向解决方案进行定制化适配才能落地运行。我错了吗？

Alexander：我觉得你的判断是对的。如果你一开始就试图从零直接跳到一，脑子里又有一个宏大的愿景——比如构建一个覆盖所有流程的终极自动化系统——那确实会立刻撞上大量现实障碍。

我这里并不是贬义地说“宏大”，而是说这类项目不可避免地要处理安全、合规等问题，而这些问题都是真实存在的。你还需要打通各种数据系统、系统记录、执行系统等等。要完成这些，你基本上需要一个完整的、企业级的 IT 或数据基础设施团队来支撑。

但我们观察到，如果完全采用这种自上而下（top-down）的方式，结果往往是：严重低估、甚至浪费了 AI 在帮助企业中的潜力。

相比之下，更好的方式可能是并行推进。一方面继续解决系统层面的难题，另一方面，把 AI 先交到真正干活的人手里——那些每天在一线工作的员工。

当员工开始实际使用 AI，他们会逐渐建立起一种“心理模型”，理解 AI 能帮自己做什么、不能做什么。然后，他们会自然地把 AI 拉进自己的工作流中。

我举个例子：假设你在做客服工作，公司开始用 AI 自动化你工作中一些重要环节，但你自己从来没用过 ChatGPT，甚至被禁止使用。那么在这种情况下，你对“AI 到底是什么”是没有直觉的。

但如果是在另一种世界里，你一边日常使用 ChatGPT 工作，一边看到 LLM 正在自动化你的一部分任务，那你对 AI 的理解会深刻得多。你会觉得自己是被“加速”的，是有控制权的，甚至能影响自动化往哪个方向发展，而不是被一个“从天而降的黑箱系统”所取代。后者其实是非常令人无力的。

所以回到你提的问题：你提到的数据控制问题确实存在，也非常现实。但归根结底，每一个工具、每一个功能、每一个工作流，最终都是服务于某个具体的人——某个员工。而这些员工，最终都是通过浏览器、文件系统等接口在使用工具。换句话说，一切最终都会收敛到一个“界面”，而这个界面是可以被运行在本地计算机上的智能体（agent）所操作的。这也是为什么 OpenAI 会去做一件在外界看来有点“反常”的事——我们在构建自己的浏览器（Atlas）。

你可能会问为什么要这么做，原因有很多，但其中一个关键原因是：当我们从端到端严格控制浏览器时，就能为企业构建安全的、可控的智能体式浏览体验。

这样，智能体就可以“代理式”地访问那些企业还没有通过 API 或 FD（功能部门）完全开放的系统和流程。

GPT-5.3 Codex效率大幅提升，

我们如何做到的？

主持人：你之前提到，有些工程师甚至不愿意合上电脑，因为他们不想中断用 Codex 构建的效率。你们和 Cerebras 建立了合作，而 Cerebras 目前被认为是推理速度最快的算力提供方之一。这是一次非常漂亮的合作。那么，推理速度对使用 Codex 的开发者到底有多重要？

Alexander：简单来说：非常重要。

主持人：那这会不会形成一种“推理能力的垄断”？比如你们现在有了，竞争对手没有。

Alexander：这只是我的个人看法，但我不认为最终会走向一种垄断式的格局。市场上的竞争压力非常大，未来一定会出现多种不同的解决方案。

不过我可以透露的是：关于这次合作，我们很快会有新消息公布，而且我对此非常兴奋。这些东西一旦上线，会非常棒。

即便不谈硬件合作，仅从模型本身来看，比如 GPT-5.3 Codex，相比之前的模型，在效率上已经有了显著提升。我们收到的反馈是：开发者明显感觉到它比以前快得多，而且是“有竞争力的快”。此外，你还可以在多个层面做优化：模型本身的效率以及推理方式的改进。

举个具体的例子：我们最近在 API 层面做了一次更新，相关模型的响应速度提升了大约40%；而在 Codex 产品里，速度也提升了大约25%。所以，速度真的很重要，我们基本是在硬件、推理方式、模型层三个方向同时推进。

主持人：你刚才提到把 AI 交到用户手里，这让我想到推理成本的问题。我有位朋友 Jason Lemkin（来自 SaaStr）提出一个观点：“推理就是新的销售和市场”。意思是说，与其养庞大的销售和市场团队，不如把钱花在推理上，让用户更快上手、看到价值，最终甚至不再需要传统的销售和市场团队。这有点像下一代的 PLG（产品驱动增长）。你怎么看？

Alexander：说实话，我对这个观点是有些保留的。在这样一个“人人都能构建产品、构建门槛越来越低”的世界里，真正困难的事情并没有消失。什么是难的？是与客户建立真正良好的关系 并理解他们真正需要什么。

而且我认为，这些事情甚至比以前更难了，因为市场上的选择变得更多、软件数量爆炸式增长。

另外，构建“正确的东西”和“高质量的东西”依然非常难。

所以回到销售和市场这个问题，我并不认为它们会消失。相反，随着市场竞争加剧，它们的难度其实是在上升的，而不是下降。

在 OpenAI，

很多人不再打开 IDE 了

主持人：能不能聊点更具体的？比如在 OpenAI 内部，现在有多少代码是由 Codex 生成的？我记得之前 Claude for Work 的负责人 Boris 说他们内部几乎 100% 都是 AI 写代码。

Alexander：我先说我个人的感受，再说团队整体情况。基本上，我认识的大多数人现在已经很少再打开传统代码编辑器了。

这种变化是逐步发生的，但一个非常明显的“拐点”出现在GPT-5.2 Codex发布之后。那一代模型突然在以下几个方面变得非常强：

• 能持续运行更长时间

• 能端到端完成任务

• 能管理上下文

• 能更好地遵循指令

这也是我们后来决定做 Codex App 的重要原因之一。在 GPT-5.2 Codex 之前，我们更多是在用 AI 做自动补全 或者“结对编程”（pair programming）。 那时候，你仍然需要坐在电脑前，手放在键盘上，AI 可能帮你做一点点事情，但整体节奏还是你在“开车”。

而从 2024 年 12 月 GPT-5.2 Codex 开始，我们切换到了一种完全不同的工作方式：我不再和 AI 一起写代码，而是把整个任务直接委托给它。流程变成了一起制定计划、确认规格、然后我就“放手让它跑”

这是一次非常本质的转变。

这也是为什么我们在上周发布了 Codex App——我们想打造一种更适合“委托（delegation）”而不是“结对”的产品形态，让你可以同时把任务分配给多个智能体。

即便在 OpenAI 内部，这种变化也非常剧烈。我没有一个精确的百分比数据，但可以说：绝大多数代码现在都是由 AI 写的。很多人甚至不再打开 IDE。即便打开，更多也是为了设计模块之间的接口 或协助规划方案， 真正的代码实现，已经不再由人类直接完成了。

Codex App 为什么

不是一个传统 IDE？

主持人：那你觉得 24 个月后，IDE 还会是开发栈的一部分吗？

Alexander：这要看你怎么定义 IDE。“集成开发环境”这个词本身就非常模糊，几乎什么都能算 IDE。如果按这个定义，那你甚至可以说 Codex App 也是 IDE。但我个人并不这么看。在我心里，IDE 是一个极其强大的编辑器。而我们在设计 Codex App 时，刻意没有加入文本编辑功能，就是为了让使用方式足够清晰。

Codex App 的核心能力在于：管理多个智能体、委托任务以及审查变更。它还有一个非常显眼的“Skills”系统，这是一个开放标准，能支持大量非编码任务，比如：任务分流和部署监控。但它没有文本编辑器，这是我们有意为之的设计选择。

主持人：如果大量代码都是由 Codex 生成的，那你们内部现在是怎么做代码审查的？AI 会参与内部的代码审查吗？

Alexander：这里其实有几个层面。首先，你想做什么这件事的“规格说明（spec）”或“计划（plan）”，变得前所未有地重要。你需要从架构层面去思考：这段代码应该如何工作。最近我们上线了一个非常重要的“计划模式（Plan Mode）”。它的工作方式和其他系统不太一样：智能体会先独立提出一个完整的执行方案，通常是一个相当长、相当详细的计划，然后再回来问你：

你是否同意这种实现方式？ 是否希望对某些部分提出修改意见？

这其实非常像现实中的场景：假设你招了一个刚加入团队、对代码库还不熟的新工程师。在正式开始写代码之前，他需要先向团队提交一份类似 RFC（Request for Comments）的方案，征求大家的意见。所以，即便这还不是传统意义上的代码审查，但“对计划的审查”正在变得越来越重要。这是因为我们已经进入了一个更偏向“委托（delegation）”而不是“协作编写”的工作阶段。

这一点往往被低估了。接下来才是更传统意义上的代码审查。我听到的一个非常常见的问题，尤其是在开源社区，是所谓的“AI 垃圾代码（AI slop）”。很多人直接把 AI 生成的代码提交成 PR，这些 PR 质量很差，提交者可能根本没有测试过，甚至没有真正审过代码。这是一个真实存在的问题。

因此，在使用 Codex 时，一个非常常见的做法是：让 Codex 审查它自己生成的 PR 或代码改动。而 Codex 在这方面表现得非常好。我们是明确训练过模型去做代码审查的。训练目标包括：给出高信噪比的反馈、尽量减少“误报式批评”（false positives）。这意味着：当 Codex 提出修改意见时，你是可以高度信任它的。

所以在 OpenAI 内部，以及我们推荐给外部用户的做法是：主动让 Codex 做代码审查，甚至可以设置为自动审查。

事实上，在 OpenAI，几乎所有代码在推送到主仓库时，都会自动经过 Codex 的审查。一个挺有意思的现象是：有些人为了“测试模型有多强”，会让 Codex 去审查其他模型写的代码。结果往往是：“好吧，那我可能干脆直接用 Codex 写代码算了。”

主持人：你刚才提到，对于那些还没用过 Codex，或者很久没回来用的用户，你怎么看“留存”这件事？我记得 YC 合伙人 Tom Blomfield 之前发过一条推文，提到不同代码智能体之间的切换成本——不管是 Cursor、Claude Code 还是 Codex。在这种情况下，用户到底有多“黏”？你们是如何思考留存的？

Alexander：我们在 Codex 上采取了一种相当反直觉的策略：把它做得尽可能开放。比如 Codex 的核心执行框架（harness）是开源的，我们一直在努力降低用户在不同工具之间切换的成本。举个例子：去年我们刚发布 Codex 时，做了一件很简单的事——我们只是“确立”了一个约定，而不是强推一个品牌化标准。这个约定叫agents.md。它是一个文件，你可以在里面写给智能体的指令。

我们刻意没有叫它codex.md，而是希望它成为一个所有智能体都能用的通用约定。现在，几乎所有智能体都在使用agents.md，这其实是一件很棒的事情。就在上周，我们还推动了另一件事：把Skills（技能）——也就是给智能体用的脚本和指令——放进一个中性的目录里，叫agents/，而不是放进codex/这样的私有命名空间。

同样，除了“那个熟悉的例外”，大家基本都跟进了。从开发者角度来说，这意味着：选择更多 并且试错成本更低。当然，目前来看，代码生成这类任务本身是高度“封闭”的（hermetic）。你可以把它理解成美剧里的“单元剧”：智能体读取一个通用的 agents 文件、使用通用的 skills、生成一个补丁、补丁提交进 Git。

从输入到输出，都是高度厂商中立的，所以切换成本很低。但未来会发生变化。当智能体不再只是写代码，而是开始接入 Sentry、操作 Google Docs 或连接企业内部系统，这时，“连接某个系统”本身就变成了一次高度粘性的决策。尤其在企业场景下，你必须信任：智能体能访问这些系统，同时又有足够严格的安全护栏、沙箱和权限控制。而这些事情，你是不愿意反复做很多次的。

所以我们在构建 Codex 时，其实已经提前预判了这一阶段的到来。这也是为什么我们采用了极其保守的沙箱策略——本质上是操作系统级别的控制。我个人很喜欢一本书叫《Seven Powers》，讲的是企业构建长期价值和可持续性的七种方式，其中之一就是“留存与黏性”。但对我们来说，这件事的优先级其实有点不一样。

“赢”的决定性因素：

算力优势 + 最好的模型

主持人：但如果从商业角度看，你们肯定还是会关心：如何让用户留在 Codex，而不是在 Cursor 或 Claude Code 出现更好模型时立刻切走？

Alexander：这是个很好的问题。当然，我们是在经营一家公司，但从根本上说，我们的使命是“安全地把 AGI 的收益带给全人类”。所以对很多人来说很反直觉的一点是：我们花了巨大的精力训练模型，然后把这些模型提供给竞争对手使用。我知道，从风险投资的视角来看，这几乎是难以理解的。

主持人：这在 VC 视角里确实非常反常。

Alexander：是的，但这正是 OpenAI 非常独特的地方。我们在玩一场极其长期的博弈。当竞争对手变强时，我们是能学到东西的，这反而对我们有帮助。如果他们是封闭的、黑箱式地进步，我们反而学不到。

举个例子：今天早上我还转推了 Warp 的一个新发布。我和他们没有任何商业关系，但他们在“云端 + 本地智能体协作”这件事上的一些设计思路，真的很有启发性。这个领域有意思的地方就在于：大家在不同公司、不同路径上，正在同时得出相似的结论，然后把它们实现出来。

当然，从现实角度讲，我们也并不是没有优势：ChatGPT 带来的巨大分发优势、自研模型与自有执行框架的深度耦合、对新模型的提前访问权。所以我们确实是在“为了赢而竞争”，而且我们有很多优势。但与此同时，我们也在坚持把模型服务提供给整个生态，同时推动开放标准。

主持人：如果一定要用投资语言来问一句：最终决定胜负的关键是什么？是 GTM？是品牌？是产品执行？还是算力和推理速度？

Alexander：如果从公司整体角度说——当然这已经远远超出我的职级了——我会说是：算力优势 + 最好的模型。

为了实现这一点，我们需要成功的商业模式来支撑持续投入。而 Codex 这种“研究 + 产品”高度融合的团队，其实会反过来倒逼模型进步得更快。但如果从产品层面来说，我认为最重要的一点只有一个：做出一个真正好用、让人愿意用的产品。我们一直强调先服务好个人，让人真正“熟练”地使用这些工具，再自然地把自动化引入工作流。这条路径看起来有点反直觉，但我认为它的长期影响力会更大。至于企业市场，GTM 非常重要。我学到的一个惨痛教训是：你不能只是对企业说一句“你们随便用吧”。

你需要做大量教育、支持复杂配置、和负责人（比如开发者体验负责人）一起设计工作方式，再把这种工作方式复制到整个组织中。

主持人：那你们内部衡量成功的核心指标是什么？是收入吗？

Alexander：不是。最核心的指标是活跃用户数。

主持人：具体是 DAU 还是 WAU？

Alexander：目前我们主要看 WAU（周活跃用户）。标准是：这个人是否真的在产品里完成过一次交互，比如发送过一个 prompt。

主持人：如果 Codex 是要替代 IDE 的，DAU 会不会更合理？

Alexander：我同意。DAU 很快会更合理。我们现在用 WAU，更多是历史原因。我理想中的状态是：任何一个任务，你的第一反应都是“让一个智能体来帮我”。

就像查信息打卡 Google，问问题打开 ChatGPT。

下一阶段是人们做任何事先打开一个输入框，然后智能体开始行动，哪怕它只帮你完成其中一小步。

主持人：你认为 Chat 会成为 AI 与人类交互的长期主界面吗？

Alexander：简短答案是：会。

但更准确地说，是“对话界面 + 专用界面”的组合。如果你看科幻电影，未来的 AI 往往是一个你可以用任何方式、聊任何事的存在。你不应该需要区分这是我的编程 AI 或者这是我的销售 AI。

你只是“跟一个东西说话”，它就会帮你。但对高阶用户来说，只靠聊天会很烦。就像你有一个助理，但你所有事情都必须通过“对话”才能完成，那是低效的。

所以最终形态会是 Chat / 语音作为通用入口，针对不同角色的专用 GUI。比如我：用聊天做播客准备，用 Codex App 深入看代码。而一个市场人员用聊天问产品问题，用专门的分析界面看广告数据。

构建高质量代码模型的

数据是充足的

主持人：我在 LinkedIn 上提到过这档节目，有一位来自另一家公司的优秀投资人留言说——

他用了一个“哈利·波特”的比喻，说某家公司就像伏地魔，“那个不能被提及名字的人”。他说：“你应该问问他，代码数据的护城河到底怎么看？现在是不是 Anthropic 已经拿走了所有数据？”

Alexander：从我们目前看到的情况来看——当然，这一点我也会更多地参考我们研究团队的判断——我们认为用于构建高质量代码模型的数据是充足的。我反而觉得，现在更有意思、也更困难的数据来源，在于知识型工作（knowledge work）任务。这类数据在互联网上几乎不存在，比如战略分析、复杂决策、跨角色协作，实际业务判断过程。

所以你会开始产生一些很有意思的想法，比如：是否需要付费让人去“模拟完成任务”，从而学习这些完整的任务轨迹，是否应该收购一些已经倒闭、但沉淀了大量协作数据的公司，比如使用 Slack 的组织。总体来说，知识型工作的任务分布，比编码复杂得多，也稀缺得多。

主持人：既然这些数据如此稀缺，那你们如何看待和数据服务商的关系？比如 McCor、Turing、Invisible、Scale 这类公司。你们会在这方面投入 10 倍资源，还是反而觉得“数据太贵了，不如自己做”？

Alexander：我们的判断标准其实只有一个：哪种方式能让我们跑得最快。在内部搭建完整的数据采集体系，时间成本和人力成本都非常高，而我们是一个相对精干的小团队。所以到目前为止，我的观察是：一旦我们需要大规模跑数据项目，通常会选择和这些公司合作，把精力集中在模型和产品本身。

Codex 会走向低端消费者市场吗？

主持人：在消费端，Codex 会不会和 Lovable、Replit 这类工具正面竞争？比如一年或两年后，是否会下沉到“任何人都能做一个 about me 页面或小企业网站”的层级？

Alexander：目前来看，我们并不觉得自己在和它们直接竞争。如果你看过我们的超级碗广告，口号是：“You can just build things.”（你可以直接开始构建）。通过这个应用，我们注意到：越来越多技术背景不强的人，也开始用 Codex 来做东西了。他们做的事情通常很“Hello World”级别，但确实在发生。而且我们最近有一个很大的变化：开始向免费 ChatGPT 用户和 Go 计划用户提供部分 Codex 功能。这在“可用性”层面是一次巨大的扩展。所以我确实预期，会有一些用户原本可能会去用专门的低代码工具，但现在因为 Codex 就在他们手边，于是直接用 Codex 做一些简单的构建。

主持人：如果让你说一件“最想做得不一样、但目前还没法做的事”，会是什么？

Alexander：这是个有意思的问题。老实说，最近这几周对我们来说非常好，我对当前发生的一切都挺兴奋的。

主持人：这种“风向变化”的感觉，团队内部能明显感受到吗？

Alexander：绝对能。我们对这种变化非常敏感。如果回看 Codex 的历史：去年我们第一个发布的产品，是一个听起来非常惊艳的想法——给每个智能体一台云端电脑，可以并行完成任务。

坦白说，它并没有像我们后来发布的产品那样成功。从去年 8 月 GPT-5 之后，我们开始全力推进交互式编程，而这正是当下市场竞争最激烈的方向。公开数据上看从 8 月开始，我们大约增长了 20 倍，到年底，又几乎翻了一倍。但真正的变化发生在上周。我们一直认为自己拥有最智能的模型（Codex 5.3），但用户反馈是模型偏慢、不够“好玩” 、在工作过程中沟通感不强

我们正面解决了这些问题。

即便对比某个在我们之前 20 分钟发布、短暂“state-of-the-art”的竞品模型，我们也明显感觉到了变化。

同时，我们一直被诟病的一点是：IDE 插件体验很好，但 CLI（命令行）不够精致。而现在这个 App 的反馈几乎是一边倒的正向评价——简单、直觉，甚至“出乎意料地简单”。很多曾经的批评者也被转化成了用户。再加上超级碗广告、免费开放策略——所以回到你的问题，我现在最想做的两件事是：

第一，我想重新回到云端智能体（cloud agent）。去年我们从云端转向交互式编程，是一个非常理性的决策：如果用户还不能流畅地使用工具、还不能简单地让它跑起来，就贸然推进自动化工作流，那只会变成“只有极少数高级用户能用的空想”。

但现在不一样了。当用户每天都在用、每次使用都会配置得更好，那么让它独立在云端运行，就不再是一个巨大跨越。

第二，是关注真正的瓶颈。现在，写代码本身几乎已经变得“廉价”。真正难的是：如何做代码评审、如何判断质量以及如何确认方向是对的。这些问题仍然被严重低估、投入不足。

我的目标是：最终让一个你信任的智能体，可以端到端负责一个微服务或内部工具，完成完整的迭代闭环，甚至直接接收用户反馈，而不需要人类审查。这在智能、在安全、在控制层面，都是极其困难的问题。

市场终局：少数超级智能体，

而不是十几个工具

主持人：你认为 Benchmark 和评测到底该占多大权重？

Alexander：这是个可能让你不太满意的答案：两者都重要。Benchmark 能很好地衡量“智能水平”，尤其是在评测还没被刷爆之前，进步非常有参考价值。但你必须把它和使用体验结合起来。而体验，本质上是“感觉（vibes）”。不管是内部同事还是客户，我总是惊讶于：人们对模型的评价有多么依赖感觉。人生本来就很“vibes based”。我对孩子说的教训是：人们更愿意和他们喜欢的人一起工作。

主持人：投资角度看，你如何判断这个市场的最终形态？

Alexander：我认为，最终会是更少的玩家，捕获更多的价值。我们现在处在一个“过渡期”：目前真正实现产品市场匹配的，几乎只有编码智能体。但这是暂时的。长期来看，智能体会变成什么都能帮你做的超级助手。

在那样的世界里你不会希望公司里有 12 个不同的智能体，让员工自己去想“该和谁说话” 。那样他们就无法形成熟练度，也就无法真正把自动化融入工作。相反，如果你只有一个可以聊任何事情的智能体，员工的 onboarding 就是一句话：“有事就找它。” 它会成为工作的重力中心。

我以前在 Dropbox 工作。在 Slack 崛起之前，我们曾讨论过：人们是该在文档里评论，还是去 Slack 里讨论？文档内评论更高效，但现实是：Slack 成了沟通的中心引力场。哪怕效率更低，人们也更愿意在那里交流。我认为，未来的智能体，也会发生同样的事情。

SaaS 是否会被模型公司“吃掉”？

主持人：现在的人才争夺有多激烈？我常对公司说：与其在旧金山，不如在欧洲建团队，因为 SF 的人才又贵又难留。我错了吗？

Alexander：人才战争现在非常激烈。即便是在OpenAI，我们品牌很强，也依然要花大量精力去“赢下”心仪的候选人。没人是“免费送上门”的。

主持人：在股权定价下，最顶尖的人才还觉得有吸引力吗？

Alexander：目前没有人向我表达过相反的看法

主持人：你刚才提到，目前智能体真正大规模使用的场景，主要还是编码，少量扩展到比如客服。但从投资角度看，我今天在寻找那些能长期积累价值、为客户持续提供卓越产品的公司。

现在市场上有一种很强的观点：大型 SaaS 公司的收入耐久性接近于零，SaaS 已死，因为模型提供商（你们、Anthropic 等）会“来吃我们的午餐”。 你会如何建议？

Alexander：我的第一反应其实非常朴素：所有东西最终都是为人服务的，否则意义何在？

即便是 SaaS，本质上也是为人设计的。所以我会反问几个问题：这家公司是否真正拥有与“人”的关系？ 或者，它是否掌握了一个极其关键的系统记录（system of record）？

如果答案是“是”，那我并不认为这家公司会轻易消失。事实上，在 AI 时代，这两点——

人与系统的交互入口 + 核心记录系统，可能比以往任何时候都更重要。

反过来，如果一家 SaaS 公司只是一个“胶水层”：不直接面对人也不拥有系统级记录，那我会更谨慎。我不是这方面的终极专家，但这种公司让我更不安。

Alexander：如果基于这种逻辑再看市场，比如Salesforce、ServiceNow股价下跌 20%、30%、甚至 40%，我认为这种反应被严重夸大了。

确实有一些公司处境艰难。坦率说，我认为Dropbox正面临非常困难的局面。

但像Monday.com这样的公司——对其主要用户群体（大量中小企业和消费者）来说：你能不能用 AI 临时“vibe coding”一个待办清单？可以。

但成本是否划算？并不划算。

一个待办清单的需求本身非常稳定、简单：添加任务、完成任务、查看历史、分配成员。

并不值得反复用 AI 定制。所以现实是：大多数人会继续用现成工具。市场的恐慌情绪，更多是条件反射式的过度反应。

不过我确实认为：客服会成为被强烈冲击的领域。老实说，我不太愿意站在那个赛道上。

给下一代工程师的建议

主持人：最后，请您回答几个网友的提问。有位学生提问是这样的我是 CS 学生，在斯坦福 / 剑桥 / ETH。如果我想在未来 5 年成为 AI 生态中有价值的工程师，你会怎么建议？

Alexander：说实话，从未有过比现在更好的时代来当工程师。你拥有前所未有强大的工具能快速理解复杂代码库、能让 AI 帮你规划改动，甚至能把过去几天的研究压缩到几个小时。所以首先，你应该非常乐观。

但问题变成：既然构建变得容易，什么变得稀缺？我给出的答案是：主动性（agency）、审美（taste）和质量（quality）。

我的建议只有一句话：去构建东西，而且是高质量的东西。当有人带着有思想的项目来找我，那比一份标准简历有吸引力得多。

https://www.youtube.com/watch?v=S1rQngjpUdI

声明：本文为 AI 前线整理，不代表平台观点，未经许可禁止转载。

会议推荐

InfoQ 2026 全年会议规划已上线！从 AI Infra 到 Agentic AI，从 AI 工程化到产业落地，从技术前沿到行业应用，全面覆盖 AI 与软件开发核心赛道！集结全球技术先锋，拆解真实生产案例、深挖技术与产业落地痛点，探索前沿领域、聚焦产业赋能，获取实战落地方案与前瞻产业洞察，高效实现技术价值转化。把握行业变革关键节点，抢占 2026 智能升级发展先机！

今日荐文

你也「在看」吗？