欢迎收听跨国串门计划，这是一档专注于让中文听众无障碍欣赏全球优质外语播客的节目。通过先进的 AI 声纹克隆技术，我们不仅将内容翻译成中文，还完美保留了原主持人和嘉宾的独特声音，为您呈现全球顶尖的 AI 财经、健康与科技领域精品内容。我是主播一凯，一位热衷于 AI 领域的产品经理，很荣幸能为您搭建这座跨越语言障碍的桥梁。
接下来，让我为您简单介绍本期我们克隆的这档节目。本期我们克隆的是知名产品与增长播客 Lenny's Podcasts 在二零二六年六月的一期深度对谈，主持人 Lenny Rachyski 与嘉宾 Andrew Ambrosino 展开了一场关于 AI 时代产品工作形态的坦诚交流。Andrew 是 OpenAI 旗下 Codex 应用的产品与工程负责人。
他本人经历了从设计师到工程师再到产品经理的转型，目前正带领团队打造这款正被全球越来越多人使用的桌面应用。这一期他们主要围绕 AI 如何彻底颠覆传统的产品开发流程，以及在这个实现成本趋近于零的时代，品味与判断力为何变得比以往任何时候都更重要。那我们就一起走进这期完整的对话。OpenAI 有百分之九十的人在用 Codex，不是百分之九十的工程师，是整个公司百分之九十的人。
对你前几天发的那条推文，说你想把 Codex 做成有史以来最好的桌面应用，没错，Codex 的品质门槛必须高到你打开这个应用去做下一件事的时候，心里从来不会犹豫，它就是你自然而然的选择，就像大家现在习惯打开浏览器标签页一样。确实，我懂你们不断有数据出来刷新各种使用记录，我也不知道，走着瞧吧。好像挺多人喜欢这个应用的。
你觉得为什么AI和顶尖的前沿模型在设计方面就是不太行？我觉得设计比较难打分，因为品味里人的那一面本身就是我们需要的反馈机制的一部分。以目前的技术，这一点感觉还是有点够不着。现在的产品团队形态跟几年前比是什么样的？OpenAI的每个人都非常真实，都有很棒的想法，所以每个人都在做各种东西。不是说大家在承担根本不同的角色或者关注点不一样，而是整个流程反过来了，实现本身不再是成本最高的部分了。
我斗胆说一句，是品味。你觉得未来会不会出现一种大融合，每个人什么都是，那就是未来的样子？还是说我们大体上还是会继续分工？有些事儿我是有点担心的。我听到不少公司说我们要砍掉产品岗，每个人都是 builder，然后发生的情况是。今天我的嘉宾是 Andrew Ambrosino，他是 OpenAI 旗下 Codex 应用的产品与工程负责人。
Codex 正迅速成为人们构建产品的首选应用，同时也用于非产品类工作，比如整理电脑文件、起草文档、做数据分析、阅读邮件等等。如果你听完这期节目，我们在最后还留了一小段录音结束后的花絮。当时在场的制作人聊起了他如何用 Codex 做剪辑工作。从今年一月以来，Codex 的使用量增长了六倍。目前他们每周活跃用户超过五 million，我估计这个数字很快就会过时。
在 OpenAI 内部，几乎百分之百的员工每周都在用 Codex，而且不光是工程师。Andrew 是一位从设计师转型工程师，再转型产品经理的人。他正在打造一款全世界越来越多人用来构建自己产品的应用。接下来有请 Andrew Ambrosino，Andrew，非常感谢你来欢迎做客播客。谢谢你邀请我，这是一次难得的线下录制。
我很少做这种，看看效果怎么样，看看大家是不是更喜欢这种。我们准备这次聊天的时候，我问你，你最希望听众从这次对话里带走什么？你说是AI如何改变产品工作的形态？你所在的团队可能是最前沿、最AI原生的软件团队了，所以你有一个非常独特的视角，能看到事情在往哪个方向发展，其他团队一两年或更久以后会走到哪一步。
现在的产品团队形态跟几年前比是什么样的？现在作为打造这些产品的 leader，最难的事情之一，在我看来就是流程的倒置。这一点，我想很多人都聊过，就是任何人都能做出任何东西。我现在大体上相信，从零开始，你跟这些模型聊，不管是我们的还是别家的，你真的可以搭出任何你想要的功能。这不一定是软件开发里最难的部分，但这真的很酷。
我觉得这创造了一种环境，大家都在做各种东西。你给大家无限的 token，OpenAI 的每个人都非常真实，都有很棒的想法，所以每个人都在做各种东西。而回过头看，我们长期以来跑的那套产品流程，其实是有点相反的。以前是调研构思，也许有一些原型制作，但即便我们过了瀑布式开发的阶段，它仍然带着一种味道，就是实现很贵。
所以你要做的就是通过文档调研原型，把实现的风险在前面全部排除掉，因为大家默认原型和设计更便宜，而现在这个前提变了，彻底变了。眼下，我敢说，针对某个我们急需做的功能，大概有九十个不同的探索方向，有九十个互不协同的团队在各自实现和尝试。所以，简单回答就是反过来了，不是说大家在承担根本不同的角色，或者关注点不一样，甚至不是说技能组合消失了，岗位直接没了，而是整个流程反过来了。
实现本身不再是成本最高的部分了。我斗胆说一句，是品味，是筛选的过程。在那九十次尝试里，哪些地方做得好，哪些该整合到其他方面去，该怎么去框定它，它该不该成为另一个功能的一部分？这个开关里该分几段？所有这些事情。品味这个词最近太火了，我待会儿想再聊回去。你刚才说的九十个原型这个点特别有意思，我先确认一下我理解的对不对？
就是说，OpenAI 内部现在有一个想法在流传，以前大家会写文档说明我们要做什么功能，策略是什么，PRD 怎么写。而现在你描述的情况是，大家直接上手做原型，而且公司里不同的人可能都有类似的想法，于是大家不再写文档，而是各自做出一个小原型，最后就有了大概九十个不同的东西可以看，然后从中挑出一个方向往下走。
这种情况确实很多，而且不光是我们这里，你也看到很多产品负责人说 P R D 已死，原型当道。但我其实完全不这么认为。我觉得现在有一个很有意思的现象，就是因为在各种媒介上做实现的成本都变得极低，大家很容易直接跳到做原型这一步。尤其是如果你不是工程师，或者你从来没写过代码，没兴趣，没时间，就特别容易说 P R D 没用了。
我直接给你看我是什么意思就行了。但我也注意到，对工程师来说，他们又很容易写一大堆文档，而且是那种不值得读的文档。这不是在批评写文档的人，而是说，如果实现变得极其充裕，那选对表达观点的形式就变得非常重要。如果是为了在一个模糊的领域里厘清产品思路，那可能确实该写文档；如果是为了让大家上手试试压力测试某个交互模式，那就该做原型。
我觉得现在有意思的地方就在于选对媒介这件事变得特别关键。你这么说让我想起之前一位播客嘉宾分享的一个词，叫“原始笔触”，就是说当设计师、画家或艺术家在画布上落下第一笔的时候，你后续所有的反应都是从这一笔开始的，一切都会顺着这第一笔往下走。我听你刚才的意思，有时候原型反而是错误的第一步，因为你会被这个原型框住，而不是去回应一个不同的想法或者更大的构想。
我很喜欢你这种观点。现在大家都说算了，不写了，不要文档，不要 P R D 了，而你的意思是，在特定场景下，它们其实仍然有用。对，我还觉得以前那个世界有一个特点，就是媒介本身隐含了很多信号，能告诉你这件事处在流程的哪个阶段。比如你看到一个东西，看起来像要上线的产品，那就意味着它已经到流程后期了，各种假设已经被验证过，风险已经排除，设计也看过了，商业目标也是对的。
但现在这些东西都脱钩了。以前之所以会这样，是因为在风险被充分排除之前，很难拿到资源去真正做出来。而现在这个前提已经完全不存在了。所以我觉得很重要的一点是，我们要开始明确的说，我们可以有原型，也可以有文档，但关键是我们清不清楚这个东西到底在干什么。因为，就像你说的，你不想过度锚定在一个本来只是探索性质的东西上，结果它看起来太像成品了，视觉上好像可以上线了，但它其实并不符合研究的实际方向，也不是用户真正想要的，或者对业务来说不是正确的选择。
我不想过度强调“品味”这个词，但归根结底，知道该做什么，怎么呈现信息，怎么达成目标，用什么媒介，这些正在成为最重要的事。就是这样，在各个领域都是如此。你一直在说品味，那到底什么是好的品味？是指你刚才说的决定我们要投入做哪个东西吗？还是也包括东西做出来之后判断它对不对，该不该发布？你能不能具体讲讲你心目中的好品味、好判断力到底是什么？
因为大家听到这个词可能会觉得哦，我品味很好，我懂。但在实践中，它到底长什么样？这挺有意思的。我网上刷太多了，昨天好像看到一条推文，是 Linear 的产品负责人发的，可能记错了，先说声抱歉。他说大家过度强调了品味中审美的那一面。他还拿 Paul Graham 举例，说 Paul Graham 显然品味极好，但他穿的是工装短裤。
意思是我们得把品味的含义拆开来看。这里面有很多细微的差别，我觉得你刚才提到的那些方面都包含在内，确实有审美的一面，但也有系统思维的一面，就是这个东西怎么融入整个系统。当然，品味也体现在一些细节上，比如某个交互、某个动画跟他要传达的语义不匹配，动效太快，跟他想表达的意思对不上，这些都非常重要。我可能在这方面花的时间有点过多了，但更核心的是，如果我们什么都能做，那到底应该做什么？
目标是什么？我们怎么达到那个目标？我觉得这才是关于品味真正要回答的问题。我每次听到这些，总会想一个问题：随着 AI 越来越强、越来越好，能做越来越多的工作，人类大脑在哪些地方还会持续有价值？感觉品味就是其中一部分。我顺着这个思路想到的是，AI 在真正的设计上还是很差，AI 的输出并不好，很少让人觉得就是它了，完美。
通常都是哦，这是 Claude 设计，这是 Codex 的设计。你觉得为什么 AI 和顶尖前沿模型现在就是做不好设计？你觉得他们能做到吗？会不会有一天我们惊呼：天哪，搞定了！我倾向于认为有一些实际原因导致设计落后，也有一些更难啃的问题。我不在研究院那边说这个可能会被骂。我觉得设计比软件更难打分，要建立一个训练模型的闭环。
什么是好设计，什么是坏设计，比判断代码能不能编译、能不能按预期运行要繁琐和费力得多。因为品味中人的因素本身就是反馈机制的一部分。我还觉得各大实验室历史上会把资源投入到能让 AI 研究加速的能力上。在编程模型的早期阶段，很明显模型能写出正确的代码会加速研究，对吧？但你很难对设计提出同样的论证。不是说做好设计不重要，而是它不在那个飞轮的直接路径上。
这些是实际原因，而且这些问题会消失，这些模型会在设计上变得相当好。但还有一些更模糊的东西会非常难。我脑子里有个简短的清单，一个是什么是好设计，这里面有文化的成分。你还记得吗？大概是去年，每个新出的网站都像是 Lenny 网站的翻版。Lenny 的网站设计很棒，品味很好。如果一个模型能做到这样，我会说哇，这是巨大的飞跃。
但如果我有个模型每次都输出 Lenny 的网站，那并不是挑战所在。设计中新颖性的重要程度比软件工程中高得多。软件工程里，你几乎希望它过度依赖已知模式，对吧？而设计不一样，这里面需要一些随机性和新颖性。还有一点，对我来说，我花了很多时间写代码，或者说在早期 Codex 应用上监督代码，即使模型在设计上变好了，软件设计和它生成的代码之间还存在一层抽象的互动。
比如角落里这个东西应该和下面那个东西在代码库中共享 x y z 对吧？这和说模型需要成为更好的设计师不太一样，尤其是在视觉层面，这确实是视觉设计，但它要深得多。它关乎抽象层，比如，如果明天我们公司做了一次品牌重塑，浅层的做法是我们得一个一个更新两百六十三个组件，深层的做法是这两个看起来不同的东西之间的语义关系，它们都在列表里有相同的样式，向用户传达同一种交互模式。
我觉得这在当前技术下还是有点够不着，就是那个抽象层。所以我们经历这个过程，对吧？我们十一月开始做 Codex 应用，当时没有全职用它，现在什么都用它了。这是一段旅程。但现在我们在用它的时候，实际做的事情已经不一样了。你刚才问什么来着？这个回答太精彩了。说到设计和创意，Codex 应用刚出来的时候，它是一个全新的东西，没人见过。
它不像终端，也不像 IDE，它是一个能编程的聊天工具，你还能看到代码。按你的说法，爱很难凭空提出一个全新的编程范式，这感觉就是人类大脑目前仍然有价值的地方，几乎是创造力，是做出新东西，而不是重复已有的模式。对我完全同意，为人类大脑鼓掌。目前是这样，我们准备这次访谈的时候，你说你听了 Jenny 那期节目，他是 Codex 的设计负责人，负责协同工作之类的。
他有一个核心观点，说设计流程已经死了，没有时间做设计，事情发展太快了，直接做就行了，设计只是在过程中做一些方向调整。你暗示你对设计流程有不同的看法。我和 Jenny 在很多方面可能看法一致。我不喜欢那种正式的设计流程。我同意她的观点，她确实死了。在 AI 出现之前，我就真的不喜欢这套流程。你能快速描述一下这个流程吗？
让大家对设计流程有个概念。对对，我几年前创业的时候，我们当时招设计师那会儿，有篇挺刻薄的文章讲什么案例研究工厂，大概是mid
serp时代的东西，就是说设计师被教了一套流程，把他看得高于一切，甚至高于最终成果。如果某个东西走了这套流程，那两件事就成立了。第一，它会很好，流程能保证质量和影响力。第二，如果东西本身是好的，哪怕你并不喜欢它，也没人用它，但因为它走了用户研究、发散、收敛那套流程，它就是对的框架。
这套东西一直有点学术气，但我现在觉得它的一些短板正在暴露出来，尤其是因为实现速度太快了。再说一遍，那套流程的前提假设是实现成本很高，你只能承担一次开发，所以你得在动手之前把问题空间和解决方案空间彻底穷尽一遍。然后我们后来看到 Figma、Origami 这些工具，你可以把可交互原型提前拉进流程，从而加速一些洞察。
你可以模拟生产环境。后来甚至有个梗说，高管们会问我们能不能就做个原型，然后指望它直接能用。但这件事是真的，它确实成了设计流程的一部分。我们把原型拉进了流程。现在的问题是，你可以把整个实现都拉进来，这就跟很多假设产生了错位。你看到一个打磨的很完美的原型，看起来随时可以上线。公司里足够多的人看到后，就会问：我们现在能发布吗？
但实际上，我们还在早期设计阶段，只是没人明说。这就是我们现在面对的情况，一堆人在做各种探索。九十个人会有这个想法，它看起来非常精致，但这其实就是现在的设计流程。把设计流程跟媒介绑定，这才是可怕的地方。设计师现在有更多工具来做这个流程。你可以把东西放进现有产品里做 A 斜杠 B 测试，或者直接把它当原型用。
现在很多公司都有产品婴儿版这个概念，比如 Baby Cursor，你在 Twitter 上应该见过。我们也有 Baby Codex，就是一个大幅简化的代码库，能近似生产应用的所有交互，所以改起来快得多。你可以说侧边栏这样行不行？或者弹出一个面板，里面放个群聊。如果这样那样呢？这是一个巨大的工具，是设计流程的一部分。
所以要说设计流程已死，我觉得既对也不对。如果你死守着那些工具，那些日常的具体步骤，那确实它死了，你不会好过的。但如果把流程完全扔掉，或者把流程的框架那种我们现在在流程的哪个阶段的意识扔掉，那它其实比以往任何时候都更重要。这真的很有意思，因为你的背景覆盖了所有职能。大家去看你的 LinkedIn，上面写着工程师、设计师、产品经理、创始人。
现在你负责桌面应用，我觉得设计应该不在你的管辖范围，是有独立的设计团队吗？还是归你管？看是哪一周。好，我们合作非常紧密。我们相信大家坐在一起嵌入团队汇报线的话，我不太确定。每周都在变。那 Codex 应用上的设计流程是什么样的？对，关于角色崩塌存在意义上的角色崩塌，已经有很多文章讨论过了。说以后不再有角色之分，我们倒没看到那种情况。
不过在 Codex 团队里，我们看到的角色崩塌确实比公司其他部门，甚至比其他行业都更明显。我觉得部分原因在于，这本身是一个面向工程师的技术产品。所以，我们的设计师会说工程师的语言，对吧？我们的产品经理也讲技术语言，会写代码。Alexander 有计算机科学硕士学位，而我是没有的。所以，我们确实看到了大量的角色崩塌。
每个人不再被设计在哪儿结束，工程从哪儿开始这种边界和围栏所定义，而是更多的由他们工作内容的平均分布来定义。也就是说，如果你把我们设计团队某个人做的所有事情取个平均值，里面会有大量写代码的事儿，也有大量产品工作的事，但平均下来，它的重心会落在这边，对吧？画在图上就是一个点，这也反映了我们的流程，尤其是因为整个 Codex 应用都是在 Dogfooding 循环中打磨出来的。
我们所有人都渴望尽可能多的在应用里完成工作，哪怕它现在还不是最好的工具，这样它才能变成最好的工具。所以很多设计工作，我们都是通过使用应用来推进的。然后说好，这里哪里有问题？我们经常做的一件事就是不去优化流程，而是让产品变得更好来反过来优化流程。这其实是一种让人很不舒服的状态，但每周都在变化。我特别喜欢这个观点，就是你的角色是你花时间所做事情的平均值。
如果你大部分工作都是 PM 的活，那好，你目前就是个 PM；如果是工程，那你目前就是个工程师。我有个感觉，OpenAI 是不是第一家把员工叫做技术团队成员的公司？不是吧？我记得这个做法可能最早是从 Xerox 开始的。我实习的第一家公司叫 Up There，他们也是这么做的。这个做法由来已久了。但现在确实普遍多了，不过这在注重研究的公司里算是一种传统，对吧？
嗯，明白了。所以它起源于研究领域，但我觉得这像是某种信号，预示着未来可能的方向，就是我们都统称技术团队成员。你的职能不是固定的，你不被框在 PM 部门、工程部门或设计部门里。你觉得长远来看，我们都会走向这个方向吗？你觉得职能还会继续存在吗？比如 PM 技能组合、工程技能组合、设计技能组合，这些还会在吗？
人们还是会说我是设计师，你怎么看？现在有人管这叫 builder，你觉得未来会出现那种大融合，每个人什么都是，那就是未来。还是说，我们最终大体上还是会保持分工。有一些事情是我担心的。我觉得有些公司特别喜欢走极端，急着跳上别人预言的那个潮流。我认为消除角色这个概念的危险之一在于，它可能会危险地抹杀掉有些事情是专业领域有可学习的最佳实践这个观念，对吧？
我听过很多公司说我们要取消产品这个角色。顺便说一句，我觉得这是个非常糟糕的主意。然后所有人都只叫 builder，结果就是产品这个领域积累起来的整套方法论、那些真正的最佳实践、那些被验证过成败的经验、那些真实的流程，全都被抛弃了。就因为人们觉得哦，我也会写点代码了，这不是个好状态。我觉得这不是你的领域，这种边界，我是乐于看到它消失的。
但这里需要一个平衡，就是不能让每个人什么都做。首先，无论是广度还是深度，都做不到，对吧？这也是为什么管理者不会消失的原因，不是每个人都能做所有事。而且每个领域都有它的技能成分。我觉得很多工程师有个毛病，就是不承认这一点，觉得工程本身才是技能，是写代码，其他角色就只是凭感觉做事。其实不是这样的，对吧？
没错，你会用 Excel，但你不能去财务团队干活，对吧？就是这类事情。我觉得还有一个问题就是，你想不想做这工作？我想不想做？我觉得现在更多是这个因素了。现在切换角色更容易了，学习最佳实践更容易了。你在一个角色上的效能不再跟使用某个特定工具的能力绑定了，对吧？更多是看你能不能进入这种思维模式，学会哪些方法有效，哪些无效，然后专注去做。
我花了很长时间，觉得自己不应该做软件工程师，因为我不关心汇编语言，也不去背 TypeScript 语法。其实这些角色里一直都有某种守门的东西，好像在说不擅长这个角色就等于擅长这个工具。我觉得这才是现在开始被侵蚀掉的部分。我只是觉得人们把这一切都夸大了。你们 Codex 团队是什么样的构成？有多少工程师、设计师、PM？
目前团队大概是个什么结构？每次有人问我 Codex 团队有多少人，你想让我回答这个吗？我一般会说大概在十个人到几千人之间吧。这听起来像是个糊弄人的答案，但它其实很真实，因为我们确实把这款产品看作这里所有人工作的结晶。所有投入模型研究的东西，所有让模型擅长 QA 和浏览器操作的东西，所有关于模型个性的东西，所有围绕前端基础设施的产品工作，所有用户相关的东西，这一切最终都汇聚到这款产品里。
但与此同时，我们也不是每天接受成千上万人随便提的 PR。我们有一个团队，工程师有两位数，设计师大概一半，有几个产品人员。不过这里的产品工作更像是一种区域防守。我觉得 Codex 这边，或者说桌面端这边，大家身上很普遍的一点就是能动性和品味。很多是前创始人或者在大公司做过创始人式事情的人，很多品味极好的人。
在 Open AI，我们允许团队变得很大。我们不会说“嘿，这里没有管理”，但团队确实相当大，而且主要是个人贡献者。我觉得这样挺好。你用“区域防守”这个词来形容产品工作，这很有意思。这跟设计领域的转变也有点像，就是你存在的意义是去管理和协调。多聊聊这个吧。产品人员的区域防守到底是什么样的？我跟Alexander聊过很多次这个类比，就是说，如果两个产品人员工作重叠的太厉害，通常不是个好信号。
你作为产品组织，其实想做的是这种力导向的活动，去发现哪里有缺口。尤其是在现在这个新世界里，策展、引导和对齐变得很重要。到处都是人们乱扔想法的混乱局面。那种自上而下做一整年规划的方式行不通了，所以现在的情况是我们需要品味制造者来引导事情从萌芽到最终产品该有的样子。这意味着你基本上需要覆盖整个公司，所以大家分散开来，然后说好谁最擅长什么，我们之间拉开一点距离，这样才能全面覆盖。
大概就是这么回事儿，然后你再去填补缺口，你会说我们想招有产品思维的工程师，我们不想让一堆人写一堆代码，然后需要一个完整的团队来审查产品一致性。我们希望每个人都有这些技能，但我觉得人们深入钻研的方向必须改变。这绝对是我跟像你这样的人聊的越多，越频繁注意到的一个点。现在最有价值的人，至少是最有价值的人之一，是那种能把一个想法从概念一直做到完成，并且有品味判断出这是不是好东西的人。
对，就是从头到尾的守护，对，做出好东西有一种执念。就是这种高能动性、高品位的人，完全就是你描述的那样。这是不是你在招人时考虑的方向？你觉得什么样的人在这个新世界里会做得特别好？我觉得这就是现在的核心，这也反映了我对个人贡献者和管理者之间关系的看法。不是说管理要消失了，也不是说每个人都是个人贡献者，而是现在每个人其实两者都沾点边。
如果你是个人贡献者，你也不是一个字符一个字符的敲代码了，你是在管理一些东西。你在管理 agent，你在管理正在发生的工作，这些工作汇聚起来去完成某件事。如果你是团队管理者，你做的也是同样的事，只是颗粒度不同。我招人时一般看重两点：一是对专业领域的掌控力，二是有品味，能判断出，嘿，你会有无限的 token。
我们不能只是粗制滥造，在一个内容无限的世界里，你得能分辨什么是信号，什么是噪音。你提到了规划。在现在这种变化速度下，做路线图规划变得非常困难。对，我猜在你们这个领域尤其如此。大家对此经常对我感到很头疼。是的。因为东西在不断发布，事情在不断变化，对吧？你们团队是怎么做规划的？你们会往前看多远？一个计划长什么样？
是电子表格吗？还是MD文件规划的产出物到底是什么样的？我觉得我们在规划上没做什么革命性的事儿，也没什么巧妙的招。基本思路就是越短期的事越需要细节，不是说我们不做九个月后的规划，而是那个规划必须保持非常模糊。因为你现在给九个月后的计划加任何精确度都是虚假的精确。都是虚假的精确，纯粹浪费时间。你可以嘴上说说，但我们规划的东西没一个能原样落地。
我觉得研究那边不一样，我不是代表研究团队说话，但在应用侧做产品的时候，你十一月能规划的东西，可能十二月还成立，但实际发生的根本不是那样，所以真的很难做规划，非常难。我们一般需要知道的是，模型在什么时间线上大概能做什么。我上一家公司的时候，我就看到这个转变，我们开始用模型来驱动功能，然后整个产品流程就崩了。
基本上只能变成这样，把未来一两年我们感兴趣想做的事儿全列出来，全部做原型，判断哪些现在就能做，其他的就放着慢慢酝酿。然后每次模型有新的飞跃的时候，这里有个关于 Codex 桌面应用的好故事。我非常有信心，我们二月发布的 Codex 桌面应用，如果是在十一月就准备好的话，在市场上绝对会失败。唯一的区别就是十一月到二月之间的模型能力变化。
我觉得这里面有很多值得思考的地方。同一个形态的产品，仅仅因为几个月的实际差异，结果就完全不同。这绝对是我们这档播客里反复出现的一条线，去做那些现在还不行，但等模型变强之后就能行的东西。还有另一条线，就是野心对你做的事情更有野心。所以，这是你做事的一种方式吗？就是先做一堆可能现在还跑不通的东西，放在那里，等模型追上来。
这算是你的思路吗？我觉得我们有很多这样的情况，有时候的挑战在于你必须非常清楚地说明这个东西在设计流程中处于哪个阶段。人们还有那种肌肉记忆，觉得哦，我给这个东西写了代码，所以我们应该把它推出去。不是这样的，这意味着你现在有了一个可以拿来测试未来模型的原型。我们应用里的内置浏览器就是这样。我们有一个能用的版本。
再往前追溯到 Atlas，我们在 Atlas 里就有 Agent 在跑，挺酷的。在那之前，ChatGPT 里还有 Operator，那个没做成，想法非常酷。你可以在 Operator Atlas Codex ChatGPT 之间画出一条线，本质上他们是同一个功能，但用不同的智能水平重新发布，结果就完全不同。
所以我一直推大家不要固执的认为不行，这个东西跑不通，所以它是个烂功能，不是的，它可能只是还没到时候。另外还有一个方面，尤其是在研究那边，总有一种冲动要做最有野心的东西。说好在极限情况下，模型可以直接做到这个，但在产品侧这行不通。如果你回头看最初 Codex 发布，基本上就是 Codex Web，交互体验并不好。
它的模式是你给模型一个任务，它就去做，做完回来交给你。听起来也没多激进。问题在于他任务完成的不够好。他写的代码是不错，但那个形态太超前了。然后 Cloud Code 出来了，完全本地化，不接云端，也不假装自己有那么强的 AGI 色彩。他会问你问题，就待在那里。你不能把整个人生都委托给他。这个效果好得多，因为那时候模型的能力刚好到了那个点，所以我们当时是太 A G I 化了，超前于那个时刻。
我经常回想这个教训。以前产品在市场上失败会告诉你很多关于产品形态、产品沟通方式的问题，而现在不是了。你可能需要把这个东西发布六次，它才能成功，而且形态可能完全没变。听你讲，现在做产品要考虑这么多变量，真的很有意思。有模型和研究的时间线，模型会变得多聪明，有人们能不能理解？原来可以这样在云端构建软件，这就是未来的问题。
要让人们为这个新未来做好准备，还有你们团队自己能做出什么？我很喜欢 Codex 这个例子，因为它又回到了野心这个话题。我想听听你怎么看这条线，就是更有野心一些。因为这些模型能做到的事远超你的想象，有时候对市场来说又太有野心了，市场还没准备好。你有没有想过这一点？就是推动团队更有野心，因为现在做那些过去觉得难到离谱的事变得容易太多了。
这是一个核心挑战。一旦有一个产品或者一个功能已经存在了，人们就很容易去挑那些细枝末节的问题，然后做微观优化。他们应该这么做。Twitter上的人也喜欢提醒我们这一点，我对此表示感谢。大家就应该关注已有的功能，把它们做得更可靠、更好。但这也是我们内部有自下而上探索文化的原因，因为有时候就像Codex应用在某种程度上颠覆了ChatGPT一样，未来的某个项目也会颠覆现在的东西。
这本身就是设计的一部分。你不可能让一个团队同时做好颠覆性创新和产品维护、质量打磨这两件事，总有个限度。他会设计出一个能兼顾两者的流程。稍微拉远一点看，想想AI影响我们构建产品方式的演进过程，这简直疯狂。就像你说的，我们以前所有代码都是手写的，像手工打造的人类代码，到现在AI写百分之百的代码，再到你刚才说的，现在编程更像是驾驶AI。
当你去想我的代码有多少是AI写的，这个问题几乎变成了我把它往正确方向引导了多少次，这才是编程的新形态。现在又有了agent循环这些东西。从你看到的情况来看，最新的前沿是什么？是循环吗？还是别的什么？那些最AI化、最AI前沿的团队，他们现在的运作方式，可能大家还不知道。对。循环已经是上周的事了，我们聊过这个。
一个常见的问题是，产品有多少是AI写的？这个问题一直很难回答，因为如果你用去年的标准来衡量，那我们现在百分之百的产品都是AI写的代码，所以问题更像是好吧？那这些代码是有监督写的还是无监督写的？这完全是另一回事儿。我欢迎这种标准的不断变化，因为这意味着我们在产品上取得了进展。这方面有很多探索，比如自主开发的软件，很多
harness 工程相关的东西，还有各种不同的探索方向，比如能不能让 AI 晚上来一趟，对代码库做垃圾回收，清理干净。
我觉得目前所有模型都有一个通病，就是它们通常会增加复杂度。如果有哪家公司的研究团队在听，请让模型更擅长删除代码。但目前，当你试图让开发完全自动驾驶时，这就会成为一个问题。这既涉及人的层面，也涉及代码库的层面。比如功能请求，你怎么教模型判断哪些功能该做，哪些该忽略，哪些该归到一起重新梳理？你怎么教模型构建正确的抽象？
所有这些都在变好。我觉得我们还没到那个地步，能直接设一个循环说改进应用，然后让它去听 Twitter，听 Slack，听邮件。我们还没到那一步，但我们在努力让它实现。你觉得我们会到那一步吗？会到一个直接说增长赢就行的地方吗？斜杠目标赚钱，帮我赚十亿美元，赢下市场。我不知道，我不做绝对肯定或绝对否定的判断。
对。你作为产品负责人、工程负责人，在工作中是怎么用AI的？有哪些用法可能是大家还不知道可以用这个应用来做的？对，我觉得我现在拥有全世界最棒的工作。但让这件事特别有意思的一点是，我们在开发最初的 Codex 应用时，我个人的目标就是把它做成我自己写代码用的工具。我当时想的是，我必须把它做的在开发方面足够好，好到我能用它来构建 Codex 应用本身。
而那时候的 Codex 应用还处在开发阶段，我们当时形成了一个超快的 dogfooding 循环，因为你有一个自己的 dogfooding 循环，你会觉得哦，我做不到这件事，我应该把它修好，这样我就能做这件事了。现在我能做这件事了，然后我就能做更多事儿了。我们发布了那个版本。接下来的挑战是，大家开始用它做一些形态不太一样的事情了。
现在我需要把它做大，所以我需要招几个人来帮忙。于是我的角色变了，同时应用的角色也需要改变。所以我就想，好，我需要在这里做更多的产品发现。我需要找到正确的循环，去了解每个人都在做什么，并把偏离方向的事情拉回来。于是，突然间，这就成了我开始使用 Codex 应用的目的。我仍然会写代码，我试着让自己的使用方式跟我们正在解决的问题保持一致。
现在，我会想，我需要建一个电子表格来把这个模型做出来。我需要针对这个领域的所有研究进展做一次内部深度调研，为下一个版本做准备。大概在五月前后有一个或一系列发布，给 Codex 应用带来了应用内浏览器、Computer Use 和 Artifact 创建功能。我觉得那是我们面向几乎所有人的 Codex 发布。
大家都知道 Vibe Coding 这个词。我觉得那是我们第一次 vibe 协同发布。我当时在某个 Notion 文档里列了所有需要完成的事情，然后我在做自动化，比如去收集 Pull Request 的更新、Slack 频道的更新，然后更新状态追踪表。现在这些已经很常见了，但当时我感觉自己站在了如何管理产品发布的最前沿。
简而言之，我使用 Codex 应用的方式，基本上就是我的工作演变成了什么样子，以及我如何让这个东西能完成我需要做的所有事情。我早上起来会看我的每日简报，它汇总了我在的大概三千个 Slack 频道里的所有信息，告诉我哪些事情需要我关注。我可以回消息说，好，给我五个问题，我来回答，我就能做到这些。你是怎么设置的？
对别人来说，设置这个的工作流程是什么样的？听起来太棒了。我得再说一次，我觉得我们在很多方面还处于探索阶段，所以现在的情况是我在做一个自动化，或者说一个定时任务，让它去便利我的 Slack 频道。这些是我关心并且认为最重要的东西，所以我还在定义这些，比如这些是需要留意的不同类别的事情。这里有一些上下文，然后我也把它设置成一个自动化任务。
头几次运行的时候，可能需要一些引导。幸运的是，用这个应用，我不需要去搞清楚怎么编辑指令，我只需要说：“嘿，下次运行的时候，能不能改成关注这个？”或者能不能弱化这个工作流？或者黑这件事发生了，但没出现在简报里，能不能确保这类事情被包含进来？这样我就可以一路指导他，他会更新通知我的方式。诸如此类，我觉得在未来，这一直是 Chatbot 形态的一个核心问题。
我知道怎么设置这个，我有时间去设置，因为对我来说，设置本身就是产品发现。但如果你不在 OpenAI 工作，不开发这个东西，你不会想去搞明白所有这些事情。我们需要去摸索出那种形态。对我听下来，觉得大家可能没意识到，你的应用在很大程度上可以像 OpenAI 那样运作。对。大家当时那么兴奋，就是因为你可以直接跟他说，帮我设置这个东西，每天帮我检查这件事儿，然后告诉我情况。
他开始成为所有这些产品的一部分，这太棒了。所以别人设置的方式就是直接在应用里说，我想设置一个自动化来做这件事儿，看看我的 Slack，这些是我想做的事情。然后应用会说好，他会帮你设置好。如果它没有 Slack 连接器，他会问我可以添加 Slack 连接器吗？是或否？你可以点是。我们至少能做到的是，如果你不知道怎么在应用里做某件事，你可以直接问他。
我觉得这还不够，但我认为这是我们至少能做到的。我举个好例子，我做了个小应用，用来过滤收件箱里的垃圾邮件。每封邮件进来，这是我在 Codex 里做的。每封邮件进来，它会看一遍，判断这是不是我懒得看的那种不请自来的冷推销邮件，然后打上标签，挪到别的地方去。要搭这个流程，其中一步是你得进到 Google Cloud 控制台去配一堆 Pub 斜杠 Sub API 触发之类的东西。
我不知道你用没用过那个界面，又烦人又慢。我就想，等等，我直接让你帮我做行不行？然后我就说好，帮我搞定这个。结果他就你描述的是 computer use，我以前从没亲眼见过这种事在我电脑上发生。他直接接管我的电脑，开始自己操作，就像在说：“我管你有没有 connector，我自己点就完了。”然后他还真搞定了，光看着他做这件事儿就觉得很疯狂。
设计 Connector 应用内浏览器和你的 Chrome 扩展之间的决策边界，哪个走已连接，哪个走 Computer Use，挺有意思的。而且这些全凭感觉摸索出来的。我前几天看到一条很棒的推特帖子，把这三种方式以及各自适合什么场景讲得很清楚。那个人总结得特别好，这些个人工作流真的很有意思，因为有些特别对路。
大家什么都在试，每个人都在搭自己的个人系统。你问这里每个人在做什么，答案全都不一样。然后慢慢会浮现出一些共同主题，我们就会想，这个应该做成应用里的一等体验。大家好像都在搭这个东西，那我们就直接把它做通。我觉得 memory 差不多就处于这种状态。我们这边很多人，还有其他公司的很多人，都在说，我建了个词典库或者 Notion 区域，告诉他怎么搭我的记忆宫殿，怎么放东西。
我就觉得不是每个人都该这么折腾，应该有一个 memory 功能直接帮你搞定，对吧？这挺通用的，这是一个例子。但还有别的东西，比如你工作中的流程，那种确实该你自己搭。我觉得我们一直在反复琢磨，什么对个人有效，什么该进入产品，什么该保持原样，对，那就是你做自己工作的方式，对吧？什么该变成基础能力，什么不该，嗯。
这就是你之前说的品味和判断力去甄别这些东西。我想稍微聊聊 browser use 这块，因为我觉得大家还没意识到它有多强大，能用来做什么。这让我想起，不知道你看没看 Dan Shaper 上节目那期，他有个预测，说我们以后会开始在 Codex 里运行我们的 SaaS 应用。对，而不是在 Chrome 里打开。
我知道他天天在 Slack 上找我，要这要那。你觉得未来会往这个方向走吗？我们就在 Codex 应用里工作，用 Notion、Linear、Salesforce，你的 Agent 在旁边帮你，还是你觉得这是另一个方向？这个确实很有意思，因为我们显然在浏览器形态上做过好几次尝试，对吧？Operator
ChatGPT Agent 模式 Atlas，现在桌面应用里又有了应用内浏览器，我们还能装 Chrome 扩展，让应用连接到 Chrome。
我们试过很多种形态，也学到了很多不同的东西。这里面有很多因素在起作用，也有很多很无聊的因素，比如我们最初发布应用时是 Electron 应用，里面应用内浏览器能做的事有点糙，所以当时那个应用内浏览器是给开发用的，用来在开发时测试前端。我们当时说这东西真不是干别的用的，是个开发者工具，对吧？后来我们切到了 IO 技术站，就是驱动 Atlas 浏览器的那个。
现在有了多标签页，也有了企业安全能力，你可以在里面登录各种网站。所以我们一直在迭代。我觉得最难的问题一直是这个浏览器应该是什么形态？是只给 Agent 用的吗？你平时用 Chrome 打开 Chrome 干你的事儿。当你让桌面应用做事情，它打开一个自己能快速控制的浏览器，没有 Playwright 那种延迟。
还是说，我们在试图说这个应用就是一切？我们希望你把它当浏览器用。这两者之间有很多取舍，这条路也不是特别成熟，对吧？大多数浏览器顶层就是浏览器有浏览器标签页，这会带来很多很无聊但又很繁琐的问题，比如键盘快捷键。我们是要把按键映射到 VS Code，还是映射到 Chrome，还是映射到我们自己的东西，或者映射到 Linear？
我们希望有某种肌肉记忆能延续过来，但所有这些产品都有自己的形态、子形态，市面上各种产品都有，我们该怎么办？这正好说明这个 app 有多难做。你得让它既能服务从来没做过任何东西的人，也就是比较基础的用户，又能服务像 Peter 那样的重度用户。对，就是 Open AI 那位想用它来写代码。我不太确定能不能让 Peter 用上这个 app，他可能是最后一个。
他是终端党，终端死硬派，但我会继续努力。好，我先退一步，聊聊更大的图景。如果把所有这些都考虑进来，Codex 的愿景到底是什么？它会走向哪里？未来会是什么样子？比如一两年或者十年后？我们一开始把 Codex 当了命令行工具，对吧？然后我们决定做这个 App。当时我们对这个 App 还有点不确定，但对它作为一个开发者工具的起点，我们很有信心。
它不会是一个 IDE，而是一个尺寸刚好的界面，有点像聊天机器人，但又不止于此。你能看到代码，但我们不让你直接编辑代码。今年一月、二月，OpenAI 内部发生了一件很有意思的事，那是在我们正式发布 Codex App 之前，我们开始内部 dogfooding 这个 App。我们发现，在工程和研究工作流上，我们正在收敛到相当清晰的内部 PMF。
他们用的很兴奋，特别喜欢。我们就想，好，只要在对外发布前把质量门槛提上来就行。我们确信这东西能成，但接着公司内部又启动了几个其他工作流，想看看这个 Codex 项目在编程 Agent 上确实摸到了门道。我们有市场部的人、传播部的人、财务部的人、法务部的人，几乎所有职能的人都在用这个 Codex App。
尽管他对这些人其实很不友好，对吧？他会试图给他们看代码，会请求批准运行二G，做的全是那些对他们来说明显不合适的界面行为。所以我们就想，为什么不把 Codex 加到我们其他的界面上呢？比如加到 ChatGPT 桌面 App 里，加到 Atlas 浏览器里。本质上就是把 Codex 的经验提炼出来，让它更通用，变成一个通用知识工作工具。
这些尝试推进了一段时间，然后最让人头疼的问题出现了：没有人愿意离开 Codex App 去用那些号称是为其他角色打造的 App。我觉得这整件事的教训就是开发者工具和通用知识工作工具之间的界限，这里面的细微差别远不是非此即彼那么简单。我们对此深信不疑。当然，就像我们常说的，你角色的平均值就是你现在的角色。
这在产品端也同样成立。做 Excel 工作的人不想看到 Git 仓库信息，我们知道这一点，但我们也知道，从他们在做什么，我们可以推断出很多关于他们工作类型的信息。我们可以从简单开始，在觉得有必要的时候再把产品做复杂。这不代表我们没有模式区分，你可能需要一些模式来组织你的东西，让你进入体验的方式更清晰可辨。
但我们真的坚信，我们现在构建的这个形态是能够承载那些非常深入、垂直聚焦的事情的正确形态。我们跟财务团队深度合作，跟做科学的团队合作，跟法务团队合作。所以 Codex 是开发者工具，ChatGPT 是另一个方向，到底会走向哪里？这就是我们的思考方式。你刚才说的这一点很有意思，Codex App
做的太好了，你们让大家知道它的存在，又把它做的那么好用，那么有趣，结果所有人都开始用它，而不是用 ChatGPT App。
所以，很明显的方向就是把它们合并，这样就不会造成这种混淆。我知道这也是大家一直在讨论的事情，就是把它们整合到一起。有人管他叫超级 up，我真希望他没说过这话。因为现在我每天每时每刻都得听人提超级 up，我们会熬过去的。但这是不是那种我们别叫它超级 App，但思路是不是就是一个人们去做所有事情的地方是这个大致想法吗？
还是说还没定？对我觉得我们现在看到的是它是个很好的大本营，它是个很好的地方，能让你追踪所有在不同界面上要做的事。有些事儿你完全在 App 里完成，有些事 App 会帮你打开其他 App 去做。App 可以连接 Excel，它里面确实有个电子表格编辑器。这对那些在 OpenAI 做财务模型要融几十亿美元的人来说够用吗？
大概不够，所以 A P P 会直接跟你桌面上的 Microsoft Excel 插件对话。等它干完活，你就可以关掉 Excel。所以这不只是说我们在屏幕上画个框，所有事儿都得在那个框里发生，而是这个东西应该成为你的一个家。你在那里开始工作，结束工作，自动化工作，它会调用你需要的任何工具。有个很好的故事。
我们最初发布 Codex App 时，在这个房间里拍了一些视频。我们的内部 DX 摄像师 Brent 后来接到任务要剪辑所有这些视频，他用 Codex 剪完了所有视频。这算是早期那种“哇，大家拿这东西在干什么”的时刻。他决定开始用 Codex 的过程很有意思。他一开始只是好奇 Codex 能不能剪视频。
Codex 本身不是视频编辑器，它里面没有任何那种界面，但他能理解他用的是 Premiere Pro。它可以通过编辑 Premiere Pro 里画面背后的文件来做一些剪辑，但没法做所有事。所以 Codex 很自然的就给自己做了一个扩展，可以装进 Premiere
Pro，然后它就能跟那个扩展对话，说：“Hey Premiere Pro 扩展，能不能帮我把 Premiere Pro App 里的这个标记改一下？
”我们看到这一幕的时候，觉得挺疯狂的。这是个很好的模式，有这些专门工具，各自专精某个领域。所以，我们想在 Codex 和现在的 ChatGPT 上同时做两件事：一个是，我们怎么跟你已经在用的这些工具无缝交互？我们不需要给你造一个更好的视频编辑器。但 Codex 和 ChatGPT 可以用那个视频编辑器，它可以跟它交互，把活儿交给他。
那我们怎么做到这一点？通常是通过连接器 Computer Use，甚至像这个例子里的扩展，然后还有 Dan Shepard 的那边的事儿，就是嘿，我有这些 Web App。你可以点来点去用，但我想能在 Codex 里打开它们，让 Codex 在上面做更多事。所以这差不多是两种互为镜像的模式，我们同时在大力做这两件事。
这个 premier 的故事我觉得很有意思，因为它是另一个例子，说明对这些 AI 的工作要更有野心一点。你可能不知道，也许他们能做这件事，差不多就是去试试，去试试，看他能不能搞定。我要带我们进入博客里一个常驻环节，我叫它“失败角”。想问你的问题是：大家看到像你这样的人一路高歌猛进，一直在增长，一切都在赢。
Codex做的这么好，职业生涯这么疯狂，一切都在往上走。大家可能看不到那些不顺利的时候，看不到你推出过哪些失败的东西，所以这些故事对大家来说很重要，让他们知道不是一直都在赢。能不能讲一个你职业生涯中失败过，但让你学到了很重要的东西的故事？听你这样描述，我自己感觉挺逗的。这大概是我第一次不觉得自己在失败。
我做了很长时间的创业公司创始人，最后基本上是把公司拆开卖掉了。就是那样，好几年很苦，在强监管的领域。整件事感觉就是一直在失败。我去了另一家创业公司，我们想做些AI工具，同样是在一个相当封闭、受监管的行业。那感觉就是一次又一次的尝试，然后行不通。所以对我来说，我其实失败过很多次。有时候就是某个时间点，技能、热情、市场时机刚好对上了。
我们做这个项目要把 Codex App 的经验跟 ChatGPT 结合起来，这中间不知道有多少次微小的失败，我们觉得就该长这样，然后扔到 Slack 上，就出现一个两千条消息的讨论串，说我们有多蠢。这就是我喜欢 OpenAI 的一点，大家会直接告诉我们。在内部，当我们在产品上搞砸的时候，没有人会留情面。
这也是为什么外部产品一直相当不错，因为它经历了这些两千条消息说这太烂了的循环。我在走到这一步之前，大概失败了十到十五年，所以我现在每天仍然很惊讶事情进展的这么顺利，而且我知道这一点，但。我觉得这对大家来说很重要。你可以有很多事情不顺利，然后事情开始变得超级顺利，我们就继续往前走，继续学习。我想这本身就是一个教训。
好，说到这里，我们到了非常激动人心的闪电问答环节。我有五个问题要问你，开始吧。你发现自己最常向别人推荐的两三本书是什么？老兄，我现在当爸了，我是有小孩的人了，所以我就。我也不知道，有一本叫《咕噜牛》，我拿我小孩当挡箭牌。天哪，我家孩子最近也迷上《咕噜牛》了。我们弄了个睡前流程表，现在就是穿睡衣、刷牙、读书、看《咕噜牛》，然后裹着小毯子。
对，这书真不错。我现在读的其他书也是这种风格。其实《咕噜牛》不算差，我觉得里面有些道理。说的真好，不过每本童书都跟死亡有关，不是谁吃谁就是谁杀谁，总少不了那种坏的谋杀的情节。是啊，还有毁灭。小孩儿就是喜欢暴力，哪怕他们自己不觉得那是暴力，那些词对他们来说就是能制造故事、弧光和兴奋感。好吧，选得好，咕噜牛，我现在攒了一堆书没读，真的得全看完。
你家孩子还喜欢别的童书吗？还真有，我对童书挺了解的。我最喜欢的一本童书很老了，叫《The Big Orange Splotch》，大概是这个名字，你可以查查，特别好，去买吧。如果你讨厌 H O A，更要去买。讲的是一个叫 Plumbean 先生的人住在一条街上，所有房子都一模一样，整条街非常整齐。有一天，一只鸟把一大罐橙色油漆掉在他家房子上，他心想：“去他的，我豁出去了。
”于是他去商店买了油漆、吊床、鳄鱼，把房子彻底翻新了一遍。邻居们气坏了，你知道的，ho啊，房产价值什么的。其实这本书不是讲后A的，但我个人非常反对后A。故事真的很酷，然后邻居们一个接一个去找他聊天，喝一种他们称之为柠檬水的东西。但那柠檬水特别有说服力，因为邻居们一个接一个都开始改造自己的房子了。有个人把房子弄成了船的样子，我觉得这是本好书，大家尤其在新手阶段都应该读一读。
我听到的关键词是能动性，能动性没错，你可以直接去做，直接去做，太棒了。好，我们继续。最近有特别喜欢的电影或剧吗？如果你有时间看的话。神奇校车回来了，在Netflix上是新的动画版，有Kate McKinnon配音。因为Friso老师现在成了Friso教授，他还在，但不是主角了。Kate McKinnon配新的主角Friso老师。
我一直很喜欢神奇校车，他又回来了。我从来没看过，我个人没时间看电影，所以我就一集接一集的看Netflix上那种一小时的剧。你知道大家那种看剧方式吧，就是刷剧。我坐不住，没法坐下来看完一整部电影，但可以一集一小时的连着看。对我就是这样，那种方式挺上瘾的。你最近有没有发现什么特别喜欢的产品？这个答案可能不太好，我感觉我每天都在发现我们自己的产品。
说的也是，我觉得 Linear 做的特别好。在 Codex 之前，Linear 是我最喜欢的软件产品。你们是用 Linear 来做规划吗？理论上是。你有没有特别喜欢的人生格言，在工作中或生活中经常会想起来？我想问问每一个跟我共事的人这个问题，因为我觉得我不是那种爱讲格言的人，但别人会告诉我，我有些话老是挂在嘴边。
对我们之前聊的时候，就有好多小亮点让我印象深刻，我都融进这次对话里了，所以我完全能理解。好，最后一个问题，你做过PM，做过设计师，也做过工程师，这三个角色里哪个最难？我可以挑起一场战争吗？可以，可。我不知道，我觉得他们都非常不一样。让一个人觉得难的东西，可能对另一个人来说很简单。关于这个问题的看法太多了，比如这个铁三角未来会变成什么样？
设计师是不是要完了？设计师该不该写代码？PM是不是没戏了？我们是不是不再需要工程师了？因为PM会把所有代码都写了，还是说设计师要转做PM了？好像每个人都要完蛋，又好像每个人都回来了。我不知道，我觉得现在出现了一些融合，一些流动性，这也让人耳目一新，也很棒。尤其是对那些有能动性、想把事情做成的人来说。
同时，就像我们聊过的，有些东西不应该消失，但我认为人们应该找到那些值得做的事，然后自己去琢磨在这些事上该做什么。这个结尾太棒了，Andrew，非常感谢你来参加节目，谢谢，各位再见，非常感谢大家的收听。如果你觉得这期节目有价值，可以在 Apple Podcast、 Spotify 或者你常用的播客 app 上订阅，也请考虑给我们打个分或者写条评论，这对其他听众发现我们的节目非常有帮助。
你可以在 LinusPodcast 点 com 找到所有往期节目或者了解更多关于节目的信息。我们下期再见。我喜欢 Brand 在 Premiere 里的那个用法，太酷了！我也用过 Codex 的编辑功能，来了来了，就是很简单的事儿。比如，你能不能帮我把这段剪成三段？如果对话里有停顿，Codex 的第二个麦克风能理解这个。
基本上，我们觉得每个任务都是这样开始的。产品本身不是为这个设计的，但它本质上是一个能写代码的空白聊天机器人，所以什么都能做。问题是，让它做什么才是有用的？对人们只需要对项目有好奇心，有一个明确想达成的结果，然后把 Codex 当作实现这个结果的平台，看看会发生什么。因为这么做没有任何风险，就几个 token，几个 token。
当然，如果你在 OpenAI 工作，这方面的风险就小一些。你问过有哪些技能重要？其实很多人都在问这个。然后你也聊过那种刚毕业的超级新人跟你现在这套固定流程之间的关系。我不知道该给什么建议，但如果有一条，就是别死守你现在的流程，要死守的是你独特能交付的成果，然后去改流程，去尝试。你一直守着我最懂 Figma 自动布局，你在干吗呢？
对，因为 AI 以后这方面会比你强。你一直在抛出有意思的观点，留着这句。要在 AI 时代成功，需要的自我认知程度高得离谱。确实，这也是为什么我不敢说事情以后就是这样。我父母是思想开放的人，事业也很投入，但在这里行得通的东西，放到所有人身上不一定行得通。这话怎么说都不太好听。来这里的人是自我筛选过的，是那种我自己会琢磨下一步该做什么的人。
而大多数人不会是新事物的早期采用者，而且老师要重新学东西也挺烦的，就是那种又来又得学新东西的感觉。对我讨厌重复，这是我个人的问题，这也是为什么我永远成不了最好的媒体人，因为我讨厌重复自己说过的话。完美，讨厌重复的人当创始人挺惨的，因为你必须重复。首席副读官，所以对我来说，如果每天能用不同的方式做我的工作，我超爱。
但不是每个人都这样。你给自己的职业找到了产品契合度，对，没错，就是这样。我没法谈判，因为我就是不想干别的。太厉害了，好，谢谢你。