【Codex：2026年AI增长之星】

如果问2026年哪个AI产品的增长最令人瞩目，「Codex」肯定排在第一位。自今年1月份以来，该产品的周活跃用户增长了5倍以上，增长曲线很陡，目前周活跃用户规模已达500万。其中，知识工作者（非开发者）采用Codex的速度，是开发者群体的3倍以上。

【增长催化剂：桌面App发布】

这些陡峭的增长曲线有个重要的催化剂——2月份桌面App的发布。这个桌面版提供了专属、优化的使用界面，大幅降低了使用门槛，带来了Codex下载和采用量的爆发式增长。

【幕后推动者：Andrew Ambrosino】

在这条陡峭增长曲线背后，推动产品形态发生变化的，是Codex桌面应用团队负责人Andrew Ambrosino。他同时站在两个快速重叠的世界之间：一边是以「写代码」为核心的开发者工具链，另一边则是迅速扩张到几乎所有知识工作场景的通用AI工作入口。从产品发布节奏到用户行为变化，再到团队内部如何重新定义「设计」「工程」和「产品」的边界，他所看到的，往往比增长数据本身更接近这场变化的本质。

【访谈拆解：Codex的改变与未来】

接下来这段访谈，从他的视角出发，去拆解Codex改变了什么、为何与ChatGPT合并，以及它未来的迭代方向是怎样的。

【成本之变：实现变便宜，品味变贵】

几年前，整个产品开发的逻辑是实现很贵，所以在动手写代码之前，要做大量的事前去风险工作，目的是让设计更便宜。但现在这个假设彻底反转了，在OpenAI，给人们大量的token，每个人都有很好的想法，所以每个人都在做东西。结果是，一个需要做的功能，可能有90个不同的团队在同时探索90种不同的实现方式。这意味着实现不再是昂贵的部分，那什么变贵了呢？Andrew直言不讳：是品味，更具体地说，是策展的过程。当面对这90个不同的尝试时，需要有眼光去判断：哪些东西做得不错？这些应该如何折叠进其他功能里？这个东西应该怎么框架化？这个切换按钮应该有几个段位？这些决策本身，才是现在最贵、最需要思考的地方。

【品味内涵：不止外观】

「品味」这个词在硅谷被说烂了，但在Andrew这里，它有非常具体的含义。有个有趣的段子是，Linear的产品负责人曾说有人过度强调品味的美学部分，然后举Paul Graham为例——Paul Graham明显品味很好，但他穿的是工装裤。这说明品味远不止外观。Andrew把品味的内涵列举出来：有美学层面，但那只是一部分；有系统思维的层面，即这个东西如何融入整个系统；有方向感的层面，这是什么主题的一部分；有呈现方式的层面。当然还有一些细节的层面，比如这个交互动画是否与它想表达的语义意思相符——它是不是太快速了，不适合表达这个概念。但真正的核心品味问题是：如果我们能建造任何东西，那么我们想要什么？这是什么？我们如何到达那里？这些才是真正的品味问题。它不仅是关于选择做什么，也是关于如何展现信息、如何实现目标、使用什么介质。品味是这个新时代里，人类大脑仍然最有价值的地方。

【AI设计难题：为何至今做不好】

这是个有趣的悖论：Codex在写代码上已经非常强大，但当用它生成设计时，输出的质量往往平庸。很少能说「哇，它完全搞定了」。Andrew认为这背后有几层原因。首先是实际的原因，设计比软件更难评分，因为评价设计好坏的人类品味本身就是反馈机制的一部分，这让训练模型变得困难，不像代码，很难用客观标准来衡量。其次，从研究投入的角度看，实验室历来投入最多资源去提升那些能加速AI研究本身的能力。在编码模型早期，显然能写正确的代码会加速研究，但设计能力好不好，对AI研究的加速作用不那么直接。更深层的问题涉及设计工作本身的复杂性，设计中有一个文化层面——什么算「好设计」是由文化决定的。去年所有新网站都在复制Linear的设计，那是真的好设计，有品味。但如果一个模型每次都输出Linear的样子，那就不是进步，而是失败。设计需要新颖性，而软件工程恰恰相反，你几乎总是希望代码跟随已知的模式。最难解决的问题在于抽象层，当代码驱动视觉设计时，两者之间存在着深层的互动。比如，左上角的某个东西应该和下面某个地方在代码库中共享相同的抽象。这不仅仅是说模型需要成为更好的设计师，而是说模型需要理解这些更深的结构关系——如果公司明天进行品牌重塑，浅层的做法是逐个更新263个组件，但深层的理解应该是：这两个看起来不同的东西在语义上是相同的，它们都是列表，都有相同的样式，都传达相同的交互模式。这种抽象层的理解，目前对AI来说仍然遥不可及。

【产品时机：Codex为何不能提前发】

这是一个非常深刻的观察：产品的成功不仅取决于设计本身，还取决于模型能力的时机。Andrew非常确信，如果Codex应用在去年11月就推出，它会在市场上彻底失败。而如果在2月推出的同一个产品形状，却获得了巨大成功。唯一的变量是中间这几个月模型能力的进步。换句话说，产品的交互设计、用户界面、整个概念都没有变，但模型智能程度的提升，完全改变了结果。这揭示了一个深刻的真相：在AI时代，产品是否好用、是否有价值，不是由UI设计或交互设计单独决定的，而是由「模型在这个时刻能做什么」决定的。同一个想法，用旧的模型实现可能毫无用处，但用新的模型就可能妙趣横生。这也改变了产品规划的方式，Andrew在之前的公司看到过这个转变：不再是「我们计划全年做什么」，而是变成「我们相信模型在什么时间点能做什么，让我们列出所有感兴趣的东西，为它们全部做原型，然后决定哪些现在可以做，其他的先放着等待，等到模型有新的跨越时，再用升级后的模型尝试那些之前搁置的想法」。因为整个功能是否好用的前提，不是设计的形状，而是模型是否足够聪明。

【角色边界：工程师、设计师、PM的界限】

Lenny提到，看Andrew的履历，工程师、设计师、产品经理、创业者他都做过，现在管着整个桌面App，就问设计团队是不是也归他管。Andrew笑说「看哪一周」——汇报关系一直在变，但团队一直是紧密坐在一起、彼此嵌入地工作。Andrew说，外界已经在讨论「角色坍缩」、说以后不会再分角色了，他们团队还没到那一步，但角色之间的重叠确实比公司其他部门、甚至整个行业都更明显——一部分原因是Codex本来就是面向工程师的技术型产品，团队里的设计师能讲工程师的语言，产品经理也能写代码，比如另一位产品负责人Alexander就有计算机科学硕士学位，Andrew自己反而没有。他认为，现在更准确的说法是：一个人不再由「设计到哪结束、工程从哪开始」这样的边界定义，而是由他平均花时间在做什么来定义——这也跟团队的工作方式有关，因为整个App是靠内部「吃自己的狗粮」跑出来的，大家都想尽量在App里把事情做完，哪怕它暂时还不是做这件事最好的工具，这样它才能慢慢变成最好的工具。两人也顺带聊起「member of technical staff」这个头衔的由来，Andrew认为最早可能是施乐（Xerox）开始这么叫的，如今在研究驱动型公司里已经算一种传统。Lenny追问，这是不是意味着未来大家都会变成不分职能的「builder」，PM、设计、工程这些技能分类还会不会存在。Andrew的态度很明确：他并不认同彻底取消角色划分。他见过不少公司喊出「取消产品岗位，人人都是builder」，结果是产品这个专业积累多年的最佳实践、试错经验，就因为「我也能写代码」这种想法被当成没用的东西丢掉了。「这不是你的地盘」这种画地为牢式的边界感消失，他是欢迎的，但每个专业依然有自己的技能门槛——不是谁用用Excel，就能去财务部门顶班。他也提到，现在换角色确实比以前容易了，因为能力不再和「是否精通某个具体工具」死死绑定：他自己就曾长期觉得不该做工程师，因为不喜欢钻研汇编语言、死记TypeScript语法，而这种「精通某个工具才算干得好」的门槛正在瓦解。不过他也提醒，这个趋势目前被外界过度夸大了。

【前沿开发：当下最前沿的AI辅助开发方式】

Lenny把话题往回拉了一层：从纯人工写代码，到AI能写100%的代码，再到现在「写代码」变成了「引导AI」——评估一个人写了多少代码，几乎变成了「你纠正AI方向纠正了几次」。他问，现在最前沿的做法是不是「loop」（自主循环开发）？那些走在最前面的AI团队，现在具体是怎么运作的？Andrew提到，一个本质的问题是，「多少代码是AI写的」这个问题本身已经不重要了，因为按去年的标准，现在几乎100%的代码都是AI写的；真正该问的是，这些代码是「有监督」写出来的，还是「无监督」写出来的，这是完全不同的两件事。他说自己乐见这种评判标准不断被刷新，因为这恰恰说明产品在往前走。团队做过不少「自主开发软件」方向的探索，也包括不少「harness engineering」相关的尝试，比如设想让模型在夜里自己跑一遍，把代码库做一次「垃圾回收」式的清理。他也坦言，目前所有模型都有一个通病——倾向于让代码越改越复杂。他半开玩笑地说，如果哪家公司的研究团队正好在听，希望能把模型「删代码」的能力练得更好一些。这也是把开发完全交给自动驾驶时会遇到的现实问题，人和代码库两头都是如此：怎么教模型判断该做哪些功能、该忽略哪些、哪些该合并重新归类；怎么教模型搭建正确的抽象结构。这些能力都在变好，但他认为目前还做不到「设一个loop让它自己去改进产品，同时盯着Twitter、Slack、邮件」这种程度，不过团队一直在朝这个方向努力。Lenny追问，会不会有一天，团队干脆直接给AI设一个「赢」或者「给我赚一个亿」这样的终极目标就完事了。Andrew笑着表示自己不敢把话说死，不会轻易断言「永远不会」或者「一定会」。

【合并原因：为何非得把Codex和ChatGPT合并】

Codex最早是命令行工具，后来才做成独立App，最初定位很明确：一个「开发者工具」——不是IDE，能看代码，但不让编辑代码。App正式对外发布前，团队先在OpenAI内部做了一轮试用（1 - 2月）。工程和研究场景里反馈非常清晰、非常正面。但团队同时发现，市场、公关、财务、法务等几乎所有部门的人也在用这个App——尽管它对这些人并不友好，界面里全是代码和命令行权限申请，根本不是为他们设计的体验。团队一开始的应对，是把Codex的能力搬到别的产品界面里，比如ChatGPT桌面应用和Atlas浏览器，做成更通用的知识工作工具。但结果是没人愿意离开Codex App去用那些「专门」打造的App。这让团队意识到：开发者工具和通用知识工具之间的边界正在坍塌，Codex和ChatGPT更像是同一个能力的不同入口，而不是两类独立产品。团队的结论是：这套产品该做成一个足够通用、可扩展的底层，能同时承接财务、法务、科学等深度场景。真正的挑战只在于「怎么让它足够通用」——这也是团队对「Codex到底是开发者工具，还是干脆就是ChatGPT」这个问题的回答。主持人Lenny由此点出：Codex已经做得比ChatGPT App本身更好用、更好玩，用户都跑去用它了，所以合并是必然方向，能避免认知混乱。Andrew笑着回应说，有人把这个方向叫做「超级应用」（super app），他挺后悔当初有人说出这个词，因为从那以后，他每天都要被这个说法包围。Lenny追问：先不叫它「超级应用」，但核心思路是不是「用户到一个地方，就能把所有事情都做完」？还是说，这件事目前还没有定论？Andrew给出的回答，是「home base」（大本营）这个概念：这应该是一个很好的「主场」，一个可以让用户追踪自己在不同产品界面上、所有待办事项的地方。有些事情，用户可以完全在App内部完成；另一些事情，App则负责去调用、打开别的应用来完成——比如，App可以连接Excel，App内部确实也内置了一个电子表格编辑器，但对于要在OpenAI做几十亿美元规模融资、需要做复杂财务建模的人来说，这个内置编辑器可能还远远不够。所以App会直接和用户电脑桌面上的Microsoft Excel插件对话，等事情做完，用户可以直接把Excel关掉。也就是说，这件事从来都不是「我们在屏幕上画一个方框，所有事情都必须发生在这个方框里」，而是——这个东西应该成为用户的一个「家」：你在这里开始工作、结束工作、把工作自动化，需要用到什么工具，它就去调用什么工具。

【应用案例：Codex的神奇应用】

为了说明这一点，Andrew讲了一个具体的故事。Codex App最初发布的时候，团队拍了一批宣传视频，剪辑这些视频的活儿落在了内部的摄影师身上。结果，摄影师全程用Codex剪完了这些视频——这是团队第一次真正意识到「天哪，大家居然在用这东西做这种事」的瞬间之一。摄影师会想到用Codex剪视频，纯粹是出于好奇，就是想看看Codex到底能不能干这件事。Codex本身完全不是一个视频编辑器，界面里也没有任何剪辑相关的UI，但它能理解摄影师用的是Premiere Pro，并且能通过直接编辑Premiere Pro背后、支撑屏幕显示内容的工程文件，完成一部分剪辑操作——只是这样还不能覆盖所有需求。于是，Codex接下来做的事，是给自己写了一个可以装进Premiere Pro里的扩展插件，然后通过这个插件和Premiere Pro「对话」——「嘿，Premiere Pro扩展，能不能帮我把这个标记点改一下。」团队第一次看到这个过程真实发生的时候，都觉得这事儿太不可思议了。

【未来模式：Codex与ChatGPT的发展方向】

由此，Andrew总结出了一个模型：这个世界上已经存在大量在各自领域里做到极致的专业工具，Codex——现在要加上ChatGPT——想要同时做两件事。第一件事，是如何和用户已经在用的这些工具无缝协作：团队不需要重新造一个更好的视频编辑器，而是让Codex和ChatGPT学会使用现成的工具——能和它交互、把任务交接给它，这通常是通过connectors（连接器）、computer use（电脑操作能力），或者像Premiere Pro这个案例一样，通过扩展插件来实现。第二件事，则是Dan Shipper提到过的那种设想：用户手里已经有一堆可以点来点去使用的网页应用，但希望能把这些应用在Codex里直接打开，让Codex在里面替他们多做一些事情。这两种模式，几乎互为镜像，团队目前正在同时大力推进这两条线。