AI 正在颠覆产品团队：Andrew Ambrosino 谈 Codex

OpenAI 有 90% 的人都在用 Codex。不是 90% 的工程师，而是整个公司的 90%。

90% of people at OpenAI use Codex. Not 90% of engineers. That's 90% of the entire company.

对。

Yeah.

你前几天在推文里说，你打算让 Codex 成为有史以来最好的桌面应用。

This tweet the other day where you said that you intend to make Codex the best desktop app that has ever existed.

对。Codex 的质量标准必须非常高，让你打开这个应用去做下一件事时，毫不犹豫地觉得这是你的自然选择。就像人们习惯打开浏览器标签页一样，对吧？

Yeah. The quality bar for Codex had to be so high that there was never like a hesitation that you have opening this app to do the next thing that this was your natural choice. Just like people have kind of come to open a browser tab, right?

确实。我知道你们不断创下使用量纪录。

That's true. I know there's numbers constantly coming out about the records you guys are setting for usage.

我不知道。我们拭目以待吧。很多人似乎喜欢这个应用。

I don't know. Like we'll see. A lot of people seem to like the app.

为什么你认为 AI 和顶尖的前沿模型不擅长设计？

Why do you think AI and the top frontier models are just not good at design?

我认为设计更难评分，因为人类品味这一方面是你需要的反馈机制的一部分。这在当前技术下仍然有点遥不可及。

I think design's a little bit harder to grade because the human aspect of taste is like part of the feedback mechanism you need. That is still feeling a little bit out of reach with the current technology.

现在的产品团队形态与几年前相比有什么不同？

What does the shape of product team look like now versus a couple years ago?

OpenAI 的每个人都很有主动性，有很多好主意，所以每个人都在构建一切。并不是说人们在做完全不同的角色或专注于不同的事情，而是流程反过来了。实现其实不再是昂贵的部分，我敢说是品味。

Everybody at OpenAI is very agentic, has great ideas, and so everybody's building everything. And it's not that people are doing fundamentally different roles or focusing on different things. It's that it's backwards. The implementation is actually not the expensive part anymore. It's dare I say taste.

你觉得这种每个人什么都做的趋势会到来，成为未来，还是我们会继续主要分工？

You feel like there's this collapse coming where everyone's everything and that's just the future or do you think we're going to continue to be mostly divided up?

有些事我担心。我听到很多公司说我们要取消产品角色，每个人都成为构建者，然后会发生的是……

There are some things that I'm afraid of. I've heard a lot of companies be like we're getting rid of the product role and everybody's just going to be a builder and then what happens is...

今天的嘉宾是 Andrew Ambrosino，OpenAI Codex 应用的产品和工程负责人。Codex 正迅速成为人们构建产品以及处理非产品工作（如整理电脑文件、起草文档、数据分析、阅读邮件等）的首选应用。如果你坚持看到本集结尾，我们还会有一段录制结束后制片人谈论他如何在编辑工作中使用 Codex 的片段。自今年一月以来，Codex 的使用量增长了 6 倍，目前拥有超过 500 万周活跃用户。我怀疑这个数字很快就会过时。在 OpenAI 内部，几乎 100% 的员工每周都使用 Codex，而且不仅仅是工程师。Andrew 从设计师转型为工程师，再转型为产品经理，正在构建这个越来越多的人用来构建自己产品的应用。在开始之前，别忘了查看 lenny's productpass.com，Lenny 的新闻通讯订阅者可以免费获得一年全球最热门、最精良的 AI 产品。现在，有请 Andrew Ambrosino。Andrew，非常感谢你的到来，欢迎来到播客。

Today my guest is Andrew Ambrosino, product and engineering lead for the Codex app at OpenAI. Codex is quickly becoming people's go-to app for building products and also for non-product work like organizing files in your computer, drafting documents, doing data analysis, reading your emails, and a lot more. If you stick around for the end of this episode, we actually have a little clip from after we stopped recording where the producer in the room started talking about how he uses Codex in his editing work. Since this January, Codex usage has grown 6x. They currently have over 5 million weekly active users. I suspect this number is quickly going to be out of date. Internally at OpenAI, nearly 100% of their employees use Codex weekly. And that is not just the engineers. Andrew is a designer turned engineer turned product manager who is building the app that more and more of the world is using to build their own products. Before we get into it, don't forget to check out lenny's productpass.com for a year free of the hottest and most well-crafted AI products in the world available exclusively to Lenny's newsletter subscribers. With that, I bring you Andrew Ambrosino. Andrew, thank you so much for being here. Welcome to the podcast.

谢谢邀请。这是一个难得的面对面播客。我很少做这种事。我们看看效果如何。

Thank you for having me. This is a rare in-person podcast. I rarely do this kind of thing. We'll see how it goes.

我们看看。

We'll see.

我们看看人们是否更喜欢这种形式。

We'll see if people like these more.

在我们准备这次对话时，我问你你最希望人们从这次对话中得到什么，你说的是 AI 如何改变产品工作的形态。你所在的可能是最前沿的 AI 产品软件团队。因此，你对未来的发展方向、其他团队在一两年或更长时间后的状态有着非常有趣的视角。现在的产品团队形态与几年前相比有什么不同？

When we were preparing for this chat, I asked you what's the biggest thing you want people to get out of this conversation and you said that it was how AI is changing the shape of product work. You're working at maybe the most bleeding edge AI product software team there is. So you have a really interesting lens into where things are heading, where other teams are going to be in a year or two or more. What does the shape of product team look like now versus a couple years ago?

作为构建这些产品的领导者，现在最难的事情之一就是流程的倒置，我想很多人都谈过：任何人都可以构建任何东西。我现在普遍相信，从零开始，如果你和这些模型——我们的或其他人的——对话，你可以搭建出任何你想要的功能。这未必是软件的难点，但确实很酷。我认为这创造了一个环境，人们都在做这些东西。你给人们无限的 token。OpenAI 的每个人都很有主动性，有很多好主意，所以每个人都在构建一切。而回顾我们长期运行的产品流程，它有点相反。它有点像研究、构思，可能有一些原型设计，但即使我们过了瀑布模型，它仍然带有一种实现成本高昂的意味，所以你要做的是通过文档、研究、原型来提前降低所有实现的风险，因为原型和设计更便宜是当时的假设。这已经变了，完全变了。现在，我敢肯定有 90 种不同的探索针对这个我们急需的功能。我敢肯定有 90 个不协调的团队在实现和尝试。

One of the hardest things to do right now as a leader building these products is just sort of the inversion of the process in my mind, which I think a lot of people have talked about: that anybody can build anything. I generally believe now that starting from scratch, if you talk to these models—ours or anybody else's—you can stand up whatever feature you want. And that's not necessarily the hard part of software, but it's really cool. And I think that has created an environment where people are making all of this. You give people unlimited tokens. Everybody at OpenAI is very agentic, has great ideas, and so everybody's building everything. Whereas I think, you know, you look back at product process that we've all run for a long time, and it's been a little bit opposite. It's been kind of research, ideation, maybe there was some prototyping, but even when we got past waterfall, it was still kind of flavored of like the implementation is expensive, and so what you want to do is you want to derisk all implementation up front through documents, through research, through prototypes, because prototypes and designs are cheaper was kind of the assumption there. And that's changed. That's totally changed. And right now, I'm sure there are 90 different explorations for this feature that we desperately need to do. I'm sure there are 90 different uncoordinated teams implementing and trying.

嗯……

Um...

所以我想简短的回答是，它反过来了。并不是说人们在扮演完全不同的角色或专注于不同的事情，也不是技能集消失了或角色消失了。而是它反过来了。实现其实不再是昂贵的部分，我敢说是品味。但这是策展过程。就像那 90 次尝试中，这些有什么好的？我们应该把哪些融入其他方面？我们应该如何构建它？它应该是另一个功能的一部分吗？切换开关应该有多少段？所有这些东西。

So I guess the short answer is like it's backwards. And it's not that people are doing fundamentally different roles or focusing on different things, or that even skill sets have vanished or that roles have just disappeared. It's that it's backwards. The implementation is actually not the expensive part anymore. It's, dare I say, taste. But it's the curation process. It's like of those 90 attempts, what's good about these? What should we fold into other aspects of this? How should we frame this? Should it be part of this other feature? How many segments should be in the toggle? All of those things.

本集由我们本季的赞助商 WorkOS 呈现。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay 以及数百家其他成功公司有什么共同点？它们都由 WorkOS 提供支持。如果你正在为企业构建产品，你一定感受过集成单点登录、SCIM、RBAC、审计日志等大型公司所需功能的痛苦。WorkOS 将这些交易障碍转化为即插即用的 API，拥有专为 B2B SaaS 构建的现代开发者平台。实际上，我投资的每一家开始向上市场扩张的初创公司最终都与 WorkOS 合作。这是因为他们是最好的。无论你是试图获得第一个企业客户的种子期初创公司，还是正在全球扩张的独角兽，WorkOS 都是成为企业就绪并解锁增长的最快路径。它本质上是企业功能的 Stripe。访问 workos.com 开始使用，或者直接联系他们的 Slack，那里有真正的工程师等着回答你的问题。

This episode is brought to you by our season's presenting sponsor, WorkOS. What do OpenAI, Anthropic, Cursor, Vercel, Replit, Sierra, Clay, and hundreds of other winning companies all have in common? They are all powered by WorkOS. If you're building a product for the enterprise, you've felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by large companies. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS. Literally every startup that I'm an investor in that starts to expand upmarket ends up working with WorkOS. And that's because they are the best. Whether you are a seed-stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise-ready and unblocking growth. It's essentially Stripe for enterprise features. Visit workos.com to get started or just hit up their Slack where they have actual engineers waiting to answer your questions.

Work OS 让你通过令人愉悦的 API、全面的文档和流畅的开发者体验更快地构建。前往 works.com 让你的应用准备好企业级使用。品味这个词真是个流行语。我想回到那个话题。90 个原型这个想法太有趣了。所以为了确保我理解正确。OpenAI 内部流传着一个想法。过去人们会写文档。这是我们要构建的东西。这是功能。这是策略。而现在你描述的完全合理：人们直接创建原型。你说公司里很多人都有类似的想法，现在他们不再写文档，而是创建自己的小原型，这样就产生了 90 个不同的东西，大家可以看看，也许能选出一个方向。是这个意思吗？

Work OS allows you to build faster with delightful APIs, comprehensive docs, and a smooth developer experience. Go to works.com to make your app enterprise ready today. Taste such a buzzword. I want to come back to that. This idea of 90 prototypes. So interesting. So just to make sure I understand that. So there's an idea out there floating around OpenAI. What people used to do is write docs. Here's what we're going to build. Here's the feature. Here's the strategies. Today what you're describing which makes all the sense is people just create a prototype and what you're saying is people across the company have kind of similar ideas and now instead of a doc they create their little prototype and that leads to kind of 90 different things people can look at and maybe pick here's a direction we want to go down. Is that idea?

这种情况很多，而且不仅发生在这里。你看到很多产品负责人说 PRD 已死，原型当立。但我完全不这么认为。我认为现在发生的一件有趣的事情是，由于实现成本在各种媒介上都变得非常低廉，直接跳到原型阶段非常诱人，尤其是如果你不是工程师，对吧？尤其是如果你从未写过代码，或者从未感兴趣，或者从未有时间。说 PRD 已死，让我直接展示我的意思，这很诱人。但我也注意到，对于工程师来说，写大量文档也很诱人，很多文档根本不值得读。这不是对写文档的人有意见。而是说，如果实现很充裕，那么为你要表达的观点选择合适的格式就非常重要。如果那个观点是关于模糊领域的产品清晰度，那么可能确实需要文档。如果你要做的是让人们试用某样东西并对交互模式进行压力测试，那就是原型。但我认为现在有趣的是，选择媒介变得非常重要。

There's a lot of this, and it's not just happening here. You've seen many product leaders say PRDs are dead, prototypes are in. And I actually don't believe this at all. I think that one of the interesting things that is happening right now is that because implementation has gotten so cheap across every medium, it's very tempting to jump straight to a prototype, especially if you're not an engineer, right? Especially if you've never been able to write code or never been interested or never had the time. It's really tempting to say like PRDs are dead. Let me just show you what I mean. What I've also noticed though is that for engineers, it's really tempting to write a lot of documents, a lot of documents that are not worth reading. This is no shade on people writing documents. It's that if implementation is abundant, then it's really important to pick the right format for the point you're trying to make. If that point is product clarity around a vague area, then it might actually be a document. If what you're trying to do is get something in people's hands to try out and to stress test an interaction pattern, it's a prototype. But I think this is kind of the funny thing now, which is that it's really important to pick the medium.

有一个播客嘉宾分享的术语，我听到你说这个时就想到了，叫做‘原始标记’。当设计师、画家或艺术家在画作或艺术品上留下第一个标记时，那个标记就是你开始回应的东西。所以一切都从你做的第一个标记开始。我听到你说的是，有时原型是错误的第一步，因为那样你就只是在回应这个原型，而不是一个不同的想法或更大的想法。所以我喜欢听这个。就像每个人都说，‘好吧，算了。不再写东西，不再有文档，不再有范围。’而你说它们实际上对特定用例仍然有用。

There's this term that a podcast guest shared that I think about when you say this, which is called the primal mark. When a designer or a painter or an artist just creates the first mark on a painting or a piece of art, that mark is what you start to respond to. And so everything kind of trickles down from that first mark you make. And what I'm hearing you saying is sometimes the prototype is the wrong first thing to do because then you're just responding to this prototype versus a different idea versus a bigger idea. So I love hearing this. So like everyone's just like, 'Okay, forget it. No more writing, no more docs, no more purviews.' You're saying they're actually still useful for specific use cases.

是的。我认为在以前的世界里，媒介本身隐含了很多关于事物在流程中处于什么阶段的信号。对吧？所以如果你看到某个东西感觉像生产中的应用，那就意味着它处于流程后期，假设已经去风险化，设计已经看过，这是一个好的商业目标。对吧？而现在这些东西有点分离了。以前之所以这样，是因为在充分去风险化之前很难获得资源来构建东西。而现在这已经行不通了。所以我认为非常重要的一点是开始说，看，我们可以有原型，我们可以有文档。我们清楚它在做什么吗？因为正如你所说，你不想过度锚定在一个本应是探索的东西上，但现在它看起来如此接近生产，以至于视觉上已经准备好上线，但实际上它并不是研究方向、用户需求或商业正确性的正确模型。不是要过度强调品味，但再次强调，知道该做什么、如何呈现信息、如何实现目标、使用什么媒介，这些品味正在成为最重要的事情。就是这样。这在每个领域都是如此。

Yeah. I think too there's this part of the previous world was that the medium implied it had baked in a lot of signal around where in the process something was. Right? So if you're seeing something that feels like the app in production, that means that it's late in the process, that assumptions have been derisked, that you know design has looked at this, that this is a good business goal. Right? And now those things are sort of divorced. And the reason it was that way is because it was hard to get resources to build the thing until it was properly derisked. And now that's just out the window. So I think it's really important to start saying look, we can have prototypes, we can have documents. Are we clear around what this is doing? Because to your point, you do not want to over anchor on this thing that was meant to be an exploration, but now it looks so production ready that like, oh, visually it's ready for prod, but it's not actually the right model of where the research is going or what users are asking for or what's right for the business. Not to overdo the taste thing, but it's like once again it's the taste to know like what to work on, how to present that information, how to achieve the goals, what medium to use is emerging as like the most important thing to do. And that's it. That's in every field.

当你谈到好品味时，品味是什么？是你描述的‘决定我们要投资什么’吗？还是当你有了一个东西后，‘这个对吗？这是要发布的东西吗？’谈谈当你想到什么是好品味、好判断时，具体是什么？因为人们听到这个词，他们会说，‘哦，我有好品味。我知道。’在实践中它是什么样的？

What is taste when you talk about good taste? Is it what you describe deciding here's the thing we're going to invest in? Is it also once you have a thing, is this right? Is this the thing to ship? Talk about when you think about what is good taste, good judgment, what is that concretely? Because people hear this word, they're like, 'Oh, I have good taste. I know it.' What does it look like in practice?

是的。有趣的是。有一条推文，我想是昨天来自 Linear 的产品负责人。我可能记错了。抱歉，有人说人们过度强调了品味中的美学部分。他们用了 Paul Graham 的 Craig，但以他为例说 Paul Graham 显然很有品味，却穿着工装短裤，对吧？就像，我们得稍微梳理一下品味的含义。这里有很多细微差别。我认为你提到的所有方面都包括。有美学部分。但也有系统思维部分。比如这如何融入系统？我们要去哪里，这是哪个主题的一部分？如何呈现？很多都是更广泛的背景。显然，品味的某些部分就像，这个交互动画不符合它应该传达的语义，对吧？比如对于它要传达的内容来说太突兀了。这非常重要，我可能过于关注这一点。但还有，如果我们可以构建任何东西，这应该是什么样的，目标是什么，我们如何达到，我认为这才是真正的品味问题。

Yeah. It's funny. There was a tweet, I think it was yesterday from the head of product at Linear. I might be getting that wrong. Sorry to anybody who said people overemphasize the aesthetic part of what taste means. And they used Paul Graham's Craig, but they used him as an example saying Paul Graham clearly has great taste and wears cargo shorts, right? Like, we've got to tease out what taste means a little bit. And there's a lot of nuance here. I think it's all of the above to what you mentioned. It's the aesthetic part to it. But there's also a systems thinking part of it. Like how does this fit in the system? There's a where are we going and what theme is this part of? There's how to present this. A lot of it is wider context. And obviously there are parts of taste that are like okay this interaction animation doesn't fit in the semantic meaning it's supposed to, right? Like it's too snappy for what it's actually trying to convey. And that's incredibly important and I focus probably too much on that. But there's the like what should this be like if we can build anything, what's the goal here and how do we get there that I think is like actually the real taste question here.

当我听到这样的话时，我总是在想，随着 AI 变得更强更好，做更多的工作，人类大脑在哪些方面仍然有价值？感觉品味是其中一部分。我沿着这个思路想的是，AI 在实际设计方面仍然很差。比如 AI 的输出并不好。很少有这样的情况：就是它，他们搞定了。而且总是像，哦，这是云设计。这是 Codex 设计。为什么你认为 AI 和顶级前沿模型今天仍然不擅长设计？你认为它们会达到那个水平吗？你认为我们会达到一个‘天哪，我们搞定了’的地步吗？

When I hear things like this I always wonder where will human brains continue to be valuable as AI becomes stronger and better and doing more of the work and it feels like taste is a part of it. Something I think about along these lines is just AI is still very bad at actual design. Like the output of AI is not great. Rarely is it like this is it, they nailed it. And it's always like, oh, this is cloud design. This is codex design. Why do you think AI and the top frontier models are just not good at design today? And do you think they'll get there? Do you think we'll get to a place of like, holy moly, we're done?

是的。我倾向于认为有一些实际原因导致它滞后，也有一些更难解决的问题需要攻克。

Yeah. I tend to think that there are some practical reasons why it's lagged and also some harder problems to crack.

我不在我们的研究部门，而且我这么说肯定会被骂。我认为设计比软件更难评分。创建一个循环，让模型学习什么是好设计、什么是坏设计，比检查代码能否编译或是否按预期运行更繁琐、更费力，因为品味这个人类因素是反馈机制的一部分。我还认为，实验室历来投资于让模型擅长那些能加速 AI 研究的事情。在编码模型的早期，模型能写出正确的代码显然会加速研究，而设计则不然。不是说擅长设计不重要，而是它不直接在那个飞轮里。这些是实际原因，而且这些原因会消失——这些模型会变得很擅长设计。但还有一些更模糊的东西会非常棘手。我列了一个简短的清单。一是，什么是好设计有文化因素。记得去年，每个新网站都只是 Linear 网站的翻版。Linear 的网站：设计好，品味好。如果模型做到那样，我会说‘哇，这进步太大了。’但如果模型每次都输出 Linear 的网站，那就不是挑战了。设计比软件工程更需要新颖性。在软件工程中，你几乎希望它过度依赖已知模式，而在设计中，则需要随机性和新颖性。另外，我在早期的 Codex 应用上花了很多时间写代码或监督代码，即使模型变得擅长设计，还有一个抽象层，是软件设计和所写代码之间的相互作用。比如，这个角落的东西应该与下面那个东西共享代码库中的 X、Y 和 Z。这跟说模型需要成为更好的设计师有点不同，尤其是在视觉方面，但它要深刻得多。它关乎抽象。如果明天我们公司要重新品牌，浅层的版本是我们必须逐个更新 263 个组件。深层的版本是这两个看起来不同的东西之间的语义——它们都在一个列表中，具有这种风格，向用户传达这种交互模式。我认为这个抽象层对于当前技术来说仍然有点遥不可及。所以，当我们经历这个过程时——我们从 11 月开始使用 Codex 应用，一开始不是全职使用，现在用它做所有事情——这是一段旅程。但现在我们使用它时实际做的事情不同了。所以问题是什么？

I'm not in our research, or like I'm sure I'll get yelled at for saying this. I think design is a little bit harder to grade than software. Creating a loop where you can train the model on what's good design and what's bad design is just more tedious and onerous than checking if code compiles or does what it's supposed to do, because the human aspect of taste is part of the feedback mechanism you need. I also think that the labs historically invest in making their models good at things that accelerate AI research. In the early era of coding models, it's very clear that the model being able to write correct code would accelerate research, in a way that you can't really make the same case for design. Not that getting good at design isn't important, but it's not directly in that flywheel. Those are practical reasons, and those will go away—these models will get pretty good at design. There are some murkier things that are going to be really tough. I have a short list of them. One is that there is an aspect of culture to what is considered good design. Remember last year, every new website that came out was just a copy of Linear's website. Linear's website: great design, great taste. If a model did that, I'd be like, 'Wow, this is incredible leaps here.' But if I have a model that outputs Linear's website every time, that's not the challenge. There's an amount of novelty that is more important in design than in software engineering. In software engineering, you almost want it to overindex on known patterns, whereas in design, there's an element of randomness and novelty. Also, I spent a lot of time writing code or supervising code on the early Codex app, and even as the models get good at design, there's an abstraction layer that is an interplay between the software design and the code being written. Like, this thing over here in this corner should share X, Y, and Z in the codebase with this thing down here. That's a bit different from saying the model needs to be a better designer, especially on the visual side, but it is significantly deeper. It's about the abstractions. If tomorrow our company did a rebrand, the shallow version is that we have to update 263 components one by one. The deep version is the semantics between these two things that look different—they're both in a list that have this style that convey this interaction pattern to the user. I think that abstraction layer is still feeling a little bit out of reach with current technology. So as we've gone through this process—we started the Codex app in November and we weren't using it full-time, now we use it for everything—that's been a journey. But now the things we actually do while using it are different things. So what was the question?

我知道那是个很棒的答案。说到设计和创造力，Codex 应用刚出来时，真是个全新的东西，没人见过。它不是终端，不是 IDE，而是这种能编码、你能看到代码的聊天工具。正如你所说，感觉 AI 很难想出一个全新的编程范式。而这正是人类大脑目前仍然有价值的地方——创造力，想出新的东西，而不是重复已有的模式。

I know that was an amazing answer. Speaking of design and being creative, the Codex app when it came out, it's like such a new thing that nobody had seen before. It's not a terminal thing, it's not an IDE thing, it's this chat thing that codes and you could see code. To your point, it feels like it'd be hard for AI to come up with a whole new paradigm for how to code. And that feels like where human brains continue to be valuable for now is creativity, almost, and coming up with something new versus patterns of things that have been done before.

是的，我完全同意。让我们暂时为人类大脑喝彩。

Yeah, I totally agree. Let's give it up for the human brain for now.

在我们准备这次对话时，你说你在听 Jenny 的那期节目，她是 Claude Code 和 Co-work 等公司的设计主管，她有一个论点：设计过程已死。没有时间做设计。事情发展太快了。现在就构建，设计在过程中引导方向。你暗示你对设计过程有不同的看法。

As we were getting ready for this, you said that you were listening to the episode of Jenny, who is the head of design for Claude Code and Co-work and such, and she had this whole kind of thesis that the design process is dead. There's no time for design. Things are moving too fast. Just build now and design is kind of steering things as things move along. You're implying you have kind of a different perspective on the design process.

我和 Jenny 可能在很多方面意见一致。我不喜欢传统设计过程本身。我同意她的观点，它已经死了，而且在 AI 之前我就真的不喜欢这个过程。

We probably agree on a lot of this, Jenny and I. I wasn't a fan of the design process proper. I agree with her take that it is dead, and I genuinely was not a fan of this process before AI.

你能快速给人们描述一下这个过程吗？

Can you describe the process real quick for people?

我的意思是，几年前我经营一家初创公司时，我们会进行设计招聘，有一篇尖刻的文章关于案例研究工厂，那是中期热潮时期的东西。它说设计师被教导要重视这个过程，高于一切，甚至高于结果。如果某件事经历了这个过程，那么两件事成立：一是它会是好的，过程保证质量和影响；二是如果某件事是好的，它一定经历了那个过程，即使你不喜欢它，也没人用它。这个过程是用户研究、发散、收敛——这是正确的框架。它一直有点学术化，但我认为这确实暴露了它的一些缺陷，尤其是因为实现速度。再次强调，这个过程的前提假设是实现成本高昂，你只能负担得起构建一次。所以你需要彻底遍历问题空间和解决方案空间，然后再实现。然后我们看到 Figma、Origami 等工具，你可以通过将交互原型提前引入过程来加速一些洞察。你可以模拟生产。后来有一个梗，高管们说：‘嗯，我们能不能只做个原型？’然后期望它能工作。但这是真的——这成了设计过程本身的一部分。我们把原型设计拉进来了。现在的问题是，你可以把所有的实现都拉进来。

I mean, when I ran a startup a number of years ago, we would do design hiring, and there was this snarky article that came out about the case study factory, it was mid-surge era stuff. It was that designers are being taught about this process and valuing it above all else, above all outcomes even. If something went through this process, two things were true: one, it would be good, and the process would guarantee quality and impact; and also that if something was good, it went through that process, even if you don't like it and nobody uses it. The process was user research, divergence, convergence—it's the right framework. It was always a little academic, but I think this is really exposing some areas where it falls down, especially because of the speed of implementation. Once again, that process is sort of predicated on the assumption that implementation is expensive and you can only afford to build once. So you need to exhaustively go through the problem space and the solution space before implementing. Then we saw with Figma, Origami, and all these tools that you can fast forward some insights by pulling interactive prototypes earlier into the process. You can simulate production. There ended up being a meme about executives just saying, 'Well, can we just do a prototype?' and then expecting it to work. But this thing was real—this became part of the design process proper. We pulled prototyping into that. The problem now is that you can pull all of the implementation into that.

这里存在很多假设上的错位。你看到一个完全打磨好的原型，看起来可以发货了，公司里足够多的人看到它就会问：‘我们现在能发布这个吗？’但实际上我们正处于早期设计流程阶段，没人会明说。这就是我们现在的状态，一堆多人探索。90 个人会有这个想法，它看起来非常精致，但这不是成品，这其实就是设计流程本身。将设计流程与媒介、媒体挂钩——这才是可怕的部分。设计师现在有更多工具来完成这个流程。你可以把东西放到当前产品中，进行 A/B 测试，或者直接把它当作原型。很多公司现在都有这种‘婴儿版’产品的想法，比如婴儿版 Cursor。你在推特上见过：我们有婴儿版编解码器，一个大幅简化的代码库，能模拟生产应用的所有交互，因此可以更快地进行‘氛围编码’。因为你可以想：‘如果侧边栏这样工作会怎样？如果某个面板进来并在这里有个群聊会怎样？如果 XYZ 会怎样？’这是设计流程中的一个巨大工具。所以说设计流程已死，我觉得既对也不对。如果你固守于工具、流程的具体日常细节，那么是的，它死了——你不会有好日子过。但完全抛弃流程，或者抛弃流程的框架，比如‘嘿，我们正处于流程的这个阶段’，这仍然比以往任何时候都更重要。

And there's a mismatch between a lot of assumptions. You see this fully polished prototype that looks ready to ship, and enough people at a company see that and ask, 'Can we release this now?' But we're actually in that early design process stage, and nobody's just saying that. This is where we are with a bunch of multiplayer exploration. 90 people will have this idea, it'll look really polished, but it's like, no, this is actually the design process now. Tying the design process to mediums, media—that's the scary part. It's that designers have more tools now to do this process with. You can put stuff into the current product and A/B test it or just use that as a prototype. Many companies right now have this idea of a baby version of the product, like baby Cursor. You've seen this on Twitter: we have baby Codex, a dramatically simplified codebase that approximates all the interactions of the production app and therefore is a lot quicker to vibe code over. Because you can be like, 'What if the sidebar worked like this? What if a pane came in and had a group chat here? What if XYZ?' That's a huge tool that's part of the design process. So to say the design process is dead, I feel like it's both true and false. If you are tied to the tools, the exact day-to-day specifics of the process, then yeah, it's dead—you're not going to have a good time. But to throw the process out completely, or throw out the overlay of the process like 'hey, we're at this point in the process,' that is still more important than ever.

这真的很有趣，因为你有各个职能的背景。如果人们看你的 LinkedIn，上面写着工程师、设计师、产品经理、创始人。现在你负责桌面应用，我想设计不在你的管辖范围内吧？是这样吗？有一个独立的设计团队，还是他们归你管？

It's really interesting because you have a background in every function. If people look at your LinkedIn, it's engineer, designer, product manager, founder. Now you oversee the desktop app, and I think design is not under your purview. Is that right? Is there a separate design team or are they under you?

看情况，每周不同。

Depends on the week.

好的，不错。

Okay, good.

我们合作非常紧密。我们相信要坐在一起，紧密融合。我不——他们每周轮换。

We work very closely together. We believe in all sitting together, being embedded. I don't—they shift weekly.

Cursor 这边的设计流程是什么样的？

What does the design process look like on the Cursor side?

是的，关于角色崩溃、存在性角色崩溃已经有很多文章。有人说不再有角色了。我们还没看到这种情况。我们在 Cursor 组织内看到的角色崩溃比公司其他部门和经济其他部分更多。我认为部分原因是这是一个面向工程师的技术产品，所以我们的设计师说工程师的语言，我们的产品经理说技术语言并写代码。Alexander 有计算机科学硕士学位，而我没有。所以我们看到了很多角色崩溃，我认为描述团队如何协作的一种方式是，角色之间的重叠比以前多得多。每个人不再由设计在哪里结束、工程在哪里开始的界限来定义，而是由他们工作的平均位置来定义。所以如果你把我们设计团队某个人做的所有事情平均一下，会有很多写代码的事情，很多产品工作，但平均而言，他们的点在这里。如果你画个图，这也在一定程度上说明了流程。特别是因为整个 Cursor 应用都是由‘吃自己的狗粮’循环驱动的。我们所有人都渴望尽可能多地在应用内做事，即使它不是最好的工具，这样它才能成为最好的工具。所以很多设计工作都是通过使用应用来完成的，然后说：‘好吧，这有什么问题？’这是我们做的一整套事情：我们经常不改进流程，以便让产品变得更好来做这件事，这是一个非常不舒服的境地，但每周都在变化。

Yeah, there's been a lot written about role collapse, existential role collapse. There are no roles anymore. We haven't seen that. We have seen more role collapse in the Cursor org than I think other parts of the company and other parts of the economy. I think part of this is that this was a technical product for engineers, and so our designers speak engineer, our product managers speak technical language and write code. Alexander has a master's degree in computer science, which I do not have. So we've seen a lot of role collapse, and I think that one of the ways we describe how the groups work together is that there's significantly more overlap in the roles than there used to be. And everybody's sort of defined less by the fences and boundaries of where design stops and engineering starts, but more by the average of where they're working. So if you average up all the things that somebody on our design team does, there's plenty of code writing things, plenty of things that are product work, but on average, their dots are over here. If you draw it out on a diagram, this sort of speaks to the process too. Especially because the entirety of the Cursor app has been informed by the dogfooding loop. There is a desire among all of us to try to do as much as possible in the app even when it's not the best tool so that it can become the best tool. And so a lot of design we all work on by using the app and say, 'Okay, what's broken about this?' This is a whole thing we do: we often don't improve our process so that we can make the product better to do it, which is a deeply uncomfortable place to be in, but week to week it's changing.

我非常喜欢这个观点：你的角色就是你花时间做的事情的平均值。如果你的大部分工作是 PM 工作，那么好吧，你现在就是 PM。如果是工程，你现在就是工程师。

I love this point so much that what you are—your role is the average of what you spend your time on. If most of your work is PM work, then okay, you're a PM for now. If it's engineering, you're an engineer for now.

是的。

Yeah.

我觉得 OpenAI 是第一个称员工为‘技术职员’的公司吗？

I feel like was OpenAI the first company to call people 'member of technical staff'?

不，我相信这可能始于施乐。我实习的第一家公司，叫 Up There，也这样做。

No, I believe this might have started with Xerox. The first company I interned at, a company called Up There, did the same thing.

这已经存在一段时间了，但现在更常见。这在研究型公司中是一种传统，对吧？

This has been around, but it's much more common now. It is kind of a tradition in research-focused companies, right?

好的，明白了。所以它源于研究，但我觉得这预示着未来的方向。这个想法是，我们就把所有人都称为‘技术职员’。你的职能不是固定的。你不属于 PM 或设计的某个类别。你觉得这是我们长期的方向吗？你觉得职能会继续存在吗？比如仍然有 PM 技能集、工程技能集和设计技能集。人们会说‘我是设计师’，还是你觉得这就像——人们称之为‘构建者’？你觉得角色崩溃即将到来，每个人都是全能，这就是未来，还是我们会继续主要按职能划分？

Okay, got it. So it emerged from research, but I feel like it's such a sign of where things might be headed. This idea of we're just going to call everyone 'member of technical staff.' Your function isn't set. You're not like in this bucket of the PM or the design. Do you feel like that's where we all head long term? Do you feel like functions will continue to exist? Like there's still the PM skill set and the engineering skill set and the design skill set. And people are 'I'm a designer' or do you think this is like—people call it 'builder'? Do you feel like there's this collapse coming where everyone's everything and that's just the future, or do you think we're going to continue to be mostly divided up?

有些事我担心。我认为有些公司喜欢极端地跟风，不管别人说什么会发生。我认为消除角色概念的危险之一是，它可能危险地消除‘事物是有可认知最佳实践的专业领域’这一观念。我听说很多公司说：‘我们要取消产品角色’，顺便说一句，我认为这是个糟糕的主意。然后每个人都成了构建者。结果就是，整个产品学科——已经建立起来、有真正的最佳实践、有真正尝试过和失败过的东西、有真正的流程——就被抛弃了，因为人们会说：‘哦，我写了一些代码。’这不是一个好状态。我认为‘这不是你的领域’这种边界——我欢迎它消失，但这里有一个平衡：不是每个人都能做所有事，无论是广度还是深度。这就是为什么管理者不会消失。

There are some things that I'm afraid of. I think that some companies like to be very extreme about getting onto the bandwagon of whatever people say is going to happen. And I think part of the danger in eliminating the concept of roles is that it can dangerously eliminate the idea that things are specialties with knowable best practices. I've heard a lot of companies be like, 'We're getting rid of the product role,' which I think is, by the way, a terrible idea. And everybody's just going to be like a builder. And then what happens is they don't—this whole discipline of product that's been built up and has real best practices, real things that have been tried and failed, and real processes—that just gets abandoned because people are like, 'Oh, I wrote some code.' That's not a great place to be in. I think that the boundary of 'this isn't your lane'—I welcome that part going away, but there's a balance here where it's like not everyone can work on everything, both in terms of breadth and depth. This is why managers are not going to go away.

你的 Codex 团队是什么样的？有多少工程师、设计师、产品经理？目前团队构成是怎样的？

What does your team look like on the Codex team? How many engineers, designers, PMs? What's kind of the makeup of the team right now?

每次有人问我 Codex 团队有多少人，你还记得我的回答吗？是的，我说大概在 10 到几千人之间。这是个玩笑式的回答，但也是真实的，因为我们把这看作是所有人工作的结晶。包括模型研究的一切，模型如何擅长编码和浏览器使用的一切，模型个性的一切，前端基础设施的产品工作，以及所有用户体验——所有这些都是这个产品的一部分。同时，我们并不会每天接受成千上万人的随意 PR。所以我们的团队有两位数工程师，设计方面大概一半，还有几个产品人员。虽然产品层级更像是他自己的防守打法。我认为 Codex 或桌面端团队所有人的一个共同点是主动性和品味。很多前创始人或在大公司做创始人型工作的人，很多有极强品味的人。在 OpenAI，我们让团队变得很大，所以没有管理层，但团队确实很大，主要是个人贡献者，我认为这很好。

Every time people ask me how many people are on the Codex team, do you remember my answer to this? Yeah, I say it's somewhere between 10 and a few thousand. I mean, it's a fake answer, but it's real in that we see this as the culmination of what everybody works on here. Like everything that goes into model research, everything that goes into how models are good at coding and browser use, everything about model personality, all the product work around front-end infrastructure, all of the user experience—all of it is this product. At the same time, we are not accepting PRs daily from thousands of people on whatever they want. So we have a team of double-digit engineers, probably half that on the design side, and a few product people. Although product tier is more of his own defense play. And I think one thing that is very common among everybody on the Codex side or on the desktop side is agency and taste. A lot of former founders or people who were at larger companies doing founder-shaped things, a lot of people with immense taste. At OpenAI, we let teams get very large, so we haven't—there's no management, but the teams are quite large. It's mostly ICs, and I think that's good.

你在产品工作中用了‘区域联防’这个词，我觉得很有意思。这似乎也对应了设计上的转变。就像你是在管理和协调。再多谈谈那是什么样的？产品人员的区域联防是怎样的？

You use this term 'zone defense' for product work, and I think that's really interesting. It kind of maps to the design shift also. Just like you're there to manage and coordinate. Talk a little bit more about what that looks like. What does zone defense look like for a product person?

是的，我和 Alexander 多次讨论过这个类比。如果两个产品人员合作过于紧密，那通常不是好信号。作为产品人员，你要做这种力导向的活动，寻找空白，尤其是在这个新世界里，策展、引导和对齐很重要。到处都是混乱，人们到处抛想法。那种自上而下的年度规划行不通了。所以现在我们需要品味引领者从构思到产品成型进行引导。这意味着你基本上需要覆盖公司。所以你们分散开来，说：‘好吧，谁最擅长什么？让我们之间留出空间，这样就能全面覆盖。’大致就是这样。然后填补空白。我们希望招聘有产品思维的工程师。我们不希望一群人写代码，然后需要整个团队评审产品一致性。我们希望每个人都具备这些技能，但我认为人们深入的方向必须改变。

Yeah, I've had a lot of conversations with Alexander about this analogy. It's that if two product people are working too closely, that's often not a good signal. As a product person, you want to do this forced-directed activity where you look for gaps, especially in this new world where curation, steering, and alignment are a lot of things. There's a ton of chaos, people throwing ideas all over the place. The whole top-down year-long planning thing is not going to work. So now we need the tastemakers to guide things from inception to what the product should be. That means you basically want company coverage. So you spread out and say, 'All right, who's best at what? Let's create some space between us so that we have full coverage.' That's kind of how it goes. Then you fill in the gaps. We want to hire engineers who are product-minded. We don't want a bunch of people writing code that needs full team review for product coherence. We want everyone to have these skills, but I think what people go deep on has to change.

这绝对是我和像你这样的人交谈时反复注意到的线索。现在最有价值的人，最有价值之一，是那种能把想法从构思到实现，并且有品味知道这很棒的人。全程引导，痴迷于把它做得精彩。这种高主动性、高品味的人。正如你描述的。这是你考虑招聘谁、谁会在新世界里表现出色的方式吗？

This is definitely a thread I've been noticing over and over with talking to folks like you. The most valuable person right now, one of the most valuable, is someone that can take an idea from idea to done with the taste to know this is great. Just shepherding throughout this obsession with making it awesome. This kind of high agency, high taste person. Exactly as you described. Is that the way you think about who we're hiring, who's going to do really well in this new world?

是的，我认为这是现在的核心。这也说明了我如何看待个人贡献者与管理层。并不是管理会消失，也不是每个人都是个人贡献者，但现在每个人都是两者的结合。如果你是个人贡献者，你并不是逐字逐句地敲代码。你在管理一些东西——你在管理智能体，你在管理工作，这些工作组合起来完成某件事。如果你是团队管理者，你也在做同样的事情，只是粒度不同。我通常看重对学科的精通，但还有品味，能说：‘嘿，你会有无限的 token，但我们不能只是产出垃圾。你需要能够分辨什么是信号，什么是噪音，在一个内容无限的世界里。’

Yeah, I think that's the core piece right now. It also speaks to how I see IC versus management. It's not that management is going away. It's not that everyone's an IC, but everyone's kind of both now. If you're an IC, you're not typing code out character by character. You are managing something—you're managing agents, you're managing work that comes together to do a certain thing. If you're a manager of teams, you're doing the same thing just at a different granularity. I generally look for command over the discipline, but then the taste to say, 'Hey, you're going to have unlimited tokens and I don't—we can't just be doing slop. You need to be able to determine what's signal, what's noise, in a world of infinite content.'

你提到了规划。在事物发展的速度下，规划路线图变得非常困难。我想尤其是在我们的世界里。人们总是对此很沮丧。因为事情在不断发布，不断变化。你在团队里如何规划？你考虑多远？计划是什么样的？是电子表格？Markdown 文件？计划的输出是什么？

You mentioned planning. At the pace things are moving, it's become very hard to plan roadmaps. I imagine especially in our world. People are very frustrated with me all the time on this. Because things are constantly shipping, things are changing. How do you plan on your team? How far ahead are you thinking and what does a plan look like? Is it a spreadsheet? An MD file? What's the output of a plan?

是的，我不认为我们在这方面做了什么革命性的事。我们在规划上并不聪明。我认为基本要点是：时间越近，需要的细节越多。并不是说我们不规划 9 个月后的事，而是那必须保持非常模糊，因为现在给 9 个月计划添加的任何精确度都是虚假的精确。你只会浪费时间。你可以说些东西，但我们计划的东西没有一件。

Yeah, I don't think we do anything revolutionary on that. We're not clever about planning. I think the basic gist is: the shorter term something is, the more detail it needs. And it's not that we don't plan for 9 months out, it's that that just has to stay very hazy because any amount of precision that you add to a 9-month plan right now is false precision. You're just going to waste time. You can say stuff, but nothing that we planned.

我认为研究是另一回事。我这里不是谈研究，而是应用端做产品时，任何你在 11 月计划好的事情，到了 12 月可能还成立，但实际发生的情况却不同，对吧？所以很难，做计划真的很难。我们通常需要知道模型在什么时间线上能做什么。在我上一家公司，我看到了这种转变：我们开始用模型来驱动功能，产品流程就崩溃了。基本上必须这样做：列出未来一两年我们感兴趣的所有事情，全部做出原型，决定哪些现在准备好了，其他的就放着让它酝酿。然后每当模型有新的飞跃时，就把那个东西换上新模型再试一次。因为功能好不好，完全取决于它们够不够聪明，而不是它们的形态。

I think research is different. So I'm not speaking for research here but on the applied side when we do product, anything that you could have planned in November may have been true for December but isn't what happened, right? So it's hard, it is really hard to do planning. We generally need to know what we think models are able to do on what timeline. At my last company, I saw this shift where we started using the models to drive features and the product process fell down. It basically had to be like, let's list out all the things we think we are interested in doing for the next year or two. Let's prototype all of them, decide which things are ready now, and then just let the others sit and bake. Then every time there's a new leap in models, let's try that thing again with it swapped out. Because the whole premise of whether features were good or not was based on whether they were smart enough, not the shape of them.

所以这是一个关于 Codex 应用的好故事。我非常确信，我们 2 月份发布的 Codex 应用，如果 11 月就准备好了，绝对会在市场上失败。唯一的区别就是 11 月到 2 月之间的模型，对吧？我认为这里面有很多道理：这个产品形态完全相同，但结果却截然不同，只取决于几个月的时机。

So this is a great story about the Codex app. I am very confident that the Codex app we released in February, if that had been ready in November, it would have absolutely failed in the market. The only difference was the models between November and February, right? I think there's a lot to that: this product with the exact same shape, its outcomes were totally different depending on just a few months of timing.

本期节目由 Mercury 赞助。非常不同的银行服务，深受超过 30 万企业家的喜爱，现在还有了 Command。我是 Mercury 超过 6 年的客户，从未想过离开。Mercury 就是那种由产品人而非银行家打造的银行。他们让发送发票、转账、为团队成员设置虚拟卡变得非常容易，我敢说甚至很有趣。你的银行有 API、终端原生 CLI 或 AI 就绪的 MCP 服务器吗？我觉得没有。就在最近，他们推出了 Command，一个直接内置于 Mercury 的对话界面，充当你的财务操作员。我一直在用 Command 转账、查看我在哪些类别上花钱最多、分析现金流，就在今天，我还用它查了过去一年从某个特定赞助商那里赚了多少钱。我只是问：“过去一年我从 X 那里赚了多少？”10 秒后就有了答案。这太酷了。访问 mercury.com 了解更多，几分钟内在线申请。Mercury 是一家金融科技公司，不是 FDIC 承保的银行。银行服务由 Choice Financial Group 和 Column NA 提供，均为 FDIC 成员。

This episode is brought to you by Mercury. Radically different banking, loved by over 300,000 entrepreneurs, and now with Command. I've been a customer of Mercury's for over 6 years. I have never once thought about leaving. Mercury is basically what happens when banking is built by product people, not by bankers. They make it so easy, dare I say fun, to send invoices, move money around, set up virtual cards for folks on my team. Does your bank have an API, a terminal native CLI, or an AI-ready MCP server? I don't think so. And just recently, they launched Command, a conversational interface built directly into Mercury, which acts as your financial operator. I've been using Command to transfer money around, figure out what categories I've been spending the most money in, analyze my cash flows, and just today I used it to find out how much I've made from a specific sponsor over the past year. I just ask, 'How much have I made from X over the past year?' 10 seconds later, I have an answer. It is so freaking cool. Visit mercury.com to learn more and apply online in minutes. Mercury is a fintech company, not an FDIC-insured bank. Banking services provided through Choice Financial Group and Column NA, members FDIC.

这绝对是本播客的一条主线：构建那些目前还不起作用的东西，等模型变好它们就会起作用。还有另一条主线是雄心：对你承担的事情要更有雄心。所以这就是你做事的方式吗？比如我们只管构建一堆可能还不起作用的东西，放着它们，等模型赶上？是这种思路吗？

This is definitely a thread on this podcast: build things that are not yet working, then they will work when the model gets better. And there's this other thread of ambition: be more ambitious with the things you take on. So is this just a way you approach things, like let's just build a bunch of things that may not work yet, we'll just have them around and wait for a model to catch up? Is that kind of the approach?

是的，我们有很多这样的做法。我认为有时挑战在于你必须非常清楚这处于设计过程的哪个阶段。人们仍然有这种肌肉记忆：‘哦，我写了这个代码，所以我们应该把它发布出去。’不，不，不，这意味着你现在有了一个工件，我们可以用它来测试未来的模型，对吧？这发生在我们应用的内置浏览器上。我们有一个可用的版本。回到 Atlas，我们在 Atlas 内部有智能体在工作，那很酷。在那之前，我们在 ChatGPT 中有 Operator，对吧？那没成功。非常酷的想法。在 Operator、Atlas、Codex、ChatGPT 之间可以画出一条线，它们本质上是相同的功能，但用不同的智能重新发布，结果完全不同。所以我推动人们不要固执地认为‘这不管用，所以这是个坏功能。’不，它可能还没准备好。还有一方面，尤其是在研究中，总是渴望最有雄心，说‘好吧，在极限情况下模型可以做到这个’，但在产品端就是不行。如果你回到最初的 Codex 发布，基本上它被称为 Codex Web，交互体验不好。就像你给模型一个任务，它就去执行，然后回来告诉你完成了。听起来没那么激进。问题是它任务完成得不够好。它写代码，写得不错，但那种形态太早了。然后 Claude Code 出现了，完全本地化，不连接云端，不假装那么智能体化，它会问你问题，它会待在那里，你不能把生活都委托给它。这效果好多了，因为那是当时模型所处的阶段。所以我们当时太被 AGI 冲昏头脑了。我经常思考这个教训。过去，市场会告诉你关于产品形态、产品沟通的所有事情。现在，不，你可能需要发布这个东西六次，它才能工作，而形态可能根本不变。

Yeah, I think we have a lot of that. I think sometimes the challenge is you have to be very clear again about what stage of the design process that's in. People still have this muscle memory of, 'Oh, I wrote the code for this thing, therefore we should put it out there.' It's like, no, no, no, that means you have an artifact now that we can test against for future models, right? This happened with the in-app browser in the app that we have. We had a working version. Go back to Atlas, we had agent working inside of Atlas, and that was pretty cool. We had operator before that in ChatGPT, right? That didn't work out. Very cool idea. There's some thread that you can draw between Operator, Atlas, Codex, ChatGPT that's fundamentally the same feature, but the re-releasing of it with different intelligence totally changes the outcome. So I push people not to be stubborn about 'this isn't working so it's a bad feature.' No, it might not be ready yet. There's also this aspect, especially in research, there's always a desire to be the most ambitious and to say, 'Okay, but at the limit the model can just do this,' and it just doesn't work on the product side. If you go back to the original Codex release, basically what it was is it said it was Codex Web, and it wasn't good for interacting with. It was like you give the model a task and it's going to go off, do the task, come back to you with finished. Doesn't sound that radical. The problem is it didn't do the task that well. It wrote code, it was good, but that form factor was too early. And then the Claude Code comes out, totally local, not hooked up to the cloud, doesn't pretend to be as agentic, it's going to ask you questions, it's going to sit there, you can't just delegate your life to it. That worked way better, because that's the point the models were at. So we were too AGI-pilled for the moment. I think about that lesson a lot. It used to be that the market told you all these things about the shape of the product, the communication of the product. Now it's like, no, you might need to release this thing six different times before it works, and the shape might not change at all.

听到你在构建产品时必须考虑的所有变量，真是太有趣了。现在有模型和研究的时间线，以及它变得多聪明。还有人们甚至理解这就是你如何在云端构建软件的能力，这就是未来，让人们为这个新未来做好准备。然后还有你作为团队能构建什么。我喜欢那个 Codex 的例子，因为它回到了雄心这个想法。我想听听你是否有什么想法，关于这条主线：‘要更有雄心，因为这些模型能做的比你想象的要多得多’，有时这对市场来说太雄心勃勃了，他们还没准备好。但你考虑过吗？就像推动你的团队更有雄心，因为现在做那些过去可能觉得疯狂困难的事情要容易得多？

It's so interesting to hear about all the variables you have to think about building product. Now there's the timeline for the models and the research and how smart it gets. There's people's ability to even understand this is how you could build software in the cloud and this is the future, get people prepared for this new future. And then just what you can build as a team. I love that Codex example because it comes back to this idea of ambition. I want to hear if there's anything there for you of just this thread of 'be more ambitious because these models can do so much more than you even imagine,' and sometimes it's too ambitious for the market and they're not ready for it. But you think about that at all, just like pushing your team to be more ambitious because it's so much easier to just do things that may have felt crazy hard in the past?

是的，这是一个核心挑战。一旦有了一个产品或功能，人们很容易发现小毛病并进行优化，他们应该这样做。推特上的人喜欢提醒我们这一点，我感谢他们。人们应该专注于现有的功能，让它们更可靠、更好。

Yeah, this is a core challenge. Once there's a product that exists or a feature that exists, it's really easy for people to find paper cuts and optimize, and they should. People on Twitter like to remind us of this, and I thank them for that. People should be focused on the features that exist and making them more reliable and better.

但这也是为什么我们这里有一种自下而上的探索文化，因为有时候，就像 Codex 应用在某种程度上颠覆了 Chachup T 一样，这件事也会被未来的努力所颠覆。这是设计的一部分：一个团队不可能同时擅长颠覆性部分和维护产品及其质量部分。有人指出要设计一个允许两者兼得的过程。

But this is why we also have a culture of bottoms-up exploration here, because sometimes, in the same way the Codex app came and disrupted Chachup T in some way, this thing will get disrupted by a future effort. That's part of the design: you can't always as one team be good at both the disruptive piece and the maintaining a product and its quality piece. Some point to design a process that allows for both.

稍微宏观一点，想想我们在 AI 影响产品构建方式上的进展，我们已经走了多远，这太疯狂了。从你说的，我们过去手工编写所有代码，像手工艺人一样，到 AI 编写我们 100% 的代码，再到你实际上这样表述：现在编码就是引导 AI。当你思考我的代码有多少是 AI 写的时，这几乎变成了我需要多少次把它引导到正确方向——这就是编码的新版本。现在有了智能体和循环这些东西，从你所见的，人们构建的最新前沿是什么？是循环吗？还是别的什么？最 AI 前沿的团队现在如何运作，而人们可能不知道？

Zooming out a little bit, if you think about the progression we've been on of AI impacting how we build product, it's insane how far we've come. From, as you said, we used to write all our code by hand, like artisanal human code, to AI writing 100% of our code, to you actually put it this way: now coding is steering the AI. When you think about what percentage of my code is written by AI, it's almost like how many times did I have to steer it in the right direction is the new version of coding. And now that there are agents and loops and all these things, what's the latest frontier from what you've seen of how people are building? Is it loops? Is there something else? How do the most AI-forward teams operate now that people may not be aware of?

是啊，循环已经是上周的事了。我们聊过这个。一个大问题总是：产品有多少是 AI 写的？这很难回答，因为如果你用去年的标准，那我们现在 100% 的产品代码都是 AI 写的。所以问题更像是：代码是监督式写的还是无监督式写的？这完全是另一回事。我欢迎标准的变化，因为那意味着我们在产品上取得了进展。这里有很多关于自主开发软件的探索，很多 harness 工程之类的东西，各种不同的探索。比如，如果你晚上进来对代码库做垃圾回收清理呢？我认为目前所有模型都面临的一个问题是它们通常会增加复杂性。如果任何公司的研究团队在听，请让模型更擅长删除代码。但当你试图让开发完全自动驾驶时，这就会成为问题。这既涉及人类方面，也涉及代码库方面。比如功能请求：你怎么教模型构建哪些功能、忽略哪些功能、哪些功能应该组合并重新框架化？你怎么教模型构建正确的抽象？所有这些都在变好。我不认为我们已经到了可以设置一个循环说“改进应用”并监听 Twitter、Slack 和邮件的地步。我们还没到那一步，但我们正在努力实现它。

Yeah, I mean loops are so last week, man. We talked about this. One of the big questions is always, how much of the product is AI written? And it's always hard to answer that question because if you're using the goalposts from last year, it's like, well, 100% of our product right now is AI written code. So the question is more like, okay, fine, is the code written supervised versus unsupervised? That's a totally different thing. I welcome the moving of goalposts because that means we're making product progress. There have been a lot of explorations here around autonomously developed software, a lot of harness engineering stuff, a lot of different explorations. Like, what if you came in overnight and did garbage collection of the codebase to clean it up? One thing that I think all models suffer with right now is they usually increase complexity. If research is listening at any company, please make the models better at deleting code. But that becomes a problem right now when you try to put development completely on autopilot. And it's both on the human side and the codebase side. So like feature requests: how do you teach a model which features to build, which ones to ignore, which ones to group together and reframe a little bit? How do you teach a model how to build the right abstractions? All of this is getting better. I don't think we're at a place yet where we're like, we just set up a loop that's like 'improve the app' and listens to Twitter, Slack, and email. We're not there yet, but we are trying to make it happen.

你觉得我们会达到那一步吗？你觉得我们会达到一个地方，就像‘增长’、‘赢’、斜杠目标、‘赚钱’、‘让我赚十亿美元’？赢得市场。

Do you think we'll get there? Do you think we'll get to a place where it's just like 'grow', 'win', slash goal, 'make money', 'make me a billion dollars'? Win the market.

我不知道，老兄。我不做说‘从不’或‘总是’之类的事。

I don't know, man. I am not in the business of saying never or always or whatever.

作为产品负责人和工程负责人，你在工作中如何使用 AI？有哪些使用方式可能是人们不知道他们也可以这样用这个应用的？

How are you using AI in your work as product leader, engine leader? What are some ways that you use it that maybe people may not be aware they can use the app for?

是的，我认为我现在拥有世界上最好的工作。让它非常有趣的一点是，当我们开发最初的 Codex 应用时，我个人的目标是让它成为我用来编写代码的工具。我当时想，我需要让它变得如此擅长开发，以至于我可以用它来构建 Codex 应用本身。而当时的 Codex 应用是一个开发工具。我们做了非常快速的吃狗粮循环，因为你有自己的吃狗粮循环，你会想，‘哦，我做不到这件事。我应该修复那个，这样我就能做到这件事了。’现在我能做到了。现在我能做更多事了。我们发布了它，然后下一个挑战是，嘿，人们开始用它做不同形状的事情，现在我需要发展它，所以我需要雇几个人来帮忙。于是我的角色发生了变化，同时应用的角色也需要改变。所以我想，好吧，我需要在这里做更多的产品发现。我需要找出正确的循环来查看每个人在做什么，并引导偏离轨道的事情。所以突然间，我开始用 Codex 应用来做这件事。我仍然写代码。我试图让我自己的使用方式与我们试图解决的问题保持一致。现在我想，我需要构建一个电子表格来建模这个。我需要做一个内部深度研究，了解所有进入这个研究领域的努力，为下一个版本做准备。在五月左右有一个发布或一系列发布，为 Codex 应用引入了应用内浏览器、计算机使用和工件创建。我认为那是我们的‘Codex 几乎面向所有人’的发布，每个人都知道‘氛围编码’这个词。我认为那是我们第一次五个协调发布，我在某个 Notion 文档里列出了所有需要发生的事情，我自动化了去拉取请求、Slack 频道收集更新并更新状态追踪器。现在这已经很常见了，但当时我觉得自己处于管理产品发布的最前沿。简而言之，我使用 Codex 应用的方式基本上就是：我的工作变成了什么，以及我如何让这个东西能够做我需要做的一切。我早上起来，会看到我所在的 3000 个 Slack 频道中所有事情的每日简报，比如哪些事情需要我关注。我可以回复说，‘好吧，给我五个问题，我来回答’，然后我就能做到。

Yeah, I think I have the best job in the world right now. One of the things that makes it very fun is that when we were developing the original Codex app, the goal for me personally was to make it the thing that I wrote the code with. I was like, I need to make this so good at development that I can build the Codex app with this. And the Codex app at that time was a development tool. We did that super quick dogfooding loop because you got your personal dogfooding loop where you're like, 'Oh, I can't do this thing. I should fix that so that I can do the thing.' Now I can do the thing. Now I can do more things. We released that and then the next challenge was, hey, people are starting to do some different shaped things with this, and now I need to grow this, so I need to hire a few people and help. So then my role changed at the same time that the role of the app needed to change. So I'm like, okay, I need to do more product discovery here. I need to figure out the right loops for seeing what everybody's working on and steering things that are off track. And so all of a sudden that's what I started using the Codex app for. I did still write code. I've tried to align my own usage of it with the problem that we're trying to solve. And now I'm like, I need to build a spreadsheet that models this out. I need to do an internal deep research on all of the efforts that have gone into this area of research for the next version of this. There's a release or a series of releases in Mayish that introduced the in-app browser, computer use, and artifact creation to the Codex app. That was I think our 'Codex for almost everyone' release, and everybody knows the term vibe coding. I think that was like our first five coordinated release where I had a notion doc somewhere with everything that needed to happen and I was automating going out to gather updates from pull requests, from Slack channels, and updating the status tracker. Now this is pretty commonplace, but at the time I felt like I was at the bleeding edge of how to manage a product release. In short, the way that I use the Codex app is basically like what has my job grown into and how do I make this thing able to do everything I need to do. I will get up in the morning, I will see the daily brief that I have from everything from the 3,000 Slack channels that I'm in, like which things need my attention. I can kind of message back and be like, 'All right, give me five questions and I'll answer them,' and I can do that.

你是怎么设置的？对别人来说，设置这个的工作流程是什么？因为这听起来太棒了。

How do you set that up? What's the workflow for somebody to set that up, because that sounds amazing.

再说一次，我认为我们在很多方面仍处于发现阶段。现在，我就是在做一个自动化，或者说一个定时任务，它会遍历我的 Slack 频道。这些是我关心并认为最重要的事情。

Again, I think we're still in the discovery phase on a lot of this. And right now it's like I'm making an automation that says, or a scheduled task that says, I go through my Slack channels. These are the things that I care about and think are most important.

所以我还在定义这个。这些是需要留意的事情，不同的类别。这里有一些上下文。它会设置成一个自动化任务，前几次运行时可能需要一些引导。幸运的是，用这个应用，我不需要去搞清楚怎么编辑指令。我只需要说，‘嘿，下次运行的时候，能不能关注这个？’或者‘能不能弱化这个工作流？’或者‘嘿，发生了这件事，简报里没提到，能不能确保这些内容包含进去？’所以我可以在过程中引导它。它会更新通知我的方式等等。

So I'm still kind of defining that. These are things to watch out for, different categories. Here's some context. It'll get set up as an automated task, and the first few times it runs, it might need some steering. Luckily, with this app, I don't have to figure out how to edit the instructions. I can just say, 'Hey, next time this runs, can you please worry about this instead?' or 'Can you de-emphasize this workstream?' or 'Hey, this thing happened and it didn't come up in a brief. Can you make sure that stuff is in the shape?' So I can coach it along the way. It'll update the way it notifies me, stuff like that.

太棒了。不过我觉得在未来，这一直是聊天机器人形态的核心问题，对吧？我知道怎么设置，我有时间去设置，因为对我来说这是产品探索。但如果你不在 OpenAI 工作，不开发这个，你就不想搞明白所有这些事情。我们需要搞清楚那种形态。

Amazing. I think in the future though, this has been a core problem with the chatbot shape, right? I know how to set this up. I have time to set this up because for me it's product discovery. But if you're not working at OpenAI, not developing this, you don't want to have to figure out all this stuff. We need to figure out that shape of things.

对。我听到的是，我觉得人们没有意识到你的应用可以很像 OpenClaw。

Yeah. What I'm hearing is I don't think people realize that your app can act a lot like OpenClaw.

是的。人们非常兴奋，只要跟它说话，设置这个东西，每天帮我检查这个，然后告诉我发生了什么。它开始成为所有这些产品的一部分。

Yeah. People were so excited about just talking to it, setting up this thing, checking on this thing for me every day and then telling me what's going on. It's starting to become a part of all these products.

这太棒了。所以有人设置这个的方式就是直接在应用里说，‘我想设置一个自动化来做这个。查看我的 Slack，这些是我想做的事情。’

Which is amazing. So the way somebody would set this up is they just talk within the app and say, 'I want to set up an automation to do this. Look at my Slack and these are the things I want to do.'

对，很好。

Yeah. Great.

对。然后应用会说，‘我可以添加 Slack 连接器吗？’是或否？你可以点‘是’。我们至少能做到的是，如果你不知道如何在应用里做某事，你可以直接问它，对吧？

Yeah. And the app will say, 'Can I add the Slack connector?' Yes or no? You can hit yes. The least that we can do is make it so that if you don't know how to do something in the app, you can just ask it, right?

对。我觉得这还不够，但这是至少能做的。

Yeah. I don't think that's enough, but I think that's the least we can do.

一个很好的例子是，我建了一个小应用来过滤收件箱里的垃圾邮件。每封进来的邮件，我用 Codex 构建了这个。它查看邮件，判断是不是我不想看的未经请求的冷邮件，然后打标签放到别处。设置这个的时候，有一个步骤是必须进入 Google Cloud Console，设置所有这些 Pub/Sub API 和触发器。我不知道你有没有用过那个界面，非常烦人又慢。所以我就想，等等，如果我让你来做呢？我就说，‘好的，帮我做这个。’然后它描述了计算机使用。我从来没在我的电脑上见过这种情况。它直接接管了我的电脑，开始操作。

A good example is I built this little app that filters spammy email for my inbox. Every email that comes in, I built this in Codex. It looks at it and decides if it's unsolicited cold email stuff that I don't want to look at, labels it and puts it somewhere else. To set that up, one of the steps was you have to go into the Google Cloud Console and set up all these Pub/Sub API things and triggers. I don't know if you've ever used that interface. It's so annoying and slow. So I was like, wait, what if I ask you to do it? And I said, 'Okay, cool. Do this for me.' And it just described computer use. I've never actually seen this happen on my computer before. It just takes over my computer and starts going there.

就像，我不管你有没有连接器，兄弟。我就直接开始点击。

It's like I don't care if you don't have a connector, man. I'll just start clicking.

对，它自己搞定了。看着它做自己的事，太疯狂了。

Yeah. And it figures it out. It's crazy just to watch it doing its thing.

设计连接器之间的决策边界，什么时候用应用内浏览器，什么时候用连接的 Chrome 扩展，什么时候用计算机使用，这很有趣，而且都是通过摸索来完成的。我前几天看到一个很棒的推特帖子，描述了这三种情况以及各自的用途。

Designing the decision boundary between connectors, when to use the in-app browser versus your Chrome extension that's connected versus computer use is interesting and all done through just feeling it out. I saw a great Twitter thread the other day where they described all these three and what you use it for.

对，这个人描述得很好。

Yeah. So, this person described it really well.

这些个人工作流真的很有趣，因为有些特别契合。有些人在尝试各种东西。每个人都在构建自己的个人系统。你问这里的每个人他们做什么，答案都不一样。然后会出现一些主题，我们就会想，‘你知道吗，这应该成为应用里的一流体验。’我们应该把每个人似乎都在设置的这个东西直接做好。我觉得记忆功能差不多是这样的：我们有很多人，其他公司也有很多人，他们说，‘我建了一个 Obsidian 库或 Notion 区域，然后告诉它如何构建我的思维宫殿，如何存放。’我就想，我不知道是否每个人都应该这么做。应该有一个记忆功能直接帮你做，对吧？那是相当通用的。所以这是一个。但还有其他东西，比如你的工作流程，有些东西确实应该由你设置。但我觉得我们一直在权衡：哪些对个人有效，哪些应该进入产品，哪些应该保持原样，‘不，那就是你做事的方式。’哪些应该成为基本功能，哪些不应该。

These personal workflows are really interesting because some of them really click. Some people are trying all sorts of stuff. Everybody's making these personal systems. You ask everybody here what they do and everything's going to be different. Then certain themes arise and we're like, 'You know what, that should be a first-class experience on the app.' We should take this thing that everybody seems to be setting up and just make that work. And I think memory is sort of in the shape where we've had a lot of people, and a lot of people at other companies too, are like, 'Well, I set up an Obsidian base or a Notion area and I tell it how to basically build my mind palace and how to put it.' It's like, I don't know if everyone should have to do that. There should be a memory feature that does that for you, right? That's pretty generic. So that's one. But then there are other things like the process of your job, and there's something that yeah, you should set that up. But I think we're constantly weighing through what's working for individual people, what should enter the product versus stay like, 'No, that's just how you do your job.' What should become a primitive, what shouldn't.

对，这就是你之前提到的品味和判断。提到这些，我想稍微谈谈浏览器使用这块，因为我觉得人们没有意识到这有多强大，以及它能用来做什么。这让我想起，不知道你有没有看 Dan Shipper 上播客，他预测我们会开始用 Codex 在内部运行 SaaS 应用。

Yeah, this is the taste and judgment you spoke of earlier. Citing these things, I want to talk about this browser use piece a little bit because I think people don't realize how powerful this is and what it could be used for. It reminds me, I don't know if you watched when Dan Shipper was on the podcast, he had this prediction that we're going to start using Codex to run our SaaS apps inside.

对。所以，而不是用 Chrome，我知道他每天在 Slack 上问我这个，要东西。你觉得事情会走向这样吗？我们就在 Codex 应用里工作，用里面的 Notion、Linear 和 Salesforce，有你的智能体在旁边帮忙？还是你觉得这是不同的方向？

Yeah. So, instead of going in Chrome, I know he slacks me about this every day asking for stuff. Do you feel like this is where things go, where we're just working within the Codex app using Notion and Linear and Salesforce inside with your agent kind of helping you along? Or do you think that's a different direction?

这真的很有趣，因为显然我们有过几次浏览器形态活动的尝试，对吧？Operator、Tragic de agent 模式、Atlas，现在我们有桌面应用内的应用内浏览器。我们还有能力安装 Chrome 扩展，让应用连接到 Chrome。我们尝试过很多形态，我觉得我们学到了很多不同的东西。有很多因素在起作用，有很多非常无聊的因素。比如，你知道，我们最初发布的应用是 Electron 应用。应用内浏览器能做的事情有点不稳定。所以我们的应用内浏览器是用于开发的，用于在开发中测试前端。我们当时说，‘这不是给别的用的，伙计们。这是个开发者工具。’然后我们切换到了自己的栈，这个栈曾驱动 Atlas 浏览器，所以现在我们有了多标签和企业安全，这样你就能真正登录所有网站了。所以我们一直在迭代这个。

It's been really interesting because obviously we've had a few attempts at browser-shaped activity, right? Operator and Tragic de agent mode and Atlas and now we have the in-app browser inside of the desktop app. We also have the ability to install a Chrome extension where the app connects to Chrome. We've had a lot of shapes at this and I think we've learned a lot of different things. There's a lot at play. There's a lot of really boring things at play. Like, you know, we originally launched the app. It's an Electron app. The things that you can do with in-app browsers there, it's kind of janky. So we had the in-app browser for development. It was for testing your front end on development. And we were like, 'It's not really for anything else, guys. It's a developer tool.' And then we switched over to our own stack which had powered the Atlas browser and so now we've got multi-tab and enterprise security so that you can actually log into all your websites. So we've been iterating on this.

我认为困难之处一直在于这个浏览器的形态应该是什么样的。它是只供智能体使用吗？比如你有 Chrome，你打开 Chrome，在 Chrome 里做你的事情。如果你要求桌面应用，它会快速打开一个它可以控制的浏览器，没有 Playwright 之类的延迟。但我们是说这个应用适用于一切，并希望用户把它当作浏览器来用吗？这有很多权衡。这不是一条非常成熟的路，对吧？大多数浏览器都是顶层有浏览器标签页的浏览器。这会产生很多无聊但繁琐的问题，比如键盘快捷键。我们是要把按键映射到 VS Code、Chrome、我们自己的东西还是 Linear？我们希望有一些肌肉记忆能延续，但所有这些都有不同产品子形状的形态。我们该怎么办？这恰恰凸显了这个应用有多具挑战性，你必须让它既能为从未构建过任何东西的人工作，从更基础的用户到像 Peter 这样的高级用户，他试图用它来编码。我不确定我能让 Peter 使用这个应用。我想他可能是最后一个坚守终端的人。但我会继续尝试。

I think the tough thing has always been what should the shape of this browser be like. Is this something that is only for the agent? Right, that you've got Chrome, you open Chrome, you do your thing in Chrome. If you ask the desktop app, it opens up this browser that it can control really quickly, doesn't have the latency of Playwright or whatever. But are we trying to say this app is for everything and we want you to use this as a browser? Those have a lot of trade-offs. It's not a super well-traveled path, right? Most browsers are browsers at the top level that have browser tabs. This creates a lot of boring but tedious problems like keyboard shortcuts. Are we trying to do key mapping to VS Code or to Chrome or to our own thing or to Linear? We want to have some sort of muscle memory that carries over, but we have all these things that have shapes like sub-shapes of different products out on the market. What do we do? This just highlights how extra challenging this app is, where you have to allow it to work for somebody that's never built anything, from the more basic user to power users like Peter, who's trying to code with it. I'm not convinced I'm going to get Peter to use the app. I think he might be the last terminal holdout. But I'm going to keep trying.

让我退一步，谈谈这一切的大方向。Codex 的愿景是什么？它会走向何方？一两年或十年后会是什么样子？

Let me zoom out for a moment and talk about the big picture of where you're taking all this. What's the vision for Codex? Where does this go? What's it going to look like in a year or two, 10 years?

我们之前有 Codex 作为 CLI，然后决定构建这个应用。我们对这个应用有些不确定，但对它作为开发者工具的潜力很有信心。它不会是一个 IDE，而是一个大小合适的界面，有点像聊天机器人，但不止于此，你可以看到代码，但我们不会让你编辑代码。在 OpenAI，一月份和二月份发生了一件非常有趣的事情，在我们实际发布 Codex 应用之前，我们开始内部试用 Codex 应用。我们在工程和研究工作流上收敛到了相当清晰的内部产品市场契合点。他们非常兴奋。我们想，好吧，我们只需要在向世界发布之前提高质量门槛。我们确信这会成为一件大事。但在公司内部，我们启动了其他几个工作流，说，嘿，Codex 的这些编码智能体有点意思，我们有来自市场、通讯、财务、法律，基本上每个部门的人都在使用这个 Codex 应用，尽管它对这些用户来说非常不友好。它试图向他们展示代码，试图请求批准运行命令，做所有这些对他们来说不是合适产品界面的东西。那我们为什么不把我们的其他界面也加上 Codex 呢？我们把它加到 ChatGPT 桌面应用里，加到 Atlas 浏览器里。基本上，我们吸取 Codex 的经验，让它更通用，成为一个通用的知识工作工具。这些努力进行了一段时间，然后最烦人的问题出现了：没有人愿意离开 Codex 应用去那些据说为其他角色设计的应用。我认为这里的教训是，开发者工具与通用知识工作工具之间有很多细微差别，不是非此即彼。我们对此深信不疑。就像我们谈论你的角色的平均值就是你现在的角色一样，在产品方面也是如此。做 Excel 工作的人不想看到 Git 仓库信息。我们知道这一点。但我们也知道，从他们正在做的事情中，我们可以了解到很多关于他们所做工作的类型，我们可以从简单开始，根据需要让产品变得复杂。这并不意味着我们没有模式。你可能需要一些模式来组织你的东西，并让你进入体验的方式清晰可见。但我们坚信，我们在这里构建的东西是处理深度垂直领域事物的正确形态。我们与财务团队、科学团队、法律团队深入合作。如果我们能在正确的通用模型中构建正确的可扩展性原语，那么你就可以用它做任何事情。我们的挑战是如何让它通用化？这又回到了我们能构建的最佳桌面应用是什么的问题上。Codex 是开发者工具，ChatGPT 呢？它会走向何方？这就是我们的思考方式。

We had Codex as a CLI, right? And then we decided to build this app. We were a little uncertain about the app, but had a lot of conviction in what it could be as a developer tool. It wasn't going to be an IDE. It was going to be this right-sized surface where it was sort of a chatbot, but more than that, and you could see the code, but we weren't going to let you edit the code. There's a really interesting thing that happened at OpenAI in January and February, before we actually released the Codex app, which is that we started to dogfood the Codex app. We were converging on some pretty clear internal PMF on engineering and research workflows. They were thrilled. We were like, all right, we just got to get the quality bar up before we release it to the world. We're convinced that this will be a thing. But then at the company, we spun up a few other workflows to say, hey, this Codex effort is onto something with these coding agents, and we have people from marketing, comms, finance, legal, basically every discipline, who are using this Codex app even though it is actively hostile to these people. It is trying to show them code, trying to ask for approval to run a command, doing all of these things that are actively not the right product surface for them. So why don't we take our other surfaces and add Codex to them? Let's add it to the ChatGPT desktop app. Let's add it to the Atlas browser. Let's essentially take the lessons of Codex and make it more general for a general knowledge work tool. Those efforts went for a little bit, and the most annoying problem happened: nobody would leave the Codex app for the apps that were allegedly for these other personas. I think the lesson in all of this was that the whole developer tool versus general knowledge work tool has a lot of nuance that isn't just one or the other. We believe really strongly in this. In the same way that we talk about the average of your role is what your role is now, this is true on the product side too. People who are doing Excel work don't want to see git repository information. We know that. But we also know we can tell a lot from what they're doing about what kind of work they do, and we can start simple and grow the product complex as we feel is needed. Doesn't mean we don't have modes. You might want some modes for organizing your stuff and to be legible about the ways that you enter the experience. But we really believe strongly that what we've built here is the right shape to take on really deep vertically focused things. We work deeply with our finance team, our team working on science, team working on legal. If we can build the right extensibility primitives in the right general model, then you can do anything with this. Our challenge is how do you generalize it? This is kind of going back to the best desktop app that we can build. What does that look like? Was Codex the developer tool, ChatGPT? Where does this go? This is how we think about it.

你提出的观点非常有趣，Codex 应用在让人们意识到它的存在方面做得很好，而且好用又有趣，以至于每个人都开始使用它，而不是 ChatGPT 应用。所以很明显，方向是合并它们，这样就不会造成这种混乱，我知道人们一直在讨论这个想法，把它们整合在一起。

It is so interesting the point you made that the Codex app was so good at getting people to be aware it existed and so good to use and fun to use that everyone started using that versus the ChatGPT app. So clearly the direction is to combine them so that you're not creating this confusion, which I know is something people have been talking about, this idea of bringing them together.

有人称它为超级应用，我希望他们没说过，因为现在我每天都要听到超级应用这个词。我们会克服的。

Somebody called it a super app and I wish they hadn't said that because now I have to hear about the super app all day every day. We'll get past it.

但这是不是那个想法，不叫它超级应用，而是人们去一个地方做所有事情？这是总体想法还是待定？

But is that the idea, not to call it a super app, but the idea is one place people go to do all the things? Is that the general idea or TBD?

是的。我认为我们看到的是，它是一个很好的大本营。它是一个很好的地方，可以跟踪你需要在不同界面上做的所有事情。有些事情你完全在应用内完成。有些事情应用会打开其他应用来完成。应用可以连接到 Excel，所以是的，它内部有一个电子表格编辑器。这对 OpenAI 里做财务建模、筹集数十亿美元的人来说够用吗？可能不够。所以应用直接与你桌面上的 Microsoft Excel 插件通信。完成后，你可以关闭 Excel。这不仅仅是画一个矩形在屏幕上，所有事情都需要在那个矩形内发生。这个东西应该成为你的家，你开始工作、结束工作、自动化工作，它使用你需要的任何东西。

Yeah. I think what we see here is that it's a great home base. It's a great place to keep track of all of the things that you have to do across different surfaces. Some of those things you do all of it in the app. Some of those things the app opens other apps to do. The app can connect to Excel so that, yes, it has a spreadsheet editor inside the app. Is that good enough for people doing financial modeling at OpenAI for raising billions of dollars? Probably not. So the app talks directly to the add-in in Microsoft Excel on your desktop. When it's done, you can close Excel. It's not just about drawing a rectangle on the screen and everything needs to happen in that rectangle. This thing should be a home for you where you start work, you end work, you automate work, and it uses whatever you need to do.

对吧？有个很棒的故事，我们在这个房间里为 Codex 应用的首次发布拍摄了一些视频。我们内部的 DX 摄像师 Brent 负责剪辑所有这些视频，他用 Codex 完成了剪辑，这是早期人们用这个东西做事的惊人例子之一。他决定开始使用 Codex 的过程非常有趣。他一开始只是好奇 Codex 能不能剪辑视频。Codex 本身并不是视频编辑器，它没有任何那样的用户界面，但它能理解他使用的是 Premiere Pro。它可以通过编辑 Premiere Pro 中屏幕背后的文件来做一些剪辑，但并不能做所有事情。所以很自然地，Codex 做的是为自己构建了一个可以安装到 Premiere Pro 中的扩展，然后它可以和这个扩展对话，说：‘嘿，Premiere Pro 扩展，你能帮我改一下 Premiere Pro 应用里的这个标记吗？’我们看到这一幕的时候觉得太疯狂了。

Right? There's a great story about some videos we shot in this room for the original launch of the Codex app. Our in-house DX videographer Brent was tasked with editing all these videos, and he edited them with Codex, which was one of the early examples of people using it in surprising ways. The process for why he decided to start using Codex was really interesting. He started just because he was curious if Codex could edit videos. Codex is not a video editor per se; it doesn't have any of that UI, but it was able to understand that he used Premiere Pro. It could do some edits by editing the files backing what was on screen in Premiere Pro, but it couldn't do everything. So naturally, what Codex did was build itself an extension that could be installed into Premiere Pro, which it could then talk to and say, 'Hey, Premiere Pro extension, can you please change this marker inside the Premiere Pro app?' That was pretty nuts when we saw that happening.

这是一个很棒的模型。有一些专门工具擅长特定的事情，我们试图用 Codex 和现在的 ChatGPT 同时做两件事。一是我们如何与你已经在使用的这些工具无缝交互？我们不需要为你构建一个更好的视频编辑器，但 Codex 和 ChatGPT 可以使用那个视频编辑器；它们可以交互并把任务交给它。那么我们如何做到这一点？通常是通过连接器、计算机使用，或者在这个例子中是通过扩展。然后还有 Dan Shepard 的做法：‘嘿，我有这些网页应用，你可以点击使用，但我希望能够把它们在 Codex 中打开，让 Codex 做额外的事情。’所以这有点像两个几乎互为逆的模型，我们同时在这两方面做了很多工作。

It's a great model. There are these specialty tools that specialize in things, and we're trying to do two things at once with Codex and now with ChatGPT. One is how can we seamlessly interact with these tools that you're already using? We don't need to build a better video editor for you, but Codex and ChatGPT can use that video editor; they can interact and hand stuff off to it. So how can we do that? That's often through connectors, computer use, or even extensions in this case. And then there is Dan Shepard's thing: 'Hey, I have these web apps that you can click around and use, but I want to be able to open these in Codex and have Codex do extra stuff with it.' So those are kind of like two models that are almost inverse of each other, and we're doing a lot with both at the same time.

这个 Premiere 的故事对我来说很有趣，因为它再次说明了要对这些 AI 工作更有野心。你可能不知道，也许它们能做这件事。几乎就是去试试看，看看它能不能搞定。我要带大家进入播客的一个固定环节，我称之为‘失败角落’。所以我的问题是：人们看到像你这样的人，一路高歌猛进，不断成长，一切都很成功。Codex 做得这么好。这个疯狂的职业生涯，一切都在上升。人们可能看不到那些事情不顺利的时候，以及你推出但失败的东西。这些故事对人们来说非常重要，让他们知道并非总是成功。你能分享一个职业生涯中失败并教会你重要一课的故事吗？

This Premiere story is interesting to me because it's another example of just be more ambitious with these AI jobs. You may not know, maybe they could do this thing. It's almost just like go try, go try, see if it figures it out. I'm going to take us to a recurring corner on the podcast that I call fail corner. So the question for you is: people see people like you just killing it, growing, everything's winning. Codex is doing so great. This crazy career, everything's up and to the right. People may not see the times that things didn't work out and things that you launched that were failures. These stories are really important for people to hear that it's not all just a win all the time. What's a story of a time you failed in your career that taught you something really important?

听到你那样描述我，我觉得很有趣，这也许是我第一次感觉自己没有在失败。我当了好多年的创业公司创始人。最后基本上是把公司拆着卖了。那是好几年，很艰难，高度监管的领域。整个过程感觉就像不断的失败。我去了另一家创业公司，我们试图在一个非常封闭、受监管的行业里做一些 AI 工具，感觉就是一次又一次尝试，但都不成功。所以对我来说，我其实失败了很多次。有时候只是时机到了：技能、热情、市场时机都吻合了。在这个项目里，我们把从 Codex 应用中学到的东西和 ChatGPT 结合起来，经历了不知道多少次微小的失败，我们觉得‘应该是这个形状’，然后扔到 Slack 里，结果有 2000 条消息的讨论说我们有多蠢。这就是我喜欢 OpenAI 的地方：人们会直接告诉我们。在内部产品失败时，大家毫不留情。这就是为什么外部产品很棒，因为它经历了这些‘这很烂’的循环。我在达到这一点之前失败了大概 10 到 15 年，所以我每天仍然惊讶于事情进展顺利。

It's funny to hear that description played back at me, and this is perhaps the first time I've not felt like I was failing. I was a startup founder for a long time. I ended up selling the company for parts essentially. It was years, a slog, heavily regulated spaces. The whole thing felt like a constant failure. I went to this other startup and we were trying to do some AI tools in a pretty locked down regulated industry, and that felt like time after time of trying things and it not working. So to me, it's been like I've failed actually quite a lot. Sometimes it's just a point in time where things line up: skill set, passion, point in the market line up. With this project to bring what we've learned with the Codex app and marry it with ChatGPT, there have been I don't know how many micro failures where we're like 'this is the shape it should look like' and then throw that in Slack and there's like a 2,000 message thread about how stupid we are. That's the thing I love about OpenAI: people will just tell us that. There's no holding back on when we fail with product things internally. It's why the external product has been pretty great, because it goes through these cycles of 'this sucks'. I failed for like 10 to 15 years before getting to this point, so I'm still surprised every day that things are going well.

我认为这对人们来说非常重要：你可能有很多事情不顺利，然后事情开始变得非常好，我想教训就是继续前进，继续学习。

I think this is really important for people to hear: you can have a lot of things not work out and then things start to work out super well, and it's just keep going and keep learning, I imagine, is a lesson.

好了，我们到了非常刺激的闪电环节。我有五个问题要问你。

Well, with that, we reached our very exciting lightning round. I've got five questions for you.

太好了。开始吧。

Great. Here we go.

你经常向别人推荐哪两三本书？

What are two or three books that you find yourself recommending most to other people?

你看，我现在是家长了。我有小孩，所以我不知道。有一本叫《咕噜牛》的书给我孩子看。我家孩子最近迷上了《咕噜牛》。我们有一个睡前流程表，现在是：睡衣、刷牙、书、咕噜牛、盖毯子。这本书太好了。

See man, I'm a parent now. I'm a parent of young kids, so I don't know. There's one called The Gruffalo to my kids. Our kid just got obsessed with The Gruffalo. We have a bedtime chart and now it's like pajamas, brush teeth, books, Gruffalo, on blankie. It's so good.

是的。我现在读的其他书也是这种风格。其实《咕噜牛》还不错。我觉得有些书没那么……太可爱了。是啊。虽然每本童书都跟死亡有关。有人吃人，有人杀人。总有谋杀。是的。还有毁灭。暴力。即使对他们来说不觉得是暴力，那些词也制造了弧线和兴奋感。是啊。好的。好选择，《咕噜牛》。

Yes. So other books I'm reading right now are like that style. I'm like actually The Gruffalo is not a terrible one. I feel like there's some less... So sweet. Yeah. Although every kids book is about death. Someone's eating someone, someone's killing. There's always like bad murder. Yeah. And destruction. Like violence. Even when it doesn't feel like violence to them, the words create an arc and excitement. Yeah. Okay. Great choice, Gruffalo.

我现在有一堆书要读。我需要把它们都读完。

I currently have a book backlog. I need to read all of them.

你孩子还喜欢其他童书吗？

Any other children's books that your kid likes?

好的，实际上我对童书很了解。我最喜欢的童书是一本很老的书，叫《大橙色斑点》之类的。查一下，很棒。去买吧。如果你讨厌业主协会，就去买。这本书讲的是普拉姆宾先生，他住在一个所有房子都一样的街上。街道非常整洁。然后有一天，一只鸟把一大罐橙色油漆掉在他房子上，他说：‘去他的。’我豁出去了。于是他去了商店，买了油漆、吊床、鳄鱼，彻底改造了他的房子。邻居们很愤怒，说什么业主协会、房产价值之类的。这本书不是关于业主协会的，但我非常反对业主协会。这本书真的很酷。然后邻居们一个接一个地去找他谈话，喝他们所谓的柠檬水，但那柠檬水非常有说服力，因为他们一个接一个地开始改造自己的房子。比如有个人做了一艘船。我觉得这是一本好书。

Okay, so yes, actually I am well versed in children's space. My favorite children's book ever is a very old one and it's called The Big Orange Splot or something along those lines. Look it up. It's great. Go get it. If you hate HOAs, go get it. It's about this guy, Mr. Plumbean, who lives on a street where all the houses are the same. It's a very neat street. Then one day a bird drops a large can of orange paint on his house and he says, 'F it.' I'm going all in. So he goes to the store, he gets paint, hammocks, alligators, and he totally redoes his house. The neighbors are up in arms, like HOA, property value, whatever. It's not about HOAs, but I'm a very anti-HOA person. It's just really cool. Then one by one, the neighbors go talk to him, have what they refer to as lemonade, but it's a very convincing lemonade because one by one, they all start redoing their house. Like one guy does a boat. I think that's a good book.

我从这里听到的是主动性。

What I hear from this is agency.

主动性。没错。你直接去做就行了。

Agency. Exactly. You can just do things.

直接去做。太棒了。好，我们继续。

Just do things. Amazing. Okay, we'll keep going.

最近有没有特别喜欢看的电影或电视剧？

Favorite recent movie or TV show you really enjoyed if you've had any time.

《神奇校车》在 Netflix 上回归了。是一部新的动画片。凯特·麦克金农配音，因为弗瑞丝小姐现在是弗瑞丝教授了，她还在，但不再是主角。凯特·麦克金农配音新的弗瑞丝小姐。我一直很喜欢《神奇校车》。

So, The Magic School Bus is back on Netflix. It's a new animated series. It's got Kate McKinnon because Miss Frizzle is now Professor Frizzle and she's around but she's not the main Frizzle now. Kate McKinnon plays the main Miss Frizzle. Yeah, I always liked The Magic School Bus.

我从来没看过。

I've never used it.

我个人没时间看电影。所以我都是连续看一小时的 Netflix 剧集。你知道那种做法。

Personally, I don't have time for movies. So what I do is watch hour-long Netflix things back to back. You know that thing that people do.

哦，我没办法坐下来看完一整部电影，然后再连续看一小时的剧集。

Oh, I couldn't sit down and watch a whole movie and then watch hour-long episodes and keep going.

那有点让人上瘾。

There's something addicting about that.

最近发现并特别喜欢的产品是什么？

Favorite product you've recently discovered that you really love.

这问题真难回答。我感觉我每天都在发现我们的产品。太美了。

What was a terrible answer? I feel like I'm discovering our product every day. Beautiful.

这真是……

That's so...

我觉得 Linear 做得很好。在那之前，Linear 是我最喜欢的软件产品。

I think Linear does a great job. Until this, Linear was my favorite software product.

你们是用那个来规划的吗？

Is that what you guys used to plan in?

嗯，理论上是的。

Well, in theory.

你有没有特别喜欢的人生格言，在工作或生活中经常用到？我想问每个和我共事的人这个问题，因为我觉得自己不是个有格言的人，但别人总说我经常说一些话。

Do you have a favorite life motto that you find yourself coming back to in work or in life? I want to ask everyone who works with me this because I feel like I'm not a motto person and then people tell me stuff I say all the time.

是的。就像我们之前聊天时，有很多小亮点让我印象深刻，我都融入了这次对话。我完全理解。好，最后一个问题。你做过产品经理、设计师、工程师。这三个角色哪个最难？哪个最难挑起战争？

Yeah. Like when we were chatting ahead of this, there's so many little nuggets that stood out to me that I've integrated into this chat. So I totally hear that. Okay, last question. You've been a PM, you've been a designer, you've been an engineer. Which is the toughest role of the three? Which is the hardest to start a war?

是的。我知道。我觉得它们都很不同。让一个人觉得难的事情可能让另一个人觉得容易。关于这个三角有很多说法。这个三角会变成什么样？比如设计师完了，或者设计师应该会编程？产品经理完了？我们不再需要工程师了，因为产品经理会写所有代码？或者设计师现在要转产品经理？每个人都完了，每个人又都回来了。我不知道。有一些融合。有一些流动性被引入，我觉得这很新鲜也很棒，尤其对于那些有主动性、想做该做的事的人。同时，有些东西不应该消失。但我认为人们应该找到值得做的事情，然后想办法去完成。

Yes. I know. I think they're all very different. The things that make it tough for one person make it easy for others. There's so many takes on this triad. What's going to happen with this triad? Like designers are done or should designers code? Are PMs cooked? Do we not need engineers anymore because PMs are going to write all the code? Or are designers going to PM now? And everybody's cooked and everybody's so back. I don't know. There's some convergence. There's some fluidity that is being introduced that I think is refreshing and great, especially for people with agency that want to be able to just do the thing that needs to get done. And at the same time, there are some things that shouldn't go away. But I think people should find the stuff that's worth working on and go figure out what to do on those things.

这是一个完美的结尾。安德鲁，非常感谢你来做客。

That is a beautiful way to end it. Andrew, thank you so much for being here.

谢谢。大家再见。

Thank you. Bye everyone.

非常感谢您的收听。如果您觉得本期有价值，可以在 Apple Podcasts、Spotify 或您喜欢的播客应用上订阅本节目。也请考虑给我们评分或留下评论，这能帮助其他听众找到我们。您可以在 lennispodcast.com 找到所有过往节目或了解更多信息。下期再见。

Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennispodcast.com. See you in the next episode.

我喜欢关于 Brent 在 Premiere 里的那个事。

I love that thing about Brent in the Premiere.

是的，很酷。我也用过编辑功能。基本上就是简单的事情，比如，你能把这个剪成三段吗？就像对话中有停顿，然后 CEX 能理解。基本上，每个工作我们觉得都是从这样一个故事开始的：产品不是为此设计的，但它就像一个空白的聊天机器人，可以写代码。所以它能做所有事，但什么是有用的呢？

Yeah, that's cool. I've actually used edits as well. It's basically simple stuff like, oh, could you just cut this into the three breaks, you know, like if there's a pause in conversation like the second and CEX understands it. Basically, every job we feel like starts with a story like this, which is the product's not designed for it, but it's sort of a blank chatbot that can write code. So, it can do everything, but what are the useful things for it to do, right?

我的意思是，人们只需要对项目保持好奇心。他们需要有明确的目标，然后把 Codex 作为平台去尝试，看看会发生什么，因为完全没有风险，对吧？只是几个 token 而已。

I mean, people just have to have curiosity about the project. They have to have an intentional outcome and use Codex as the platform for that just to see what happens, because there's no risk at all, right? Just a few tokens.

几个 token。

Few tokens.

但当然，如果你在 OpenAI 工作，这方面的风险就小一些。

But of course, if you're working for OpenAI, there's less risk in that regard.

是的。你问过其中一个人什么技能重要，然后你也聊过那些厉害的新毕业生和……我不知道你是否固守现有的流程。我不知道该给什么建议，但如果有一条，那就是不要固守你的流程。要专注于你独特能交付的结果，然后改变流程去尝试。就像你一直……我最擅长理解 Figma 的自动布局，对吧？你在做什么？因为 AI 也会在这方面做得更好。

Yeah. You asked one of them like what skills are important and then you've also had conversations about the cracked new grad versus the... I don't know if you're married to the exact process you have right now. I don't know what advice to ever give, but if there's one piece, it's like do not get married to your exact process. Get married to the outcomes that you are uniquely able to deliver and then do things like change your process to try things. Like you just keep... I'm the best at understanding Figma auto layout, right? What are you doing, right? Because AI is going to be better at that also.

你一直在说有趣的事情。继续。要在 AI 领域成功，需要的自我认知水平真是疯狂。

You just keep spouting interesting things. Keep it in. It's crazy the level of self-awareness that's required to be successful with AI.

是的。这也是为什么我不敢说事情会怎样，因为我想到了我的父母。他们思想开放，专注于事业，但在这里有效的方法并不适用于所有人。没有更好的说法，但在这里的人是自我选择的，他们觉得，我是那种能想出下一步该做什么的人，而大多数人不是。大多数人不会成为早期采用者。

It is. Yeah. It's also why I'm nervous to ever say like this is how something's going to be because I think about my parents. They are open-minded people. They are into their careers but just the stuff that works here is just not going to work with everybody. There's no nice way of saying that, but the people who are here are self-selecting for, oh, I'm somebody who just figures out the next thing to do and that's just not like most of the population. Most of the population will not be an early adopter of things.

而且，总是要重新学习也挺烦人的。是啊。就像，该死，又要学新东西了。

And there's also just like it's kind of a bummer to have to relearn things all the time. Yeah. You know, it's like god damn it, just to learn a new thing again.

是啊。我讨厌重复。这是我的个人特点。我不喜欢。这也是为什么我从来不是最好的媒体人，因为我讨厌重复自己。

Yeah. Like I hate repetition. This is like a me thing. I don't. This is why I'm like not ever the best media person either because I just hate repeating myself.

完美。讨厌重复自己却要当创始人，那可真糟糕，因为你得成为首席重复官。

Perfect. Sucks to be a founder when you hate repeating yourself because you have to be repeater in chief.

所以对我来说，如果我能每天用不同的方式做我的工作，那太棒了。

And so to me, I'm like if I can come in and do my job in a different way every day. Love it.

但这不是……你为你的工作找到了产品市场契合点。

But that's not... You found product-market fit for your job.

是的。没错。这就是为什么我无法谈判，因为我觉得我不想要其他工作。太棒了，伙计。

Yes. Yeah. No, that's how I can't negotiate because I'm like well I don't want other jobs. Amazing, man.