编程自动化的悖论：为何代码越多，需要的“建造者”反而越多？
Harry Stebbings：Alex，我对此真的太兴奋了。我之前在参加一个PE会议（私募股权会议），我满脑子想的都是：谢天谢地，接下来我要和Alex聊，因为这一期一定会非常棒。所以真的非常感谢你来参加，哥们。
Alexander Embiricos：非常兴奋能来这里，谢谢你。
Harry Stebbings：好，这个开场可能有点怪，但你先顺着来。你会理解我作为英国人的那些小别扭。我一直对人的动机非常着迷。你更多是被“害怕失败”所驱动，还是被“赢的刺激与兴奋”所驱动？
Alexander Embiricos：我是一个极端主义者。我绝对更多是被“赢”这个想法所驱动，而不是害怕失败。但我得向你承认一件事：在我加入OpenAI之前，我曾经在运营一家创业公司，而在那段时间里我经历过的一些最黑暗的时刻之一——而且创业过程中黑暗的时刻有很多——就是我意识到，我在最初的几个月里，其实一直在努力避免失败。
然后突然之间我意识到：天哪，这就是我为什么这么不开心的原因。这大概也是这家创业公司进展不顺的原因。于是当我们做了一个转变，基本上我需要时不时“拽住自己”，把自己重新切换回“追求赢”的状态。但真正比这更能驱动我的，是我真的非常热爱“创造东西”，而且是为人们创造东西。而且老兄，我对今年感到无比兴奋，因为很多现在还不存在的、非常了不起的东西，将会被创造出来，并交付给大量的人。
Harry Stebbings：那我直接切入正题。Elon说，编程会成为最早被大规模自动化的职业之一。从你的职位和你每天看到的情况来看，你同意吗？
Alexander Embiricos：我觉得，毫无疑问，我会同意：编程确实是llm非常擅长的最早领域之一。不过你知道，“编程被自动化”到底是什么意思呢？这是一个分量很重的说法，对吧？比如说，当我们不再手写汇编语言，而是转向更高层级的编程语言时，当这个变化发生的时候，我们会说“编程被自动化了吗”？其实并不会，对吧？我们只是能够写出多得多的代码，而结果反而是，对代码的需求大幅增加，需要的软件工程师也变得更多了。当然，过去工程师做的一部分工作确实被自动化了，就像——你知道“computer”这个词最早的来源吗？
Harry Stebbings：不知道，我……
Alexander Embiricos：我可能会把地点念错，但我记得是在Bletchley Park（英国二战时期的密码破译中心），当时有很多机器用来破译德国的Enigma（纳粹德国使用的加密机）。那时候还有人类，会去打孔卡（punch cards，把数据打在纸卡上的早期数据输入方式），然后把它们放进机器里，进行大量表格式的计算。
我可能把细节说得一团糟，但核心是：当时的工作中有非常强烈、非常繁重的人工部分。甚至连最早的电子表格软件，在某种程度上，都是基于这样一个想法：你有一整个办公室，桌子按网格排布，人们在做表格计算，然后把自己的纸张传给下一个人。所以，这些事情里的具体任务后来都被自动化了。
但每一次自动化发生之后，对“产出结果”的需求都会出现爆炸式增长。即便具体的任务形式发生了变化，你实际上仍然需要更多的人来做这类工作。
Harry Stebbings：所以你的意思是，五年后工程师会更多，而不是更少？
Alexander Embiricos：对，而且有时候我们会改变一个词本身的含义，对吧？比如现在，“computer”这个词指的是完全不同的东西，而现在我们有了“software engineer”这个称呼。所以我非常确信，我们会拥有更多的建造者。
有一件我现在观察到的很有意思的事情是：人才栈正在被压缩。现在你仍然需要软件工程师，你仍然需要设计师。我是PM，那你还需不需要PM呢？你当然可以拿这个开点玩笑。
我其实不觉得你一定需要PM。当然，也许你在说“工程师”的时候，脑海里想的是一种比过去更“全栈”的角色。哪怕只是回到几年前，当时前端工程师和后端工程师的分工要清晰得多。而现在，至少如果我看看Codex团队，这种情况已经少得多了，大家更偏向真正的全栈。所以我认为人才栈会被压缩，但我们仍然会有大量人在进行创造。
Harry Stebbings：那你为什么觉得在这个世界里我们不需要PM？你这话可把我胃口吊起来了。
Alexander Embiricos：这只是我开的一个玩笑。首先，我觉得非常难定义PM是什么，或者说产品经理到底是什么。我某种程度上认为，这个角色本身就是“被明确地定义为不被定义的”，你的目标就是去适应团队或业务当下所需要的一切。
而且你知道，很多时候，如果你有一群人，比如像我们现在这样，试图以最快的速度去构建产品，那么产品经理能做的事情，就是花时间后退几步，试着“看向拐角之外”，弄清楚接下来该做什么，和市场团队协作，走向市场，或者成为团队里最大的拉拉队长和质量把关者。
但我刚才描述的所有这些事情——也就是我现在所做的这些事——其实完全可以由一个非常强的工程负责人，或者一个对产品有深度思考的设计师来完成。所以我认为，产品经理这个角色通常是有用的，但在团队真正变得很大之前，你可能并不需要太多。
超越算力迷思：人类的“打字速度”才是AGI真正的瓶颈
Harry Stebbings：我过去几天真的把你“扒了个底朝天”，这是一场非常有意思的探险——深入读了你的文章、你的推文，还有你之前的访谈。你曾说过：人类的打字速度和验证工作，才是通向AGI的关键瓶颈，而不是模型算力或架构。
但你当时就停在那儿了，我当时就在想：帮我理解一下，为什么“人类打字速度和验证工作”会是关键瓶颈？你真正想表达的到底是什么？
Alexander Embiricos：当然可以。好，这个问题很有意思。我觉得瓶颈其实有很多个，但这个可能是最“标题党”的那个。如果你不介意，我稍微用一点苏格拉底式的方式来问。你觉得你今天一天大概会用AI多少次？
Harry Stebbings：每天30次以上。
Alexander Embiricos：好，明白。那你觉得——假设你完全不需要付出任何精力——AI每天可以帮你多少次？
Harry Stebbings：我是说，在所有事情上，我觉得它会24小时全天候地运行，覆盖每一件事。
Alexander Embiricos：完全正确。而且我现在从工程师那里听到一些说法——无论是在OpenAI内部还是外部——他们会跟我说：“我一直让Codex运行着，我从来不关电脑。如果在开会的时候它没有在跑，那我就是在浪费时间。”“我得确保Codex随时都有活在干。”这真的非常酷、非常令人兴奋，但这其实是很多工作，对吧？要去管理这些东西、管理这些agents，并确保它们一直在运转。
再回到你刚才说的“每天30次”这件事。当我们看Codex用户实际使用Codex的频率时，大概也是这种“几十次”的量级。但我认为AI本来应该每天帮我们成千上万次，当然前提是算力预算允许，而我们也会随着时间慢慢走到那一步。
但问题在于——至少以我自己为例——我就在做这件事，我也知道我应该在所有事情上用AI，但我就是太懒了，懒得打那么多prompt。我也不够有创造力，想不出AI所有可能帮到我的方式。于是我最后用AI的次数，其实和你差不多。
甚至我现在还停留在这样一个阶段：当我用AI做了一件很酷的事情，比如为这次和你的对话做准备，我还会有点为自己感到骄傲。
我会觉得：“哦，挺酷的，我又用了一种新的方式来用AI。”这对你我这样对这个话题非常感兴趣的人来说没问题。但我不认为，大多数人如果想从AGI中受益，就应该被期待去付出这么多努力来研究“如何使用这个工具”。
它对他们来说，应该是毫不费力的。所以我认为，我们真正想要到达的世界是：你在使用AI时，根本不需要琢磨该怎么prompt。一切都应该对你来说非常简单，你甚至不需要意识到“AI可以帮我”，它只是了解你、连接到你的上下文，然后恰到好处地主动帮上忙。
Harry Stebbings：这也是为什么我觉得Claude在“包装”这件事上做得很好。他们做了Claude for Legal、Claude for Excel，你可以直接把它嵌进去，然后生成一个DCF模型。我对模型本身不太感兴趣，但这确实比以前人们能做到的要好得多。那你觉得，你们的工作是不是就是把prompt和人类的操作“产品化”，从而消除这个瓶颈？
Alexander Embiricos：对，完全是。我认为我们的工作，就是确保模型本身具备极强的能力，然后最终走向一个高度产品化的世界。在那个世界里，你可能只有一个“魔法文本框”、或者一个语音输入，或者随便什么形式，甚至你只需要把AI加进一个群聊里，它就会开始帮忙。但我觉得，中间其实有一个非常有意思的过渡阶段，而且我认为，当下最大的价值其实就在这个阶段。
我解释一下我的意思。你当然可以尝试把AI的某一个具体能力，产品化给某一个具体市场——很多公司正在这么做。但问题是：到底什么会真正奏效，其实很难判断。正确的产品状态到底是什么？你之前播客里有一位嘉宾提到过一件我觉得很有意思的事情：他说，企业如果不配备FTEs（全职员工），就无法真正采用AI。
Harry Stebbings：对，那是Invisible AI的Patrick。
Alexander Embiricos：对。尽管我现在确实在招聘FDEs（前线部署工程师），而且如果你是FDE，请一定来申请我的岗位，但我其实完全不同意那个观点。我认为我们需要做的，是构建工具，让像你这样的人，可以像Fitzpatrick在播客里说的那样，使用FDE来自动化工作流。但这样一来，你就会受限于：你从自上而下的视角能想到什么，以及你通过FDE编制，能够实际搭建什么，对吧？
但对我来说，AI最令人兴奋的未来，是每个人都感觉自己像个“超人”。是被AI全面赋能的状态。而要做到这一点，我们需要的是面向个人用户的工具，让每个人都觉得自己对AI是“流利的”。
所以我认为，当下这个阶段最有意思的地方，正是在于：为那些有兴趣探索“如何使用AI”的人而构建工具。这也是为什么，我觉得当Claude Code第一次发布时，真正做对的一件事是：他们提供了一个极其容易使用、适用于任何上下文的工具，就直接在你的终端里。于是人们开始实验：到底可以在哪些地方用它。
当我们思考AI如何被用于“非编程工作”时，最重要的一件事，不是过度地把它限定成：“这是AI的能力，但只适用于金融”、“只适用于某一个特定工作流”，而是要构建一个更加开放式的工具，让人们可以在任何任务中，创造性地使用它。
Harry Stebbings：但这样一来，不就又把负担、努力和责任重新推回到用户身上了吗？这不正好回到了你所说的那个瓶颈———人类需要采取行动，而人类往往既缺乏定义任务的能力，也缺乏去做这件事的意愿？
Alexander Embiricos：是的，我同意。这正是为什么我认为它是瓶颈。基本上，在我脑海里，这里存在三个阶段。
Alexander Embiricos：首先，让agents在软件工程和编程领域真正跑得很好，因为llm（此处原文用语，指一类语言模型）恰好非常擅长这一点。接下来，我们会意识到：要让一个agent在更通用的场景中真正有用，“会用电脑”这件事极其重要。同时，我们也会意识到：所有的agents本质上都是编程型智能体，因为编程是agent使用计算机的最佳方式。
所以，让我们把同样这种极其灵活的理念，开放给任何一个对探索和折腾感到兴奋的人。我们已经开始看到人们在Codex app上这样做了。比如说，Codex app是为软件构建者打造的，但我们看到构建者们正在用它完成各种各样与编程无关的任务。
然后，最后一步，当我们看清楚什么是真正有效的，我们就去做你刚才提到的那种产品化。你会拥有一些高度具体的功能，开箱即用，立刻生效。而且我认为，我们会在接下来的一个月里，把整个“1、2、3”的路径直接速通。
Harry Stebbings：我对你刚才关于 FDS（原文用语，泛指部署到前线的技术角色）以及在企业内部实施的说法，有一个挑战。那就是：数据安全的敏感性、权限访问和授权配置真的难，而且我觉得，人们其实远没有我们想象中那么聪明、那么自信，尤其是在大型企业里。
我的意思是：我认为你确实需要一个FDE（前线部署工程师）进场，去为大量不同的横向解决方案做定制适配，才能真正跑起来。我说错了吗？
Alexander Embiricos：如果你的目标是从0到1一步到位，而且你有一个——我这里不是贬义——一个宏大的愿景，想要构建某种“终极工作流自动化系统”，那是的，你确实必须跨过所有这些安全门槛、合规门槛——而且这些门槛都是真实存在的，对吧？
你得去连接各种数据系统、各种权威数据系统。所以，是的，你需要NFD（此处原文用语，语境中指前线部署类工程角色）来完成这些事情。
但我看到的情况是：当我们完全自上而下地做这些事情时，往往会极大地低估和浪费AI的潜力，也无法真正帮助到这家公司。当然，你也许可以并行推进这些事。但如果你只是把AI直接交到真正做具体工作的那群人手里，他们就能开始建立起一个“AI能如何帮助我”的心智模型，并且同时开始把AI拉进自己的工作流里。
这里我打个比方。想象一下，你在做客户支持相关的工作，AI被引入你的岗位，并开始自动化你工作中相当有分量的一部分，但你从来没听说过ChatGPT，甚至你也不被允许使用它。在这种情况下，你对这个东西几乎没有任何直觉理解。
而在另一个世界里，你一边在工作中使用ChatGPT，一边看到自己的一部分工作正被自动化，你对这套系统的运作方式就会有强得多的直觉。我会认为，在这种情况下，你会感觉自己被极大地赋能，你会觉得这是一次加速，而且你在某种程度上，可以影响和引导这些自动化被构建的方向，而不是感觉这一切像某种完全“ex machina（机械降神，指突如其来、不可控的外力）”的东西，让人感到被剥夺了力量。
所以拉回到我们刚才的话题：我认为，这件事是有解法的，尽管你提到的数据控制问题确实存在。但归根结底，每一个工具、每一个功能、每一个工作流，都是为“人”服务的，而这些人，是某个组织里的员工。这些员工最终都是通过浏览器，或者通过本地文件系统来访问工具的，对吧？
所以说到底，一切最终都会收敛到某种界面，而一个运行在你本地计算机上的agent，是可以与这些界面交互的。我认为这一点其实非常不寻常。
比如在OpenAI，我们正在构建一个浏览器项目代号。你可能会好奇：为什么要做浏览器？原因有很多，但我认为其中一个关键原因是：通过构建浏览器，并且对其进行端到端的严格控制，我们可以为企业构建安全的智能体式浏览。这是一种访问方式，可以让agents去访问那些尚未由FDs构建完成的系统。
Harry Stebbings：我现在脑子里有太多问题想问你了，在我跑偏之前我想拉回来一点。你之前提到，有些工程师甚至不关电脑，因为他们不想在构建时损失任何一点生产力，尤其是在使用Codex的时候。你们和Cerebrals达成了合作，而Cerebrals显然是目前推理速度最快的提供方。我觉得这对双方来说都是一次巨大胜利。我直说吧：对于开发者来说，在使用Codex以及AI编程的未来中，“速度”到底有多重要？
Alexander Embiricos：呃，简单的答案是：它极其重要。
Harry Stebbings：那这会不会变成一种“推理垄断”？也就是说你们现在拥有这个能力，而竞争对手没有？
Alexander Embiricos：这只是我个人的看法，但我并不认为最终会走向那种垄断式的世界。我觉得竞争压力会非常大，这件事最终会有多种不同的解决方案。不过我可以说的是，关于这次合作，我们很快会有一些消息发布，我对此真的非常兴奋。这会非常棒。
即便如此，GPT5.3Codex这个模型本身，就已经比之前的模型高效得多。而我们收到的反馈是：人们现在真的感觉它在速度上已经非常有竞争力了。所以有很多事情是你可以做的。一方面是模型本身，另一方面是你如何去做inference（推理）。
我们最近就上线了一项改动：在API中，这些模型的服务速度提升了大约40%；而在Codex中，速度也提升了大约25%。所以我认为速度非常重要，而且我们正在从所有维度推进这件事：包括硬件层、inference方式，以及模型层。
Harry Stebbings：你之前提到过把AI交到用户手里。我们刚才也聊到了inference。我有一位很好的朋友，Jason Lemkin，来自zasta，他说：inference正在成为新的销售和市场。也就是说，你不再是为销售和市场团队付费，而是为inference付费，让用户可以快速上手、迅速看到价值，最终你甚至会看到销售和市场团队被移除。这有点像下一代的PLG（Product-Led Growth，产品驱动增长）。
Alexander Embiricos：我不知道，我对这个观点其实有点不确定。我认为，从根本上说，在这样一个任何人都能构建东西、而且构建门槛越来越低的世界里，真正困难的事情是什么？是与客户建立良好的关系，是理解他们真正需要什么。而这件事，和以往一样困难，甚至可能更难，因为市场里可供选择的东西实在是太多了。
其他依然困难的事情还包括：构建“正确的产品”，以及构建“高质量的产品”。但回到销售和市场这个话题，我并不认为它们会消失，因为就像我刚才说的，随着任何一个市场里的软件数量不断增加，这件事只会变得更难，而不是更容易。
告别IDE与结对编程：开启“任务委托”与Agent协作的新纪元
Harry Stebbings：我能不能问一下：你们现在内部的代码里，有多少是由Codex生成的？我记得之前在Claude for Work的讨论里，Boris说几乎是100%，或者接100%。那你们内部的coded-aperture（原文用语，指内部代码生产情况）大概是多少？
Alexander Embiricos：那我先说我自己，再说整个团队的情况。我会说，我认识的大多数人，基本上已经不再打开编辑器了。
而这是一次阶跃式的变化。它其实是逐渐发生的，但我认为，外部市场真正感知到这个变化的时间点，是GPT5.2Codex发布的时候。那一刻，模型突然在长时间运行、端到端处理任务、管理上下文以及遵循指令方面都变得好得多。于是我们看到了这个拐点，而这也正是我们构建这个app的部分原因。
所以，整体来看，在GPT5.2Codex之前，我们用来写代码的AI功能更多像是自动补全，或者你是在和模型做结对编程。在我看来，那时你仍然需要坐在电脑前、手放在键盘上，模型也许会出去做一点小活，但你仍然需要在场、主导整个过程。它只是帮你处理一些小事情。
而到了2023年12月GPT5.2Codex的时候，我们基本上切换到了另一种模式：“我会把这个任务完全委托出去。”不是马上让它写，而是：先和它一起制定一个plan，确认我们认可它将要执行的spec（规格说明），然后我就让它自己去“慢慢煮”。这是一种完全不同的工作方式。
而且这件事真的就在我们对话的当下还在变化。所以，我们上周发布这个Codex app的部分原因，就是我们想构建一种产品形态或用户体验，让“委托”这件事比“结对”更加自然、更加符合人体工学。也就是：你可以同时把任务委托给多个agents。
所以即便是在OpenAI内部，这件事也正在发生巨大的变化。我没法给你一个精确的百分比，但我会说：绝大多数代码都是由AI写的。而且现在，大多数人甚至都不会再打开IDEs（集成开发环境）。如果他们真的打开IDE，可能只是因为你想“掌控接口”，对吧？比如你会帮忙把两个模块之间的接口梳理清楚，然后让AI把剩下的部分补全。或者你想和AI一起协作制定一个计划，然后再让AI去填充实现。但代码本身，已经不再是由人类来写了。
Harry Stebbings：那在24个月后，IDE还会是技术栈的一部分吗？
Alexander Embiricos：好，那从形式定义上来说——集成开发环境，这个词本身就非常模糊，几乎任何东西都可以被称作 IDE，对吧？所以我觉得这个定义本身并没有太大意义。
如果你这么定义，那你甚至可以说Codex app也是一个IDE。但我个人并不这么看。在我看来，IDE是一个非常强大的编辑器。而我们在Codex app里刻意没有加入文本编辑功能，因为我们希望非常清楚地传达：你应该如何使用这个工具。它有大量用于管理多个agents、进行委托、审查变更的能力。它还有非常显眼的技能——这是一个开放标准，非常适合用来做非编程工作，比如调试任务、监控部署之类的事情。但它不提供文本编辑。
Harry Stebbings：如果我们假设，大部分代码都是由Codex生成的，那你们是如何做代码审查的？AI会负责内部的代码审查吗？
Alexander Embiricos：这里有几个层面。首先，你要做什么的spec（规格说明）或plan（计划），变得前所未有地重要。也就是说，要从架构层面思考：这段代码应该如何运作？
我们最近上线了一个非常显眼的plan mode，它和其他工具有点不一样：你会让agent先出去，提出它打算如何完成这件事。这是一个相当长的计划，然后它会问你：你是否同意它的执行方式？或者你是否想提供一些输入？
这非常类似于：如果你新招了一个工程师，他刚加入你的代码库，在真正开始干活之前，需要先向团队提交一份RFC（请求评审文档）。所以，尽管这并不算是传统意义上的code review，但我认为，对“计划”的审查正变得越来越重要，因为我们正在进入一个以“委托”为核心的agent协作阶段。这是一个被严重低估的点。
Alexander Embiricos：然后——真正的代码审查。我听到很多人，尤其是在开源世界里，都在抱怨一个问题：大量的AI slop（AI垃圾代码）。人们会直接往开源仓库里提PR（Pull Request），但这些PR很烂。提交的人可能根本没有测试过，甚至也没有审查过代码。我认为这是一个真实存在的问题。
因此，在Codex的常见实践中，就是让Codex审查它自己生成的PR或修改。而Codex在这方面真的非常强。我们明确地训练过模型，让它擅长做code review。这包括：让它擅长给出高信噪比的反馈，也就是说，它几乎不会给出误报的批评。这意味着，当它真的给出反馈时，你是可以高度信任的。
所以我们不仅鼓励团队内部和外部的人直接让Codex来review，你甚至还可以把它设置成自动审查。在OpenAI，几乎所有代码，只要你push到Git repo，都会被Codex自动审查。事实上，有一个挺有意思的现象：一些还没怎么用过Codex，或者很久没用的人，会用Codex去审查其他模型写的代码。结果他们往往会说：“靠，我可能真的应该直接用Codex来写代码。”
Harry Stebbings：你刚才说了一点很有意思：对于那些可能还没试过，或者正在回归使用的人来说，你是如何看待这个品类的留存的？我记得Tom Blomfield（YC合伙人）几个月前发过一条推，一直让我印象很深。他说了一件很奇怪的事：在不同提供方之间切换的成本其实非常低。无论是Cursor、Raw Code，还是Codex——老实说我已经记不清他当时具体说的是哪个了。那用户到底有多“粘”？你们又是如何思考留存的？
Alexander Embiricos：我们在Codex上采取了一种有点反直觉的做法：就是把它构建得非常开放。比如说，Codex的核心执行框架是开源的，而且我们一直在努力让切换成本变得更低。
举个例子：当我们去年首次发布Codex时，我们确立了一个约定，叫agents.md。这本质上是一个文件，你可以在里面给agent写指令。我们没有把它命名成Codex.md，因为我们希望它是所有agents都可以使用的通用标准。现在，几乎所有agent都在使用agents.md，除了Claude（这其实也挺酷的）。
就在上周，我们还推动把skills（技能）——也就是我们用来给agent提供指令和脚本的标准——放进一个中性命名的文件夹，叫agents，而不是codec之类的名字。结果，除了“老熟人”之外，几乎所有人都跟进了。我觉得这对开发者来说非常棒，他们拥有了更多选择，而我们也在努力让他们更容易尝试不同的东西。
当然，话说回来。这些编程任务——也就是你让agent写代码的场景——其实是非常“密封的”。我的意思是，如果用电视剧来类比，它更像是单集剧。你有一个开放的agent文件，任何agent都能读；你有skills，任何agent都能用；你让agent写代码，它生成一个patch，然后这个patch进Git。
所以在这个流程里，前后两端都非常中性、vendor-neutral，这使得在不同工具之间切换非常容易，但当agents开始做的事情不再只是写代码，而是更通用的工作——无论是为软件工程师，还是为任何builder，它们就必须开始和其他系统打交道。
比如，你的agent开始和错误监控系统对话，或者和Google Docs之类的系统交互。那我认为，这些agents就会变得非常“粘”。因为，一旦你决定把agent接入这些系统，这本身就是一个高粘性的决策。
如果你是一家企业，真正去信任一个agent，让它访问这些工具，同时确保它有可靠的安全护栏、sandbox（沙箱环境）和控制机制，我认为这是至关重要的。而且这件事，你不会想反复做很多次。所以我们在构建Codex的时候，就已经预见到这一点。因此我们采用了最保守的sandboxing（沙箱隔离）方案。Sandboxing本质上是一整套操作系统层面的控制，用于限制agent能做什么。
Harry Stebbings：但我是《Seven Powers》这本书的粉丝——这是一本非常棒的书，讲的是企业如何通过七种方式积累价值与可持续性。其中一个就是粘性和留存。如果我们现在站在同一阵营、一起做Codex，我们该如何创造真正的留存模式、行为和机制，确保用户会留在Codex，而不是在出现更好模型时转向Cursor，或者Claude Code？
Alexander Embiricos：是的，这点很有意思。一方面，当然，我们是在经营一家企业。但另一方面，我们的使命是确保将AGI的益处安全地交付给全人类。所以，关于Codex团队，有一件事对很多人来说其实是不太直觉的。
Harry Stebbings：你其实——我知道——你的工作就是让Codex成功。
Alexander Embiricos：我们的工作是“智能的分发”（distribution of intelligence），对吧？所以我们当然在构建Codex，而这对很多听众来说是非常反直觉的。但事情是这样的：我们投入了大量精力去训练这些模型，然后又把这些模型提供给我们的竞争对手使用。而从我们的视角来看……
Harry Stebbings：作为一名风险投资人，这件事对我来说真的太难理解了。你意识到这一点吗？
Alexander Embiricos：我完全意识到这一点。OpenAI是一个非常有趣、也非常不寻常的工作场所，但本质原因在于，我们是在打一场非常长期的战役。对我们来说，如果竞争对手变得更强，我们反而能从中学习，这实际上是对我们有帮助的。所以我们在非常用力地推动Codex的增长，因为——
Harry Stebbings：如果他们是封闭的、自己变强了，你是学不到东西的。
Alexander Embiricos：我并不这么认为。比如说，最近有一系列发布，甚至就在今天早上，我真的刚刚quote tweet了一条关于Warp的新发布（没有任何利益相关）。他们在“代理如何同时在云端和本地运行”这一点上的设计方式里，有很多很酷的想法。对我来说，这是非常有启发性的。我从各家公司身上看到这些东西。而这个领域最酷的一点就是：我们几乎不可避免地在一起得出相同的结论。
然后在Codex团队内部把这些东西真正做出来。我们确实有一些巨大的优势：我们有ChatGPT带来的巨大分发优势；我们有训练自有模型的能力优势；我们能让模型在我们自己的harness（模型运行与评测框架）里表现最好，同时也不断让harness适配新模型。而这些，没有任何其他人能提前接触到。所以我认为我们是在“为了赢而打”，我们有非常明显的一系列优势；但与此同时，我们也在打这场长期战：把模型服务给所有人，推动开放标准，让所有人都能使用我们正在推动的这些东西。
Harry Stebbings：我想问你一个问题：什么才算“赢”？我知道我在用风险投资的语言，而你们的视角更自由、更开放。但如果我一定要逼你回答——真正决定胜负的，是GTM（go-to-market，市场进入与销售执行）吗？毕竟，全球的大型企业都想和OpenAI合作，我在你们销售团队里有很多朋友，来自顶级品牌的inbound（主动咨询）非常惊人。
所以，是GTM？还是因为品牌与产品执行力？还是因为Codex本身就是一个他妈的好产品？还是计算力/推理速度上的真实优势？哪一个才是“定义性的胜利因素”？
Alexander Embiricos：好，如果从OpenAI的整体视角来说——当然，这已经远远超出我的职级了——我会说是算力优势（compute advantage）和拥有最好的模型。而为了实现这一点，我们必须构建能够产生收入的业务。
另外一件非常有意思的事情是：Codex团队是一个研究与产品高度融合的团队，而通过打造成功的产品，我们反过来对模型改进施加了巨大的压力，让模型进化得更快。这是从公司层面的视角。
如果回到产品层面，最重要的一件事就是：做出一个人们真正想用的好产品。就像我之前说的，我们非常希望先为“个人”构建产品，让人们对这些产品变得足够熟练，然后再把自动化拉进来。这听起来可能有点反直觉，但我认为它带来的影响力，会远远超过那种只从“企业工作流”视角出发的方式。这本质上是一个产品执行问题。
当你进入企业市场，GTM就非常重要了。我吃过的一个大亏是：如果你只是走进一家企业说——“嘿，我们在这儿，你们随便用吧。”那是行不通的。你需要大量的教育、配置支持，以及对整个团队的赋能。真正有效的方式更像是：去pitch，去见developer experience的负责人，理解他们希望团队如何运作，然后给他们工具，把这种运作方式扩散到整个组织。
Harry Stebbings：你刚刚提到了收入，这是衡量一家企业的一个指标。那如果你坐下来和BA（Brad或其他高管）说：“这是我们现在真正要优化的东西。”你的最核心指标是什么？
Alexander Embiricos：其实不是收入。最核心的指标是活跃用户数。
Harry Stebbings：你们怎么衡量活跃用户？
Alexander Embiricos：我们看的是周活跃用户。定义非常简单：这个人这一周有没有在产品里完成一次“交互”（turn），比如发出一个prompt。
Harry Stebbings：你觉得周活跃够频繁吗？如果这是在替代IDE（集成开发环境），daily active（日活）是不是更合理？
Alexander Embiricos：我觉得很快就会是日活更合理。我们现在用周活，更多是历史原因，一开始这样是合理的。但我同意这个批评。我们需要进入一个世界：对于任何一个任务，你的第一反应就是“让一个agent来帮我”。
就像Google Search一样：任何事情，我先打开搜索框；ChatGPT出现后：任何信息问题，我打开这个输入框；而我认为今年的下一阶段是：任何任务，不只是获取信息，而是“做事”，我都走向这个输入框，然后某些事情开始发生来帮我。
Harry Stebbings：你刚刚提到ChatGPT作为界面。我对此非常着迷，因为它对忙碌的人类来说似乎是一个极其高效的输入方式。但我和Andreessen的GP（普通合伙人）Akaya聊过，他说：不不不，这个东西是Sam和Elon为高效人群设计的，而地球上大多数人更想要基于浏览器的探索式交互UI。你认为ChatGPT会成为下一波AI与人类交互的长UI吗？
Alexander Embiricos：简短答案是：是的。但实际上这里有两个层面。如果你想象未来——比如一部科幻电影——AI会是什么样？我认为科幻作品往往是未来的一个很好预测器，而答案通常非常简单。它就是一个你可以随意交谈的“存在”，你想聊什么都行。
我不应该被迫切换到“这是我的编程AI”、“这是我的销售AI”。我只想对着一个东西说话，它就帮我。所以ChatGPT或语音将成为一切的支柱。你可以把它加进任何群聊，它能自己发现如何帮你。
但如果你是一个power user（高阶用户），你并不总是想通过“对话”来中介一切。就像你有一个执行助理，但你只能通过说话和TA工作——那会非常烦。所以在某个点上，你想直接看、直接改。因此，ChatGPT会和高度定制的功能型GUI（图形界面）一起存在。
比如我：我可能用ChatGPT来做播客准备；但当我真正看产品、看代码时，我会进入Codex app深度使用。而一个市场营销人员可能只用ChatGPT问问题，然后在一个专门的广告分析GUI里工作。
Harry Stebbings：我完全理解。我想问你另一个问题：你如何看待agent-to-agent（代理对代理）的交互体验？比如一个代理替我提交差旅报销，另一个代理在合规部门审批。
Alexander Embiricos：最快的回答是：对agent来说最好的接口，通常也是对人类最好的接口。比如测试输出：如果你把所有测试结果全部打印出来，人类很痛苦，AI也一样。只输出失败测试——对人更好，对agent也更好。所以agent-to-agent的交互点，大概率会非常像“人类在循环（human-in-the-loop）”的系统。
Harry Stebbings：有人让我一定要问你：coding数据是否已经被Anthropic拿走了？
Alexander Embiricos：就我们看到的情况而言，我们有足够的数据来构建非常好的coding模型。反而更有挑战的是知识工作数据——它们根本不存在于互联网上。你可能需要付钱让人模拟工作流程；或者收购已经倒闭但有大量内部数据的公司（比如Slack数据）。知识工作任务的数据，比coding难得多。
Harry Stebbings：你们会在数据供应商上花10倍的钱吗？
Alexander Embiricos：我们的核心问题永远是：怎么跑得最快？内部搭建这些能力非常耗时，而我们团队很小。所以目前，如果要做大规模数据活动，我们通常会借助这些公司。
Harry Stebbings：在消费者侧，你们会和Lovable、Replit这类工具竞争吗？
Alexander Embiricos：目前还没有直接竞争。但我们发现，越来越多技术门槛较低的人正在开始用Codex构建东西。很多是“hello world”级别。而现在Codex已经向免费ChatGPT用户开放了一部分能力。这会让很多人用Codex做原本会去用专门工具做的事情。
Harry Stebbings：你最想做、但现在做不了的事情是什么？
Alexander Embiricos：这是个有意思的问题。说实话，这几周对我们来说都非常好。我现在对发生的一切都非常兴奋。
Harry Stebbings：这真的很有意思。你刚才说最近这几周对我们来说非常好，我也强烈地感受到了这一点。团队内部是否也能感受到这种动量的风向变化——无论是在正向周期还是负向周期中？
Alexander Embiricos：当然，我们对这一点非常敏感。如果你回顾Codex的历史，去年我们发布的第一个东西，是一个让人极度兴奋的想法。大概就是：“嘿，我们要在云端给agent一个属于它自己的电脑。你可以拥有任意多个agent，让它们并行地为你处理任务。”这是一个非常棒的想法。”但老实说，它的效果并没有我们后来发布的产品那么好，它并不是最优解。
然后从8月开始，随着GPT-5的推出，我们开始在交互式编码上非常用力地推进——而这正是当前市场竞争最激烈的地方。我们可以说是一路狂奔。我记得公开指标大概是：自8月以来，我们增长了大约20倍，而在年底阶段，从12月到现在又翻了一倍。具体数字我可能记不太准确，当时竞争基本上是势均力敌、咬得很紧。但我们在上周感受到的转折是：我们第一次觉得，我们拥有了当前最智能的模型，而这一点被“免费Codex”牢牢确立了。
此前我们收到的反馈主要集中在：模型有点慢；用起来可能没那么有趣；在我工作的时候，它和我沟通得不够好。我们正面解决了这些反馈。而且这在对比一些竞争模型时依然成立——有的模型在我们发布前20分钟刚刚上线，号称是SOTA（当前最先进）。那种感觉就像汽水一样——只爽了20分钟。与此同时，我们一直也在收到大量关于用户体验质量的反馈。
在Codex中，我们最受欢迎的使用入口一直是IDE插件，而CLI（命令行界面）相对来说打磨得没那么好。但随着App的推出，市场反馈几乎是一边倒的：这是一个非常高质量的体验。它简单、直觉（原文如此）、易用，人们非常喜欢使用它，甚至我们最大的批评者，也被转化成了用户。
再加上我们投放了超级碗广告，然后又转向免费策略。所以回到你刚才的问题：“我最想做出哪些不同的改变？”第一点是：我其实很想重新回到云端。去年我们从以云端agent为核心的策略，转向更偏向交互式体验的方向，背后的逻辑非常简单。这和我之前跟你提到的FTEs（全职人力等价）有点类似。如果你在终端用户还没有真正熟练掌握工具、还无法轻松把它用起来之前，就过早推进完整的工作流自动化，那么就会出现一种脱节，最终只剩下一个不切实际的“管道梦”，只有极少数高阶用户才能真正用好。
但一旦你建立了一个基础：人们每天都在使用你的工具；他们会对它进行配置；而且每用一次，工具就变得更好；那么再进一步让它在云端独立运行，其实只是一个非常小的跃迁。所以我认为，现在是我们重新构建云端产品、并让它与本地产品高度紧密集成的时候了。事实上，它们已经在一定程度上是集成的。
第二件我想做得不一样的事，是开始更加认真地思考瓶颈问题。今天，代码生成本身几乎已经变得微不足道了。真正困难的是：代码评审；我们如何判断代码质量是否足够好？我们如何确认自己正在做“正确的事情”？这些瓶颈依然被严重低估，也严重缺乏投入。
我希望我们能走向这样一个世界：你可以信任一个agent，让它完整地负责一个微系统或内部工具，能够独立完成完整的迭代闭环，包括吸收来自用户的反馈，而不必每一步都经过人工审查。这是一个极其困难的问题——不仅是智能层面的挑战，也是安全与控制层面的挑战。
Harry Stebbings：那我们到底应该在benchmarks和evals（评测）上放多大的权重？
Alexander Embiricos：我觉得这个答案你可能会觉得有点烦：要放“一定的权重”，但不是全部。在我看来，benchmarks在衡量“智能水平”方面非常有用，尤其是在eval还没有被刷爆之前，当你看到这些基准测试出现实质性进展时，它们非常有价值。
但你必须把这一点和另一件事结合起来看：“使用这个模型的感觉如何？”而这一点，完全是感觉驱动的。无论是和内部同事交流，还是和模型的客户交流，我总是会感到惊讶——人们对模型的评价，在很大程度上是基于感觉的。
智能分发的终局：当AI成为像Slack一样的“工作重力中心”
Harry Stebbings：生活本身就是vibe驱动的。人们更愿意和自己喜欢的人一起工作。从投资的角度来看，我需要思考这个市场最终会走向怎样的终局状态。它会像Uber和Lyft那样，绝大多数市场集中在两家公司手中？还是会像AWS、Azure、Google Cloud那样，形成33/33/33的格局？
Alexander Embiricos：我认为最终可能会是更少的参与者，在长期捕获绝大部分价值。原因在于——也许这个观点有点“辣”，但我认为我们正处在一个暂时性的阶段。现在，agent在coding方面非常强；如果你回看去年，可能很多人以为agent也会在其他领域同样强，但那并没有发生。
所以从整个行业来看，我们目前只有coding agents拥有PMF（产品市场匹配）。此外还有一些非常狭窄的使用场景，比如客服。但我认为这很可能只是暂时的。从长期来看，我们会拥有那种几乎什么都能帮你做的agent。你只需要和一个超级助手对话；如果你在某个具体职能上需要深入操作，再进入对应的UI。
在那样的世界里，你并不希望公司里有12个agent，让员工自己去搞清楚该和谁对话。因为那样他们无法形成熟练度，而如果没有熟练度，他们也不会把自动化真正引入自己的工作。但如果你有这样一个“什么都能聊”的统一入口，新员工入职时只需要被告知：“你有任何需求，就去跟它聊。”那么人们就会形成肌肉记忆，它会成为工作的重力中心，自动化也会自然地被引入。
作为构建ChatGPT的团队，我们在交付这种未来形态上处在一个非常有利的位置，我打一个可能有点牵强的类比。我以前在Dropbox工作，那是在Slack还没有真正崛起之前。当时我们曾经思考过一个问题：人们到底应该在Dropbox的文档里评论，还是应该去Slack里讨论这些文档？
从理论上讲，在Dropbox里直接对视频的具体时间点、或文档的具体位置进行评论，是更高效的。但现实中我们看到的是：Slack成为了人与人交流的绝对重力中心。没有人真的想在文档里评论，我只想直接在Slack上跟你说。于是我们看到，即便效率更低，事情还是会被强烈地拉向Slack。
我认为agent也会发生类似的情况。如果有一个agent几乎什么都能用，它会形成巨大的吸引力。人们会讨论如何最好地使用它，团队之间会分享最佳实践，围绕它举办hackathon，最终你只会剩下少数几个这样的agent。
Harry Stebbings：你刚才提到，除了coding之外，agent的使用并没有真正大规模扩散，而客服可能是一个例外。我的问题是：假设我今天是一名投资人，我在寻找那些能够长期积累价值、并为客户提供卓越产品的公司。现在市场上有一种看法认为：大型SaaS公司的收入耐久性已经为零，SaaS已死，因为模型提供方——比如你们、Anthropic等——会“来抢我们的饭碗”。你会给我什么建议？
Alexander Embiricos：一切最终都是为人服务的，否则还有什么意义？即便是SaaS工具，本质上也是为人类构建的。所以对我来说，我会问两个问题：这家SaaS公司是否拥有与某个具体人的关系？或者，这家SaaS公司是否拥有一个极其重要的权威数据系统？
如果它拥有其中之一，我并不认为它会消失。如果两者兼有，那就更是如此。实际上，我认为人与人的交互关系，以及系统记录的掌控权，比以往任何时候都更加重要。相反，如果一家SaaS公司只是一个“胶水层”，但既不掌控人与人的关系，也不掌控系统记录，虽然我不是这方面的专家，但我会对这种公司更加担心。
Harry Stebbings：那如果我们以这个立场来看，比如Salesforce的服务业务现在下跌了20%、30%、40%。我认为这种反应被严重夸大了。当然，也确实有一些公司是理应如此的恕我直言，我认为Dropbox现在处境非常艰难。但像Monday.com这样的公司——对于绝大多数中小企业（SMBs）和消费者而言，而他们恰恰构成了其市场的大多数——他们能不能通过vibe coding自己做一个to-do list？可以。但这样做成本高效吗？并不高效。
等你把它定制、打磨到可用状态，说实话，一个待办事项列表本身也非常简单：新增任务、完成任务、查看历史任务、给新成员分配任务。这并不难。所以最终你还是会选择继续使用现有产品。因此我认为市场的反应被极度放大了，这是一种典型的非理性反应。但我确实认为——客服领域会受到冲击，我不想待在那个赛道里。
Alexander Embiricos：我觉得这可能会改变你应该投资什么样的创始人。可能在某个阶段，作为一个产品构建者，我也曾非常喜欢那种：只要能把产品做好，其它什么都可以暂时不管的创始人。比如他们是否有清晰的客户假设、go-to-market 策略或分发能力。因为当时，构建一个好产品本身就已经非常难了。
但我认为那是一个异常阶段。放到今天，构建一个好产品相对变得更容易了，因此你更应该回到：投资那些真正理解分发、并且对特定客户要解决什么问题有深刻领域认知的创始人。
Harry Stebbings：那如果你站在我团队的角度，作为投资人，你会如何思考那些既能长期积累价值、又不会被模型提供方威胁的投资方向？比如你们显然会进入医疗、会进入coding、会进入客服，那你们不会进入哪里？Claude Code又不会进入哪里？
Alexander Embiricos：我有点想直接说：我不知道。这对投资人来说是一个非常困难的时期。市场变化太快了，很难下结论。
Harry Stebbings：这确实是一个非常难以投资的时代。我的回答其实有两个方面：第一，我会寻找那些拥有物理基础设施的领域。我不认为你们会进入能源供应。第二，是FinTech和银行集成，那些极其复杂、棘手的金融产品。我不认为OpenAI会跑去东南亚和500家银行建立合作关系。
Alexander Embiricos：是的，我基本同意。归根结底还是那一点如果你进入的是一个高度复杂、需要深度客户关系和市场知识的领域，那依然非常有吸引力。
Harry Stebbings：英国的人才战争到底有多激烈？我看旧金山，然后我会跟公司说，其实在欧洲建团队反而更好，因为在这边几乎不可能招到人才，也不可能留住人才。我是错的吗？
Alexander Embiricos：我认为现在的人才争夺战极其激烈。你知道的，显然在OpenAI，我们有一个非常强大的品牌，因此我们确实能够吸引大量人才。但即便如此，我们依然要花费大量精力去“成交”那些我们真正感到兴奋的候选人。即使是我们，也完全不是那种“你想要谁就能免费得到谁”的状态。
Harry Stebbings：我可以问一下，你们给人才的股票入场价格，对最顶尖的人才来说现在还足够有吸引力吗？
Alexander Embiricos：目前还没有任何人跟我说过相反的情况。
Harry Stebbings：在你看来，寻找“完美匹配的人”与寻找“足够好的人”之间，你们更偏向哪一边？
Alexander Embiricos：我之前开玩笑说过PM（产品经理）某种程度上是可有可无的。其实那并不是真的。你仍然需要产品人才，但我确实认为，他们必须是“完美匹配”的那种人。如果你找了一个并不完全匹配的人，他们带来的伤害可能会大于帮助。所以这也意味着，相比我以前的角色，我们现在的筛选标准要严格得多。
Harry Stebbings：假设我是一个CS学生，好吗？我在Stanford，我在Imperial，我在Cambridge，或者我在ETH这种顶级院校。站在你现在所知道的一切角度，你会给我什么建议，来帮助我规划接下来五年的职业生涯？我希望在明年进入职场时，作为一名工程师，能在AI生态中变得有价值。
Alexander Embiricos：基本上，我会说：现在可能是成为工程师的最佳时代。你拥有极其强大的工具，可以非常快地变得“非常厉害”。你进入一个复杂代码库的速度也从未如此之快，因为你可以向AI询问大量关于代码库的问题，你还可以让它帮你规划修改方案，而这些事情在过去可能需要你花上好几天去研究。
所以第一点，我会说：你应该对未来保持非常乐观。但接下来的问题当然是：当你进入职场后，你的能力不是问题，真正的问题变成了：你如何拿到这份工作？
正因为现在“构建东西”变得前所未有地容易，真正变得稀缺的是：行动力、品味和质量。所以我会强烈建议你：去不断地构建东西；展示你的主动性；展示你在“做什么、为什么做”上的品味；并且去构建高质量的项目。然后，把这些东西分享出来。你知道的，我们会收到大量主动联系——不论是通过招聘页面，还是通过社交媒体。就我个人而言：当有人给我写信，附上了一些有意思的思考，以及一个有意思的项目链接，这比一份普通简历更能吸引我的注意。
Harry Stebbings：最后一个问题，在进入快问快答之前。你之前提到过Dropbox，Dropbox的校友群体真的非常惊人，能看到那么多优秀的人才从Dropbox走出来，真的很震撼。你从Dropbox学到的、对你现在在OpenAI的思考影响最大的一条经验是什么？
Alexander Embiricos：这个我甚至不用想。这其实就是我之前跟你说过的那一点。当你在为人、为终端用户构建工具时，你必须把这个工具视为一个“system of engagement（参与系统）”。如果人们不想用你的工具，如果它没有一种“这是完成某件事最轻松方式”的自然感觉，那人们就是不会用它。
我正是通过观察Slack如何彻底爆发式增长，学到了这一点。所以现在，当我们在构建agent时，我会一直问自己：如果我们把agent纯粹当成一个工作流自动化工具来做，那启动它永远都会像拔牙一样痛苦；你得请Accenture之类的咨询公司；他们需要投入大量全职人力；整个过程会非常艰难。
但如果你能构建一个人们真心喜欢使用的系统，哪怕一开始他们只用它来完成部分任务，随着时间推移，他们会越来越熟练，你也会逐步把它连接到更多工具上，最终，你就可以一层一层地引入自动化。当然，这些路径并不是相互排斥的。
Harry Stebbings：那你觉得，今天的Dropbox要如何重新点燃增长？
Alexander Embiricos：至少在我还在Dropbox的时候，我们最独特、最擅长的一点是：桌面软件。桌面软件很有意思，它从来没有真正消失过。但现在，它是真的“回来了”。如果你是在解决生产力和知识工作的问题，确实，到处都有system of record需要去连接，但最终，一切都发生在用户的电脑上——要么在浏览器里，要么在本地应用中。
所以我确实认为：agent在工作场景中带来生产力提升的最快路径，是首先直接进入用户的电脑。和他们已有的工具一起工作，而不需要先部署FTE去做复杂配置。然后，随着时间推移，再逐步接入各种系统。如果我是Dropbox，我会思考：我们如何利用自己在桌面软件上的独特领域能力，以及“覆盖在电脑之上的协作层”，来赋能生产力agent？这个方向有点宽泛，但我认为这是最合理的切入点。
Harry Stebbings：不，我非常喜欢这个回答，也真的很感激。最后一个问题，然后我们进入快问快答，我保证。我是被教育在一个“利润率极其重要”的世界里成长的。软件的高利润率，是它成为优秀投资品类的核心原因。但现在我们看到，尤其是在推理成本极高的玩家身上，利润结构发生了巨大变化。
我应该在多大程度上暂时忽略这一点，认为成本会下降、token成本会下降，最终只要用户规模和用户喜爱度上来了，利润自然会回来？还是说，不，利润率真的很重要，你就该一直盯着它？
Alexander Embiricos：我认为这两点同时成立。成本会大幅下降。同时，如果今年是agent被广泛部署、并开始真正接入工作系统的一年，那这也将是agent被连接到各种系统的一年。而这种连接一旦发生，就会非常“粘”。所以我把今年看作是一场竞赛。你需要赢下这场竞赛，在此过程中，短期牺牲一些利润率是可以接受的。
Harry Stebbings：快问快答。我说一句简短的陈述，你给我第一反应，可以吗？过去12个月里，你在哪个问题上改变了看法最多？
Alexander Embiricos：我加入OpenAI的时候——那已经不止12个月前了——我曾以为，一年之内我们就会整天开着电脑屏幕共享，然后和一个agent直接通过语音对话。这个判断完全错了。多模态模型，支持视频和音频的进展速度比我预期得慢。相反，我们看到的是：agent通过代码与电脑交互，反而先走通了路径。这对我来说，是一次彻底的认知重构：我们如何把AI的价值带给普通人，并不是主要通过视频和音频。
Harry Stebbings：你最尊敬的、但不太为人所知的competitor是谁？为什么？
Alexander Embiricos：我脑海中第一个浮现的是Amp。我觉得你说的是Amp，它来自Sourcegraph的那群人。他们的产品有着极佳的口碑，总是在“远超其体量”的情况下打出惊人表现。但我更敬佩的是：他们帮助推动了整个agent生态的标准化，包括agents.md、.agents/skills。
正如我之前说的，这让用户更容易管理他们正在尝试的多个agent。我们发布了agents.md，他们也发布了agent.md。事实上，这一切的起点只是Quinn发了一条推文，说：“嘿，你们买了agents.md这个域名吗？我们可以统一拼写，直接标准化。”这件事看似很小，却引发了一整套社区层面的标准化，我觉得这非常棒。
Harry Stebbings：你觉得大家对Anthropic广告的反应是正确的吗？
Alexander Embiricos：反应其实非常多样。我听到的那个——我认为是对的——是这样的，一家公司在描绘一个相当悲观的未来，而另一家公司——我们OpenAI——是在告诉人们：你可以去构建、去梦想。我觉得那种回应非常精彩。
Harry Stebbings：你在Codex期间，做过的最艰难的产品决策是什么？
Alexander Embiricos：我可以告诉你一个最痛苦的。有一段时间，Codex Cloud几乎是无限使用的。不是完全免费——你需要订阅ChatGPT——但一旦订阅，你就可以无限用。我们每天都知道：只要无限制状态持续得越久，未来想收回就会越痛苦。但当时我们太专注于在其他、更有PMF的方向竞争，就一直拖着这个决定。
当我们最终把无限使用收紧到一个更合理的限额时，用户的反弹非常大。虽然真正强烈不满的只是极少数用户，他们觉得一切都应该“永远免费”，但社交媒体的噪音会被无限放大，根本不会区分具体细节。我从中学到的教训是：你不能把“无限制”这个状态维持太久。
Harry Stebbings：数据定价、祖父条款定价真的太难了。今天我们在工程和产品上做了哪些事，你觉得五年后回头看会说：“天哪，我们当时怎么会这么干？”
Alexander Embiricos：为什么不是：手动编辑代码本身？另一个可能更“辣”的是：手动管理系统的部署和监控。我基本上认为，大公司可能需要很长时间才能转向新的方式，但很多初创公司可能会直接构建在一个全新的、完全由AI管理的技术栈之上。
需要澄清的是：这个栈现在还不存在。但它会是一个fully managed AI stack，具备非常强的、确定性的护栏，控制agent能做什么、如何部署到真实世界。
最终，你创办一家公司的方式可能会变成：先找一个agent，让它开始构建东西；然后不断加入更多agent；最终，你甚至可能把联合创始人拉进这个agent协作系统。于是，你的主要沟通工具，可能不再是Slack，而是agent通信工具。你也不再需要人肉维护那套痛苦的CI/deploy流程，而是让agent来完成这些事情。
Harry Stebbings：有点奇怪的问题，但我很好奇：agent的护栏是谁来提供的？是你们吗？还是会有第三方来告诉agent：“你不能访问人力资源”，“你不能访问市场部”？你如何看待护栏的提供者角色？
Alexander Embiricos：我认为最终两种都会存在。我们在agent护栏上投入了大量精力。比如，我们几乎是唯一一家认真做OS-level sandboxing（操作系统级沙箱）的公司，尤其是在coding agents上。Windows上甚至还不存在这种能力，是我们在构建，而且是开源的。
ChatGPT还支持connectors，比如连接Google Docs，我们也在agent能对这些系统做什么上，设置了非常严格的护栏。但我也认为：仅靠我们是不够的。未来一定会出现第三方，为非常具体、非常定制化的企业需求提供护栏。那大概会是下一个创业浪潮。
Harry Stebbings：最后一个问题。如果你看向未来10年，你最兴奋的是什么？
Alexander Embiricos：这件事很可能不需要等10年。当我加入公司时，我个人的使命感是：即便是一年半前的模型，其实就已经拥有大量“能力溢出”，只是我们没有构建出合适的产品形态。结果是：像我这样的人，比我奶奶获得的好处多得多。
我最兴奋的，是找到一种AI的“形态”，能真正帮助所有人——尤其是非技术人群，尤其是年长的人。一个非常具体的画面是：有一天，我们会把一个agent加进家庭WhatsApp群，它自然地开始对家庭有用，而不需要任何人额外学习或思考。当然，还有很多实现路径，但这是我能为我奶奶想到的、最直观的一种。
Harry Stebbings：兄弟，真的太感谢你了。感谢你包容我跳跃式的问题，也感谢你的精彩分享。
Alexander Embiricos：非常感谢你。老实说，我也感谢你包容我同样跳跃的回答。
盛达优配提示：文章来自网络，不代表本站观点。
