Andrew Ambrosino：OpenAI Codex 负责人谈产品工作新形态

00:00OpenAI 有 90% 的人使用 Codex。不是 90% 的工程师，而是整个公司 90% 的员工。

00:06对，你前几天发推说，希望把 Codex 做成有史以来最好的桌面应用。

00:12是的，Codex 的质量标准必须高到让你打开应用做下一件事时毫不犹豫，让它成为自然而然的选择，就像人们习惯打开浏览器标签页一样。

00:24确实如此。我知道你们的使用量纪录不断刷新。

00:28我也不确定，走着瞧吧。很多人似乎喜欢这个应用。

00:31你觉得为什么 AI 和最前沿模型目前不擅长设计？

00:36我觉得设计更难评估，因为品味中人的因素是反馈机制的一部分。就目前的技术而言，这一点似乎仍遥不可及。

00:46如今的产品团队和几年前相比，形态有什么变化？

00:50OpenAI 的每个人都很有行动力、点子多，所以大家都在构建各种东西。并不是大家职能不同，而是流程倒过来了。实现本身已经不再昂贵；不如说，品味才是。

01:05你觉得每个人都包揽所有工作、角色坍缩的情况会出现吗？还是我们仍会大致划分职能？

01:11有些事让我担心。我听过不少公司说：“我们要取消产品岗位，所有人都只负责构建。”那之后会发生什么呢……

01:22今天的嘉宾是 OpenAI Codex 应用的产品与工程负责人 Andrew Ambrosino。Codex 正成为人们构建产品以及处理非产品事务的首选应用，例如整理电脑文件、起草文档、数据分析和阅读邮件。（00:01:39）节目最后还会有一段停录后的片段，现场制作人谈自己如何在剪辑工作中用 Codex。（00:01:49）从今年一月以来，Codex 使用量增长六倍，每周活跃用户超过 500 万。我猜这个数字很快就会过时。在 OpenAI 内部，几乎 100% 的员工每周都用 Codex，而且不只是工程师。（00:02:06）Andrew 做过设计师、工程师、产品经理，如今正在开发越来越多人用来构建产品的应用。（00:02:15）开始之前，别忘了访问 lennysproductpass.com，Lenny’s Newsletter 订阅者可免费获得一年精选 AI 产品。下面请听 Andrew Ambrosino。（00:02:33）Andrew，谢谢你来做客，欢迎来到播客。

02:37谢谢邀请。

02:38这是少见的线下播客，我很少这样录制。看看效果如何。

02:42走着瞧。

02:42看看大家会不会更喜欢这种形式。准备聊天时，我问你最希望听众从中得到什么，你说想谈谈 AI 如何改变产品工作的形态。（00:02:52）你所在的可能是最前沿、最拥抱 AI 的软件团队之一，能很好观察未来趋势，以及其他团队一两年后可能的样子。如今的产品团队与几年前相比，形态有什么变化？

03:09作为领导者，眼下构建这些产品最难的一件事，是我脑中的流程发生了反转。很多人也谈过：任何人都能构建任何东西。现在我认为，只要从零开始和模型对话，不论哪家模型，都能搭出想要的功能。这不是软件最难的部分，但很令人兴奋。（00:03:44）给人无限 token，OpenAI 每个人行动力强、点子多，于是大家都在构建。过去的产品流程则相反：先研究、构思，也许做原型。即使摆脱瀑布式开发，流程仍默认实现成本很高。（00:04:20）因此人们用文档、研究和原型提前降低实现风险，因为过去默认原型和设计更便宜。如今完全变了。（00:04:35）现在一个亟需开发的功能可能同时有 90 个彼此不协调的团队在探索和实现。

04:48简而言之，流程倒过来了。不是角色、关注点或技能消失，而是实现不再昂贵；不如说，品味才是。（00:05:07）真正重要的是策展：90 种尝试里哪些做得好？哪些该整合？该如何包装？要不要并入另一个功能？开关里该包含多少选项？

04:50本期节目由冠名赞助商 WorkOS 呈现。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay 等成功公司都由 WorkOS 提供支持。（00:05:38）构建企业产品的人都知道，集成单点登录、SCIM、基于角色的访问控制、审计日志等功能有多麻烦。WorkOS 以现代开发者平台和即插即用 API，扫清这些障碍。（00:05:55）我投资的创业公司几乎每一家向企业市场拓展时都会使用 WorkOS，因为它们最好。无论你是想拿下首个企业客户的种子轮公司，还是正在全球扩张的独角兽，WorkOS 都是让产品满足企业需求、释放增长的最快路径，就像企业功能领域的 Stripe。访问 workos.com 开始使用，或去他们的 Slack 提问，那里有工程师回答。（00:06:22）WorkOS 通过出色 API、完善文档和顺畅体验，帮助你更快构建产品。（00:06:33）“品味”都快成口头禅了，之后想再聊。你说 OpenAI 有 90 个原型，这很有意思。以前遇到一个想法，大家会先写文档，对吧？

05:23是的。很多产品领导者说 PRD 已死、原型当道，但我并不认同。（00:07:17）实现成本变低，人们很容易直接做原型，尤其非工程师，过去不会或没时间写代码的人，会说：“PRD 过时了，我直接给你看。”（00:07:45）但工程师也容易写出一大堆不值得读的文档。这不是批评写文档，而是实现变得充裕后，必须根据要表达的观点选择媒介。（00:08:05）如果目的是澄清模糊的产品方向，文档可能合适；如果想让大家试用并压力测试交互模式，原型更合适。关键是选对媒介。

06:46一位播客嘉宾提到“原初笔触”这个概念，我一直记着。艺术家在画布上落下的第一笔，就是你开始回应的对象；一切都从这笔延展开来。（00:08:47）有时原型不该是第一步，否则大家会被它锚定，而不是考虑其他想法或更大方向。所以不应一概宣布不写作、不写文档、不写 PRD；这些在特定场景下仍有用。

06:46过去媒介会自带信号，说明项目进展。如果东西像已上线产品，通常意味着项目已到后期、假设经过验证、设计师看过，商业目标也合理。（00:09:32）过去必须先降低风险才能拿到资源。现在则不同。可以有原型，也可以有文档，但要说明各自表达什么。（00:09:51）别过度依赖一个原本只是探索用途、却看起来能上线的原型。视觉上准备好了，不代表它符合研究、用户需求或业务目标。（00:10:08）品味体现在判断做什么、怎样呈现、如何实现目标、选用何种媒介，这适用于所有领域。

07:05好品味具体指什么？是决定投入什么，还是做出来后判断是否合适、是否应该调整？（00:10:37）能具体谈谈好品味、好判断力是什么样吗？人们听到会说：“我有品味。”实践中怎么表现？

08:28我昨天看到一条推文，可能来自 Linear 的产品负责人，也可能记错了。推文说，人们过分强调品味中的审美部分，并以 Paul Graham 为例：他显然很有品味，但穿工装短裤。（00:11:11）品味有很多细微差异，既包括审美，也包括系统思维：某个东西如何融入整体，属于什么方向和主题，以及如何呈现。（00:11:35）更广泛的背景也很重要。当然，品味也包括判断交互动画是否符合要表达的语义，比如动画太急促就不匹配。这很重要，我可能过度关注这一点。（00:11:52）但还包括“我们应该做成什么？”如果什么都能构建，目标是什么、该如何实现？这才是品味真正要回答的问题。

09:04AI 越来越强、承担更多工作后，人类思维还有哪些价值？品味显然是其中之一。我也觉得 AI 目前非常不擅长真正的设计，产出并不好。

10:26是的。

10:46它很少能做到“完美了，就是这个”。结果往往更像“这是 Claude Design 的风格”“这是 Codex Design 的风格”。你觉得为什么目前 AI 和最前沿模型不擅长设计？它们会追上来吗？未来会不会有一天我们惊呼：“天哪，设计已经完成了”？

12:06我觉得这和品味有关。AI 也许能生成视觉稿，但判断某个方案是否契合产品、用户和整体方向，仍需要更广的背景与人的反馈。

12:24是的。

12:24很少出现“就是这个，完全做对了”的时刻。结果往往看得出是 Claude Design 或 Codex Design 的风格。你觉得为什么当前 AI 和前沿模型还不擅长设计？它们会达到让我们惊叹、认为设计已经解决的程度吗？

12:40是的。我认为这背后既有一些实际原因，也有更难解决的问题。我不在研究组织，替我们这样说可能会被同事批评。我认为设计比软件更难评估。建立一个训练循环，让模型学会什么是好设计、什么是坏设计，比检查代码能否编译、是否完成预期功能更繁琐、更费力。（00:13:09）因为品味中人的因素是反馈机制的一部分。我还认为，过去实验室会优先让模型擅长能加速 AI 研究的事情。早期编程模型能写出正确代码，显然会加速研究；但设计就很难以同样方式纳入这个飞轮。这并不是说设计不重要，而是它没有直接进入那个循环。（00:13:46）这些是实际层面的原因，最终会消失，模型会相当擅长设计。但也有更模糊、更难解决的问题。我有个简短清单。其中之一是，文化会影响人们对好设计的判断。你还记得大概去年，每个新网站都像是在抄 Linear 的网站吗？（00:14:15）Linear 网站设计和品味都很好。如果模型做出那样的网站，我会觉得进步惊人；但如果模型每次都输出 Linear 网站，那就不是挑战所在。设计比软件工程更重视新意。软件工程更希望复用已知模式；设计则需要一点随机性和新颖感。（00:14:48）我在 Codex 应用早期花了很多时间写代码或监督写代码。即使模型设计能力提升，软件设计和代码之间仍有一层抽象关系：代码里这个角落的组件应该和下面那个组件共享哪些东西。（00:15:14）这不仅仅是要求模型成为更好的设计师，尤其不只是视觉设计，而是更深一层的抽象。比如公司明天改品牌，浅层处理是逐个更新 263 个组件；深层处理则是理解外观不同的两个东西，在语义上有什么关系，它们同属列表、使用相同样式、向用户传达同一种交互模式。（00:15:48）我觉得目前的技术还难以触及这一抽象层。Codex 应用去年 11 月启动时，我们没有全职使用它；现在所有事情都用它，这是一个过程。但我们如今用它做的事情也变了。刚才的问题是什么来着？

16:17我知道，这是个很棒的回答。谈到设计和创造力，Codex 应用刚推出时是个前所未见的新东西。它不是终端，也不是集成开发环境，而是一个能写代码、也能查看代码的聊天应用。（00:16:32）你说得对，AI 很难提出一种全新的编程范式。至少目前，人脑的价值似乎仍在于创造新事物，而不是套用已有模式。

16:47是的，我完全理解。让我们为人类大脑鼓掌。

16:50至少目前如此。准备节目时，你说你听了 Jenny 那期节目，她负责 Claude Code 和 Cowork 的设计。她提出了一套观点，认为设计流程已经过时。（00:17:02）她说没有时间做设计，事情发展太快了；先构建，设计则在过程中引导。听起来你对设计流程有不同看法。

17:13我和 Jenny 在很多方面可能意见一致。我不喜欢传统设计流程本身，也认同她说它已经过时。我在 AI 出现前就真心不喜欢那套流程。

17:27你能简要描述一下大家所说的那种设计流程是什么吗？

17:31我几年前经营创业公司时会招聘设计师。当时有篇略带讽刺的文章讲“案例研究工厂”：在搜索引擎结果页盛行的年代，设计师被教导重视流程胜过一切，甚至胜过最终结果。（00:17:55）人们以为，只要走完这套流程，结果就一定好，流程能保证质量和影响力；甚至即使你不喜欢、没人使用，只要它走过流程，就算好设计。（00:18:13）这套流程包括用户研究、发散和收敛，框架本身没错，但一直有点学院派。我认为实现速度变快后，它的问题更加暴露。（00:18:31）这套流程默认实现成本高，只能构建一次，所以开发前必须穷尽研究问题空间和解决方案空间。（00:18:51）后来有了 Figma、Origami 等工具，人们能更早加入交互原型，模拟接近生产环境的体验。高管甚至会开玩笑说：“能不能直接做个原型，就期待它能用？”（00:19:15）但原型确实成为了设计流程的一部分。现在的问题是，几乎所有实现都可以放进这个流程，很多旧假设因此不再成立。（00:19:31）你会看到一个高度打磨的原型，看起来像是随时能发布。公司里的人看了就会问：“现在能上线吗？”但实际上可能仍处在设计初期，团队在进行多种探索，却没人明确说出来。（00:19:52）90 个人可能各自做出很精致的想法，但这恰恰就是现在的设计流程。真正令人担心的是把设计流程和媒介、具体工具绑定起来。设计师现在只是多了几种完成流程的工具。（00:20:12）你可以直接在现有产品里做改动并进行 A/B 测试，也可以把它当原型。很多公司会做一个“迷你版”产品，你可能在 Twitter 上看过 Baby Cursor。我们也有 Baby Codex：大幅简化的代码库，却能模拟生产应用的交互，因此更容易用氛围编程去探索。“侧边栏能否这样工作？”“能否从这里滑出一个面板并加入群聊？”它是设计流程里很有用的工具。（00:20:46）所以说设计流程已死，既对也不对。如果你执着于工具和流程每天的具体做法，那确实已经过时。但完全抛弃流程，或者不再说明“我们现在处在流程的哪一步”，反而比以往更危险。

21:11很有意思，你的背景几乎涵盖所有职能。看你的 LinkedIn，做过工程师、设计师、产品经理、创始人。现在你负责桌面应用。我想设计不归你管，对吗？有独立的设计团队，还是向你汇报？

21:25看这一周怎么安排。

21:26好。

21:27我们合作很紧密，提倡大家坐在一起、嵌入团队。至于汇报关系，我也说不清。

21:35汇报线每周都会变。Codex 应用的设计流程是什么样？

21:38关于职能坍塌，已经有很多讨论，甚至说这是身份认同危机，职能都不存在了。我们没有看到这种情况。不过，Codex 团队的职能重叠确实比公司其他部门、甚至经济中的其他行业更多。我认为部分原因是这是面向工程师的技术产品，所以设计师懂工程语言，产品经理懂技术，也会写代码。（00:22:08）Alexander 有计算机科学硕士学位，我可没有。我们确实看到很多职能重叠。我们描述团队协作的一种方式是：不同岗位之间的重叠远超以往。人们不再由“设计到哪里结束、工程从哪里开始”这类边界定义，而更多由实际工作内容的平均分布来定义。（00:22:37）如果统计设计团队成员做的所有事情，会发现他们写不少代码，也做不少产品工作，但平均而言他们的重点仍落在设计区域。流程也是如此，Codex 应用的整个开发都受到内部试用循环的影响。（00:23:02）我们都希望尽可能在应用里完成更多工作，即便它暂时还不是最好的工具，这样它才能变成更好的工具。大家通过使用应用来共同做设计、发现“哪里不好用”。我们甚至常常不先改进流程来让产品更适合工作，而是直接在不舒服的状态下坚持使用。这种情况每周都在变化。

23:30我很喜欢这个观点：你是什么岗位，取决于你把时间花在哪些工作上。大部分时间做产品工作，那暂时就是产品经理；做工程工作，那暂时就是工程师。OpenAI 是第一家把员工称为“技术人员”的公司吗？

23:46不，我觉得这个说法可能从 Xerox 开始。我实习的第一家公司 Upthere 也这么称呼员工，这种做法已经存在很久了。只是现在更常见；它一直是研究型公司的传统。

24:01明白了，它源自研究领域。但我觉得这也预示着未来：大家都叫技术人员，职能并未固定，不属于 PM、工程或设计部门。（00:24:16）你觉得长期来看会这样吗？职能会继续存在吗？PM、工程和设计仍然有各自技能，大家也会认同自己是设计师吗？还是说“构建者”会成为新称呼，最后每个人都会做所有事，不再划分职能？

24:38有些事情让我担心。有些公司会极端地追逐大家宣称即将到来的趋势。取消职能概念的危险之一，是可能错误地抹掉这些工作本身是专业领域、拥有可知最佳实践的事实。（00:25:10）我听过不少公司说要取消产品岗位，这在我看来是个糟糕主意，然后大家都只做构建者。这样一来，产品这个学科经过长期积累的最佳实践、经验和失败教训、流程都会被抛弃，因为大家会想：“我写了点代码。”这不是好结果。（00:25:37）我欢迎取消“这不归你管”这种职能边界，但需要平衡。首先不是每个人都能做所有事，无论工作广度还是深度都不可能，这也是经理不会消失的原因。（00:25:58）不是每个人都能做所有工作。每个专业领域都有技能要求；我觉得很多工程师容易忽视这一点，以为工程是一门技能，写代码才算专业，其他岗位只是在随便发挥。事实并非如此。会用 Excel，不代表你就能在财务团队工作。

26:24我觉得还有一点是：“你真的想做这类工作吗？”

26:27是的。

26:27那我想不想做呢？

26:28我认为更重要的是，如今换职能更容易，学习最佳实践也更容易；一个人是否胜任某个岗位，也不再和能否使用特定工具绑定。更重要的是，能否调整到合适的思维模式，学会什么有效、什么无效，然后专注做好它。（00:26:52）我曾经很长时间觉得自己不该做软件工程师，因为我不在乎汇编语言，也不想死记 TypeScript 语法。过去这些岗位里一直有这种门槛，把“会用某个工具”当成“擅长这项工作”。这种门槛正在消退。我觉得人们把这些变化夸大了。

27:22Codex 团队现在是什么构成？有多少工程师、设计师、产品经理？

27:29每次有人问我 Codex 团队有多少人，你记得我怎么回答吗？我会说：“大概 10 人到几千人之间。”听起来像打趣，但也是真的，因为我们把它看作所有人共同工作的结晶。（00:27:45）模型研究、模型使用计算机操作和浏览器的能力、模型个性，以及前端基础设施和产品设计，所有这些工作共同构成了这个产品。当然，我们也不会每天接受几千个人随便提交的代码。（00:28:07）我们有几十名工程师，设计团队大概是其一半，也有几位产品人员，不过这里的产品工作更像区域防守。我认为 Codex 或桌面团队成员普遍具备主动性和品味。（00:28:29）许多人曾是创始人，或在大公司做过创业型工作，也有不少人品味出众。OpenAI 允许团队规模较大，所以我们并不是说“不要管理”；但团队里主要还是个人贡献者，我觉得这很好。

28:47你用“区域防守”来形容产品工作，很有意思，也对应了设计工作的变化：产品人员负责管理和协调。能展开讲讲吗？产品岗位的区域防守具体是什么样？

29:00我和 Alexander 多次聊过这个比喻：如果两名产品人员贴得太近工作，往往不是好信号。产品组织更应该像受力导向的活动，先问：“哪里有空缺？”（00:29:22）在这个需要策展、引导和协调的新环境里，想法不断涌现、混乱很多；自上而下的全年规划行不通。（00:29:36）所以需要有品味的人从构想到产品方向一路引导，也要覆盖整个公司。大家要分散开来，明确谁擅长什么，并留出空间，确保没有遗漏。（00:29:55）同时填补空缺时，我们希望招到具备产品思维的工程师。我们不希望大家写完代码后还需要整个团队评审，才能确保产品一致性。所有人都应该具备这些能力，只是每个人深入钻研的领域需要变化。

30:14我不断听到类似观点：如今最有价值的人之一，是能凭借好品味把一个想法从构思一路做到完成的人。

30:28对。

30:28也就是始终推动项目、执着于把它做好，成为你所说的那种主动性强、品味出众的人。这正是你们招聘和判断谁能在新时代表现出色的标准吗？

30:40是的，我认为这正是核心。它也体现了我对个人贡献者和管理的看法：管理不会消失，也不是人人都只做个人贡献者，而是现在每个人多少兼具两种角色。个人贡献者不再逐字敲代码，而是在管理某件事、管理智能体，管理各部分工作如何汇合并完成目标。（00:31:14）团队经理做的事也一样，只是管理粒度不同。我当然会看候选人是否掌握专业领域，也会看其品味：在拥有无限 token 的情况下，不能只制造粗制滥造的内容。你必须能在无限内容中分辨信号与噪声。

31:38提到了规划。事情发展太快，路线图很难制定，我想你们尤其如此。

31:47大家经常因此对我很不满，是的。

31:50变化不停发生，你们如何规划团队工作？会考虑多远？计划长什么样，是电子表格还是 Markdown 文件？最终产物是什么？

32:00我们在这方面没什么革命性做法，也谈不上多聪明。基本原则是，离现在越近的计划，细节越多。不是说我们不做九个月后的计划，只是远期计划必须很模糊。（00:32:17）现在给九个月后的计划添加任何精确度都是虚假的，只会浪费时间。可以谈一些方向，但实际发生的往往和计划不同。我这里说的是应用产品，不代表研究组织；在应用侧，十一月规划的事情也许十二月时仍成立，但最后未必真的发生。（00:32:41）规划确实很难。通常需要判断模型预计何时能做到什么。（00:32:49）我上一家公司开始用模型驱动功能开发时，产品流程就不太适用了。我们会先列出未来一两年感兴趣的事情，逐一做原型，判断哪些现在已准备好，其他的则先放着酝酿。（00:33:18）每当模型出现新突破，就换上新模型重新尝试。因为功能是否可行，关键在模型是否够聪明，而不在功能本身的形态。（00:33:31）Codex 应用就是个好例子。我很确信，二月发布的 Codex 应用如果十一月就准备好并发布，市场表现肯定会失败。两者唯一的区别是十一月到二月之间模型进步了。我认为这很说明问题：形态完全相同的产品，仅仅差几个月，结果可能截然不同。

34:04本期节目由 Mercury 呈现。这家与众不同的银行深受 30 多万名创业者喜爱，如今还推出了 Command。我使用 Mercury 六年多了，从没想过离开。（00:34:17）Mercury 就像是由产品人而非银行家打造的银行。它让发送发票、转账和为团队创建虚拟卡变得轻松，甚至很有趣。你的银行有 API、终端原生 CLI 或适配 AI 的 MCP 服务吗？我想没有。（00:34:38）他们最近推出了 Command，这是直接内置于 Mercury 的对话界面，可充当财务运营助手。我用它转账、查看哪些类别开支最多、分析现金流。（00:34:58）今天我还问它过去一年某个赞助商给我带来多少收入。只要问“过去一年我从 X 赚了多少？”，十秒后就能得到答案。太酷了。访问 mercury.com 了解更多，几分钟即可在线申请。Mercury 是金融科技公司，并非 FDIC 承保的银行。银行服务由 Choice Financial Group 和 Column N.A. 提供，两者均为 FDIC 成员。（00:35:17）这档节目常谈到先构建目前还不能正常工作的东西，等模型变好它就能工作。另一个主题是提高雄心，挑战更大的目标。你们的做法就是先构建一堆暂时不能工作的东西，留着等模型赶上来吗？

35:39我们确实有很多这种做法。难点有时在于，必须明确说明设计流程处于哪个阶段。人们仍有惯性思维：“我都写了代码，所以该发布了。”不，不是这样；你现在只是有了一个可以用未来模型测试的产物。（00:35:57）应用内浏览器就是一例。回想 Atlas，我们曾让智能体在其中运行，很有意思。此前 ChatGPT 里也有 Operator，虽然效果不好，但想法很好。从 Operator 到 Atlas、Codex、ChatGPT，可以看到它们本质上是同一个功能，换用更聪明的模型后，结果就完全不同。（00:36:28）所以我会提醒大家不要固执地说：“它现在不行，所以功能很糟。”也可能只是还没准备好。（00:36:37）研究领域总想追求最雄心勃勃的愿景，比如“理论上，模型最终能做这个”。但应用产品不能只靠理论上限。（00:36:52）最初的 Codex Web 是让模型接到任务后离开一段时间，完成后再回来汇报。听起来并不激进，但当时它执行得不够好。它能写代码，但这种交互形态来得太早。（00:37:15）后来 Claude Code 出现，完全本地运行、不依赖云端，也不假装自己接近通用智能。它会提问、会停下来，不是把人生全盘委托给它。这种方式更适合当时模型的能力。（00:37:32）当时我们过于沉迷通用人工智能愿景。我常想到这个教训。过去产品上市失败，会告诉你产品形态或表达方式有问题；现在可能需要发布六次才真正可行，而且形态可能完全不变。

37:55听起来构建产品现在要考虑很多变量：模型和研究的进度、模型能力增长的时间表、人们理解云端软件这种新方式的程度、如何让用户为新功能做好准备，还有团队本身能构建什么。（00:38:13）Codex 的例子又回到雄心这个话题。你们会鼓励团队更有雄心吗？毕竟模型能做的远比我们想象的多，但有时雄心太大，市场还没准备好。（00:38:26）你会推动团队挑战过去看似难以实现的事情吗？

38:34这是个核心挑战。已有产品或功能之后，人们很容易发现各种小瑕疵——

38:43做微优化。

38:44而且他们应该这么做。Twitter 上的人会提醒我们这一点，我也感谢他们。大家应关注已有功能，让它更可靠、更好。但我们也保持自下而上的探索文化。（00:38:56）因为就像 Codex 应用在某种程度上颠覆了 ChatGPT，未来的尝试也可能颠覆 Codex。设计过程应承认这一点。一个团队不一定能同时擅长颠覆式探索和维护现有产品质量；因此必须设计流程，让两者都能进行。

39:18拉远来看，AI 影响产品构建的进程变化惊人。过去我们手工编写每一行代码，现在 AI 能写 100% 的代码；你说如今编程变成引导 AI。（00:39:41）如果问“代码里有多少是 AI 写的”，也许更应该问“我得引导它几次”，这才是 AI 时代的编程。如今有智能体和循环，你看到的最前沿团队最新是怎么构建软件的？是循环吗？还有什么外界可能不知道的做法？

40:07是的，我觉得循环编程已经是上周的事了。我们之前聊过，大家总会问：“产品里有多少代码是 AI 写的？”这个问题很难回答，因为如果还用去年的标准，我们现在的产品 100% 都是 AI 写的。更有意义的问题是：代码是在监督下还是自主编写的？这是完全不同的事。（00:40:36）我欢迎标准不断变化，因为这意味着产品在进步。我们探索过很多自主开发软件的方式，也做过不少 harness 工程试验，比如让系统夜间自动清理代码库。模型现在普遍有个问题：它们通常会增加复杂度。（00:41:01）如果各家研究团队听得到，希望模型能更擅长删除代码。但如果完全让开发自动驾驶，这就会成为人和代码库两方面的问题。如何教模型该做哪些功能、忽略哪些、把哪些合并并重新界定？如何教它构建正确抽象？（00:41:31）这些都在进步，但还没到设一个循环说“改进应用”，再让它监听 Twitter、Slack 和邮件就能自行完成的地步。我们正在努力实现。

41:49你认为未来会发展到那一步吗？只要给它“增长、获胜”这样的目标就行？

41:54或者说“帮我赚钱，让我成为亿万富翁”。

41:58“赢下市场”。

41:58我不知道。我不会轻易说永远不可能或一定会发生。

42:05你作为产品和工程负责人，平时如何使用 AI？

42:10是的。

42:11有哪些用法可能是人们还没意识到的？

42:15我觉得自己现在有世界上最棒的工作。其中让我觉得有趣的一点是，开发最初版 Codex 应用时，我个人的目标是让它成为我写代码的工具。我当时想：“必须把它做得足够好，让我能用它开发 Codex 应用。”那时 Codex 还是开发工具。（00:42:39）我们很快就建立起内部试用的循环：我做不到某件事，就把产品修好以便做到；做到了之后，又能做更多事。然后我们发布了。（00:42:54）接下来的挑战是，人们开始用它做不同类型的事情，我需要扩大团队、招人并提供帮助。我的工作随之变化，应用的角色也需要变化。（00:43:07）我开始做更多产品探索，找出观察大家工作进展、把方向偏离的项目拉回正轨的合适机制。我也仍然写代码。（00:43:22）我努力让自己的使用方式与正在解决的问题保持一致。后来我需要建立一份电子表格来建模，也需要深入研究这一研究领域过去的所有工作，为下一代产品做准备。（00:43:41）五月前后有一系列发布，为 Codex 加入了应用内浏览器、计算机操作和创建各类产物的能力。我认为那是一次“Codex 几乎人人可用”的发布，也可以说是我们第一次用氛围编程协调整个发布。（00:44:01）我有一份 Notion 文档列出所有待办事项，再自动收集 PR、Slack 频道的进展并更新状态追踪表。当时我觉得自己处于产品发布管理的最前沿，如今这已很常见。（00:44:22）简而言之，我如何使用 Codex，取决于我的工作变成了什么，以及如何让它能完成我需要做的一切。我早上会查看日报，里面汇总我加入的 3000 个 Slack 频道里发生的事，告诉我哪些需要关注。我可以回复：“好，给我五个问题，我来回答。”然后就能处理。

44:49你是怎么设置的？别人要如何搭建这种工作流？听起来太棒了。

44:53很多功能目前还处于探索阶段。我现在会创建自动化或定时任务，让它浏览我的 Slack 频道，重点关注我认为重要的事情。（00:45:12）我会提供需要留意的类别和背景信息，然后设成自动任务。最开始几次运行可能需要我引导。好在这个应用不要求我去找指令编辑页面。（00:45:27）我只要说：“下次运行时请关注这个，降低那条工作流的优先级”，或者“这件事发生了，但日报没提到，以后请纳入这一类内容。”我可以一路指导它调整通知方式。

45:44太棒了。

45:45不过未来有个核心问题，是聊天机器人这种形态本身。我知道怎么设置，也有时间去设置，因为这对我来说是产品探索。但如果你不在 OpenAI 工作、不负责开发产品，就不应该还要花时间摸索这些。我们得找到更合适的产品形态。

46:06我听下来觉得，人们可能没意识到 Codex 应用也能像大家很兴奋的 OpenClaw 一样工作。你只要跟它说：“帮我设置这个；每天检查这件事，再告诉我结果。”

46:19完全正确。

46:20这一能力开始融入各种产品，太棒了。用户可以直接在应用里说：“我要建立一个自动化任务，让它查看我的 Slack，并完成这些事。”

46:20是的。

46:32很好。

46:32应用会告诉你它将为你设置好。如果没有 Slack 连接器，它会问：“可以添加 Slack 连接器吗？”你点同意即可。（00:46:43）最低限度是：如果你不知道怎样在应用里完成某件事，至少能直接问它。我认为这还不够，但这是我们最低限度该做到的。

46:52举个例子，我用 Codex 做了个小应用，过滤收件箱里的垃圾邮件。每封新邮件进来后，它都会判断这是不是我不想看的主动推销或陌生开发邮件，然后加上标签并移到别处。（00:47:08）要设置这个功能，其中一步是进入 Google Cloud 控制台，配置各种 API、触发器之类的东西。你用过那个界面吗？特别麻烦又慢。

47:20是的。

47:20我就想：“要不直接让你来做呢？”于是我说：“好，帮我做这个。”然后它就开始操作……这就是你说的计算机操作。我以前从没见过它在我的电脑上这样做。它直接接管电脑，开始点击操作。

47:32它会说：“有没有连接器无所谓，我直接开始点。”

47:35对，它自己摸索并完成操作。看着它这样做真的很不可思议。

47:39设计连接器之间的决策边界很有意思：什么时候用应用内浏览器，什么时候用已连接的 Chrome 扩展，什么时候让智能体直接操作电脑。我们是在不断摸索中找到答案的。

47:52前几天我看到一条很棒的 Twitter 讨论串，清楚描述了这三种方式以及各自适用场景。有个人总结得很好。

47:58个人工作流特别有意思，有些做法确实很实用。大家尝试各种方案，各自构建个人系统。你问这里的每个人在做什么，答案都不一样。但随后会出现一些共同主题，我们会想：“这应该成为应用里的正式功能。大家都在设置的这个东西，应该直接做成产品功能。”（00:48:23）记忆功能就是一个例子。很多人，包括其他公司的员工，会说：“我建了一个 Obsidian 知识库或 Notion 空间，让它按我的想法搭建个人知识宫殿、把信息放进去。”但我不认为每个人都应该被迫这么做。产品应该提供通用记忆功能。（00:48:45）还有些东西则是个人工作流程，适合由个人自行设置。我们一直在辨别哪些个人工作流适合纳入产品，哪些就应该留作个人做事方式。哪些应该变成通用功能，哪些不应该？

49:06这正体现了你之前提到的品味和判断力。我想聊聊浏览器操作，因为大家可能没意识到它有多强大、能用于什么场景。这让我想起 Every 的 Dan Shipper 上节目时预测，我们会开始用 Codex 从内部操作 SaaS 应用，而不是打开 Chrome——

49:29我知道，他每天都在 Slack 上找我，让我帮忙做各种事。

49:33你觉得事情会发展到这一步吗？zeolite——我们都在 Codex 应用里使用 Notion、Linear 和 Salesforce，由智能体协助工作？还是你认为方向不同？

49:46这很有意思。我们尝试过几种浏览器交互形态：Operator、ChatGPT 智能体模式、Atlas，现在还有桌面应用里的内置浏览器，也可以安装 Chrome 扩展，让应用连接到 Chrome。（00:50:07）我们试过很多形态，也学到不少。还有许多很琐碎的实际问题。应用最初是 Electron 应用，里面的内置浏览器体验有点笨拙。（00:50:22）最初它只是为了开发，方便测试开发中的前端。我们还特意说：“它没有其他用途，这是开发者工具。”后来我们改用为 Atlas 浏览器提供支持的 Owlstack。（00:50:37）于是现在支持多标签页，也有企业安全能力，让你能登录各种网站。我们一直在迭代。一直难以确定的是，浏览器应该是什么形态？它是否只供智能体使用？（00:50:54）也就是说，你照常打开 Chrome 浏览，而当你向桌面应用提要求时，它打开一个可控浏览器，速度快、不受 Playwright 延迟影响。还是我们想把这个应用做成一切都能处理的平台，让用户把它当浏览器？（00:51:11）这两种方式都有取舍。现成经验不多，大多数浏览器都是独立的顶层产品，有自己的标签页。于是会产生许多琐碎但棘手的问题，例如快捷键：该兼容 VS Code、Chrome，还是我们自己的操作，或者 Linear？（00:51:33）我们希望用户能沿用一些肌肉记忆，但市场上不同产品已有许多子形态。我们究竟该怎么做？

51:42这正好说明应用有多难设计：既要让所有人都能使用，从从未构建过东西的普通用户，到像 Peter 这样用 OpenClaw 编程的高级用户。

51:58我不确定能不能说服 Peter 用这个应用。我觉得他可能是最后一个——

52:02他是终端的死忠。

52:04……终端死忠。

52:04好。

52:05但我会继续努力。

52:06好，暂时拉远一点，聊聊整体方向。你们准备把这些带向何处？Codex 的愿景是什么？一两年后、十年后它会是什么样？

52:18最初，Codex 是命令行工具，后来我们决定开发应用。起初对应用形态不确定，但相信它能成为开发者工具。（00:52:35）它不是集成开发环境，而是恰到好处的界面，像聊天机器人但不止于聊天；可以看代码，但不能直接编辑。（00:52:45）一二月间、正式发布前，我们开始内部试用，发现工程和研究工作流的产品契合度很明确。（00:53:08）大家非常喜欢。我们想把质量做好再发布。但公司内部也开始探索其他工作流，想看看这套编程智能体的能力。（00:53:23）营销、传播、财务、法务等职能的人都开始使用 Codex，尽管它对他们并不友好，会展示代码，还会询问是否允许运行 ripgrep 等开发工具。（00:53:41）显然这不是适合他们的界面，于是我们想把 Codex 加到 ChatGPT 桌面应用和 Atlas 浏览器里，让经验更通用，成为一般知识工作工具。（00:54:02）试了一阵后出现最让人头痛的问题：没人愿意离开 Codex 应用，去用那些据说适合其他用户的应用。我认为开发者工具和一般知识工作工具并非非此即彼，其中有许多细微差别。（00:54:25）就像一个人的岗位取决于实际工作内容，产品形态也可以如此。（00:54:36）做 Excel 工作的人不想看到 Git 仓库信息；但我们也能从他们正在做的事了解其工作类型。可以从简单功能开始，再按需增加复杂性。（00:54:53）这不代表没有模式。用户可能需要不同模式来整理内容、理解如何进入体验。但我们相信，当前形态适合承载深入的垂直专业工作。（00:55:13）我们和财务、科学、法务团队合作，认为只要建立合适的可扩展原语和通用模型，就能用它完成许多工作；挑战在于如何泛化。（00:55:33）这又回到“怎样打造最好的桌面应用”。它究竟是开发者工具 Codex，还是 ChatGPT？这就是我们的思考。

55:47Codex 应用很成功地让大家知道它的存在，而且很好用、很有趣，于是很多人开始用它而不是 ChatGPT。显然，方向是把两者结合，避免用户困惑。这就是产品未来吗？

56:06有人称它为“超级应用”，我真希望他没这么说，因为现在我每天都得听人谈超级应用。我们会熬过去的。

56:17不称超级应用。大方向是让人们有一个地方处理所有事情吗？还是仍未确定？

56:23我认为它会成为很好的工作中枢，帮你追踪分散在不同界面的所有任务。有些事情直接在应用里做，有些由应用打开其他工具完成。它可以连接 Excel，在应用里提供电子表格编辑器。（00:56:47）但对在 OpenAI 做数十亿美元融资模型的财务人员来说，这可能不够，于是应用直接调用桌面版 Microsoft Excel 插件，完成后你可以关闭 Excel。（00:57:03）这不是说所有事情都必须在一个矩形界面里完成，而是让应用成为你开始、结束和自动化工作的中枢，并使用需要的工具。（00:57:21）Codex 应用发布时，我们在这间屋子拍了一些视频。内部视频制作人 Brent 负责剪辑，后来他用 Codex 剪完所有视频，这让我们很惊讶。（00:57:41）他起初只是好奇 Codex 能不能剪视频。Codex 不是视频编辑器，也没有对应界面，但它发现 Brent 使用 Premiere Pro，能修改 Premiere Pro 背后的项目文件来完成部分剪辑，却无法做所有事。（00:58:08）于是 Codex 自己构建了一个可安装到 Premiere Pro 的扩展，再通过扩展发指令修改软件里的标记。我们看到时觉得不可思议。（00:58:28）专业工具各有所长。我们同时尝试两件事：让 Codex 和 ChatGPT 与用户已有工具无缝协作，而不是重做视频编辑器；它们能调用工具、交接工作。（00:58:47）这通常通过连接器、计算机操作或扩展来实现。（00:58:59）Dan Shipper 提出的另一种模式是，把用户已有的网页应用打开到 Codex 里，让 Codex 帮忙完成更多事。这两种模式几乎相反，但我们都在探索。

59:18Premiere 的故事让我想到，AI 工作可以更有雄心。你不一定知道它能不能做，但可以先试试看。（00:59:31）接下来是固定环节“失败角”。人们看到你现在成绩很好、Codex 大获成功，却不一定看到失败。失败经历很重要，因为并非总是一路成功。你职业生涯里有哪些失败让你学到重要一课？

60:03听你这样描述我很有意思。也许这是我第一次不觉得自己正在失败。我做了很久创业公司创始人，最后基本是把公司拆卖了。那几年很艰难，行业监管严格，整个过程一直像在失败。（01:00:28）后来我去了另一家创业公司，在同样监管严格的行业尝试 AI 工具，还是一次又一次试了又失败。我确实失败过很多。有时只是到了某个时间点，技能、热情和市场时机终于吻合。（01:00:52）如今把 Codex 应用经验与 ChatGPT 结合的项目，也经历了数不清的小失败。我们提出一种形态发到 Slack 上，随后会有两千条消息讨论我们多么愚蠢。（01:01:13）我喜欢 OpenAI 的一点是，内部有人会毫不留情地告诉我们产品做错了。正是这些循环让最终产品变得更好……

61:27两千条？太糟了。

61:28我在这之前失败了大概 10 到 15 年才走到今天，所以现在事情进展顺利，我每天仍觉得意外。

61:38大家很需要听到这一点：很多事可能都不顺利，但后来也可能突然变好。关键是继续前进、继续学习。（01:01:48）接下来是闪电问答。我有五个问题。

61:53好。

61:54[00:01:54 无法辨认] 你最常推荐给别人的两三本书是什么？

61:59你看，我现在是家长了，孩子还很小。

62:02不错。

62:04我也说不准。有一本叫《咕噜牛》，我会读给孩子听。

62:07天啊，我家孩子最近也迷上《咕噜牛》了。

62:10是吧。

62:11我们有睡前流程表：穿睡衣、刷牙、看书、读《咕噜牛》，然后盖着小毯子睡觉。

62:18是的。

62:18这本书真不错。

62:19我现在读的其他书也都是这类。

62:23好，轻松的书。

62:24其实《咕噜牛》不算差。

62:25不是。

62:25我觉得里面有些道理。

62:26是啊，很可爱。不过每本儿童书好像都在讲死亡：有人吃了别人，有人被杀，总有暴力和毁灭。

62:35孩子喜欢暴力，即使他们不觉得那些词是在描述暴力……

62:40这就构成了故事起伏和紧张感。

62:42对。

62:42好，《咕噜牛》选得不错。

62:44我现在有一堆待读书单，得找时间全读完。

62:49还有什么孩子喜欢的童书吗？

62:52好。其实我对童书很熟。我最喜欢的儿童读物是一本很老的书，名字大概叫《大橘色斑点》之类。去搜一下，真的很好，去买一本。如果你讨厌业主协会，也一定要读。（01:03:09）故事讲的是 Plumbean 先生，他住在一条所有房子都一模一样、整整齐齐的街上。一天，一只鸟把一大罐橘色颜料掉在他家屋顶上，他就想：“去他的，我干脆彻底改造。”于是他去商店买来颜料、吊床、鳄鱼等，把房子彻底翻新。（01:03:29）邻居们非常不满，担心业主协会、房价之类的。虽然这书不是在讲业主协会，但我很反感业主协会。后来邻居一个接一个去找他，喝了书里称作柠檬水的饮料——那柠檬水显然很有说服力。结果每个人都开始重新装修自己的房子，有人把房子改成船。（01:03:49）我觉得这是本好书，尤其适合那些反对一切新变化的人读。

63:54我听到的是“主动性”。

63:56正是主动性。你可以自己动手做事。

63:59自己动手做。太棒了。好，我们继续。最近有没有特别喜欢的电影或电视剧？如果你有时间看的话。

64:05Netflix 上《神奇校车》回归了，是新动画版。Kate McKinnon 配音，因为 Ms. Frizzle 现在成了 Professor Frizzle，她仍会出现，但不再是主角。Kate McKinnon 配演新的 Ms. Frizzle。我一直喜欢《神奇校车》，现在它回来了，而且非常——

64:22我从没听说过这部作品。挺酷的。

64:24我个人没时间看电影，所以会连续看 Netflix 的一小时剧集。你知道那种看法吧？

64:33追剧？

64:34我无法坐下来完整看一部电影，然后再接着看一小时剧集……这是个点子。这种方式还挺让人上瘾。

64:41最近发现、特别喜欢的产品是什么？

64:44这个答案很糟糕。我觉得我每天都在发现我们自己的产品。

64:49真好。

64:49这太糟了。

64:50虽然听起来有点老套，不过——

64:50我觉得 Linear 做得很好。直到现在，至少在软件产品里，Linear 是我最喜欢的。

64:59你们用它做规划和协调吗？

65:01理论上是。

65:04你有没有在工作或生活中常常想起的人生格言？

65:07我想问问所有和我共事过的人这个问题，因为我觉得自己不是会说格言的人，但别人会告诉我一些我经常挂在嘴边的话。

65:16是的，录制前聊天时有好多小观点让我印象深刻，我已经把它们融进这次对话里了。所以我完全理解。（01:05:23）最后一个问题。你做过 PM、设计师和工程师。三种角色里，哪一个最难？

65:33你是想挑起争论吗？

65:35是的。

65:35我不知道。我觉得三种职能很不一样，对一个人来说困难的事，对另一个人可能很容易。关于设计、产品和工程这三者的未来有太多说法：设计师是不是没用了？设计师该不该写代码？PM 是不是要被淘汰？PM 都会写代码了，还需要工程师吗？还是设计师会变成 PM？（01:06:03）一会儿说人人都完了，一会儿又说人人都能大展身手。我不确定。职能确实在融合、变得流动，我觉得这既令人耳目一新，也很好，尤其对那些有主动性、愿意去做必要之事的人。不过，就像我们之前说的，有些专业领域不该消失。我认为大家应该找到值得投入的事情，再去弄清楚如何行动。

66:32这种总结很漂亮。Andrew，非常感谢你来做客。

66:35谢谢。

66:36各位再见。感谢收听。如果你觉得节目有价值，可以在 Apple Podcasts、Spotify 或常用的播客应用中订阅。也欢迎评分或留下评论，这能帮助更多听众发现节目。你可以在 lennyspodcast.com 查看往期节目或了解更多。下期再见。

67:02我很喜欢你讲 Brent 用 Premiere 的那个故事。

67:04是的。

67:04太棒了。我也用 Codex 帮忙剪过片子。

67:07就是这样。

67:09都是些简单操作，比如“能不能把这段剪成三个部分？”或者对话里有停顿、第二个人开始说话时剪开，Codex 就能理解。

67:19我觉得很多工作都始于这样的故事：产品不是为这件事设计的，但它像一个能写代码的空白聊天机器人，似乎什么都能做。问题是，哪些事情值得让它做？

67:34是的，人们只需要对项目保持好奇，明确自己想要的结果，再把 Codex 当作平台去试试会发生什么，因为几乎没有风险。

67:34对。

67:34只花几个 token。

67:49几个 token。不过如果你在 OpenAI 工作，当然在这方面的风险要低一些。

67:59你问过一个人——其实问过很多人——哪些技能重要，也聊过“能力超强的新毕业生”与……

68:06对，没错。

68:07我不知道你是否非得坚持现在这套流程。虽然我不知道该给什么建议，但如果只能说一点，那就是：“别迷恋你现在的具体流程。”应该专注于自己能独特带来的成果，然后改变流程、尝试新方法。

68:28你一直在贡献金句。

68:29如果你自称“最擅长理解 Figma 自动布局”，那你到底在做什么？

68:33对，因为 AI 也会比你更擅长这个。

68:36是啊。

68:36你一直说出很有意思的话。

68:38这段保留。

68:39成功使用 AI 需要非常强的自我认知。

68:39确实。

68:39是。

68:46这也是我不敢轻易说“未来一定会怎样”的原因。我会想到我的父母，他们思想开放，也在工作中很投入，但适用于我们这群人的做法，不会适用于所有人。这话不好听，但事实如此。

69:00是的。

69:01不过在这里工作的人本身就有选择性：他们往往会主动想“下一步该做什么”。但大多数人群并不会成为新技术的早期采用者。

69:13而且一直重新学习新东西，也确实挺累的。

69:13是啊。

69:18“天啊，又要重新学一个新东西。”

69:22我讨厌重复。这是我个人的问题，所以我可能永远成不了优秀的媒体人，因为我不喜欢反复讲同样的话。

69:31完美。

69:32如果你讨厌重复，当创始人可就难了，因为你必须重复讲。

69:35首席复读官。

69:36所以，如果我每天都能用不同方式完成工作，我会很喜欢。但这并非适合所有人……

69:44你为自己的工作找到了产品市场契合度。

69:46是啊，确实如此。我没法协商换工作，因为我不想做别的工作。

69:54太棒了。

69:55是的。

69:55谢谢。