新晋设计工程师如何利用 AI 策略提升自己

欢迎来到 Dive Club。我是 Rid，这里是设计师永不停止学习的地方。今天的嘉宾是 Carl Kosh，他将深入探讨如何作为新晋设计工程师提升自己。他会分享一些具体策略，让你充分利用 AI，甚至还会带我们了解他在 DuckDuckGo 担任设计工程师时打磨的一些细节。这期节目非常非常实用。那么，我们直接进入这些策略吧。

Welcome to Dive Club. My name is Rid and this is where designers never stop learning. Today's episode is with Carl Kosh and he's going to do a deep dive into how you can level up as a new design engineer. He's going to share specific tactics that you can use to get the most out of AI and even walks us through some of the little details that he's sweating as a design engineer at DuckDuckGo. And this is a very very practical episode. So, let's dive right in to some of these tactics.

我发现 AI 及其生成的代码有一个大问题，就是它非常确定性。它的整个方法就是寻找下一个最佳 token，然后基于这些 token 产生最佳输出，对吧？有时这很有帮助，因为你会得到最佳结果——它从 GitHub 获取所有训练数据，然后生成最好的东西。但有时它学习的内容可能并非最优。所以你最终得到的东西能用，但不一定以最佳方式运行。我做的这个小演示就是想直观展示我的意思。这里有两种方法，左边和右边。当我在里面输入内容时，比如我想筛选出鼠标垫，我输入 mouse，你可以看到每次我改变一个值，就会加载并闪烁一下。你还可以看到这个数字在疯狂增长。需要指出的是，这有点过于激进，因为我们运行在开发模式下。React 的严格模式基本上给我们带来了问题。它不会渲染那么多次，但至少对于右边这个例子，每次变化你会看到两次渲染。那么，到底发生了什么？我想区别在于，响应式方法把所有变化都包裹在 useEffect 里。useEffect 是 React 特有的东西，但 AI 就是喜欢把所有东西都塞进去，只要它能找到办法。

One of the big problems that I found with AI generally and the code that it produces is it's very deterministic. So like its whole approach is to look for the next best token and then produce the best output based on those tokens, right? Sometimes that's super helpful because you're going to get the best outcome because you're going to get like all of this training data from GitHub and it's going to create the best thing. But sometimes it's learning from stuff that's maybe not optimized. And so what you end up with is stuff that works but it doesn't necessarily work in the best way. And so what this little demo is that I put together is like trying to visualize what I mean by that. So you've got two two approaches, left and right. When I enter something in here, so let's say I'm trying to filter down and I'm interested in getting a mouse pad. So I'll type mouse and you can see every time I change a value, something kind of loads and flashes a bit. And you can also see this number is incrementing an insane amount. Important thing to flag is that like this is a bit over ambitious at the moment because we're running in a dev mode. So strict mode on reacts is basically causing us problems. It wouldn't render as often but you would at least render twice uh for every instance of this right-hand example. So what's going on uh and the difference here I guess is the reactive way is wrapping all of these changes inside of a use effect. Use effect is a thing that's very react specific, but it's something that AI just loves to put everything inside if it can find a way to do so.

我最近也注意到了。

I have noticed that recently.

对。我们本质上就是把状态变化放在 useEffect 里，所以基本上每件事都做了两次。而右边，我们直接实时更新状态。你看，没有闪烁。每次变化我们仍然会渲染，因为每次输入字母我们都要做点什么，但我们只做一次。而左边，如果忽略严格模式，每次变化我们会渲染两次。这是一个简单的小事，但你已经能看到两种方法之间的巨大差距。在这个例子里，只是过滤一个列表，还好。但如果我们是从网络过滤这个列表，发起网络请求，列表包含图片和大量数据，我们实际上就是在给前端增加不必要的负担，毫无价值。你可以用 AI 来解决这个问题。你可以说“这种情况一直发生”，但根据我的经验，如果你说“每次输入都会闪烁”，AI 会大费周章地试图解决闪烁问题，却不知道闪烁正是因为它把所有东西都包在不必要的地方造成的。

Yeah. And what we're doing essentially is we're putting the stateful changes inside of use effect. So we're we're basically doubled doing everything. Whereas on the right hand side, we're just directly going to update the state in real time. And you can see there is no flash. and we render still for every change because obviously we're trying to do something each time I type a letter. But we're only doing it once. Whereas on this side, if we ignore the the strict mode stuff, we would be rendering twice for each of these. It's a small simple thing, but you can already see like this huge gap between these two ways of doing something. And in this example, it's like, you know, filtering a list. That's fine. But if we are filtering this list from the network, so we're making network requests and that list contains images and lots of heavy data, we're essentially really overloading the front end with all of this extra work for absolutely no value. You could AI your way out of it. You could just say like this keeps happening, but in my experience like you say like this keeps flashing. If you don't know what's going on, you just say, "Every time I type, it flashes." The AI will go on this huge rampage of trying to like solve the Flash, but not understand that it created the Flash by just wrapping everything in a way it didn't need to be wrapped.

快速插播一条消息，然后我们继续。你知道吗？我对 Granola MCP 很兴奋。它让你可以直接将 AI 工具连接到你的 Granola 会议笔记。作为一个最近一直在用 vibe coding 做很多工具的人，这个发布非常重要，因为我的会议笔记是我拥有的最有价值的上下文之一。现在我可以找到特定主题、提取行动项，并根据我的会议历史回答任何问题。这些功能今天已经可用，我已经在疯狂地用它构建东西了。所以如果你想加入我，请访问 dive.comclub/granolamcp。就是 granolamcp。刚刚发布的更智能版本的 Lovable，在解决复杂任务方面提升了 71%，这意味着它可以更自主地完成更多工作。它有更智能的规划、提示队列，你可以在 Lovable 工作时堆叠请求。我最喜欢的部分是自动化测试，这意味着 Lovable 现在像真实用户一样测试你的应用。它会打开自己的浏览器，导航流程，调查边缘情况，并为你捕捉 bug。最棒的是，当它发现问题时，它会当场修复。我真的相信 Lovable 是目前构建软件最简单的方式。所以请访问 dive.club/lovable 尝试新版本。好了，现在回到节目。

Real quick message, and then we can jump back into it. You know what? I'm excited about the Granola MCP. It allows you to connect your AI tools directly to your Granola meeting notes. And as somebody who's been vibe coding a lot of tools recently, this release is a pretty big deal because my meeting notes are some of the most valuable context that I have. And now I can find specific topics, pull out action items, and get any question answered based on my meeting history. This is all available today and I'm already building with it like crazy. So if you want to join me, head to dive.comclub/granolamcp. That's granolamcp. An even smarter version of Lovable just released, but is 71% better at solving complex tasks, which means it can do more work more autonomously. There's more intelligent planning. There's prompt queuings. You can stack requests while Lovable works. And my favorite part, there's automated testing, which means Lovable now tests your apps like a real user. Opens its own browser, navigates flows, investigates edge cases, and catches bugs for you. And the best part is when it finds a problem, it fixes it right on the spot. I genuinely believe Lovable is the easiest way to build software today. So head to dive.club/lovable to try the new release. Okay, now on to the episode.

即使对于那些可能对看代码感到害怕的人来说，只要在脑子里记住一点：AI 倾向于过度使用 useEffect，这样你就可以轻松地说“嘿，是不是发生了这种情况？”或者确保我们没有做那种事。我已经把这个知识收进我的工具箱了。所以谢谢你。

And even for people who maybe are quite intimidated by actually looking at the code, just having the tiny piece of knowledge in their brain about hey AI has a tendency to overuse use effect making it easy to just say hey like is this something that's happening you know like or make sure that we are not doing that kind of thing. I've already tucked that away in my toolkit. So thank you.

这是个好问题。我真正注意到这一点，是因为 React 自己写了一篇博客文章，标题好像是“你可能不需要 effect”。整篇文章基本上在说，每个人似乎都过度使用 useEffect，因为它是让东西变得响应式的方法，但实际上我们现在有很多其他方法在代码中创建响应式结果。就像这个例子，你可以直接更新和操作状态，看到响应式输出。这太棒了。所以在这种情况下我们不需要 effect。于是我最终形成了一种技能。

It's a good one. I think the thing that really caught me onto it actually was that React themselves wrote a specific blog post which was titled I think it was you might not need an effect. The whole post was basically detailing the fact that everyone seems to overdo use effect because it's like the way to make something reactive but actually we've got loads of other ways now in code to create reactive like outcomes. And even things like this example where you can just directly update manipulate state and see a reactive output. That's awesome. And so we don't need the effect in this case. And so I ended up creating a skill.

嗯，那是在技能出现之前，但我创建了一个文档交给 AI，基本上就是放进去说，你看，这里有一篇关于不要使用效果的文章，照着做。然后我就可以随时调用它，比如问，你确定这里需要闪烁效果吗？参考一下这个文档。很多时候它会告诉我，这里有一个不必要的效果，我们把它去掉吧。

Well, it was before skills, but I created a document that I gave to the AI and just basically put it in there and said, look, you know, here's this article about not using an effect. Follow this. And so then I could just always call upon that and say like, are you sure we need like something's flashing here? Like refer to this document. And often times it would tell me like there's an unnecessary effect in here. Like let's get rid of it.

是的，这对我来说很有道理。我现在也在很大程度上这样思考我的实践：我不必学会所有东西，只需要做好策划正确的知识和灵感，然后以某种方式组织起来，让我能很容易地指向它来改进自己的实践。

Yeah, that makes a lot of sense to me. And it's even how I'm thinking a lot about my practice now is I don't necessarily have to learn everything. I just have to do a good job of curating the right pieces of knowledge and inspiration and then organizing it in a way where I can very easily point at it to improve my own practice.

是的。我认为秘诀就是我们之前提到过的，设计工程思维的理念是：你不需要成为编码专家，因为那样我就只是一个前端工程师了，而到那时，你知道我们就不需要这个角色了。更重要的是拥有那种结合的心态：足够好奇、注重工艺、有兴趣尝试并找到最佳解决方案，同时结合逻辑性、深思熟虑，并关心我们如何实际构建并让它工作。将这两种心态结合起来，会让你达到一个不同的境地，我认为，这比单纯依赖代码的设计师或完全依赖别人给设计或让 AI 出设计的工程师要好。拥有那个中间地带，我认为能给你带来最好的东西。还有那个“万事通”的争论，但没关系。我不介意成为设计和工程领域的超级通才，这没问题。

Yeah. And I think that's the secret is I mean we touched on it a bit earlier but the idea of the design engineering mindset is you don't need to be an expert in coding because then I'd just be a front-end engineer and at that point you know we don't need the role. It's more about having that kind of combined mindset of being curious enough, craft-oriented enough, and like interested to try and find like the best possible solutions combined with being logical, being thoughtful, and caring about like how do we actually build this and make this work? And combining those two mindsets gets you to this like a different place, I think, than you get if you're just a designer relying entirely on code or an engineer relying entirely on being given a design or asking AI to come up with a design. Like having that middle ground, it just gives you the kind of best of everything, I think. And there's the whole master of non-argument, but like that's fine. Like I don't mind being super generalist like across the board with design and engineering, but that's fine.

我认为我们正处于通才掌权的时代，你正好说到了这一点：能够用代码让像素活起来，与让它们以最佳方式移动和表现，这两者之间有很大的区别。所以我想知道你是否还有其他例子，可以作为设计师可以借鉴的小技巧，因为这对我已经非常实用了。

I think we're in the power to the generalists era and you're hitting on this thing where you know there's such a big difference between being able to bring your pixels to life in code versus getting them to move and behave in the best possible way. So I'm wondering if you have other examples that we can point to as just little tactics that designers can adapt because already this has been very practical for me.

是的。那么第二个演示，我想我们这里有了。这是我在 AI 生成的代码中发现的另一个非常常见的问题，但这只是工程学 101。考虑到我们提供给这些 LLM 的数据量，居然还有这些非常常见的简单错误，这让我有点困惑。但在这个例子中，我们又有左右对比。每次你在列表中创建东西时，为了正确渲染，你需要给它分配一个 ID。你可能遇到过这种情况：创建列表项时需要添加一个 key，这个 key 必须是唯一的，否则我怎么知道列表中的第一个和第三个是不同的？我看到 AI 非常常见的做法就是直接使用索引。索引是从零开始的数字，原则上看起来没问题，如果你不了解底层工作原理，你会觉得 0、1、2 都是不同的数字，所以当然没问题。

Yeah. So demo number two I guess that we've got here. So this is another like really common thing that I find in AI created code, but it's something that's just engineering 101. It kind of baffles me given the amount of data that we have available to these LLMs that like there are still these really common simple things going wrong. But in this example again, we've got the same thing left and right. So every time you create something in a list, for rendering to happen properly, you need to assign it an ID. And so you will have probably come across this with like create a list item you need to add a key and that key needs to be something unique otherwise like how do I know that the first one in the list and the third one in the list are different. The kind of very common approach that I see AI take is to just use an index. So index being a number from zero to whatever in principle it seems fine like if you just think as someone who doesn't understand how all of this is working under the hood okay you know not and one and two they're all different numbers so like that's fine of course.

索引就是数组中的位置，对吧？

And the index is just placement in an array right?

没错，是的，所以这就是为什么它从零开始，数组是零基的，所以从原则上讲，我们从零开始是有道理的，你会觉得没问题，那是唯一的。但现实是，正如你所说，我们根据它在数组中的位置来分配 key，这意味着它实际上并不像我们想的那样唯一。为了证明这一点，比如我在这里的框中输入 hello，然后在这里也输入 hello。左边我们使用索引，右边我们定义了一个基于几个不同参数的唯一 ID。如果我添加一个新条目，我的期望是它出现在顶部。

Yeah exactly yeah yeah so hence that's why it starts at zero so arrays has a zero base so we always start at zero from a kind of principal standpoint it makes sense and you're like okay fine that's unique. The reality is because of what you said there, the fact that we're assigning it a key based on where it is in the array, that means that it isn't actually unique like we think it is. To prove that point out, like if I just put hello into this box here and then we'll do like hello in this one here. So on the left we're using index. On the right we've defined like a unique ID which we're basing off of a few different parameters. If I add a new entry, my expectation here, add a new entry, it's going to come in at the top.

嗯。

Yeah.

所以我添加一个新条目，但什么？是的，它没有。这是因为它是数组索引，所以它被添加到了末尾。现在，如果我想做同样的事情，我可以这样。好了，在这一边，它像我们期望的那样出现在顶部。

So I add a new entry but what? Yeah, it doesn't. And that's because it's an array index. So, it's adding it at the end. Now, if I want to do the same thing, I can go cool. All right. On this side, we're getting it in the top like we expect.

所以，这没问题，很好。这意味着我们的右侧方法是有效的。在左侧方法中，还有另一个问题，因为这种基于索引的绑定，比如如果我改一下，我不知道，把这个设为 bad。我随便放什么词。如果我尝试删除 hello，你会看到，等等，什么？

So, that's fine. That's good. And that means that like our right hand approach is working. On our left hand approach, there's another problem which is because of this index base bound like if I change I don't know, let's put this one like bad. I put whatever words we want. If I try and discard the hello, you'll see that wait, what?

当然，它没起作用。这完全是因为索引不正确。而在我们定义了唯一 ID 的这个例子中，我可以独立地按正确顺序删除正确的东西。所以我的期望得到了满足，本该如此。这非常微小，非常具体。就像我之前遇到过的，你拼凑一些东西，让 AI 生成一个列表，然后你发现：“什么？每次我点删除，删掉的都是错误的那一个。” 这是因为 AI 似乎默认使用索引。

Sure, it didn't work. And it's all because the indexing is incorrect. Whereas in this example where we've got a unique ID that we're defining, I can independently remove the correct things in the correct order. So my expectation is met as it should be. That's so tiny and it's so specific. Like again, I've just been there before where you will put together something, ask AI to like put a list of XY Z together and you're like, "What? Every time I hit delete on this thing, it's just like the wrong one's being deleted." And it's because it just seems to want to default to using the index.

我知道这不是这个演示的重点，但是天哪，我非常注意你在右侧创建新项和删除项时元素的移动方式。那里有很多意图：创建新项时它从侧面滑入，删除时它先是降低不透明度，然后向上滑动。而我每次构建这个时，都会把它做成一个动作。但这感觉非常好。我想我们之前聊过一点，但设计工程思维的理念就是，即使是这样一个简单的小演示，我也愿意花时间在删除一个东西的体验上，因为最后那 10% 真的很重要。

I know this is not the point of this demo, but man, I'm paying so much attention to how things move when you create a new item on the right and delete an item. And there's like a lot of intentionality there where you're creating a new one and it's sliding in from the side and then when you remove one it first I guess maybe decrease the opacity and then slides up. Whereas every time I would build this I would have that be like one motion. But this feels so good. I guess we talked about it a bit, but like the idea of the design engineer mindset of just making like a silly little demo like this right now it's like I'm going to put that time into what the experience feels like just to delete a thing because that little 10% at the end really matters even though.

这就像，你知道，我是说这是一次性代码，我只是为了证明一个观点，但即使只是挑选一些工具，比如不必要的，我的意思是整个东西并不漂亮，这不太标准。但有很多这样的小细节，我会想，嗯，我要多花那 10% 的精力，因为如果全都是默认的浏览器样式，我会觉得奇怪。

This is like a you know I mean it's throwaway code right I'm just like doing it to prove a point but even just picking like instrument saf you know like unnecessary I mean it's not beautiful the whole thing right this fairly isn't standard. But there's like lots of little pieces like that where I'm like, well, I'm going to put that extra 10% in just because I feel weird if I just if it was all just, you know, I don't know, default browser stuff.

而且我觉得，作为一个还在努力提升、还没有达到这种品味水平的人，我可以看着这个说，‘哇，真不错。’然后我得训练自己的大脑去问，‘我为什么这么喜欢？’接着我就开始真正注意，哦，他在用两个不同的部分来思考这个问题。哦，新项目从侧面滑入。这正是我试图更有意识去做的事情——拆解为什么优秀的设计工程师擅长他们的工作，以及什么让设计真正有效。然后我就可以慢慢地把一两个、三个小技巧加入我的工具箱。我已经记下了：下次我要添加一个项目时，我会让它从左侧滑入 8 像素。

And I think again, like speaking as someone who is trying to build more that doesn't necessarily have this level of taste yet, you know, like I can look at this and be like, 'Wow, that was good.' And then I had to train my brain to be like, 'Why do I like that so much?' And then I'm really paying attention to, oh, okay, he's thinking about this in two different parts. And oh, new items slide in from the side. That's like something I'm trying to do way more intentionally is trying to tease apart why really good design engineers are good at what they do and like what makes it actually work. And then I can just slowly add one, two, three little pieces to my toolkit. And already I've now made the mental note like, okay, next time I have something where I'm going to add an item, I'm going to slide it in like 8 pixels from the left.

我想我对这些事情的思考方式是，如果你把它当作一个设计问题来拆解，试着理解‘我到底在做什么？’它只是屏幕上的数字像素，不是实物。但如果说我要添加一个新条目，我是在把某样东西放入一个已有的集合中。所以这就是为什么会有那种轻微的滑入效果——因为我在插入它，我在把它推进去，就像在现实生活中我们会做的那样，把它放进那个空间。然后当我丢弃它时，我对它不那么感兴趣了，因为我在摆脱它。你知道，我不需要它了。所以它更像是‘噗’一声消失，然后一切回到起点。这给了我们一个机会，把一些人性化和现实感带入原本只是数字像素的东西。

I guess the way that I think about it with these things is like if you break it down as a design problem and try to understand like what what am I actually doing here? Like it's digital pixels on a screen. It's not a physical thing, but like if I'm saying I want to add a new entry, I'm putting something into an existing set of things. And so that's why there's that kind of slight slide in cuz it's like I'm inserting it. I'm pushing it and like in real life that's what we would do. We put it into that that space. Then when I discard it, it's like I'm less interested by it cuz I'm getting rid of it. You know, I don't need it. And so it's kind of more of a just poof and go away and then everything kind of comes back to the kind of starting point. So it's it gives us that opportunity to I guess bring a bit of humanity and like reality to something that isn't inherently just digital pixels on a screen.

我笑了，因为你说‘噗’这个词，这正是我点击隐藏时脑子里出现的词。

I'm smiling because you said the word poof and that was the exact word that was in my brain when you hit hide.

这个词永远留在我脑子里。每次我想设计一个动画来消除某样东西，就是‘噗’一下让它消失。

It's It's the one that lives in my brain forever. Every time I'm trying to think of an animation to get rid of something, just poop it away.

很好，很好。好了，我们继续吧。我很享受。

That's good. It's good. Okay, let's keep going here. I'm enjoying myself.

所以我们有这个检查器。这个……它没那么令人兴奋，对吧？这个 UI 是故意有点小问题的。这更多是提醒我们自己，你使用的浏览器比你意识到的功能更多。有时调试问题的最佳地点就是浏览器本身。显然，Cursor 最近推出了在浏览器内调试的功能，你可以在侧面板和选择状态等地方做更多创意操作，这对很多情况都有帮助。但如果你用的是 Claude Code，做的是更终端化的事情，或者你用的不是 Cursor 的 IDE，你就没有那些功能。所以你可以直接利用我们这里已有的东西。显然有很多微妙而巧妙的东西，但最直接的问题是示例中的图片。图片被压扁了。这张看起来其实还行，差不多。我不知道实际背景什么样，但看起来挺接近的。如果我不知道要找什么，我可能会立刻想，‘嗯，好吧，这张没问题，其他的是坏的。’所以如果我试图提示 LLM 说‘你需要修复这些图片’，我该怎么说？我说‘图片被压扁了’。你告诉 LLM，它会说‘好的，没问题。’然后它会调整所有尺寸，因为它认为‘图片被压扁了’。哦，所以它会改变尺寸来解决问题。然后发现‘还是没解决’。于是你又得和它纠缠，问一堆问题。但实际上，我只需要右键点击，检查元素。如果我点击了图片，它就会直接带我进入控制台中的图片元素。我已经知道要找什么了。显然，这是可以训练自己掌握的东西，但我立刻就知道这个 object-fill 是问题所在。

So, we got this inspector. So, this um this is kind of more of it's is less overexiting, right? This um is just a slightly broken UI uh on purpose. This is more just like reminding ourselves that there's more to the browser that you're using than you realize. And sometimes the best place to debug a problem is is just in the browser. Obviously, you know, cursor recently have shipped the ability to kind of debug in the browser inside of cursor and do a lot more creative stuff inside of there with the the side panel and the selection states etc. which helps with a lot of this. Let's say if you're using Claude Code, you're doing something that's maybe more terminal based if you want to play in that area or you're using an ID that isn't cursor, you won't have that stuff. So, you can just leverage what we have here. So, obviously there's a ton of things that are subtle and sweet, but like the most immediate problem is the images in this uh example. So, like the images are getting squished. Now, this one looks fine actually, pretty much. I don't know what the back looks like in real life, but it looks pretty close. you know, if I don't know what I'm looking for, I might immediately be like, 'Huh, okay. Well, that one's fine. The others are broken.' And so, if I'm trying to prompt an LLM to be like, 'Ah, you need to fix these images.' Like, what am I going to say? Like, well, the images look squashed. You say that to the LLM, it's like, 'Great. Okay, cool.' And it will resize everything because it's like, 'Well, the images are squashed.' Oh, so it's going to change the dimensions to try and solve the problem. And then it's like, 'Okay, that's not solved it.' So, then you end up fighting with it again, asking it all these questions. But in reality, like all I got to do is just right click, inspect element. And if I've clicked on the image, I'm going to get taken straight to the image in this little console. I already know what I'm looking for. Obviously, it's the sort of thing you can kind of train yourself to get towards, but I know immediately this object fill is the problem.

嗯。

Mhm.

只需把 fill 改成 cover，我就能解决问题。然后我可以关掉检查器，因为一旦你做了调整，如果不刷新页面，检查器中的更改会保留。所以你不用一直开着它碍事。这样我就能看到，‘好的，太好了。’所有这些图片，虽然不是特别好看，但都合适了，看起来正确。这些小事情能节省大量时间，也节省大量浪费的积分和精力。我也犯过这个错，我知道很多人也是。一旦你开始用 AI 来帮助构建东西，很容易就总是依赖 AI 来解决问题。即使是我这样知道如何快速解决某些问题的人，也会陷入循环。我会想，‘我知道问题是什么，直接修吧。’然后 AI 可能修好了，但又产生了另一个问题，或者没完全修好。而我本来一分钟前就能解决，却没有。反而过度提示，最终和它对抗。实际上，我读了一篇 Andrej Karpathy 的有趣文章，就在前几天，昨天吧，他正好说到这个：你可以让 AI 生成一些东西，有时你会得到一千行代码，你一看觉得不太对，然后 AI 会立刻回答‘是的，你说得对。’然后它重构为一百行代码，完美运行。你会想，‘为什么第一次不这样做？’但正是因为你意识到它不对，才提示它去修复。我觉得这没问题，因为不是一次搞定，而是两次搞定，而且你仍然很快完成了。但如果你不知道质疑它，最终可能会得到臃肿的代码库，用几万行代码做本可以用几千行完成的事。

And just in one change from fill to cover, I can solve the problem. And I can get rid of the inspector because once you've made a tweak, if you don't refresh the page, the changes you've made in the inspector stay. So you don't have to have it living there always and getting in the way. But then that means I can look at this and go, 'Okay, great.' Like all of these images now, you know, they're not super nice images, but they all fit and they look right. Those sorts of little things that save you, I guess, a ton of time, but also just a ton of wasted credits and energy. I've been guilty of this, and I know a lot of people are. Once you start to play with using AI to help you build stuff, it's very easy to then just always go to the AI to solve a problem. And it's actually like even for me as someone who knows how to solve some of these problems quickly, I can get caught in a loop. I'll just fix this thing cuz I know what the problem is. Just fix it. And then it does maybe fix it, but then creates another problem or it doesn't quite fix it. And I could have solved it a minute ago, but I didn't. Instead, I just overprompted and overprompted and ended up fighting against it. And actually, I read an interesting article by Andre Kapathy. I think it was just the other day, yesterday, and he was speaking exactly to this where it's like you can ask AI to produce something and sometimes you get a thousand lines of code and you look at it and you think that doesn't seem quite right and then the immediate answer will be something like yes, you're right. And then they'll refactor it into something it's 100 lines of code and it works perfectly. and you think, 'Why didn't you do that the first time?' But it took you to know that it didn't look right to prompt it to then fix it. And I think that's fine cuz it's like a, you know, instead of being a one and done, it's a two and done. And you still got there pretty quick. But if you don't know to question it, you can end up with bloated repositories that are like tens of thousands of lines of code to do stuff that you could do in a few thousand.

我们能谈谈这个吗？我相信有很多听众在点头，因为他们从概念上理解，是的，如果你知道要找什么，你会得到更好的输出。然而，我花了很多时间思考，一个还不知道要找什么、甚至不太懂语法的人，如何能策略性地、高回报地缩小这个差距？因为现在已经不像以前那么简单了，比如去参加编程训练营，花八个月学语法。

Can we talk about that for a second? because I'm sure that there's a good amount of people that are listening that are like nodding along cuz they're understanding conceptually, yes, if you know what to look for, you will get a better output. And yet, I spent a lot of time thinking about how can somebody who actually doesn't know what to look for yet, they don't even really know that much syntax at all. How can they strategically close that gap in a way that is high ROI? Because it's not as simple anymore as like, well, just, you know, go to a coding boot camp, go spend eight months learning syntax.

你知道，在如何培养这种能力方面，肯定有一条更愉快的路径，但直觉上感觉不太对。肯定有更好的方法，肯定有可以优化的地方。对于那些有动力、想规划学习路径，但又不想从零开始搭建一个 HTML CSS 网站作为第一步的人，你有什么建议吗？

You know, there's got to be a happier path in terms of how to grow that muscle and be able to... that doesn't really pass the sniff test. There's got to be something better there. There's got to be a way to optimize there. Any thoughts for that person who's motivated, wants to think about a learning journey, but doesn't really just want to start building an HTML CSS website from scratch as step one?

是的，你这么说很有意思。我私下指导过很多人，实际上有很多人，从轶事来看，很多人正试图转向设计工程角色，无论是作为受雇岗位，还是仅仅作为一种更注重意识的思维转变。我发现自己一直在重复同样的话。比如，理想情况下，你需要理解终端，然后掌握基础知识，一旦你掌握了这些，你就可以做 HTML 和 CSS 的基础，然后你就可以不断构建。但很多人离开后回来跟我说：‘我刚参加了一个 React 训练营。’我说，好吧，但你也跳过了很多重要的东西，直接跳到了框架上。框架很好，但它们存在的全部原因就是创建一个抽象层。它们试图让你远离实际的工作方式，这对日常实用来说很好，但不利于你理解真正出错或真正发生的事情。这促使我整理了一门课程。我觉得这是我能做的最好的事情，来帮助弥合知识差距：把我所知道的一切，我花多年学习的一切，整合起来，以一种真正带领人们从零知识开始的方式。真的，我们说的是你甚至从未打开过终端，但我们从那里开始。到课程结束时，你正在构建网页、原型、交互式的东西、有动效的、能做巧妙事情的东西。这是一个完整的范围。我希望，但愿如此，它能提供一个人们可以随时回顾的资源。它不应该是一门从零到一的课程，然后发布就完事了，比如‘完成了课程，拿到了证书，我把它放到 LinkedIn 上，就完了。’这个想法是，它几乎成为一个你可以回头参考的仓库，如果你想再次做一个特定的动画。比如，‘哦，我记得在课程中学过，所以我可以回去找到它并重用。’

Yeah, it's funny you say that. I mentor a lot of people on the side and there's a lot of people actually just generally, anecdotally, there's a lot of people trying to move towards more of a design engineering role, whether that's actually a role they do as an employed role or whether it's just a mindset shift of being more aware. And I found myself just saying the same things over and over again. It's like, ideally you need to understand the terminal, then just the basics, and once you know that, you can do the basics of HTML and the basics of CSS, then you could kind of build and build and build. But then a lot of those people would go off and they'd come back to me and be like, 'I just did a React boot camp,' and I'm like, okay cool, but also you've just skipped so much important stuff and moved straight to a framework. Frameworks are great, but the whole reason they exist is to create a layer of abstraction. They're trying to take you away from how it's really working, which is great for practical day-to-day use, but it's not great for you understanding what's really going wrong or what's really happening. It spurred me to put together a course. That felt like the best thing I could try and do to help bridge that gap of knowledge: to take everything I know, everything I've spent years learning, and piece it together in a way that will properly take people on a journey from zero knowledge. Literally, we're talking you've never even opened the terminal before, but we start there. And by the end of it, you're building web pages, prototypes, things that are interactive, that have motion, that do clever stuff. It's a full spectrum. I'm hoping, fingers crossed, that it helps to provide a resource that people can come back to as well. It shouldn't be a course from zero to one and then just ship it and be done with it, like 'completed the course, got a certificate, I'll put it on LinkedIn and that's it.' The idea is that it becomes almost a repository that you can refer back to if you want to do a specific animation again. Like, 'Oh, I remember learning it in the course, so I can go back to that and find it and reuse it.'

嘿，快速说明一下。录制结束后，我问卡尔是否愿意为 Dive Club 听众提供特别折扣，他同意了。所以，如果你访问 dive.club/carl，就是 K A R L，你可以享受他的“成为设计工程师”课程 10% 的折扣，我们也会把它放在节目笔记中。好了，回到节目。

Hey, quick note. After recording, I asked Carl if he'd be down to offer a special discount for Dive Club listeners, and he agreed. So, if you head to dive.club/carl, that's K A R L, you can get 10% off his Become a Design Engineer course, and we'll put it in the show notes, too. All right, back to the episode.

而且我也很喜欢你特别定义了“前端的前端”，因为我认为这也是一个重要的区分。至少在我自己的实践中，作为一个做创业设计、身兼多职的人，前端的前端就是设计。这不再是工程的事了。作为设计师，我拥有这一切。这也说得通，对吧？这是用户体验的核心部分。它如何感觉、移动和表现？而到目前为止，这总是别人的工作来最终落地。这其实只是一个工具问题。现在我感觉自己有了能力，我就说：‘是的，这就是 UX 设计。我拥有这个产品的体验，这需要在前端的前端上把每一个细节都做到位。’

And I also love that you specifically defined like the front of the front end because I think that's an important distinction, too. And at least in my own practice as someone who is doing the startup design thing where you're wearing all of the hats, the front of the front end is design. Like that is not an engineering thing anymore. As a designer, I own all of that. And it makes sense too, right? That is a core part of what the user experience actually is. How does it feel and move and behave? And up to this point, it's always just been like somebody else's job to kind of land the plane on that. And it was really just a tooling issue. And now that I feel empowered, I'm like, 'Yeah, that's just UX design. I own the experience of this product and that entails nailing every single detail on the front of the front end.'

是的，我完全同意。实际上，如果你退回到 20 年前，前端的前端是由设计拥有的，因为那时有网页设计师的概念。网页设计师是当时任何机构中最常见的招聘岗位。期望是 HTML 和 CSS 是你的工作：你设计并构建基础，然后可能有人介入，做一点 PHP，大概在那时设置数据库，处理所有更交互和数据相关的部分，但你的网页设计师在整合前端。有趣的是，我们经历了一个巨大的旅程。我们之前讨论过关于成为通才的话题。当 Facebook 定义了产品设计师并说‘好吧，现在我们需要把这些东西都分开：产品设计、UX 设计、UI，它们不同吗？哦，也许我们只是把每个人都分散到这些超级专业的角色中’时，我们经历了一个巨大的旅程。我认为这些角色在一段时间内非常实用。它们实际上对交付优秀产品有很大帮助。但随着 AI 成为平衡器，赋予设计师更多权力和对前端的更多控制，我感觉我们正在重新回到通才领域。人们会想雇佣这样的人，因为从商业角度来看，这很有道理。你得到一个人可以做两个角色，对吧？太好了。但同样，从更自私的个人角度来看，作为在公司工作的设计师，这实际上给了我们更多对最终用户看到的东西的控制。作为设计师，我们最关心什么？我们关心最终客户将体验什么，那个使用产品的最终用户。你谈到了这一点，它确实包含了 UX。能够说：‘那个圆角看起来有点不对，我不喜欢。’而不是必须通过某种线性工具或其他什么进行对话，提交工单，试图让它被优先处理，做所有这些事情，你可以直接说：‘实际上，我只需快速跳进代码库，调整圆角，提交一个修复 PR，找人快速看一下，搞定。’5 分钟，10 分钟就完成了，而不是花两周时间试图让某人在路线图上优先处理它。

Yeah, I totally agree. And actually, if you step back like 20 years, the front of the front end was owned by design because you had the idea of the web designer. The web designer was the most common hire in any kind of agency actually at that time. And the expectation was HTML and CSS was your job: you design and you build the basics, and then someone probably jumps in and does a bit of PHP probably back then to set up the databases and do all the more interactive and data related parts, but your web designer was putting the front end together. And it's funny, we went on this huge journey. We talked about it earlier about being a generalist. We went on this huge journey when Facebook defined the product designer and went like, 'Okay right now we need to split all these things up: product design, UX design, UI, is it different? Oh maybe we just spread everyone apart into these super specialist roles' which I think were really practical for a time. They actually helped a lot for delivering great products. But with AI being this leveler of giving designers more power and more control over the front end, I feel like we are sort of swooping back into generalist territory. People are going to want to hire that because from a business perspective, it makes sense. You get one person who can do two roles, right? Great. But also from a more selfish individual perspective for us as designers working in a company, it's actually giving us way more control over the thing that people see at the end. And what do we really care most about as designers? We care about what the end customer is going to experience, that end person who uses the product. And you talked about it, the fact that it encompasses the UX, it really does. And being able to say, 'That radius just looks a bit off and I don't love it.' And rather than having to have a conversation about that in some linear or whatever people are using, raising a ticket and trying to get it prioritized and doing all this stuff, you can just say, 'Actually, I'm just going to jump in the codebase quickly, tweak the radius, ship a fix PR, get someone to have a quick look at it, done.' 5 minutes, 10 minutes done, instead of battling for two weeks trying to get someone to prioritize it on a roadmap.

在过去的 15 年里，我每天都在设计产品。但在过去的 6 个月里，一切都变了。有了 AI 的加入，我比以前更快地产生想法。但如果我无法获得让团队对齐所需的反馈，这一切都无关紧要。而现在，获取异步反馈仍然有点糟糕。所以，我正在构建我一直想要的产品，它叫做 Inflight。我每天都在用它分享想法并从团队那里获得反馈。

I've been designing products every day for the last 15 years. But in the last 6 months, everything has changed. With AI in the mix, I'm cranking out ideas faster than ever. But none of that matters if I can't get the feedback that I need to get the team aligned. And right now, getting async feedback still kind of sucks. So, I'm building the product I've always wanted, and it's called Inflight. I use it every day to share ideas and get feedback from the team.

你提到变形效果很有意思，因为我一直没能用 AI 做出让我满意的效果，它总是有点歪，或者我不知道该用 motion 还是纯 CSS，或者像你提到的 clip path。也许我们可以稍微具体一点，因为这对我来说非常相关。设计师应该如何思考创建这种效果？假设他们不会写太多代码，只是试图引导 AI 来帮忙。

It's interesting that you talk about the morphing effect because I haven't been able to really pull that off in a way that I've been proud of with AI and it always kind of gets skewed or I never know like do I use motion for this or is it just CSS or like you mentioned clip paths like maybe we could just get ultra specific here for a second because this is very topical for me. How should designers think about creating this type of effect? Assuming that they're not going to be writing much syntax and it really is just trying to coach the AI to help.

嗯，我认为这里又是一个例子，说明对工作原理有一点了解能给你正确的词汇去描述它。就像我们遇到 use effect 错误时，会说“哦，不太对，我以前见过，可能是 use effect”，然后就能引导对话。这里你也可以这样做，比如你说“我想做一个 clip path 动画。我有一个圆形，我倾向于避免使用库，因为我想保持响应式，减小包体积，关注性能——这对我们构建搜索引擎显然很重要。所以，使用 clip path，按钮是一个圆形，我想让它变形为包含内容的对话框形状。”你可以从那里开始，就这么简单。但你已经给了它关键词：clip path、起始为圆形、变形为对话框。它应该能从这些信息中推断出足够的内容。然后一旦它开始工作了，仍然需要一些打磨。但功能实现后，你就可以开始思考如何调整 cubic bezier，比如我希望动画实际感觉如何？然后你可以使用很多工具，比如 design engineering 网站上的工具，easing.dev 也很适合获取小片段来尝试。通常我会获取这些片段，然后放一堆进去，试试“如果很快弹出是什么感觉？如果很慢弹出呢？”然后开始仔细拆解，找到感觉恰到好处的值组合。这花了一点时间调整，因为最初要么太快，要么太夸张。我还看到很多这种情况，特别是如果你让 AI 构建东西，它会把所有东西都做成弹簧效果。所有东西都是弹簧。

Well, I think here is another example where understanding a little bit about how it works gives you the right vocabulary to talk about it. So, just like we would if we had the use effect error where it's like, okay, that's not quite right. I've seen it before. It's probably use effect. And I can kind of steer the conversation. You could do the same thing here where you say like I want to do a clip path animation. So, I've got this circle. I prefer to avoid using a library because, you know, I want to keep it responsive. I want to keep it kind of keep the bundle size down, focus on kind of performance, which is obviously huge for us building a search engine. So, like, you know, use a clip path and I want the button is going to be a circle and I want it to morph into the shape of the dialogue that contains the contents. And you can kind of start from there, like as simple as that. But already you've kind of given it key words which are clip path starts as a circle morph dialogue. So it's like it should know from that and be able to infer enough. And then once you get to that point it's like okay now it's functioning and it still takes some finessing. But once it's functioning then you can start to think about like okay how do I dial in this cubic bezier? Like what do I want this to actually feel like as an animation? And then you can use there's tons of tools. There's some tools on the design engineering website. There's tools like easing.dev is really good for just getting little snippets you can play with. And then typically I'll just get those and just drop a bunch in and just try like what does it feel like if it's really fast out? Does it feel like if it's really slow out? And just start to really kind of pick it apart and find the right combination of values that just feel just right. And this took us a little while to tune because originally it was like too quick or it was too kind of boisterous. Another thing I see a lot with these things, especially if you ask AI to build stuff, is it springs everything. Everything's a spring.

所有东西都是弹簧。对，所以你会听到“boing”，然后这个东西飞来飞去，有时候很酷，但如果你在这种上下文中，这个东西在弹来弹去，而我想阅读——我点击它是有原因的。目标是阅读版权信息。所以动画不能过于随意，不能太抢眼。

Everything's a spring. Yeah. So, you be like boing, you know, you got this thing flying about and you know, cool sometimes, but if you're in this kind of a context and this thing was like bouncing around like I'm trying to read, you know, I've clicked it for a reason. The goal is to read the copyright information. So, the animation needs to not be like overly gratuitous and like too in your face.

所以我们思考的方式是：如何让它比单纯的显示和消失更有趣、更周到，但又不会走向随意和过度。还有其他的地方，比如这个“更多”按钮，当我们处理这个时，如果你想展开答案，这里有一些微妙的动画，状态池发生变化。它们只是帮助讲述“有事情发生”的故事，感觉比突然变化要好一点——如果突然变化，你注意不到变化，那可能是个问题。

So the way that we kind of thought about it is how do we make it so that it's more interesting and more kind of thoughtful than just appearing and disappearing but without going down a path of being like gratuitous and just like over the top. There's other places like this more button as well when we worked on this like this is if you want to expand the answer out like there's some subtle animation here where the state pool changes happen. They just kind of help to tell the story of like something's happening and it feels a little bit nicer than just if it suddenly changes you don't notice the change and that can be a problem.

这类东西对你来说可能显而易见，但即使像 clip path 和 morph 这样的实用词汇，对我其实也很有帮助，因为我总在寻找合适的语言来描述我想要的东西。所以我很喜欢听你讲这些。我想稍微拉远一点，你谈过这种作为设计工程师的心态。还有没有其他我们没聊到的、属于这个范畴的东西，你觉得一个更偏向传统设计师、想锻炼这些能力的人可以思考的？

This kind of stuff might seem obvious to you, but even very practical stuff like the words like clip path and morph. Like that's actually really helpful for me as I'm just always trying to find the right language to describe what I want. And so I love hearing that. I'm wondering even like zooming out for a second, you've talked about this mindset for what it means to be a design engineer. Is there anything else that falls into that category that we haven't talked about that you think someone who does resonate as being, you know, much more of a traditional designer who wants to grow those muscles, anything else that falls into that category that we can be thinking about?

对我来说，最大的事情是我们聊过 LLM 如何帮助设计师升级，让他们变成能写代码的设计师，对吧？这很棒，因为我们能看到设计师交付那些他们可能永远无法交付、或者无法完全按自己想法实现的东西。我认为真正区分设计工程师和前端工程师的是创造力和工艺。这是一种关心最后 10% 的心态。就像我提到的，点击率不到 1% 的按钮根本不需要动画，确实不需要。但我希望它动起来，因为我想让那 0.1% 或 0.04% 的人——不管比例是多少——在点击时感受到被在乎的体验，有一个愉悦的瞬间，让他们觉得做这个的人考虑到了这一点。即使他们没有有意识地想到，潜意识里也会感受到。对我来说，这就是设计工程师：一个以设计师心态交付产品的人。你在思考如何构建，但你在思考如何以最令人愉悦的方式构建。

So, for me, the biggest thing is we talked about LLM and how they're kind of helping to level up designers and turn them into designers who can code to a degree, right? And that's fantastic because we're able to see designer ship stuff that maybe they wouldn't have ever got to ship or wouldn't have quite turned out the way they wanted to. And I think that the piece that really tells a design engineer from just a front-end engineer is creativity and craft. And it's having the mindset of being someone who cares about that final 10%. Like I was talking about less than 1% clicked button doesn't need to animate. It just doesn't. But I want it to animate because I want the that 0.1% or 0.04% or whatever it is that the person who's going to click that to have an experience that feels cared about and and like has a moment of delight that they can be like that person who made that thought about this. Even if they don't consciously think it, they're going to think it subconsciously. That for me is the design engineer. It's somebody who has a designer's mindset towards shipping product. So, you're thinking about how to build it, but you're thinking about how to build it in the most delightful way possible.

我喜欢用创造力和工艺来定义。这让我好奇，你在设计工程师的就业市场上看到了什么？我很好奇现在的状况，以及随着 AI 让代码越来越便宜，这个趋势会走向哪里？

I love the combination of creativity and craft as a definition. And it then kind of makes me wonder like what are you seeing at the job market level for design engineers? I'm curious state of the world today, but then also like where's this kind of heading as AI continues to make code cheaper and cheaper?

我认为目前很多职位仍然处于我们过去或现在的状态：设计工程师仍然需要具备基础的编码知识，能够编写代码，并把 AI 作为加速器，而不是 100% 依赖 AI 来写代码。当然，在就业市场之外，你可以用 vibe coding 把东西直接部署到生产环境，并且 100% 成功。但在职场中，这行不通。你不会看到雇主说：“好，我完全信任 vibe coding。”有些地方在尝试，我听说 Intercom 有些设计师在用 vibe coding 直接部署到生产环境。听到这个很有意思，因为当他们在构建、交付和开发的东西足够简单，可以信任机器完成全部工作时，这确实有价值。但根据我的经验和对话，大多数雇主仍然会担心让人们盲目信任 AI 并部署到生产环境。事实上，这让我想起《办公室》里的一幕——Michael Scott 盲目信任导航，结果开进了湖里。就是这种心态：你让机器告诉你一切，然后你说“好，我就这么做”。这能帮你走一段路，但并不意味着你突然就能用 vibe coding 成为 100% 的设计工程师。我认为你仍然需要足够的心态。不过，这种情况会改变——我不是在对着云喊叫的老头。我现实地知道，不会永远需要你掌握所有这些事情的 100% 知识。就像设计工程师需要理解设计和前端一样，随着时间的推移，这个范围会越来越窄，直到 AI 足够好，我们可以说“我不需要知道 useEffect 的 bug，因为训练数据已经足够让它不再犯这个错误”。这只是时间问题，我不否认，但我认为这还需要几年。所以，现在仍然是掌握这些基础的好时机。

I think a lot of the roles still at the moment are sat kind of maybe where we were or where we are kind of in the current state which is that a design engineer still needs to have fundamental coding knowledge and needs to be able to code and use AI as an accelerator but not the 100% their their way of coding something. Obviously outside of the job market you can vibe code something into production and and be super successful like 100%. Uh in the job space like that just won't fly. Like you're not going to see an employer being like, "Cool, you know, I'm going to trust 100% vibe coding." Some places are are triing it. I've heard some mutterings around Intercom are triing designers uh vibe coding into production. And super interesting to hear that that's like happening because I think there's definitely a value to it when the thing that they're building and shipping and working on is like simple enough that you could trust the machine to do the whole thing. But I think most employers I think at le you know at least in my experience in the conversations I've had are still going to be nervous about allowing people to just like blindly trust an AI and ship to production. In fact like uh if I think about it it reminds me very much of uh of the office and people may remember this but the moment where Michael Scott blindly trusts the sat nav uh and then finds his way into a lake. But it's that same kind of mindset of like, you know, you let the machine just tell you everything and you go, "Okay, I'll do it and I'll do it that way." And that can get you a certain amount of the way through, but it doesn't mean that, you know, suddenly now you can vibe code like a thing that you're you're 100% now a design engineer. I think you still need to have enough of a mindset. I think that will change though, like, you know, I'm not I guess old man yelling at clouds about this. Like I know realistically that like it's not going to be a forever world that you're going to need 100% knowledge across the board of these things. Um, and I think just as like a design engineer needs to understand design and like the front of the front end over time that is going to narrow and narrow and narrow to the point that AI probably will get good enough that we can say like you know I don't need to know about the use effect bug because enough has happened in the training data that it knows to not do that anymore. It's only a matter of time like I'm not going to deny that but I still think we're probably like a few years off from that being a thing. So, I think it's still a good time now to to grasp on those fundamentals.

让东西变得好用和令人愉悦之间有很大的差距。即使回到你添加和隐藏的那些小元素，里面有很多细节，你能感受到不同。我开箱即用根本达不到那种质量。而且这远远超出了我如今看到的很多讨论——我们指着紫色渐变说那是 AI 的视觉垃圾。我其实不太在乎视觉效果。我认为视觉质量的门槛会快速提高，但那不是我作为交付型设计师脱颖而出的最佳方式。我希望东西感觉惊艳、响应迅速、快速且优化。我花更多时间在交互上与 AI 周旋，你很快就会发现自己在那个领域的不足。现实是，我可能确实需要多学一点。这让我想起你的一句话，我记下来了，大概是“用 vibe 构建，但用严谨交付”。我感觉自己在“用严谨交付”这部分有差距，这绝对是我在努力成长的地方。我第一个承认，我工作中很多东西都是用 vibe coding 做的，我和任何人一样都在利用这些工具。

And there's such a gap between making something functional and delightful. Even going back to like those little items that you were adding and hiding, you know, like there's a lot that goes into that and you feel the difference. I'm not getting anywhere near to that level of quality out of the box. And again, it's like it's so beyond the conversation that I see a lot today of, you know, we point at the purple gradients and how that's, you know, visual slop from AI. I don't even care about the visuals really. I I think the bar for visual quality is going to continue to rise really quickly. And I don't really see that as the best way for me to even stand out as a designer who ships. I want things to feel amazing and to be really snappy and fast and optimized. And I'm I spend so much more of my time wrestling with AI around like interactions and you very quickly realize what you don't know in that world. The reality is I probably do have to learn a little bit more. It reminds me of even like one of your quotes that I wrote down. It was something like uh build with vibes but ship with rigor. I'm like I can feel my gap right now in the ship with rigor part of the equation. And it's definitely something that I'm trying to grow in. I'd be the first to admit I vibe code a bunch of stuff that I work on. Like I leverage these tools as much as anyone.

你知道，有些时刻我会想：‘哦，我现在还算设计工程师吗？我是不是正在远离这个角色，因为我越来越依赖 AI 来解决问题？’但后来我不得不回到一个事实：让我对事物有不同感觉的是，我会做出 AI 不会做的设计决策。有时候我让它去做一件事，它说做完了，我一看结果，心想：真的吗？但也有时候，我会想到一个它根本不会想到的点子。这些点子并不复杂。我们说的是简单的东西，比如我的个人网站。有些例子，比如那些卡片：当你悬停在这些卡片上时，它只是把当前元素的图片取出来，放到背景里，模糊并放大。仅此而已。这是一个简单、微妙、几乎毫无意义的小动作，但它给这一刻带来了一点生气。是的。我们在这些音乐卡片上也做了同样的事情。它只是把专辑封面图取出来，放在上面，然后模糊掉。然后你看到这些小音符在飞舞。都是些不必要的小细节。它们只在桌面上显示，在移动设备上看不到——这对重要交互来说总是一个问题，但在这里它只是点缀，所以没关系。我喜欢把它看作一种方式，让人们有机会看到那额外的 5% 到 10%——‘哦，我足够在意，所以决定这么做。’我试着在整个网站里都撒上这样的小细节，但又不想过多地分散注意力，偏离网站的核心目的：这里有一些我做过的东西，可能很有趣；这里有一些你可能想读的内容；如果你想聊聊，如果我能帮上忙，那我们就谈谈。这就是我网站的目标。所以，只要你能约到我的时间，或者雇我做些自由职业，看到我做过的东西，那我的问题就解决了。如果你想深入了解细节，还有更多东西可以挖掘，但故意不放在最显眼的位置。

You know, there are definitely points in time where I'm like, 'Oh, am I still a design engineer now? Am I moving away from this because I'm relying more and more on AI to solve problems for me?' But then I just have to keep coming back to the fact that the thing that makes me feel differently about stuff is that I make design decisions that an AI won't make. And there are times when I'll ask it to go off and do a thing and it's like I've done it and then I look at what it's done and I'm like, really? But then there's also times where I'll have thought of an idea that it wouldn't even think of. That's not complicated. We're talking simple stuff like my personal website. Some of the examples like the cards: when you hover over these ones, it's just taking the image that you've got here of the particular element and then placing it in the background, blurring it, and enlarging it. That's all I'm doing. And it's a simple, subtle, mostly pointless thing to do, but it just brings a bit of life to this moment. Yeah. And we do the same thing here on these music cards. It just takes the album artwork, places it above it, and then blurs it. And then you got these little music bars flying around. Unnecessary little details. They're things that will only show on desktop. You're not going to see this on mobile, which is always a problem with important interactions, but in this case, it's just the light, so it doesn't really matter. And I like to think of it as a way of giving people an opportunity to see that little 5-10% of, 'Oh, I just cared enough to decide to do that.' And I've tried to sprinkle little pieces of this throughout my site, but without trying to draw too much attention away from the focus of what I have it there for, which is: here's some stuff I've built that might be interesting, and here's some content that you might want to read, and if you want to chat and I can be useful to you, then let's talk. That's the goal of my website. So as long as you can book some time with me or hire me to do some freelance work and you can see the things I've done, then I've solved my problem. And if you want to dig into the details, there's more stuff you can go and find, but it's deliberately not super upfront.

我喜欢这个图片模糊效果，因为它并不难实现。我觉得除非我漏掉了什么，否则我很自信我能一次搞定，而且代码写法你会认可。但我也喜欢的是，这正好体现了你对创造力和工艺的双重定义。让它出色的不一定是工艺——代码很简单，但创造力很有趣，对吧？那个微妙的小细节，让它和你平时在网页上交互的普通卡片有所不同。而且你能同时兼顾这两者。我还在思考这作为设计工程师的定义，它真的引起了我的共鸣。

I like the image blur because it's not that hard to pull off. I think unless I'm missing something, I'm very confident that I could oneshot that in a way that you would approve of in terms of just the way the code is written. But I also like that that's how you have that two-part definition of creativity and craft. Like what makes that good is not necessarily the craft. The code's pretty easy, but the creativity, it's interesting, right? That subtle little detail that makes it a little bit different than your normal card that you would interact with on the web. And being able to spike in both of those. I'm just still thinking about that as a definition of a design engineer and it's really resonating.

我是说，之前在 Dive 上看到过一些人的作品集，非常有趣。表面上看，就是‘好吧，一些文字，一个 Bento 网格，行吧。’但就在你悬停的那一刻，卡片发生了变化，一些令人兴奋的事情发生了。就是那种对细节的关注，足够在意，以至于当有人访问那个网站并看到悬停效果时，他们会想：‘好吧，你为什么花时间做这个？你这么做是有原因的，这让我感兴趣。现在我想深入了解你。’我不是说我也做到了那个水平。我想我尽量保持克制，因为我在设计上更偏向极简。但我认为现在是时候开始添加一些小点缀了，那些感觉有趣而微妙的小瞬间，那额外的 10%。我以前没有意识到这一点，但我也觉得我可以在自己拥有的网站上做到这一点。也许是作品集。我有一阵子没有作品集了，但比如 Dive 网站，我痴迷于那些在 Framer 里的悬停细节和所有小东西。这几乎是我的一种自我表达。我还没能在作为日常工作一部分的产品中感受到这一点。但最近我刚刚开始得到一些这样的片段。而这只有通过能够在代码中打磨细节才能实现。我个人在 Figma 里感受不到那种感觉。我必须反复调整某些东西，反复玩悬停状态。我在想 Dive 网站上的剧集卡片。我在上面花了太多时间。但我喜欢它的感觉。这就是我想要的感觉。而在飞行产品中，我也开始能更多地做这样的事情：不，我可以痴迷于它的感觉，它可以成为我的一种表达。不是所有地方都这样。有些部分很糟糕，但有些部分真的很好。我的意思是，对于一个对设计工程这条路感兴趣的设计师来说，这是一个多么有趣的时刻，因为你可以在自己互联网的小角落之外获得那种感觉。

I mean, there's been examples before on Dive of people's portfolios that are super interesting. On the face of it, it's like, 'Okay cool, some text, a bento grid, all right.' And then it's that moment when you hover over that the card changes and something exciting happens. It's that little attention to detail of caring enough that when someone visits that site and has that rollover effect, they're going to be like, 'Okay, why did you put that time in? You did it for a reason, and that makes me interested. Now I want to dig in and find out more about you.' And I'm not saying I'm doing anything to that level. I think I've tried to keep things more restrained because I'm far more minimal when it comes to design. But I figured it was a good time to start adding some little touches, little moments that feel interesting and subtle, that 10% more. I haven't made this connection before, but I've also felt like I can do that on websites that I own. Maybe it's portfolio. I haven't actually had one of those for a little bit, but like the Dive website, I obsessed over those hover details in Framer and all the little things. And it was almost like an expression of myself. I haven't yet been able to feel like that about a product that I'm working on as a part of my actual day job. And I think I'm just getting little pieces of that recently. And it only comes with being able to sweat the details in code. I personally don't feel that in Figma. I have to be really massaging something and playing with the hover states repeatedly. I'm thinking about the episode cards on the Dive website. I spent way too long on those. But I like how it feels. This is what I wanted it to feel like. And I'm getting to do a little bit more of that with the inflight product where it's like, no, I can just obsess over how it feels and it can be this expression of who I am. Not everywhere. Some pieces suck, but some pieces are really good. And I mean, what a fun time to be a designer who was interested in this design engineering path because you can get that feeling outside of your own little corner of the internet.

当你谈到产品时，这很有趣。我认为这是一个非常不同的世界。对我来说，作为一家公司的设计工程师，我觉得在网上看到设计工程时的一个危险区域是，很容易陷入一个陷阱：认为成为一个伟大的设计工程师意味着你是一个出色的动画师，能够构建这些超级美丽的细节，让所有东西连接、变化和变形。而现实是，作为设计工程师，我们在日常工作中投入的大部分精力，远不是那些工艺细节，而是试图将设计意图转化为功能、美观、快速和高效的东西。

It's interesting when you talk about product. I think it's a very different world. For me as someone who is a design engineer at a company, I guess the danger zones of seeing design engineering online is it can be easy to fall into the trap of thinking that being a great design engineer means that you're an excellent animator and you can build these super beautiful details of how all these things can join and change and morph. And the reality is that most of the energy we put into stuff in day-to-day work as a design engineer is a lot less about those kind of crafty details and more about trying to translate design intent into something that is functional and beautiful and fast and efficient.

是的。

Yeah.

没错。尤其是当你做搜索引擎的时候，关键就是不要添加任何会造成速度瓶颈的额外东西。但当你得到那个机会说‘让我们添加那个微小的瞬间’时，比如我放进去的那个小小的变形按钮，或者那个‘更多’按钮的状态变化。

Right. Especially when you work on a search engine, it's all about not adding all of these extra things that are going to create any kind of speed blocks. But when you get that time to say, 'Let's add that tiny moment,' the little morphing button that I put in or the changes of state of that more button.

就是那些微小的时刻，我觉得自己拥有那种权威，或者说得到了许可，可以全力以赴，放手去做。因为我知道，我在边缘部分做的所有工作都是扎实的、高效的，它一定会奏效。所以我会投入时间让这些事发生，是因为我在乎、我希望它们存在，而不是因为有人指示我这么做。所以我认为，对于任何有志于设计工程的人来说，值得知道的是，没有人期望你必须成为动画大师，或者必须为你做的每件事都加入动效——虽然有时感觉好像是这样。

It's those little tiny moments where I'm like, I have the authority or like I have the permission to go all out and just go for it in those little moments because I know that all the things around the edges that I've worked on are sound and it's performant. It's going to work. And so I'm gonna put that time in to make those things happen because I care and I want them to be there, not because anyone's directing me to do so. So I think for anyone who is aspiring towards design engineering, it's worth knowing that there won't be an expectation that you have to be this master animator and that you need to be able to put motion into everything you work on because it can sometimes feel that way.

不，我觉得这点说得很好，我很喜欢“许可”这个词。我希望更多设计师能感受到那种许可。随之而来的，是对自己需要学习多少东西的认知。所以感谢你今天来做客，分享你在制作这门课程时思考的一些思维模型和策略。我们会在节目笔记里放上链接，供有兴趣深入了解的朋友参考。就我自己而言，仅从这次对话中，我就获得了一些非常实用的收获，以及可以开始融入自己实践的东西。所以感谢你今天来做客，Carlos。非常感谢。

No, I think that's a great point and I love the word permission. And my hope is that more designers are feeling that level of permission. I think with that comes the awareness of the amount that you have to learn. So I appreciate you coming on today and sharing some of the mental models and tactics that you're thinking about while making this course. We'll put the link in the show notes for anybody who's interested in going deeper. I know for myself, even just from this conversation, I've come away with some super practical takeaways and things that I can start to incorporate in my own practice. So I appreciate you coming on today, Carlos. Thanks so much.

嗯，谢谢邀请。

Yeah, thanks for having me.

在你走之前，我想花一分钟给你介绍一下我最喜欢的产品，因为总有人问我用什么工具。Framer 是我建网站的工具，Genway 是我做研究的方式，Granola 是我在评审会上记笔记的工具，Jitter 是我给设计加动效的工具，Lovable 是我用代码实现想法的工具，Mobin 是我找设计灵感的工具，Paper 是我像创意人一样设计的工具，而 Raycast 是我每一步的快捷方式。这些公司都是我精心挑选的，这样我才能全职做这些节目。所以，支持这个节目的头号方式就是去看看它们。你可以在 dive.comclub/partners 找到完整列表。

Before I let you go, I want to take just one minute to run you through my favorite products because I'm constantly asked what's in my stack. Framer is how I build websites. Genway is how I do research. Granola is how I take notes during crit. Jitter is how I animate my designs. Lovable is how I build my ideas in code. Mobin is how I find design inspiration. Paper is how I design like a creative and Raycast is my shortcut every step of the way. Now, I've hand selected these companies so that I can do these episodes full-time. So, by far the number one way to support the show is to check them out. You can find the full list at dive.comclub/partners.