智东西（公众号：zhidxcom）
编译 |  茄子
编辑 |  程茜

智东西7月1日消息，6月28日，Lenny播客最新一期访谈，对话OpenAI Codex产品与工程负责人安德鲁·安布罗西诺（Andrew Ambrosino），讨论AI正在如何重塑软件产品的生产方式，诸多观点值得产品和研发从业者参考。

Codex作为OpenAI旗下的AI编程工具，是近一年来该公司活跃用户数量增长最快的产品之一。近半年来，其使用量增长6倍，周活跃用户超500万。

而Andrew则是Codex产品桌面应用开发的负责人同时也是OpenAI的技术团队的一员。他曾担任过设计师、软件工程师，早年还是YC明星金融创业公司Catch的创始人，身兼CEO、CTO、产品负责人多职。

▲Andrew Ambrosino工作履历（图源：领英）

Andrew指出，随着大模型降低实现成本，软件开发的核心瓶颈正从“写出功能”转向“做出取舍”。在OpenAI内部，同一需求可能同时出现大量并行原型，而产品团队的主要工作变为筛选与整合，而非实现本身。

他认为，在这一变化下，“品味”成为关键能力，包括定义做什么、如何组织系统以及如何表达产品形态。而传统以PRD（产品需求文档）与瀑布流程为中心的开发方式正在被解构，文档与原型的作用转向按问题类型选择使用。

同时，Andrew透露OpenAI约90%员工正在使用Codex，覆盖工程及非技术岗位，其外部周活已超过500万，AI正在从编程工具扩展为跨职能的通用工作入口。

▲Codex技术负责人Andrew访谈现场，Andrew（左）、主持人Lenny（右）（图源：YouTube）

以下是本次访谈的核心要点：

1、Codex周活超500万，超过90%OpenAI员工在用：自2026年1月至今，Codex使用量增长6倍，周活跃用户超500万。OpenAI内部90%员工每周使用，涵盖工程、市场、财务、法务等岗位。

2、产品开发流程倒置：以前是“写文档→研究→原型→实现”（因为实现贵），现在是“实现成本趋近于零，任何人都能做出任何东西”OpenAI内部一个功能可能有90个不同团队同时在搞原型。

3、最核心的能力变成“品味”：实现不值钱了，值钱的是“判断做什么”、怎么做好“品味”，哪些功能该合并、用什么媒介传递信息、什么才是用户真正需要的。

4、AI做不好设计的三个原因：设计比代码难评分；模型训练缺乏设计反馈回路；设计需要“新颖性”，而AI擅长学习已有模式。

5、角色正在坍塌：设计师写代码、PM写代码、工程师做产品设计。OpenAI不设固定角色标签，按“技术成员”划分，你的角色就是你花时间做的那些事。

6、Codex目标是成为最好的桌面应用：Codex的愿景不只是开发者工具，目标是成为“最好的桌面应用”，能写代码、整理文件、做数据分析、读邮件、操作浏览器，一个应用覆盖所有知识工作。

7、失败过10-15年才找到成功：Andrew创业10-15年一直在失败，直到Codex才找到成功。他给的建议是：“不要固守你的流程，固守你能交付的结果。”

以下是对访谈全程内容的编译（为优化阅读体验智东西做了不改变原意的编辑）：

Lenny：OpenAI 90%的人都在用Codex。

Andrew：不是90%的工程师，是90%的整个公司。

Lenny：你前几天发了条推文，说你想让Codex成为有史以来最好的桌面应用。

Andrew：对。Codex的质量门槛必须足够高，高到你在打开这个应用做下一件事的时候不会有任何犹豫，它就是你自然而然的选择。就像人们现在习惯去打开一个浏览器标签一样。

Lenny：是的。我知道不断有数据出来，说你们创下了各种使用量纪录。

Andrew：我不太确定。再说吧。反正挺多人喜欢这个应用的。

Lenny：你觉得为什么AI和那些最前沿的模型就是做不好设计？

Andrew：我觉得设计更难评分，因为人类审美的那部分是反馈机制中必需的。用目前的技术来达成那一点，还是有点遥不可及。

Lenny：现在产品团队的形态跟几年前相比，是什么样的？

Andrew：OpenAI的每个人都非常有主动性，都有很好的想法，所以每个人都在做所有的事。并不是说人们在扮演根本不同的角色，或者专注于不同的事情。而是说现在的流程是倒过来的。实现不再是昂贵的部分了，我敢说，昂贵的是“品味”。

Lenny：你觉得会有这样一种“坍塌”到来吗，就是每个人都变成全能型选手，那就是未来？还是你觉得我们还是会主要保持职能分工？

Andrew：有一些事情我是担心的。我听说很多公司说我们要取消产品这个角色，每个人都将成为一个“构建者”，然后会发生的是……

一、Andrew：AI时代，产品开发流程已经倒过来了

Lenny：我们在准备这次聊天的时候，我问你你最想让大家从这次对话中得到什么，你说的是AI如何改变产品工作的形态。你工作在可能是最前沿的AI软件团队。所以你对未来的方向、对其他团队一两年后会走到哪里，有一个非常有趣的视角。那么现在产品团队的形态跟几年前相比，是什么样的？

Andrew：现在最难的事情之一，作为一个领导者在构建这些产品时，就是流程的倒置。我想很多人都讨论过这一点，就是现在任何人都可以构建任何东西。

我现在确实相信，从零开始，如果你跟这些模型对话，我们的也好，别人的也好，你确实可以搭建出你想要的任何功能。这并不是软件开发中困难的部分，但这确实很酷。而我认为这创造了一个环境，让人们可以做所有这些东西。你给人们无限的token。

OpenAI的每个人都非常有主动性，都有很好的想法，所以每个人都在做所有的事。而你看我们运行了很多年的产品流程，它一直是有点相反的，对吧？

它一直是研究、构思，也许有一些原型，但即使我们过了瀑布式开发阶段，它还是带有一种“实现是昂贵的，所以你需要在前面通过文档、通过研究、通过原型来去风险化，因为原型和设计更便宜”的假设。这个假设现在已经变了。现在，我敢肯定，对于某个我们急需做的功能，有90个不同的、没有协调的团队在各自实现和尝试？

所以简短的回答是，流程是倒过来的。并不是说人们在做根本不同的角色，或者关注不同的事情，也不是说技能消失了，或者角色就这么没了。而是流程倒过来了，实现不再是昂贵的部分了，我敢说，昂贵的是品味。

但它是策划的过程，是那90次尝试中，哪些是好的？哪些应该融入到其他方面？应该怎么框定这件事？它应该属于那个功能的一部分吗？开关里应该有几个分段？。

Lenny：“品味”这个词已经被说烂了。我想回头再说这个。关于那90个原型的想法，太有意思了。所以我想确认一下我理解得对不对。OpenAI内部有一个想法在流传。人们以前的做法是写文档。

Andrew：对。

Lenny：我们要构建什么，功能是什么，策略是什么，PRD。现在你描述的，完全说得通，人们直接创建一个原型。你是说公司里不同的人有类似的想法，现在他们不写文档了，而是创建自己的小原型，这就导致了90个不同的东西，大家可以看看，也许从中选一个方向。是这个意思吗？

Andrew：这种事儿很多。你已经看到很多产品负责人说PRD已死，原型为王。但我完全不相信这个。我认为现在发生的一件有趣的事情是，因为实现的成本在每一个媒介上都变得非常便宜，直接跳到一个原型是非常诱人的，尤其是如果你不是工程师，如果你从来没有写过代码，或者从来没有兴趣，或者从来没有时间，说“PRD已死，让我直接给你看我的意思”是非常诱人的，对吧？

但我也注意到，对于工程师来说，写很多文档也是非常诱人的，很多不值得读的文档。这不是在贬低写文档的人。而是说如果实现是充裕的，那么为你想要表达的观点选择正确的格式就变得非常重要。

如果那个观点是在一个模糊区域的产品清晰度，那它可能确实需要一份文档。如果你要做的是把东西放到人们手里去试用、去压力测试一个交互模式，那它就是原型。但我觉得现在有趣的一点是，选择正确的媒介变得非常重要。

Lenny：有一个术语，之前一位播客嘉宾分享过，我听到你说这个的时候就想到了，叫做“原始标记”。当设计师、画家或艺术家在一幅画或一件艺术品上做出第一个标记时，那个标记就是你开始回应的东西，一切都会从你做的第一个标记开始延伸。

所以听到你说的，有时候原型不是应该做的第一件事，因为那样你就会只是对这个原型做出反应，而不是对一个不同的想法或者一个更大的想法做出反应。我很喜欢听到这个。所以不是像大家说的“不再写文档了，不再写PRD了”。你说的是它们在特定场景下仍然有用。

Andrew：对。我觉得还有一点是，在以前的世界里，媒介本身就隐含了很多信号，表明某件事在流程中的位置。所以如果你看到某样东西感觉像是在生产环境中的应用，那就意味着它在流程的后期，假设已经被去风险了，设计已经看过了，这是一个好的商业目标。而现在这些东西被解耦了。之所以以前是这样，是因为在事情被恰当去风险之前，很难获得资源去构建它。现在这已经完全过时了。

所以我认为非常重要的是要说，我们可以有原型，我们可以有文档，但我们是否清楚这个东西是做什么的？因为正如你所说，你不想过度锚定在某个本应是探索性的东西上，但它现在看起来已经这么像生产就绪了，视觉上已经准备好上线了，但它并不是研究方向的正确模型，也不是用户真正需要的，也不是对业务最有利的。

不是要过度强调品味这件事，但还是一样，品味——知道做什么，如何呈现信息，如何达成目标，用什么媒介——正在成为最重要的事情。在所有领域都是如此。

二、AI时代，真正稀缺的是“品味”

Lenny：当你谈“品味”的时候，你说的好品味是什么？是你描述的那种决定“这就是我们要投入的事情”吗？还是说当你有了一个东西之后，判断“这个对吗？这个东西能发布吗？”当你想到好品味、好判断的时候，具体来说是什么？

Andrew：对。挺有意思的。我在网上刷太多了。有一条推文，好像是昨天的，他们用了Paul Graham的例子，说Paul Graham显然有好品味，但他穿着cargo shorts，对吧？所以我们得把品味的意思稍微拆解一下。这里面有很多细微差别。我觉得你刚才提到的那些都是其中一部分。

有审美的部分，但也有系统思考的部分，这个东西怎么融入整个系统？还有我们往哪里走，这个主题是什么？怎么呈现它？很多都是更广泛的上下文。当然，品味中也有部分是“这个交互动画在语义意义上不匹配它所试图传达的意思”，对吧？它太跳了，和它要表达的意思不符。这非常重要，我可能过度关注这个了。

但是，还有那种“这个东西应该是什么样的？如果我们什么都能造，那目标是什么？我们怎么到达那里？”——我觉得那才是真正品味的问题所在。

Lenny：当我听到这些的时候，我总是在想，随着AI越来越强，能做越来越多的工作，人类的大脑还会在哪些地方继续保持价值？感觉品味是其中一部分。我在这条线上思考的另一点是，AI在真正的设计上仍然非常糟糕。AI的输出并不好。

Andrew：对。

Lenny：很少能说“就是它了，他们做到了”。而且总是“哦，这是Claude设计，这是Codex设计”。你觉得为什么AI和最前沿的模型在今天就是做不好设计？你觉得它们最终能达到那个水平吗？你觉得我们会达到一个“天哪，我们不用再干了”的状态吗？

Andrew：对。我觉得有一些实际的原因导致它滞后了，也有一些更难解决的问题。我不是研究团队的，我这么说肯定会被骂的。我觉得设计比软件更难评分。创建一个反馈回路来训练模型什么是好设计、什么是坏设计，比“代码能不能编译”“它能不能做该做的事”要繁琐和繁重得多，因为人类审美的那部分是反馈机制中必需的。

我也认为实验室历史上更倾向于让模型擅长那些能加速AI研究的事情。在编码模型的早期阶段，很明显模型能够写出正确的代码会加速研究，对吧？而对于设计，你不能真正提出同样的理由。不是说擅长设计不重要，而是它不直接在那个飞轮里，对吧？这些是实际的原因，而且这些会消失的——这些模型会在设计上变得相当好。但有一些更模糊的东西会非常棘手。我列了一个简短的清单。

一是，什么被认为是好设计，其中有一部分是文化性的。你还记得吗，大概是去年，每一个新出来的网站都只是Linear网站的复制品。Linear的网站设计很好，品味很好。如果一个模型能做到那样，我会说“哇，这真是巨大的飞跃”。

如果我有一个模型每次都输出Linear的网站，那挑战不在于此。在设计中有一种“新颖性”的成分，它实际上比在软件工程中更重要。软件工程中你几乎希望它过度偏向已知的模式，对吧？而设计不一样，它需要一些随机性和新颖性。

二是，对我来说，我花了很多时间写代码，或者在早期Codex应用上监督代码，即使模型在设计中变得很好，也存在一个抽象层，是软件设计和正在写的代码之间的互动。

这边角落里的这个东西应该在代码库中与下面的这个东西共享某些内容。这和“模型需要成为一个更好的设计师”是有点不同的，尤其是在视觉方面，但它要深得多。这是关于抽象层的。

比如，如果明天我们公司做了品牌重塑，浅层版本是我们得一个一个更新263个组件。深层版本是，这两个看起来不同的东西之间的语义——它们都在列表中，拥有某种样式，向用户传达某种交互模式。我觉得在目前的技术下，那个抽象层还是有点遥不可及的，对吧？

所以我认为，当我们经历这个过程的时候，我们11月开始做Codex应用，一开始我们没有全职使用它，现在我们用它来做所有事情，这个过程是一段旅程，但现在我们在使用它的时候实际做的事情已经不一样了。所以问题是什么来着？

Lenny：没有，那个回答非常精彩。说到设计和创意，Codex应用刚出来的时候，它是一个全新的东西。以前没人见过。它不是终端，不是IDE。它是一个能写代码的聊天界面，你还能看到代码。听你这么说，感觉AI很难“给出一个全新的编码范式”。而这似乎就是人类大脑目前仍然有价值的地方——几乎是创造力，想出新的东西，而不是从已有事物的模式中生成。

Andrew：对。我完全同意。让我们暂时为人类大脑鼓掌。

三、AI没有杀死设计流程，只是重构了它

Lenny：在我们准备这次对话的时候，你说你在听Jenny的那一期节目，她是Claude Code和Claude Cowork的设计负责人。她有一个观点是设计流程已死。没有时间做设计了，事情发展太快了，直接构建，然后设计在事情推进的过程中引导方向。你暗示你对设计流程有不同的看法。

Andrew：我和Jenny可能在这方面有很多共识。我不是“设计流程本尊”的粉丝。我同意她的观点，它确实死了。而且在AI之前我就真的不喜欢这个流程。

Lenny：你能快速描述一下那个流程吗？让大家知道你说的是什么。

Andrew：几年前我创办一家初创公司的时候，我们做设计招聘，有一篇有点讽刺的文章出来了，关于案例研究工厂的。那是mid-syrup时代的东西。

设计师被教这个流程，并且把它看得高于一切，甚至高于结果。如果某样东西经过了那个流程，那就两件事是成立的：一是它会是好的，流程能保证质量和影响力；二是如果某样东西经过了那个流程，即使你不喜欢它、没人用它，它也是好的。流程就是用户研究、发散、收敛。框架是对的，但一直有点学术化。

但我认为这确实暴露了它的短板，尤其是因为实现的速度。而且，再一次，那个流程是建立在“实现是昂贵的，你只能负担得起构建一次”的假设之上的。所以你需要在实现之前彻底地遍历问题空间和解决方案空间，对吧？然后我们看到了，像Figma、Origami和所有这些工具，你可以通过把交互原型提前拉到流程中来加速一些洞察，对吧？

你可以模拟生产环境，就是高管们会说“我们能不能做一个原型”，然后期望它能直接工作，对吧？但这东西是真的。这成为了设计流程本尊的一部分。我们把原型拉进了流程里。

现在的问题是你可以把所有实现都拉进去。在很多假设之间存在不匹配。你看到一个完全打磨好的原型，看起来已经可以发布了，公司里有足够多的人看到它，他们会说“我们现在能发布这个吗？”

但实际上我们还在早期设计流程阶段，只是没人说出来，对吧？这就是我们现在的情况，像多人探索一样。90个人会有这个想法，它会看起来很精致，但实际上这就是现在的设计流程。把设计流程和媒介绑定在一起，这是可怕的部分。

设计师现在有更多的工具来做这个流程，对吧？你可以把东西放到当前产品中，你可以做AB测试，或者就把它当原型用。很多公司现在都有“产品婴儿版”的想法，比如Baby Cursor。你在Twitter上见过这个，我们有Baby Codex，对吧？一个大幅简化的代码库，模拟了生产应用的所有交互，因此在上面进行vibe coding要快得多。

因为你可以说，“如果侧边栏这样工作会怎样？”或者“如果一个面板进来，在这里有一个群聊会怎样？”“如果XYZ会怎样？”这是一个巨大的工具，是设计流程的一部分。

所以说设计流程已死，我觉得既对也不对。如果你绑定的是旧的工具、旧的规格、旧的那套日常具体流程，那它确实死了，你会过得很不舒服。但把整个流程扔掉，或者把流程那种“我们在这个阶段”的框架扔掉，那比以往任何时候都更重要。

Lenny：这真的很有意思，因为你有各个职能的背景。如果大家看你的领英，上面写着工程师、设计师、产品经理、创始人。现在你负责桌面应用，而且设计不在你的管辖范围内，对吧？是有独立的设计团队，还是他们在你下面？

Andrew：看每周情况吧。

Lenny：好的。

Andrew：我们合作非常紧密。我们相信大家一起坐在一起、嵌入彼此。汇报线什么的，我不知道。

Lenny：他们每周都在变。Codex的设计流程是什么样的？

Andrew：关于角色坍塌、存在性角色坍塌已经写了很多了。没有什么角色了。我们没有看到那种情况。我们在Codex组织内看到的角色坍塌比公司其他部门和经济其他部门要多。我认为部分原因是这是一个面向工程师的技术产品，所以我们的设计师懂工程师的语言，我们的产品经理懂技术语言、会写代码。Alexander有计算机科学硕士学位，而我没有。所以我们看到了很多角色坍塌。

我觉得我们描述团队协作方式的一种方式是，角色之间的重叠比过去多得多。每个人不再是由“设计在哪里停止、工程从哪里开始”的边界来定义，而是由他们工作的平均位置来定义。

如果你把设计团队每个人做的事情平均一下，有很多代码相关的工作，有很多产品相关的工作，但平均来看，他们的点在这边。如果你把它画成图的话。

这也跟流程有关。尤其是因为Codex应用的整个开发都是由内部自测（dogfooding）循环驱动的。我们所有人都有一个愿望，就是尽可能多地在这个应用里做事，即使它不是最好的工具，这样它才能成为最好的工具。

所以很多设计是我们所有人通过使用这个应用来完成的，然后说“这个哪里有问题？”我们经常做的一件事是我们不改进流程，而是为了让产品变得更好而去做它，这是一个非常不舒服的处境。但每周都在变化。

Lenny：我特别喜欢你提出的这个观点：你的角色就是你花时间做的事情的平均值。如果你大部分时间都在做PM的工作，那你现在就是PM。如果是工程，那你现在就是工程师。你觉得是OpenAI第一个把员工叫做“技术成员”的吗？

Andrew：不是，我相信这可能是从Xerox开始的。我实习的第一家公司，叫Upthere，也是这么叫的。这个概念一直存在，但现在更常见了。这确实是研究型公司的一个传统，对吧？

Lenny：好的。它从研究领域出来，但我觉得这可能是未来方向的一个信号——我们就叫每个人“技术成员”，你的职能不是固定的，你不是被框在PM或设计或工程的格子里。你觉得长远来看我们都会走向那个方向吗？

你觉得职能会继续存在吗？仍然有PM的技能、工程的技能、设计的技能，人们会说“我是设计师”。还是你觉得会出现一种“坍塌”，每个人都是全能型选手，那就是未来？还是我们还是会保持职能分工？

Andrew：有一些事情我是担心的。我觉得有些公司喜欢极端地追随别人说的趋势。取消角色概念的部分危险在于，它可能危险地消除“专长有可掌握的最佳实践”这个观念。

我听说很多公司说我们要取消产品角色，我觉得这是个糟糕的主意，然后每个人都将成为一个“构建者”。然后会发生的是，他们不喜欢已经建立起来的产品这个学科，而它是有真实的最佳实践、有真实尝试过和失败过的东西、有真实流程的——这些就被抛弃了，因为人们会说“哦，我写了几行代码”，对吧？那不是个好状态。

我觉得像“这不是你的领域”这种边界，我欢迎它消失。但这里面有个平衡。不是每个人都能做所有事，无论从广度还是深度上。这就是为什么管理者不会消失。不是每个人都能做所有事，而且每个学科都有技能成分，我认为很多工程师没有认识到这一点——工程有技能成分，而其他角色只是在“凭感觉做事”。

Lenny：对。我觉得还有一点就是“你想做这个工作吗？”

Andrew：我是不是想做？我觉得现在更多的是，切换角色变得更容易了，学习最佳实践变得更容易了，你的有效性不再与你使用某个具体工具的能力绑定在一起了，更多的是你能不能让自己进入这种思维模式，学习哪些东西有效、哪些无效，然后专注于此。
我

花了很长时间觉得自己不应该当一个软件工程师，因为我不关心汇编语言或者背诵TypeScript语法，你知道吗？这些角色中一直有一些部分是那种“看门人”性质的，说“擅长这个角色就是擅长这个工具”。我觉得那正是开始瓦解的东西。我只是觉得人们把这些事过度夸张了。

Lenny：你的团队现在是什么样的？Codex团队有多少工程师、设计师、PM？现在团队的构成大概是什么样的？

Andrew：每次有人问我Codex团队有多少人，我说大概在10到几千人之间。这是个假答案，但也是真的，因为我们确实把它看作是所有人工作的集大成。所有模型研究的东西，所有让模型擅长代码和浏览器使用的东西。所有模型个性的东西。所有前端基础设施的产品工作，所有用户相关的东西——全都是这个产品。

但与此同时，我们也不是每天接收成千上万人的PR。所以我们有一个团队，工程师是两位数，设计师大概是一半。有几个产品人员，虽然产品角色更多是“区域防守”的打法。

我觉得Codex这边或桌面端所有人都有一个共同点，就是主动性和品味。很多前创始人，或者之前在大公司做创始人风格事情的人，很多有极佳品味的人。在OpenAI我们允许团队变得很大，所以我们没有那种“没有管理层”的情况，但团队确实相当大，大部分是IC。我觉得这很好。

Lenny：你用了“区域防守”这个词来形容产品工作，我觉得这很有意思。它跟设计的转变也有对应关系。就是你在这里管理和协调。多谈一点，那是什么样子的？对产品人来说，区域防守是什么样子的？

四、Codex在11月上线一定会失败

Andrew：对，我和Alexander就这个比喻谈了很多次。就是说如果两个产品人合作太紧密，那往往不是一个好信号。你作为产品人，想做的是某种力导向的活动，就是“哪里有缺口？”尤其是在这个新世界里，策展、引导和对齐是很重要的工作。有大量的混乱，人们在到处扔想法。自上而下、长达一年的那种规划行不通了。

所以现在我们需要品味制造者来引导，从概念到产品应该是什么。这就意味着你基本上想要覆盖整个公司。所以你们分散开，说“谁最擅长什么？让我们之间留出一些空间，这样我们就能覆盖全面。”就是这样做的。

然后你们填补缺口。我们说“我们想招有产品思维的工程师。我们不希望一群人写了一大堆代码，需要整个团队来审查产品一致性。”我们希望每个人都有这些技能，但我觉得人们深入钻研的东西必须改变。

Lenny：这确实是我在和像你这样的人交谈时反复注意到的一个主题。现在最有价值的人之一，是那种能把一个想法从概念到完成、并且有品味知道“这个很棒”的人。就像一个守护者，贯穿整个过程的这种“让它变得很棒”的执着。就是你说的那种高主动性、高品味的人。这就是你对“我们在招什么样的人”和“谁会在新世界里表现很好”的思考方式吗？

Andrew：对，我觉得那是现在的核心部分。这也说明了我如何看待IC与管理层的区别。不是说管理层要消失了，不是说每个人都是IC了，而是每个人现在都两者兼有，对吧？如果你是IC，你不是在逐个字符地敲代码，对吧？你在管理一些东西——你在管理Agent，你在管理工作，那些工作汇集在一起做某件事。如果你是团队管理者，你在做同样的事情，只是粒度不同。

我通常寻找的，显然是对本学科的掌握，然后还要有品味，说“你会拥有无限的token，我们不能只是在生产垃圾，你需要能分辨什么是信号、什么是噪音”——在一个无限内容的世界里。

Lenny：你提到了规划。以现在的发展速度，做路线图规划变得非常困难。我觉得尤其是在你的世界里。

Andrew：人们对此很沮丧。是的。

Lenny：因为东西在不断发布、不断变化。你们团队是怎么做规划的？你们会想多远？规划长什么样？是电子表格吗？是MD文件吗？规划的产物是什么？

Andrew：我觉得我们没有做什么革命性的东西。我们在规划上并不聪明。基本思路是，时间越短的东西，细节越多。不是说我们不规划9个月后的事，而是那只能保持非常模糊，因为你给9个月计划添加的任何精确性都是虚假的精确性，你只是在浪费时间。

你可以说些什么，但我们在产品侧做的任何计划，在11月能计划的可能12月还成立，但不是实际发生的。规划确实非常难。我们一般需要知道我们觉得模型在什么时间线上能做什么。

在我上一家公司，我看到了这种转变，我们开始用模型来驱动功能，产品流程失效了。基本上只能是：列出我们觉得未来一两年感兴趣做的所有事情，全部原型化，决定哪些事情现在准备好了，其他的就放着，然后每次模型有新的飞跃，就用新模型再试一次。因为功能好不好的前提是基于它们是否足够智能，而不是它们的形态。

这是一个关于Codex应用的好故事。我很确定我们在2月发布的Codex应用，如果它在11月就准备好了，它在市场上绝对会失败。唯一的区别就是11月到2月之间的模型。我觉得这很能说明问题——这个产品形状完全一样，但结果完全不同，仅仅隔了几个月。

Lenny：这确实是我这个播客里反复出现的一个主题——构建那些“现在还不能用、但模型变强了就能用”的东西。还有另一个主题，就是雄心。对你做的事情要更有雄心。所以这是你们做事的一种方式吗？就是构建一堆现在可能还不能用的东西，先放着，等模型跟上？

Andrew：对，我们有很多这样的东西。我觉得有时候挑战在于，你必须再次非常清楚地说明那在设计流程的哪个阶段。人们还是有那种肌肉记忆，觉得“哦，我为这个东西写了代码，所以我们应该把它推出去”。不是的，那意味着你现在有了一个工件，可以用来对未来模型进行测试，对吧？

这事发生在我们应用里的内置浏览器上。我们有一个能用的版本。回到Atlas，我们有Agent在Atlas内部工作，那挺酷的。在那之前我们在ChatGPT里有Operator，但没有成功。想法很酷。在Operator、Atlas、Codex、ChatGPT之间可以画出一条线，它们本质上是同一个功能，但在不同的智能水平下重新发布，结果完全不同。

所以我推着人们不要固执地说“这个不行，所以这是个坏功能”。不是的，它可能还没准备好。还有一点，尤其是在研究领域，总是有想成为最雄心勃勃的欲望，说“在极限情况下模型能做到这个”，但在产品侧它就是不成立。

如果你回到最初的Codex发布，基本上就是它说自己是Codex web，但和它交互并不好，你给模型一个任务，它会去做，然后带着完成的结果回来找你。听起来没那么激进。问题在于它做得没那么好。它写了代码，但那个形态太早了。

然后Claude Code出来了，完全是本地的，不连接云端。它不假装自己是那么具有智能体性的，它会问你问题，它会坐在那里，你不能把你的整个生活都委托给它。那个效果好多了，因为那就是当时模型所处的阶段。所以我们当时太“AGI上头”了。我觉得我经常从这个教训中思考。

以前是市场营销告诉你关于产品形态和产品沟通的所有这些东西，现在不是了，你可能需要把一个东西发布六次，它才能工作，而它的形态可能完全没有变化。

Lenny：听到你们在产品构建中要考虑的所有变量，真的很有意思。现在有模型的时间线、研究进展、它变得多聪明。还有人们能否理解“这就是你如何在云端构建软件的方式”、这是未来——让人们为这个新未来做好准备。

然后是你们团队能构建什么。我喜欢Codex的例子，因为它回到了“雄心”这个主题。我想知道这对你来说有没有什么启示——就是要更有雄心，因为这些模型能做的事情比你想象的要多得多。有时候它对市场来说太有雄心了，市场还没准备好。但你会思考这个吗？就是推动你的团队更有雄心，因为做那些在过去可能看起来疯狂困难的事情变得容易多了。

Andrew：对，这是一个核心挑战。一旦有一个产品或者功能存在了，人们很容易找到各种小毛病并优化它们。

Lenny：微优化。

Andrew：他们应该这么做，Twitter上的人也喜欢提醒我们这一点，我感谢他们。人们应该关注已经存在的功能，让它们更可靠、更好。但这也是为什么我们有一种自下而上探索的文化，因为有时候就像Codex应用出现并以某种方式颠覆了ChatGPT一样，这个东西会被未来的某个努力颠覆。这也是设计的一部分，你不能总是一个团队同时擅长颠覆性的部分和维护产品质量的部分。你需要设计一个能同时容纳两者的流程。

Lenny：稍微拉远一点看。如果你想想我们一直在经历的AI影响产品构建方式的进程，我们已经走了多远，从你所说的“我们以前手工写所有代码，像手艺人一样创造人类代码”到“AI写100%的代码”，再到你实际说的“现在编码就是引导AI”。

当你思考“我的代码有多少是AI写的”这个问题，几乎变成了“我引导了它多少次”才是编码的AI版本。现在还有Agent、循环等等这些东西，从你所见的，最新前沿是什么？那些最AI原生的团队现在是怎么运作的？可能人们还不太了解。

Andrew：对，循环已经是上周的事了，兄弟。我们讨论过这个。一个最大的问题总是“产品有多少是AI写的？”这个问题总是很难回答，因为如果你用去年的标准，那我们现在产品100%是AI写的代码。所以问题更像是“代码是有监督写的还是无监督写的？”那是完全不同的事情。我欢迎标准的改变，因为那意味着我们在产品上取得了进展。

在自主开发的软件方面有很多探索。很多harness工程的东西，很多不同的探索。比如“如果你在夜间运行，对代码库做垃圾回收来清理它，会怎样？”有一件事我认为所有模型目前都有的问题就是它们通常会增加复杂性。如果研究团队在听，请让模型更擅长删除代码。但现在当你试图把开发完全放在自动驾驶上时，这就成了一个问题。这在人这一侧和代码库那一侧都是问题。

比如功能请求，你怎么教一个模型哪些功能该构建、哪些该忽略、哪些该分组并稍微重新框定？你怎么教一个模型如何构建正确的抽象？所有这一切都在变好。我不认为我们到了那种“我们只需要设置一个循环来改进应用”的阶段，让它监听Twitter、监听Slack、监听邮件——我们还没到那一步，但我们正在努力让它发生。

Lenny：你觉得我们会到那一步吗？我们会达到那种“增长”然后“获胜”的状态吗？

Andrew：目标赚钱，让我赚十亿美元？

Lenny：赢得市场。

Andrew：我不知道，兄弟。我不是那种说“永不”或“总是”的人。

Lenny：作为产品负责人、工程负责人，你在工作中是怎么用AI的？有哪些你使用它的方式可能是人们没意识到可以在应用里用的？

Andrew：我觉得我现在拥有世界上最好的工作。但让它变得非常有趣的一点是，当我们在开发最初的Codex应用时，我个人的目标是让它成为我写代码用的工具。我说“我需要把这个东西做得在开发上足够好，以至于我可以用它来构建Codex应用本身”。那时的Codex应用是一个开发工具，对吧？

我们很快就进入了个人dogfooding循环，因为你会说“哦，我做不了这个事，我应该修好它，这样我才能做这个事。现在我能做这个事了，现在我能做更多的事了。”我们发布了那个。然后下一个挑战是“嘿，人们开始在用这个东西做一些不同形态的事情了，现在我需要让它增长，所以我需要招几个人来帮忙”。

所以我的角色在那时变了，与此同时应用的角色也需要改变。我说“好，我需要做更多的产品发现。我需要找到正确的循环来看到每个人在做什么，并引导偏离轨道的事情。”所以突然之间，那就是我开始用Codex应用做的事情，对吧？我仍然写代码。我试图让我自己的使用方式与我们要解决的问题保持一致。

现在我会说“我需要建立一个电子表格来建模这个。我需要做一个内部深度研究，了解所有已经投入这个研究领域的努力，为下一个版本做准备”。在五月份左右的某个发布或一系列发布中，我们为Codex应用引入了内置浏览器、计算机使用和工件创建功能。那我觉得是我们Codex的“几乎面向所有人”的发布。每个人都知道“vibe coding”这个词。

我觉得那是我们第一次协调发布的五个功能——我当时有一个Notion文档记录了所有需要做的事情，然后我在自动化地去从PR、从Slack频道收集更新，更新状态追踪器。现在这已经相当普遍了，但在当时，我觉得自己处于“如何管理一个产品发布”的最前沿。

简而言之，我用Codex应用的方式基本上就是“我的工作变成了什么，我怎么让这个东西能做我需要做的一切？”我早上起来，会看到我收到的每日简报——来自我加入的3000个Slack频道里的所有内容，哪些需要我的关注。我可以回复说“给我五个问题，我来回答”，我就能做到。

Lenny：你是怎么设置那个的？对想设置的人来说，工作流是什么样的？因为听起来太棒了。

Andrew：再说一次，我觉得我们在很多这方面还处于发现阶段。所以现在，我是在做一个自动化或者定时任务，说“我过一遍我的Slack频道，这些是我关心的、认为最重要的事情”。所以我还在定义那些“需要留意的事情”，按不同类别划分，这里有一些上下文。然后我会把它设置为一个自动化任务。

前几次运行可能需要一些引导，幸运的是，用这个应用，我不需要去弄清楚如何编辑指令，我直接说“嘿，下次运行的时候，能不能请你关注这个而不是那个？”或者“你能不能弱化这个工作流？”“嘿，这件事发生了，但它没有出现在简报里，你能不能确保那种形态的东西？”我可以在这个过程中指导它，它会更新它通知我的方式之类的。太棒了。

Andrew：但在未来，这其实是聊天机器人形态的一个核心问题，对吧？我知道怎么设置这个，我有时间设置这个，因为对我来说这是产品发现。但如果你不在OpenAI工作，不在开发这个，你不想必须搞清楚所有这些东西。我们需要搞清楚那种形态。

Lenny：对。我听到的是，我觉得人们没有意识到你们的应用可以很像OpenClaw。人们那么兴奋的是，你只要跟它说，设置这个，每天帮我检查这个，然后告诉我发生了什么——它开始成为所有产品的一部分了。这太棒了。所以某人设置这个的方式就是他们在应用里说“我想设置一个自动化来做这个，看看我的Slack，这些是我想做的事情”。

Andrew：对。应用会说你说的对，它会为你设置。如果它没有Slack连接器，它会说“我能添加Slack连接器吗？”是或否？你可以点“是”。我们至少能做到的是，如果你不知道如何在应用里做某事，你直接问它就行，对吧？我觉得这还不够，但我觉得至少是我们能做的。

Lenny：对。一个好例子是我在Codex里建了一个小应用来过滤收件箱里的垃圾邮件。每封进来的邮件，它会看然后判断这是不是那种我不想看的未经请求的冷邮件，给它打标签然后放到别处。为了设置那个，其中一步是你得去Google Cloud控制台设置那些pub/sub、API和触发器。我不知道你有没有用过那个界面，真的很烦人很慢，对吧？

Andrew：对。

Lenny：所以我就想“等等，如果我让你去做呢？”然后我说“好的，酷。帮我做这个。”然后它就描述了计算机使用。我以前从没真的在我的电脑上见过这个——它就接管了我的电脑，开始去那里操作。

Andrew：就像“我不管你有没有连接器，兄弟。我就开始点。”

Lenny：对，然后它自己搞定了。看着它做事太疯狂了。

Andrew：设计连接器之间的决策边界——什么时候用内置浏览器，什么时候用你连接的Chrome扩展，什么时候用计算机使用——这很有趣，都是靠感觉来摸索。

Lenny：我前几天看到一条很好的Twitter帖子，他们描述了这三种形态以及各自用途。那个人描述得非常好。

Andrew：这些个人工作流真的很有意思，因为有些真的很受欢迎。人们在尝试各种东西。每个人都在建立自己的个人系统。你问这里的每个人他们怎么做的，每件事都不一样。然后会出现一些共同的主题，我们会说“你知道吗，那应该成为应用里的一流体验。我们应该把大家似乎都在设置的这个东西直接做出来。”

我觉得记忆就属于那种形态——我们有很多人，其他公司也有很多人，说“我建了一个Obsidian库或者Notion区域，我告诉它怎么构建我的‘思维宫殿’，怎么放东西”——我不知道是不是每个人都应该那样做，你不应该非得那样做，应该有一个记忆功能为你做这件事，那是相当通用的。那是其中之一。

但还有其他东西，比如你的工作流程，有些东西你应该去设置。但我认为我们一直在筛选哪些对个人有效的东西应该进入产品，哪些应该留在“那只是你做你工作的方式”。哪些应该成为基础组件，哪些不应该。

Lenny：对，这就是你之前说的品味和判断——筛选这些东西。我想谈一下浏览器使用这个部分，因为我觉得人们没有意识到它有多强大，以及它可以用来做什么。这让我想起，我不知道你有没有看Dan Shipper上这个播客的那期，他有一个预测，就是我们开始用Codex来运行我们内部的SaaS应用。

Andrew：对。所以，不用去Chrome里。我知道他每天给我发消息问这个。

Lenny：你觉得这是未来的方向吗？我们就在Codex应用里工作，在里面用Notion、Linear、Salesforce，有Agent在旁边帮忙？还是你觉得那是不同的方向？

Andrew：这确实非常有意思，因为显然我们有过几次尝试浏览器形态的东西，对吧？Operator、Atlas里的Agent模式，现在桌面应用里有内置浏览器。我们也可以安装Chrome扩展让应用连接Chrome。我们有很多不同的形态。

我觉得我们从中学到了很多不同的东西。有很多因素在起作用。比如，我们最初发布应用的时候，它是一个Electron应用。内置浏览器能做的事情有限，而且有点卡顿。所以我们的内置浏览器是为开发准备的，是用来测试前端的。我们说“它真的不适合做别的事情，它是一个开发者工具”。

然后我们切换到了我们的OWL技术栈，它驱动了Atlas浏览器，所以现在有了多标签页，有了企业安全功能，你可以真正登录到所有网站。我们一直在迭代。我觉得困难的地方一直在于这个浏览器的形态应该是什么样的？

这是只给Agent用的吗？你打开Chrome，在Chrome里做你的事，如果你问桌面应用，它会打开一个它能快速控制的浏览器，没有Playwright那样的延迟，还是我们想说这个应用是万能的，我们希望你把它当浏览器用？

这两者有大量的权衡，这不是一条有很多人走过的路，对吧？大多数浏览器在顶层就是浏览器，有浏览器标签页。

这创造了很多非常无聊但繁琐的问题，比如键盘快捷键，对吧？我们是做键位映射到VS Code，还是到Chrome，还是到我们自己的东西，还是到Linear？我们想有一些能延续的肌肉记忆，但所有这些在市场上有不同产品子形态的东西，我们该怎么办？

Lenny：这正好凸显了这个应用有多难，你要让它对从来没构建过东西的人也能工作，从更基础的用户到像Peter——OpenClaw那样用它来编码的高级用户。

Andrew：我不确定我能让Peter用这个应用。我觉得他可能是最后一个。

Lenny：他是终端的坚守者。

Andrew：但我会继续尝试。

Lenny：好。让我拉远一点，谈谈你们要把这一切带向哪里的宏观图景。你对Codex的愿景是什么？它会走向哪里？它会是什么样子？一两年、十年后？

Andrew：我们有Codex作为CLI，对吧？然后我们决定构建这个应用。我们对这个应用有点不确定，但对它能成为什么有很强的信念——作为一个开发者工具。它不会是一个IDE。它会是这个恰到好处的界面，有点像一个聊天机器人，但远不止于此，你能看到代码，但我们不让你编辑代码。

OpenAI在1月、2月发生了一件非常有趣的事，在我们真正发布Codex应用之前，我们已经开始在内部自测Codex应用了。我们发现我们在工程和研究工作流上已经收敛到相当清晰的内部产品市场契合了。他们很高兴，很喜欢它。我们说“我们只需要把质量门槛提上去再发布给全世界。我们相信这会是个东西。”

但后来在公司里，我们启动了一些其他工作流，说“嘿，Codex这个努力在编码Agent上确实有进展”，我们有来自市场、来自公关、来自财务、来自法务、基本上来自各个领域的人在用这个Codex应用，即使它对这些人是主动不友好的——它在试图向他们展示代码，它在试图请求批准运行命令，它在做所有这些对它们来说不是正确产品形态的事情。

那我们为什么不在其他界面上也加入Codex呢？我们把它加到ChatGPT桌面应用里吧，我们把它加到Atlas浏览器里吧。基本上就是把Codex的经验教训拿来，让它更通用，成为一个通用的知识工作工具。那些努力进行了一段时间，然后最烦人的问题发生了——没有人愿意离开Codex应用去那些据说是为其他用户群体打造的应用。

我觉得这里面的教训是，“开发者工具vs通用知识工作工具”这个二分法有很多细微差别，不是非此即彼。我们非常坚信这一点。就像我们讨论“你角色的平均值就是你的角色”一样，在产品侧也是真的，做Excel工作的人不想看到git仓库信息。

我们知道这一点，但我们也知道我们可以从他们做的事情中判断他们做的是什么样的工作，我们可以从简单开始，根据需要让产品变复杂。

这并不意味着我们没有模式，你可能想要一些模式来组织你的东西，来标示你进入体验的方式。但我们坚信我们构建的这个东西有正确的形态来承担真正深度的、垂直聚焦的事情。

我们与财务团队、科学团队、法务团队深入合作。我们说如果我们可以构建正确的可扩展性原语和正确的通用模型，那你就能用这个东西做任何事，对吧？然后我们的挑战就是怎么把它通用化。

但这又回到了“我们能构建的最好的桌面应用是什么样的”。所以Codex是开发者工具，ChatGPT是……这些都走向哪里？我们就是这么想的。

Lenny：你刚才说的那个点太有意思了——Codex应用做得太好了，让人们对它有了认知，用起来很好、很有趣，以至于所有人都开始用那个而不是ChatGPT应用。所以很明显的方向是把它们结合起来，这样你就不会制造这种混淆，我知道这也是大家一直在讨论的，把它们合并在一起的想法。

Andrew：有人叫它“超级应用”，我希望他们没说过这个词，因为现在我每天都要听到“超级应用”这个词。我们会克服的。很好。

Lenny：好。但那是不是就是——我们别叫它超级应用——但想法是，一个地方让人们去做所有事情。那是大致的方向还是待定？

Andrew：对。我们看到的是，它是一个很好的大本营。它是一个很好的地方来跟踪你需要在不同界面上做的所有事情。有些事你在应用里全部完成，有些事应用会打开其他应用来做。

应用可以连接Excel，所以它有内置的电子表格编辑器。那对在OpenAI做财务建模、募集数十亿美元的人来说够用吗？大概不够。所以应用直接和你桌面上的Microsoft Excel插件对话。

做完之后，你可以关掉Excel，对吧？所以不仅仅是“我们在屏幕上画一个矩形，所有事情都需要发生在这个矩形里”。它应该是你工作的起点、终点、自动化的地方，它使用你需要的任何东西。

有一个很好的故事，我们在这间房间里为Codex应用的首次发布拍了一些视频，我们内部的DX视频剪辑师Brent被安排去剪辑这些视频，他用Codex剪辑了所有视频，这是早期的“哇，人们在用这个东西做什么”的例子之一。

他决定开始用Codex的过程非常有意思。他开始只是因为好奇Codex能不能剪辑视频。Codex本身并不是视频编辑器，它没有那种界面，但它能理解他用的是Premiere Pro。它可以通过编辑Premiere Pro里支撑屏幕上内容的后台文件来做一些剪辑，但它不能做所有事情。

所以很自然地，Codex接下来就给自己构建了一个扩展，可以安装到Premiere Pro里，然后它就可以和那个扩展对话，说“嘿，Premiere Pro扩展，你能不能帮我把Premiere Pro应用里的这个标记改一下”。我们当时看到这个的时候觉得太疯狂了。

这是一个很好的模型，有一些专业工具专门做某些事情。所以我们试图用Codex和现在的ChatGPT同时做两件事：一是如何无缝地与你已经在用的这些工具交互，说“我们不需要为你构建一个更好的视频编辑器”。

但Codex和ChatGPT可以用那个视频编辑器，它可以交互，可以把东西交给它，对吧？这通常通过连接器、计算机使用，或者在这种情况下的扩展来实现。

还有一种Dan Shipper的模式，就是“嘿，我有这些网页应用，我可以点来点去用，但我想能在Codex里打开它们，让Codex对它们做额外的事情”，这两种模式几乎是相反的，我们同时在两者上都做了很多工作。

五、2000条”这很烂”：OpenAI的产品打磨方式

Lenny：Premiere这个故事对我来说很有意思，因为它又是一个“对这些AI工作要有更大雄心”的例子。你可能不知道，也许它们能做到这件事。几乎就是“去试试，看看它能不能搞定”。我要带我们进入播客的一个固定环节，我叫它“失败角落”。

问题就是，大家看到像你这样的人，一路高歌猛进，一切都在赢。Codex做得很棒。这个疯狂的职业生涯，一切都在向上。

人们可能看不到那些事情不顺利的时候，你发布过但失败了的东西。这些故事对人们来说很重要，让他们知道不是一直都赢。有没有一个你职业生涯中失败过但教会你很重要东西的故事？

Andrew：听到那种描述真是有趣。这大概是我第一次觉得自己不是在失败。我做了很长时间的创业公司创始人。最后基本上是把公司拆解卖了，对吧？那是好几年。那是一场苦战。是在高度监管的领域。整个过程感觉像是一直在失败。

我去了另一家创业公司，我们试图做一些AI工具，也是在同样受限的行业里，感觉是一次又一次地尝试然后失败。

所以对我来说，我实际上失败过很多次。你知道有时候只是时间点到了，技能、热情、市场时机都对齐了，这个项目我们才能把在Codex应用上学到的东西和ChatGPT结合起来。

我不知道有多少微小的失败——我们说“这应该是这样的形态”，然后扔到Slack里，结果有2000条消息的线程说我们有多蠢。

这就是我喜欢OpenAI的地方，人们会直接告诉我们。当我们在内部产品失败时，他们不会保留意见。这就是为什么外部产品一直很好的原因，因为它经历了这些。

Lenny：2000条“这很烂”。

Andrew：我在达到这个点之前失败了大概10到15年。所以我每天还是对事情进展顺利感到惊讶。我知道。

Lenny：我觉得这对人们来说真的很重要——你可以有很多事情没有成功，然后事情开始变得非常好，就是继续前进、继续学习，我想这是一条教训。

结语：Codex不只是开发者工具，它正在变成“工作的中枢”

AI抹平开发成本，写代码不再稀缺，但统筹规划、系统抽象、战略判断的“审美判断力”成为行业稀缺能力。Andrew认为，现有大模型缺少原创设计、长周期推演能力，无法独立完成完整产品经营；同时否定“全员开发者、淘汰产品岗”的激进行业论调。

以Codex为代表的新一代AI应用正在从单一工具，演变为跨应用的工作入口与执行中枢，使软件逐渐从“被使用的工具”，转向“执行工作的系统”，也预示下一代AI Agent竞争重心将从基础执行能力，转向战略决策与复杂业务统筹。

来源：Lenny’s Podcast