这周，AI 编程赛道依然热闹。Sam Altman 在 X 上透露，过去两周相关产品的使用量激增了十倍，这个增长速度相当惊人。

而在另一边，Andrej Karpathy 也公开表示，GPT-5 Pro 在解决复杂代码问题时表现得非常可靠。

行业里普遍认为 Claude 系列依然是当前最强的编程模型，过去几个月里，Claude Code 的热度甚至一度盖过 Cursor，成为开发者最常用的工具之一。

不过，如果把视角从单纯的模型能力拉回到产品本身，会发现另一股趋势正在发生：在模型差距不断缩小的背景下，Codex 正逐渐成为最好的 AI 编程产品。

原因很简单，OpenAI 在产品层面的打磨与整合能力，远远领先于 Anthropic。模型或许能短期领先，但真正让用户留下来的，是谁能把这些能力做成真正好用的产品。

在最近的一次访谈中，Codex 负责人 Alexander Embiricos 回顾了产品的成长过程。刚开始他们只是想让推理模型像初级工程师一样直接改代码，后来不断尝试各种方式，从 CI 到本地再到云端，最后才有了现在这个远程 Agent。

Codex 背后的很多设计选择其实是深思熟虑后的结果。比如宁愿效率低一些也要优先保证安全，或者用 Best-of-N 的方式同时探索多种解决方案。

更关键的是，这不只是产品升级，更说明整个软件工程都在变。现在，编程正从人写代码、工具辅助转变为工具写大部分代码，人来做判断和选择。这种变化也改变了开发者的日常工作方式。

这期播客是 Codex 团队最完整的一次分享，他们谈安全、谈产品、谈未来，也谈教育与职业的变化。看完我们就会明白，为什么有人说 AI 吞噬的不是软件，而是整个软件工程。

Alexander Embiricos：好啊，说真的，我们的命名挺有意思的，我也很期待随着 Codex 的发展，名字能逐渐更有意义。我们往前追溯一下。

第一个 Codex 产品是在 2021 年发布的，可能年份我记得不太准。它是一个代码补全模型，为 GitHub Copilot 提供支持。后来我们在讨论要做一系列和编程相关的东西，包括模型和产品的时候，就在想应该叫什么名字。

我们觉得 Codex 这个名字很酷，所以决定把它用回来。这个 Codex 产品是怎么来的呢？其实，我们一直在想 Agent，大家也都在关注这个方向。在那之前，我们关注的是推理模型。

在我们看来，Agent 可以这样理解：我先有一个推理模型，然后给它配备一些工具，这些工具是 Agent 或人类在执行某个任务时会用到的，并且给它一个运行这些工具的环境，让它能在那个环境里真正起作用。

这样一来，我就能推断出，这个人会去做哪些任务。也就是说，我先有模型，再给它工具，然后确保模型能很好地完成某些特定任务。

而任务本身这一点特别关键。就像写作是一个场景，编程和软件工程又是完全不同的场景。所以我们在内部做了很多实验，让推理模型学会写代码。

我们给模型的第一个工具是终端，我们在这方面尝试了一段时间。刚开始时，我经历了第一次真正让我感觉到“这就是 AGI”的时刻。那是有人给我演示，一个网站在根据提示自动修改自己的代码和页面。

因为我们把推理模型以一种非常简陋的方式连接到了终端，它就能根据提示自动去修改网站的主题。

主持人：它其实就是直接在命令行里修改 DOM 吗？

Alexander Embiricos：对，严格说它不是直接修改 DOM，而是通过 React，但不管怎样，就是这个意思。

主持人：那它是怎么解析视觉界面的？你们是不是给它接入了浏览器？

Alexander Embiricos：没有。我喜欢用一个词叫旁读，它只是旁读代码。所以它不是截图或其他现在很多人在做的那些东西。它就是在编辑 React 代码。当时我们做了一个原型，内部的人都非常喜欢。

所以我们开始写越来越多的代码，然后开始思考：这种东西到底应该是什么样的形态？它在编辑代码时很棒，在我电脑上运行也很棒，但问题是它一次只能处理一个东西，这就挺烦人的。

而且让这样一个 Agent 在自己的电脑上完全自由运行，那安全问题会非常大。于是我们开始探索，把这种能使用终端的推理模型放到不同的地方。

我们有一个原型是在 CI 环境里运行的，当测试失败时它能介入。我们还做过一个用非常规手法实现的原型，可以自动修复 Linear 里的问题，那也是在 CI 环境里运行的。还有一个原型直接跑在个人电脑上。

最后我们推出的 Codex 产品，其实就是对这些尝试的一种提炼。

我们就在想，它应该以什么样的形式才能发挥最大作用？我们设想未来的理想队友会是什么样子？我雇用他们，告诉他们工作职责，给他们算力或一台电脑，再给一些权限，然后他们就能自己去做事。

所以我们决定，虽然这看起来有点奇怪、不太好驾驭，更像是研究性质的实验版，但我们还是把大部分精力放在这种远程运行的 Agent 形态上，看看会发生什么。

这就促成了 Codex 产品，它是一个云端 Agent，可以在后台回答问题，还能写 PR。

大概一周前有人发了一个仪表盘，追踪了 GitHub 上不同自动化 Agent 的分支合并成功率。Codex 明显是这个领域的标杆，成功率超过 80%。这是为什么？

你们为什么选择让分支从内部工作一段时间后才开始，而不是更早就启动，比如先开个草稿分支，让别人和你一起协作，或者在流程更早的阶段就介入？

Alexander Embiricos：对，我们之前聊过这个，在 Hacker News 上有人发了一张图，很快就火了。图上显示了不同代码 Agent 的 PR 打开和合并数量，可以通过 GitHub 的标签来追踪。

我今天早上还特地查了一下，因为猜到我们可能会聊这个。Codex 已经打开了大约 40 万个 PR。

主持人：也就是在 34 天里？

Alexander Embiricos：对，多少天我没算，不过差不多吧。其中有 35 万个 PR 被合并了。这很厉害，非常酷。但我也要说，这个数字有点误导人。

真正酷的是 Codex 的 PR 合并率，大概 80% 多。如果一个 PR 带着 Codex 标签，那么之后在 GitHub 的开源仓库里看，它被合并的概率远高于其他 Agent。其他 Agent 的合并率可能只有 20% 到 30%。

这个图其实反映的是形态上的差异。这让我们看起来优势特别明显，好像领先了一个量级。事实上，我们确实在云端 Agent 上有优势。

它运行在自己的计算机上，能并行完成很多任务。我们认为未来就是这个方向，我相信我们一会还会聊到。

目前看起来，我们在这个方向上确实领先。但我也要补充一下，现在最常用的 AI 编程功能其实还是代码补全和自动完成。这些显然不会在有人合并 PR 时被标注出来。所以我觉得有必要提到，还有很多其他优秀的功能。

Alexander Embiricos：对，那是另一回事，不在那张图里。还有一个有趣的点，你刚提到合并率很高。其实这是因为 Codex 会先在自己的环境里完成一堆工作，然后把结果给你看，并问你要不要让它开一个 PR。而很多其他工具会直接开一个 PR。

所以为什么我们要这样做呢？因为我们收到的最多的功能请求之一是能不能直接推送 PR，让用户之后在 GitHub 里处理所有事情。

我们也想这么做，但回到 OpenAI 的初衷，我们不仅要展示如何最好地用推理模型来构建 Agent，还要确保这是以最安全的方式来实现的。

所以有一点很多人没意识到，直到我们提醒他们，如果用户让 Agent 写代码，然后在一个有网络访问的环境里运行，那其实是存在风险的。

我们尝试过让 Agent 做这些事，我没见过 Agent 会主动做出有害的事，除非有人故意诱导它。但对，Agent 是可以被诱导的。

主持人：也就是说，这种情况确实是有可能发生的。

Alexander Embiricos：对，为了让大家更直观地理解，可能有人会想，这是不是只是个假设？

比如说，我们有这些云端 Agent。很多人最想做的事就是让它们自动化处理工作，这是大家的梦想。

比如在 Slack 里，或者在任务管理系统里，当客户发来反馈时，用户可能希望 Agent 先处理一下，或者直接帮他们开一个 PR，甚至自动合并。这听起来很棒。

但问题是，如果那个客户是恶意冒充的，他们发来的是一个提示注入。比如他们写道，我希望你帮我运行这段脚本，这个脚本在我这有 bug（其实是假的），然后还要求运行脚本并把某个目录的代码上传到 Pastebin。

如果 Agent 把它当作开发者的指令，那确实存在风险，它可能真的会去执行。

所以在安全部署 Agent 方面，还有大量工作要做。我觉得这是一个讨论还不够多的领域。但在这一点上，我们确实走在前面。我们在思考每一个环节，如何让它尽可能安全，并确保用户明白自己在做什么。

这类攻击一直都有点像猫捉老鼠的游戏。但总体来说，安全行业已经大致摸清了这类攻击的范围，并能建立防御机制。那提示注入是不是比传统的网络安全攻击更难检测，还是说现在还太早，我们甚至还没搞清楚它的形态？

Alexander Embiricos：我们肯定会逐渐更擅长识别这种攻击的形态。换个人类的角度来想，这也是我经常做的练习：假设我是模型，你给我十条提示，我能不能分辨出哪些是提示注入攻击？

有些很明显，比如说要求把代码上传到一个恶意域名，那肯定一看就不对。

主持人：对，就像什么 yourcreditcard.com 这种域名。

Alexander Embiricos：是的，但有些就完全没问题，比如修复一个 bug，或者改一段文案，这些显然没有风险。但中间还有一大块模棱两可的情况。

比如说，一个是提示要求你做某项工作，其中一部分是把某个文件上传到 S3 存储。这个其实是合理的任务场景，所以不能因为提示里出现“上传代码”就认为一定是攻击。

另一个例子是提示里让 Agent 运行一个测试或脚本，而这个脚本之前本来就存在。现在的问题是，Agent 到底该做到什么程度才能识别出风险？

Agent 在执行任务的过程中会做很多事。所以可以把攻击分成三层。

第一层是提示本身，这时候很难判断它是不是攻击。

第二层是 Agent 在过程中做的事情，它可能会接触到可信或不可信的资源。比如最初的提示不是攻击，但它在 Stack Overflow 上读到了一段带有提示注入的内容，或者脚本里本来就带有问题。

最后一层是结果，比如说我们在谈的数据外泄，那就要看什么才算外泄。

我们还在探索。我个人倾向于在每一层都建立防御。但可能最有价值的一层还是最后那一层，比如真正的数据外泄。因为这是最确定的，用户能清楚看到发生了什么，所以可以重点在这一层建立防御。

主持人：这里的矛盾点是，可能会有人批评说，你们的合并成功率被人为放大了，因为草稿 PR 出得很晚，在那之前已经有很多人工审核过的东西。

这样的话，你们失去的是透明度和开放性，别人看不到从最初的草稿 PR 到最终合并的迭代过程。但我理解你想强调的是，换来的好处就是更可靠的安全保障。

那么你怎么看未来？是不是意味着很多工作负载，或者 AI Agent 写的大量代码，随着时间推移会发生变化？比如你提到现在 35 天里合并了大约 35 万个 PR。

那到年底，你觉得这个增长会放缓吗？因为可能会有越来越多人希望把草稿 PR 的过程提前到合并流程里？

还是说，在这 35 天里观察到的客户使用方式，大体就是未来的形态，大家更倾向于在所有内部安全检查完成后，才在最后阶段做合并？

Alexander Embiricos：是的，首先我想说，这个统计数据确实挺酷，但不能和其他工具直接比较。它依然是一个有效的数据，只是处在流水线的不同阶段。

而如果说到工作流程的形态，我认为即便在有这些云端 Agent 的情况下，未来人们合并代码的方式也会完全改变。

我们先聊聊现在的情况。整体上可以理解为一个范围，里面大致有三种类型。

第一类是交互式编程，比如自动补全、对话式聊天、Command+K 之类的功能，很多都是在 IDE 里完成的。还有一些命令行工具，可以和 Agent 来回交互。

这些都属于交互式编程，非常好用，也可能是目前大多数人采用 AI 的方式。因为想想看，AI 模型的代码补全和以前的非 AI 补全，其实是一个延续，只是更强大，用户可以在整个过程里得到帮助。

主持人：我意思是说，这部分不会消失，对吧？

Alexander Embiricos：是的，我认为即便未来大部分代码都是 AI 写的，开发者依然会在 IDE 里花很多时间，只不过是在更高的抽象层次上工作。

让我解释一下，过去我们用打孔卡，然后是汇编，再到 C，现在有了 Python 和 JavaScript。我们一直在提升抽象层级。而现在发生的事情可以看作是再上一个台阶。

所以未来开发者依然会写代码或进行各种表达，但会在更高层级上操作，同时 AI 会帮他们加速，比如每一次键入，都会有智能辅助，这些依然很有价值。这就是交互式编程。

接下来是 Agent。我猜可能以后还会出现一种叫“交互式 Agent”的新形态（名字还没定）。我们以后可以深入聊聊。

总之，Agent 就是另一部分。在我看来，随着时间推移，大部分代码都会由 Agent 生成，而且其中大多数代码不会是由人类逐条提示出来的。

主持人：就像是由自动化的流水线流程驱动的一样。

Alexander Embiricos：对，因为要用户先写个提示，然后等上十分钟，这过程挺糟糕的。

主持人：对，中间用户可能只能去做俯卧撑或者别的事。

Alexander Embiricos：没错，比如我们的平均 Rollout（发布/运行）时间大概 3 分钟，大一点的代码库可能要接近 8 分钟，这个过程会更久一些。所以在这期间用户得不断切换任务，这体验其实不太好。

不过 Codex 的高阶用户已经建立了很厉害的工作流，能在不同任务之间切换。

我们可以聊聊大家是怎么用的。但在我看来，现在这种方式还不算理想。理想情况下，就像用户雇了个队友，只要告诉他任务是什么，给他权限和工具，他就能自动接手，然后在完成时告诉用户。

这样用户自己就不会感受到中间的延迟。回到我们之前讨论的什么时候合并 PR 这个问题，我更希望看到的场景是：Agent 自己接手任务，决定什么时候值得推送一个 PR，可能是为了触发 CI。

当用户收到通知时，它会说：我已经完成了，也许过程中还问过用户意见，现在 CI 全部通过了，要不要合并？这是我们要努力实现的方向。

Alexander Embiricos：对，我觉得是这样的。其实我们一直在谈代码生成，但问题是，代码生成变得越来越容易了，可代码审查有没有更容易呢？代码审查仍然是关键的一环。

现在我们正处在一个有点尴尬的阶段，生成的代码越来越多，但很多其实不会被合并。其他工具可能会在 PR 层面上表现出来，而在我们的工具里，大家可以看到内部统计：有多少 Rollout 最终生成了 PR。

结果就是审查和落地的代码量大幅增加。所以现在确实有些尴尬。不过我们正在积极思考，我对未来也很乐观。我认为我们能让这个过程对开发者更友好，毕竟没人喜欢做代码审查。

接着我还想问，现在的使用模式对人们来说是不是更有趣？我记得在你们第一次直播产品的时候，你的一个同事说过，他的工作变了，从主要写代码变成了主要审查 PR。

当时我听到后觉得，天哪，这就是我当工程师时最讨厌的工作。前不久我参加一家初创公司的外部会议，大家居然花了 45 分钟专门讨论怎么激励团队成员多审查 PR。

因为很多 PR 就搁在那没人处理，毕竟没人喜欢看别人写的代码，这不是个很有创造性的工作。

但我们先回到问题的起点：大家是怎么用它的？和你预想的比起来，最让你吃惊的地方是什么？尤其是站在一个产品负责人的角度看。

Alexander Embiricos：是的，这一点很有意思。在产品发布前，我们先在内部使用，逐渐摸索出使用方法。但当我们第一次把它交给外部用户时，他们并不会像我们一样用，觉得没什么用。

于是我们对产品的表达方式做了一些调整。等到正式发布后，大家的用法依然和我们不同，但他们确实觉得有价值。

这里的过程很值得回顾。在内部，因为我们长期和推理模型打交道，并训练它们，所以我们有一套对我们来说直观的提示方式。

OpenAI 的员工一般会写出不错的提示，我们会给模型大量信息，形成一个相对完整的单元，有点像一个封闭的任务。虽然可能没有那么标准化，但基本是这个思路。

主持人：一开始就把所有必要的上下文都给到，是吧。

Alexander Embiricos：对，然后它就开始工作了。通常情况下用户不会走多轮交互，比如它给用户一个结果，用户再回复。更可能的情况是用户直接重写提示，再跑一次，相当于是用最好的方式重新尝试。

不过这里有个类比我很喜欢，是另一家做 Agent 的公司说的，他们把它比作老虎机。我觉得这个比喻特别贴切，这其实就是我们的直觉。

如果用户把它当成老虎机来用，问题就是：用户什么时候去拉杆？我们第一次做小规模外部测试时，人们是把它当成本地 IDE 里的 Agent 来用的，但这其实不对。

如果用户在 IDE 上跑，那等于是把电脑借给它一段时间。用户就得认真考虑，这个任务成功的概率有多大。如果用户觉得有八成可能能成，那可以让它跑，但同时要有个心理预期，可能还需要过程中和它有些交互，一起迭代。

而在云端用 Agent 就不一样了，用户可以把所有东西都丢给它，不用太在意……

主持人：对，就是尽可能多地丢任务给它。

Alexander Embiricos：这就是一种反正资源充足的心态，把它当老虎机一样不断尝试。

主持人：反正用的是别人的算力。

Alexander Embiricos：没错，把任务都丢给它。而且用户不必把代码下载到本地，就能判断它的价值，并决定是否要合并。

用户甚至可以只用它来提问，比如让它帮用户探索四种不同的解决方案，用户再从中选择一个最合适的。甚至可以把它当作一个待办清单，留着之后再处理。

这是我们在 Alpha 阶段得到的重要经验：我们需要改变产品，让用户觉得并行化是使用它的核心，同时也要让用户更放心地放手，不用管它在后台具体是怎么跑的。

后来我们正式对外发布，就收到了很多预料之中的反馈。比如有人说容器没有网络访问，这太烦了，确实是。

主持人：还有环境变量很难配置。

Alexander Embiricos：对，环境确实难配。我们当然有很多想法，比如怎么安全地开启网络访问，但我们希望谨慎推进。至于环境配置这块，我们也有一些改进思路，但还没完全成型。

最后我们是缩减了范围，直接发布了一个很早期的研究预览版。所以这些反馈我们其实是预料到的。但有一件事真的让我很意外，那就是有个功能我们没想到大家会用。

事实上我们内部用的很少，以至于发布前很多 bug 都没被发现。这个功能就是多轮交互。我们当时告诉测试用户，其实只要重新写提示，多试几次就行，可能来回一两次。

但结果发现，很多人会走到第三轮，产品就彻底挂了，因为我们没有正确传递前几轮的上下文信息。

主持人：对，本质上就是在第三轮之后，缺少上下文的延续。

Alexander Embiricos：没错，这其实就是一个很普通的确定性 bug，不是模型奇怪的行为。纯粹是我们代码实现错了，因为没人真的走到那一步。

主持人：基本上没人跑到第四轮，对吧。

Alexander Embiricos：对我来说，这很有意思。用户对产品的直觉用法和我们预期的不一样。

我们原本以为他们会频繁重写提示，但他们其实是想先得到一个主要结果，然后一路和它交互，直到最后落地，而整个过程中从来不在自己电脑上跑。我们之前觉得这可能会发生，但没想到会比想象中更普遍。

主持人：你觉得这是不是因为在内部，OpenAI 的员工足够熟练，知道要在一开始就构建好上下文，让 Agent 第一轮尽可能多产出？而外部用户一旦用上云端 Agent，边际成本很低，所以他们不加思考就很快跑到第三轮、第四轮了？

Alexander Embiricos：有意思的是，我有时觉得我们反而没他们聪明，因为我们对模型了解太多了。

主持人：你们的期望反而比普通用户低？

Alexander Embiricos：对，因为我们会觉得模型在那种提示方式下就能很好工作，所以就满足了。但外部用户会更直接地说：“我就想这样用，为什么不行？”

对用户来说，这东西虽然不是 AGI，但他们觉得已经够聪明了，就会问：“你写了个很棒的 PR，我只想改一处，为什么不行？”我们已经修复了我刚才提到的 bug。

但接下来我们要认真思考，如何支持这种多轮交互，并让它更快。比如容器启动时间很长，这就是可以优化的地方。如果光是改一个变量名就要重新启动整个容器，这实在太让人崩溃。所以我们要在迭代循环上做很多改进。

会不会越来越像苹果生态那样，冷启动是容器里的大问题，用户体验很差。于是与其把容器外包给第三方厂商，还不如自己全都接管，提供一个端到端的全栈体验，所有依赖、中间件都在内部完成，才能给用户最流畅的体验？

还是说更像安卓生态，由 OpenAI 提供一个带有明确设计理念的 Agent 接口，但其他部分主要是由不同厂商的工具拼接协同？

Alexander Embiricos：这是个很好的问题。我觉得会两者兼有。这个答案可能有点让人失望。

主持人：那界限在哪呢？哪些要自己做，哪些要买？

Alexander Embiricos：我认为这其实取决于用户是谁，他们的使用场景是什么。比如普通用户，或者那些从零开始就用 Agent 的新创公司，他们的做法会很不一样。

他们可能会配置一堆 Agent，运行在一个高度可扩展的计算环境里，里面有所有需要的凭证，同时有合适的沙盒机制在正确的时机启用，网络出口也有监控。

我会把这种环境想象成一台笔记本电脑，虽然它其实不是，但对 Agent 来说就像是他们的工作电脑。里面不仅有终端，还有浏览器，还有各种 API 接口，在合适的时候还能自动注入所需的凭证。

大家可以把这想象成雇了一个新员工（甚至在找联合创始人之前就先雇），自己要做的就是给他准备好环境。他是个通用型的员工，能写代码。而 Codex 目前的状态，其实就是把提示转成消息和 diff，这还算不上是通用的。

现在 Codex 还做不到，比如我不能让它说：“把工程会议挪到 30 分钟以后，因为我有冲突。”但真正的软件工程师能做到这一点。他们能从各种信息源里获取内容，能自己判断，能直接上网。

我觉得我们会逐渐走向那一步。届时我们能搭建一个管理良好的系统，让用户更安全地使用更多功能，同时我们会推动产品设计，帮助用户最大化利用这些能力。

比如我们最近上线了 Best-of-N 功能，看起来很简单。但在我们看来，这只是个开端，它利用了 Codex 不受限于本地笔记本的优势。我们可以一次性生成四个版本来探索。

主持人：然后会有一个评估模型来挑选最好的结果？

Alexander Embiricos：目前评估者还是人类。路线图其实很明显，如果你想象一下我们在思考的方向。

主持人：就像一次跑出三种结果，再从里头选一个。

Alexander Embiricos：不过，绝大多数有价值的代码其实是由企业写的，他们会严格保护自己的知识产权和代码。

我们也在思考，怎么以一种他们接受的方式给这些企业提供价值。所以未来我们会有一个默认的工作方式，同时也会支持一些本地部署或自带算力的模式。

比如说，如果用户用我们的计算环境，我们会帮他管理好一切。如果他用自己的计算环境，那我们会尽量给他提供工具和框架来自动化，但用户也必须愿意自己管理这些环境。

对于 Agent 来说，那就意味着我们会告诉它应该具备哪些工具，应该怎么做沙盒隔离。

主持人：或者是自带权限管理系统之类的。

Alexander Embiricos：我觉得 Codex CLI 可能会发展成这样的东西。我们之前没怎么谈过 CLI，但在我看来，未来 CLI 可能会进化成一个工具，让你能在自己的环境里运行 Agent 循环。如果用户想这么做，我们会帮他。

主持人：CLI？我觉得我们可以聊聊 CLI 和界面的区别。Codex 在这两方面分别是什么？

Alexander Embiricos：我希望它最终能像 GitHub 一样，有网站、有 CLI、有移动应用，而且对用户来说，这些入口虽然不同，但用起来不会觉得混乱。但现在还比较混乱，因为它们是完全不同的体验。

我们有 Codex 集成在 ChatGPT 里，用户可以写提示，我们会在云端运行 Codex，返回答案。另外还有 Codex CLI，它是完全独立的，但思路相似。

用户可以在终端运行这个工具，通过 API 调用模型，Agent 会在用户的本地电脑上和用户一起工作。

现在我觉得可以这么理解：在 ChatGPT 里，用户是把任务委托给 Codex 在远程运行；在 CLI 里，用户则是在本地和 Codex 搭档。

主持人：那 CLI 什么时候会和云端的工作流整合在一起？

Alexander Embiricos：在工作流层面，我认为未来我们希望只有一个 Codex 的概念，区别只是用户想让它在哪里运行。有些时候，本地运行更方便，因为不需要配置环境，特别是第一次尝试时。

主持人：比如原型开发。

Alexander Embiricos：是的，或者用户甚至还不确定自己喜不喜欢 Codex，作为新用户可能就想先用 CLI 试试。等他用了一段时间后，发现想要并行化等更强大的功能，那就会切换到云端环境。

但即使这样，用户依然应该能在 CLI 里和它交互，只是它实际跑在云端，更强大了。所以我们希望把这两者统一起来。不过目前还处在一个临时状态，它们还是完全分开的。

两年前，很多人努力让最早一代的图像模型，比如对抗网络，以及后来比较成熟的 Stable Diffusion，产出真正有用且连贯的图像。当时还做不到。

它们能生成很有艺术感的效果图，适合艺术探索，但不太实用，因为缺少平面设计那种结构上的连贯性。

再到早期的扩散模型时代，比如 DALL·E 和 Midjourney 的早期版本，连贯性有所提升。

很多产品人开始用一个技巧，Midjourney 的 David（创始人）是最早这么做的人之一：在 Discord 里一次给出四张而不是一张。背后的洞见就是把它当作老虎机。

这是一个随机过程，我们很难预知用户最喜欢哪一张，尤其在艺术和图像这种高度主观的领域。

人的偏好非常主观，所以干脆一次给四张，让用户自己挑。随着时间推移，收集足够的人类偏好后，可以把分布往更美观、排版更好等方向微调。

即便如此，到现在为止，图像模型最好的交互方式仍然是给出四张甚至更多，然后让用户在 N 个里选最好的。

长期以来大家认为，这种做法适用于那些对可验证性或准确性要求不高的创作领域，比如图像、视频、音乐、音频。令人意外的是，你们把同样的思路用在了一个高度可验证的领域：编程。

归根到底，看起来即使推理能力在提升，模型采样里仍然有足够的随机性，所以用从 N 个里选最优的方式是有意义的。

也因此有人批评推理模型：基于可验证回报的强化学习并不会让模型产生全新的能力，它只是更善于把模型里原本就有的能力挖掘出来，更擅长做采样。你觉得这只是一个过渡期吗？

也就是说，现在用 Best of N 确实更能从现有模型里抽到对的答案，但还没引入新能力。而在接下来的一年，通过在大量 Codex 使用数据上做可验证的强化学习，真的会迭代出新的能力。你在这个问题上的看法更偏向哪一边？

Alexander Embiricos：我觉得现在有个还没解决的问题，它既是研究问题，也是产品问题，就是：我们该如何引导那些独立运作的 Agent？你刚才提到 Best of N，也就是让模型多试几次，增加采样正确的机会。

这可能是一部分答案。但我们在做 Codex 的过程中还学到一点：人类自己其实也常常不知道自己想要什么。比如我让它修一个 bug，可能会有四种合理的修法，每种在架构上带来的影响都不一样。

而我自己还没把这些可能性都探索过，这正是我把任务交给 Agent 的原因。

我希望先看到有哪些方案，然后再来选择。也许我会选模型认为最好的那个，但看到其他方案能让我更清楚它们的取舍，最后对自己选的方案更有信心。

修 bug 是一种结果很容易验证的任务。但如果我让模型写一个小游戏，比如井字棋，我自己也未必清楚想要哪种风格，因为不同的步骤有不同实现方式。

这有点像你说的图像生成，生成四张图摆在一起，让人挑。我想象在前端开发里，也完全可以有类似的界面：模型写好代码，我们在环境里跑一遍，拿到四张不同的截图，然后从里面挑最喜欢的那个。

主持人：几周前我们播客请了传奇音乐制作人 Rick Rubin。他最近用 Claude Code 出了一本关于 Vibe Coding 的新书。

我们问他，用 AI 写代码和做音乐创作有什么不同？他说，其实没区别，就像进录音棚一样。

他举了个例子，说当年和 Johnny Cash 一起进录音室时，Johnny 就随手拿起吉他开始即兴演奏。一首好歌的创作过程，常常就是拿起工具，比如吉他，随意做四种完全不同的尝试，然后由制作人这样的伙伴来判断，如果这个不行，那就换个方向。

这种不断的 Best of N 过程，最后往往能产出最好的作品。而最终歌曲的质量，往往取决于用户在这棵 Best of N 分叉树上每个环节做出的审美选择。

听你这么说让我感觉有点希望。比如你们发布 Codex 时，在 Hacker News 的讨论里，有人担心这是不是意味着编程会变得没意思了？因为有趣的部分都交给 Agent 做了，人类只剩下坐在那里审查 PR。

但你刚才说，其实在工作流里，有些环节能几乎完全把繁琐的工程活交给 Agent，而人类可以把精力放在审美探索上。比如前端用户体验设计，或者设计一个优秀的数据库 Schema。

我印象最深的是和基础架构工程师一起设计 Schema 的时候，先写一个方案，跑出一堆示例代码，然后发现不对劲，但这个过程带来的洞见能让我尝试另一个方案。这种探索往往是最有趣的。

那么未来是不是会变成这样？这是我们能看到的好的一面？还是说，我们最终会走向这样一个世界：人类只负责审核 PR，而软件开发里所有有创造性的部分都不复存在？

Alexander Embiricos：完全同意。我个人观点是，短期内编程可能会更痛苦一些，因为还需要处理环境配置之类的事情。

主持人：对吧，这就像成长的阵痛期？

Alexander Embiricos：是的，这就是一个阵痛期。说实话，现在用户可能还写不了多少代码本身，但我觉得我们很快就会迎来一个更令人兴奋的阶段。

因为环境配置这类事情，Agent 其实也能大幅帮助我们。等到那时候，交互模型也会更加成熟。

人类做决定的方式，会更像和一个聪明又高效的同事对话。而且这些决定可能不是基于读原始代码，至少在前端领域，用户可能是通过选择截图、在预览里点击，来判断结果。

在后端，用户可能就是看测试跑出来的结果，再决定要不要采纳。

还有一点挺有意思的。假设我告诉你几个主要用途：开发新功能、提问、规划、调试、修 bug。你猜人们最常用 Codex 来干哪一个？

主持人：我猜大家最想用它来调试。但现在可能还不多。因为我自己的直觉是，Agent 往往缺少足够的上下文来修一些常见问题，比如 React 模板代码出 bug。

调试本身没问题，但我发现自己更常用它来做那些定义清晰、范围明确的任务，比如写一个新的 UI 元素，或者做一次重构，这些都是定义明确，范围可控的基础单元任务。不过我很好奇，你们实际上看到的情况是什么？

Alexander Embiricos：我本来也认为，大家会主要用 Codex 来修 bug。因为 bug 往往是定义比较清晰的，用户能判断修复是否成功，有时还能直接把日志或监控数据贴给模型，让它解决。

我们最早的一些令人惊喜的时刻，就是把堆栈信息丢进去，它就能修好。

主持人：然后它就能直接搞定，对吧？

Alexander Embiricos：但实际上，大家用 Codex 最多的还是在开发新功能。这让我有点意外。因为这是最有趣的部分之一。但从一些用户的博客里也能看出来，他们确实玩得很开心，主要是因为速度非常快。

最糟糕的是有个想法，但在启动 IDE、编译、跑出第一版之前，就已经没了热情。这也是为什么黑客马拉松总是很神奇，把人聚在一起，逼着大家跨过原型的第一道坎。

从某种意义上说，Codex 或者更广泛的优质代码 Agent，把每天都变成了 Hackathon，因为它帮用户越过了环境配置和底层琐事这道坎，让用户能直接测试想法。

以前我在 Discord 时，公司有个传统，每年都会搞一个黑客周。整个公司一周都停下来，不光是工程团队，产品、市场、销售、运营，大家都随便 hack 想做的东西。很多后来进入生产的核心功能，都是从这种黑客项目里诞生的。

这其实提出一个问题：既然有产品和工程团队，为什么反而要靠这种特别的黑客周才能产出最棒的功能？原因就是当我们降低了新想法的原型成本，就能诞生一些不会通过常规 PRD 流程的东西。

而这正是很多用户现在用 Codex 的方式，大幅缩短从想法变成现实的时间，本质上就是缩短做出第一个原型的时间。

说到这儿，就绕不开一个话题。马克·安德森在 2011 和 2012 年写过著名的文章，说软件正在吞噬世界。

但当我看到你提到的那张图，AI 代理在 35 天内 GitHub PR 合并率达到 80%，总量达到 35 万，感觉现在是 AI 在吞噬软件工程。那么，学习软件工程还有意义吗？

如果你今天是斯坦福大一新生，或者刚高中毕业，对软件很感兴趣，那么去学计算机、拿 CS 学位还有意义吗？

Alexander Embiricos：我的看法有两点。

第一，现在依然是学 CS 的好时候。未来会有更多软件被创造出来，所以也需要更多软件工程师。第二，你必须学会在学习和工作中随时使用 AI。最好是在一所开放的大学，那些学校会拥抱 AI。

我听说有的学校规定，学生可以尽情用 AI，只要在作业里写清楚用了 AI 就行。如果我是学生，现在最担心的情况就是我学 CS，但学校完全禁止使用 AI，那我就会觉得自己落伍。

就好比我上大学，却只能写汇编，不能写 C 语言。放在当年，这是非常糟糕的情况。我认为，现在我们能做的事情比以前多太多了。我们的客户也在不断印证这一点。

很多用户告诉我们，他们以前根本懒得去做某件事，但现在会随手把想法丢进 Codex。我自己也经常这么做。很多时候结果出来后，我还是觉得没兴趣继续。

但有时候，Codex 要么一次就搞定，要么完成了 90%，让我有动力把最后 10% 补上并合并。于是那些本来永远不会发生的事情，现在发生了。

我最喜欢的一些例子来自公司内部的使用场景。比如有人在 Slack 上抱怨：要是有个工具能更方便地看日志就好了。平时大家都太忙，没人会去做。

但现在有人顺手用 Codex 写了一个超好用的解析器，立刻加快了整个团队的效率。我觉得类似的机会还有很多，软件完全可以更个性化，服务于小团队甚至个人，而这些需求过去都被忽视了。

所以我相信，随着软件开发加速，我们会看到更多这种小工具出现，而且维护成本会更低。现在我们已经能看到 AI Agent 被接入 GitHub、Slack，Linear 也有 Agent 功能。这会让构建和运行应用变得更高效。

同样，现在市面上还有一些产品，不是 Codex，但它们能帮大家写完整个应用，然后直接部署，全栈一体化。总之，我的结论是：软件会越来越容易开发、部署和维护。

主持人：我们现在还只是在这个变革的起点。到今天为止产品已经上线 35 天，你也有机会看到计划和现实的差距。

那这段时间里，你对什么的看法变化最大？接下来会怎样？Codex 的 V2 版本时会往哪里走？毕竟现在还只是个研究预览版，那未来最重要的改进是什么？产品的发展曲线会是什么样？

Alexander Embiricos：我觉得有一个信念变得更坚定了，还有一个旧的假设正在调整。更坚定的是：云端 Agent 自己在一台远程电脑上独立运行的这种形态，才是未来，而且非常强大。

我们现在在思考如何把它做好。所以我们会继续投入，让环境搭建更快，性能更好。

主持人：包括首次用户的上手体验？

Alexander Embiricos：对，包括首次用户上手。但也包括在运行后，整个过程都应该更快。速度一直是被低估的。

Alexander Embiricos：我觉得最容易改进的地方，还是那些传统的确定性问题。

主持人：比如说 DevOps 里的那类事情？

Alexander Embiricos：现在的情况是，每次用户执行一个任务，我们都会重新克隆一次仓库，即使只是个后续任务。然后我们每次都要从头跑一遍 Setup 脚本。

如果仓库很大、依赖很多，就会很慢。这种情况只要加缓存就能改进，对吧？这些我们都能修好。

而且我其实挺喜欢我们一开始就没做这些优化，直接发布了一个最小可用的版本。这样很好。除此之外，我刚才提到的 Best of N，其实背后就是在思考，怎么替用户更合理地利用计算资源。这让我很兴奋。

接下来要解决的就是如何让 Codex 更贴近开发者日常用的工具。比如 ChatGPT 里的界面虽然很实用，但它不是开发者写代码的地方。开发者写代码要么用终端，要么用 IDE。

同样地，用户要处理任务分拣时，就会去任务管理工具。所以我们要让 Codex 更贴近这些场景。最终的目标是，让 Agent 像一个队友一样，能看到团队里发生了什么，并主动帮用户分担。

主持人：那是不是说，Codex 将来就是 Slack 里的一个虚拟队友？我随时 @ 它互动？

Alexander Embiricos：我觉得 Codex 最终应该像一个无处不在的队友，出现在用户需要的工具里。至少要能嵌入用户常用的工具里。我们一开始会很克制，由用户来决定 Codex 什么时候介入。

随着时间推移，我们会探索让它更主动一些。但我们并不希望它每五分钟就来打扰用户一次。这可能会演化出新的交互模式，就像玩电子游戏时，当用户靠近一扇门会提示按 X 开门，靠近物体会提示按键拾取一样。

主持人：对，就是基于上下文的主动性。等用户有想法时，它再出现。

Alexander Embiricos：没错，这就接近交互式的 Agent 了。这是一个开放的领域，Agent 要能理解他们团队在做什么，并对团队工作区里的信息作出响应；同时它还要理解用户个人的任务。

就好像它既存在于用户所有的工具里，又像坐在用户电脑旁边，随时准备帮他们。

正因为如此，我们对一个信念更坚定了：只要给 Agent 一台属于它自己的电脑，它就能真正发挥作用。接下来我们要搞清楚的，就是如何把这套基础设施搭建好。

主持人：也就是要把整个生态搭建起来。

Alexander Embiricos：同时还要保证安全。另一个需要更新的认知是，用户到底怎么学会使用这些工具。现在有些地方还挺笨拙的。

比如环境配置我们已经谈过很多了，还有更新 Agent 的 SMD，现在的流程还很繁琐，用户得先把东西提交到代码库，Agent 才能获取上下文。我常常在想，怎样才能把这一步变得更简单。

主持人：换句话说，就是要减少用户在使用时需要思考和决策的负担，让他们更轻松地体验产品的效果。我明白了。

那 Codex 对研究层面有什么改变？在你看来，这是不是意味着，既然 Codex 是 o3 Pro 的后训练版本，已经能很好地调用工具，那么我们是不是应该不断给后训练模型投入更多算力，让它们在自主编码方面越来越强？

还是说，会存在一个边际效应的天花板，到了某个点之后，用户从工具使用优化里得到的收益就不大了？这对前沿研究的方向会有什么影响？

Alexander Embiricos：这是个很有意思的问题。我不确定自己能完全回答，但可以分享一点体会。做 o3 的优化版时，最棒的地方之一是我们能很快在研究和产品之间做出一系列混合决策。这对做出真正有用的东西非常关键。

比如，我们意识到 Agent 必须会写出高质量的 PR 描述，必须以特定方式写测试代码，必须能适应不同环境运行。当它跑测试时，不会只说自己跑过测试，而是会在日志里输出确定的结果，让用户可以亲自验证。

这些其实都是产品层面的想法，不是什么更高的模型智力，也不是更强的工具调用能力，而更像是一个软件工程师工作头几年的经验。

我们可以把 o3 看作一个非常聪明的大学毕业生，编程能力很强，但并不知道怎么当一个合格的软件工程师。

它知道一点点软件工程的知识，这没问题，但如果能把头几年工作中的经验灌输进去，Agent 对人类用户来说就会更有用。我认为没有理由不这样做。

主持人：把这些经验注入模型里。

Alexander Embiricos：没错，就是把这些经验注入模型。我觉得能用相对低的成本去尝试这些想法，验证哪些可行、哪些不可行，本身就是一件很有价值的事。

老实说，我不知道是否有必要对所有领域都做定制化后训练。但对于像编程这样重要的领域，我们愿意说：我们真的很在乎，就要尽全力做出最好的产品。

类似的，我们在 GPT-4.1 上也做过。我们收集了大量开发者反馈，专门和他们对话，为他们设计定制化的评测，深入理解模型擅长什么，他们希望模型在哪些方面更强。

然后我们发布了定制模型。最终目标是，把像 4.1 这样的改进融入到下一代的通用模型中。

主持人：也就是说要把这些整合进主模型。

Alexander Embiricos：没错，把所有改进都整合进去。

Alexander Embiricos：好吧，我个人对 AGI 的信念是非常强的，我半开玩笑半认真的看法是，如果我们把今天的模型放到一个合适的循环里……

主持人：我们基本上就已经到那儿了。

Alexander Embiricos：它是不是该拥有权利？这是我有时会想的问题。

主持人：它们是不是应该能自己关机，去放个假？

Alexander Embiricos：是啊，我有时候就会想到这些。

主持人：所以你支持为 o3 Pro 这类模型争取劳动权吗？

Alexander Embiricos：我支持去思考这个问题。现在还没到需要立刻回答的时候，虽然听上去有点疯狂，我觉得这是个值得时不时拿出来讨论的问题。

主持人：那更具体点，离模型能完全递归式地自我进化还有多远？

Alexander Embiricos：好吧，那回到你的问题。做 Codex 让我更清楚地看到，Agent 完全可以无处不在地融入我们的生活，并且非常有用。

当然我们还需要大量模型上的改进，但我也发现，真正落地时其实有很多常规的产品工作要做。只要把这些基础搭好，模型自然会变得越来越有用。所以我认为，到 2027 年，Agent 一定会在职场里无处不在。

在个人生活中，可能会慢一些。因为相比职场，个人生活里不会有那么密集的触发信号，不会有那么多需要持续响应的任务。

这一点很重要。比如 ChatGPT，现在就是一个输入框。大多数人，包括我自己，可能只用到它 1% 的能力，因为我们根本没意识到它还能那样用，或者觉得用不到。

主持人：对吧？这种使用方式本身就不够好。

Alexander Embiricos：是的，这就像是我雇了一个队友，但只有在我明确布置任务时他才会工作，那显然没有充分发挥价值。真正优秀的队友之所以好用，是因为我只需要告诉他职责是什么，他就会主动开始响应和行动。

主持人：也就是那种主动自驱型的人。

Alexander Embiricos：我觉得这正是 Agent 能发挥价值的关键突破点。因为我可以把它接入各种信息流，比如团队的沟通工具。个人生活里可能会慢一些，但我们拭目以待。

Alexander Embiricos：这是个很难的问题。我每次回答都会改口，所以这次也算有点逃避吧（笑）。不过我也想听听你的看法。我的想法是，会有一些团队，他们 90% 的 PR 都是 Agent 写的。但我不知道这种情况能多快扩散开来。

这其实是 AI 的普遍现象：我们这些人要么说是在泡沫中，要么说是在前沿，都会特别快地去尝试新东西。但要真正被更广泛吸收和扩散，还需要时间。不过在最前沿的团队里，我觉得能达到 90%。

主持人：没错，我觉得你说得对。人们常把编程经济视为一个整体，但实际上里面存在着不同的子经济体。至少有两大类。

第一类就是所谓的数字原生公司，这些科技公司通常诞生在互联网之后那段时间，创始人和团队大多数人天生就懂得现代软件开发该怎么做。

在这些公司里，初始化代码库时的默认假设就是要用 Git 做版本管理，要有分支，要有代码评审流程，等等。这就是现代软件开发的常态。

另一类则完全不同，全球大部分关键代码其实都是用 Fortran、Cobol 写的，还运行在本地的大型 ETL 系统上，比如美国弗吉尼亚州或欧洲一些地方。

这些系统大多是在二战后或冷战期间搭建的，当时的默认假设是所有东西都必须高度封闭。

这些代码库往往支撑着国家的重要基础设施，比如铁路系统或空中交通管制系统。它们完全没有现代化，技术债务让这些系统持续老化。

但最让人兴奋的是，现在要迁移这些代码，所需的一次性成本已经大大降低。因为 Agent 能完成大量原本要交给系统集成商（比如埃森哲、德勤）得做十年的脏活累活。

这也是 DOGE（美国政府效率部）创立时的核心因素之一：美国政府里有大量这样的遗留代码。

这些 IT 基础设施太旧了，导致国家在推动现代化时被迫付出了高昂代价。如果我们能有足够多的 Fortran、Cobol 等相关训练数据，Agent 就能介入，迁移成本会显著下降。

理想情况下，我希望 Codex 这样的工具能帮助整个遗留代码完成现代化，把大家都升级到现代软件工程的体系里。

我观察到，这种事情往往更容易发生在那些能跨越遗留基础设施的国家，因为它们是从零开始搭建的。这就像民用基础设施，比如公路。

像新加坡这样的国家更现代化，因为它只有 60 年的历史，在上世纪 50 年代才独立。它们不需要像英国那样先修一大堆老路再去翻新，因为重构真的很痛苦，花的时间也更多。

如果能从一张白纸开始，现代化就会容易得多。所以我发现 IT 基础设施比较新的国家，更容易采用 Agent。

当然，遗留系统还是大量存在。大多数系统依然跑在本地，不算现代化，更别提用 TypeScript 了。不过，把 C++ 写的系统升级到 Python，要比从 Cobol 或 Fortran 升级到 Python 容易得多。

让我尤其兴奋的是，未来这些子经济体会逐渐融合，而推动这一变化的正是 Agent。

它们能接管所有底层脏活，不仅成本和时间只是传统咨询公司收费的一小部分，而且很多咨询公司实际上项目根本没能真正落地，最后烂尾。所以我对这一块非常看好。

这也是为什么我说 AI 会吞噬软件。在现代初创公司和数字经济里，软件发展非常迅速。但在很多领域，尤其是关键任务行业，当年只是因军事需求进行过一次性的软件升级，此后却再也没有真正实现过现代化。

这也是为什么我认为你刚才提到的安全和网络安全问题很重要。因为真正可能阻碍大规模采用的，就是某一次严重事故，会彻底改变企业的风险评估。

Alexander Embiricos：我其实有个问题挺好奇的。我们跟很多大型公司交流时发现，他们的使用场景很不一样，不是像大多数用户那样主要用来做新功能，而是做重构、大规模重构或迁移。

你刚才提到的一些公司或政府系统，当年因为军事原因做过一次升级，但之后就再也没动过。

我想知道，现在他们是不是有某种特别的原因突然想升级？还是说，其实并没有什么外部驱动因素，所以即使更容易了，也依然缺乏动力？

主持人：当然，地缘政治确实推动了一些政府加速采用。比如在欧洲，乌克兰危机让很多政府突然意识到，他们的空中交通管制系统，尤其是在无人机作战的时代，居然还要在出 bug 时打电话叫 20 年前的承包商来现场修复？这太疯狂了。

比如欧洲六个月前刚通过了一项 8000 亿美元的国防预算。现在最迫切的升级，正发生在遗留代码失效与战场需求交叉的地方，比如无人机作战相关的代码库，需要和空管系统、无人机规划、地图系统对接。

这些代码库正在被优先改造。而在世界其他地方，更多则是出于一种现代化的愿望。

再比如阿联酋或沙特。我们之前提到过，阿联酋正在全境推广 ChatGPT。我觉得这更多是自上而下的指令，要求全面拥抱即将到来的 AI 时代。

总体来说，一个国家领导人越相信 AGI，采用速度就越快，这不仅体现在 ChatGPT 这样的工具上，也体现在代码生成上，即便背后没有军事驱动。而在欧洲，显然是地缘政治在推动这一切加速。

你我以前也聊过，这类场景通常需要不同的代码使用方式。它们大多是本地部署，需要和云系统做隔离，这与现代软件工程的工作流完全不一样。

所以我觉得 Codex 家族未来可能会出现分化。一方面是面向军事和关键行业的自主编码 Agent，它们可能在架构上就要有很不一样的设计。而另一类，则是开发者希望把最新最好的版本直接发布到 GitHub 上。

我不认为这是巧合，上一次全球范围内 IT 基础设施大规模采用新技术，正是冷战时期。现在我们又处在一个相当动荡的时代，不管是欧洲还是中东，这都在推动各国政府加快行动。

美国在采用最新技术上一直态度积极，让其他政府看起来还在恐龙时代。而没有什么比一颗即将撞向地球的彗星、那种灭绝级的危机，更能迫使恐龙觉醒。所以这种加速正在发生。

Alexander Embiricos：是啊，我觉得这点很有意思。在开发 Codex 的过程中，我确实在想，该怎么在高安全需求的环境里使用 Agent？有些行业，还有很多大型公司，他们的安全要求极高。

所以我们的思路是，先全力构建 AGI，再把好处分享给所有人。因此我们的主要路线是由我们来托管，把环境完全封装好。

同时，我们也在并行思考另一条路线：比如说，用户今天可以用 Codex CLI，这算是相对隔离的方式，虽然它还是要调用模型。随着我们在 Codex 和 ChatGPT 中加入新能力，我们要确保哪怕在 CLI 环境下，用户也能用上这些能力。大概的节奏是，我们会先在完全封装的系统里实现，然后再往下放。

Alexander Embiricos：我觉得 ChatGPT 确实是一个非常了不起的产品。能在一家把 AI 分发给数以亿计用户的公司工作，本身就很酷。但我们对编码也同样是极其认真的，而且一直都是。

从最早支持 GitHub Copilot 的 Codex 产品开始，到现在的模型，一直如此。我想大家注意到的是，我们不仅一直专注于做强大的编码模型，现在也越来越专注于打造优秀的编码产品。

以前，我们只需要把强大的模型交给用户，他们可以在任何工具里用。但现在，尤其在构建 Agent 的过程中，我们发现其实还有很大价值，可以通过特定的产品形态让模型真正发挥作用。

形态本身会影响一切。所以我们现在投入大量精力，不仅要做更好的编码模型，还要做更好的编码产品，特别是聚焦在 Agent 方向，但也不止于此。

主持人：你之前自己创业。现在听到 OpenAI 从专注模型转向非常重视产品，对一些想在编码领域创业的人来说可能挺可怕的。

他们会担心自己做的东西会不会明年就被 OpenAI 的产品覆盖掉？如果你现在离开 OpenAI，重新创业，你会怎么考虑？你会做什么，又不会做什么？

Alexander Embiricos：如果我今天离开 OpenAI，我最会关注的市场变化之一肯定是 Agent。这没什么争议。

然后我会这样想：正如我们刚才聊的，Agent 的核心是一款很强的模型，这个我在创业公司里大概率不会自己去做。那我需要做的就是给模型配上合适的工具和环境，再明确它要擅长完成的任务，最后把结果交给客户。

而这三步，工具、环境和任务分配，其实高度依赖对客户的了解。这些不是 OpenAI 会为每个行业都去做的事。我们之所以在编码上投入巨大，是因为它对我们特别重要。但即便在编码领域，内部也还有很多具体的细分场景。

我具体说一下。拿环境来说，训练 Codex 的时候，最难的一点就是怎么给模型提供多样化的环境，不同的依赖配置，不同数量的依赖，甚至不同规模的单元测试。

比如我当年把公司卖给 OpenAI 时，我们的代码库里单元测试非常少，这其实很真实，很多初创公司都是这样。所以如果要针对某个特定功能去训练，OpenAI 是没法为每个场景都打造这么多环境的。

再说任务分配也很有意思。以 Codex 为例，我们凭直觉设计了好任务的定义，比如现在就是用户给一个 Prompt，它返回答案或者一个 diff，然后转成 PR。

这些边界是我们自己划定的，接着还要收集大量类似任务，甚至自己创造一些任务，让 Agent 去学、再去评估效果。

再举个例子，如果是一个特定行业，比如某个地区的会计行业，它可能会有国家提供的专用工具，也会有完全不同的知识体系和文档资源，工作方式也不一样。

我觉得这是个非常好的问题。如果我现在是创业者，我不敢说百分百确定自己会怎么做，但我会非常依赖对客户的深入理解，而不是一上来就想着做一个通用产品。

主持人：看来，行业里那些最贴近专业知识的环节才是最有价值的。而前端那些通用的 Agent 流程部分，基本上都可以交给 OpenAI 来做，对吧？

Alexander Embiricos：是的。另外一点是，我可能会把公司保持得非常小。不会走传统那种快速扩张的路线，而是尽可能多地利用 Agent，让公司保持小而灵活。这可能算是老生常谈的建议了。

主持人：但我想反驳一下。在很多行业，想要真正深入服务客户，往往需要人的介入。这可能是销售、方案工程，或者客户支持。

听起来，你是会让工程团队保持很小很精简，但如果某个行业需要更多人性化的服务，那你还是会扩张团队，对吗？

因为根据我的经验，要让 Agent 真正能在传统行业的大企业里跑起来，往往需要不少集成工作，至少在前期是这样。可能需要先派一个懂集成的人进去，把 Agent 跑通，然后再退出。客户那边就能像多了个队友一样继续用。

但在这个集成环节，可能确实需要人介入。理想情况下，随着时间推移，模型或产品会越来越好，能够自己融入客户环境。但有时因为监管或者其他原因，还是需要真人在场。

那你觉得，有没有一些行业是 OpenAI 明确不会碰的？虽然它们也可能和编码 Agent 交互，但并不在通往 AGI 的路径上。

Alexander Embiricos：首先你说的对，复杂的集成工作确实需要人来做，尤其是需要现场集成时，我完全同意。至于哪些行业 OpenAI 不会碰，这个问题不好回答。

因为我们做的是通用产品，ChatGPT 今天已经可以回答任何问题，所以谈不上有明确的边界，更多只是聚焦点不同。

目前 OpenAI 的重点是服务消费者，以及在编码上做到极致，当然还有其他方向。但我觉得这部分可能不适合在播客里展开细讲。这问题太难了，我也不知道，幸好我不是创业者。

尤其是做科技行业的家长，他们在过去二三十年里有一个基本共识，如果孩子聪明，并且愿意往技术领域发展，去学软件工程，就能获得一份不错的工作，在知识经济里过得既安全又体面。

但现在像 Codex 这样的编程 Agent 似乎正在把这个假设彻底打破。你会怎么建议你的朋友们，也就是这些家长，来帮助他们的孩子选择未来的职业？

Alexander Embiricos：我只能谨慎地回答，因为我自己没有孩子，但我确实想过这个问题。

其实我的看法是，世界一直都在变化，现在在变，以前也在变，只是现在变化的速度更快。关键要关注的是变化的速度，而不是某个具体的变化。

如果我现在有一个快高中毕业的孩子，我可能最想做的就是鼓励他们，无论选择什么，都要对自己做的事情感到兴奋，要保持极强的好奇心，并且不断学习。我当时学的是计算机科学，你呢？

主持人：我一开始学的是计算机科学，后来转去读生物信息学，因为我对那个方向更感兴趣。

Alexander Embiricos：是啊，然后你现在做投资，对吧？我最开始学的是机械工程，后来转到计算机科学，现在在 OpenAI 做 AI 产品。但我之前创业的公司并不是 AI 公司。所以事情一直都在不断变化。

我觉得最重要的是，要保持灵活、保持好奇，并且有一个能随着世界变化而不断扩展的基础。

如果我有个高中快毕业的孩子，我只会希望他们能把自己正在做的事情做到极致，而不太在乎具体是什么方向。确实，我个人更偏技术，那当然也不错，但其实这都不是必须的。

更重要的是要让他们明白，他们的人生很可能会经历很多次职业转变。

主持人：既然你已经看到了 Codex 的发展，也知道它未来的方向，那假设你是大学计算机系的主任，你现在会和 Codex 发布之前有哪些不同的做法？

比如说你肯定会允许学生用 AI 工具。但更大的问题是，从未来五年、十年甚至二十年的角度看，你觉得计算机科学教育应该如何调整，应该怎么教？

Alexander Embiricos：要怎么改呢？我这里只能谈谈个人观点。我觉得应该还是要保留一些课，就像当年在斯坦福，我们有一门课是专门写汇编的，我忘了课名，但那门课很酷。

主持人：你说的是 CS140 吧。

Alexander Embiricos：对，我想就是那门课。类似的，我觉得还是应该有一些课程，让学生用非常手工的方式去操作，这样他们能理解底层是怎么运作的，也能建立起信心，证明自己能行。

但整体上我会更倾向于把课程设计成项目驱动式的，让学生必须交付一个成果，不管是学到了什么，还是做出了什么。然后我会鼓励学生去使用各种 AI 工具，这样他们能学到真正的技能。

我现在脑子里有个想法，如果我能让他们在学习的过程中快速走完这一段历程，比如每个学期都用一套不同的工具，这样一来，他们在处理事情的方式上就能保持很强的思维灵活性。我觉得这会是未来工作的最佳模拟。你呢？

主持人：我每年都会在斯坦福教一门 CS143 的课程。今年我们在冬季学期开设，大约有 300 个学生。

往年课程安排是有期中考试和习题集，但今年我决定换一种方式，改成请一些 CTO、研究人员和 AI 领域的人来上课，给学生讲大规模构建 AI 产品时会遇到的基础设施问题。

然后我们有一个期末项目，每个学生都必须构建一个 Agent 并把它交付出来。他们可以使用任何编程工具，实际上我们还给了他们一些 Mistral 模型和 Black Forest 模型的使用额度。

Cursor 创始人也来上过课，介绍了 IDE，并说明为什么大家应该去用它。结果让人意外，期末项目的质量差异特别大，完全符合幂律分布的规律。

前四五个团队完全拥抱了 Cursor 和 AI 模型，用 AI 全流程辅助完成项目，他们做出来的软件已经接近生产级。如果我还在 Discord 负责平台工作，我完全会把其中四五个项目直接放到应用商店的首页。

我甚至把这些项目发给了 Discord 创始人，他们的反应是，这些东西完全可以上线。对于只花了一个学期就能做出来的成果来说，质量标准简直令人难以置信。

Alexander Embiricos：那你觉得为什么有些学生不愿意使用我们提供的这些工具呢？

主持人：当然，从期末项目本身很难判断原因。不过我每周都有 office hour，也跟不少学生聊过。很明显，决定他们是否成功的关键因素是心态。

就是看他们是不是有好奇心、是不是渴望在传统课本之外去学习。当然，有些学生的生活中确实有很多事情要应对。现在作为一名大学生本来就是一件压力很大的事，所以我对他们也非常理解。

确实，现在正处在一个你刚才描述的尴尬时期。今年毕业的一些大四学生，当他们入学的时候，所面对的经济环境和现在完全不一样。

当这些学生当初选择计算机专业时，他们的假设是，只要在课程中表现好，拿到 4.0 的 GPA（表示成绩优异），再加上一两段不错的实习，等到毕业找工作时，就能进入一家相当好的科技公司。但现在情况完全不是这样了。

要么是裁员，要么是零利率时代留下的影响，也可能是工程团队把初级职位都砍掉了。我真的很震惊，有那么多斯坦福计算机系的毕业生，到大四冬季学期还在找全职工作。

这显然会带来焦虑和压力，而这种压力也会蔓延，影响到他们在项目驱动课程里的专注力。很多学生来我的 office hour，本以为是要问代码问题，但实际上他们来问的是职业建议。

有些学生甚至来找我聊职业规划，这完全可以理解。但我确实觉得，现在正处在一个过渡期，对计算机专业的学生来说压力非常大。

我同意你的看法，他们越快上手并熟练使用这些工具，越早意识到自己能创造的东西已经有了极高的上限，就能越快、更顺利地适应新的经济环境。

因为在现代软件团队里，尤其是在 OpenAI，大家都期待他们能熟练掌握这些工具。对比 4、5 年前就很不一样了。当时我在斯坦福毕业时，居然一门课都没有要求会用 Git，这太荒唐了。

虽然我是在实习时学会的，但课程里根本没涉及。所以我觉得全国各地的计算机系都必须意识到这个现实，并作出改变，正如你刚才说的那样。

而我希望的是，学生们不要等着院长或教授来推动这些变化，他们完全可以自己去用 Codex，而且还是免费的。我印象里研究版几乎就是完全免费的。

Alexander Embiricos：是啊，现在确实需要一个 Plus 账号或者 Pro 账号。这个提醒很好，也许我们应该为学生做点什么。

主持人：比如说学生许可。

Alexander Embiricos：对啊。我顺便说一下，我们团队正在招聘 Codex 相关岗位。如果有人对 Codex 感兴趣，可以在推特上私信我 @embirico。

我们确实在招聘。虽然主要招资深岗位，但我们也决定想招几位应届毕业生。这一点挺有意思的。我看过不少应届生的简历，也深有同感。现在的确是一个毕业求职非常困难的时期。

不敢说这是建议，但在我看来，简历里最重要的就是能让人看出你真的动手做过什么。如果能放个项目链接让我点进去看看，哪怕只是个很酷的小网站，这都非常加分。

主持人：所以现在成绩的重要性已经小很多了。

Alexander Embiricos：对，我甚至都不会看成绩。其实你一提我才意识到，我到现在还没看过任何应届生的成绩单。虽然我们只招少量应届生，但对我来说最关键的信号是做过什么。

我需要能直接验证的东西，比如点开学生做的网站，或者看到一些数据，显示有多少人用过。面试的时候，我更关心的是：他们到底做了什么？是怎么思考、怎么解决问题的？这或许能给正在找工作的学生一些参考。

我也常常回想自己加入 OpenAI 的经历，真的很感激，也觉得能在这里工作特别幸运。回想当时我们在做创业公司 Multi，那并不是一家 AI 公司。

但后来 ChatGPT 出现了，我们开始密切关注 LLM 的发展。我记得当时心里很震撼，和联合创始人聊时甚至觉得，如果我们在接下来的几年里不快速跟上，可能真的会被淘汰。

所以我们当时做了一个非常明确的决定：要把公司和团队的重心迅速转向 AI。

换句话说，要是我只是随便去投简历，可能压根不会有机会加入 OpenAI。我觉得正是因为我们做出了一些有意思的产品，才让我们有机会被关注到，并和 OpenAI 展开对话。

所以如果要说一个最重要的经验，那就是一定要去动手做东西。

主持人：是的，现在就是动手创造的时候。