Codex、ChatGPT为何合体？Codex未来何去何从？OpenAI核心leader回应一切

2026年，要说哪个AI产品的增长势头最猛，Codex绝对排在第一梯队。

从今年1月到现在，这款产品的周活跃用户数翻了5倍还多，增长曲线相当陡峭。目前，它的周活跃用户规模已经达到了500万。更值得注意的是，知识工作者——也就是非开发者群体——采用Codex的速度，是开发者的3倍以上。

增长曲线出现这种爆发，有个关键的催化剂：2月份桌面版App的发布。桌面版提供了专属的、优化过的使用界面，大大降低了使用门槛，直接带动了Codex下载量和采用量的飙升。

但在这条陡峭曲线的背后，推动产品形态发生变化的，是一个相对不那么被公开讨论的关键角色——

。

作为直接负责Codex桌面端产品演进的人，他恰好站在两个快速重合的世界之间：一边是以“写代码”为核心的开发者工具链，另一边是正在迅速扩展到几乎所有知识工作场景的通用AI工作入口。从产品发布节奏，到用户行为变化，再到团队内部如何重新定义“设计”、“工程”和“产品”的边界，他看到的，往往比增长数据本身更接近这场变化的本质。

接下来的访谈内容，就是从他的视角出发，拆解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的未来将走向何方？

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给出的回答，是“

”（大本营）这个概念：这应该是一个很好的“主场”，一个可以让用户追踪自己在不同产品界面上、所有待办事项的地方。有些事情，用户可以完全在App内部完成；另一些事情，App则负责去调用、打开别的应用来完成——比如，App可以连接Excel，App内部也确实内置了一个电子表格编辑器，但对于要在OpenAI做几十亿美元规模融资、需要做复杂财务建模的人来说，这个内置编辑器可能还远远不够。所以App会直接和用户电脑桌面上的Microsoft Excel插件对话，等事情做完，用户可以直接把Excel关掉。

也就是说，这件事从来都不是“我们在屏幕上画一个方框，所有事情都必须发生在这个方框里”，而是——

。

为了说明这一点，Andrew讲了一个具体的故事。Codex App最初发布的时候，团队拍了一批宣传视频，剪辑这些视频的活儿落在了内部的摄影师身上。结果，摄影师全程用Codex剪完了这些视频——这是团队第一次真正意识到“天哪，大家居然在用这东西做这种事”的瞬间之一。

摄影师会想到用Codex剪视频，纯粹是出于好奇，就是想看看Codex到底能不能干这件事。Codex本身完全不是一个视频编辑器，界面里也没有任何剪辑相关的UI，但它能理解摄影师用的是Premiere Pro，并且能通过直接编辑Premiere Pro背后、支撑屏幕显示内容的工程文件，完成一部分剪辑操作——只是这样还不能覆盖所有需求。于是，Codex接下来做的事，是给自己写了一个可以装进Premiere Pro里的扩展插件，然后通过这个插件和Premiere Pro“对话”——“嘿，Premiere Pro扩展，能不能帮我把这个标记点改一下。”团队第一次看到这个过程真实发生的时候，都觉得这事儿太不可思议了。

由此，Andrew总结出了一个模型：这个世界上已经存在大量在各自领域里做到极致的专业工具，Codex——现在要加上ChatGPT——想要同时做两件事。

：团队不需要重新造一个更好的视频编辑器，而是让Codex和ChatGPT学会使用现成的工具——能和它交互、把任务交接给它，这通常是通过连接器、电脑操作能力，或者像Premiere Pro这个案例一样，通过扩展插件来实现。

第二件事，则是Dan Shipper提到过的那种设想：

，让Codex在里面替他们多做一些事情。这两种模式，几乎互为镜像，团队目前正在同时大力推进这两条线。