设计 AI 体验：为六个月后的未来而构建

在过去大概 6 到 12 个月里，我看到的是人们构建方式的一种缓慢变化。现在做设计师真是太令人兴奋了。我觉得这给了很多人一种重获新生的感觉，对吧？他们基本上拥有了这种新的媒介，以前你可能会觉得自己被挡在门外，而现在唯一的限制真的就是你的想象力了。

What I've seen over the past kind of 6 to 12 months is this slow change in how people build. So exciting to be a designer right now. It's I think given a lot of people like a new lease of life, right? They basically have this new medium that previously you might have felt kind of like locked out of and now the only limit is really your imagination at this point.

欢迎来到 Dive Club。我叫 Red，这里是设计师永不停歇的学习之地。本周的嘉宾是 Ed Bayes，他是 ChatGPT Work 和 Codex 的设计负责人。我们将深入探讨 AI 体验的设计，以及为 6 个月后的未来做原型需要什么。Ed 甚至屏幕共享了他做的一些例子，并深入讲述了过去几个月里原型设计在 OpenAI 内部角色如何转变。那么，让我们从了解 Codex 设计背后的最初目标开始这场对话。

Welcome to Dive Club. My name is Red and this is where designers never stop learning. This week's episode is with Ed Bayes who's the design lead for Chachet Work and Codeex. So, we're going to do a deep dive into designing AI experiences and what it takes to prototype 6 months into the future. Ed even screen shares a couple examples of things that he's made and goes deep into how the role of prototyping has shifted internally at OpenAI over the last few months. So, let's start this conversation by hearing more about the original goal behind the design for Codeex.

Codex 在 OpenAI 的历史其实相当长，也很有故事。我想大多数人都知道这个应用，他们可能也知道 CLI，当然还有我们的模型。但多年来，尤其是在研究方面，我们一直在大力推动编程智能体，把它作为模型开发的下一个前沿。不过从产品角度看，我们最早的一次重大发布应该是在去年年初，我们推出了一款基于网页的产品，叫 Codex。你连接你的 GitHub，然后基本上就是启动这些异步任务。你发送一个提示，可能是想修一个 bug，或者你从 Slack 里得到一些反馈，把它粘贴进去，然后过一会儿你会收到一个通知，接着就有一个 PR 可以审查。

The history of Codex at OpenAI is actually pretty long and storied. So, you know, I think most people know about the app. They might have known about CLI, obviously our models as well. But, you know, for a number of years, particularly on the research side, been really pushing um coding agents as, you know, kind of the next frontier of model development. But from a product perspective, I guess kind of one of our first big launches was at the beginning of last year, we launched a kind of web-based product called Codex. And you connect your GitHub and basically kick off these async tasks. So you'll, you know, send a prompt, you might want to fix a bug or, you know, you get some feedback from Slack. You paste it in and then you then get a ping a little bit afterwards and you then have like a PR to review.

那是一款非常受喜爱的产品，但当时市场上很多其他产品走的是相反的方向。它们走的是同步路线。所以你有 Claude Code 和其他一些产品，它们是那种基于终端的产品，在人们所在的地方与他们相遇。

It was a really well-loved product, but at the time like a lot of other products in the market were kind of going the opposite way. They were going like synchronously. So you had maybe Claude Code and others and they were like these terminal-based products that kind of meet people where they are.

我在这里使用的一个关键框架就是为 6 个月后做设计。所以如果你假设模型能力会变得更好，你想想我们 6 个月后可能处在什么位置，然后开始为那个世界构建产品，这是一个很好的框架。而且你知道，我们能看到去年年底模型能力变得相当惊人。我觉得我们看到了一个机会，去构建一款生活在那个未来的产品。

One of the key kind of frameworks I use here is like designing for 6 months out. So if you just presume that model capabilities are going to get better and you think about where we might be in six months and you kind of start to build products for that world that's kind of a good framework to to use and you know we could see model capabilities getting pretty incredible towards the end of last year. We saw an opportunity I think to build a product that lived in that future.

这和我们创造的第一轮云端产品非常相似，从信息架构的角度看，也许你可以把聊天从右边移到左边，智能体成为他们交互的主要界面，审查代码和查看代码很重要，但也许没那么重要。而在之前的世界里，在那种 IDE 世界里，代码在左边，这是你交互的主要界面，你可能会进去自己改代码里的值，然后右边有一个扩展，你可能会时不时进去看看。但鉴于我们看到的模型发展方向，我们采取了一个相当有主见的立场，去构建一款智能体优先的产品，它明确不是 IDE。我们没有采用当时其他人可能采用的一些线索，我们只是看向未来，我们想，好吧，在一个模型会越来越擅长这件事的世界里，理想的界面会是什么样子？

Pretty similar to the first round of of cloud-based products that we created where from like information architecture perspective maybe you can move the chat to the left from the right the agent becomes the primary you know interface they interact with and reviewing the code and seeing the code is important but it's maybe like less important whereas in the previous world in the kind of IDE world you know you had code was on the left and this kind of you know the primary surface that you interact with you might go in and change you know change values out of the code yourself and then you have this kind of extension on the right which kind you maybe go into time to time but given where we we saw the models going we took a pretty opinionated stance to build a kind of agent first product which was you know explicitly not an IDE you know we didn't take some of the cues that maybe others at the time took and we just you know we just looked to the future and we thought okay in a world where you know models will get better and better at it like what would the ideal interface for that look like

在那个世界里，就像我说的，首先智能体在左边，那是你交互的主要对象，但同时你也会同时处理不止一件事。产品的核心论点是，我们想为你的智能体构建一个指挥中心，这意味着也许你同时处理多件事，也许从开发角度你同时处理多个代码仓库，这影响了很多我们正在做的决定。

and in that world as I say first the agent is on the left that's the primary thing you're interacting with but also you're going to be working on kind of more than one thing at once and the core thesis of the product was we wanted to build a kind of command center for your agents and that meant that maybe you're working on multiple things at a time, maybe you're working from a development perspective on multiple repos at a time and that kind of influenced a lot of the decisions that we're making.

但没错，当时我觉得这是一个相当有争议的决定。在某些方面我们算是弱势的一方，所以我们能够做出一些更大的尝试。但我记得在内部，即使在一些设计评审中，有些反馈是，我们是不是干脆做一个 IDE？我不确定。尤其是因为模型当时还没完全到位。所以我能看到它可行，但也许还需要其他几件事落地。

But yeah, at the time I think it was a reasonably kind of controversial decision. You know, in some ways we were kind of the underdog. So we were able to take perhaps some of those bigger swings, but I remember internally, you know, even at some design reviews, you know, some feedback was like, well, should we just build an IDE? Like, you know, I'm not sure. Particularly because the models weren't quite there yet. So it's like I could see it working but like you know maybe a few other things have to land.

然后你知道，从 12 月开始，我们的模型能力出现了几次真正的阶跃式变化。很明显这就是正确的形态，我们真的看到内部桌面应用相对于其他服务的采用率急剧上升，尤其是在开发者中，而且很快就扩展到其他用例、非技术用例。我们想，好吧，我们在内部确实搞出了点名堂。所以到我们发布它的时候，我们相当有信心，然后它显然从那以后增长了很多。

And then you know as kind of from December we had a few real kind of step changes in our model capabilities. It became very clear that you know this was the right form factor and we really saw that internally the internal adoption of the desktop app over other services just really skyrocketed particularly among developers and quite quickly among other use cases non-technical use cases. We kind of figured okay we're on something here internally. Um so by the time we released it you know we felt pretty confident and then you know it's obviously grown a bunch since.

我记得那个时期，左侧智能体聊天的范式刚出来。它有点两极分化，人们几乎觉得它太抽象了，而现在我们已经安顿下来，它就是那个模式，对吧？

I remember that period in time where the paradigm of the left agent chat came out. it was a little bit polarizing and people almost felt like it was too abstracted and now it's just we've settled in like it's the pattern right

我觉得即使现在，我们有一个右侧面板你可以打开，你可以在那里审查代码，因为 Codex 现在已经演变成类似聊天的桌面应用，ChatGPT Work 在网页和移动端也有。我们现在有一堆其他用例，你可以生成幻灯片，可以生成表格，这些都在那里打开。但我觉得我可能最自豪、或者说最兴奋的事情是，你可以在没有那个的情况下生活，你可以在一个相当熟悉的界面里生活，更像 ChatGPT 而不是 IDE。对我来说，这才是我们现在所处位置和前进方向真正令人兴奋的地方。有了 ChatGPT，你基本上有了这种通用的提问界面，如果你是火箭科学博士，你会去同一个界面，就像你是中西部一个学编织的人一样，对吧？并不存在针对不同原型的两种产品。我觉得我们现在随着 ChatGPT Work 和这些更易用的版本的发布，我们正在看到这种完成工作的通用界面，我觉得这非常令人兴奋。是的，我们仍然有专为开发者定制的产品。

and I think even even now you know we have we have a right panel you can open you can review code there as codex has now evolved into kind of chat desktop app and chatdy work on on web and mobile you know we now have a bunch of other use cases there you can now generate slides you can generate sheets and this kind of all all opens there but I think the thing that I maybe I'm kind of like most most proud of or almost excited about is you know you can live in the without that and you can live in it in a pretty familiar interface like more similar to say like chat GBT than like an IDE and to me that I think is the really exciting thing about where we are now and and where we're going which is you know with JBT you basically had this kind of universal interface for asking questions and if you're a PhD rocket scientist you'd go to the same surface as if you're someone learning to knit in like the Midwest right it there aren't these like two products for different different archetypes and I think what we're seeing now with the launch of CHP work and these more accessible versions. I think we're we're seeing this kind of universal interface for getting work done, which I find really exciting. It's it's, you know, yes, we still have products tailored for developers.

开发者会有自己的工作流，但打造这些真正易用的界面，只是把编码智能体的能力扩展到越来越多的人，开发者很早就用上了，现在我觉得其他人也慢慢开始了解了。

Developers will have their own workflows, but creating these really accessible interfaces just expands the access of the power of coding agents to more and more people, which developers kind of got early and now I think the rest of folks are getting to know as well.

先插播一条消息，然后我们继续。我现在正在做一个新的 Dive 网站。跟你说，能在 Framer 里搞定我需要的一切，真的很重要。它现在远不只是个网站搭建工具，它其实是一个完整的 AI 设计智能体。我可以在画布上探索想法、搭建响应式页面，甚至为所有剧集设置好 CMS，这太有帮助了。但这不只是图方便。Framer 还抬高了我能创作的上限。他们刚发布了一整套 3D 工具，让智能体能处理透视、深度、原点，然后我可以直接在画布上微调属性，不用来回写提示词。这也是我把 Dive 的一切都建在 Framer 上的又一个原因。所以，去 dive.club/framer 开始创作吧。

Real quick message and then we can jump back into it. So, I'm working on a new Dive website right now. And let me tell you, having everything I need within Framer is a pretty big deal. It's so much more than just a website builder now. It really is a full AI design agent. I can explore ideas on a canvas, build out responsive pages, even set up my CMS for all of the episodes, which is incredibly helpful. But it's not just about the convenience. Framer also raises the ceiling for what I can create. They just released a whole set of 3D tooling so agents can work with perspective, depth, origin, and then I can fine-tune properties directly on the canvas without having to prompt back and forth. It's just another reason why I build absolutely everything for Dive on top of Framer. So, head to dive.club/framer to start creating today.

还记得 Jamie Ganon 来做客聊当 AI 创意总监吗？她参与了一个为 Claire Vo 新公司做的超棒品牌项目。让我印象深刻的是，她用动效把整个揭幕过程做活了。不出所料，她用的是 Jitter。一方面，它非常简单直观，哪怕你从没做过动效设计；另一方面，它又极其强大，你可以搭建自己的创意工具，做出各种自定义动画和效果。Jitter 多年来一直是我首选的动效工具，我强烈推荐。去 dive.comclub/jitter 开始吧。

Remember when Jamie Ganon came on to talk about being a creative director with AI? Well, she was part of an incredible branding project for Claire Vo's new company. And what stood out to me was how she brought the entire unveiling to life with motion. And to no one's surprise, she used Jitter. On one hand, it's so simple and intuitive, even if you've never done motion design before. On the other, it's incredibly powerful, and you can build your own creative tools to create all kinds of custom animations and effects. Jitter's been my go-to motion tool for years and I cannot recommend it enough. Head to dive.comclub/jitter to get started.

现在进入正题。

Now on to the episode.

你能再深入讲讲把 Codex 带进 ChatGPT 的过程吗？因为 ChatGPT 在消费者友好度上算是领先的，简单到“我奶奶都在用 ChatGPT”那种程度。但你又得把全部能力装进去，不只是当下的能力，还要考虑六个月后的愿景。你最初思考怎么实现这件事时，纠结过哪些设计上的挑战？

Can you go a little bit deeper into that process of bringing Codex into ChatGPT? Because ChatGPT I think was kind of the leader in terms of consumer friendliness and a super simple "my grandma uses ChatGPT" kind of thing. And yet you have to take all of the power, not only in the present day but thinking about that six-months-from-now vision, and fit all that in. Like what were some of the design challenges that you were wrestling with when you first started thinking about what it would take to pull that off?

是的，我觉得有几个。第一个其实取决于模型能力，对吧？你得先跨过某个信心门槛，确认模型能完成一大堆非常复杂的事情。一旦跨过这个门槛，你才能开始真正精简界面。在那之前，你确实需要能验证一堆改动，对吧？再回想一下 IDE 扩展、CLI 那个世界，你可能会把代码库摆在面前，验证改动，也许再回去改东西。首先你得有信心，模型能力已经跨过某个门槛，你才能开始把这些抽象掉。另一方面，我觉得开发者是很多这类技术的超级早期采用者，他们更能接受“我打开这个编码智能体，它就能编辑我电脑上的文件”这种想法，对吧？但对很多人来说，这其实是一个全新的范式，他们可能只用过 ChatGPT 之类的产品。那些产品在网页上，不访问你的本地文件，过去可能也做不了太多操作。所以这是一种与这些智能体协作的新方式，你得带着人们一起走过这段旅程。而对开发者来说，他们很快就懂了。

Yeah, I think there are a few. I think first one of them, and it's really gated on model capability, right? You have to pass a certain threshold of confidence that the model can do a whole bunch of very complex things. And once you pass that, then you can start to really pare back the interface. Before then, you really needed to be able to verify a bunch of changes, right? So again, thinking back to the IDE extension, CLI world, right, you might have your codebase up in front of you and you can validate changes, maybe you go back and change things. First you need the confidence that the model capability has passed a certain threshold that you can start to abstract that away. And then on the other hand, I think developers were super early adopters of a lot of this technology and I think a little bit more comfortable with this idea that, you know, I open this coding agent and it can edit files on my computer, right? This is actually a completely new paradigm for lots of people who may have interacted with, say, ChatGPT and other products, right? It's in the web, it doesn't access your local files, kind of historically maybe can't take that many actions. So there's this new way of working with these agents that you have to bring people along on that journey. And I think for developers, they got it pretty quickly.

我们做了一整套很棒的沙箱保护和流程安全机制，这样如果模型要执行某些操作，比如可能在你电脑上运行命令，你可以选择逐案批准。开发者很早就熟悉了这一点。而我觉得现在的一个关键挑战是，当我们进入这个让产品变得更容易上手的世界时，也要把很多安全思维带进来，让人们保持掌控。比如，假设你连接了 Gmail，对吧？它不应该每次都直接替你发邮件，你得批准。再说一遍，我觉得就是带着一批新用户走过这段旅程，教他们：这个桌面应用能编辑我电脑上的文件，能发邮件或 Slack 消息，对吧？这背后有一大堆设计挑战。

And we built a whole bunch of great sandbox protections and safety processes so that if the model is taking some action, you know, maybe it might be running a command on your computer, you can choose to approve it on a case-by-case basis. So developers got quite familiar with this early. And then I think one of the key challenges now, as we move into this world where we're making these products way more accessible, is also bringing a lot of that safety thinking and keeping people in control. So for example, say you connect your Gmail, right? It shouldn't just send emails for you; every time you have to approve things. And again, I think just bringing a new cohort of folks along on this journey and teaching them, you know, this desktop app can edit files on my computer, it can send emails or Slack messages, right? A whole bunch of design challenges associated with that.

当 AI 热潮刚开始时，有一堆人上节目说我们必须超越聊天机器人，那种整个 UX 原语让人觉得，哦，这明显只是一块垫脚石。后来我觉得钟摆又摆回来了，人们说，是啊，其实聊天挺好的，你知道吗？我很好奇，你们内部是怎么讨论的，尤其是考虑到变化速度这么快。

So when all of the AI frenzy started, it was a bunch of people coming on to the show and talking about how we've got to push past the chatbot, you know, like that entire UX primitive felt like, oh, this is so clearly a stepping stone. And I think the pendulum swung where people are like, yeah, actually, chat's pretty good, you know? I'm wondering, like, internally what's the dialogue for you all, even particularly given how fast the rate of change is happening.

你知道，就像我说的，我们发布了 Codex 桌面应用，大概是在六个月前。在那之前，它显然是在内部使用，但我觉得从去年 12 月到现在，开发者工作流已经发生了巨大变化。不过从大局来看，这只是一段很短的时间。所以，不，我完全不觉得我们在最终形态上已经定型了。我觉得你现在已经开始看到这一点了。一些为几个月前模型能力优化的模式，现在开始受到压力测试，对吧？比如左侧边栏架构，如果你同时处理多件事，怎么导航？怎么同时展示最高优先级的事情？如果你想同时启动 10 件事，怎么做？怎么保持进度？所以桌面应用最初的设想，就像我提到的，是为你的智能体打造一个指挥中心。我觉得我们做出了第一版，但我不觉得已经结束了。尤其是，如果我们用同样的框架往前看，想想六个月后模型能力会到哪一步，如果那样推演，我绝对不认为今天的模式就是我们最终会落定的模式。

You know, we've kind of, as I say, launched the Codex desktop app. I think it was around six months ago. Before that, it was obviously used internally, but I think developer workflows have dramatically changed from like December to now. But that's, in the grand scheme of things, a very short period of time. So, no, I don't think we're locked down at all in terms of the final patterns. And I think you're starting to see that now. I think you're starting to see some of the patterns that are optimized for maybe where the models were a few months ago are starting to be stress tested, right? So for example, the left sidebar architecture, if you're working across multiple things at once, like how do you navigate? How do you show the things that are highest priority at once? If you want to kick off 10 things at once, how do you do that? How do you stay on track? So the original thesis of the desktop app was, as I mentioned, building this command center for your agents. And I think we had the first iteration of that, but I don't think we're over, particularly again if we were to take the same framework and look forward and think, okay, where are model capabilities going to be in six months? If you project that forward, I definitely don't think the patterns today are the final ones we'll land on.

我想深入聊聊你们是怎么运作的，以及设计实践是什么样的。

I want to dig into how you all operate and the practice of design and what that looks like.

不过在我们深入细节之前，你能不能先给我们一点背景，讲讲你负责的产品面，还有团队结构，有多少设计师，谁在做什么，你怎么分配工作，诸如此类。

But maybe before we get into the weeds, can you just give us a little bit of context for the surface area that you're thinking about and also like team structure, how many designers, who's working on what, how you even spread out the work, that kind of a thing.

好的，没问题。我负责 Codex 和 ChatGPT work 的设计团队。Codex 这边我们有一堆服务：有 Codex 桌面应用，还有 CLI 产品，也有 IDE 扩展。然后在 ChatGPT work 这边，也就是我们面向非开发者的智能体式产品，我们也有桌面应用，还有网页版和移动版的 ChatGPT work。所以产品面挺多的。我组织团队的方式其实不太按功能、也不太按饼图里很窄的那一块来切，而是尽量给设计师一个比较宽的职责范围。我的总体理念是，设计能在整个产品开发生命周期里创造价值，它不是最后一步的打磨，而包含大量早期的产品思考和探索。所以我更多是按用户画像而不是按功能来组织结构。比如在 Codex 这边，我们有设计师专注于开发者这一类画像。日常他们可能在做一个功能，比如代码审查功能，或者跟 Codex 桌面应用、甚至 CLI 相关的东西。但因为他们脑子里有这种更高层次的职责范围，所以当我们做引导流程、上线新的通用功能时，能确保不会在整个生命周期里漏掉开发者。其他领域也类似。比如我们有 Sites 这样的功能，也有可以创建表格和幻灯片的功能，有设计师负责这些产品功能。但同样，他们不是只为那个功能的某个具体指标做优化，因为那样会丢掉大局。他们的职责横跨整个生命周期，覆盖知识工作者使用我们产品的全过程，或者一个高级用户的全过程。所以我们有一批设计师分布在这些不同的服务上，日常可能在做具体功能，但负责的是更宽的生命周期。

Yeah, totally. So I run the design team for Codex and ChatGPT work. We have a bunch of services on the Codex side. We have the Codex desktop app, we also have a CLI product, we have an IDE extension. And then on the ChatGPT work side, which is our agentic product for non-developers, we also have a desktop app, but we also have ChatGPT work on web and also ChatGPT work on mobile. So quite a bunch of different surface areas. The way I like to structure teams is actually less around features and narrow parts of the pie, and trying to give designers a broad scope. My general philosophy is design can add value across the whole range of the product development life cycle. It's not this kind of last mile polish. It's a lot of early product thinking, explorations. So the way that I structure it is more around personas than features. So maybe on the Codex side, we have designers who are focused on a developer persona. So maybe on a day-to-day basis, they're working on a feature, maybe it's a code review feature or something related to the Codex desktop app or even the CLI. But given that folks have this higher order scope in their mind, that means that when we're doing things like onboarding, when we're shipping new general features, we make sure we don't drop the ball on developers across that whole life cycle. Similar for other areas, right? So we have features like Sites, or we have features like you can create sheets and slides, and we have designers who own those product features. But again, they're not just optimizing for some specific metric for that specific feature, because you kind of lose the bigger picture. So they're spread across the whole life cycle of what it means to be a knowledge worker using our products, or what it means to be a power user. So we have a bunch of designers spread across these different services. Day-to-day they might be working on features, but owning that broader life cycle.

我们能不能在用户画像这件事上再深入一层？比如你团队里有没有专门关注非工程师画像的设计师？是不是还有另一个维度，比如高级用户和新用户？这到底是怎么运作的？以及它可能怎样影响团队的协作方式？

Can we go just like one level deeper on the personas thing? So like are there designers on your team that are specifically focused on like non-engineer personas? Is there another axis even for power user versus new user? Like how does it even work? And maybe how does that impact the way that the team collaborates?

这确实有点模糊，因为开发者可以指很多东西，知识工作者也可以指很多东西。但在日常里，它体现为我们尽量贴近用户。所以我们做很多用户研究，也鼓励设计师每周至少花一次时间和内部或外部的人交流，这些人可能对智能体式产品比较陌生，比如做招聘或法务的人，基本上就是非开发者画像。然后我们每周也会讨论产品当下好的、坏的和糟糕的地方，什么进展顺利，什么不顺利，哪里可以改进。这其实也是一个强制机制，让大家贴近外部的用户研究。可能是 Reddit，可能是 Hacker News，可能是 Twitter，最好是更偏量化的东西。基本上就是建立一种激励机制，让大家觉得自己尽可能贴近用户，而不是坐在泡泡里做设计。

It gets a bit fuzzy, right? Because developers can mean many things, knowledge workers can mean many things. But the way that it shows up in the day-to-day is we try and stay super close to users. So we do a lot of UXR. We try and encourage designers to spend at least one session a week with folks either internally or externally who might be newer to agentic products, so it might be someone working in say recruiting or legal, basically non-developer personas. And then we also, in our weekly, talk through basically what's the good, bad and the ugly of the product at the moment, like what's going well, what's not, and where can we improve. And that is really a forcing function as well for folks to stay close to external UXR. So it might be Reddit, it might be Hacker News, it might be Twitter, ideally something more quantitative. Basically trying to create an incentive structure so that people feel like they're as close as they can to users and you're not just sitting in this bubble designing.

好，我想回到你之前提到的一个说法，你说在 OpenAI 这样的地方工作，重要的是要有这种“往前看六个月”的心态。我想知道你有没有例子说明这在实践中是什么样子，以及作为设计师，你怎么去锻炼这种面向未来六个月做原型的能力？

All right, so I want to return to a phrase that you said earlier where you talked about how working at a place like OpenAI, it's important to have this like six months out mentality. And I'm wondering if you have examples for what that looks like in practice, and as a designer how do you even think about growing this muscle of prototyping six months into the future?

我觉得对很多设计师来说，用模型生成非常丰富的内容——不只是文本，还有小组件或丰富的 UI——一直是圣杯。而超级 AGI 药丸版本就是：你不再有严格的设计系统，你让模型想怎么做就怎么做，它可以自己选择用文本回应还是用丰富的 UI 回应。但要走到那个世界，得先满足几个条件。首先，模型得在前端方面非常强。我们的模型在这方面已经取得了很大进步。但大概六个月前做这方面的设计时，你只能往前推演，假设事情会变得非常好。我觉得这里的一个挑战还在于，要针对你实际所处的约束来做设计。在生成式 UI 这个领域，大概有两个阵营。一个是高度编辑化的世界，延迟超低，方差也相当小。比如我在 ChatGPT 上发消息问一场体育比赛的比分，我大概不希望每次都用不同的小组件给我看比分。或者我问搜索结果之类的。所以我们有一套很棒的设计语言，它会适时出现，针对延迟做了优化，让回答成为非常丰富的响应。Codex 这边的一个好处是，我们用非常强大的模型，而且用户更偏高级用户，尤其是在桌面端。所以我们在延迟上有更多余地。如果模型生成完整输出，可能要花比如 10 秒左右，而在 ChatGPT 上你就得让它非常快。但有了这点灵活性，我和一些研究团队的人坐下来聊了很久，讨论这会是什么样子。我们之前没有真正探索过这个方向。我们大概经历了三个原型阶段。

I think it's been this holy grail for a lot of designers of using the model to generate very rich outputs, not just text, so maybe widgets or rich UI. And the super AGI pill version is you don't have this strict design system, you just let the model really do whatever it wants, and it can choose whether it responds in text or responds in rich UI. Right? But getting to that world is gated on a few things. First, the models have to be great at front end. Our models have made great strides in that space. But designing for this maybe six months ago, you just project forward and you just assume that things will get really good. I think also one of the challenges here is designing for the constraints that you work within. So there are maybe two camps in the Gen UI space. One is this highly editorialized world which is super low latency and the variance is reasonably small. Maybe if I send a message on ChatGPT and I ask for a sports game score, each time I probably don't want a different widget showing me what the score is. Or if I ask for a search result or something. So we have this really great design language that appears just in time and it's optimized for latency and making answers a really rich response. One of the benefits on the Codex side is we use super powerful models and I think users skew a little bit more power user, particularly on desktop. So we have a little bit more leeway with latency. If the model is generating a full output, it might take say 10 seconds or something, whereas if you're on ChatGPT you want to really make it super snappy. But with a little bit of that flexibility, I sat down with some of the researcher team and we talked about this for a while of like, what would this look like? We haven't really explored this before. We kind of had these three phases of prototyping.

一开始，你在 Figma 里做原型，做出这种很漂亮的交互，然后做压力测试，把它拆开。后来模型变得非常强，而且如果你作为设计师本身有开发背景，你就可以直接上手搭原型。所以我们最早做 Codex app 的时候，有一个 Codex 的迷你版本，我和团队里另一位设计师会进到同一个共享代码库里，基本上搭一个假版本来测试交互。我们甚至会把 API 接进去，就为了感受一下这些不同的响应是什么感觉。

First, you prototyped in Figma, and you'd bring this kind of beautiful interaction to create, you'd stress test it, tear it apart. And then once the models got really good, and also if you had a development background yourself as a designer, you could hop in and build prototypes. So we had a kind of mini version of Codex when we were first building the Codex app, where another designer on the team and I would hop into this shared codebase and basically build this fake version to test out interactions. We might even pipe in the API just to see how these different responses felt.

现在到了第三个阶段，我把它叫做——怎么说呢——就是在生产环境里 vibe。你大概率不会把它合并，但你会开一个分支，然后做最疯狂、最天马行空的想法，你用起来的感觉、体验起来的感觉就像真实产品一样。你还可以把这个分支分享给别人，他们能去看、去亲自感受。

And then now we're at this third stage, which I call it — I don't know — it's like vibing in prod. You're probably not going to merge it, but you'll create a branch and you can just do the most insane, out-there idea that you like, and the way it feels and the way you experience it when you're working with it feels like the real product. And you can just share that branch with someone, they can check it out and feel it out themselves.

我用这种方法为这类生成式 UI 的工作做了很多早期探索，测试了很多不同的例子。不过也许我可以直接给你看——这里的提示词是“用可视化的方式解释反向传播”。你可以看到，在最终的系统回复里，模型直接渲染出一个完全生成、超级可交互的答案。所以这是一个非常早期的原型，跟我们现在真正做出来的东西比，现在看还挺粗糙的。但你可以调整学习率的值。你可以点进去，还可以点击内联可视化里的某些部分，它会发出一条后续回复。对吧？所以这里你可以继续做梯度下降，它会继续带你走完这段学习体验。这是第二步。所以它又是实时渲染出一些东西。这完全是模型即时生成的。

I did a bunch of early explorations for this kind of gen UI work using this approach, tested a bunch of different examples. But maybe I can just show you — the prompt here is like, explain backpropagation visually. And as you can see here, in amongst the final system response, the model just renders a fully generated answer that's super interactive. So this was a very early prototype, it's pretty rough now compared to where we actually landed. But you can play around with learning rate values. You can go in and you can also click certain parts of the inline visualization and it can send a follow-up response. Right? So here you can continue to gradient descent and it will continue walking you through this learning experience. Here's step two. So again, it just renders something in real time. So this is fully generated by the model on the fly.

在系统层面，你们做了多少引导，如果有的话？

How much guidance at a system level are you doing, if any?

我觉得这其实是设计流程里另一个非常有意思的部分，就是这里可能还是有一点传统设计的成分，对吧？它怎么渲染，如果要复制它，那个可供性在哪里。但这里面很大一部分其实是技能编写。确实有一种做法是，你就让模型生成一切、任何东西。而且再过六个月，也许前端能力和模型会达到一个水平，可以超级一致、体验很好。但在那之前，我们觉得有一点编辑化的处理是好的。所以你会看到——我可以再给你看一个例子，对吧？你会开始看到一些模式。如果你现在在生产环境里用它，我们其实已经随着时间迭代过了。这基本上意味着，与其去详细规定这些可视化出现的具体方式——比如我再快速给你看一个例子，这个有一些 3D 可视化。如果你要把 3D 渲染可能长什么样子的每一种版本都规定出来，你基本上做不到，因为它是完全由模型驱动的，对吧？你还可以有不同的轨道场景。所以是的，与其规定到像素级别，你基本上是上升到技能层面，在技能里定义一套设计语言。也许你会引用某些 token、最佳实践，然后你构建一堆评估，对吧？

I mean, this is I think another really interesting part of the design process, which is there is a little bit of traditional design maybe, right? How does it render, if you're going to copy it, where's that affordance. But a big part of this actually is kind of skill writing. So there is a world where you just let the model generate everything, anything. And again, in six months maybe front-end capabilities and models will be at a level that it can be super consistent and feel great. But until then, we kind of felt it's good to have a little bit of editorialization. So as you'll see — I can show another example, right? You'll start to see some patterns. And if you use it in prod now, we've iterated on this over time. That means basically instead of speccing out exact ways that these visualizations can occur — like if I just show you another example real quick, this has some 3D visualizations. If you were to spec out every possible version of what 3D rendering might look like, you basically wouldn't be able to do them, because it's fully driven by the model, right? You can also have different orbital scenes. So yeah, instead of speccing out the pixels, you basically move to the skill level and you define a design language within the skill. So maybe you reference certain tokens, best practices, and then you build a bunch of evals, right?

我做法是，你建一个所谓的黄金集，比如 10 个、20 个我们想优化的提示词。比如这个学习例子，用于研究。然后你跑一遍，看输出，看哪里出了问题，也许再调整一下，然后你就可以开始构建这种能随着时间越来越好的飞轮。而且一旦你在全公司做视频，你会得到一堆反馈。所以真的是迭代式、评估驱动的。在这个早期原型之后，我把它交给团队里一位非常出色的工程师，他用非常非常科学的方法来做这件事，通过爬山法不断改进视觉效果。但没错，这是一个很好的例子，说明研究、设计、工程之间非常紧密的协作，最终推动了一些我们讨论了很久、但只有靠最近这些模型进展才真正解锁的东西。

So the way that I did it is you create a kind of golden set of, say, 10, 20 prompts that we want to optimize for. So maybe this learning example, for research. And then you'll run it through, you'll see the output, you'll see what went wrong, maybe you'll tweak it, and then you can start to build this kind of flywheel that can get better over time. And again, once you do video across the company, you get a bunch of feedback. So really iterative and eval driven. And after this early prototype, handed this off to just a really brilliant engineer on the team who took a very, very scientific approach to this to hill climb improving the visuals. But yeah, this is a good example of a really close collaboration with research, design, engineering, ultimately to push forward some things that we've talked about for a while but were really unlocked only by these recent model advances.

好，我想稍微岔开一下，聊聊评估驱动的设计在实践中是什么样子，因为这东西开始在节目里冒出来了，但我觉得我们还没有一个很好的例子，给那些不在这种环境里的设计师。

Okay, quick rabbit trail that I want to go down is what eval-driven design looks like in practice, because it's something that started popping up on the show, but I don't think we have a great example for designers who just are not in that environment.

在我看来，设计有科学的一面，也有艺术的一面，对吧？设计的科学也许是字体排印、间距。就是那种——不知道你有没有读过早期泰勒式的人机工程学大爆发那些东西，对吧？用户与界面交互有一些科学的方式，我们为此做优化。然后是艺术那一面，更开放。它由文化驱动，随时间变化。极端的一端可能更偏向感觉。所以我觉得这里面很多是偏向、倾向于前半部分的。

In my mind, you have the science of design and then you have the art of design, right? The science of design is maybe typography, spacing. It's the kind of — I don't know if you've read any of the kind of initial Taylor type explosions of ergonomics, right? There are kind of scientific ways that users interact with interfaces and we optimize for that. And then there's the art side, which is more open-ended. It's driven by culture, changes over time. The extreme end maybe more like vibe based. So I think a lot of this is leaning, skewing towards the first half.

首先，我觉得就是非常具体地弄清楚，你想用这个功能解决的用户问题是什么。然后写出一堆你基本上想敲定的黄金流程。做评估有几种方式，对吧？一种是超级科学的——你可能会想出 1000 个、10000 个不同的提示词，把所有这些输出都过一遍。但最初步的版本也许是先草拟出 10 个、20 个你想尝试的英雄流程，其中一些例子就经历过这个过程，然后基本上就是把它跑在你想要测试的任何交互或功能上。针对这些流程测试它。它在这个流程里管用吗？如果不管用，它在哪些地方崩掉？

First, I think just getting really concrete about what are the user problems that you're trying to solve here with this feature. And then writing out a bunch of basically golden flows that you want to nail down. And there are a few ways of going about evals, right? One is super scientific — you might come up with a thousand, 10,000 different prompts, you can go through all these outputs. But the baby step version is maybe sketch out 10, 20 hero flows you want to take a crack at, which some of these examples went through, and then just basically run it over whatever interaction or feature you're trying to test out. Test it for these flows. Does it work for that flow? If not, where are the areas that it falls apart?

这真的取决于功能。但对于这个来说，很多都是很细枝末节的东西，比如，好吧，这些交互里有一堆其实不太管用。所以也许有时候它画的是 SVG 而不是图标。

It really depends on the feature. But for this, a lot of it was quite in the weeds of like, okay, a bunch of these interactions don't really work. So maybe sometimes it draws SVGs instead of icons.

所以也许你可以给它多一点指导。或者有时它会偏离我们的 token 系统。再次，也许你可以给它一点指导。或者也许有特定的库，比如 3D 库或其他你可能想利用的。所以真正科学地对待它，我认为真的很有帮助。再次，你可以用小的 N 来做，对吧？10、20 个提示。然后我认为就是与研究 and 工程建立真正紧密的合作关系来扩大规模。所以构建一个评估工具，让你可以大规模测试交互。你可以自己做，也可以与某人合作来做。幸运的是，就像我说的，在这个团队我有一个非常非常出色的工程合作伙伴 Philip，他领导了很多这方面的工作，基本上创建了评估提示集，你生成大量的输出，然后你可以手动浏览它们。还有很多其他细节我可能不能深入。但我认为首先真正弄清楚你要解决的问题是什么，然后找到一种可验证和可扩展的方式来测试它。

So maybe you can give it a little bit more guidance there. Or sometimes it kind of strays from our token system. Again, maybe you can give it a bit of guidance there. Or maybe there are specific libraries, like 3D libraries or others that you might want to lean into. So getting really scientific about it, I think, really helps. And again, you can do that with a small N, right? 10, 20 prompts. And then I think just building a really close partnership with research and engineering to scale that up. So building an eval harness where you can actually test the interactions at scale. You can either do this yourself or you can partner with someone to do it. It's lucky again, as I say, on this team I have a really, really fantastic engineering partner, Philip, who's led a lot of this, basically creating the eval prompt set, you generate a huge number of outputs, and then you can just go through them by hand. And a whole bunch of other details I probably can't go into. But I think first just really getting crisp on what's the problem you're solving, and then finding a way to test it in a verifiable and scalable way.

听你说话，我意识到也许其中一个挑战是，你发现了一堆它不足的地方，然后你写了过于规定性的修复，但突然你有一堆这样的修复，你几乎在限制下一代模型可能的样子。你必须有意地弄清楚如何走这条钢丝吗？

I'm realizing listening to you talk that maybe one of the challenges with this is that you find a bunch of ways that it's falling short, but then you write overly prescriptive fixes, but then all of a sudden you have a bunch of them and you're almost like capping what the next generation of models could be. Do you have to intentionally figure out how to walk that tight rope?

是的。我的意思是，我不知道你是否听说过一点教训。这就像机器学习领域最初的必读文章。我会非常糟糕地转述，但基本上任何类型的脚手架，比如过度脚手架，就像我刚才谈到的一些东西，会随着新模型的发布而被冲走。所以，我认为你必须保持超级灵活，对吧？比如说我们用特定模型发布这个，然后当新模型出来时，你必须测试所有东西，也许你实际上可以移除之前的一堆脚手架，然后重新开始，也许你会发现一些新问题。但要把它看作一个非常动态的过程。再次，以那个北极星为目标，比如在 6 个月内，也许你实际上不提供任何指导，但在你达到那里之前，你可以帮助引导它。

Yeah. I mean, I don't know if you heard of the bit of lesson. It's like the original go-to essays in the ML space. I'm going to paraphrase it very badly, but basically any kind of scaffolding that you do, like over scaffolding, some of the things that I just talked about, will kind of get washed away with new model releases. So, I think you just have to stay super flexible, right? To say we ship this with a particular model and then when a new model comes out, you have to test it all, maybe you can actually remove a whole bunch of the scaffolding that you had before and you start again, maybe you find some new issues. But seeing it as a very dynamic process. And again with that north star, like in 6 months, maybe you actually don't provide any guidance, but until you get there, you can kind of help steer it along that way.

还有其他你想分享的原型示例吗？我注意到还有几个窗口。

Were there other prototyping examples that you wanted to share? I noticed a few more windows.

是的，我有一个搞笑的。所以它绝对不是最精致的版本，但它与我在团队中尝试建立的人驱动方法有关。我的产品设计理念是，我们与产品经理和其他产品人员非常紧密地合作，但真正推动人们也推进自己的想法。如果他们有一个特定的未来愿景。所以，我早期的一个原型，当时我们称之为 autopilot，它基本上演变成了所谓的 goal，我认为已经被很多人使用，就是这个想法。它可能来自一个循环梗，你也许对模型说哦我想创建这个网站，然后你只需排队一堆继续继续的提示，网上曾经有一个梗说很多人以这种方式工作。所以再次，像与研究合作，与 harness 团队的其他人在某种程度上合作，我们坐下来思考，好吧，如果围绕更基于目标的模型稍微重新构建提示，实际上会是什么样子？所以说你的提示是一个目标，有一些成功标准，你能基本上启动一个提示，然后当助手回合结束时，运行几乎像一个分类器，说好吧你解决了那个目标吗？如果没有，继续。所以更多这种 autopilot 世界。所以这就像一个超级搞笑的例子，但它是基于那个的即兴创作，对吧？所以你基本上可以打开这个 autopilot 功能，对吧？也许你定义成功标准可能是什么，然后你启动它，然后我们有这种类似 Figma 风格的 UI，也许代理在控制中，它在发送消息，当助手响应结束时，它会考虑好吧它解决了那个目标吗？如果没有，好吧继续，让我们发送一个提示来达到那里，它可以基本上运行只要你喜欢。所以这是一个搞笑的例子。我想它像是创造世界上最好的笑话之类的，这显然是一个棘手的问题，没有真正的答案。但这是我刚刚拼凑的一个早期原型。我们在周五有这些很棒的演示日之类的事情，我们分享原型，然后是的，这最终演变成一个更简单的界面，就是 goal，我们把它带入了 harness 和产品中。但再次只是一个例子，在生产中 vibe。所以这只是一个我拼凑的分支。可能像一个周末的事情，实际上这会是什么样子？你可能有哪些不同的交互？你只是设置一个提示吗？你有一些奇怪的接管东西吗？

Yeah, I have a goofy one. So it's definitely not the most polished version, but it's kind of related to the person-driven approach that I try to build with the team. My philosophy on product design is, you know, we work very, very closely with PMs and other product folks, but really try and push folks to push forward their own ideas as well. If they have a specific vision of the future. So, one very early prototype that I jammed on was at the time we called it autopilot and it basically evolved into what is called goal, which I think has been used by a lot of folks and it's this idea. It kind of came from one of these maybe this kind of loop meme where you maybe you say to the model oh I want to create this website and then you'll just queue up a bunch of continue continue prompts and there was a bit of a meme at one time online that a lot of people work in that way. So again, like working with research, working with others on the kind of harness team, we kind of sat down and thought through okay what would it actually look like to slightly reframe prompting around more of an objective-based model, right? So say your prompt is an objective that has some success criteria, can you basically kick off a prompt and then when the assistant turn finishes, run almost like a classifier and be like okay did you solve that objective? If not, carry on. So more of this autopilot world. So this is like super goofy prototype but it's a riff on that, right? So you basically can turn on this autopilot feature, right? Maybe you define what might the success criteria be and then you kick it off and then we have this kind of like Figma style UI maybe where the agent's in control and it's sending messages and when the assistant response finishes, it will consider okay did it solve that objective? If not, okay carry on and let's send a prompt to get there and it can run basically as long as you like. So this is a goofy example. I think it was like create the best joke in the world or something which is obviously one of those tricky problems which doesn't really have an actual answer. But this was like an early prototype that I just jammed together. We have these great demo day type things on Fridays where we share prototypes and then yeah this eventually evolved into a much simpler interface which was goal which we brought into the harness and the product. But just an example again of vibing in prod. So this was just a branch that I jammed on. Probably like a weekend thing of like actually what would this look like? What are the different interactions that you might have? Do you just set a prompt? Do you have some weird takeover thing?

我想稍微谈谈那个周五演示环境。所以你知道设计团队中的每个人都在把原型带到桌面上。这些原型中有多少百分比属于你所说的这种 vibe prod 类别 3 类型的原型？

I want to talk about that Friday demos environment for a little bit. So you know everybody's bringing prototypes to the table within the design team. What percentage of those prototypes are in this like vibe prod category 3 type of prototype that you're talking about?

绝对在增加。我认为在过去六个月、十二个月里，我看到的是人们构建方式的缓慢变化。正如我之前提到的，可能在过去一年左右或几年里，有这三种浪潮，你有 Figma 原型，然后你有这些迷你假原型，然后有这种方法，你只是创建一个分支。你知道，随着时间的推移，我看到的一件事，我们也有进行中的设计频道，人们在那里发布东西，有很多人我坐下来和他们聊天，我认为，你知道，他们以前没有编码过，然后突然他们发送这些链接，比如他们构建的应用程序，我就像，哇，你知道，你是怎么构建的？就像，是的，你知道，开始使用 codec，他们就像转变了一堆。

Definitely increasing numbers. I think what I've seen over the past kind of six, 12 months is this slow change in how people build. As I mentioned earlier, there have been these kind of like three waves maybe over the past like year or so or few years where you had like Figma prototypes and then you've had like these like mini kind of fake prototypes and then this kind of like approach where you just like create a branch off broad. You know, one thing that I've seen over time and we also have like work in progress design channels where people post stuff and there have been a bunch of folks who I've kind of sat down with and chatted to and I think like, you know, they haven't coded before and then suddenly they're like sending these like links to like, you know, apps they built and I'm like, wow, like you know, how did you build that? Like, yeah, you know, started using codec and they kind of like transformed a bunch.

甚至最近，我团队里的一位设计师，一位非常出色的设计师，以前从来没真正写过代码。我们内部很多人用 Origami。我们有很多来自 Meta 的人。我记得走到他工位旁，他有一个原型。我说：“等等，那是什么？第一，那是原型吗？不知道你会写代码。第二，这简直就是真正的 ChatGPT。”他说：“我不知道发生了什么，也不知道怎么做到的，我只是让 Codex，比如在本地打开 ChatGPT，创建 Brad 来做一些编辑。”他说：“我不知道发生了什么，但就这样了，我有了这个了不起的原型。”所以变化巨大，我认为现在大多数人都在以这种新方式工作。

And even recently, a designer on my team, an amazing designer, never really coded before. A lot of people internally use Origami. We've got a lot of folks from Meta. I remember going up to his desk and he had this prototype. I was like, "Wait, what is that? A, is that a prototype? Didn't know you could code. B, this is like actual ChatGPT." And he was like, "I don't know what has happened or how, but I just asked Codex, like open ChatGPT locally, created Brad to make some edits." He's like, "I don't know what happened, but here we are and I have my amazing prototype." So it's dramatically changed and I think most people now are kind of working in this new way.

有一个问题我一直在问自己。如果公司主动申请和你交谈，而不是反过来，会怎样？这个问题正是全新 Dive Talent Network 的基础。而且它正在奏效。比如现在，我正在帮助许多我认识的最令人兴奋的初创公司，招聘收听这档节目的设计师和构建者。所以，如果你好奇外面有什么机会，如果你想加入我的名单，或者你正在寻找下一位设计人才，请访问 dive.club/talent 立即加入。

There's one question that I can't stop asking myself. What if companies applied to talk to you rather than the other way around? And that question is the foundation for the all-new Dive Talent Network. And it's working. Like right now, I'm helping many of the most exciting startups that I know to hire the designers and builders who listen to this show. So, if you're curious what might be out there and if you want to get on my list or maybe you're even looking for your next design hire, head to dive.club/talent to join today.

你谈到了 work in progress 频道。你能再深入讲讲吗，过去几个月你们在人们工作方式上经历了这种转变。这如何改变协作的样子？甚至想法被分享和聚集的方式。

You talked about the work in progress channel. Can you go a little bit deeper into, you know, this past few months you have this transition in the way that people are working. How is that changing what collaboration looks like? Even the way that like ideas are shared and rallied around.

是的，是的。好问题。我认为内部另一个重大突破是我们有一个叫 Sites 的功能。所以基本上，你可能会创建一个本地原型，然后你只要说，基本上就是聊天，给我一个链接，它就会部署到一个 URL，你可以决定谁可以访问，然后你就可以把那个链接分享给团队。也许你正在琢磨一个想法，你可以直接私信某人一个链接，他们就能实时把玩它。所以，work in progress 挑战肯定已经朝那个方向走了很多，我们有一些有趣的内部聚合器来展示这些不同的原型，这样你可以看到人们一直在捣鼓什么，对吧？也许你可以 fork 它们，然后自己开始引导它们。所以，我认为它已经变成了一个非常丰富的环境，有点像，你知道，链接而不是视频，像混音而不是从零开始。这非常酷。老实说，现在做设计师感觉太令人兴奋了。我认为这给了很多人一种新的生机，对吧？基本上拥有这种新的媒介，以前你可能觉得自己被锁在外面，而现在唯一的限制真的就是你的想象力了。

Yeah. Yeah. Good, good, good question. I think another big unlock that's happened internally as well is we have this feature called Sites. So you can basically, you know, you might create a local prototype and then you can just say, basically chat, give me a link, and it will deploy it to a URL and you can decide who can access it and then you can just share that link with your team. You know, maybe you'll be riffing on an idea and you can just DM someone a link and they can actually play with it live. So yeah, the work in progress challenge has definitely moved a lot in that direction and we have some fun internal aggregators for these different prototypes so you can see what people have been jamming on, right? Maybe you can fork them and start to channel them yourself. So yeah, I think it's become this very rich environment where it's kind of like, you know, links instead of videos, like remixing instead of starting from scratch. It's been very cool. It feels like honestly so exciting to be a designer right now. It's I think given a lot of people like a new lease of life, right? To basically have this new medium that previously you might have felt kind of locked out of and now the only limit is really your imagination at this point.

我完全同意，我觉得即使只是做 Web 应用和原生应用之间的区别，我认为也相当极端，做原生应用可能很麻烦，所以也许这就是为什么我问有多少那些原型处于第三阶段，因为即使只是，你知道，有快速粗糙的原型制作，利用这些新能力，然后还有，不，我真的是在 fork 被十亿人使用的 ChatGPT，并且原生地设计，我感兴趣的是你们怎么看待这种分裂，以及保持速度，但我也明白，当一切都不是确定性的时候，在 API 之上构建也非常重要，这种张力我认为是现在最值得深入探讨的事情之一。

I totally agree and I feel that I think the difference between working on even just web apps versus native apps is a little bit I think rather extreme like it's it can be cumbersome doing the native app thing like which is why maybe the the reason I was asking about like how many of those prototypes are in phase three is even just you know there's there's quick and dirty prototyping with these new capabilities and then there's like no I'm literally forking ChatGPT used by a billion people and designing natively and like I was interested like how you all even think about that split and maintaining speed but also I get that you have to like building on top of the APIs when everything is non-deterministic is really important too and that tension I think is one of the more interesting things to dig into right now

我认为这真的取决于你要解决的问题，对吧？所以举个例子，再用一个具体的例子，你知道当我们发布 work 时，我们也发布了一种改变模型和推理水平的新方式，我们引入了这个滑块。所以，再次提到我提到的这位设计师，Tar 和团队做了这个，你——我认为对于那个，非常小的交互和导航，关于它如何工作以及如何交互，是相当自包含的。所以对于那个，我们只是有一个原型，基本上是一种本地 React 原型。你在上面捣鼓，你弄清楚这个非常具体的交互，然后交给工程师。但假设你在做一个更大的 IA 变更或探索，首先你需要一些聊天记录库存。所以，如果你在做本地原型，你就必须创建那些。而且，你知道，我们使用的媒介是如此不确定，如果没有水流过管道，就很难推理，对吧？就像，有些想法在纸上听起来很棒，但当你实际发送一堆提示时，正如我所说，通过可视化，构建黄金评估，它在设计评审或原型中可能看起来很棒，但实际上当用户使用时，就完全不同了。所以，我认为我们设计的媒介的本质要求这样做。但对于一些小交互，就不需要，对吧？然后也许对于设计系统，你根本不需要原型，对吧？我认为很多工作仍然在 Figma 中发生。我认为它是我们工具包中非常重要的工具，但我仍然认为人们可以使用的工具范围正在扩大。

I think it really depends on the problem that you're solving as well, right? So for example, again just to use a concrete example, you know when we released work we also released a new way of changing model and reasoning level we introduced this slider. So again, this designer that I mentioned, you know, Tar and the team kind of worked on this and you— And I think for that, like the very small interactions and navigation around how that works and how it interacts are reasonably self-contained. So for that, like we just had a prototype that was basically like a kind of local React prototype. You jam on it, you work out this very specific interaction, then you hand it off to engineers. But say you're working on some bigger IA change or exploration, like first you need some inventory of chats. So, you know, if you were doing a local prototype, you'd have to create those. And, you know, the medium that we're working with is like so nondeterministic that without the kind of water flowing through the pipes, it's hard to reason about, right? Like, you know, some of these ideas like sound great on paper, but when you actually send a bunch of prompts, as I was saying, right, with the visualization, building like golden evals, it's like it can look great in a design review or in a prototype, but actually when users use it, it's completely different. So yeah, I think the nature of the medium of what we're designing with kind of necessitates that. But then for some of these small interactions, it's not required, right? You know, and then maybe like for design systems like you don't need prototypes at all, right? Like I think there's a lot of work still happens in Figma. I think it's like a really important tool in our toolkit, but still I just think like the scope of the tools that people have access to is expanding.

在你看来，什么样的工作仍然最适合用 Figma 来做？

What type of work is still best suited for Figma in your mind?

人们通常谈论的是探索与利用的权衡，对吧？比如在早期阶段，或者如果你考虑传统的设计流程，那种探索阶段，你想要广泛尝试，测试一堆东西，用非常低保真的方式，也许像线框图。这经常被用到。但我发现，是的，有那一面，但我也发现它对系统设计非常非常有用。比如说你在设计，我不知道，最近有人在搞的一个系统是评论功能。对，我们有很多不同的界面，人们可能会在上面评论。我们有浏览器，有幻灯片、文档，还有一些新东西，我们希望有一个系统能在所有这些界面上都运行良好。你希望在一个地方看到所有东西，你希望非常具体地处理像素，你希望把所有东西都规格化，这样交接给边缘团队时才能顺利，因为这不是那种你想匆忙完成的事情。你真的想把所有属性和像素都弄对，因为这是代码库中高度复杂的部分。Composer 是另一个好例子，或者像左侧边栏和侧边栏行这样的东西。你真的想非常具体地处理所有不同的边缘情况，确切的填充或排版尺寸。初始探索阶段和设计系统，但中间阶段也是如此。我认为很多人现在真的来回切换，特别是有了他们的一些 MCP。就像你可以把 Figma 快速放入代码，你也可以反过来，用这种方式规格化一堆不同版本的 Figma。所以我们肯定来回使用，仍然经常用它。

The types of things that people typically talk about is the kind of explore versus exploit, right? Like at the early point or if you're thinking about the traditional design process, the kind of exploratory phase, you want to go wide, you want to test out a bunch of stuff, you want to just do it in very low fidelity, maybe like wireframes. That's often used a lot. But I find, yeah, there's that side, but I also find it very very useful for systems as well. Say you were designing, I don't know, a system that someone was jamming on recently was like commenting. Right, we have a bunch of different surfaces that people might comment on. We have a browser, you have slides, documents, some new things, and we want to have this system that works well across them all. And you kind of want to see everything in one place, and you want to get really specific on the pixels, and you want to spec everything out so that handoff to edge goes well, because it's not maybe the kind of thing that you'd want to just rush. You want to really get all the props and pixels exactly right, because it's a high complexity part of the codebase. Composer is another good example of that, or maybe things like the left sidebar and sidebar rows. You really want to get very concrete about all the different edge cases, the exact padding or typography sizing. The initial exploratory phase and design systems, but in between as well. I think a lot of people really go back and forth now, particularly with some of the MCPs that they have. It's like you can take Figmas and put them into code real quick, you can also go the opposite way and spec out a bunch of different versions of Figma that way. So we definitely go in and out and still use it a lot.

我想多谈谈你们是如何运作的，我的问题是，你们有一个大约八人的团队，每个人都在快速制作原型，每个人都感觉自己作为构建者超级有力量。至少从我的角度来看，感觉有更多的想法在飞。因此，一些软技能变得更加重要，因为你不能构建所有东西，对吧？所以当你观察团队，甚至 OpenAI 内部的其他设计师时，你注意到那些对公司、产品战略产生巨大影响的设计师有哪些特质？

I want to talk a little bit more about how you all operate and I think my question is like you have this team of like eight people and everybody's slinging prototypes around and everybody's feeling super empowered as builders. And at least from my vantage point, it feels like we have way more ideas flying around. Therefore, some of the almost soft skills become even a little bit more important because you can't build everything, right? And so when you kind of look at the team and and maybe even other designers inside of OpenAI, like what are some of the traits that you notice in the designers that are having an outsized impact on the company, on product strategy, that kind of a thing?

好问题。我认为这也归结于一个核心问题，就像在很多关于原型的辩论中，人们使用的工具有点迷失了方向，没有跳出来思考设计是什么，设计的角色是什么，为什么它不同于前端工程，为什么它不同于产品。最终，你可以拥有世界上最引人注目的原型，但如果你不能说服任何人去构建它，那么它只会放在你的桌子上。所以，能够很好地沟通，能够用非常简单的方式表达你的想法，能够与实验室的工程合作伙伴、研究合作伙伴紧密合作，他们以完全不同的方式沟通，有完全不同的词汇和看待世界的方式。所以，要同情他们作为利益相关者用户，并以一种对他们有吸引力的方式传达你的想法，这不仅解决用户问题，还能让他们也参与进来。我目前的一个训练观点可能有点令人惊讶，因为我在做 Codeex 和编码产品，我真的不认为你需要会编码才能成为设计师。这归结于设计的角色是什么，对我来说，基本上是构建未来的愿景，然后带领人们前进。但有一位教授的一句话真的让我印象深刻，那就是你在描绘未来的愿景并带领人们前进。没有多少其他职能能做到这一点，要做到这一点，你需要沟通，你需要带领人们一起踏上这段旅程。所以，你知道，我们团队中一些最有效的人，比如有个人前几天开玩笑说，他基本上大部分时间都在 Slack 上争论，这是个玩笑，但真正意味着提出想法并带领人们前进，在人们有不同想法的线程中。这可能意味着你曾经分享过一个例子，比如想出一个原型并在上面涂鸦，对吧？只是为了展示一个想法并提出来。这可能和花一周时间在分支上构建一个完美的原型一样有效，归结为设计的角色是什么以及你如何能有效。我认为这并没有真正随时间改变，你可以利用工具，正如你所说，你也可以用它们来分散注意力，比如你可以制作一堆原型，但可能什么也没被构建，所以总是有取舍。

Good question. I think it also comes down to like a core quite like I think in a lot of this kind of debate around prototyping it's it's kind of gets lost in the source a little bit about like tools that people use and it doesn't zoom out and think about like what is design like what is the role of design um why is it different from from front end engineering why is it different from product and you know ultimately you can have the most compelling prototype in the world but if you can't convince anyone to build it then you know it'll just like sit on your desk so the ability to communicate really well the ability to express your ideas in very simple ways you know the ability to work closely with engineering partners at the labs like research partners who you know communicate in a whole different way have a whole different lexicon and different way of seeing the world. So empathizing with them as a as a stakeholder user and and and and you know communicating your idea in a way that's compelling to them that doesn't just solve a user problem but also you know brings them along in the journey as well. One of my training opinions at the moment which is maybe a little surprising given that I work on kind of codeex and coding product products is I really don't think that you need to be able to code to be a designer like it kind it comes down to like what is the role of design and for me it's basically about kind of like building a vision of the future and then bringing people along but yeah there's a kind of quote from one of my professors that really stuck with me which is you're painting a vision of the future and bringing people along. There aren't many other functions that do that and to do that you need to communicate you need to bring people along on that journey with you. So, you know, some of our most effective people on the team, like one person, uh, you know, joked me the other day that like he he basically spends most of his time arguing in Slack is the kind of joke, but you know, what that really means is putting forward ideas and bringing bring people along, you know, on threads where people have different different ideas. And that might mean you shared an example once of like coming up with a prototype and like scribbling on it, right? Just to kind of show an idea and putting it forward. that might be just as effective as you know spending whatever a week building this like perfect prototype off you know in a branch off off master or whatever boiling it down to kind of what is the role of design and and how can you be effective I don't think that's changed really over time and you can use tools you know to your advantage and to your point you know you can also use them um to get a bit distracted like you can just make a whole bunch of prototypes but maybe nothing gets built right so there are always trade-offs

假设你确实让人们对你用代码构建的原型感到兴奋，也许它只是从生产环境分出的一个分支。你能谈谈交接是如何改变的吗？比如，现在我们在代码库中制造混乱，而不是交出那些非常整洁和精致的 Figma 模型，与工程师的有效协作是什么样子的？

Let's say that you do get people excited about a prototype that you've built in code maybe it is something that is just a branch off of prod. Can you talk a little bit about how handoff has changed? Like what does effective collaboration with engineers look like now that we're making a mess in the codebase versus handing over these really neat and polished Figma mocks?

我的意思是，我认为它通常遵循一个过程，对吧？所以首先，也许你有一些功能的草图，可能来自产品经理，或者你有一些核心产品需求，你在玩弄它。所以首先你会勾勒出一堆这些想法，你知道，描绘一个愿景，或者如果是设计驱动的，也许有一些关于产品走向的核心论点，你可以构建那个愿景。

I mean, I think it typically follows a process, right? So, so first like maybe you have some, you know, sketch of feature um from some maybe it's a product manager, others you have some like core product requirement, you're kind of playing around with it. So first you're going to sketch out a bunch of these ideas, you know, paint a vision or if it's like design driven, maybe have some core thesis about where you want the product to go and you can kind of build that vision.

并不是说你直接把一个 8000 行的 PR 发给工程师，说“你上吧”。我觉得设计团队有责任更科学地对待这些事情。对吧？然后你迭代，如果需要的话在 Figma 里画出来。有些大的系统性问题，你得把它理清楚。但我觉得这几乎是一种号召，就像“这就是未来”，然后你就进入设计和协作的日常。有时候这意味着深入设计评审，迭代一个想法，在 Figma 里把东西规格化。或者可能差不多快好了，然后你坐在工程师伙伴旁边，与其减少你和 Figma 之间的延迟，不如直接坐下来结对，用那种方式调整东西。

It's not the case then that you just kind of send this, you know, 8,000-line PR to an engineer and say, you know, off you go. I think it's then beholden on design to get more scientific about things, maybe. Right? You then iterate, you then sketch it out in Figma if required. There are big systems problems you kind of get crisp on. But I think it's almost this rallying cry of like, here's the future, and then you just get into the bread and butter of just designing and collaboration. And sometimes that means just going really deep in maybe design review and iterating on an idea and speccing things out in Figma. Or maybe it's almost there, and then you're sitting next to an engineer partner, and instead of maybe reducing the latency between you and Figma, maybe you can just sit down with them and you can pair and you can tweak things in that way.

我最近经常思考的一件事是，我们仍然在考虑交接的方式，这有点拟物化。我们在代码中探索这些新的能力，但然后我们几乎试图把它改装回我们熟悉的人与人之间的交接。但未来，实际上你甚至不会太多考虑人的消费，我们会纯粹只是交接给我们的工程师智能体。

Something I'm thinking about a lot recently is that the way we're still thinking about handoff is slightly skeuomorphic, in that we have these new sets of capabilities we're exploring in code, but then we almost try to retrofit it back into what we're familiar with in terms of human-to-human handoff. But in the future, actually you won't even really think about the person's consumption that much, and we'll purely just be handing off to our engineer's agent.

有一个世界我们会到达那里，是的，我们可能在未来 6 到 12 个月内到达。但我确实认为，目前，这些决策中总是有人在环。无论是有人与智能体一起，人类验证它，在这种情况下，你有不同的职能，有几个不同的人在环。这归结为不同的职能和不同的角色是什么。我们认为设计、前端、更广泛的工程之间有一些功能差异吗？我认为有。在那个世界里，我认为至少在短期内，我们会拥有这个我们已经拥有很长时间的三重奏，即产品经理、产品设计师、工程师，每个人都带着非常不同的视角来解决同一个问题。也许我会与工程师的智能体或产品猎人的智能体沟通，但仍然有人在环中做出这些决策，把那种框架应用到你所构建的东西上。

There is a world in which we get there, and yeah, we may be there in 6 to 12 months. I do think though, for now, there's always a human in the loop in these decisions. Whether it's one person with agents and the humans verifying it, where in this case you have different functions, and there are a few different humans in the loop. It kind of comes down to what are the different functions and what are the different roles. Do we think there's some functional difference between design, front end, engineering more broadly? I think there is. And in that world, I think at least in the short term, we'll have this kind of trio that we've had for a long time, which is product manager, product designer, engineer, each come with a very different lens to problem solving the same problem. And maybe I'll be communicating with the engineer's agent or the product hunter's agent, but still there's a human in the loop there making those decisions, bringing that kind of framework to bear on the things that you're building.

你还有其他哲学，甚至影响你作为团队领导者的表现方式吗？

Are there other philosophies that you hold that impact even just the way that you show up as a leader for the team?

我不一定热衷于商业框架，但我确实认为我真正关心的事情：文化和价值观，特别是考虑到我有幸在前沿实验室工作的产品类型，对吧？我们的产品可能触及数十亿人。它们把我认为最神奇的技术带给世界，能够解决各种不可思议的问题，推动科学进步。所以我对能从事这项工作感到真正的谦卑，我试图招聘和建立也有这种感觉的团队。所以这对我来说非常重要。再次，它归结为痴迷于花时间与用户相处，理解我们做出的决策如何影响那些用户，但也只是对我们前进方向的谦卑。我们可以在内部通过我们测试的工具和模型看到这一点。所以试图建立那种以及一些其他可能更基于价值观的东西，我真正相信的是高信任、高自主性的团队，它们几乎不能没有彼此。所以为了高自主性并做我描述的事情，比如产品设计师可能带来完整功能，并感到有能力这样做，你只有建立了信任才能做到。实际上，这只是意味着与内部这些决策的关键人物非常亲近，这通常是研究，但也包括工程。它又回到了谦卑的部分，比如成为一个真正伟大的跨职能合作伙伴。一旦你与人们建立了信任，并信任自己的技能、直觉和对未来的愿景，并且这与其他人以及使命一致，那么你就可以非常高的自主性，也许推动一些更大的想法。所以是的，少一些框架，可能更多基于价值观。

I'm not big on business frameworks necessarily, but I do think things that I really really care about: culture and values, particularly given the kinds of products that I'm lucky enough to work on at a frontier lab, right? Our products reach potentially billions of people. They're bringing what I find to be just the most magical technology to the world and being able to solve all sorts of incredible problems and push forward scientific progress. So I feel a real humility in getting to work on this, and I try to hire and build teams that also feel that. So that's something that's really important to me. Again, it comes down to being obsessed with spending time with users and understanding how the decisions that we take impact those users, but also just a humility about where we're going. We get to see a snapshot of that internally with the tools and models that we test. So trying to build that and a few other maybe more values-based things that I really believe in is high trust, high agency teams, and they kind of can't really go without each other. So in order to be high agency and do the things that I describe, which is like product designers maybe bringing full features to bear and feeling empowered that they can do that, you can only do that if you've built trust. Practically that just means being really close with the people who are key to these decisions internally, which is often research but also engineering. And it kind of comes back to the humility part, like being a really great cross-functional partner. And once you build trust with folks and trust in your own skills and instincts and vision of the future and that's aligned with other people and the mission, then you can be really high agency and maybe push forward some of these bigger ideas. So yeah, less frameworks and probably more values-based.

在评估设计师并考虑他们是否适合团队时，你是否有具体的方法来筛选谦卑？

Are there specific ways that you screen for humility when you're assessing a designer and considering whether or not they'd be a good fit for the team?

我肯定会问很多关于使命的问题。对吧。所以你知道，我认为很多设计师是从设计进入 AI 领域的。我可能有点反向的过程，我早期职业生涯从事 AI 政策，然后去研究生院学习机器学习和设计，从事机器人技术，然后从事一系列非常研究导向的产品和项目，包括构建我们的一些评估，用于 40 和其他。所以从那个方向来，也从事过一些更具公共目的的项目，我只是问很多关于使命的问题，比如你为什么在这里工作，为什么在其他地方工作，为什么你想从事 AI，是因为它是热门的东西，还是你真的关心技术如何影响人们，特别是我们的使命，即构建造福全人类的 AGI。所以主要是我们的使命，以及人们呈现工作的方式，协作呈现，降低自我，与跨职能合作伙伴很好地合作，你通常能感觉到。但我认为深入价值观是一个很好的方法。

I definitely ask about mission a lot. Right. So you know I think a lot of designers have kind of come into the AI space from design. I had a bit of a backwards process maybe I came in from AI in a way like my early career worked on AI policy and then went to grad school kind of studied ML and design worked on robotics and then worked on a bunch of very like research focused products and projects including building some of our evals that were used for 40 and others. So having come from that direction and also having worked maybe on like projects that have more of a like public purpose I just ask a lot of questions about mission like why you know why do you work here why do you work here other places like why do you want to work on AI you know is it cuz it's you know the hot thing or like do do you actually care about the technology how it impacts people and specifically our mission you know which is to kind of build AGI that benefits all of humanity so it's mainly our mission and just you know the way the folks present work presenting it collaboratively kind of lower ego working really well with cross functional partners you can kind of you can often get it. But I think like digging in around values is a really good way to do that.

你多次提到研究以及它在 OpenAI 作为设计师的表现中所扮演的角色。我想知道我们是否可以深入探讨一下，因为很多听众没有机会在前沿实验室工作，也许它更像一个黑箱，包括我自己。比如你如何有效地与研究合作？那个部门在想法如何形成以及设计如何融入方面扮演什么角色？你能谈谈这一部分吗？

You've mentioned research and the role that that plays in like showing up as a designer at OpenAI a few different times. And I'm wondering if there's more we could dig into there because a lot of people listening don't get to work at a frontier lab and maybe it's a little bit more of a black box myself included. Like how do you effectively collaborate with research? What's the role that that part of the org plays in terms of how ideas are shaped and where design fits in? So can you talk a little bit about that piece?

是的，所以很有趣，OpenAI 是一种非常草根、自下而上的文化。所以不一定有流程或剧本。

Yeah, so it's interesting like OpenAI is a very kind of grassroots kind of bottoms up culture. So there aren't necessarily like kind of processes or a playbook.

归根结底是人际关系和工作伙伴关系。Codex 之所以如此成功，尤其是在早期，原因之一就是团队非常小，而且产品团队与研究团队合作得非常非常紧密。物理上，我就坐在训练模型的研究人员对面，如果我对某种行为或能力有疑问，想基于它构建一些东西，我就直接问他们。部分原因是我已经开放两年了，刚加入时我在研究团队工作，构建了一系列用于训练模型的界面，所以大部分时间我都在研究区走动。

It comes down to relationships and working partnerships. One of the reasons why Codex was so successful, particularly in the early days, was a very small team, and product working very, very closely with research. Physically, I would sit across from the researchers training the models, and if I had a question about a certain behavior or capability I was interested in building something with, I would just literally ask them. Part of it is that I've also been open for two years, and when I first joined, I worked on the research team building a bunch of interfaces to train our models, so I spent most of my time within the research walk.

很大一部分就是人际关系和伙伴关系。这在实践中意味着，如果你和人们聊天，你会发现他们以不同的方式看待世界，他们有特定的框架和某些信念或假设。

A big part of it is just relationships and partnerships. What that actually means in practice is that if you chat with folks, you see that people approach the world in a different way, and they have a certain framework and certain beliefs or assumptions that they hold.

换个角度问这个问题就是：设计师如何与研究合作，或者我怎样才能做得更多？这有点像肯尼迪的那句话：不要问你的国家能为你做什么。我认为设计师也有责任，如果你对这个领域感兴趣，就要投身其中。在我们组织内部，有讲座你可以去听。如果你想，你可以阅读这些机器学习研究背后的教科书，或者听播客。如果人们不太技术，你可以提升自己的知识。坦率地说，我认为设计和产品也有责任跟上最新的思考。

Another way of framing this question is: how do designers work with research, or how can I maybe do more? It's kind of like the JFK quote: ask not what your country can do for you. I think it's beholden on designers as well, if you're interested in this area, to throw yourself into it. Within our org, we have talks that you can go to. If you want, you can read up on the textbooks that are behind a bunch of this ML research, or you can listen to podcasts. If people are less technical, you can bring up your knowledge. I think it's also beholden on design and product, frankly, to get up to speed on the latest thinking.

在内部做这件事很容易。在外部，你可以通过大量公开记录来做。然后从那里开始，你可以建立一些直觉，了解我们可能走向何方，人们特别感兴趣的是什么。然后如果你想象那个世界并勾勒出来，思考：好吧，我正在构建的产品在那个世界中会是什么形状，或者你可以构建哪些新产品来真正展示我们可能走向何方的能力。

It's very easy to do that internally. Externally, you can do it via a lot of public records. And then from there, you can start to build some intuition about where we might be going, what are the particular things that people are interested in. Then if you just imagine that world and sketch it out and think, okay, what is the shape of the product that I'm building that would work in that world, or what are new products that you can build to really showcase the capabilities of where we might be going.

我知道你有一个小团队，你之前也谈过希望保持这个规模，保持灵活、高自主性和主人翁精神等等。但假设有人在听，他们被你说的一切所启发，他们认为自己有能力在这种环境中茁壮成长。他们想让自己出现在你面前。所以，你提到了谦逊这一点，但今天你在设计师身上还会看重什么？他们可以提出哪些信号，让你觉得‘好吧，是的，我绝对应该考虑那个人担任某个角色。’

I know you have a small team and you've talked before about wanting to maintain that size and being nimble and high agency and ownership and all that. But let's say somebody's listening and they're inspired by everything that you're saying and they think that they have what it takes to thrive in this environment. They want to get themselves in front of you. So, you mentioned the humility piece, but what else would you be looking for in a designer today? And what are some of the signals that they could put forward to get you to the point where you're like, 'All right, yeah, I should definitely consider that person for a role.'

是的，首先，人们应该随时联系我。我总是很乐意聊天。我一直非常非常感兴趣听到对这个领域感兴趣的人的消息，特别是那些对研究有真正兴趣或背景，但也做过设计的人。我觉得那个领域的人不多，我总是很好奇想认识这样的人。

Yeah, I mean, first off, people should feel free to reach out to me at any point. Always happy to chat. I'm always really, really interested in hearing from folks interested in the space, particularly people who have a real interest or background in research but have also worked in design. I feel like there aren't that many folks in that space, and I'm always really curious to meet folks like that.

但是的，当我看候选人或者作品集时，我觉得尤其是现在，我和专业经验一样感兴趣的一件事是：你周末在做什么？现在是一个如此令人兴奋的构建时代。即使现在，我晚上或周末真的没有太多时间，但当我能的时候，我仍然在做原型。我真的在寻找那种能量，那些对这个新的构建时代感到非常兴奋，几乎无法控制自己，在业余时间构建东西的人。

But yeah, when I'm looking at candidates or portfolios, I think particularly now, one thing I'm just as interested in as professional experience is: what are you doing on the weekends? It's such an exciting time to build. Even now, I don't really have much time on evenings or weekends, but when I can, I'm still prototyping. I really look for that energy, people who are just really excited about this new era of building and almost can't control themselves and are building stuff in their spare time.

所以我认为对于职业生涯早期的设计师来说，这是一个非常艰难的时期。也许你还没有在公司或其他地方参与过那么多项目，但你仍然可以在业余时间做一些事情并传达出来。也许有开源项目你可以参与，或者你可以在 Twitter 等网上发布作品，试图提升知名度。

So I think it's a really tough time for designers early in their career. Maybe you haven't worked on as many projects at a company or elsewhere, but you can still work on things in your spare time and communicate that. Maybe there are open source projects you can work on, or you can publish work online on Twitter or whatever to try to raise a profile.

然后是的，我认为我可能最看重的有两种人。一种是经典的设计师独角兽类型：经验丰富、高自主性、真正以产品为中心，并且方法谦逊。你可以基本上信任他们去构建惊人的东西，你不需要太参与日常事务。这些人通常确实有一点经验。

And then yeah, I think there are two profiles that I probably look for the most. One is just the classic designer unicorn trope: super experienced, high agency, really product focused, and humble in their approach. Folks that you can basically trust to go off and build amazing things, and you don't really need to be super involved in the day-to-day. Those folks often do have a little bit of experience.

然后我对职业生涯初期的人非常感兴趣。我认为那些特别成长起来并且是这个世界原生的人。很多设计师基本上经历了这个过程：他们以某种方式工作了 10、15 年或更久，现在他们正在发现这种新的工作方式。而也有全新一代的设计师，这对他们来说是常态，我认为他们在某些方面以非常不同的方式工作。也许他们不受过去设计师工作方式的限制。

And then I'm really interested in people at the beginning of their career. I think people who particularly have grown up and are kind of native to this new world. A lot of designers have basically been through this process where they've worked a certain way for like 10, 15 years or longer, and now they're discovering this new way of working. Whereas there are a whole new generation of designers as well who this is the norm, and I think work in a very different way in some ways. Maybe they aren't constrained by some of the ways that designers worked in the past.

所以我也非常兴奋能与职业生涯更年轻的人合作。我们在那个领域雇佣的一些人，是我合作过的最优秀的人，真的非常有活力，真的以原型为先，并且真正理解技术，我认为很多人做不到。

So I'm also really excited to work with folks younger in their career. Some of the people that we've hired in that space, some of the best people I've ever worked with, just really high energy, really prototyping first, and really get the technology in a way that I think a lot of folks don't.

除了以原型为先之外，你认为还有哪些行为主要存在于职业生涯更年轻、天生适应这种工作方式的设计师身上？比如，那在你看来是什么样子的？

Are there behaviors outside of prototyping first that you think exist mostly in designers who are younger in their career and native to this way of working? Like, what does that even look like to you?

也许你不太会被通过不同工作或生活中积累的所有东西所拖累。我认为这种真正无拘无束的雄心非常有趣。不太看到或理解可能性的极限，我认为这是一个非常令人兴奋的特点。但我也确实认为，很多这些价值观并不特定于初级设计师或年长设计师。

Maybe you're less bogged down by all the things that you accumulate over time through different jobs or just in life. I think just this real unbounded ambition is really interesting. Not really seeing or understanding the limits of what's possible, I think, is a really exciting profile. But I do also think that a lot of these values are not specific to junior designers or older designers.

还是像我说的那样，就是那种低自我、高信任、高主动性的人，你知道，也许你职业生涯还比较早期，经验还比较少，但你能清楚地看到一条非常强的成长轨迹。

Again, it's as I talked about, it's these kind of low ego, high trust, high agency folks who, you know, maybe you're earlier in your career and you have less experience, but you can clearly see a very strong trajectory.

是啊，这说得通。我觉得哪怕就我自己的实践来说，我常常会惊讶于某件事居然能成，那是因为我戴着这样一副眼镜，脑子里装着一些约束条件——比如我做不到这个，你知道，这不可能或者不可行。而现在成长起来的这些人，他们真的觉得自己在电脑上什么都能做，没有任何东西拦得住他们。

Yeah, it makes sense. I think even for my own practice, often I'll be surprised that something works, and it's because I have this lens that I wear of an understanding of some of the constraints — like I can't do that, you know, that's not going to be possible or feasible. Whereas the people that are coming up now literally think that they could do everything on their computer and there's nothing stopping them, you know.

老实说，他们是对的。对使用 Codex 这类工具的人来说，最大的障碍之一就是这种限制性想法——哦，它做不了那个。但每一次，至少我自己逼一逼自己，你知道，它真的会拓展可能性的边界。你知道，我见过设计师提交后端代码，还有各种几年前根本无法想象的事情。

And honestly, they're right. One of the biggest barriers for folks using tools like Codex is this limiting factor of like, oh, it can't do that. But every time, at least I've kind of pushed myself, you know, it really expands the scope of what is possible. You know, I've seen designers commit backend code and all sorts of stuff that would just be unimaginable a few years ago.

不，Ed，这次聊得太棒了。感谢你今天来做客，分享了一些原型背后的故事，还聊了你们是怎么工作的。你们在很多方面都在为行业里的很多人树立标杆。所以真的很感谢你抽出时间，今天和我们分享这些。

No, Ed, this has been awesome. I appreciate you coming on today and sharing a little behind the scenes of some of the prototypes and talking about how you all work. You guys are kind of setting the bar for a lot of the industry in so many ways. So really appreciate you taking the time and sharing with us today.