砍掉PM、全员做Builder？OpenAI Codex主管：人人皆可做产品就是“毒鸡汤”，别总觉得别的岗位只是在摸鱼！

现在最贵的东西，叫“品味”。

编译 | 王启隆

出品丨AI 科技大本营（ID：rgznai100）

安德鲁·阿姆布罗西诺（Andrew Ambrosino）在硅谷折腾了十几年，做过设计师、写过代码，也自己创过业。但大多数时候，他觉得自己是个失败者——他的公司最后基本是拆碎了贱卖掉的。

这种在泥潭里摸爬滚打的体验，直到他接手OpenAI 智能体产品 Codex时才算熬出头。今年 1 月以来，这个产品的周活暴涨了 6 倍，突破了 500 万。最夸张的是在 OpenAI 内部，甚至有接近 100% 的员工每周都在用它，包括根本不懂代码的财务和法务。而四月份左右，泼天的热度让 Codex 突然出圈，接上了今年“龙虾潮”的机遇。

这种爆红也彻底颠覆了团队做产品的方法。以前，写代码是最贵的，所以大家得先写一堆需求文档和原型来规避开发风险。现在，用 AI 写代码便宜到近乎不要钱。在 OpenAI 内部，经常有 90 个完全不搭界的团队，同时手搓出 90 个功能一模一样的产品原型。当“实现”不再是瓶颈，如何在这 90 个原型里看出哪个有灵气，哪个能和系统对上，就全凭产品经理和设计师的“品味”（Taste）了。

在与播客 Lenny's Podcast 的最新对话中，安德鲁结合自己在泥潭里摸爬滚打十几年的教训，聊了聊为什么他们不取消产品经理分工、为什么要在模型还没变聪明前就提前做功能，以及一个剪辑师用 Codex 给 Premiere 自动写插件的真实故事。以下是他在实战中踩出来的几个最清醒的认知：

• 当写代码便宜到近乎不要钱，“品味”（Taste）就成了最值钱的东西。AI 让任何人都能在几分钟内搓出一个高保真的功能原型。但在无限多的原型里，知道哪一个体验更对、哪一个动效不会和系统起冲突，甚至在 90 个点子里拼凑出一个完美的方案，这考验的是人真正的审美和判断。
  

• 以为能用 AI 跑出几行代码，就觉得不需要产品常识和管理方法，这只是工程师的自嗨。

• 跟风取消产品经理、让所有人自称“建造者”是个非常愚蠢的决定。
  

• 产品的死活不再由外壳决定，而是取决于底层模型的智力什么时候跨过那个坎。同样的 Codex 应用，在 2 月发布能月月翻倍，但在 11 月发布就注定完蛋，这中间只差了几个月模型智力的代际升级。

• 做产品的人得学会宽容：有些功能现在跑不通，不代表它是个坏主意，它可能只是在等底层大模型变得更聪明。

• 真正的“高智能”不是让用户去适应聊天框，而是让 AI 顺着你既有的工具去摸索。
  

• AI 的终点不是把所有软件塞进一个黑色的对话框里，而是像水一样渗透进你习惯的所有工具。

领取地址：https://s.csdn.cn/4nPsOp

人人皆可手搓原型的时代，比拼的不再是开发速度，而是审美

主持人：我们在准备这次聊天时，我问你最希望大家从这场对话中获得什么，你说是：AI 正在如何改变产品工作的形态。

你所在的团队，可能是全世界最前沿的 AI 软件团队之一，所以你对未来走向有一个特别有意思的观察视角——其他团队在一两年甚至更久之后，大概也会走向那里。

和几年前相比，现在一个产品团队的形态是什么样的？

Andrew Ambrosino：现在，作为一个带队做这些产品的人，最难的事情之一，就是我心里所说的那种“流程反转”。很多人其实都提到过这一点：现在是谁都可以构建任何东西，对吧？

我现在基本相信，如果从零开始，只要你跟这些模型交流——无论是我们的模型，还是别家的——你都能把你想要的功能先搭起来，对吧？这当然不代表软件开发本来就很难的那部分不存在了，但这件事真的很酷。

而我觉得，这造成了一个环境：所有人都在不断地做各种东西，对吧？

主持人：你给了大家无限 token。

Andrew Ambrosino：OpenAI 的每个人都非常有主动性，也都有很棒的点子，所以每个人都在构建各种东西。

而回头看我们长期以来一直在运行的产品流程，它其实是反过来的，对吧？先做研究、再做构思，可能会有一些原型。即便我们已经走出了瀑布式开发，但整体仍然带着一种底层假设：实现是昂贵的。

所以你要做的是，在前期通过文档、研究和原型，把实现相关的风险尽可能都消掉，因为原型和设计更便宜——这就是当时的默认前提。

但现在变了。彻底变了。现在，对于某个我们迫切需要推进的功能，我敢肯定有 90 种不同的探索正在发生。我也敢肯定有 90 个彼此没有协调的团队，正在各自实现、各自尝试，对吧？

所以，如果要给一个简短答案，那就是：一切反过来了。

这并不是说人们在做根本不同的角色，或关注根本不同的事情，也不是说技能集消失了，或角色本身突然不存在了。而是说，一切反过来了，对吧？现在真正不再昂贵的，其实是实现。真正昂贵的，容我这么说，是品味。

更准确地说，是“策展”这个过程。就像：在那 90 次尝试里，哪些东西是好的？哪些值得融入这个功能的其他部分？我们该如何去定义它？它是不是应该成为另一个功能的一部分？切换开关里到底该有几个分段？

原型做得太逼真，反而容易让人不敢跳出框架去思考

主持人：“品味”这个词现在太热门了。我们等会儿再回来聊这个。

你刚刚提到“90 个原型”的说法很有意思。我想确认一下我理解得对不对：OpenAI 里有个想法在流动。过去大家会做的事情是写文档——“这是我们要做的东西，这是这个功能，这是这项策略。”

而你现在描述的是——而且这听起来完全说得通——人们直接做一个原型。你的意思是，公司里很多人其实都有相似的想法，现在他们不再写文档，而是各自做一个小原型，于是就形成了 90 个不同的东西，大家可以去看、去挑，最后决定：我们想沿着这个方向走。是这个意思吗？

Andrew Ambrosino：确实有很多这种情况。而且不只是发生在这里。你也看到很多产品负责人说：PRD 已死，原型当立。其实我一点也不认同这个说法。

我觉得现在正在发生的一件有意思的事是：因为在所有媒介上，实现都变得极其便宜，所以人们非常容易直接跳到原型——尤其当你不是工程师的时候，对吧？尤其是当你以前不会写代码，或者从没对写代码感兴趣，或者根本没时间时。你就会特别想说：“PRD 已死。让我直接做给你看。”

但我同时也观察到，对于工程师来说，现在也很容易去写大量文档——大量不值得别人读的文档。

这不是在讽刺写文档的人。我的意思是：如果实现变得极其充裕，那么更重要的是，你要为你想表达的观点选对表达形式。

如果你要表达的是：某个模糊领域里的产品清晰度，那么它可能真的应该是文档。如果你要做的是：把某个东西交到大家手里，让大家试一试，去验证某种交互模式是否成立，那它就该是原型。

但我觉得现在有趣的地方恰恰就在于：选对媒介，变得极其重要。

主持人：你这么说的时候，我想到播客里有位嘉宾分享过一个词，叫 primal mark（原初笔触）。当设计师、画家或者艺术家在一幅画或一件艺术作品上留下第一笔时，那第一笔就会成为你之后不断回应的对象。之后的很多东西，都会顺着那第一笔一路流淌下来。

所以我从你这里听到的是：有时候原型反而是错误的第一步，因为之后你就只是在回应这个原型，而不是回应另一个想法、另一个更大的想法。我很喜欢这个观点。

所以现在大家都在说：“好吧，算了，不写东西了，不写文档了，不写 PRD 了。” 但你的意思是，对于特定场景，它们其实依然有价值。

Andrew Ambrosino：对。我觉得还有一点是，在以前那个世界里，媒介本身其实隐含了很多关于“这件事目前处于流程哪个阶段”的信号，对吧？

如果你看到一个东西，它看起来已经很像正式上线的应用，那意味着它在流程中已经走得很后面了——意味着前面的假设已经去过风险、设计团队已经看过它、这个方向符合商业目标，对吧？

而现在，这些事情都被拆开了。

以前之所以会那样，是因为如果一件事还没有被充分去风险，你很难拿到资源把它真正做出来。而现在，这一点已经完全被打破了。

所以我觉得现在特别重要的一点是，要开始明确地说：我们可以有原型，也可以有文档——关键是，这个东西到底是在做什么，是否足够清楚。因为正如你说的，你绝对不想对一个本来只是用来探索的东西产生过度锚定，只因为它看起来太像正式产品了——视觉上它也许已经像是 ready for prod，但实际上，它并不符合研究的方向或用户的真实需求，对吧？

不仅是审美，这关乎你选择在什么事情上投入精力，而这种选择，实际上就是“品味”在起作用。而这就是在任何领域都最关键的事情。

主持人：当你谈论“好品味”时，所谓的品味到底是什么？是决定我们该投资什么的判断标准吗？还是说，当你已经拥有某样东西时，你会问自己：这合适吗？这值得推出市场吗？当我们思考什么是好品味、什么是良好的判断力时，这些概念具体又体现在哪些方面呢？因为人们听到这个词，总会想：“哦，我有好品味，我懂我懂——但实际生活中它到底是什么样子？”

Andrew Ambrosino：对，这很有意思。前几天——我实在是太常上网了——有条推文，我记得好像是 Linear 的产品负责人发的，我可能记错了，如果说错了先向原作者道歉。他说，人们过于强调“品味”里审美的那一部分。

他举了 Paul Graham 做例子，说 Paul Graham 显然有很好的品味，但他穿的是工装短裤，对吧？所以我们确实得稍微拆解一下，“品味”到底指什么。

这里面有很多细微差别。我觉得你刚才说的那些，其实都算。品味当然包含审美层面，但它也有系统思维的一面：这个东西如何嵌入整个系统？它还涉及“我们要去哪里”“这属于哪个更大主题的一部分”；还涉及你该如何呈现它。

很多时候，品味其实来自更广阔的上下文。当然，品味也包括一些更细部的东西，比如：这个交互动效和它本该承载的语义其实并不匹配，对吧？它的节奏太利落了，但它想表达的内容其实不该是这种感觉。

这类判断非常重要，而我可能在这方面花了过多精力。但还有一个更大的问题是：这个东西本来应该长成什么样？如果我们现在什么都能做，那这里的目标到底是什么？我们该怎么走到那里？

我觉得，这其实才是真正的“品味问题”。

为什么 AI 仍然不擅长设计？

主持人：当我听到这样的讨论时，我总会想：随着 AI 越来越强、越来越好、做的工作越来越多，人类大脑还有哪些地方依然有价值？而我感觉“品味”就是其中之一。

顺着这个话题我还会想到一点：AI 现在在真正的设计上还是很差。AI 的输出并不好。

Andrew Ambrosino：对。

主持人：很少会让人觉得：“就是这个了，他们做对了。” 更多时候你会说：“哦，这一看就是 Claude 风格的设计，这一看就是 Codex 风格的设计。”

你为什么觉得，AI 和最前沿的大模型今天就是不擅长设计？你觉得它们未来能做到吗？你觉得我们会不会走到这样一天：天啊，设计这件事也彻底完成自动化了？

Andrew Ambrosino：对。我倾向于认为，这背后既有一些现实层面的原因，也有一些更难攻克的问题。

我不在我们的研究组织里。我这么说大概会被研究团队骂。但我觉得，设计确实比软件更难打分一点。你要建立一个闭环，让模型知道什么是好设计、什么是坏设计，这件事比起“代码能不能编译”，要更繁琐，也更费劲，对吧？

因为你所需要的反馈机制里，人的“品味”因素是不可或缺的一部分。

我还觉得，实验室从历史上看，往往优先投资于那些能加速 AI 研究本身的能力。在早期代码模型时代，这一点特别明确：模型如果能写出正确的代码，就能直接推动研究进展，对吧？而对于设计，你很难提出同样直接的论证。

这并不是说“设计不重要”，而是说它并不直接处在那个飞轮里。

这些是现实原因，而这些原因会慢慢消失。模型在设计上最终会变得相当不错。

但还有一些更模糊、更难的问题，解决起来会非常棘手。我脑子里大概有一个简短列表。

第一，什么算“好设计”，其实带有文化层面的成分。你应该记得去年吧，那时候每一个新网站都像在抄 Linear 的官网，对吧？Linear 的官网：设计很好，品味很好。如果模型每次都能做出那样的东西，我会说：哇，这已经非常惊人了，是巨大跃迁，对吧？但如果我的模型每次输出的都是 Linear 官网，那问题并没有真正解决。

在软件工程里，你几乎反而希望模型更偏向已知模式，对吧？但在设计里，情况恰恰相反：不，你需要一定程度的随机性和新鲜感。

还有一点，对我来说——我在早期 Codex 应用上花了很多时间写代码，或者监督代码——即使模型变得擅长设计了，软件设计 and 实际代码之间仍然存在一个抽象层，它们之间有一种彼此咬合的关系。

比如说：界面这个角落里的东西，在代码库里应该和下面另一个地方的东西共享 X、Y、Z 这些抽象，对吧？这和“模型需要成为一个更好的设计师”其实是两回事。它当然也涉及视觉设计，但深度要大得多。

它关乎抽象本身。如果明天我们公司做了一次品牌重塑，浅层的问题是：我们得把 263 个组件一个个改掉。深层的问题则是：这两个外观不同的东西，它们之间的语义关系是什么？它们都出现在列表里，它们都有这种风格，它们都在向用户传达某种交互模式。

我觉得，以当前技术来说，这层抽象依然显得有点遥不可及。

所以我觉得，在整个过程中，我们从 11 月开始做 Codex 应用，那时我们还没有全天候使用它。现在我们什么都用它做。这中间经历了一个过程。而如今，我们在使用它时真正做的事情，也已经和以前不一样了。

所以你刚才的问题是什么来着？

主持人：我知道。我得说，这个回答太精彩了。

说到设计和创造性，Codex 应用刚出来的时候，真的是一种全新的东西。

主持人：以前没人见过这样的东西。它不是终端，也不是 IDE，而是一种能写代码的聊天界面，而且你还能看到代码。

就像你刚才说的，这种情况下很难指望 AI 直接说：“来，这是一整套全新的编码范式。” 这让我觉得，至少现在，人类大脑依然有价值的地方，就在于创造力，在于提出新的东西，而不只是沿用过去已有模式。

Andrew Ambrosino：对，我完全同意。此刻，我们还是该为人类大脑鼓掌。

主持人：在我们准备这次节目时，你提到你听了 Jenny 那期节目。她是 Clockwise and Co 的设计负责人之类的角色。她有一个完整观点：设计流程已经死了。现在已经没有时间做设计了，事情发展太快了。就是先做出来，设计只是在过程中边走边纠偏。

而你似乎暗示，你对“设计流程”这件事有点不一样的看法。

Andrew Ambrosino：Jenny 和我在很多地方可能其实是有共识的。我本来就不是那种拥护传统设计流程的人。我认同她说“它已经死了”这个判断。而且说实话，就算在 AI 出现之前，我也不喜欢那套流程。

主持人：你能不能快速描述一下那个流程？让大家知道我们说的“设计流程”到底是什么。

Andrew Ambrosino：几年前我自己创业的时候，我们也做设计招聘。那时候出过一篇有点嘲讽意味的文章，讲“case study 工厂”。一到这个阶段，设计师们就被灌输流程本身才是最重要的，过程的工整大过一切，甚至是产出的结果本身。

仿佛只要一件事走过了这套流程，就有两件事自动成立：第一，它一定是好的；也就是流程本身保证质量，保证影响力。第二，只要它走过那套流程，那它就是好的——哪怕你不喜欢，哪怕没人用它。

它一直有点学院派意味，但我觉得当下这个时代，正在把它失效的地方暴露得特别清楚，尤其是在实现速度极大提升之后。

而且再说一遍，这套流程其实建立在一个前提上：实现很昂贵，你通常只负担得起“真正构建一次”。所以你必须在动手实现之前，完整而彻底地遍历问题空间和方案空间，对吧？

后来，随着 Figma、Origami 以及各种工具出现，我们看到一种变化：你可以把交互式原型更早地拉进流程，用来提前获取一些洞察。你可以去模拟生产环境。

后来甚至出现了一种梗：高管们会说，“那我们干脆直接做个原型不就行了？” 然后还期待它真的能跑起来。但这件事又的确是真实发生的，对吧？这逐渐成了设计流程的一部分。我们把原型前移进来了。

而现在的问题是，你甚至可以把整个实现都前移进来。这就导致大量底层假设之间出现错位。再一次，当你看到一个非常精致的原型，看起来已经像是随时可以发布了，足够多的人在公司里看见它，就会说：“那我们现在能发了吗？” 但实际上，我们还处在非常早期的设计阶段，只是没人明确说出来。

这就是我们现在面对的大量多人并行探索，对吧？90 个人可能都会有这个想法，做出来的东西也都看上去很成熟，但实际上：不，这本身才是现在的设计流程。

真正可怕的，是把设计流程和媒介绑定在一起。如今设计师有了更多工具来跑这个流程。你甚至可以直接把东西放进当前产品里，做 A/B 测试，或者把它就当作一种原型。

现在很多公司都有一个所谓的“baby version（宝宝版）产品”的概念。你在 Twitter 上应该见过，比如 baby Cursor。我们也有 baby Codex，对吧？它是一个被大幅简化的代码库，但能近似还原正式应用中的所有交互，因此更适合快速进行 vibe coding，对吧？因为你可以说：“如果侧边栏这样工作会怎样？” “如果这里弹出一个 pane，然后里面有个群聊会怎样？” 或者“如果 XYZ 会怎样？” 对吧？

这就是一个非常强大的工具，而且它已经成了设计流程的一部分。

所以说“设计流程死了”，我觉得既对，也不对，对吧？如果你死死绑定于那套流程每天该怎么执行的具体形式，那对，它死了。你不会过得太舒服。但如果你因此就把流程本身彻底扔掉，或者把“我们现在正处于流程的哪个阶段”这层覆盖视角也一起扔掉，那就错了。因为这件事现在比以往任何时候都更重要。

主持人：这真的很有意思，因为你的背景几乎涵盖了所有职能。别人如果去看你的 LinkedIn，就会发现：工程师、设计师、产品经理、创始人。现在你负责这个桌面应用。而我想，设计似乎并不直接归你管。是这样吗？是有单独的设计团队，还是他们也归你——

Andrew Ambrosino：这要看是哪一周。我们合作非常紧密。我们相信要坐在一起、深度嵌入式协作。至于汇报关系，我不太——

主持人：他们每周都在变化。那 Codex 的设计流程具体是什么样的？

Andrew Ambrosino：关于“角色坍塌”，已经有很多讨论了——那种近乎存在主义式的角色坍塌：“已经没有角色了。” 但我们并没有看到这一点。

我们确实看到了比公司其他部门、甚至整个经济里很多其他地方都更多的“角色融合”，尤其是在 Codex 组织里。我觉得其中一部分原因是，这原本就是一个面向工程师的技术产品，所以我们的设计师“会说工程师的语言”，对吧？我们的产品经理也懂技术语言，也会写代码。

Alexander 甚至有计算机科学硕士学位，而我都没有计算机科学硕士。所以我们确实经历了很多角色融合。

而我们描述这些群体如何协作的一种方式是：如今各角色之间的重叠程度，比以前大得多。大家不再是由“设计做到哪儿结束、工程从哪儿开始”这种边界来定义，而更像是由“他们平均把时间花在哪些事情上”来定义。

所以，如果你把我们设计团队里某个人做的所有事情平均一下，里面会有很多写代码的内容，也会有很多产品相关的工作。但从平均值来看，如果你把它画在一张图上，他们的点大致还是落在“设计”这一侧，对吧？

这其实也和流程有关。尤其是因为整个 Codex 应用，都是在 dogfooding（自我试用、自我使用）闭环中逐渐成型的。

我们所有人都有一种强烈愿望：我们故意忍受不舒服的流程，好让产品本身变得更好。这其实是一个非常不舒服的状态。但每周都在变化。

主持人：我太喜欢这个观点了——“你的角色，就是你把时间花在哪里的平均值。” 如果你大部分工作都在做 PM 的事情，那好，你现在就是 PM。

Andrew Ambrosino：对。

主持人：如果你主要在做工程，那你现在就是工程师。

觉得懂两句 AI 跑通几行代码就不需要产品经理，这只是工程师的自嗨

主持人：我一直觉得，OpenAI 是第一个把大家都称作 Member of Technical Staff 的公司？

Andrew Ambrosino：不是。我印象里这可能最早可以追溯到 Xerox。第一家我实习的公司叫 Up There，也是这么叫的。

这已经存在很久了，只是现在更普遍，尤其是在研究型的公司里。所以，它其实是从研究文化里衍生出来的。但我感觉这其实也是一个信号，预示着未来的方向。所有人都在变成“技术人员（Member of Technical Staff）”，你的岗位边界不再分明。

你觉得在更长远的未来，产品经理、设计师和工程师这些专业岗位，还会作为独立的工种存在吗？还是说，我们会迎来一个“全民皆为构建者（Builder）”的大坍塌时代？

Andrew Ambrosino：这正是我有些害怕的地方。

因为有些公司特别喜欢盲目跟风，一旦外面吹起什么风，他们就恨不得立刻跳上这班车。我听过很多公司说他们要干掉产品经理这个岗位，老实说，这简直是个糟糕透顶的决定。

产品经理是一个有着完整方法论和最佳实践的专业学科，经历了无数次的尝试和失败才沉淀下来。如果你仅仅因为自己用 AI 写了两行代码，就觉得可以把整个产品纪律扔进垃圾桶，那是极其危险的。

我不喜欢用“别越界”来限制团队的发挥，也乐于见到岗位边界变得模糊。但这其中有一个平衡：因为没人能包揽所有的广度与深度。这也是为什么管理永远不会消失。

不同的职能都有极高的专业门槛。很多写代码的工程师会有一种傲慢，觉得只有写代码才是硬核技术，其他岗位都只是在“随便混混（Vibe）”。不，绝对不是这样的。

就像你虽然能用 Excel 算账，但这绝不意味着你能去干财务。

在 AI 时代，转岗和学习最佳实践确实变得容易了。你不需要因为自己不会记 TypeScript 语法或者汇编语言而觉得做不了工程师。AI 正在剥离这些曾经用来划分阶层、制造信息不对称的“工具看门机制”，但它不应该剥离对岗位底层核心能力的敬畏。

大家没必要把这件事说得太绝对、太夸张。

主持人：Codex 团队现在是什么样的？有多少工程师、设计师、PM？目前团队的构成是怎样的？

Andrew Ambrosino：每次别人问我 Codex 团队到底有多少人——你还记得我的回答吧？

主持人：记得。

Andrew Ambrosino：我会说，大概在 10 人到几千人之间。我知道这听起来像个假答案，但某种意义上它又是真的，因为我们确实把这个产品看成这里所有人工作结果的汇聚。

所有和模型研究有关的工作，所有让模型更擅长编码和浏览器使用的工作，所有和模型人格有关的工作，所有前端基础设施相关的产品工作，所有用户侧工作——这一切，最终都体现在这个产品里。

但与此同时，我们也不是每天真的接收几千上万人随便往里提 PR。所以我们确实有一个团队：工程师是两位数，设计那边大概是一半，产品人员有几个——不过在这里，产品更像是一种独立的防守打法。

我觉得 Codex 这边，或者说桌面应用这边，大家身上有一个共同点，就是主动性和品味。很多人以前都是创始人，或者在大公司里做着“创始人形状”的工作。也有很多人的品味非常强。

在 OpenAI，我们允许团队做得很大，所以我们并没有经历那种“这里没有管理”的状态，但团队确实规模不小。大部分人是 IC（individual contributor，独立贡献者），而我觉得这很好。

主持人：你提到一个词叫“区域联防（zone defense）”来形容产品工作，我觉得这很有意思。它和设计上的那种转变也有点映射关系——就像你们更像是在管理和协调。你多讲讲这个吧。对于一个产品人来说，“区域联防”是什么样的？

Andrew Ambrosino：对。我和 Alexander 聊过很多次这个比喻。我们的观点是：如果两个产品人贴得太近地一起工作，往往不是一个好信号。

作为一个产品组织，你其实更希望形成一种“受力分布式”的状态：哪里有空缺？尤其是在这个新的世界里，策展、引导、对齐，才是大量工作的核心；与此同时，周围又充满了混乱——人们到处抛点子，对吧？那种自上而下、规划一整年的方式，已经行不通了。

所以现在更像是：我们需要那些有品味的人，从原初的概念阶段一路将产品引导落地。而这意味着，你基本上需要对整个公司形成覆盖。于是你们就分散开来，说：“好，谁最适合哪一块？我们彼此之间拉开一些空间，这样整个版图就都有人覆盖。”

大概就是这么运作的。然后你去填补空白，会说：“我们希望招聘的是有产品意识的工程师。”

我们不希望变成这样：有一堆人在写一大堆代码，最后为了保证产品一致性，还得整个团队一起重新评审，对吧？我们希望每个人都具备这些能力。但我觉得，人们真正深入钻研的方向，必须发生变化。

主持人：我最近和像你这样的人交流得越多，越反复注意到一件事：如今最有价值的人之一，就是那种能把一个想法从想法一路带到落地的人，而且还具有那种知道“这真的很棒”的品味，能一路护送这个东西，痴迷于把它做得足够出色——就是你刚刚描述的那种高主动性、高品味的人。

这是不是你们在想“我们要招什么样的人、谁会在这个新世界里表现得特别好”时的核心标准？

Andrew Ambrosino：对。我觉得这就是现在最核心的一块。它也和我看待 IC 与管理的方式有关：不是说管理要消失了，也不是说每个人都会变成 IC。而是说，现在每个人某种程度上都同时具备两者，对吧？

如果你是 IC，你现在也不是一个字符一个字符手敲代码，对吧？你其实是在管理某些东西。你在管理智能体（Agent）。你在管理那些正在发生、正在汇聚起来以完成某个目标的工作。

如果你是团队管理者，你做的本质上也是同样的事，只不过颗粒度不同。

我通常会看候选人当然是否真正掌握这门学科，但接下来还要看他们是否有那种品味，能在“你将拥有无限 token”这个前提下，仍然知道：我们不能只是不断制造垃圾。你必须能够在无限内容的世界里，分辨什么是信号，什么是噪音。

主持人：你刚才提到规划。按照现在的发展速度，做 roadmap 规划已经变得非常困难了。

Andrew Ambrosino：对。很多人总是因为这个对我很不满。

主持人：对。因为事情一直在发版，一直在变化，对吧？你们团队怎么做规划？你们会往前看多远？一个计划长什么样？是一张表格？一个 MD 文件？最终产出通常是什么？

Andrew Ambrosino：对。我不觉得我们在这件事上有什么革命性的做法。我们并没有在规划上耍什么聪明。

基本原则是：越短期的事情，越需要细节。任何九个月后的计划加上的任何精确度，都是虚假的精确，只会浪费时间。

你当然可以说一些方向性的东西，对吧？但我们在 11 月能规划到的事情——我觉得研究不太一样，所以我这里不是代表研究团队发言——至少在应用侧、在做产品的时候，11 月制定的任何规划，也许 12 月还成立，但后来发生的事情就完全不是那个样子了。

所以规划真的很难做。

我们通常需要知道的是：我们认为模型会在什么时间线具备什么能力？我在上一家公司时，就已经看到这种转变了：我们开始用模型能力去驱动功能，而传统产品流程就崩掉了。我们基本上只能这样做：把我们觉得未来一两年可能想做的所有事情全部列出来，把它们都做出原型，判断哪些是现在就成熟可做的，然后把其他的先放在那里，继续“焖着”。然后每次模型有新的飞跃，就把那些东西再拿出来，用新模型重新试一遍。

因为决定一个功能好不好用的根本前提，不再是它的形状，而是模型够不够聪明。

Codex 应用就是个很好的例子。我非常确定：我们在 2 月发布的那个 Codex 应用，如果它在 11 月就已经准备好了，那它在市场上绝对会失败。而这中间唯一的变量，就是模型。

同一个产品、完全相同的形态，仅仅因为时间点差了几个月，结果就会完全不一样。

产品的死活不再取决于它的外壳，而是在等底层的模型什么时候变聪明

主持人：这也是这档播客里一直在反复出现的一条主线：去构建那些现在还不能真正工作，但随着模型变强，将来就会工作的东西。与此同时还有另一条主线，就是“更有野心一点”：去做更大胆的事。

所以这是不是你们的一种工作方式？比如：我们先做很多现在可能还跑不通的东西，把它们先放在那里，等模型追上来。大致是这样的思路吗？

Andrew Ambrosino：对。我觉得我们有很多这样的做法。不过有时挑战在于，你必须再次非常明确地知道：这件事目前处于设计流程的哪个阶段。

大家还是会有那种肌肉记忆：哦，我已经把这东西的代码写出来了，所以我们就应该把它发出去。不，不，不——这只意味着你现在有了一个产物，我们可以用它去测试未来模型的能力。

我们在应用里的 in-app browser（应用内浏览器）就是这样。我们当时已经有一个“差不多能用”的版本了。甚至更早在 Atlas 里，我们就已经让 agent 在 Atlas 里面工作了。那挺酷的。再往前，我们在 ChatGPT 里还有 Operator，对吧？那次没有成功，但这个想法本身非常酷。

你可以在 Operator、Atlas、Codex、ChatGPT 之间画出一条线，它们本质上是同一个功能，但仅仅是换了不同水平的智能重新发布，结果就会完全不同。

所以我会推动大家不要太固执，不要一看到“它现在不好用”，就说“这是个坏功能”。不是——它可能只是还没到成熟的时候。

还有一点，尤其是在研究领域，总会有一种冲动：要做到最有野心，要说“好吧，如果从极限角度看，模型最终就是能把这件事做完。” 但在产品侧，这种思路是不成立的。

如果你回到最初 Codex 发布的时候，本质上它其实就是“Codex web”，而且它在交互上做得并不好。它的形态是：你给模型一个任务，它会离开去做，做完后回来跟你说“finished”。听上去也没那么激进。问题在于，它做任务的效果其实没那么好。

它会写代码，也确实不错。但那种产品形态出现得太早了。

后来 Claude Code 出来了——完全本地运行，不接云端，也不会摆出一副那么 AGI 信仰满满的姿态。它会问你问题，它会停在那里，你没法把整个人生都委托给它。结果它反而更成功，对吧？因为那正是当时模型所处的能力节点。

所以当时我们“太 AGI-pilled 了”，超前于那个时刻了。这是我经常会反复想的一课。

过去，能力和市场会共同告诉你产品该长什么样、该如何表达。而现在情况变成了：不，你可能需要把同一个东西发六次，它才终于能工作，而它的形状本身可能一次都不用改。

主持人：现在做产品真的要考虑太多变量了，听你讲特别有意思。你要考虑模型的发展时间线、研究进展、智能会提升到什么程度；还要考虑用户是否已经能够理解“原来软件可以这样在云端构建，这就是未来”；还要考虑你们团队本身到底能做什么。

而我很喜欢你用 Codex 举的这个例子，因为它又回到了“野心”这个主题。我想听听你对这一点还有没有更多想法：

这些模型能做的事情，比你想象的还要多。有时它会比市场准备得更超前，市场还接不住。

但你会刻意去想这个吗？你会不会推动团队更有野心，因为现在去做那些过去看来难得疯狂的事，已经容易太多了？

Andrew Ambrosino：会。这是一个核心挑战。一旦某个产品已经存在，或者某个功能已经存在，人们就会很容易开始找纸割伤式的小问题去优化，而他们也确实应该这么做。Twitter 上的人也总会提醒我们这一点，我也感谢他们。大家确实应该关注已经存在的功能，让它们更可靠、更好用。

但这也是为什么我们这里还保留了一种自下而上的探索文化。因为有时，就像 Codex 应用曾某种程度上对 ChatGPT 形成了“颠覆”一样，未来也会有新的尝试来颠覆现在这个东西。而这其实也是设计的一部分：你不可能总是让同一个团队，同时既擅长做颠覆性探索，又擅长维护现有产品及其质量。到了某个时候，你必须设计出一套流程，让这两件事都能发生。

主持人：稍微拉远一点看，如果你回想我们一路走来的这条线——AI 如何影响我们构建产品的方式，真的太疯狂了。就像你说的，我们过去是手工一行一行写代码，像工匠一样写人类代码；后来变成 AI 写 100% 的代码；再到——你是这么描述的——现在“编码”其实是在引导 AI。

而当你问“我有多少代码是 AI 写的”时，新的问题几乎变成了：我需要把它往正确方向引导多少次？这才是新的“编码”。

现在又有 agent、loop（循环）、还有这些各种机制。就你所见，如今人们构建产品的最前沿是什么样？是 loops 吗？还是别的什么？就是那些最 AI-forward 的团队，现在到底是怎么运作的，也许很多人还没意识到。

Andrew Ambrosino：loop 都已经是上周的事了，兄弟。

我们刚才也提过，一个很大的问题总是：“产品里有多少是 AI 写的？” 但这个问题其实一直很难回答，因为如果你沿用去年的衡量标准，那答案就是：我们现在产品里 100% 的代码都可以算是 AI 写的。

所以更有意义的问题是：好，那这些代码到底是“被监督着写出来”的，还是“无人监督地写出来”的？这就是完全不同的问题了。

我很欢迎“球门不断移动”，因为这意味着我们的产品确实在进步。

我们这里已经做了很多关于 autonomously developed software（自主开发软件）的探索——自主开发。还有很多 harness engineering（测试与约束框架工程）方向的尝试。各种不同形态的探索。

比如说：如果 AI 每晚过来对代码库做一次 garbage collection（垃圾回收式清理），把它清理得更干净，会怎样？我觉得现在所有模型的一个共同问题是：它们通常会让复杂度上升。请让模型更擅长删代码。

但当你试图把开发彻底切换成 autopilot（自动驾驶）时，这就会立刻变成一个问题。不时对人而言，对代码库本身也是。

比如功能请求，对吧？你怎么教一个模型知道哪些功能该做，哪些该忽略，哪些应该打包到一起然后稍微重新定义一下？你怎么教模型构建正确的抽象？这一切都在变好。

但我觉得我们还没有走到这样一个阶段：说“好，我们设一个 loop，目标就是 improve the app，它去监听 Twitter、监听 Slack、监听邮件，然后自己改进应用。” 我们还没到那一步，但我们确实正在努力把它做成。

主持人：你觉得我们会到那一步吗？你觉得会不会有一天，真的只要说一句：增长、胜利、斜杠目标、赚钱、给我做出十亿美元、赢下市场——然后它就自己去实现？

Andrew Ambrosino：我不知道，兄弟。我不是那种会轻易说“永远不会”或者“肯定会”的人。

AI 的终点不是把所有软件塞进聊天框，而是像水一样渗透进你习惯的所有工具里

主持人：对。那你自己作为产品负责人、工程负责人，在工作里是怎么用 AI 的？有哪些你使用它的方式，是很多人可能还没意识到这个应用居然也可以这么用的？

Andrew Ambrosino：对。我觉得我现在拥有全世界最好的工作。

而它之所以这么有意思，其中一个原因就是：当我们最初开发 Codex 应用时，我个人的目标就是要把它做成“我拿来写代码的那个工具”，对吧？我当时想的是，我必须把它做得在开发这件事上足够强大，强大到我可以用它来构建 Codex 应用本身。

而当时的 Codex 应用，本身就是一个开发工具。

我们很快形成了那个 dogfooding 闭环，因为你会有一种个人级的自我试用闭环：你会说，“哦，这件事我做不了。那我得把它修掉，这样我才能做这件事。现在我能做这件事了。那我又能做更多事了。” 对吧？

后来我们把它发布出去，接下来的挑战就变成了：人们开始用它做一些形状完全不同的事，对吧？而现在我要把这个产品继续做大，所以我需要招几个人，我需要帮忙。于是，我自己的角色也发生了变化，同时应用本身需要承担的角色也在变化。

于是我开始想：好，我需要在这里做更多产品探索。我需要建立更合适的 loop，来观察每个人在做什么，来纠正那些偏离轨道的东西。突然之间，这就变成了我开始用 Codex 应用去做的事情。

我当然还写代码。我一直努力让自己对它的使用方式，尽量和我们正在解决的问题保持对齐。而现在我会想：我需要做一个 spreadsheet（电子表格）来建模这个问题；我需要对这一研究方向里所有已经发生的尝试，做一轮内部 deep research（深度研究），以服务下一个版本。

在大约 5 月份那一轮发布里，我们把应用内浏览器、computer use（计算机使用）、artifact creation（产物创建）带进了 Codex 应用。我觉得那是我们“Codex 几乎适用于所有人”的一次发布。

大家都知道 vibe coding 这个词。我觉得那是我们第一次做了一次 vibe-coordinated release（凭感觉协调出来的发布）：我在某个 Notion 文档里列着所有必须发生的事情，然后我在自动化收集来自 pull request、Slack 频道的更新，自动更新状态追踪器。现在这已经很常见了，但在当时，我真觉得自己站在了“如何管理一次产品发布”的最前沿。

简而言之，我使用 Codex 应用的方式基本就是：我的工作成长成什么样了，我就推动这个工具具备完成这些事情的能力。

我每天早上起来，会先看一份 daily brief（日报简报），它汇总了所有东西——我所在的 3000 个 Slack 频道里，到底有哪些事情需要我注意。我可以直接对它说：“好，给我列 5 个问题，我来回答。” 然后我就可以这么做。

主持人：这个怎么搭？普通人怎么搭出这样的工作流？因为听起来太棒了。

Andrew Ambrosino：office 里的自动化还处于探索阶段。我现在是写了一个定时任务去遍历我的 Slack，把那些我最关心和最重要的事情列出来，然后给它注入足够多的判定规则和上下文。在刚跑这个任务的几次，它确实需要不少调校。在这个应用里，我不需要去改底层的代码，我可以直接对它说：“嘿，下次运行的时候，能不能更关注这个？” 或者“这个工作流麻烦你弱化一点。” 通过这种类似做教练一样的方式，它就会自我迭代，更新通知我的格式。

未来的瓶颈在于，这种精巧的自动化配置，我能做，是因为我是产品研究，有大把时间去琢磨。但对普通用户而言，你不能指望他们去钻研这个。我们得想办法把这个路径抹平。

主持人：对。一个很好的例子是，我做了一个小应用，帮人过滤垃圾邮件。每封邮件进来——这个也是我用 Codex 做的——它会判断：这是不是那种我根本不想看的 unsolicited cold email（不请自来的冷邮件）？然后给它打标签，放到别的地方去。

而在配置这个东西时，有一步是你得进 Google Cloud Console，去设置一堆 Pub/Sub API 的东西和触发器。我不知道你有没有用过那个界面，真的又烦又慢，对吧？所以我就在想，等等，那我能不能让你帮我做？于是我说，好，你替我弄这个。

Andrew Ambrosino：然后你就在描述 computer use。

主持人：我以前从没见过有东西会在我的电脑上这么做。它会直接接管我的电脑，然后自己开始进去操作。

Andrew Ambrosino：它就像在说：“我才不管你有没有 connector，兄弟。我直接点进去就是了。”

主持人：对。而且它真的能自己搞定。看着它自己操作，简直太疯狂了。

Andrew Ambrosino：在 connectors、应用内浏览器、以及与你的 Chrome extension 相连的方式、还有 computer use 之间，如何设计决策边界——也就是在什么时候该用什么——这件事非常有意思，而且目前基本都是靠不断“摸感觉”做出来的。我前几天看到一个很棒的 Twitter thread，里面就有人把这三种模式解释得很好，也说了它们分别适合什么场景。

主持人：所以那个人解释得特别清楚。

Andrew Ambrosino：这些个人工作流真的很有意思，因为其中有些会非常“对味”。大家都在尝试各种各样的东西。每个人都在造自己的个人系统。你去问这里的每个人他们怎么用，答案都会不同。然后某些共同主题就会浮现出来，我们就会客观地将其沉淀为应用中的一级体验。我们不希望每个人都自己去重复造轮子，比如记忆（Memory）功能。

我们看到很多人都在费劲地自己搭 Obsidian 或者 Notion，来作为个人的“心智宫殿”，这不应该由用户来费心。这就是我们说的基础能力（Primitive）。我们要分辨，哪些是个体的工作习惯，哪些才是应该沉淀进底座的基础功能。

主持人：对。这就是你前面讲的那种品味和判断力——决定这些事。

我还想多聊一点 browser-use（浏览器使用）这一块，因为我觉得很多人并没有意识到它有多强，或者它到底能拿来做什么。

这让我想起，之前 Dan Shipper 上播客时曾预测，我们未来会直接在 Codex 应用里去承载和运行其他的 SaaS 软件。

Andrew Ambrosino：对。

主持人：也就是说，不是去 Chrome 里——

Andrew Ambrosino：我知道。他每天都在 Slack 上给大伙发消息提各种需求。

主持人：你觉得未来真会往那个方向走吗？我们会在 Codex 应用里直接使用 Notion、Linear、Salesforce，由你的 agent 一路辅助你？还是你觉得那其实是另一条路线？

Andrew Ambrosino：我们在应用内浏览器的演进上学到了很多。最初在 Electron 框架里，它的表现其实挺糟糕。所以当时定位很窄，就是个开发者调试前端的辅助工具，它不适合干别的。

后来我们全面切换到了 Atlas 的浏览器技术栈，实现了多标签页、企业级安全和网站登录，才算进入正轨。但始终难解决的一点是：这个浏览器应该长成什么样？它是只作为 Agent 快速调用的一个低延迟、可控后台；还是我们要野心勃勃地告诉用户，这个应用可以替代一切，它就是你的主浏览器。

这是两条完全不同的路，有很大的取舍。而且因为以前没人做过，会遇到很多非常无聊但很烦人的细节，比如快捷键。我们需要兼容 Chrome、VS Code 还是 Linear 自己的快捷键？我们需要让用户的肌肉记忆延续下来。

主持人：好，我们往外拉一层，聊聊你们正在把这一切带向哪里。

Codex 的愿景是什么？它会走向哪里？一年后、两年后、十年后，它会长成什么样？

Andrew Ambrosino：Codex 一开始只是个 CLI。后来我们决定做这个应用，虽然当时内部有很多不确定性，但我们对它作为开发者工具的形态有很强的信念。

它不是个 IDE。它是尺寸刚刚好的界面，看着像 chatbot，但它能呈现代码，只是我们不允许用户在应用里直接修改代码。

在正式发布前，我们在内部 dogfood 时就发现，工程和研究团队对它的喜爱超出了想象，PMF 极度明确。但与此同时，我们去测试另外几条线：既然 Codex 的代码智能体跑通了，那财务、法务、市场是不是也能用？结果发现这些非技术人员也在疯狂使用它。即便这个界面对他们很不友好，不停地跳出代码和终端提示，但他们就是不肯走。

这说明“技术开发”和“通用知识工作”之间，其实没有一道绝对的非黑即白的墙。

我们现在最核心的逻辑是：正如一个人的角色是由他做的事情的平均值决定的，产品也是。做 Excel 算账的人不想看代码仓库，这很正常。但我们可以通过他的行为推断他当前在干什么，从而灵活、自动地调整应用的复杂度，而不需要粗暴地给他们推一个完全不合脚的新界面。

我们希望这个产品能成为用户的“工作主基地”。

它不只是在屏幕上画一个黑色的矩形，然后逼着你把所有工作都塞进这个矩形里。它是一个你开始工作、结束工作、自动化工作的起点和终点，而在这个过程中，它会去调用任何你需要的工具。

Andrew Ambrosino：这里有个特别棒的故事。我们曾经在筹备发布素材时，摄影师 Brent 需要剪辑几条片子。

他是直接用 Codex 剪出来的。在当时这让我们极度震惊，因为 Codex 连视频剪辑的 UI 都没有。但它能理解 Premiere 的底层工程文件，通过改写这些数据来进行基础剪辑。在遇到改不动的地方时，Codex 甚至自己给自己写了一个 Premiere 的专属扩展插件并安装了上去，通过这个插件去控制软件内部的标记（Marker）。

这太离谱了。

它揭示了未来的两种产品合作模式。第一种是：我们不一定要造一个比别人更好的视频编辑器，但我们的 AI 可以像手一样去操作和接管既有的专业软件；第二种是：直接在 Codex 里打开现有的 Web 软件，并在其上叠加 AI 带来的高阶能力。我们正在同时高频地推进这两件事。

主持人：这个 Premiere 的故事对我来说很有意思，因为它再次说明了一件事：对于这些 AI 工作，应该更有野心一点。你也许根本不知道——说不定它真的能做到这件事。某种意义上几乎就是：去试，去试试看，看它能不能自己琢磨出来。

主持人：接下来我要带你进入播客里的一个固定环节，叫作“失败角落（fail corner）”。

问题是这样的：大家看到像你这样的人，会觉得你一路都在大杀四方，不断成长、一路赢，Codex 表现这么好，职业路径这么精彩，一切都在一路向上。但人们往往看不到那些没有成功的时候，以及你推出过但失败了的东西。

让大家听到这些故事非常重要——因为事情并不总是一路赢到底。

你职业生涯里，有没有哪次失败，给你带来了特别重要的教训？

Andrew Ambrosino：听你这么描述我自己，真挺有意思。这可能是我第一次没有感觉自己一直在失败。

我是说，我做了很长时间创业者。最后公司其实是被拆开卖掉的，基本算是“卖零件”吧，对吧？那是很多年，整个过程非常艰难。我做的是高度监管行业。整个过程都像是一场持续不断的失败。

后来我去了另一家创业公司，我们在另一个同样封闭、同样受强监管的行业里尝试做一些 AI 工具，那也一直是反复尝试、反复不成功。

所以对我来说，我其实失败过很多次。很多时候只是某个时间点上，技能、热情、市场，刚好对齐了。

至于现在这个项目，把我们在 Codex 应用里学到的东西和 ChatGPT 结合起来，这里面我都不知道经历了多少次微型失败。比如我们会想：这个东西应该长成这种形状。然后我们把它扔进 Slack，接着就会出现一个 2000 条消息的长线程，大家在里面疯狂讨论我们到底有多蠢。

这也是我喜欢 OpenAI 的地方：如果我们在内部做产品方面失败了，人们真的会直接告诉我们。没有人会给你留情面。也正因为如此，我们对外的产品才会这么好，因为它们都经历过这种“2000 条消息告诉你这玩意儿真烂”的循环。

在到达今天这个位置之前，我大概失败了 10 到 15 年。所以直到现在，我每天还是会对事情进展顺利这件事感到惊讶。

主持人：我觉得这是本期节目最重要的一句格言：你可以失败很多次，但只要在某个对的时间点技能和市场接上了，你就成了。

AI 产品正在从概念演示走向业务现场，真正的竞争也从“谁更会讲故事”转向“谁更能落地”。

7 月 17-18 日，2026 奇点智能产品大会将在北京金隅喜来登酒店举办，围绕 Agent 智能体、企业级 AI、AI 原生组织、具身智能、软件生产力、多模态产品、人机协同与行业应用落地等核心议题，邀请 40+ 一线产业实践者，共同拆解 AI 产品从 0 到 1、从 Demo 到规模化应用的真实路径。