Codex技术大佬亲自揭秘：做AI产品最后拼的竟然是“品味”？

发布时间：2026-07-18 03:36:35 来源：安智兰德资讯网 作者：娱乐

智东西 编译 | 茄子
编辑 | 程茜

智东西7月1日消息，品味6月28日，技竟Lenny播客发布最新一期访谈，佬亲对话OpenAI Codex产品与工程负责人安德鲁·安布罗西诺（Andrew Ambrosino）。自揭最后双方深入探讨了AI如何重塑软件产品的产品生产范式，其核心观点为产品与研发从业者提供了极具前瞻性的品味参考。

作为OpenAI旗下增长最快的技竟AI编程工具，Codex近半年使用量激增6倍，佬亲周活跃用户突破500万。自揭最后Andrew Ambrosino不仅是产品Codex桌面应用开发的负责人，更是品味OpenAI技术团队的核心成员。他拥有独特的技竟跨界背景：曾担任设计师、软件工程师，佬亲早年还是自揭最后YC明星金融创业公司Catch的创始人，身兼CEO、产品CTO及产品负责人多职。

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

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

在这一范式转移中，“品味”（Taste）成为关键能力，涵盖定义做什么、如何组织系统以及表达产品形态。传统的PRD（产品需求文档）与瀑布流开发模式正在解构，文档与原型的作用正根据问题类型进行动态选择。

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

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

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

1. Codex周活超500万，渗透率极高：自2026年1月至今，Codex使用量增长6倍，周活跃用户超500万。OpenAI内部90%的员工每周使用，涵盖工程、市场、财务、法务等全岗位。
2. 产品开发流程倒置：传统流程为“写文档→研究→原型→实现”（因实现成本高）；现流程为“实现成本趋近于零，人人皆可构建”。OpenAI内部一个功能可能有90个不同团队同时开发原型。
3. 核心能力转向“品味”：实现不再昂贵，稀缺的是“判断做什么”的品味，包括功能合并、信息媒介选择及用户需求洞察。
4. AI设计困境的三大原因：设计难以量化评分；模型训练缺乏设计反馈回路；设计需要“新颖性”，而AI擅长学习既有模式。
5. 角色边界坍塌：设计师写代码、PM写代码、工程师做设计。OpenAI不设固定角色标签，按“技术成员”划分，角色由实际投入时间定义。
6. 愿景：成为最好的桌面应用：Codex不止于开发者工具，目标是成为覆盖写代码、文件整理、数据分析、邮件处理及浏览器操作的“通用知识工作入口”。
7. 长期主义与迭代：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：所以我就想“等等，如果我让你去做呢？”然后

相关文章