文章作者、来源：机器之心

如果你问 2026 年哪个 AI 产品的增长最令人瞩目，那「Codex」肯定是排在第一位的。

自今年 1 月份以来，该产品的周活跃用户增长了 5 倍以上，增长曲线很陡。目前，它的周活跃用户规模已经达到 500 万。其中，知识工作者（非开发者） 采用 Codex 的速度，是开发者群体的 3 倍以上。

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

而在这条陡峭增长曲线背后，推动产品形态发生变化的，是一个相对更少被公开讨论的角色 ——Codex 桌面应用团队负责人 Andrew Ambrosino。

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

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

视频链接：https://www.youtube.com/watch?v=P3KDebPTUrw

我们对访谈的部分内容进行了整理，详细内容请参考原视频。

实现变便宜了，那什么变贵了？

几年前，整个产品开发的逻辑是这样的：实现很贵。所以在动手写代码之前，你要做大量的事前去风险工作 —— 写文档、做研究、做原型，目的是让设计更便宜。正是因为实现本身成本高昂，你必须在前期就把一切梳理清楚。

但现在这个假设彻底反转了。在 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 给出的回答，是「home base」（大本营）这个概念：这应该是一个很好的「主场」，一个可以让用户追踪自己在不同产品界面上、所有待办事项的地方。有些事情，用户可以完全在 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 学会使用现成的工具 —— 能和它交互、把任务交接给它，这通常是通过 connectors（连接器）、computer use（电脑操作能力），或者像 Premiere Pro 这个案例一样，通过扩展插件来实现。

第二件事，则是 Dan Shipper 提到过的那种设想：用户手里已经有一堆可以点来点去使用的网页应用，但希望能把这些应用在 Codex 里直接打开，让 Codex 在里面替他们多做一些事情。这两种模式，几乎互为镜像，团队目前正在同时大力推进这两条线。