夜雨聆风
来源：Lenny's Podcast，嘉宾是 Andrew Ambrosino，OpenAI Codex 应用的产品与工程负责人。他的履历很特别：设计师出身，转去做工程，又做产品经理，还当过创业公司创始人。
「OpenAI 内部，90% 的人都在用 Codex。」
访谈一开场，主持人 Lenny 就把这个数字摆了出来。然后他强调了一句：不是 90% 的工程师，是整个公司的 90%。
Andrew 是 OpenAI Codex 应用的产品和工程负责人。今年 1 月到现在，Codex 的用量涨了 6 倍，周活用户超过 500 万。Andrew 自己补了一句：这数字很快就会过时。公司内部，几乎 100% 的员工每周都在用 Codex，而且远不止工程师。
但真正让我感兴趣的，是 Andrew 对「产品到底该怎么做」的判断，整个倒了过来。
「实现，已经几乎不要钱了。」他说，「现在真正稀缺的，说出来你可能不信，是品味。」
这是什么概念？过去几十年，所有做产品的人都默认一件事：写代码很贵，所以要在动手之前，用文档、调研、原型把风险降到最低。Andrew 说，这套逻辑现在彻底反了。
下面是完整对话。
/01/ 「90% 是整个公司」：一个被所有人打开的 App
Lenny：你前几天发推说，你想把 Codex 做成史上最好的桌面应用。
Andrew：对。Codex 的质量门槛必须高到这种程度：你想做下一件事的时候，打开它是你天然的选择，中间不会有一丝犹豫。就像大家已经习惯了打开一个浏览器标签页那样。
Lenny：我看到关于你们用量破纪录的数字一直在往外冒。
Andrew：我也不知道，走着瞧吧。挺多人好像挺喜欢这个 app 的。
Lenny：我们聊之前，我问你最希望大家从这场对话里带走什么，你说是「AI 正在怎样改变产品工作的形状」。你在的，可能是全世界最前沿的 AI 软件团队，所以你看待事情走向的视角很特别。跟几年前比，现在一个产品团队的形状，是什么样的？
Andrew：现在作为一个做这些产品的负责人，最难的一件事，是流程在我脑子里整个被倒了过来。很多人都聊过这一点：现在任何人都能做出任何东西。你跟这些模型对话，我们的也好，别人家的也好，从零开始，你想要什么功能都能立起来。这本身不是软件里难的部分，但它真的很酷。
于是就出现了一种局面：所有人都在做所有东西。你给大家无限的 token，OpenAI 的每个人又都极有行动力、点子又多，结果就是人人都在造东西。
而你回头看我们跑了这么多年的产品流程，方向其实是反的。它大概是：调研、想点子、可能做点原型。哪怕过了瀑布流时代，那套流程骨子里还是假设「实现很贵」。所以你想做的，是在动手之前，用文档、用调研、用原型，把所有实现风险都提前降掉，因为原型和设计便宜。
这一点，现在彻底变了。此时此刻，对于某个我们急需要做的功能，我敢说同时有 90 个互不协调的团队，在各自实现、各自尝试。
说白了，整件事是反过来的。变的其实只是顺序。大家的岗位没换，技能也没消失，岗位也没凭空蒸发。实现，已经不是最贵的那一环。最贵的，甚至可以说，是品味。 是那个「策展」的过程：这 90 个尝试里，哪些是好的？哪些该并到别的地方去？该怎么框定它？要不要做成另一个功能的一部分？那个切换里到底该放几档？这些，才是现在要花心思的地方。
/02/ 90 个原型同时在跑，「PRD 已死」？他第一个不同意
Lenny：「品味」这个词太热了，我们一会儿再回来聊。先说这个 90 个原型的事。我理解一下：OpenAI 内部飘着一个想法，过去大家会写文档，说我们要做什么、什么功能、什么策略。今天你描述的是，公司里很多人有类似的想法，现在不写文档了，各自做个小原型，于是冒出 90 个不同的东西，大家看一圈，挑一个方向。是这个意思吗？
Andrew：这种事很多，而且不只我们这儿。你看到很多产品负责人都在说「PRD 已死，原型当道」。但我其实完全不信这套。
现在有意思的一点是：因为在每一种媒介上，实现都变得太便宜了，直接跳到做原型的诱惑非常大，尤其当你不是工程师。你可能从来没写过代码，或者没兴趣、没时间。这时候你特别容易说：PRD 已死，我直接做给你看。
但我也注意到，对工程师来说，另一个诱惑是写一大堆文档，一大堆根本不值得读的文档。我不是在嘲笑写文档的人。我的意思是，当实现变得唾手可得，为你想表达的那个点选对格式，就变得特别重要。如果你想表达的是「在一个模糊地带把产品想清楚」，那它可能真该是一份文档。如果你想做的是「把东西塞到别人手里去试，去压测一种交互」，那它就该是个原型。现在好玩的地方就在这儿：选对媒介，特别重要。
Lenny：有个播客嘉宾分享过一个词，我每次想到这个就会冒出来，叫「原初的那一笔」（primal mark）。一个设计师、画家、艺术家在画布上落下的第一笔，那一笔，就是你之后开始回应的对象。后面的一切，都从这第一笔往下淌。我听你的意思是：有时候原型是错的第一笔，因为你接下来只会去回应这个原型，而不去回应一个不同的、更大的想法。所以你是说，文档和评审在特定场景下，依然有用。
Andrew：对。而且过去那个世界里，媒介本身就内置了大量信号，告诉你这个东西现在走到流程的哪一步了。你看到一个像是已经在线上跑的产品，就意味着它处在流程后段，意味着假设已经被验证、设计已经看过、商业目标也成立。可现在，这些东西被拆开了，彼此脱钩了。
之所以以前是那样，是因为在东西被妥善验证之前，你很难拿到资源去把它造出来。现在这个前提，被直接扔出窗外了。所以特别重要的一件事，是开始明说：我们可以有原型、可以有文档，但我们对「这玩意儿到底在干嘛」，清不清楚？因为你绝不想过度锚定在一个本来只是探索、却看起来已经能上线的东西上。它看着太「能发布」了，可它根本不是研究真正要去的方向，也不是用户在要的东西，也不一定对生意有利。
我不想把品味这事讲过头，可还是绕回来了：是那个品味，让你知道该做什么、该怎么呈现这些信息、该用什么媒介去达成目标。这件事，正在变成最重要的事。每个领域都一样。
/03/ 到底什么是「品味」？保罗·格雷厄姆穿着大裤衩
Lenny：当你说「好品味」的时候，它到底指什么？是你刚才说的「决定我们要投入做哪件事」？还是当你已经有了个东西，去判断「这个对不对、是不是该发」？大家一听这个词就觉得，哦我有品味，我知道。可它具体长什么样？
Andrew：有意思。我太上网了。昨天好像有条推，是 Linear 的产品负责人发的，我可能记错了，先跟当事人道个歉。他说大家太过强调「品味」里审美的那一面，还拿保罗·格雷厄姆当例子：他说格雷厄姆显然品味极好，可人家天天穿大裤衩。所以我们得把「品味」到底是什么，稍微掰开一点。
这里面很有讲究。我觉得你刚说的几样，全都算。它有审美的一面，但也有一个「系统思维」的一面：这东西怎么嵌进整个系统里？还有一个「方向」的一面：我们要去哪儿、这属于哪个主题？还有「怎么呈现」。很多时候，品味是更宽的上下文。当然也有那种很具体的：这个交互动画跟它本该传达的语义不搭，太「脆」了，配不上它真正想表达的意思。这一点极重要，我可能在这上面花了过多的心思。
但真正算得上品味的那个问题，是：如果我们什么都能造出来，那这东西到底该是什么？我们要怎么走到那儿？我觉得这才是品味真正要问的。
/04/ 为什么顶级模型，设计还是这么烂？
Lenny：每次听到这种话，我都会想：AI 越来越强、做的事越来越多，人脑还能在哪儿继续值钱？感觉「品味」是其中一块。沿着这条线我还想到一件事：AI 现在做实际设计，还是很差。它的产出不怎么样，很少有那种「就是它了，绝杀」的时刻。永远是「哦这是 Claude 风的设计」「这是 Codex 风的设计」。你觉得为什么今天顶级的前沿模型，就是不擅长设计？以后会到位吗？会不会有一天我们「我的天，搞定了」？
Andrew：我倾向于认为，有几个很实际的原因让它一直落后，也有几个更难啃的问题。我不在研究那块，估计说这话要挨骂。我觉得设计比软件更难「打分」。要建一个能训练模型的回路，告诉它什么是好设计、什么是坏设计，比「代码能不能编译、是不是按要求跑」要繁琐、要费劲得多。因为人的品味，本身就是你需要的那套反馈机制的一部分。
我还认为，实验室历来会优先把模型训得擅长那些能加速 AI 研究的事。在编程模型的早期，模型能写出正确的代码，会直接加速研究，这一点非常清楚。设计就很难讲出同样的故事。倒不是说把设计做好不重要，问题在于它没直接卡在那个飞轮里。这些是实际原因，以后都会消失，这些模型会变得相当擅长设计。
但还有一些更模糊的东西，会非常难搞。我列过一个小清单。
一个是，「好设计」里有一层文化的东西。你记得吧，大概去年，每个新出来的网站，都是 Linear 网站的翻版。Linear 的网站，设计很棒、品味很好。如果一个模型做出那个，我会惊呼「天哪这进步太大了」。可如果我有个模型每次都吐出 Linear 的网站，那这就不是我们要的挑战了。设计里，「新意」的分量，比软件工程里要重得多。软件工程你甚至希望它过度依赖已知的模式；设计正相反，这里头有一种随机性、有一种新意在。
还有一层，我在早期 Codex app 上花了大量时间写代码、或者说盯代码。哪怕模型设计变好了，软件设计和它写出来的代码之间，还有一层抽象。比如，屏幕这个角落里的这个东西，应该跟下面那个东西，在代码库里共享某某属性。这跟「模型得是个更好的设计师」是两码事。它表面是视觉问题，往里看要深得多，它关乎那些抽象。
举个例子，假如明天我们公司做了一次品牌重做。浅层版本是：我们得把 263 个组件一个一个更新一遍。深层版本是：这两个看起来不一样的东西，它们之间的语义是什么。它们其实都在列表里、都带着同一种样式、向用户传达同一种交互模式。我觉得这一层抽象，以今天的技术，还是有点够不着。
所以这一路走下来：我们 11 月开始做 Codex app，那会儿还没全职用它，现在什么都用它。这是一段过程。但现在，我们用它真正去做的那些事，又是另一批事了。
Lenny：那是个绝妙的回答。说到设计和创造力，Codex app 刚出来的时候，是个全新的东西，没人见过。它不是终端，不是 IDE。它是一个会写代码、还能看到代码的「聊天」东西。按你的逻辑，让 AI 自己提出「这是一种全新的写代码范式」会很难。这好像就是人脑暂时还值钱的地方：创造力，想出新东西，而不是把做过的模式再拼一遍。
Andrew：完全同意。来，为人脑鼓个掌，暂时的。
/05/ 「设计流程已死」，对，但也不对
Lenny：我们准备这场对谈的时候，你说你在听 Jenny 那期播客，她是 Claude Code 和 Cowork 的设计负责人。她有一整套论点：设计流程死了，没时间设计了，一切都动得太快，先做就完事，设计只是在过程中顺手把方向掰一掰。你好像有点不同看法。
Andrew：我和 Jenny 在很多点上其实是一致的。我对「设计流程」这套东西本来就没好感。我同意她的判断：它死了。而且在 AI 出现之前，我就不喜欢这套流程。
Lenny：能不能快速描述一下这个流程，方便大家理解？
Andrew：我好些年前在一家创业公司，我们会做设计招聘，当时有一篇挺刻薄的文章，讲什么「案例研究工厂」，是那个网红设计满天飞的年代的东西。意思是，设计师被教导要看重「流程」本身，看得比一切结果都重，甚至比结果还重。只要某个东西走完了这套流程，两件事就被认为成立：一，它会是好的，流程保证质量、保证影响力；二，就算你不喜欢、就算没人用，只要它走完了用户调研、发散、收敛这套流程，它就是好的。
这套框架，用户调研、发散、收敛，本身是对的，只是一直有点学院派。我觉得现在恰恰暴露了它崩盘的地方，尤其是因为实现速度太快了。这套流程的前提，是假设实现很贵、你基本只能造一次。所以你必须在动手之前，把问题空间和解空间穷尽地走一遍。
后来 Figma、Origami 这些工具出现，你可以把交互原型更早地拉进流程里，提前拿到一些洞见，模拟出接近线上的效果。当时甚至出现一个梗：高管们就说「我们能不能直接做个原型，然后指望它就能用」。但这件事是真的，它后来真的成了设计流程的一部分，我们把做原型纳进来了。
现在的问题是：你可以把全部的「实现」都拉进来。于是又出现了一堆假设上的错配。你看到一个抛光到位的原型，看起来已经能出门发布了，公司里足够多的人看到，就开始问「我们能不能现在就发」。但恰当的状态是：我们其实还在早期设计阶段，只是没人把这句话说出来。90 个人会有这个想法，它会看着很精致，可其实，这就是现在的设计流程。
把设计流程和媒介死死绑在一起，才是吓人的地方。设计师现在做这套流程的工具，反而更多了。你可以把东西放进现有产品里做 A/B 测试，或者就拿它当原型。现在很多公司都有那种「婴儿版产品」的概念，比如「婴儿版 cursor」。你在推特上见过，我们有「婴儿版 Codex」，一个被极度简化的代码库，近似复刻了线上 app 的所有交互，因此能很快地拿来氛围编程（vibe coding）。你可以试：要是侧边栏这么工作会怎样？要是来个面板、里头有个群聊会怎样？这是设计流程里特别好用的一个工具。
所以说「设计流程死了」，我觉得对也不对。如果你死守那套流程的工具、那套日复一日的具体规程，那它确实死了，你会很难受。可要把整套流程完全扔掉、连「我们现在处在流程哪一步」这层覆盖都扔掉，那层东西，比以往任何时候都更重要。
/06/ 角色正在融化：你是什么，取决于你时间花在哪
Lenny：你的背景很全。看你领英，工程师、设计师、产品经理、创始人都干过。现在你管桌面 app，设计是不是不在你手下？还是有个单独的设计团队？
Andrew：看是哪一周吧。
Lenny：行，挺好。
Andrew：我们合作得非常紧。我们信「坐在一起、彼此嵌进去」这一套。
Lenny：所以汇报线每周都在变。Codex 上的设计流程长什么样？
Andrew：关于「角色坍塌」「岗位彻底消失」这种话，外面写了很多。我们没看到那么夸张。但 Codex 这个组里，角色坍塌确实比公司其他部门、比经济里别的地方都更明显。一部分原因是，这本来就是个给工程师用的技术产品，所以我们的设计师会说工程师的语言，我们的产品经理懂技术、会写代码。Alexander 有计算机科学硕士学位，而我没有。
我们描述各组怎么协作的一种说法是：现在角色之间的重叠，比过去大得多。每个人不再由「设计到哪儿为止、工程从哪儿开始」那道篱笆来定义，而更多由他工作落点的「平均值」来定义。你把我们设计团队某个人做的所有事平均一下，里头有不少在写代码，也有不少是产品工作，但平均下来，他的点落在这一块。如果你画在图上，这也正好说明了流程。
尤其是，整个 Codex app 都是被「吃自己狗粮」这个回路塑造出来的。我们所有人都有一种欲望，就是尽量在 app 里把事情做完，哪怕它当下并不是最好的工具，这样它才能变成最好的工具。所以很多设计，是我们一边用这个 app、一边问「这儿哪里不对劲」做出来的。这是一件我们会刻意做的事：我们常常宁可不去改进自己的流程，为的是逼着自己把产品做得更好用。这是个让人极其不舒服的位置，但每周都在变。
Lenny：我太喜欢这个点了。你的角色，就是你时间花在哪儿的平均值。 如果你大部分活儿是产品工作，那好，你现在就是产品经理。如果是工程，那你现在就是工程师。
Andrew：对。
Lenny：是不是 OpenAI 第一个把人叫「member of technical staff（技术成员）」的？
Andrew：不是。我相信这个最早可能是施乐开始的。我实习的第一家公司，叫 Up There，也这么叫。这个叫法早就有了，只是现在常见多了。在以研究为重心的公司里，它算是个传统。
Lenny：明白了。它从研究里长出来，但我觉得它是个信号，预示着事情可能会往哪儿走：大家都叫「技术成员」，你的职能不固定，你不被塞进产品经理、设计或者工程那个格子里。你觉得我们长期都会走到那一步吗？还是说职能会继续存在，产品经理、工程、设计各自的技能组依然在，人们还会说「我是个设计师」？还是会像有人说的，所有人都变成「构建者」，一个所有人都干所有事的坍塌正在到来？
Andrew：有些东西是我害怕的。有些公司特别喜欢在「大家说会发生什么」这件事上走极端、抢着上车。消灭「角色」这个概念，危险之处在于：它可能会顺手消灭掉「这些是有门道、有可知最佳实践的专业」这个认知。
我听到不少公司说「我们要取消产品这个岗位」，顺便说，我觉得这是个糟糕透顶的主意，以后所有人都是「构建者」。然后会发生什么？产品这门已经建立起来、有真实最佳实践、有真实「试过且失败过」的经验的学科，就被丢掉了，因为大家想「哦，反正我写了点代码」。这可不是什么好地方。
「这不归你管」这种边界消失，我是欢迎的。但这里有个平衡：一个人没法把所有东西都干了，无论广度还是深度。这就是为什么管理者不会消失。而且每个学科都有技能的成分。很多工程师就犯这个毛病，不承认别的角色也有技能，觉得工程是写代码、是有技能的，别的角色不过是「在那儿瞎晃」。不是这么回事。是，你会用 Excel，但你没法进财务团队干活。就是这类事。
更要紧的变化是，现在换角色更容易了，学最佳实践更容易了，更容易不把你在一个角色里的有效性，跟「会不会用某个具体工具」绑死。我憋了好久，一直觉得自己不该当软件工程师，因为我不在乎汇编语言，也不想背 TypeScript 语法。这些角色里，一直有一种把门的东西，说「你在这个角色里行不行，就看你这个工具用得溜不溜」。而这个，正在开始瓦解。我只是觉得，大家把这一切都夸张化了。
/07/ Codex 团队有多少人？「10 到几千之间」
Lenny：你们 Codex 团队长什么样？多少工程师、设计师、产品经理？
Andrew：每次有人问我 Codex 团队有多少人，你还记得我的答案吗，我会说，介于 10 个人到几千人之间。这听着像个糊弄人的答案，但它是真的。因为我们把这个产品，看成这里所有人工作的总和：所有进到模型研究里的东西，所有让模型擅长计算机使用和浏览器操作的东西，模型的人格，所有围绕前端基础设施的产品工作，所有用户侧的东西，全都汇进了这一个产品。
但与此同时，我们也不是每天接受成千上万人提交的、想加什么就加什么的代码请求（PR）。所以具体的团队，是两位数的工程师，设计大概是这个数的一半，再加少数几个产品的人，产品更像是「区域联防」。Codex 这边、桌面端这边，所有人身上很常见的两样东西，是行动力和品味。很多人是前创始人，或者在大公司里干过「创始人形状」的活儿，很多人品味极好。在 OpenAI，我们让团队规模长得很大，没有「没有管理」这回事，但团队确实很大，绝大多数是个人贡献者（IC）。我觉得这样挺好。
Lenny：你用了「区域联防」这个词来形容产品工作，挺有意思，跟设计的转变也对得上：你在那儿主要是协调和统筹。具体讲讲，对一个做产品的人来说，「区域联防」长什么样？
Andrew：我和 Alexander 聊过很多次这个比喻。如果两个做产品的人靠得太近，那通常是个坏信号。作为产品的人，你反而想做一种「力导向」的动作，去找那些缝隙在哪。尤其在这个新世界里，策展、引导、对齐占了很大比重：到处是混乱，人人在四面八方乱抛点子。那种自上而下、规划一整年的玩法，行不通了。所以现在需要有品味的人，从一个想法萌芽起，就去引导它该长成什么产品。
这意味着你基本上要做「全公司覆盖」。你摊开，问：谁最擅长什么？我们之间留出点空间，好让整体没有死角。然后你去补缝隙。我们想招的是有产品脑子的工程师，我们不希望出现一堆人写一堆代码，然后还得整个团队去审它「产品上是否自洽」。我们希望人人都有这些技能，但人们往哪儿钻得深，必须变。
Lenny：跟很多像你这样的人聊下来，我一遍遍注意到一条线：当下最值钱的人之一，是那种能把一个想法从「想法」一路带到「做完」、并且有品味知道「这东西很棒」的人。一路盯着，痴迷于把它做到牛。高行动力、高品味。是不是你们招人、你们判断「谁会在这个新世界里干得好」的方式？
Andrew：对，这就是当下最要命的那块。它也对应了我怎么看「个人贡献者 vs 管理者」：管理不会消失，也不是人人都成了个人贡献者。现在的情况是，每个人都两者兼具。如果你是个人贡献者，你不再一个字符一个字符地敲代码了，你在管理一个东西，管理一群智能体，管理正在发生、最终汇成某件事的工作。如果你是带团队的管理者，你做的是同一件事，只是颗粒度不同。我一般会找：对这门学科当然要有掌控力，但还要有品味去判断。你会有无限的 token，我们不能净产出垃圾，你得能分清什么是信号、什么是噪声，在一个内容无限的世界里。
/08/ 怎么做规划？9 个月后的事，必须留「模糊」
Lenny：你提到规划。在这种节奏下，做路线图变得特别难吧？
Andrew：尤其在我们这行。
Lenny：大家是不是经常因为这事对你很不满？
Andrew：经常。
Lenny：因为东西一直在发、一直在变。你们团队怎么规划？你会往前想多远？一份计划长什么样，是个表格，还是个 MD 文件？产出是什么？
Andrew：我觉得我们在这事上没什么革命性的做法，我们规划得并不聪明。基本的意思是：一件事越短期，它需要的细节越多。我们当然也为 9 个月后做规划，只是那份规划，必须保持非常模糊。因为现在你给一份 9 个月的计划添加的任何精度，都是假精度，你只是在浪费时间。话你是可以说的，但我们规划的东西，没一个最后是那样的。
研究那块不一样，我不替研究说话。但在应用这边、我们做产品的时候，任何你能在 11 月规划好的东西，可能在 12 月还成立，但根本不是后来真正发生的事。所以规划真的非常难。我们一般需要知道：我们觉得模型在什么时间线上能做到什么。
我上一家公司，我亲眼看到这个转变：我们开始让模型来主导功能，结果整套产品流程就崩了。它基本变成：把我们未来一两年里所有感兴趣做的事都列出来，全做成原型，判断哪些现在就能上，剩下的让它们搁着发酵；每次模型出现一次大跳跃，就把那个东西拿出来，换上新模型再试一遍。因为一个功能好不好，取决于模型够不够聪明，跟它的形状没关系。
这里有个关于 Codex app 的好故事。我非常确信，我们 2 月发布的那个 Codex app，如果它在 11 月就准备好了，在市场上一定会彻底失败。同一个 Codex，2 月发能火，11 月发会死， 唯一的差别，就是 11 月到 2 月之间的模型。同样形状的产品，仅仅因为差了几个月的时机，结果天差地别。
/09/ 「我们当时太 AGI 上头了」：提前造好，等模型追上来
Lenny：这档播客里一条反复出现的线是：去造那些现在还不灵、但模型变好之后就会灵的东西。还有一条线是「野心」，对你接的活儿，再大胆一点。这是不是你做事的方式：先造一堆现在可能还不灵的东西，放着，等模型追上来？
Andrew：对，我们有很多这种。挑战在于，你得反复说清楚：这东西现在处在设计流程的哪一步。大家还有那种肌肉记忆：哦我给这玩意儿写了代码，所以我们该把它发出去。不不不，那意思是你现在有了一个「制品」，可以拿它去测试未来的模型。
我们 app 里的内置浏览器就是这样。往回看，Atlas 里我们就让 agent 跑起来过，挺酷。再往前，ChatGPT 里有 Operator，那次没成，但想法很酷。从 Operator 到 Atlas 到 Codex 再到 ChatGPT，你能拉出一条线，说到底是同一个功能，但用不同的智能水平重新发一次，结果完全不同。所以我会推着大家别犯轴，别因为「现在不灵，所以是个烂功能」就否了它。它可能只是还没到时候。
尤其在研究里，总有一种「要做最有野心的那个」的冲动，会说「在极限处模型就能直接做到这个」。但在产品侧，这就是不灵。你回看最早的 Codex 发布，它当时叫 Codex web，并不适合跟它交互：你给模型一个任务，它跑去做、做完回来给你。听着不算激进，问题是它当时把任务做得没那么好。它写了代码，写得不错，但那个形态太早了。然后 Claude Code 出来，完全在本地，不联云，也不假装自己有多 AGI。它会问你问题、会停在那儿，你没法把整个人生都甩给它。那个反而好用得多，因为那才是当时模型所在的位置。说白了，我们当时对那个时刻，太 AGI 上头了。这个教训我常想。
以前是市场告诉你产品的形状、产品的沟通方式。现在不一样了，你可能得把同一个东西发布六次，它才灵，而那个形状可能根本没变过。
/10/ 「Loops 都是上礼拜的事了」：最前沿的团队怎么写代码
Lenny：缩放视角看，AI 影响我们怎么做产品的这条进展线，疯得离谱。从我们以前手写所有代码、像手工艺一样人肉敲，到 AI 写 100% 的代码，再到你说的，现在写代码是「在引导 AI」，你算「多少比例的代码是 AI 写的」，几乎等于「我得把它往对的方向掰多少次」。现在有了智能体、有了循环这些东西，从你看到的，最前沿的团队，最新的边界是什么？是循环（loops）吗？还是别的？
Andrew：循环？那都是上礼拜的事了，老兄。一个老被问到的问题是：产品里有多少是 AI 写的？这问题永远难答，因为如果你用去年的标尺，那现在我们产品 100% 都是 AI 写的代码。所以问题更该是：这些代码，是有人监督着写的，还是没人监督？这是两码事。我欢迎标尺一直往后挪，因为这说明我们在产品上有进展。
这块有很多探索，围绕「自主开发的软件」、围绕大量「框架工程」（harness engineering）。我会想：要是它半夜进来，给代码库做一次「垃圾回收」、清理一遍，会怎样？所有模型现在都有个通病：它们通常会增加复杂度。如果有哪家公司的研究团队在听，拜托，让模型更擅长删代码。当你想把开发彻底交给自动驾驶时，这就成了问题，人这一侧和代码库那一侧都是。比如功能请求：你怎么教一个模型，哪些功能该做、哪些该忽略、哪些该归并到一起重新框定？你怎么教它搭出对的抽象？这些都在变好。
但我们还没到那一步，还没法就架个循环，跟它说「去改进这个 app，去听推特、听 Slack、听邮件」，然后它就自己干了。我们还没到，但我们正试着让它发生。
Lenny：你觉得我们会到那一步吗？会到「去吧，赢下市场、给我赚十亿美元」那种程度吗？
Andrew：我不知道，老兄。我不做那种说「永远不会」或者「一定会」的生意。
/11/ 他自己怎么用 Codex：早上一份「3000 个 Slack 频道」的简报
Lenny：你自己作为产品和工程负责人，怎么在工作里用 AI？有哪些用法，是大家可能还不知道这个 app 能做的？
Andrew：我觉得我现在有全世界最好的工作。好玩的一点是，当初做最早那版 Codex app 时，我个人的目标，是把它做成「我用来写代码的那个东西」。我得让它在开发上好到，我能用它来造 Codex app 本身。那时候 Codex app 就是个开发工具。我们跑了一个超快的狗粮回路：你有自己的个人狗粮回路，哦，我做不了这件事，那我得修好它，好让我能做这件事；现在我能做了，现在我能做更多了。
我们发布了那一版，下一个挑战是：人们开始用它做一些不同形状的事了，我得把这个做大，得招几个人来帮忙。于是我的角色，和 app 的角色，同时需要变。我得做更多产品发现，得搞清楚用什么回路去看大家在做什么、去把跑偏的东西掰回来。突然之间，这就成了我用 Codex app 在做的事。我还是写代码，但我也开始：我得做个表格把这块建个模；我得对这块研究里所有已有的努力，做一次内部深度调研，为下一个版本做准备。
5 月左右有一连串发布，把内置浏览器、计算机使用、制品创建带进了 Codex app。那大概是我们「让几乎所有人都能用的 Codex」那次发布，也是大家都知道「氛围编程」这个词的时候。那是我第一次做「五个协调发布」，我在某个 Notion 文档里写好了所有该发生的事，自动去 Slack 频道、代码请求里收集更新，回填到状态追踪器里。这现在挺常见了，但当时我觉得自己站在「怎么管一次产品发布」的最前沿。
简单说，我用 Codex app 的方式，基本就是：我的工作长成什么样了？我怎么让这东西能做我需要做的一切？我早上起来，会看到一份每日简报，来自我所在的 3000 个 Slack 频道里、哪些事需要我关注。我可以回一句：给我五个问题，我来答。
Lenny：这怎么设置的？太想要了。
Andrew：我觉得这块我们都还在发现阶段。现在我会做一个自动化、或者说定时任务：我过一遍我的 Slack 频道，这些是我在意、觉得最重要的，我还在定义，这些是要留意的、不同的类别、这里有些上下文。它会被设成一个自动任务。头几次跑可能需要点引导。好在有这个 app，我不用去找怎么编辑指令，我直接说：下次跑的时候，能不能改成操心这个？或者把那条线弱化一点？或者「这事发生了、简报里没出现，能不能保证以后这类东西在里面」。我就这么一路把它教会，它会更新通知我的方式。
将来这是个问题：我知道怎么搭这个，我也有时间搭，因为对我来说搭它本身就是产品发现。但如果你不在 OpenAI、不在做这东西，你根本不想去搞懂这一摊。我们得把这个东西的形状搞出来。
Lenny：我听下来，大家可能没意识到，你这个 app 用起来很像那种「你直接跟它说话，让它帮你搭一个东西、每天帮你盯一件事再告诉你情况」的产品，它开始变成所有这些产品的一部分。所以一个人要这么用，就是在 app 里说话：我想设一个自动化做这件事，看我的 Slack，这些是我想做的。
Andrew：对。它会帮你搭好。如果它没有 Slack 连接器，它会问「我能加个 Slack 连接器吗？」你点「是」就行。至少我们能做到：你要是不会在 app 里做某件事，你可以直接问它。我不觉得这够，但这是我们至少能做的。
举个例子，我做了个小应用，过滤收件箱里的垃圾邮件，是在 Codex 里做的。每封进来的邮件，它都看一眼，判断这是不是我不想看的那种主动推销冷邮件，给它打标、挪到别处。搭这个时，其中一步是你得进 Google Cloud 控制台，设一堆 Pub/Sub API 和触发器。不知道你用过那个界面没有，又烦又慢。我当时想，等等，要是我让你来做呢？我说，行，酷，帮我做这个。它就，你刚才说的那个「计算机使用」，我以前真没在自己电脑上见过这个。它直接接管我的电脑，自己跑去那儿点。它不在乎有没有连接器：管它呢，我直接开点。然后它就把这事搞定了。看着它自己在那儿忙活，挺疯的。
这些个人工作流特别有意思，因为有些是真的对上了。大家在试各种东西，每个人都在搭自己的私人系统。你问这里每个人他们怎么用，答案全不一样，然后某些主题会浮现，我们就会想：这个该成为 app 里的一等体验。记忆大概就是这种形状：很多人，包括别家公司的人，会说「我建了个 Obsidian 库」或者「弄了个 Notion 区」，告诉它怎么搭我的记忆宫殿。我觉得你不该非得这么干，应该有个记忆功能替你做。这算挺通用的一个。但还有些事，是你这份工作本身的流程，那种你确实该自己搭。所以我们一直在筛：什么对某个人有用、什么该进产品、什么只是「这就是你干活的方式」、什么该成为一个基本单元、什么不该。
/12/ 把 SaaS 装进 Codex 里跑：Dan Shipper 的预言
Lenny：这就是你前面说的品味和判断。我想多聊聊「浏览器使用」这块，因为我觉得大家没意识到它有多强、能拿来干嘛。这让我想起，不知道你看没看 Dan Shipper 上我们播客那期，他来自媒体公司 Every，他有个预测：我们会开始用 Codex 在里头跑我们的 SaaS 应用。所以不用开 Chrome 了。你觉得事情会往那走吗？我们就在 Codex app 里，用着 Notion、Linear、Salesforce，让你的智能体在旁边帮你？
Andrew：他每天都在 Slack 上找我要这个功能。这事一直挺有意思。我们在「浏览器形状」的事上试过好几次：Operator、agent 模式、Atlas，现在桌面 app 里有内置浏览器，我们还能装一个 Chrome 扩展，让 app 连到 Chrome。我们在这上面试过很多形状，学到很多不同的东西。
里头有很多很无聊但很磨人的问题。我们最初发布的是个 Electron 应用，内置浏览器能做的事有点糙。所以一开始内置浏览器是给开发用的，是给你在开发时测试前端用的，我们就说「它不是给别的用的，伙计们，它是个开发者工具」。后来我们切到了我们自己的 OWL 栈，就是给 Atlas 浏览器供能的那套，于是有了多标签页，有了企业级安全，你能真的登录你所有的网站。我们一直在迭代这个。
难的一点一直是：这个浏览器到底该是什么形状？它是只给智能体用的吗，你有 Chrome，你开 Chrome 自己干活；你要是问桌面 app，它就开一个它能快速控制的浏览器，没有 Playwright 那种延迟？还是说，我们想讲「这个 app 是给一切用的，我们想让你拿它当浏览器」？这两条各有取舍，而且不是条走熟了的路。大多数浏览器，顶层就是浏览器、有浏览器标签页。这就冒出一堆无聊又繁琐的问题，比如键盘快捷键：我们到底是把键映射到 VS Code、Chrome、我们自己的东西，还是 Linear？我们想要某种能延续过来的肌肉记忆，但市面上这些产品各有各的「子形状」。怎么办？
这正好说明了这个 app 有多难，你得让它同时服务一个从没造过任何东西的人，和一个想拿它写代码的硬核玩家，比如 Peter。我不确定我能让 Peter 用上这个 app，他可能是最后一个死守终端的人。但我会继续努力。
/13/ 终极愿景：一个「大本营」，而不是一个长方形
Lenny：往大了说，你想把这一切带去哪？Codex 的愿景是什么？一两年、十年后，它长什么样？
Andrew：我们先有了作为命令行工具（CLI）的 Codex，然后决定做这个 app。我们当时对这个 app 有点不确定，但对它作为一个开发者工具能成为什么，有很强的信念。它不会做成 IDE。它会是一个「尺寸刚好」的界面：有点像聊天机器人，但又不止于此，你能看到代码，但我们不打算让你编辑代码。
1 月、2 月，在我们真正发布 Codex app 之前，OpenAI 内部发生了一件很有意思的事：我们开始吃自己的狗粮。我们发现，在工程和研究的工作流上，内部已经收敛出相当清晰的产品市场契合（PMF），用的人很兴奋、很喜欢。我们想，好，只要把质量门槛提上去就能发了，我们确信这会成。
但接着，公司里又冒出来几个别的工作流：市场、传播、财务、法务，基本上每个学科都有人在用这个 Codex app，哪怕它对这些人是「主动敌对」的。它在试图给他们看代码，在请求批准去对代码库跑搜索，它在做一堆对他们来说根本不对的事。所以我们想，那不如把 Codex 加到我们别的界面上？加到 ChatGPT 桌面 app，加到 Atlas 浏览器，把 Codex 的经验拿过去，做成一个更通用的知识工作工具。
这些尝试跑了一阵，然后最烦人的问题出现了：没人愿意为了那些号称给他们设计的 app，离开 Codex app。我觉得这里的教训是：「开发者工具 vs 通用知识工作工具」这件事，有很多讲究，不是非此即彼。我们对这点信得很深。就像我们说「你的角色是你时间花在哪的平均值」，产品侧也是这样：做 Excel 的人，不想看到 Git 仓库的信息，这我们知道。但我们也知道，从他们在做什么，我们能看出他们做的是哪类工作，于是可以从简单开始，按需要把产品长复杂。这不代表我们没有「模式」，你可能想要一些用来整理你东西的模式，让你进入这个体验的方式更清晰。但我们真的非常相信，我们在这儿造出来的，是去承接那些很深、垂直聚焦的事的对的形状。我们和财务团队、科学团队、法务团队深度合作。如果我们能在对的通用模型上，搭出对的可扩展性基本单元，那你用它就能做任何事。我们的挑战是：怎么把它通用化？
有人把它叫「超级 app」，我真希望他们没这么说，因为现在我得天天听「超级 app」。我们会跨过去的。
Lenny：所以方向是，先别叫它超级 app，一个让人去做所有事的地方？
Andrew：我们看到的是，它是个很好的「大本营」，一个帮你追踪你在不同界面上要做的所有事的好地方。有些事你全程在 app 里做，有些事，是 app 替你打开别的 app 去做。比如 app 能连到 Excel，是的，app 里头有个电子表格编辑器，但它够 OpenAI 那些为融数十亿美元做财务建模的人用吗？大概不够。所以 app 会直接跟你桌面上微软 Excel 里的插件对话，做完了，你可以把 Excel 关掉。所以这不只是「我们在屏幕上画个长方形，所有事都得在这个长方形里发生」。它该是你的一个家：你在这儿开始工作、结束工作、把工作自动化，它用上你需要的任何东西。
有个很好的故事。我们为 Codex app 最初的发布，在这个房间里拍了几支视频，然后我们内部的开发者体验摄像师 Brent，被分去剪这些视频。他用 Codex 把视频全剪了，那是早期那种「哇，大家在拿这玩意儿干嘛」的时刻之一。他开始用 Codex 的理由很有意思，他只是好奇 Codex 能不能剪视频。Codex 本身并不是个视频剪辑器，里头没有那套界面，但它能理解他用的是 Premiere Pro。它可以通过编辑 Premiere Pro 屏幕背后的那些文件，做一些剪辑，但做不了全部。于是 Codex 接下来很自然地，给自己造了一个能装进 Premiere Pro 的扩展，然后它就能跟这个扩展对话：「嘿 Premiere 扩展，能不能把 Premiere 里的这个标记改一下。」我们看到这个的时候，挺炸的。
这是个很好的模型。世上有这些专门干某件事的专精工具，所以我们想用 Codex、现在还有 ChatGPT，同时做两件相反的事。一件是：怎么和你已经在用的工具无缝交互？我们不需要给你造一个更好的视频剪辑器，但 Codex 和 ChatGPT 可以去用那个剪辑器，把活儿交接给它，常常是通过连接器、计算机使用，或者像这次这样的扩展。另一件是 Dan Shipper 那个：我有一堆能点来点去的网页应用，但我想能在 Codex 里打开它们，让 Codex 在上面多干点事。这两个几乎是互为反面的模型，我们俩都在大力做。
Lenny：你那个点很有意思，Codex app 你们做得太成功，大家太知道它存在、太好用太好玩，于是开始用它而不用 ChatGPT app。所以方向很清楚，是把它们合起来，免得造成混乱。
Andrew：对。
/14/ 失败角落：「我失败了 10 到 15 年」
Lenny：我带你去一个我管它叫「失败角落」的固定环节。大家看到像你这样的人，就是一路在赢、一路在长，Codex 做得这么好，整个职业生涯一路向上向右。大家可能看不到那些没成的时刻、你发布过的失败品。这些故事对大家很重要，不是一直在赢。讲一个你职业里失败、但教会了你很重要东西的故事。
Andrew：听你这么把我描述一遍，挺好笑的，因为这大概是我第一次「不觉得自己在失败」。我当了很久的创业公司创始人，最后基本是把公司拆开卖掉了。那是好些年，是场苦役，是在重度监管的领域里。整件事感觉就是一场持续的失败。我又去了另一家创业公司，我们在做一些 AI 工具，也是在一个挺封闭、受监管的行业里，那感觉就是一次又一次地试、一次又一次地不灵。所以对我来说，我其实失败过相当多次。有时候，就是某个时间点，几样东西对上了：技能、热情、市场的时机，对上了。
我们把 Codex app 学到的东西，拿来和 ChatGPT 结合，这中间我数不清有多少次微型失败。我们会说「它该长这个形状」，然后扔进 Slack，立刻有一条 2000 条消息的长串，在讲我们有多蠢。这正是我爱 OpenAI 的地方：大家会直接告诉你。在产品上我们内部失败的时候，没有谁藏着掖着。外部产品之所以挺好，正是因为它经历了这种「2000 条消息说这玩意儿真烂」的循环。
我在到这个点之前，失败了大概 10 到 15 年。所以我每天还是很惊讶事情居然顺。这对大家很重要：你可以有一大堆事没成，然后事情开始变得超级顺，秘诀就是接着走、接着学。
/15/ 闪电问答，以及录完之后的「彩蛋」
Lenny：进入闪电问答。你最常推荐给别人的两三本书？
Andrew：我现在是个家长，俩小孩还小，所以有一本叫《咕噜牛》（The Gruffalo）。我家娃最近迷上了《咕噜牛》。我们有张睡前流程图，现在是：睡衣、刷牙、读书、咕噜牛、上小毯子。太好了。顺便说，每本童书都是关于死亡的，总有谁在吃谁、谁在杀谁，总有那种「坏」。但它会制造一个弧线和兴奋感。
我还有本超爱的童书，很老了，叫《大橘点》（The Big Orange Splot）。讨厌业主委员会（HOA）的人，去找来看。讲一个叫 Plumbean 先生的人，住在一条所有房子都长一样的街上，特别整齐。有一天一只鸟把一大罐橘色油漆掉他房子上，他说「去他的」，全押了。他跑去店里买油漆、买吊床、买鳄鱼，把房子彻底翻新，邻居们炸了锅，什么业委会、房产价值。然后邻居一个一个去找他，喝了点据说是「柠檬水」的东西，结果他们一个接一个也开始翻新自己的房子，有个人还搞了条船。我觉得这书人们都该读读，尤其是新人。
Lenny：我听出来的是，行动力。
Andrew：行动力，没错。你可以直接去做事。
Lenny：最近喜欢的电影或剧？
Andrew：《神奇校车》回来了，在 Netflix 上，新的动画版，有 Kate McKinnon，因为弗里斯老师现在升成弗里斯教授了。我个人没时间看电影，我就是把一小时一集的 Netflix 剧一集接一集地刷。
Lenny：最近发现的、特别喜欢的产品？
Andrew：这答案可能很烂，我感觉我每天都在发现我们自己的产品。另外，Linear 做得很棒，在这之前 Linear 一直是我最喜欢的软件产品。
Lenny：最后一个。你做过产品经理、设计师、工程师，这三个里哪个最难？
Andrew：它们都很不一样。对一个人来说让它难的东西，对另一个人来说正是让它容易的东西。围绕这个「三件套」有太多说法了：设计师完蛋了？设计师该不该写代码？产品经理凉了？我们是不是不再需要工程师了，因为产品经理会把所有代码都写了？还是设计师现在去做产品了？所有人都凉了，所有人又都支棱起来了。我不知道，确实有某种收敛，有某种被引入的流动性，我觉得这挺让人耳目一新、挺好的，尤其对那些有行动力、就想去把该做的事做掉的人。同时，像我们聊的，有些东西不该消失。但我觉得，大家应该去找那些值得做的事，然后到那些事上去搞清楚该怎么干。
Andrew：每一份活儿，我们感觉都从这么一个故事开始：产品不是为这事设计的，但它是一个能写代码的空白聊天框，所以它什么都能做。那么，对它来说有用的事是哪些？人们得对这个项目有好奇心，得有一个想要的、有意图的结果，然后拿 Codex 当平台去试，看会发生什么。因为完全没有风险，就几个 token 的事。
我不知道该给什么建议，但如果只有一条，那就是：别和你此刻的流程结婚，要和你独一无二能交付的那个结果结婚。 然后去改你的流程、去试新东西。比如你说「我最懂 Figma 的自动布局」，那你在干嘛呢？AI 在这件事上也会比你强。要靠 AI 成事，需要的那种自我觉察的程度，挺疯的。
这也是我从不敢说「事情就会是这样」的原因。我父母是很开明的人，对自己的事业也投入，但这儿管用的这套东西，就是没法对所有人都管用，这话没有好听的说法。在这儿的人是自我筛选过的：「我就是那种会自己琢磨下一件该做什么的人」，而大部分人不会是新事物的早期采用者。而且，总得不停地重新学东西，也挺烦的，「我擦，又要学个新玩意儿」。我讨厌重复，这是我个人的毛病，也是我从来当不好「媒体人」的原因，我就是讨厌重复自己。
Lenny：当创始人却讨厌重复自己，挺惨的，因为你得当「复读机总司令」。
Andrew：所以对我来说，如果我能每天用不同的方式做我的工作，我爱死了。
Lenny：你给你的工作找到了产品市场契合。
Andrew：对。我没法跳槽，因为我压根不想要别的工作。
写在最后
这场对话名义上的题眼，是「AI 正在怎样改变产品工作的形状」。但听到最后你会发现，Andrew 真正反复在讲的，是一件更朴素、也更狠的事：当「造东西」这件事的成本趋近于零，整个行业过去几十年攒下的那套秩序，正在被悄悄抽掉地基。
他最有价值的判断，我认为有三处，都不是鸡汤。
一是「选媒介」。当文档、原型、甚至完整实现都唾手可得，真正稀缺的能力，是判断「为这个点，此刻该用哪种媒介」，以及看穿「一个抛光到位的原型，并不等于一个想清楚了的产品」。这是给被「PRD 已死」裹挟的所有人，泼的一盆冷水。
二是「时机即一切」。同一个 Codex，2 月发能火、11 月发会死，差的只是几个月的模型。这把产品经理最习惯的「打磨形状」直接降权了。很多时候你做的没错，只是做早了。于是「提前造好、放着发酵、等模型跳一次就再试一次」，成了比写路线图更靠谱的玩法。
三是 Andrew 自己半遮半掩说出来的那句话：「这儿管用的这套，没法对所有人都管用。」
这恰恰是我想替你按住、看清楚的地方。
整场访谈听下来，它当然有它没说出口的另一面。Andrew 是 OpenAI Codex 的产品负责人，他描述的每一个迷人结论，品味取代实现、提前下注、一个能干所有事的「大本营」，最后都顺势指向同一个动作：用 Codex。这倒不说明他不真诚。任何一个产品负责人讲他的产品，本身就是一次最高明的销售。「超级 app」他嘴上嫌弃，可那正是这套叙事的终点。
更值得品的，是「实现已经免费、最贵的是品味」这句金句，对谁是福音、对谁是判决。对已经坐在牌桌上、手里攥着经验和审美的资深者，这是解放。可对一个人，他的全部价值恰恰建立在「我能把这个实现做出来」之上，「实现现在免费了」翻译过来，就是「你的那份工作没了」。Andrew 不是没看到这一层，他说他「害怕」，他说取消产品岗是「糟糕透顶的主意」。但整场对话的底色，是属于赢家的乐观。他最诚实的一刻，是承认这套打法只对一小撮自我筛选过的早期采用者管用，「大部分人不会是早期采用者，这话没有好听的说法」。
说白了，「角色正在融化」是真的，「你是你时间花在哪的平均值」也是真的，前提是，你得是那个还有时间、有余裕、有资格去重新选择把时间花在哪儿的人。被融化掉的另一批人，在他这套讲述里，没有结局。
至于 Andrew 那句给得最漂亮的临别赠言，别和你的流程结婚、要和你能交付的结果结婚，它确实是这整场对话里最值得抄下来的一句。只不过别忘了，说这话的人，是用 OpenAI 的前沿模型，失败了 10 到 15 年之后，才终于等到技能、热情和时机三样东西，在同一个月里对上的。这条经验是真的。能不能复制，是另一回事。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
谢谢你看我的文章，我们，下次再见。
