火箭飞船上的设计：Lovable 的第一位设计师

欢迎来到 Dive Club，我是 Rid，这里是设计师永不停歇学习的地方。本周的嘉宾是 Nad Chishtie，他是 Lovable 的第一位设计师。Lovable 是欧洲历史上增长最快的初创公司，也很快成为我最喜欢的用代码探索想法的方式。所以我们将深入幕后，看看在火箭船初创公司做设计是什么感觉，以及像 Lovable 这样的工具如何帮助设计师成为构建者并影响实践的未来。但我也想从了解 Nad 在 Lovable 旅程的开端开始这期节目，因为他为那些有兴趣成为创始设计师的人分享了一些非常棒的建议。

Welcome to Dive Club. My name is Rid, and this is where designers never stop learning. This week's episode is with Nad Chishtie, who's the first designer at Lovable, which is the fastest growing startup in European history and has pretty quickly become my favorite way to explore ideas in code. So we're going to get a little behind the scenes and see what it's like designing at a rocket ship startup and all of the ways that tools like Lovable can help designers become builders and impact the future of the practice. But I also want to start this episode by learning more about the beginning of Nad's Lovable journey because he shares some really great advice for people who are interested in becoming founding designers.

我基本上是在业余时间把玩 LLM，更像是一种爱好。我感染了好奇心，我想和世界上其他人对 ChatGPT 的好奇一样。但我超级好奇我能在设计中使用它们做什么。当时，我在一家做安全消息的成长型公司工作，我们在公共领域有非常好的吸引力。我们必须做很多关于可访问性、对比度以及满足不同平台和环境的不同可访问性标准的设计工作。这一切都很有回报，但对团队来说有点辛苦。所以我开始用 LLM 构建这些小工具，比如我可以给它们一个强调色，然后用计算机视觉模型从品牌色创建 Tailwind 色阶，然后交叉检查这些不同颜色组合工作时的对比度。我完全被这个 bug 感染了：哇，这感觉就像是未来会是什么样子，而不是我们必须手动做所有事情。所以我开始尝试，这让我找到了一个名为 GPT Engineer 的开源项目，这是我们的创始人之一 Anton 做的项目。他基本上出于同样的原因开始尝试 LLM，但完全是在瑞典并行进行的。他是一家 YC 初创公司的 CTO，非常喜欢他正在做的事情，但他很沮丧，因为他认为他所有的工程同行对 LLM 都太缺乏想象力了。他能看到未来 5 到 10 年，认为世界上大部分代码将由 LLM 编写，而人们会对他说不，告诉他他错了。所以他非常沮丧，做了一个概念验证，叫做 GPT Engineer，基本上是一个命令行工具，你让 AI 构建一些东西。如果它不知道你的意思，它会反问一个问题；否则，它就直接为你构建。他构建了那个，它成为了 GitHub 上最大、最流行的代码生成项目之一，从零到 52,000 颗星。我找到了那个项目，开始玩它，然后联系了 Anton，开始做一些咨询工作，比如一些合同工作，从零设计到一些设计。但后来我飞过去亲自见了团队，从那时起，我基本上决定全力以赴。

I was basically hacking around with LLMs in my spare time as more of a hobby. I kind of got infected with the curiosity, I guess the same as the rest of the world did with ChatGPT. But I was super curious about what I could use them for in design. At the time, I was working at a scale-up that was working on secure messaging, and we had really good traction in the public sector. We had to do all this design work around things like accessibility, contrast ratios, and meeting different accessibility standards for different platforms and environments. It was all quite rewarding but a little bit grueling for the team. So I started building these little utilities using LLMs where I could do things like give an accent color to them and then use computer vision models to create a Tailwind color scale from a brand color, then do a cross-check of the contrast ratios when these different color combos are working. I got completely bitten by this bug of: wow, this actually feels like what the future is going to be like, rather than us having to manually do everything ourselves. So I started experimenting with that, and that led me to an open source project called GPT Engineer, which was a project made by Anton, one of our founders. He had basically started experimenting with LLMs for the same reason but completely in parallel over in Sweden. He was a CTO of a YC startup, really loved what he was doing, but he got quite frustrated because he thought all of his engineering peers were being too unimaginative with LLMs. He could see 5 to 10 years into the future and think most code in the world is going to be written by LLMs, and people would say no to him and tell him he was wrong. So he got really frustrated and put together a proof of concept called GPT Engineer, which was basically a command line tool where you ask the AI to build something. If it doesn't know what you mean, it asks you a question back; otherwise, it just builds for you. He built that, and it became one of the largest, most popular code gen projects on GitHub, going from zero to 52,000 stars. I found that project, started playing around with it, then reached out to Anton, did some advisory stuff to begin with, like a bit of contracting and moving from zero design to some design. But then I flew over to meet the team in person, and since then, I basically decided to go all in.

快速了解一下：作为设计师，你有多强的技术背景？

Just quick context: how much of a technical background do you have as a designer?

我永远不会称自己为工程师，但我一直认为真正理解我的材料几乎是一种职业责任。所以我总是拼凑前端，努力做到足够技术化，以便能够与我密切合作的人进行高频、高带宽的对话。我可以在技术架构等方面深入，但总是以与设计相关的方式。所以我会说在抽象上是工程思维的，而且我能和工程师沟通得很好。

I would never call myself an engineer, but I've always seen it as almost a professional responsibility to really understand my materials. So I've always hacked together front end and strived to be technical enough that I can have a high-frequency, high-bandwidth conversation with the people I'm working closely with. I can go quite deep on things like technical architecture, but always in a way that relates back to design. So I would say engineering-minded in the abstract, and I can communicate very well with engineers.

这很酷，因为你是那种能从 Lovable 这样的产品中获得超能力的人，而且你能创造那个未来。所以我想现在应该很有成就感。

It's cool because you're the perfect type of person that then gets superpowers from a product like Lovable, and you get to create that future. So I would imagine it's quite fulfilling right now.

100%。我对自己的形态、技能组合以及这一切的发展方向感到非常幸运。但我也认为这在某种意义上是一种修正。作为设计师，我们知道形式追随功能，它们彼此一样重要，但我觉得在数字设计世界中，我们只是痴迷于形式。所以现在，至少有了 AI，我们可以再次拓宽，塑造双方，并且更加跨领域和跨职能。

100%. I feel very fortunate with my shape and skill set and where all of this is going. But I also think it's a bit of a correction in some sense. As designers, we know that form follows function and that they're as important as each other, but I feel like in the digital design world, we just obsess over form. So now, at least with AI, we can widen back again and shape both sides and also be way more cross-domain and way more cross-function.

就像人们可以做他们以前从未做过的事情。他们在做他们以前甚至无法想象的事情。它是欧洲历史上增长最快的初创公司。作为灵魂设计师，那是什么感觉？我们思考问题的方式以及我工作的方式，是我试图在个人速度和团队速度上都挑战自己。所以对我来说，这意味着作为设计师，我是一个赋能者。你正处于这个前所未有的小公司集合中，你不是唯一的年轻火箭船。一切都在飞速发展。所有人的目光都集中在这套产品上。我们基本上先构建了这个设计工具版本，经历了一次存在主义崩溃，删掉了一半，然后发布了这个更简单的版本。最终目标将是拥有一个像成熟设计工具一样精细的像素级控制的东西。我不太确定的是：它的形态会是我们所知道的设计工具吗？我认为有机会将我们习惯的很多东西宣布为遗留物。但这很上瘾，你知道吗？尝试解决下一个问题，然后下一个，再下一个，这很有趣。现在我通常会在 Figma 中设计第一个状态，然后转到 Lovable，从那里制作一个交互式原型。我会和 AI 一起即兴创作，制作实时原型。

Like people can do things that they never could do before. They're doing things that they could never even imagine before. It's the fastest growing startup in European history. What the heck is that like as the soul designer? The way that we think about things and the way that I kind of work is I'm trying to challenge myself across both individual velocity but also team velocity. So for me, what that means is as a designer, I'm an enabler. You're just in this unprecedented little collection of companies where you're not the only young rocket ship. Everything's moving so fast. All eyes are on this suite of products. We basically built this sort of design tool version first, had an existential breakdown, deleted half of it, and then shipped this kind of simpler version afterwards. The eventual goal will be to have something where you have as fine-grained pixel-level control as you can get from a fully-fledged design tool. Where I'm less certain is: will the shape be design tools as we know it? I think there's an opportunity to declare a lot of what we've got used to as legacy. But it's addicting, you know? It's just fun to try to solve the next problem and then the next problem and the next problem. Now I just generally will design maybe the first state in Figma and then punch out to Lovable and just make an interactive from there. I'll kind of jam with the AI to work through live prototypes.

比你想象的要简单得多，而且我现在在设计上获得的乐趣比过去很长一段时间都要多。所以请前往 dive.club/lovable 开始构建吧。那是 l o v a b l e。作为一名设计师，我经常与人交流：团队会议、设计评审、用户访谈。所以捕捉我得到的想法和反馈非常重要。这就是为什么我从来从来从来从来从来不会在讨论设计时不运行 Granola 在后台。它就像 Apple Notes，但能为我转录会议。所以当会议结束时，Granola 会增强我写下的笔记，我甚至可以提问或从通话中获得定制的摘要。它很快就成了我设计实践中的必备工具。每个设计师都应该使用它。如果你想访问秘密链接 dive.club/granola，那么你和你的团队可以获得三个月的免费使用。那是 dive.club/granola。好了，现在进入正题。

Way easier than you think and I'm having more fun designing right now than I have in a long time. So head to dive.club/lovable to start building today. That's l o v a b l e. As a designer, I'm always talking to people: team meetings, design crits, user interviews. So it's super important to capture the ideas and feedback that I'm getting. And that's why I never ever ever ever ever have a conversation about design without running Granola in the background. It's like Apple Notes but it transcribes my meetings for me. So when the meeting ends, Granola enhances the notes I've written, and I can even ask questions or get tailored summaries from the call. It's very quickly become a staple tool in my design practice. Every single designer should be using this. And if you want to go to the secret link dive.club/granola, then you and your team can get three months free. That's dive.club/granola. Okay, now on to the episode.

好了，现在我们来聊聊 Lovable。大约 10 个工程师，每天都有新的 AI 进展，它是欧洲历史上增长最快的初创公司。作为唯一的设计师，那到底是什么感觉？

Okay, so let's talk about Lovable now. So roughly 10 engineers, every day there's a new AI advancement, it's the fastest growing startup in European history. What the heck is that like as the sole designer?

真的很有趣，我想。首先，肯定有压力大的时刻，或者你知道，有些时候感觉喘不过气来，但总体上是给予能量而不是消耗能量。我认为这是最重要的事情，因为如果不是这样，其他一切都会更困难。但内部节奏非常快。在文化上，我们非常非常重视最大化学习，高于一切。我们思考问题的方式以及我工作的方式，是试图在个人速度和团队速度上都挑战自己。所以对我来说，这意味着作为一名设计师，我是一个赋能者。我看待事物的方式是，设计决策每时每刻都在发生。每个团队中的每个人都在做出决策，这些决策最终会以某种方式影响用户。我的工作是促成更高质量的决策，而不是自己做出所有决策，然后像瀑布一样把它们推给团队。

Really fun, I guess. Like, first of all, there's definitely stressful moments or like, you know, moments of being underwater, but overall energy giving rather than energy taking. And like, that's I think that's the most important thing, because if that wasn't the case, everything else would be more difficult. But super high paced internally. We, culturally, put a very very high emphasis on maximizing learning above everything else. The way that we think about things and the way that I kind of work is I'm trying to challenge myself across both individual velocity but also team velocity. And so for me, what that means is as a designer, I'm an enabler. The way that I see things is that design decisions are happening all of the time. Like everyone in every single team everywhere is making decisions that in some way will resolve into user impact at the end of the day. My job is to enable kind of higher quality decisions across the board, rather than making all those decisions myself and then waterfalling them onto the team.

这在实践中意味着什么？

What does that mean in practice?

这在实践中意味着，对我们来说，很多工程师都在尽可能端到端地负责事情。我基本上是在引导他们。这与其说是“这是 Figma 画布上抽象的完美设计，然后我们去实现它”，不如说是“好吧，我们首先对齐要解决什么问题”。工程师在如何解决这些问题上有很大的自由度，然后我们在这个过程中逐步提升最佳用户体验。这很合理：当你以这个行业和公司阶段所需的速度运作时，你基本上是在消除自己作为瓶颈的角色。即使在我待过更大的团队时，我也发现这是一种健康的运作模式，因为首先，不幸的是，设计师并不总是拥有最好的想法。你知道，最棒的东西往往来自协作，也来自最意想不到的地方。所以我一直非常努力地避免这种瀑布式的感觉，或者认为事情要么被设计了，要么没被设计，而现实是，如果人们可以更新产品，那么它总是被某人在设计。

What that means in practice is, for us, a lot of the engineers are carrying things end to end, as much as possible. I'm basically kind of guiding them. It's less so much about 'here's the perfect design that will exist in the abstract on a Figma canvas and then we go and create it', and more so about 'okay, let's align first of all on what problems we're going to solve'. The engineers have a lot of latitude on you know how to solve those, and then we tier up on the best user experience along the way. And it makes sense: you're basically removing yourself as a bottleneck when you're operating at a level of velocity that is required in this type of industry at this stage of the company. Even when I've been in larger teams, I've found this to be a healthy mode of operation as well, because I mean, first of all, it's not that designers have the best ideas, unfortunately. Like, you know, the very very best things happen from you know from collaborating and also come from the most unexpected places. And so I've always tried really hard to avoid this sort of feeling of waterfall, or that things are either designed or they're not designed, when the reality is that if people can update the products, it's always getting designed by someone.

我敢肯定现在有人在听，会说：“好吧，当理论上工程师可以端到端地负责较小的事情时，你如何确保产品达到合适的质量水平？所有东西都在同时成型。”尤其是作为第一位设计师，我不知道你是否经历过这个，我有时会害怕把达不到我标准的东西推上线，因为我知道它永远不会被优先处理，就像一切都在快速推进，那个东西可能会在产品路线图增长的过程中被固化一整年。

I'm sure there's somebody listening right now that's like, 'Well, how do you ensure the right level of quality in the product when engineering, in theory, could take smaller things end to end? Everything's kind of being shaped all at once.' And especially as the first designer, I don't know if you've ever experienced this, I've sometimes felt this fear of pushing something to prod that isn't up to my bar, because I know like it's never going to get prioritized, like you're everything's moving too quickly, where that thing might be cemented for a full year as the product roadmap grows.

我几乎把这看作是一种赤字。所以我把质量视为债务。我从不认为质量是需要达到的某个标准；它更像是一种赤字，或者一种可以上下波动的感觉。当然，有些功能上线时我们是负债的，所以我们需要在未来偿还这笔债务。但没错，我认为这是一种活的东西，我们创造债务，然后偿还，这是一个不断循环的过程。这也意味着我们可以在内部将这些对话转化为技术债务之类的东西，然后很容易就能倡导在偿还技术债务的同时偿还一些设计债务。

I think about this as almost like a deficit. And so I think about quality as debt. I'm never thinking about quality being this bar that needs to be met; it's more so this almost this deficit or this feeling that can go up and down. For sure, there's features that go out where we're in debt, and so we need to pay off that debt in future. But yeah, I see there's this sort of living thing where we create debt and we pay it off, and it's just this constant moving cycle. It also means that we can translate those conversations internally to things like technical debt, and it becomes very very easy to then advocate for paying off some of this design debt alongside technical debt.

你已经多次担任创始设计师的角色了。所以在我们深入探讨你在 Lovable 的工作方式之前，我想稍微保持在高层次，借鉴你作为多次经历这种情况的人的观点。至少对我来说，每次我作为第一位设计师从空白画布开始时，这就像是一个机会，可以把我学到的一切、所有过去的经验，用来找出我想要调整的正确事情，或者我想要做得不同的方式。我很好奇这是否引起了你的共鸣，以及你作为 Lovable 的设计师是否有某些方式在利用这张白纸。

You've done the founding designer role multiple times now. So before we get into the weeds of how you work at Lovable, I kind of want to stay a little bit higher level and tap into your perspective as someone who has been in this situation multiple times. And at least for me, every time I start with kind of the blank canvas as the first designer, it's like this opportunity to take everything that I've learned, all my past experiences, and figure out the right things that I want to tweak or the ways that I want to do differently. And I'm curious if that resonates and if there are certain ways that you're taking advantage of this blank slate as a designer at Lovable.

我真的很喜欢和创始人一起工作。创始人很棒，因为我认为从某样东西从未存在或根本不存在，到“好吧，这真的会在世界上存在”，需要很大的信念。作为第一位设计师，我认为你处于创始人和市场的交汇点。所以你在做的是试图挖掘这种原始的雄心、原始的信念，并让它对其他人来说变得可理解。应该存在一种健康的推拉：有些东西之所以存在，是因为它符合团队或个人的原始愿景，而另一些东西则完全由市场引导，更像是“哦，我们在这方面完全错了，但这里有所有这些其他令人惊讶的奇妙事物”。我认为我反复觉得有趣的是坐在这两者之间，并在它们之间保持健康的推拉。

I really love working with founders. And so founders are great because I think it takes a lot of conviction to sort of go from something just never existing or not existing at all to like 'okay, this is actually going to exist out in the world'. And as a first designer, I think you sit in this intersection of founders and the market. And so what you're doing is you're sort of trying to tap into this raw ambition, raw conviction, and kind of make it understandable for everyone else. And there should be this sort of healthy push-pull of, you know, there's things that just exist because that was in the original vision of the team or individual people or whatever, and there's other things where you get completely led by the market, and it's more so about 'oh, we were completely wrong about this, but here's all these other amazing things that take you by surprise'. I think what I find repeatedly interesting is sitting between these two and having this healthy push-pull between them.

对于有兴趣在初创公司做设计的人，你有什么建议可以让他们借鉴或利用你的一些经验，以便在那种介于市场和创始人之间、一切都在快速变化的环境中取得成功？

Any advice for someone who's interested in designing at startups that they could kind of pull from or tap into some of your learnings for how to succeed in that environment where you're sitting in between kind of the market and the founder and everything's moving so quickly?

保持极度好奇，学得极快，不要爱上你的想法，因为它们会是错的，然后不断迭代。还有你听过的每一个初创公司套路：和你的用户交谈，和你的客户交谈，构建人们想要的东西。重复这样做，其他一切都会随之而来。我认为最大的推动力就是这个。

Be insanely curious, learn extremely quickly, don't fall in love with your ideas because they're going to be wrong, and just iterate. And every single startup trope you've heard of: talk to your users, talk to your customers, build what people want. Just do that on repeat, and everything else will kind of fall out of it. I think the biggest enabler is just that.

对我来说，就是持续学习，既学习用户和市场，比如你的产品表现如何、哪里失败了，也学习人。我认为设计师其实拥有一种超能力，任何有研究训练的人都是如此。我们被教导如何与人交谈，如何把他们的目标、欲望、恐惧解码出来，只要把这些研究超能力应用到一切事情上——比如去跟财务人员聊聊他们的财务运作或报告流程——只要在整个团队或整个组织里走动，把它当成一个用户研究问题。如果你反复这么做，我觉得几乎没有什么问题是解决不了的。

For me has been constant learning, learning both about users, the market, like how your product's doing, where it's failing, but also learning about people as well. I think designers actually have such a superpower in well anyone that has any kind of research discipline. The fact that we get taught and we learn how to talk to people, decode them into goals, desires, fears, just apply those research superpowers to absolutely everything, like apply it to talking to a finance person about how their finance operations are going or the reporting processes like whatever. But just go around the entire team or the entire org and just pretend it's a user research problem. If you do that on repeat, I think there's actually almost nothing that can't be solved.

我很喜欢这个观点，因为这也是与创始人打交道的好建议——把他们当作一个研究项目，帮他们理清自己脑海中的各种想法和纠结。我从很多这类对话中体会到，优秀的第一位设计师的一个特质就是能成为创始人的有效思想伙伴，甚至帮他们排序和梳理所有想法。因为想法有上百万个，每个都不错，那么如何按正确顺序找出正确的那些，以及早期阶段该忽略哪些好想法呢？

I love that, because it's even great advice for how to interface with a founder too, treating them like a research project, helping them navigate the weeds of their own mind and all of the ideas and untangling things. Something that I've kind of picked up from a lot of these conversations is that a trait of a great first designer is being an effective thought partner for that founder and helping them even sequence and think through all of the ideas, you know, because there's a million ideas, all of them are good. Okay, well how do we make sense of the right ones in the right order and what good ideas to ignore in the early stages?

我觉得这需要时间，但一旦你们建立了足够的信任和默契，你就会开始对哪些想法是噪音、很可能永远行得通产生直觉。而有些想法我们该稍微考虑一下，因为其中可能有一个方面或一个侧面，如果奏效的话会产生完全不成比例的影响。我们能深入探讨那一点吗？

I think it comes with time, but I think once you have a good amount of trust and a good amount of gel, you start to build a bit of like intuition around what are the really noisy ideas where these are probably just never going to work. This is like what are the that we should entertain a little bit because there's probably one aspect or one shade of it that could have a completely outsized impact if this works. Can we double click on that piece?

因为你处在一个有趣的位置——这虽然是创业公司设计师的普遍部分，但你也在一个押注大量技术突破的领域里设计，这些突破将改变整个行业。所以我的感觉是，你大概在“今天可能的事”和“这一切可能走向何方”这两个世界之间游走。这如何影响你探索和测试不同想法的方式，甚至在与创始人的对话中？

Because you're in an interesting place now where yeah, that's like a universal part of being a startup designer, but you're also designing in a space where you're kind of just betting on a massive amount of technological breakthrough which will change the entire industry. And so my sense is you're probably kind of straddling these two worlds of what's possible today versus where this all might go. And how does that impact the way that you explore and test out different ideas, even in conversation with a founder?

我认为这又归结到学习上。我和团队经常思考的是：如何在最短的时间内最大化我们的学习。这意味着大量快速、粗糙的实验，愿意犯错，把东西推出去看看什么能行。我们失败的时候，恰恰是当我们试图过于有远见的时候。有些项目或角度，我们以为模型会在六个月后做到某件事，实际上有时我们太听信基础模型提供商的话，他们说这些即将到来，所以你应该考虑以这种方式构建，为九个月后做准备。每当我们走那条路，结果都不理想。而每当我们真正缩短迭代周期，深入与用户交流，先做很小的部分，然后迭代构建，通常都能得到好结果。

I think again, like it all comes down to learning. What I think about and what we think about as a team a lot is just how do we maximize our learning in the shortest scale possible. What that means is like lots of rapid, scrappy experimentation, lots of you know being willing to be wrong and just putting things out there to kind of see what sticks. Where we have failed actually has been when we've tried to be too visionary. And so there's been a couple of projects or a couple of angles where we've worked on a problem and we've thought okay, the models are going to do this in like six months time. And actually in some cases you've listened too much to the foundation model providers where they've kind of said like oh these things are on the horizon, so therefore you should be thinking about building in this way for like nine months time or whatever. Whenever we've gone down that route, we've had suboptimal results. Whereas whenever we've really reduced our iteration cycles, really you know spoken deeply to our users, really small pieces first and then kind of built iteratively from there, we've generally kind of come to a good outcome.

我认为在 AI 之前就是这样：你应该总是把范围缩小到最小的可行版本。现在依然如此。显然还会有大赌注，尤其是当模型能力出现巨大阶跃变化时，你需要为此做好准备。但同样，即使是学习新模型，我认为你也应该非常迭代地处理：从小处着手，然后慢慢构建。

I think that was true pre AI that you should always be scoping things down to the smallest version possible. I think it's still true. I think there's obviously going to be still big bets and you know there's especially when there's a huge step change in like model capability like you need to be ready for that. But again, like even learning with a new model, I think you should approach that very iteratively of starting small and then building up slowly from there.

我想深入探讨你的工作方式，也许我们可以用你刚发布的视觉编辑功能作为窗口，了解日常工作和如何处理不同想法。也许我们可以从头开始，假设你已经识别出这个广阔的机会空间。作为设计师，你当时是如何探索并厘清它可能是什么的？

I want to go really deep into how you work and maybe we could use the visual edits feature that you just released as kind of a window into what day-to-day is and how you work through different ideas. Maybe we could start all the way at the very beginning when presumably you've identified this broad opportunity space. How were you then as a designer exploring and bringing clarity to what that could be?

我们有一个深刻的基本哲学信念：最好的 AI 工程师或我们这类产品的最佳形态，几乎应该像一个所见即所得的工具。它应该提供即时反馈，就像你在 Figma 画布上画一个矩形，它立刻以 120 帧每秒或你屏幕的刷新率出现。我们希望产品感觉像那样即时。从第一天起，我们就觉得这会促进构建最好的产品。而有些竞争对手完全不这么想。比如很著名的，Cognition 推出了 Devin，他们完全走智能体路线，认为 LLM 可以写代码，然后他们可视化一个桌面，你把任务扔给这个工程师，它花四小时处理再返回。显然所见即所得工具和那种方式是两个极端，但我们一直在试图找出我们在这条光谱上的位置。每次我们更倾向于即时反馈，我们从未后悔。从第一天起，我们就希望核心体验尽可能快速、有回报。视觉编辑功能从来不是一个需要优先排期的路线图项目，它从第一天起就一直在视野中，因为我们直觉上认为你总是想直接操作软件。这就是我们构建它的原因。

We had this kind of deep fundamental philosophical belief that the best AI engineer or the best product of our kind of shape would almost feel like a WYSIWYG tool. It would be like instant feedback, the same way that if you draw a rectangle on a canvas in Figma, it's just there instantly at 120 frames per second or whatever your screen is refreshing at. And we wanted our product to feel as instant as that. Since day one, we just sort of felt that it's going to promote being able to build the best products. And some of our competitors didn't think like this at all. So like obviously super famously, like Cognition launched Devin and they just went full-blown agent of like oh actually LLMs can write code, instead we're going to visualize like a desktop and sort of you're going to fire something over to this engineer and it's going to spend four hours processing things and then come back or whatever. There's obviously two extremes between a WYSIWYG tool and that, but we were always trying to figure out like where do we sit along this scale. And every single time we indexed more on instant feedback, we never regretted it. Since day one, we always wanted to have the core experience to be as rewarding as possible as fast as possible. Visual edits, they were never really like a roadmap item that needed to be prioritized. They'd kind of just always been on the horizon since day one because it just felt intuitive to us that you'll always want to directly manipulate software. And so that's kind of why we did them when we built them.

我们实际上几乎构建了两个版本。第一个版本，我们最初的假设是设计工具已经解决了很多问题，我们真正独特增加的是与 AI 协作并在已知环境中操控结果的能力。第一个版本对任何在过去二三十年用过 Photoshop、Sketch、Figma 等设计工具的人来说都非常熟悉。我们有一个图层面板，可以浏览所有图层，一个属性面板，可以检查并操控它们，所有好东西。但后来我们意识到，这些东西从 90 年代起就没怎么变过。Photoshop 的第一个版本在 1992 年就有图层面板了。于是我们开始从第一性原理问自己：为什么，为什么没有进化？我们认为有一个很好的理由……

I mean we actually built two versions of them almost. So the very first version that we built, our kind of ingoing hypotheses was the design tools have solved a bunch of problems and really what we're adding uniquely is the ability to collaborate with AI and manipulate the outcome in a known environment. The first version that we built was actually like super familiar to anyone that has used Photoshop, Sketch, Figma, insert design tool here over the last 20-30 years. So we had a layers panel where you could browse all of your layers, we had a properties panel where you could inspect things and then manipulate them, all the good stuff. But we had this moment where we realized that actually these things haven't really moved since the 90s. The very first version of Photoshop had a layers panel in like I think 1992. And so we started to sort of ask ourselves from first principles like why, why haven't things evolved? And we thought there was a good reason for like...

之前的转变，比如从桌面到网页，是说得通的：你仍然坐在台式电脑前，所以桌面界面是合理的。但我们意识到，现在有了 AI，我们可以真正向前迈进，而不是迭代式地小修小补。所以我们删除了图层面板，因为我们意识到，谁在乎图层呢？我觉得设计师之间甚至还在争论如何命名图层——比如“别删我的组 1427”——这本身就是一个强烈的信号。所以我们建了图层面板，又删掉了；加了更多样式功能，又删掉了。甚至——我技术背景很强，很熟悉 Flexbox，所以在 Webflow 这样的工具里，如果我想在某个响应式断点用 justify-between，它给我更多控制。但我们有了一个顿悟：谁想学 Flexbox？谁想吸收所有这些疯狂的领域知识，只是为了创造自己喜欢并希望别人也喜欢的东西？所以我们构建了这个设计工具版本，经历了一次存在主义危机，删掉了一半功能，然后发布了这个更简单的版本。

Previous shifts, like desktop to web, kind of make sense: you're still at a desktop computer, so a desktop interface makes sense. But what we realized was that actually now with AI, we think we can move forward genuinely forward rather than iteratively. So what we did is we deleted the layers panel because we realized that who cares about layers? I think the fact that there's even a debate amongst designers about naming layers—like 'don't delete my group 1427'—is a leading indicator. So we built a layers panel, got rid of it, built more styling, got rid of it. Even down to—I'm quite technical, I know Flexbox well, so in a tool like Webflow I'm at home if I want to use justify-between at a responsive breakpoint, it gives you more control. But we had this revelation: who wants to learn Flexbox? Who wants to ingest all this crazy domain knowledge just to create something they like and want others to like? So we built this design tool version, had an existential breakdown, deleted half of it, and shipped this simpler version afterwards.

你们真的把完整的图层面板发布到测试版了吗，还是只是在内部意识到这不是该走的方向？

Did you actually ship the full layers panel to even a beta, or was it just internally you had this realization that this is not the direction we should go?

具体到那个功能，那是内部的。我们构建并使用了它，然后睡了一觉，第二天醒来就想，‘不，我想走得更深。’因为即使在这个新的更小的范围内——‘好吧，我们不要完整的图层面板，但我们仍然想找到合适的交互提示水平，让用户做出更精确的修改’——作为设计师，你在实现那个版本时纠结了哪些问题？

For that one specifically, that was internally. We built it and used it, then slept on it, and woke up the next day and were like, 'No, I want to keep going even deeper.' Because even within this new smaller ballpark of 'okay, we don't want the full layers panel, but we still want to find the right level of affordances to give users to make these more precision changes'—what were some of the things you were wrestling with as a designer figuring out how to implement that version?

团队听腻了的一个词是“渐进式披露”。所以我们基本上在琢磨该展示什么、什么时候展示，以及如何渐进地展示。我们最终得出的方案是一个单一面板：首先，如果你不是设计师，也从不关心手动为应用设置调色板，这个功能几乎是不可见的，你可能根本不会注意到界面中有这个按钮。这是刻意为之，因为并非所有人都是设计师，而且我们的很多用户是第一次构建应用的人。首先，整个功能完全隐藏；其次，当你深入更高级的属性时，它会逐渐变得更复杂。所以大部分工作就是弄清楚如何随时间渐进地展示。

The word the team got really bored of hearing from me was 'progressive disclosure.' So we were basically trying to figure out what to show and when, and how to do it progressively. Where we landed was basically a single panel where first of all, the feature is almost invisible if you're not a designer and you're never going to care about manually setting a color palette for your app. You probably won't even notice that the button exists in our interface. That was very deliberate, because not everyone is a designer, and a lot of our users are people building apps for the first time. First of all, the entire feature is completely hidden, and secondly, it gets more progressively complex once you drill down into more advanced properties. So that was most of the work: figuring out how to be progressive over time.

你对这个方向有什么想法吗？你是把视觉编辑视为未来探索的基石吗？你是怎么考虑的？

Do you have any thoughts on where this could go? Are you viewing visual edits as a building block for any future exploration? How are you thinking about that?

最终目标是拥有像成熟设计工具那样精细到像素级的控制。我不太确定的是，它的形态是否还是我们今天所知道的设计工具。我认为有机会把很多我们习惯的东西宣布为遗留物。那将是我们更多实验的地方，可能先犯更多错，然后才做对。那也可能让人们感到有些沮丧，因为有些功能明显缺失——比如如果你想给图层命名，你不能一键完成。但我觉得，从一两年来看，这样做是对的，而不是梦游般地假设未来还需要过去的工具。

The eventual goal will be to have something where you have as fine-grained pixel-level control as you can get from a full-fledged design tool. Where I'm less certain is whether the shape will be design tools as we know it. I think there's an opportunity to declare a lot of what we've got used to as legacy. That's where we'll probably experiment a lot more, where we'll probably get a few things more wrong before we get things more right. It's where perhaps people might feel a bit more frustrated because this thing's plainly missing—like if you do want to name a layer, you can't just one-click go. But I think with maybe a one- or two-year view, it's the right thing to do, rather than just sleepwalking into assuming we need the tools of the past in the future.

但这不仅仅是过去的工具。你身处一个非常迷人的领域，我基本上从不在节目中问竞争对手，但我想这次破例，可以吗？因为你们处在一个前所未有的公司集合中，你不是唯一的年轻火箭船；一切发展如此之快，所有人的目光都集中在这套产品上。那么，作为其中一家公司的设计师，你如何把握关注周围动态的适当程度？

It's not just the tools of the past though. You're in a really fascinating space, and I basically never ask about competitors on this show, but I think I am going to ask you if that's okay. Because you're in this unprecedented little collection of companies where you're not the only young rocket ship; everything's moving so fast, all eyes are on this suite of products. So how do you think about the right level to even pay attention to what's happening around you as a designer at one of these companies?

这真的很有趣。现在在这个领域做技术，就像——我感觉自己像小时候第一次做这件事时一样充满活力。太棒了，这真的很好。不太好的地方是，它非常容易让人分心。哪怕只是喝杯咖啡时刷一下 Twitter——就有成千上万的东西能把你吸进去。这对我来说是一场个人斗争，所以我不得不提升自己。我的手机 24 小时开着勿扰模式，因为这样我的生活更好。我会为任何可能分心的事情大量设置时间盒。但说实话，这非常令人振奋。感觉——只有事后才能这么说——事情变得有点停滞了。我们有移动端，显然那是一个巨大的转变，然后作为设计师，我们开始思考跨平台设计和设计运营之类的事情。但我们基本理解 SaaS，对吧？就像，当然会有新的 SaaS 公司，但就是这样：交付一些价值，按周期收费，差不多就是这样。而现在一切都在改变，我认为这很棒。所以最终，这是一个超级有趣、超级好玩的领域。

It's really fun. Working in tech in this space right now is as fun as—I feel as energized as I did when I was a kid doing this for the very first time. Awesome, so that's really great. What's less great is it can be super distracting. Even just scrolling Twitter whilst having a coffee—there are thousands of things that can suck you in. That's a bit of a personal battle, so I've had to up my game. My phone lives on Do Not Disturb 24/7 because my life is better that way. I try to time-box a lot for anything that could be a distraction. But it's super energizing honestly. It feels like—and I can only say this with hindsight—things got a little bit stale. We had mobile, obviously that was a huge shift, and then as a designer we started to think about designing cross-platform and things like design ops. But we kind of understood SaaS, right? It was like, of course there will be new SaaS companies, but it was what it was: deliver some value, charge people for it on a recurring basis, more or less. And now everything's changing, and I think that's awesome. So ultimately, it's a super fun, super entertaining space.

作为设计师，你对设计工具的未来状态有什么信念或假设，是你正在反向推导的？

Do you have any beliefs or hypotheses about the future of the state of design tooling that you're kind of working backwards from as a designer?

我认为就像开发者有自己的开发环境一样。看看 IDE，其中的“I”代表“独立”。每个开发环境之所以可以独立，是因为代码是可互操作的。你可以把源代码存在某个地方，开发者可以按设备甚至按个人选择工作方式，一切都能正常工作。我认为设计的未来也会非常相似。我认为会有多个赢家。我不认为会有一个 AI 设计工具通吃一切。

I think the same way that developers have their own development environments. If you look at IDE, the 'I' stands for 'independent.' The reason why every development environment can be independent is because code is interoperable. You can have your source code stored somewhere, developers can pick and choose how they want to work individually per device even, and everything just works. I think the future of design will be really similar. I think there's going to be multiple winners. I don't really see there being one AI design tool that will win.

同样，我也不认为现有巨头就处于最佳位置。我可以想象几乎是为特定目的而生的细分工具，比如取决于它是做动效、更精细的调色工作、还是使用着色器等等。但我认为现在有了大语言模型，代码可以成为事实来源，而不是设计文件。我认为这将实现互操作性，因此设计工具可以独立工作，但贡献给同一个源头。我认为这甚至回到了你之前谈到的对学习和好奇心的强调。这是很长时间以来第一次出现真正的市场分化。也许我们正处于这样一个时期，我认为是的。但天哪，我们谈论 Figma 已经很久了，好多年。而且我确实相信他们会有所动作。你知道，几个月后 Config 就要来了，每个人都有自己的猜测。但事实是，现在有很多非常有趣的细分工具，设计师可以用各种不同的方式可视化他们的想法，这非常令人兴奋。

Likewise, I don't even see it that the incumbents are the best positioned. I can imagine almost niche tools for niche purposes, like depending on whether it's motion or doing more detailed color work or using shaders or whatever it might be. But I think now with LLMs, code can be the source of truth rather than design files. And I think that's going to enable this interoperability, and therefore design tools being able to work independently but contribute to the same source. I think it even goes back to some of the emphasis on learning and curiosity that you were talking about earlier. It's the first time in so long that there's a real fracturing of the market. And maybe we're in one, and I think we are. But gosh, I mean, all we talked about was Figma for a long time, many years. And I do believe that they're going to make some kind of a play. And you know, we have Config here in a couple months, and everyone has their ideas of what that could look like. But the fact is, there are a lot of really interesting niche tools in a lot of different ways that designers can visualize their ideas now, which is very exciting.

100%。而且我认为细分工具也应该被庆祝。我认为在科技领域，尤其是在风险投资中，游戏规则总是谁将获胜，谁就能获得多数市场份额。但尤其是现在有了 AI，既然我们可以更便宜地编写软件，我认为我们应该庆祝这样一个事实：我们可以创建更多单一用途的工具，专注于一个问题并把它做得非常非常好。你玩过 Unicorn Studio 吗？好奇问一下。对我来说，这就是细分工具的完美例子，它是无代码 WebGL。并没有很多人在摆弄它，但那些在玩的人正在做出最不可思议的输出。在 Twitter 上我显然看到了，它只是……我看到这样的东西，我就想，天哪，我对工具的长尾效应感到非常兴奋。

100%. And I think also niche tools should be celebrated. I think in tech, especially in venture capital, the name of the game is always who's going to win and it's always who can get majority market share. But especially now with AI, now that we can write software cheaper, I think we should be celebrating the fact that we can create more single-purpose tools that can focus on one problem and do that really, really well. Have you played with Unicorn Studio, out of curiosity? That's like the perfect example of a niche tool for me, where it's no-code WebGL. And there's not that many people tinkering with it, but the people that are are just making the most incredible output. On Twitter is obviously where I'm seeing it, and it just... I look at something like that and I'm like, man, I'm so excited for the long tail of tooling.

所以我还没玩过，对于不了解的人来说，它是什么？我应该做什么？比如，如果我玩一下，第一件事应该做什么？

So I haven't played around with it, so for the uneducated, what is it and what should I do? Like, what should the first thing I do be if I play around with it?

这就是重点，它非常艺术导向，因为它只是开放式的 WebGL，你可以创建这些非常非常详细的 3D 动效，然后它导出一个格式，你可以将其嵌入为 Framer 组件之类的。所以我帮助做的一件事是制作这个 3D 移动球体，但它完全由代码控制，你知道，它不是视频文件。所以它只是提高了你能用这些花哨视觉细节做的事情的上限，也许类似于 Rive 对动画的作用。我只是……我是个工具迷，所以对于像我这样花太多时间刷 Twitter 分心的人来说，现在是个有趣的时刻。

So that's the thing, it's so art-forward because it's just open-ended WebGL where you can create these really, really detailed 3D motion effects, and then it exports a format that you can embed as a Framer component, for instance. And so one of the things I helped with is making this 3D moving orb, but it's all controlled in code, you know, it's not a video file. And so it just raises the ceiling for what you can do with these kind of cheesy visual details, maybe in a similar way that something like Rive would for animation. I just get... I'm a tooling nerd, so this is just a fun time to be someone who does spend too much time scrolling on Twitter getting distracted.

酷。好吧，你给我的清单又增加了一个分心的事。说到分心，我确实想在这里深入一下技术细节，因为我看了你的路线图，在“下一步”一栏中看到了 MCP，这是现在 Twitter 上经常看到的热词之一。我不知道，我肯定其他遇到它的人也有和我一样的 FOMO。所以你能解释一下它可能意味着什么，或者它未来可能为设计师解锁什么吗？

Cool. Well, you've added one distraction to my list. Speaking of distractions, actually I do want to get nerdy for a second here, because I was looking at your roadmap and I saw MCP in the "next up" column, which is one of those kind of buzzwords that you're seeing all the time on Twitter now. And I don't know, I'm sure other people that have come across it feel the same FOMO that I do. So do you have the ability to explain what that might mean or what it might unlock for designers in the future?

MCP 代表模型上下文协议，按照典型的计算机科学家风格，这是个糟糕的名字。我们通常不擅长命名。它只是一种标准化的方式，让模型与其他事物通信。如果你在用 AI 构建，你将能够集成 MCP，任何集成 MCP 的其他东西都将能够互操作。所以我们现在就在用 MCP。我们在 Lovable 正在酝酿一些东西，我们将与 MCP 服务器集成，比如 Stripe、网络爬虫，以及我们用于构建全栈应用的 Supabase。因为我们完成了一次 MCP 集成，Lovable 就能与所有这些东西非常好地互操作。所以我们将看到的是，从大语言模型是各自独立的小孤岛（有自己的历史、知识，是自包含的），以及某个 SaaS 平台也是它自己的孤岛，到所有这些事物都能相互通信。这就是梦想，这就是愿景。不过非常前沿，而且我认为也有很多承诺实际上可能还没有完全实现。所以我们将看看这走向何方，但非常令人兴奋。

MCP stands for Model Context Protocol, and in typical computer scientist fashion, it's a terrible name. We are terrible at naming things generally. All it is, is it's just a standardized way for models to talk to other things. If you're building with AI, you'll be able to integrate MCP, and anything else that integrates MCP will just be able to interoperate. And so we're using MCP right now. Something that we're cooking up at Lovable, where we'll be integrating with MCP servers on things like Stripe, as well as things like web scrapers, as well as Supabase, which we use for building full-stack applications. Because we've done one integration with MCP, Lovable will just interoperate with all of these things really, really well. And so what we'll see is we'll go from this world of LLMs being little silos where they have their own history, their own knowledge, and that's kind of self-contained, and separately a particular SaaS platform being its own silo over there as well, to just all of these things being able to talk to each other. So that's the dream, that's the pitch. Pretty bleeding edge though, and I think there's also a lot of promises being made that actually maybe aren't quite being met yet. And so we'll see where this goes, but it's super exciting.

我们能谈谈 Supabase 这部分吗？因为那实际上是我使用 Lovable 时的顿悟时刻，就是我可以直接把它连接到数据库，与数据库对话，进行更改，而不必深入模式或真正理解幕后的一切是如何工作的。设计那个集成是什么样的？更广泛地说，创建试图简化和揭秘幕后发生的一些技术事物的交互，你是如何找出用户对抽象与控制之间的界限的？

Can we talk about the Supabase piece for a second? Because that was actually my aha moment with Lovable, was when I could just connect it to a database, talk to the database, and make changes without having to get into the schemas or really understand how anything's actually working behind the scenes. What was that like designing that integration, and even more broadly, creating interactions that try to simplify and demystify some of the technical things that are happening behind the scenes? How do you figure out where that line of abstraction versus control exists for users?

我们集成 Supabase 是因为我们希望让人们能够创建全栈应用。所以在 Lovable 出现之前，有多种选择可以创建落地页、静态网站之类的。但创建一个真正可用的应用程序非常困难。我们看了很多不同的选项，我们非常非常喜欢 Supabase 正在做的事情。所以使用它，或者说让人们能够将其用作后端，是理所当然的。至于我们如何设计它，我们基本上发布了我们能做的最简单、最小的版本，然后在那之后做了两件不同的事情。第一件事是我们通过大量的用户引导通话非常非常缓慢地添加功能。我们把它放在私人测试版一段时间，然后我们一个一个地引导人们加入，然后就是经典的迭代产品开发。实际上，所有这些中真正让我们惊讶的一件事是，人们非常愿意用这些工具进行相当长的自我教育之旅。所以我认为经典思维一直是这种“不要让我思考”和减少摩擦、减少摩擦。但我们看到的是人们非常兴奋。人们可以做他们以前从未能做的事情。他们正在做他们以前甚至无法想象的事情。实际上，一旦人们尝到了“哇，我真的可以自己做这个”的甜头，他们就愿意踏上整个自我教育之旅：“让我学习什么是数据库”，甚至“我不知道数据库是什么，我要去谷歌搜索什么是数据库”，然后我会继续……

We integrated Supabase because we wanted to enable people to create full-stack applications. And so before Lovable existed, there were multiple options to create a landing page, a static website, or whatever. Super difficult to create a real working application. We looked at a bunch of different options, and we really, really liked what Supabase was doing. And so it's a bit of a no-brainer to use that, or to enable people to use that for a backend. In terms of how we designed it, we basically shipped the simplest, smallest version of it that we could, and then we did two different things after that. The first thing is we added to it very, very slowly with a bunch of user onboarding calls. We had it in private beta for a while, and then we would onboard people into it one by one, and then just simply classic iterative product development. One thing that really surprised us actually with all of this was that people are really willing to go on a quite long self-education journey with these tools. And so I think classical thinking has been this whole sort of "don't make me think" and sort of reduce friction, reduce friction. But what we're seeing is that people are very stimulated. People can do things that they never could do before. They're doing things that they could never even imagine before. And actually what's happening is that as soon as people get a taste of "wow, I can actually do this for myself," they're willing to go on this entire self-education journey of "let me learn what a database is," even like "I don't know what one is, I'm going to Google what is a database," and then I'm going to sit on...

比如在 YouTube 上花两个小时学习什么是托管后端之类的。我们最终得出的结论是，早期指标显示，人们觉得能创建全栈应用非常赋能，而且他们也愿意学习。所以我们其实不太关心技术抽象或术语，因为术语因人而异，取决于你的领域知识。我觉得我们目前找到了一个不错的平衡点：解释清楚它是什么以及它的价值，然后在关键时刻手把手引导。但我觉得我们还能做得更多，我们现在是走中间路线，试图稍微技术一点，但又不至于太技术。

YouTube for like two hours learning about what like a managed back end is or whatever it might be and so of where we landed we had these early indicators that people felt very empowered by being to create full stack and we also had this early indication that people were willing to educate and so in the end we actually cared less about like what is the technical abstraction and like what is jargon because jargon is quite individually dependent depending on your domain knowledge and so I think we've struck an okay balance so far of kind of just explaining what it is and the value of it and then trying to hold your hand at sort of key moments but I think we can do a lot more we're kind of riding the middle at the moment of just like trying to be a little bit technical but not too technical

你说的“尝到一点甜头”很有道理，因为那正是我的经历。回想起来，你第一次生成任何东西时，头 10 秒就获得了巨大的价值，你会觉得“天哪，太疯狂了，再来一次”，然后立刻就有动力继续下去。我眨个眼，接下来就在读 Twilio 文档，因为我想接入 API。我本来没打算这么做，但这事会上瘾。解决一个问题，然后下一个，再下一个，真的很有趣。

It makes sense what you're saying about like the getting a little taste because that's was my experience even reflecting back on the journey it's like you get so much value and you're so interested in that first like 10 seconds the first time you generate anything you're like holy smokes that was crazy let's do it again and right away you're very motivated to keep going I guess and and I don't know like I blinked and the next thing I'm like reading twilio docs cuz I want to hook up the API you know like I had no intention of doing this but it's addicting you know it's it's just fun to try to solve the next problem and then the next problem the next problem

我觉得“有趣”这个词很贴切。作为设计师，我们经常思考“心流”状态，你知道当你进入心流时，几乎会失去时间概念。我们的一个核心理念就是弄清楚什么能促进心流、什么会破坏心流。从这个角度看，很多技术概念或抽象起初可能看起来非常领域特定，但如果它们能促进心流、赋能你的构建过程，那仍然非常有趣。这对我们来说就是一个好结果。

I think fun is the word like we we think a lot about flow as designers we know this right like you know when you're in flow and you know when like um you almost lose all you know concept of time one of our kind of driving philosophies is just trying to figure out what promotes and what detracts flow when we think about things that way it's actually quite surprising how many technical Concepts or how many technical abstractions you know might initially seem like they're they're quite domain specific but if they're promoting flow and if they're empowering you as you build um it's still super fun and so that feels like a good outcome for us

你提到了促进心流和反馈速度，显然你们团队有这些理念在指引。那么还有没有其他我们没聊到的、像北极星一样指引你作为设计师的东西？

You talked about promoting flow speed to feedback it's clear that you do have these philosophies as a team that are guiding you and so are there any other that we have not talked about that are kind of serving as like a North star for you as a designer

我们经常讨论的一个概念是“时钟速度”。我们认为，最好的产品是通过不断学习来打造的，而要实现最大化的学习，就需要个人和团队都保持一种舒适的“高时钟速度”。所以我们经常挑战自己：做一个决定需要多久？沟通一定要那么长时间吗？与其得出结论后说“让我跟别人确认一下，下周开会”，为什么不直接当场做一个 10 美分版本的决定呢？我们在这方面对自己要求很高。我认为这对我们的整体学习能力、以及我们能构建什么，都带来了回报。当然，这也有代价：有时候这种“凑合”会牺牲质量。但到目前为止，它让我们做出了一个非常强大、用户喜爱、产品市场匹配度极高的产品。我宁愿面对质量挑战——质量总是可以改进的——同时拥有好的匹配度，而不是反过来。

One thing we talk about a lot is clock speed or this idea of clock speed we think that we build the best products by learning as much as possible always and we think we learn as much as possible by kind of having comfortably High clock speed like individually and as a team and so we try to challenge ourselves on how long do we take to make a specific decision or does communication need to take as long like rather than you know arriving at a conclusion and being like let me S check that with someone else and put in a meeting for next week like what stops you from making a like a 10c version of that decision on the spot instead and so we challenge ourselves on clock speed a lot I think that's paid dividends when it comes to our like overall learning and our like abilities and like what we can build it comes with the the kind of trade-off that you know sometimes that can come in the face that scrappiness can come in the face of quality but uh so far I mean that's basically given as a super powerful product that people love with really really great fit where I'd rather have the sort of quality challenge of like quality can always be better than and with some fit rather than the other way around

有没有一个例子，你们优先考虑了时钟速度，直接做出了决定，而不是在内部争论不休？

Is there an example where you've prioritized clock speed and just pulled the trigger on a decision versus turning it into this debate internally

老实说，可能我们发布的每一个主要功能都是如此。比如可视化编辑功能，我们确实在图层面板等问题上有过哲学层面的争论，比如“我们有没有可能让这些成为历史？”但同时我们也意识到，一条路是再琢磨几天甚至几周，另一条路是直接把它从讨论中拿掉，然后以令人不适的速度获取新反馈。我想我们就是在努力拥抱这种“舒适地快”中不舒服的部分。

Honestly probably every major feature that we shipped so like the um like the visual edits for example I mean for sure we had this philosophical debate on like layers panels and like let let's see if we have a shot at making these Legacy but it was also like okay there's there's one path where we simmer on this for you know days to weeks more there's another path where we just remove it from the conversation and we can get new feedback uncomfortably fast and so I guess we're trying to embrace that uncomfortable part of comfortably fast

我有点共鸣，因为我最近在做一个新产品时也经常用“琢磨”这个词。我们再聊聊你的个人流程吧：在你自己的设计旅程中，什么时候你会使用 Lovable？

I feel some conviction because I've been using the word simmer a lot lately as I work on a new product let's talk about your personal process a little bit more when are you reaching for lovable in your own design Journey

总的来说，做设计时我总是从大到小。我会先确定层级，然后是其中的信息，接着是内容设计，内容满意后再布局。我的设计流程是：先问大问题，想清楚从内容角度我想要什么，然后根据功能特性，要么用 Figma 来找出最佳信息布局方式，要么如果是交互式的，我现在就直接用 Lovable。以前我对设计工具感到沮丧的地方在于，需要 500 个画板、极其完美的编排才能构建出我想要的东西。而现在，我通常先在 Figma 里设计第一个状态，然后转到 Lovable，从那里开始做交互。我会和 AI 一起即兴协作，制作实时原型。

So in general with with design like I always start kind of big to small and so I'm very much like okay like hierarchy first information within that and then content design and then once I'm happy with content then lay it out and so in terms of my design process I I try to ask the big questions first I try to figure out what I want from a Content perspective and then depending on what the feature is I'll either reach for fig to figure out the best way to lay out the information or if it's interactive like these days I just go straight for lovable I think where I was getting frustrated by design tools was just the whole pool noodling of like needing 500 artboards with like the most perfect sort of orchestration in order to you know build what I wanted whereas now I just generally will Design maybe the first state in FMA and then punch out to lovable uh and then just make an interactive from there and so I'll kind of jam with the AI to work through like live prototypes

你能聊聊你和 AI 即兴协作具体是怎样的吗？以及你在这个过程中学到了哪些经验或技巧，可以帮助设计师更好地进行提示？

Can you talk a little bit about what jamming with the AI looks like for you and any lessons or tips that you've picked up along the way to help designers become better at prompting

我会说，把 AI 当作一个创意伙伴。它在任何创意学科中都出奇地好，实验总是有益的。实际上，缺乏结构的地方正是你找到新颖解决方案的地方。所以不要想着“我需要完美的结构和完美的想法，然后把它翻译给 AI，让它执行我脑子里的东西”。相反，要超级开放，和它即兴协作，就像音乐家之间的即兴合奏一样，直接开始，事情自然会发生。摄影师不会试图完美地操控光线，他们设置好镜头，方向对了，然后自然光会提供一些光线，光子以意想不到的方式反弹，某个时刻美妙的事情就发生了，那时你会说“好了，我抓住了”。用 AI 做设计也是一样。当然，你需要运用自己的品味，对一切结果进行过滤。但不要期望它完美，也不要试图做到完美，顺其自然就好。

I would say treat uh AI as a creative partner it's surprisingly good in any of the creative discipline like experimentation is always good like actually a lack of structure is where you find um you know where you find novel Solutions and so rather than thinking okay I need to have the perfect structure and the perfect idea and I need to sort of translate that for this AI to then execute on what I think is in my head just be like super open and like just jam with it the same way I don't know if you're like a musician and you're just jamming with someone like just just go for it and like things things will just happen like a photographer doesn't try to manipulate light perfectly they set up a shot and the shot is in the right direction but you know nature provides some light and you know the photons bounc around in an unexpected way and then you know at some point something beautiful happens and like that's when you're like okay I've got it and just treat designing with AI the exact same way I'd say like obviously you need to exercise your own taste and you need to apply your own filter on everything that happens but I'd say don't expect it to be perfect and don't try to be perfect just uh Just Go With It

你有没有一个例子，和 AI 协作时它带你去了一个有点出乎意料的地方，但结果却很好？

Do you have an example of when collaborating with AI took you to a place that was a little bit unexpected but it

结果非常棒。在内容设计方面，这种情况经常发生。而且有时候幻觉对这方面也很有帮助，尤其是在命名功能时。所以肯定更多是在内容设计方面。我在想视觉或交互方面有没有什么有趣的东西。

Turned out pretty awesome. Happens all the time with content design, I'd say. And sometimes the hallucinations are actually really great for this as well, especially with naming features. So definitely more on the content design front. I'm trying to think if there's anything interesting on the visual or interaction side.

是的，实际上我强烈推荐大家去尝试一个 AI 驱动的设计工具，比如 Lovable 这样的工具，然后给它不同的艺术风格，构建一个你喜欢的 UI。一开始它可能看起来有点普通，但一旦你开始考虑添加个性，就让它为你设计风格，几乎就像一位艺术创意总监一样，尽情发挥。因为这些模型是在整个人类知识上训练的，所以如果你说“让它更像装饰艺术风格”或“让它更像包豪斯风格”之类的，不要局限于你在 Twitter 上看到的 UI 风格，比如玻璃拟态之类的。想任何视觉上的东西，它们都能做得非常好。把它当作一个创意合作者，不仅在功能部分，在其他所有方面也是如此。这会非常有收获。

Yeah, actually one thing that I'd really recommend anyone do is pick up an AI-powered design tool, like a tool like Lovable, and actually just feed it different art styles, build a UI that you like. It's going to look probably a little bit vanilla to begin with, but as soon as you start thinking about adding personality, actually just ask it to style things for you and almost act like an artistic creative director and go crazy. Because these models are trained on the entirety of human knowledge, so if you say something like 'make it more Art Deco' or 'make it more Bauhaus' or whatever, don't stick to the UI styles that you see on Twitter, like glassmorphic or whatever. Think of anything visual and they do a surprisingly good job. Just treat it as a creative collaborator, not just on the functional parts but everything else. It can be super rewarding.

我喜欢这个。你说得完全正确。有一套与 UI 相关的形容词词汇，我在与 AI 讨论视觉时几乎只使用这些词。这是一个非常好的建议，就是打破常规。我可以说什么都行，说什么它都会生成一些东西，所以我不妨用它来打破我想象力的局限。

I love that. You're totally right. There's a lexicon of adjectives that relate to UI, and I almost exclusively use those when I'm interfacing with AI about a set of visuals. That's such a great piece of advice, just breaking out. Like I can say anything, I can say anything and it's going to generate something, so I might as well use that as a way to break out of the box of what I'm capable of imagining.

当我们研究自动生成色阶时——我们并没有发布这个功能——但当时我输入了很多我最喜欢的电影和摄影师的剧照。所以你甚至可以说，“构建一个 UI”，然后说，“嘿，这是我最喜欢的韦斯·安德森电影的一个镜头，让这个界面更有安德森的感觉。”它做得非常好。

When we were working on auto-generating color scales—we didn't ship any of this—but when we were working on that, I was feeding in a lot of stills from some of my favorite films and some of my favorite cinematographers. So you could even be like, 'build a UI' and then be like, 'hey, here's a shot from my favorite Wes Anderson film, and let's make this feel more Anderson.' And it does a surprisingly good job.

作为 Lovable 的设计师，你在塑造用户与 AI 的交互方面扮演了多大的角色？比如输出的具体措辞、系统提示之类的内容，还是界面本身？这是你职责的一部分吗？

How much of a role as a designer at Lovable are you playing in shaping the interactions that users are having with the AI? The specific words that are coming out, any system prompt stuff, versus the interface itself? Is that part of the role for you?

我从界面方面开始，所以当然第一个要解决的问题是构建用户将要交互的 UI。但你很快会意识到，设置 AI 响应的行高并不是真正的 AI 设计；人们用它做什么才是。所以是的，当然。我们在构建 AI 方面有一种相当任人唯贤的内部文化。公司里的每个人都可以编辑它的思考方式和工作方式。实际上，公司里的大多数人都在为它做贡献，甚至非工程师也是如此。我们支持团队中的一个人一直在为核心 AI 做贡献，他们正在将通常的客户服务问题反馈给 AI，以便当场改进。我们也有这样的反馈循环。

I started out on the interface side, so of course the first problem to solve was putting together our UI that people are going to interact with. But you kind of quickly realize that setting the line height of the AI response isn't really designing AI; what people do with it kind of is. So yeah, for sure. We have a pretty meritocratic internal culture in terms of how we build our AI. Everybody in the company can edit how it thinks and how it works. Actually, most people in the company contribute to it, even non-engineers. One of the people who works on our support team is contributing to the core AI all the time, and they're sort of closing the loop from what would typically be a customer service problem to just feeding back to the AI to improve things on the spot. We have that feedback loop there as well.

这已经不是第一次听说支持团队或增长团队的人为核心系统提示做贡献了。我认为这是一个非常有趣的趋势。我之前提到过：现在的公司分为两类。一类是适应 AI 的公司，另一类是从 AI 中诞生的公司，AI 及其能力是它们工作、运营和思考方式的核心。我想知道这在多大程度上引起了共鸣，以及是否有其他例子可以说明 Lovable 的运营方式与你过去的经历有何不同和独特之处。

It's not the first time I've heard it where people on support or growth teams are contributing back to the core system prompts. I think it's a really interesting trend. I was kind of mentioning this earlier: companies fall into two buckets right now. You have companies that are adapting to AI, and you have companies that have been birthed from AI, and AI and its capabilities are at the center of how they work, how they operate, how they think. I'm wondering how much that resonates and if there are other examples where you can point to the way that the org operates at Lovable that is distinct and unique from what you've experienced in the past.

我们习惯创建的每一种人员基础设施，我认为总体上都是可以挑战的。我并不是想危言耸听，这只是我看到的现实。而且不仅仅是在 Lovable。还有其他公司，甚至更大的公司，也在进行这种 AI 优先的转型，并且看到了这一点。在欧洲，Klarna 就很有名地这样做，Intercom 也公开表示过进行这种转型。我认为整个职能部门可以合并和整合，这非常有趣。在我上一家公司，我们有太多人介于产品和客户之间，他们几乎只是同一问题的不同变体。所以我们有产品经理、研究员、解决方案架构师、售前工程师、客户经理等等一大堆人，他们的工作都是了解产品和客户，但解决流程的不同部分。这是一个很好的例子，说明你可以将几乎所有这些人合并成一个职能或很少的人。我在各个领域都看到了这一点。作为一家新公司，我们的优势是不必转型到新世界，我们可以直接开始。但我确信这是未来，也是发展的方向。

Every bit of kind of people infrastructure that we've got used to creating, I think it's up for challenging in general. I don't mean to be too alarmist with that, it's just the reality of what I'm seeing. And not just across Lovable, by the way. There are other companies, also much larger, that are kind of doing this sort of AI-first pivot and seeing this as well. So in Europe, Klarna quite famously is doing this, and also Intercom has been pretty public about doing this kind of pivot. I think entire functions can collapse and merge, which is really interesting. At my last company, we had so many people that sat between product and customers, where they were almost just different flavors of the same problem. So we would have product managers, researchers, solutions architects, pre-sales engineers, account managers, and this kind of laundry list of people where the job was to know the product and know the customer but solve different parts of this flow. That's a really good example of how you could collapse almost all of that down to either one function or very few people. I'm seeing that across the board entirely. And so we have the benefit as a new company of rather than having to pivot to the new world, we can just start. But I for sure think it's the future and where things are going.

嘿，我是 Rade。经常有人问我最喜欢的产品，所以我想花一分钟快速介绍一下我的工具栈。Deson 是我用来在不编码的情况下交付设计变更的工具。Frame 是我用来构建网站的工具。Genway 是我用来做研究的工具。Jitter 是我用来给设计添加动画的工具。Play 是我用来设计和制作移动应用原型的工具。Visual Electric 是我用来生成所有图像的工具。Raycast 是我每一步的快捷方式。我亲自挑选了这些公司与我合作，这样我就可以全职做这些节目。所以支持这个节目的最好方法就是去看看它们。你可以在 dive 找到完整列表。

Hey, it's Rade. I'm constantly asked about my favorite products, so I want to take just one minute and give you a quick rundown of my stack. Deson is how I ship design changes without having to code. Frame is how I build my websites. Genway is how I do research. Jitter is how I animate my designs. Play is how I design and prototype mobile apps. Visual Electric is how I generate all of my imagery. And Raycast is my shortcut every step of the way. Now, I've hand-selected these companies to partner with me so that I can do these episodes full-time. So the best way by far to support the show is to check them out. You can find the full list at dive.

在新世界里，设计的价值主张会如何转变？大家都会说品味将变得至关重要，我觉得这百分之百正确。另一件我觉得很有意思、也思考了很多年的事是，不同行业对“设计”这个词的使用方式完全不同。比如我是狂热的 F1 车迷，也热爱赛车和航空航天。那些行业里的总工程师就是总设计师。那为什么在科技行业，设计师的角色如此不同？我认为我们会看到更多这种融合。设计与工程是最明显的，但实际上在很多方面它们是一体两面。现在有了 AI，我觉得它们可以以非常新颖和激动人心的方式融合，同时也能跨职能地融合，比如设计和产品管理。

How does the value proposition of design shift in that new world? The obvious thing everyone says is that taste is going to be paramount. I think that's 100% true. The other thing I find really interesting, and I've thought about this for years, is how different industries use the term 'design' in different ways. For example, I'm a huge Formula 1 nut, and I love motorsports and aerospace. The chief engineer in those industries is the chief designer. So why is it that in tech, being a designer is so fundamentally different? I think we'll see more of that merger. Design and engineering are quite an obvious one, but in a lot of ways, they are two sides of the same coin. Now with the advent of AI, I think that can merge in very new and exciting ways, as well as cross-functionally in other ways, like design and product management.

没错。这正是我想补充的。回到你一开始说的，你坐在创始人和市场之间，那是非常高层次的设计。设计就是定位：我如何设计整个产品形态，以及它如何契合我看到的各种机会？在一个迭代速度可以进一步提升、更多人能够交付和发布产品的世界里，我感到兴奋。设计的那个部分也让我激动：非常战略性的产品级设计、市场级设计。想想就让人兴奋。

For sure. That was the piece I was going to add on. Going back to what you were talking about at the very beginning, where you're sitting between the founder and the market, that's design at a very high level. It's positioning as design: how do I want to design the shape of the entire product offering, and how does that fit into the different opportunities I'm seeing? I'm excited in a world where we can further increase the speed of iteration, and more people are capable of shipping and getting something out the door. That part of design is exciting to me too: the very strategic product-level design, market-level design. It's exciting to think about.

是的，百分之百。而且我觉得现在一切皆有可能。我们很容易忘记科技行业还很年轻。我们从 90 年代的静态网站，到 Web 2.0，再到今天。很多管理实践或公司结构都是我们自发形成的。我们走到今天，并不是因为这是最优设计，而只是偶然发生的。另一件容易被遗忘的事是，我喜欢科技的一个原因是它几乎没有限制。但另一方面，我们也会遇到糟糕的管理者，坦率地说。我们会有没受过培训、或者可能不该在那个位置上的人。这在很多方面也适用于创始人。所以我们围绕相当不完美或次优的结构来构建职能和整个公司。我认为现在一切都可重新定义。无论我们传统上怎么想，比如产品设计和工程之间的正式界限，我认为我们可以模糊甚至尽可能消除它们。

Yeah, 100%. And I think it's all to play for as well at the moment. It's maybe easy to forget that tech is quite young. We've literally gone from static websites in the '90s to Web 2.0 to here. There are a lot of management practices or company structure things that we just sort of made up organically. The way we've arrived at organically isn't because it's the most optimal design; it's just because it's kind of what happened incidentally. The other thing that's easy to forget is that one of the reasons I love tech is that there are almost no barriers to what you can do. But the other side of that is that we end up with bad managers, frankly. We end up with people who are not trained or maybe shouldn't be in that position. This also extends to founders in a lot of ways. So we build functions and entire companies around quite imperfect or suboptimal structures. I think all of it's up for play at the moment. Whatever we've considered traditionally, like product design and engineering and these formal lines between them, I think we can blur if not eradicate them as much as possible.

我们能不能对正在收听的人说点什么？他们在概念上对你说的所有内容感到兴奋，觉得有道理，但仍然存在一个鸿沟需要跨越：如何让像 Lovable 这样的工具融入他们日常的工作流程，尤其是在一家没有在 AI 前沿探索的公司？他们可能还在做那个 SaaS。像 Lovable 这样的工具在他们的流程中处于什么位置，他们又该如何思考用它来推动自己的手艺？现实是它可能并不适合，所以还有其他工具。例如，我们不支持导入现有应用；你不能把已有的应用带进来然后编辑。但我想说的是，回到持续学习这个理念上，通过端到端的交付你能学到很多。如果你是非技术背景，也就是说你不是能开发、构建、部署、维护全栈应用的工程师，你现在可以为你想要的任何东西做这些事了。仅仅是解决一个你觉得很小的问题这个行为本身：你可以构建它、交付它、把它给别人，然后从中学习。这本身就非常有价值。你会学到东西，也会更了解自己。我鼓励人们从这个角度去玩它。即使你没有商业头脑，即使你不想“我要创办自己的公司”或“我要做 X、Y、Z”，只是为了好玩而做。就像你会为爱人做一顿家常菜一样，为爱人做一个应用，看看会发生什么。我开始在 Lovable 里做生日贺卡。我给爸爸做了一张：我可以递送它、打印出来、生成一个二维码，那就是贺卡。然后你扫描卡片，它会跳转到一个带有有趣小动画的定制网站。为什么不呢？这很有趣。

Can we speak to someone who's listening, who is excited by everything you're saying conceptually, it makes sense, and yet there's still this chasm they have to cross to figure out how a tool like Lovable fits into their everyday workflow at a company that isn't pushing the boundaries of AI? They're probably still working on that SaaS. Where does a tool like Lovable sit in their process, and how can they even think about using it to push their craft forward? There's also the reality that it might not be the fit, so there are other tools. For example, we don't support importing if you have an existing application; you can't bring that in and then edit it. But what I would say is, coming back to this idea of constant learning, you learn so much by shipping end to end. If you are non-technical, as in you're not an engineer who can develop, build, deploy, maintain full-stack applications, you can do that now for anything you want. Just the sheer act of solving something that feels like a small problem to you: you can build it, ship it, give it to people, and learn from it. That in itself is incredibly rewarding. You're going to learn and reveal more about yourself. I would encourage people to play with it from that perspective. Even if you're not commercially minded, even if you're not thinking 'I want to start my own startup' or 'I want to do X, Y, and Z,' just do it for fun. The same way you would make a loved one a home-cooked meal, just make a loved one an app and see what happens. I started making birthday cards in Lovable. I made one for my dad where I can deliver it, print it, make a QR code, and that's the card. Then you scan the card and it's a custom website with little fun animations. Why not? It's fun.

他们喜欢吗？

Do they like them as well?

哦，是的，很棒。完全独一无二。而且花不了多少时间。这只是一种发挥创意的有趣方式。我开始降低自己制作东西的门槛。我第一次涉足 Supabase 是一个超级碗赌注游戏。我针对最热门的超级碗赌注提了 20 个问题，每个人都填写了，然后它会生成一个动态排行榜。你可以看到谁答对的问题最多，我们可以一起观看并刷新页面。太棒了。我以前绝对做不到。大概花了两个半小时，那是我几个月来最开心的时候。

Oh yeah, it's great. It's totally unique. It doesn't even take that much time. It's just a fun way to be creative. I've started lowering the bar for what I can make. My first foray into Supabase was a Super Bowl betting game. I asked 20 questions for the most popular Super Bowl prop bets, everyone filled it out, and then it would generate a dynamic leaderboard. You could see who got the most questions right, and we could all watch together and refresh the page. It was amazing. I would have never been able to do that before. It took me probably two and a half hours, and it was some of the most fun I've had in months.

我也很喜欢这两个例子。我其实之前都忘了，但回想大约 10 到 15 年前，我经常在网上给别人发贺卡，因为那很傻。但那些贺卡总是充斥着广告，很糟糕。所以现在你可以构建完全定制的东西，它是你的。我们根本不用再考虑那些了。

I love those two examples as well. I'd actually blocked this out of my memory, but going back almost 10-15 years, I used to send greeting cards online to people because that was a dumb thing. But they were always riddled with ads, they were horrible. So now you can just build something completely bespoke, it's yours. We just don't have to think about that.

好了，我们刚才谈到了 AI 原生或者说一切皆可重塑。作为拥有一个白纸一张的设计组织需要组建的人，你对此如何反应？这如何影响你寻找的设计师类型、你优先考虑的特质，甚至你梦想你们未来可能的工作方式？

Alright, so we were touching on some of the AI-native or everything's up for grabs. How are you then reacting to that as someone who has this blank slate of a design org to assemble? How does that impact the types of designers you're looking for, the traits you want to prioritize, and even the way you dream about how you all might work in the future?

我认为 Lovable 的一个独特之处在于，我们招聘的通才可能比一般公司多。实际上，团队中的大部分人——也许不是大部分，但很大一部分——是前创始人。我想说整个团队的一个共同点是，每个人都真的很……

I think one of the things that's unique at Lovable is that we hire probably more generalists than companies do generally. We actually most of the team, well maybe not most, but a good portion of the team is ex-founders. I'd say one thing that the entire team has in common is that everyone's really...

高能动性，而且大家通常都有点不寻常的背景。比如负责我们社交媒体的 Henrik，他做社交媒体是因为他之前运营过一个《美国办公室》的 Instagram 账号，完全爆火，有几十万粉丝。他十几岁就开始用周边商品之类的东西变现，所以他对社交媒体理解得非常深，而且有那种特立独行的劲头。在设计方面，我们的想法也一样：招聘通才、高能动性、不太考虑条条框框的人，而且要有自己摸索解决问题的特立独行精神。

High agency and generally people have had slightly unusual backgrounds in some way. For example, Henrik who runs our social media accounts got into social media because he used to run an Instagram account for the US Office that went completely viral, hundreds of thousands of followers. He started monetizing it as a teenager with merchandise and stuff, so he just really deeply understands social media and has this kind of Maverick streak. On the design side, we're thinking about things the same way: hiring people who are generalists, very high agency, don't necessarily think about the constraints of the box, and also have this Maverick streak of figuring things out for themselves.

我喜欢前创始人的文化。就通才而言，这大概是最有趣的了——每个人都身兼多职，大家一起摸索。我猜这一定是个很好玩的工作场所。

I love the culture of former founders. That's about as fun as it gets in terms of generalists, everybody wearing all the hats, we're all just figuring this out together. I got to imagine it makes for a fun place to work.

好处是，尤其是作为设计师，这里的流程不是瀑布式的。不是那种‘这是完美的设计，我想到了每一个边缘情况，给你’。这意味着我们可以协作，校准最重要的部分：我们在解决什么问题、为什么解决、整体理念是什么，然后一起把快乐路径敲定下来。这本身就非常有成就感。而且和这么多高能动性的人一起工作，每个人都超级聪明、超级有干劲，所以学习的机会也很大，这很棒。

The nice thing is that especially as a designer, design is not waterfall here. It's not like 'here are the perfect designs, I've thought through every single edge case, here you go.' It means we can collaborate and calibrate on the most important parts: what problems are we solving and why, and what's the overall philosophy, and really nail out the happy paths together. That's super rewarding in itself. But also working with a lot of high agency individuals, everyone's super smart and super driven, so the opportunity for learning is huge, which is great.

在设计 AI 产品时，你遇到了哪些其他挑战或考虑因素，是可能不在这个领域的人不知道的？

Any other challenges or considerations that you're experiencing when designing for AI products specifically that maybe someone who's not in this field would be unaware of?

是的，有一件事让我非常惊讶：最终用户、模型、模型拥有的上下文，以及你如何通过自己的应用架构来围绕模型构建，这四者之间存在着完全共生的关系。这需要在全栈范围内都配合得很好。对于 Lovable 用户来说，如果你想在应用里加一个新功能，我们通过一整条代码路径和模型路径来处理。如果你要修一个 bug，一个失败的做法是把这些当成技术问题，比如‘AI 工程师会搞清楚在这些具体情况下 AI 模型该有什么上下文’。我们成功的地方，其实都是用户体验问题：用户在那一刻想做什么？甚至在打开应用之前，他们的目标是什么？他们如何按大小分解任务，又如何导航？我认为最好的 AI 产品真正做到了用户目标与具体实现的结合。我真的很惊讶这一切如此共生。在大规模公开发布之前，我们有大约六到九个月的等待名单，期间我们做了三次大的重构，几乎删掉了整个应用重新开始，因为我们对核心用户流程不满意。我们不能一边改 UX，一边单独考虑 AI；我们必须把这两件事完全放在一起考虑。

Yes, one thing that really surprised me is that there's a completely symbiotic relationship between the end user, the models, the context that the models have, and also how you build around the models with the actual architecture of your own application. This needs to work really well across the whole stack. For Lovable users, if you're trying to add a new feature to your app, we handle that through one entire code path and one entire model path. If you're trying to fix a bug, one failure would be treating these as technical problems, like 'the AI engineers are going to figure out what context the AI models will have in these specific instances.' Wherever we've succeeded, it's actually been a user experience problem: what is the user trying to do in that exact moment? What is their goal even before they launch the app? How are they breaking down tasks in terms of size, and how are they navigating through that? I think the best AI products really nail this marriage of user goals to the individual implementations. I was really surprised at how symbiotic all of that is. While we had a waitlist for around six to nine months before our big public launch, we did three major re-architectures where we almost deleted the entire app and started again, because we weren't happy with the core user flow. We couldn't just edit the UX on one hand and think about AI on the other; we had to think about these things completely together.

我们聊了很多。最后还有什么想法、建议或心得想留给那些对你们团队工作方式感兴趣，或者只是想知道如何开始摆弄和探索 AI 的人吗？

We've covered a lot of ground. Any parting ideas or advice or learnings that you want to leave people with who are interested in how you all are working as a team or even just what it's like to start to tinker and explore with AI?

其实我也很想向别人学习。我觉得现在机会很多。有几个关键产品在做非常了不起的工作，我很想弄清楚现在最好的 AI 产品是哪些，什么让大家这么兴奋。任何产品只要让用户的行为因为它的存在而发生了有趣的变化，我都想了解。我很想听听你已经在关注并从中汲取灵感的产品。我觉得 Granola 非常有意思，因为它的 UX 极其简约，大概就是四五个小决策做得特别好，然后这就支撑了一大堆不同的用例。它还在很多方面迫使你改变。Granola 彻底颠覆了我对记笔记的思考方式。历史上我们总说‘减少摩擦，在用户所在的地方满足他们’，但有了 AI，我们需要反过来。不是去迎合用户，而是给他们超能力。Granola 就是那种让我在很多方面感觉自己拥有超能力的工具。

I'd actually love to learn from others as well. I think there's so much up for grabs right now. There are a few key products out there doing really amazing work, and I'd love to figure out which are the best AI products right now and what is getting everyone else excited. Anything where there's an interesting intersection of users actually behaving differently thanks to products existing. I'd love to hear about anything that's already on your list that you're taking inspiration from. I think Granola is a really interesting one because the UX is so minimal, it's like four or five small decisions made really well, and that empowers a bunch of different use cases. It also forces you to change in a lot of ways. Granola has turned how I think about note-taking upside down. Historically we've always said 'reduce friction and meet users where they are,' but with AI we need to invert that. It's not about meeting people where they are; it's about giving them superpowers. Granola is one of those tools where I feel in a lot of ways like I have superpowers.

嗯，我对 Lovable 也绝对有这种感觉。哪怕只是在咖啡馆里用移动版网站，它都成了我在手机上玩的新游戏。所以我很感谢你们投入的所有工作，也谢谢你今天花时间跟我们分享一些幕后故事。很高兴见到你并和你聊天。

Well, I've definitely felt that about Lovable too. Even just using the mobile site in a cafe, it's become the new game that I play on my phone. So I appreciate all the work that's gone into it and you taking the time to share a little behind the scenes with us today. Great to meet and talk.