播客推荐 | 最危险的，是看起来随时能上线的原型 | OpenAI Codex 负责人

title: Why OpenAI is merging Codex and ChatGPT and the future of knowledge work | Andrew Ambrosinourl: https://www.youtube.com/watch?v=P3KDebPTUrwdate: 20260628

推荐语

OpenAI Codex 应用的产品与工程负责人 Andrew Ambrosino，聊实现变便宜之后，产品流程、设计和角色分工分别发生了什么。他的总判断：旧流程靠文档和原型在动手前降低风险，前提是实现昂贵；这个前提没了，流程整个反转，贵的变成筛选。

其中一些反共识的观点：

看起来随时能上线的原型，可能还在最早期的探索；写完代码也不等于该发布，那可能只是一个用来测试未来模型的 artifact——”像成品”这个阶段信号已经失效
功能好不好，本质取决于发布时模型够不够机智。同一个形态可能要发布六次才成功，Operator、Atlas、Codex 本质就是同一个功能；也因此，给九个月后的计划加任何精度，都是虚假精度
“设计流程已死”和”PRD 已死”都只对一半：死的是步骤和固定格式，而”我们在哪个阶段”的框架、为观点选对媒介（文档还是原型），比以往更重大
“多少代码是 AI 写的”已经是个过时的问题，目前是 100%。真正的问题是有监督写的还是无监督写的——而无监督的拦路石之一，是模型只会加代码，还不会删代码
角色由你工作内容的平均值定义，不再由职能边界定义。但会用 Excel，不等于能进财务团队

播客推荐 | 最危险的，是看起来随时能上线的原型 | OpenAI Codex 负责人

文字凝练稿

00:01:17

Lenny Rachitsky:

今天的嘉宾是Andrew Ambrosino，OpenAI Codex应用的产品和工程负责人。Codex正迅速成为人们构建产品的首选应用，也被用于非产品类工作，列如整理电脑文件、起草文档、做数据分析、读邮件等等。如果你听到节目最后，会有一段我们停止录制后的花絮，制作人聊了他如何用Codex辅助剪辑工作。

自今年1月以来，Codex的使用量增长了6倍，目前已有超过500万周活跃用户，我估计这个数字很快就会过时。在OpenAI内部，接近90%的员工每周使用Codex，而且不只是工程师。Andrew是一位从设计师转工程师、再转产品经理的人，如今在打造这个越来越多人用来构建自己产品的应用。

我们准备这次对话时，我问你最希望大家从中获得什么，你说是AI正如何改变产品工作的形态。你所在的可能是最前沿、最“AI化”的软件团队，所以你对趋势有很独特的视角。那目前的产品团队形态，和几年前相比是什么样？

Andrew Ambrosino:

目前作为一个leader最难的事情之一，就是整个流程在我看来发生了反转——任何人都能构建任何东西。我目前基本信任，只要你跟这些模型对话，我们的也好、别人的也好，你想要什么功能都能搭起来。这本身不是软件的难点，但很酷，它创造了一种环境：你给大家无限的token，OpenAI每个人都超级agentic、点子许多，于是每个人都在构建一切。

而回看我们长期以来运行的产品流程，恰恰相反：先是研究、构思，也许有些原型，即便过了瀑布流时代，底色仍是“实现很昂贵”，所以你要通过文档、研究、原型提前降低所有实现风险，由于原型和设计更便宜。

目前这彻底变了。我敢肯定，此刻有个我们急需做的功能，正有90个互不协调的团队在各自实现和尝试。所以简短的回答是：它反过来了。不是说大家的角色发生了本质变化、技能消失了或职位没了，而是流程反转了——实现已经不再是昂贵的部分。

昂贵的——我甚至敢说——是品味，是筛选的过程：这90个尝试里，哪些是好的？该把什么并入其他部分？该怎么呈现？它该不该成为另一个功能的一部分？切换开关里该有几个分段？就是所有这些问题。

00:05:23

Lenny Rachitsky:

我想回到“90个原型”这个特别有意思的点，确认一下我的理解。过去人们的做法是写文档：这是我们要构建的、这是功能、这是策略，也就是PRD。而你描述的今天是，公司里许多人有类似的想法，目前不写文档，而是各自做一个小原型，于是产生了90个不同的东西可供参考，也许从中挑出一个方向。是这个意思吗？

Andrew Ambrosino:

这种情况许多，不只是发生在我们这儿。你见过许多产品负责人说“PRD已死，原型当道”，但我实则完全不认同。有意思的是，由于实目前每种媒介上都变得如此便宜，人们很容易直接跳到原型，尤其是非工程师——如果你从没写过代码、没兴趣、或没时间，就特别容易说“PRD已死，我直接给你看我的意思”。

但我也注意到，工程师则很容易写一大堆不值得读的文档。我不是要嘲讽写文档的人，而是说，既然实现如此充裕，那么为你要表达的观点选对格式就变得超级重大。如果你要表达的是某个模糊领域的产品清晰度，那可能就该用文档；如果你要做的是把东西交到别人手上试用、压力测试某个交互模式，那就该用原型。所以目前有趣的地方就是，选对媒介变得超级重大。

Lenny Rachitsky:

有位播客嘉宾分享过一个词让我想到这个，叫“primal mark（原初笔触）”——设计师、画家或艺术家在画作上落下的第一笔。你会开始对那一笔做出反应，之后的一切都从那第一笔延伸下来。我听你的意思是，有时原型是错误的第一步，由于你会只对着这个原型反应，而不是去想别的、更大的想法。所以并不是大家说的“算了，别写了，不要文档、不要PRD了”，你是说它们对特定场景依旧有用。

Andrew Ambrosino:

是的。过去世界的一部分是，媒介本身就内含了许多信号，告知你某个东西处在流程的哪个阶段。如果你看到的东西感觉像生产环境里的应用，那意味着它处在流程后期、假设已经被降低风险、设计已经审过、这是个好的业务目标。

而目前这些东西被割裂开了。之所以以前是那样，是由于在东西被恰当地降低风险之前，很难拿到资源去构建它，而目前这一点彻底不成立了。所以我觉得很重大的是要开始区分：我们可以有原型、可以有文档，但我们是否清楚这个东西在做什么？由于如你所说，你不想过度锚定在一个本该是探索的东西上，可它目前看起来太像成品了——“哦，视觉上它可以上线了”，但它实则并不是研究走向、用户诉求或业务需求的正确模型。

不想过度强调品味这件事，但归根结底又回到品味：知道该做什么、如何呈现信息、如何达成目标、该用什么媒介，正成为最重大的事——这在每个领域都是如此。

00:10:26

Lenny Rachitsky:

当你说好品味时，指的是什么？是你刚描述的那种决定“就是它，我们要投入这个”？还是有了东西之后判断这对不对、是不是该发布的那个？请具体讲讲你心里的好品味、好判断到底是什么，由于大家听到这个词都觉得“是啊，我有品味，我知道”，但它在实践中到底什么样？

Andrew Ambrosino:

有意思，我太上网了。就在昨天，我看到Linear产品负责人的一条推特——如果记错了向本人道歉——大意是人们过度强调品味中审美的部分。他们用Paul Graham举例，说PG显然很有品味，却穿工装短裤。所以我们得把“品味”这个词稍微拆解一下。

这里有许多微妙之处。我觉得你提到的那些都算：的确有审美的部分，但也有系统思维的部分——这东西如何融入整个系统？还有方向感——我们要往哪走？这属于什么主题？还有如何呈现，许多是更广的上下文。当然也有些品味是关于细节的，列如这个交互动画不符合它本该传达的语义含义，太“利落”了，配不上它想表达的东西。这一点极其重大，我可能过于关注它了。

但真正的品味问题是：如果我们什么都能构建，那目标是什么？我们怎么达到那里？我觉得这才是真正的品味问题。

Lenny Rachitsky:

听到这些我总会想，随着AI越来越强、做越来越多的工作，人脑会在哪里继续有价值，品味似乎是其中之一。沿着这个思路，我还想到AI在实际设计上依旧很差，输出往往不怎么样，很少让人觉得“就是它，做到位了”，总是一眼看出“这是Claude的设计”“这是Codex的设计”。你觉得为什么AI和顶尖前沿模型今天就是不擅长设计？它们会达到那个水平吗？会到“天哪，我们完事了”的地步吗？

Andrew Ambrosino:

我倾向于认为，既有一些实践上的缘由导致它滞后，也有一些更难攻克的问题。我不在我们的研究组，说这些肯定会挨骂。我觉得设计比软件更难打分，创建一个能训练模型、判断什么是好设计什么是坏设计的循环，比“代码能不能编译、能不能实现该做的事”更繁琐、更费劲，由于品味中的人类因素是你需要的反馈机制的一部分。

我还认为，实验室历来投资于那些能加速AI研究的能力。在编程模型的早期，很明显模型能写出正确代码会加速研究，而设计上你没法给出同样的论证。不是说擅长设计不重大，而是它不直接在那个飞轮里。这些是实践缘由，它们会消失，这些模型会变得相当擅长设计。

但还有一些更模糊的、会超级棘手的东西，我列了个短清单。一是好设计里有文化的成分。你记得大致去年，每个新出的网站都是Linear网站的翻版。Linear的网站，好设计、好品味。如果一个模型做出那样的东西，我会觉得“哇，这是了不起的飞跃”；但如果我有个每次都输出Linear网站的模型，那不是挑战所在。设计里“新颖性”的重大程度比软件工程高得多——软件工程你几乎希望它过度依赖已知模式，而设计里有随机性和新颖性的成分。

还有，我在早期Codex上花了大量时间写代码、或者说监督代码。即便模型变得擅长设计，还有一个抽象层：软件设计和正在写的代码之间有互动关系。列如这个角落里的东西，在代码库里应该和下面那个东西共享X、Y、Z。这跟说“模型需要成为更好的设计师”不太一样，它虽然也是视觉设计，但要深得多，是关于抽象的。

列如明天我们公司做了品牌重塑，浅层版本是我们得逐个更新263个组件；深层版本是，这两个看起来不同的东西之间的语义——它们都在具有某种样式的列表里，用来向用户传达这种交互模式。我觉得这个抽象层用当前技术还有点够不着。

所以随着我们走过这个过程——我们11月开始做Codex应用，当时还没全职使用它，目前什么都用它。这是一段旅程，但目前我们用它实际做的事情已经是不同的事情了。

00:16:14

Lenny Rachitsky:

说到设计和创造力，Codex App 刚推出时是个全新的东西，以前没人见过。它不是终端，也不是 IDE，而是一个能写代码、还能看到代码的对话式产品。就像你说的，让 AI 提出一整套全新的编程范式似乎很难。我觉得人脑目前依旧有价值的地方，几乎就在于创造力、想出全新的东西，而不是重复那些已经被做过的模式。

Andrew Ambrosino:

我完全同意。为人脑鼓个掌吧。

00:16:50

Lenny Rachitsky:

在我们准备这期节目时，你说你听了 Jenny 那期——她是 Claude Code 和 Cowork 的设计负责人，她有一整套论点认为设计流程已死：目前没时间做设计，一切变化太快，直接开建，设计只是在推进过程中掌舵。你似乎有不太一样的见解。

Andrew Ambrosino:

我和 Jenny 实则在许多地方是一致的。我本来就不喜爱那套所谓正规的“设计流程”，也认同它已经死了。几年前我做创业公司做设计招聘时，有篇挺尖刻的文章叫“案例研究工厂”，讲的就是设计师被教导要把这套流程凌驾于一切结果之上：只要东西走过了这套用户研究、发散、收敛的框架，就被认为必定是好的、能保证质量和影响力，哪怕没人用。这一直有点学院派。

目前实现速度暴露了它的软肋。这套流程的前提是：实现很昂贵，你只能构建一次，所以必须在动手之前穷尽问题空间和解决方案空间。后来 Figma、Origami 这些工具让你能把交互原型提前拉进流程、模拟生产环境——虽然后来有个梗是高管们总说“能不能直接做个原型就指望它能用”，但这件事是真实的，原型化成了正规设计流程的一部分。

目前的问题是，你可以把整个实现都提前拉进来。这里有个错配：你看到一个高度打磨、像是随时能发布的原型，公司里足够多人看到就会说“能不能目前就发”，可实际上我们还处在早期设计阶段，只是没人这么说。这只是一堆多人协作的探索，看起来很完善，但这实则就是目前的设计流程。

所以说设计流程已死，我觉得既对也不对。如果你绑定在工具、绑定在流程的日常具体步骤上，那它的确死了，你会很不舒服。但要把流程整个扔掉，或者扔掉那层“我们目前处在流程哪个阶段”的框架，那反而比以往任何时候都更重大。而且设计师目前有更多工具来跑这个流程——可怕的地方就在这儿：你可以把东西塞进现有产品里做 A/B 测试，或者直接当原型用。

许多公司目前有一个“婴儿版产品”的概念，列如 baby Cursor，Twitter 上见过，我们有 baby codex——一个大幅简化的代码库，能近似复现生产 App 的所有交互，因此 vibe code 起来快得多。你可以试“如果侧边栏这样运作会怎样”“如果这里弹出一个面板做群聊会怎样”，这是设计流程里超级重大的一个工具。

Lenny Rachitsky:

很有意思，你有全功能的背景——看你的 LinkedIn，工程师、设计师、产品经理、创始人，目前负责桌面应用。设计应该不在你的管辖范围？是有单独的设计团队，还是归你管？

Andrew Ambrosino:

看是哪一周吧。我们合作超级紧密，信奉坐在一起、彼此嵌入，汇报线每周都在变。

Lenny Rachitsky:

那 Codex 上的设计流程是什么样的？

Andrew Ambrosino:

关于“角色坍塌”已经有许多讨论——说角色不复存在了。在 Codex 这个组，我们看到的角色融合的确比公司其他部分、比整个经济体都更明显。部分缘由是这是一款面向工程师的技术产品，所以我们的设计师“会说工程师的语言”，我们的产品经理懂技术、会写代码。Alexander 有计算机科学硕士学位，我可没有。

我们描述各组如何协作的一种方式是：角色间的重叠比以前多得多，每个人不再由“设计到哪儿为止、工程从哪儿开始”这种边界来定义，而是由他工作内容的平均值来定义。如果你把设计团队某个人做的所有事情平均一下，里面有不少写代码的活儿，也有不少产品的活儿，但平均下来，点会落在某个位置——你把它画在图上就清楚了。

这也和流程有关。由于整个 Codex App 都是被 dogfooding 循环塑造的，我们所有人都渴望尽量在 App 里完成更多事情，哪怕它还不是最好的工具——正因如此它才能变成最好的工具。所以许多设计工作，我们就是靠用 App 来做，然后问“这里哪儿坏了”。我们常常是为了把产品做好而不去改善自己的流程，这是个超级不舒服的处境，但每周都在变。

Lenny Rachitsky:

我特别喜爱这个观点——你的角色就是你花时间做的事情的平均值。如果你大部分工作是产品经理式的，那你目前就是 PM；如果是工程，那你目前就是工程师。

00:23:42

我感觉 OpenAI 是不是第一家把员工称作“technical staff”（技术团队成员）的公司？

Andrew Ambrosino:

不是，我信任这可能最早源自施乐。我实习的第一家公司叫 UpThere，也是这么做的。这早就有了，只是目前更常见，它算是研究型公司的一个传统。

Lenny Rachitsky:

清楚，所以它源于研究界。但我觉得这可能是一个方向的信号——大家干脆都叫 technical staff，你的职能不固定，不再被归进 PM 组、工程组或设计组。你觉得长期我们都会走向这里吗？还是职能会继续存在，仍有 PM、工程、设计各自的技能组，人们说“我是设计师”？还是像有人所说的“builder”，会出现一切人做一切事的坍塌？

Andrew Ambrosino:

有些事我是害怕的。有些公司喜爱很极端地跟风别人预测会发生的事。撤销“角色”这个概念的一部分危险在于，它可能危险地抹掉这样一个认知：这些是有门道、有可知最佳实践的专业。我听到不少公司说“我们要撤销产品岗”，我觉得这是个糟糕的主意——大家都变成 builder，结果产品这门积累起来的学科、那些真实的最佳实践、试过又失败的东西、真实的流程，就由于“我写了点代码”而被抛弃了，这不是个好地方。

“这不是你的赛道”这类边界消失，我是欢迎的，但这里有个平衡：不是所有人都能什么都做，无论从广度还是深度。这也是管理者不会消失的缘由。而且每个学科都有技能成分——许多工程师就犯了这个错，不承认工程本身是门技能之外，别的岗位也是技能，觉得别人只是在“vibing”，实则不是这么回事。你会用 Excel，但你不能因此就进财务团队，就是这类事。

Lenny Rachitsky:

我觉得还有一点是，你想不想做这个活儿。

Andrew Ambrosino:

我更想说的是，目前换角色更容易了，学最佳实践更容易了，也更容易不把你在某个岗位的胜任度和会不会用某个具体工具绑在一起。更多是看你能不能进入那种心态、搞清楚哪些有效哪些没用，然后专注在上面。我曾经很长时间觉得自己不该当软件工程师，由于我不在乎汇编语言，也不想背 TypeScript 语法。这些岗位里一直有一种守门：认为“擅长这个岗位就是擅长这个工具”。我觉得这正在开始瓦解，只是人们把这一切都夸大了。

00:27:22

Lenny Rachitsky:

你们 Codex 团队目前是什么构成？有多少工程师、设计师、PM？

Andrew Ambrosino:

每次有人问我 Codex 团队有多少人，我都说介于十人到几千人之间。这听着像敷衍，但也是真的——由于我们把它看成这里所有人工作的组合：模型研究、模型如何擅长代码和浏览器使用、模型个性、所有产品打磨、前端基础设施、所有用户相关的东西，全都汇入这个产品。但与此同时，我们也不是每天接受成千上万人任意提交的 PR。

所以核心团队是两位数的工程师，设计大约是它的一半，还有少数产品人——不过这里的产品更像是一种“区域联防”打法。桌面这边所有人有一个很普遍的共性，就是能动性（agency）和品味（taste），许多是前创始人，或者在大公司做过创始人式工作的人，品味都极强。在 OpenAI 我们允许团队做得很大，并不是说没有管理，而是团队规模挺大、以 IC（个人贡献者）为主，我觉得这是好事。

Lenny Rachitsky:

你用了“区域联防”来形容产品工作，这挺有意思，也和设计的转变相呼应——你在那儿更多是协调管理。能多讲讲产品人的“区域联防”是什么样吗？

Andrew Ambrosino:

我和 Alexander 就这个类比聊过许多。如果两个产品人靠得太近，往往不是好信号。作为一个产品组，你想做一种“力导向式”的活动，去找空白在哪。尤其在这个新世界里，策展、掌舵、对齐特别重大——到处是混乱，大家四处抛想法，那套自上而下、一年计划的做法行不通了。

所以目前需要品味制定者从萌芽阶段就引导产品该是什么样，这意味着你要做到“公司级覆盖”：大家散开，判断谁最擅长什么，彼此拉开空间以实现全覆盖，然后填补空白。同时我们想招有产品思维的工程师，不想变成一堆人写代码、还需要全团队审查产品连贯性；我们希望人人都有这些技能，但大家往深里钻的方向必须变。

Lenny Rachitsky:

这绝对是我和你这样的人聊天时反复注意到的一条线索：目前最有价值的人之一，是能把一个想法从 idea 做到 done、有品味知道“这很棒”、一路陪它跑完执行并做到出彩的人——就是你描述的这种高能动性、高品味的人。这是不是你思考“我们要招谁、谁会在这个新世界做得很好”的方式？

Andrew Ambrosino:

是的，这就是目前的核心。它也呼应了我对 IC 与管理的见解：不是管理要消失，也不是人人都成 IC，而是目前人人都兼具两者。如果你是 IC，你不再逐字敲代码，而是在管理某个东西——管理 agents，管理正在发生、并汇聚成某件事的工作；如果你是团队管理者，你做的是同样的事，只是粒度不同。

我招人看重的，显然是对领域的掌控，但更看重品味——由于你会有无限的 token，我们不能就这么产出 slop（垃圾内容），你得能在一个内容无限的世界里判断什么是信号、什么是噪声。

00:31:41

Lenny Rachitsky:

目前东西迭代得太快，做路线图规划变得超级难，我想在你的领域尤其如此。那你们团队怎么规划？会往前看多远？规划的产出是什么样的，是个电子表格，还是一个 md 文件？

Andrew Ambrosino:

大家一直对我在这件事上很不满。我们在规划上没做什么革命性或机智的事。基本思路是：越短期的东西越需要细节，我们不是不为九个月后做规划，而是那必须保持超级模糊——由于你目前给九个月的计划加上任何精度，都是虚假精度，只会浪费时间。

研究那边不一样，我不代表研究，但在应用产品这边，你在11月能规划的任何东西，对12月可能还成立，但那不是实际发生的。所以规划真的很难。我们大体上需要知道：我们认为模型在什么时间线上能做到什么。

我上一家公司经历过这种转变——我们开始用模型来驱动功能，原来的产品流程就崩了。基本上变成：把接下来一两年我们感兴趣做的所有事情都列出来，全部做原型，判断哪些目前就绪了，其余的就让它们放着慢慢酝酿。每次模型有新的飞跃，就把模型换掉再试一次那个功能。由于功能好不好，本质上取决于模型够不够机智——取决于它们的形态。

关于 Codex app 有个很好的故事。我超级确信，我们2月发布的这个 Codex app，如果在11月就做好发布，它在市场上绝对会失败。唯一的差别就是11月到2月之间的模型。同样形态的产品，仅仅由于几个月的时机差异，结果就完全不同。

00:34:04

Lenny Rachitsky:

你在播客里说过一条线索：构建那些目前还不work、但模型变好后就能work 的东西。还有另一条关于野心的线索：对你要做的事情更有野心。所以这就是你的方法吗——先建一堆目前可能还不work 的东西放着，等模型追上来？

Andrew Ambrosino:

对，我们有许多这样的东西。挑战在于你得超级清楚它处在设计流程的哪个阶段。人们还有那种肌肉记忆：哦，我为这东西写了代码，所以我们应该把它发出去。不，不对，那只意味着你目前有了一个可以对未来模型做测试的 artifact。

列如我们 app 里的 InApp browser 就是这样，我们有过一个大致能用的版本。往回看 Atlas，我们在 Atlas 里让 agent 跑起来了，挺酷的。再往前是 ChatGPT 里的 Operator，那个没成，但主意很酷。Operator、Atlas、Codex、ChatGPT，本质上是同一个功能，但用不同的智能水平重新发布，结果就完全不同。所以我推动大家别固执地认为“这不work，所以是个烂功能”，不，它可能只是还没到时候。

还有一点，尤其在研究界，总有一种冲动想做最有野心的事，说“好，但在极限情况下，模型就能做到这个”——这在产品侧就是行不通。

回到最初的 Codex 发布，基本上就是 Codex Web，它并不适合交互。你给模型一个任务，它就跑去把任务做完再回来找你。听起来没那么激进，问题是它任务做得不够好——它写代码，写得不错，但那个形态太早了。然后 Claude Code 出来，完全本地、不接云端，它没那么 AGI pilled，它会问你问题、会停在那儿等你，你没法把整个人生都甩给它。这反而好用得多，由于那才是当时模型所处的水平。所以我们对那个时刻来说太 AGI pilled 了。

我常常想这个教训。以前是进入市场会告知你产品形态、产品传达的一切；而目前，你可能需要把同一个东西发布六次它才work，而形态可能压根没变。

Lenny Rachitsky:

听你讲目前做产品要思考这么多变量真有意思：模型和研究的时间线、它会变多机智；人们能不能理解“原来可以在云端构建软件、这就是未来”、让人们为新功能做好准备；还有你作为一个团队能建出什么。我很喜爱那个 Codex 的例子，它回到野心这个话题——想听听你对“更有野心”这条线索有什么见解，由于这些模型能做的远超我们想象。有时候又对市场太超前，人们还没准备好。你会去推动团队更有野心吗？由于目前做那些过去觉得难到发疯的事情，容易太多了。

Andrew Ambrosino:

这是个核心挑战。一旦一个产品或功能存在了，人们很容易去找小毛病、做微优化，他们也应该这么做，Twitter 上的人喜爱提醒我们这一点，我也很感谢他们。大家的确应该聚焦在现有功能上，让它们更可靠、更好。

但这也正是我们这里有一种自下而上探索文化的缘由。就像 Codex app 出来后在某种程度上颠覆了 ChatGPT 一样，这个东西未来也会被新的努力颠覆，这是设计的一部分。由于一个团队没法同时既擅长颠覆，又擅长维护产品和它的质量。到某个点上，关键是设计一个能兼顾两者的流程。

00:39:18

Lenny Rachitsky:

稍微拉远一点看。回顾 AI 影响我们做产品的整个进程，简直疯狂——从你说的过去全靠手工、像手工艺一样创作的人类代码，到 AI 写100%的代码，再到你说的目前“编程就是引导 AI”。当你想“我的代码多少是 AI 写的”，几乎就等于“我得引导它多少次往正确方向走”。目前有了 agent、loop 这些东西，你看到的最新前沿是什么？那些最 AI-forward 的团队目前是怎么运作的，可能是大家还不知道的？

Andrew Ambrosino:

loop 都是上周的老黄历了，兄弟。我们聊过——一个大问题总是“产品有多少是 AI 写的”，这问题很难回答，由于如果你用去年的球门来衡量，那目前我们产品100%都是 AI 写的代码。所以问题更像是：这代码是有监督写的还是无监督写的，这就完全是另一回事了。我欢迎球门被移动，由于那意味着我们在取得产品进展。

这里有许多探索，围绕自主开发软件、大量 harness 工程之类的不同方向。我会想，列如如果它隔夜进来给代码库做一次垃圾回收、把它清理干净会怎样。有一件所有模型目前都受困的事：它们一般会增加复杂度。任何公司的研究者要是在听，拜托让模型更擅长删代码。

当你想把开发完全交给自动驾驶时，这就成了问题，人的一侧和代码库一侧都是。列如功能请求：怎么教模型该建哪些功能、忽略哪些、把哪些归组并稍微重构，怎么教模型建立正确的抽象？这些都在变好。但我不认为我们已经到了那个地步——设一个 loop 说“改善这个 app”，让它去监听 Twitter、Slack、email。我们还没到那儿，但我们在努力让它成真。

Lenny Rachitsky:

你觉得我们会到那儿吗？会到那种只给一个目标——“赢”，就行了的地步吗？

Andrew Ambrosino:

或者目标是“赚钱，给我赚十亿美元”、“赢下市场”。我不知道，兄弟，我不做那种说“永远不”或“总是”的生意。

00:42:05

Lenny Rachitsky:

你作为产品负责人和工程负责人，是怎么在工作中使用 AI 的？有没有一些用法是大家可能没意识到可以这么用的？

Andrew Ambrosino:

我觉得我目前有全世界最好的工作。让它很有意思的一点是，我们开发最初的 Codex app 时，我个人的目标就是让它成为我用来写代码的那个工具。我当时想：我得让它擅长开发到我能用它来构建 Codex app 本身。而当时 Codex app 本身就是个开发工具。

我们做了个超快的 dogfooding 循环：我做不了某件事，就该修复它好让我能做；目前能做了，就能做更多事了。发布之后，下一个挑战是人们开始用它做不同形态的事，我得把它做大、招几个人来帮忙。所以我的角色和 app 的角色同时需要改变——我得做更多产品发现，找到能看到每个人在做什么、并纠正跑偏的循环。突然间，这就是我开始用 Codex app 做的事。我还是写代码，但我尽量把自己的用法跟我们要解决的问题对齐。目前我会用它建一个电子表格来做建模，或者对这个领域为下一版所投入的所有研究做内部的 deep research。

有一个发布，给 Codex 引入了 in-app browser、computer use 和 artifact 创建，那是我们的“Codex for (almost) everything”发布。大家都知道 vibe coding 这个词，我觉得那是我们第一个用 vibe coding 做的发布——我有个 notion doc 记录了所有要发生的事，我在从 slack 频道自动化 pull request、更新状态追踪器。这目前挺常见了，但当时我感觉自己在管理产品发布的最前沿。

简而言之，我用 Codex app 的方式基本就是：我的工作成长成了什么，我怎么让这东西能做我需要做的一切。我早上起来会看一份 daily brief，涵盖我所在的3000个 slack 频道里的所有东西——哪些需要我关注，然后我可以回消息说“给我五个问题，我来答”，就能这么做。

Lenny Rachitsky:

你是怎么设置这个的？别人要设置这个的工作流是什么样的？听起来太棒了。

Andrew Ambrosino:

这方面我们还在发现阶段。目前就是我做一个自动化，或者一个定时任务，让它过一遍我的 slack 频道，告知它这些是我在乎、认为最重大的东西。我还在定义这些——不同类别要注意什么，给它一些 context，然后把它设成一个自动化任务。头几次运行可能需要一些引导。好在有了这个 app，我不用去搞清楚怎么编辑指令，我可以直接说“下次运行时，你能不能改成关注这个”，或者“能不能淡化这个工作流”，或者“这件事发生了却没出目前 brief 里，你能不能确保这类东西被涵盖进去”。我可以一路指导它，它会更新通知我的方式之类的。

我觉得未来——这一直是 chatbot 的一个核心问题——我知道怎么设置，也有时间设置，由于对我来说设置它本身就是产品发现。但如果你不在 OpenAI 工作、不开发这个，你不会想去搞懂所有这些东西。我们得把那种形态搞清楚。

Lenny Rachitsky:

我听到的是，大家可能没意识到你们的 app 能表现得很像 OpenClaw。人们当时特别兴奋的就是——你就跟它说话，设个东西，让它每天帮我查这个、然后告知我情况怎么样。这正开始成为所有这些产品的一部分，太棒了。所以别人设置的方式就是：直接在 app 里说话，说“我想设一个自动化来做这个，看我的 slack，这些是我想要的东西”？

Andrew Ambrosino:

对，没错。app 会帮你设好。如果它没有 Slack connector，它会说不行，要不要加 Slack connector，你选 yes 就行。至少我们能做到的是：如果你不知道怎么在 app 里做某件事，你可以直接问它。我不认为这就够了，但我觉得这是我们至少能做到的。

00:46:52

Lenny Rachitsky:

举个好例子，我用 Codex 做了一个过滤垃圾邮件的小应用。每封邮件进来，它都会判断这是不是那种我不想看的、主动推销式的冷邮件，然后打上标签放到别处。

设置过程中有一步是要进 Google Cloud Console，配一堆 Pub/Sub 的 API 和触发器。不知道你有没有用过那个界面，特别烦人又吓人。我就想，要不我让 Codex 来做？它说没问题，然后就像你说的那样开始 computer use——我从没在自己电脑上见过这种场景，它直接接管了我的电脑，开始操作。

Andrew Ambrosino:

它就像是说，我不管你有没有 connector，我直接开始点。

Lenny Rachitsky:

对，然后它自己就摸索出来了。看着它做这些事，真的太疯狂了。

Andrew Ambrosino:

设计 connectors、in-app browser、Chrome extension、computer use 之间的决策边界——什么时候用哪个——很有意思，而且全都是靠摸索出来的。

这些个人工作流特别有意思，有些真的很戳中人。大家都在尝试各种东西，每个人都搭建自己的一套系统，你问这里每个人他们怎么用，答案可能都不一样。然后某些主题会浮现出来，我们就会觉得，这个东西应该做成 app 里的一等公民，把大家似乎都在搭建的东西直接做好。

我觉得 memory 大致就是这种形态。我们和许多公司的人都遇到过，有人搭一个 Obsidian 或 Notion 空间，告知它怎么帮我搭建“记忆宫殿”、怎么归置——你不应该需要自己做这些，应该有个 memory 功能替你完成，对吧？这个比较通用。但也有别的东西，列如你工作的具体流程，那种就该你自己去配置。所以我们一直在权衡：什么对个人有用、什么该进入产品，什么只是“这就是你干活的方式”而已。

制作人:

什么该成为 primitive，什么不该。

Lenny Rachitsky:

这就是你前面说的品味和判断力，在决定这些事。

00:49:10

我想聊聊 browser use 这部分，由于我觉得大家还没意识到它有多强劲、能用来做什么。这让我想起 Dan Shipper 上节目时的一个预测——我们会开始用 Codex 来运行 SaaS 应用，不用再进 Chrome。他每天都在 Slack 上问我要各种东西，哈哈。你觉得事情会往这个方向走吗？我们直接在 Codex app 里用 Notion、Linear、Salesforce，让 agent 一路辅助你？还是说你觉得是另一个方向？

Andrew Ambrosino:

这个挺有意思，由于我们显然在浏览器这类形态上做过好几次尝试：Operator、ChatGPT agent mode、Atlas，目前又有了桌面应用里的 in-app browser，还有让 app 连接 Chrome 的扩展。做了这么多形态，我们学到了许多。

其中有许多很枯燥的因素。我们最初发布的 app 是 Electron app，里面 in-app browser 能做的事情有点糙，它当时是为开发用的、为测试前端用的，我们就说这只是个开发者工具。后来我们切换到了支撑 Atlas 浏览器的 OWL stack，目前它支持多标签页，还有企业级安全，你可以真正登录你所有的网站。我们一直在迭代这个东西。

一直以来最难的问题是：这个浏览器应该是什么形态？它是只给 agent 用的吗？你有 Chrome，就在 Chrome 里做你的事；当你让桌面 app 做事时，它会打开一个能被它快速控制的浏览器，没有 Playwright 那种延迟。还是说我们想让这个 app 做所有事、想让你把它当浏览器用？这些各有许多取舍，而且不是一条被走熟的路。

制作人:

大多数浏览器最顶层都是浏览器本身。

Andrew Ambrosino:

有浏览器标签页。这就带来一堆很枯燥但很繁琐的问题，列如键盘快捷键。我们是要把键位映射到 VS Code、还是 Chrome、还是我们自己的体系、还是 Linear？我们想保留某种能延续过来的肌肉记忆，但市面上已经出了这么多不同产品的子形态，我们该怎么做？

Lenny Rachitsky:

这恰恰凸显了这个 app 格外有挑战，你得让它既能服务从没建过任何东西的人……

Andrew Ambrosino:

……也能服务像 Peter Thiel 那样的高级用户。我很想让 Peter Thiel 用它来写代码，不过我不太确定能不能让他用上这个 app，我觉得他可能是最后一个坚持用终端的人。但我会一直努力。

00:52:05

Lenny Rachitsky:

我会继续努力。让我拉高视角谈谈大局——综合这一切，Codex 的愿景是什么？它会走向哪里？一两年、甚至十年后会是什么样子？

Andrew Ambrosino:

我们最初有 Codex 的 CLI，然后决定做这个 app。我们对 app 有点不确定，但对 Codex 作为开发者工具很有信念。它不会是个 IDE，而是一个尺寸合适的界面——有点像聊天机器人，但又不止于此，你能看到代码，但我们不打算让你编辑代码。

在 OpenAI，一二月份发生了一件很有意思的事，那是我们真正发布 Codex app 之前。我们开始在内部 dogfood，发现工程和研究工作流上出现了相当明显的内部 PMF，大家超级喜爱。我们就想，只要把质量门槛提上去就能发布了。

但在公司里，我们还开了几个别的工作流，发现来自市场、公关、财务、法务，基本各个部门的人都在用这个 Codex app——尽管它对这些人充满敌意：它会给他们看代码，会请求批准去运行 rg 命令，做的全是对他们来说不对的产品动作。

于是我们想，那就把 Codex 加到别的界面上吧——加到 ChatGPT 桌面应用，加到 Atlas 浏览器，把 Codex 的经验推广成通用的知识工作工具。这些努力推进了一阵，然后最烦人的问题出现了：没人愿意离开 Codex app，去用那些号称是为这些角色做的 app。

我觉得这里的教训是，开发者工具和通用知识工作工具之间有许多细微差别，不是非此即彼。做 Excel 工作的人不想看到 Git 仓库信息，这我们知道；但我们也知道，从他们做的事情能看出许多他们做什么工作。我们可以从简单开始，觉得需要时再让产品变复杂。这不代表我们没有模式——你可能想要一些模式来组织你的东西、让你进入体验的方式更清晰。

但我们超级坚信，我们做出来的这个形态，很适合承载真正深入的垂直领域工作。我们和财务团队、做科学的团队、法务团队都深度合作。我们的想法是：如果能搭好正确的可扩展性 primitives 和正确的通用模型，你就能用它做任何事。那我们的挑战就是，怎么把它通用化。这又回到了那个问题：我们能做出的最好的桌面应用是什么样？我们就是这么思考的。

Lenny Rachitsky:

你说的这点特别有意思——Codex app 做得太好了，你们让大家意识到它的存在、又好用又有趣，结果所有人都开始用它，而不是 ChatGPT。所以方向显然是把它们合并，这样就不会造成混淆。大家也一直在讨论把它们合到一起这个想法。

Andrew Ambrosino:

有人管它叫 super app，我们很郁闷，由于目前我天天都得听到“super app”这个词。

Lenny Rachitsky:

好吧，我们不叫它 super app，但那个理念就是——一个让大家去做所有事情的地方。是这个大致意思吗？

Andrew Ambrosino:

对，我们看到的是，它是个很好的 home base，一个能跨不同界面追踪你要做的所有事情的地方。有些事你完全在 app 里做，有些事 app 会打开其他 app 来做。

app 可以连接 Excel，所以它的确内置了一个电子表格编辑器。但这对在 OpenAI 做融资几十亿美元的财务建模的人够用吗？大致不够。所以 app 会直接跟你桌面上 Microsoft Excel 里的 add-in 通信，做完之后你就能关掉 Excel 了。

所以这不只是“我们在屏幕上画个矩形，一切都得发生在这个矩形里”。它应该是你的一个家，你在这里开始工作、结束工作、把工作自动化，它会调用你需要的任何东西。

有个很棒的故事：我们为 Codex app 的首发在这个房间里拍了些视频，我们内部的 DX 视频制作者 Brent 负责剪辑这些视频。他就用 Codex 剪完了所有视频，这是早期“大家拿这东西在做什么”的例子之一。他开始用 Codex 的过程很有意思——他纯粹是好奇 Codex 能不能剪视频。

Codex 本身不算视频编辑器，里面没有那种 UI，但它理解他用的是 Premiere Pro，能通过编辑 Premiere Pro 屏幕背后的那些文件来做一些剪辑，只是做不了全部。于是很自然地，Codex 接着给自己造了一个能装进 Premiere Pro 的扩展，然后跟它通信：嘿 Premiere Pro 扩展，能帮我改一下 Premiere Pro 里的这个标记点吗？我们看到这一幕的时候，觉得挺疯狂的。

这是个很棒的模型。存在这些专门做某件事的专业工具，所以我们在 Codex、目前也在 ChatGPT 上，同时想做两件事。一是怎么无缝地跟你已经在用的工具交互——我们不需要给你造个更好的视频编辑器，但 Codex 和 ChatGPT 可以用那个视频编辑器，可以跟它交互、把任务交接给它，这往往是通过 connectors、computer use，甚至像这个例子里的 extensions。

另一件就是 Dan Shipper 说的：我有这些能点来点去用的 web app，我想把它们打开在 Codex 里，让 Codex 帮我做额外的事。所以这是两个几乎互为逆向的模型，我们两边都在大力投入。

Lenny Rachitsky:

这个 Premiere 的故事对我很有启发，由于它又是一个例子，说明我们对这些 AI 任务应该更有野心。你可能不知道，也许它们能做成这件事——几乎就是去试试看，看它能不能自己搞定。

00:59:31

我要带我们进入播客的一个固定环节，我管它叫 Fail Corner（失败角）。问题是这样的：大家看到你这样的人一路高歌猛进、样样都赢，Codex 表现这么好，职业生涯一路向上。但人们看不到那些没成功的时候、你推出的那些失败的东西。这些故事对听众真的很重大——不是一直都在赢。你职业生涯中有没有一个失败、并从中学到重大东西的故事？

Andrew Ambrosino:

听到你这么描述我，挺好笑的，由于这大致是我第一次觉得自己没在失败。我当了很久的创业公司创始人，最后基本是把公司拆开卖了。那是好几年的苦熬，都是重度监管的领域，整件事都感觉像是持续的失败。后来我去了另一家创业公司，想做一些 AI 工具，也是相当封闭的监管行业，那也是一次又一次尝试却不成功。

所以对我来说，我实则失败了相当多次。有时候只是时间点凑上了——技能和市场的拐点对齐了。

就说这个把 Codex app 的经验和 ChatGPT 结合的项目吧，上面不知道有多少次微小的失败。我们觉得“就该长这个样子”，然后扔到 Slack 里，就冒出一个 2000 条消息的线程，说我们有多蠢。这正是我爱 OpenAI 的地方——大家会直接这么告知你，内部产品失败时毫不留情。外部产品之所以做得还不错，恰恰是由于它经历了这些 2000 条“这烂透了”的循环。

在走到这一步之前，我大致失败了 10 到 15 年。所以我每天都还很惊讶事情进展顺利。我觉得这一点对大家来说真的很重大。

Lenny Rachitsky:

可以有许多事情不成，然后事情又突然开始变得特别顺。就继续走下去、继续学习——我想这就是那个教训。

01:01:48

好，接下来是激动人心的闪电轮，我有5个问题。第一个：有哪两三本书是你常常推荐给别人的？

Andrew Ambrosino:

我目前是幼儿的父亲，所以推荐的都是那种绘本。有一本叫《咕噜牛》（Gruffalo）。

Lenny Rachitsky:

天哪，我家孩子最近就迷上了咕噜牛，睡前流程里都有它。

Andrew Ambrosino:

咕噜牛实则还不错，里面有些道理。不过我最喜爱的一本是很老的书，叫《Big Orange Splot》之类的，值得一看。如果你讨厌业主委员会（HOA），必定去看。讲的是一个叫 Plumbean 先生的人，住在一条家家户户长得一模一样、超级整齐的街上。有一天一只鸟把一大罐橙色油漆掉在他家房子上，他就想“管它呢，我要豁出去了”。于是他去店里买了油漆、吊床、鳄鱼，把整栋房子彻底重做。

邻居们群情激愤——业主委员会、房产价值什么的。这书实则不是讲HOA的，但我是坚定的反HOA人士。然后邻居们一个个去找他，喝他所谓的“柠檬水”，那是一种很有说服力的柠檬水，由于他们一个接一个也开始改造自己的房子，有人还把房子改成了船的样子。我觉得那些胆小怕事的人尤其该读读这本书。

Lenny Rachitsky:

我从中听到的是 agency（能动性）。

Andrew Ambrosino:

没错，你可以just do things（你就是可以去做事情）。

Lenny Rachitsky:

太棒了。下一个：最近有没有特别喜爱的电影或剧？

Andrew Ambrosino:

《神奇校车》回归了，Netflix上的新动画版，Kate McKinnon配音——目前 Frizzle 老师升成了 Frizzle 教授，还在，但不再是主角，Kate McKinnon 演的才是主角 Frizzle 老师。我一直喜爱神奇校车。我个人没时间看电影，所以就一集接一集地看那种一小时长的剧集，停不下来。

Lenny Rachitsky:

最近发现的特别喜爱的产品呢？

Andrew Ambrosino:

我感觉每天都在重新发现我们自己的产品。在这之前，Linear 是我最喜爱的软件产品，它做得超级好。

Lenny Rachitsky:

那你有没有常常回想的人生格言？

Andrew Ambrosino:

我总想问身边的同事这个问题，由于我觉得自己不是个格言型的人，结果别人却总能说出我常挂嘴边的话。

Lenny Rachitsky:

我懂。最后一个问题：你当过PM、设计师、工程师，这三个角色哪个最难？

Andrew Ambrosino:

这三者超级不同，让一个人觉得难的地方，对另一个人可能很轻松。关于这个“铁三角”有太多说法了——设计师完了吗？该学写代码吗？PM完蛋了吗？还需要工程师吗，还是PM会把代码都写了？或者设计师目前也当PM？大家都要完蛋，可大家又都要王者归来。