Transcript
00:00:00如果你关注这个频道一段时间了，你可能知道我们涵盖了许多
00:00:03设计工作流和工具。我们对它们进行了数月的测试，终于弄清楚了
00:00:08为什么同一个模型有时能生成看起来完全定制化的内容，而有时却给人一种
00:00:13浓厚AI生成感的感觉。这归结于三个层级。第一级是设计单页，
00:00:19这里大多数人会忽略一点，而这正是他们的输出看起来平庸的根本原因。第二级
00:00:23是你不再局限于设计页面，而是开始设计系统，这里的工作流
00:00:28完全不同。第三级则是我们如何对照测试各种设计，以找到
00:00:34真正起作用的版本，这也是我们现在每个实际项目都会用到的方法。所以第一级是关于
00:00:39为单个页面创建优秀的设计。这是大多数人都在教的层级，因为它是
00:00:44每个优秀设计的基础。我们在之前的视频中讨论过 Opus 4.7 的设计
00:00:50能力有了多么显著的提升，过去常见的好多 AI 平庸感已经消失了。早些时候，当我们
00:00:55给它一个简单的提示词（比如创建一个落地页）时，它通常会直接采用
00:00:59紫色和白色的主题，并围绕它构建一切。这种特定的模式已经有所改善。但
00:01:04就像任何其他 AI 模型一样，这个模型也会收敛到安全的模式。通过我们对它的所有测试和
00:01:09实验，我们发现它每次都会默认使用某种特定的风格。所以现在，每当我们
00:01:15看到这种风格，就能一眼看出这个网站来自 Opus 4.7，而且这迟早会沦为
00:01:21下一批 AI 平庸之作。因此，我们需要其他方法来让这个网站看起来更好。
00:01:25现在这一层主要取决于提示词工程以及我们如何指定应用，因为
00:01:30如果你正确构建提示词，就可以直接一次性生成整个应用。提示词应该以
00:01:35你想要构建的网站意图开始，然后提及不可妥协的条件，例如
00:01:39你在应用中确切想要的内容以及你希望 UI 元素呈现的外观。之后，你指定
00:01:44色彩系统。在这里，我们使用 OKLCH，它基本上是亮度、彩度和色相的度量。
00:01:49使用 OKLCH 而不是通常的 RGB 或 HSL 更好，因为它能以
00:01:55人眼实际感知的方式来表示颜色，因此它能更好地处理亮度和平衡。它还能创建
00:01:59更平滑的渐变，不像十六进制代码那样容易产生看起来不均匀的渐变。一旦你
00:02:04设置好了配色方案，你还需要提及对比度流程。对比度是 UI 设计中
00:02:08一个非常重要的因素，因为它实际上创造了一种层级结构，引导你的视线投向
00:02:13重要的事情。如果没有明确的对比度，模型会把每个元素视作同等重要，
00:02:18这使得很难形成视觉层级。为了确保网站看起来不像
00:02:22AI 平庸之作，你还必须从提示词中控制排版，从而定义哪些字体因
00:02:27AI 平庸化而被禁用，以及在设计的不同区域应使用哪些字体。像 Inter 和 Geist
00:02:33这样的字体已经成了 AI 平庸感的标志，因为每个智能体默认都会选用它们，所以明确点出它们
00:02:38会迫使模型去寻找其他选择。然后你定义网站的布局和节奏，
00:02:42但首先你需要了解对称与不对称。对称的布局让组件
00:02:47components
00:02:51evenely placed on the grid with a balanced look, which is more suited toward professional and
00:02:56straight designs. But for a more artistic look, go for asymmetry because that gives you more room
00:03:01to experiment. It is especially good when you need to use negative space since that lets the design
00:03:06breathe. The kind of product you are building decides which one fits better. Then define all the sections
00:03:11that you want, the materials you'll use, and how the website should behave responsively. And the most important
00:03:17part is mentioning the anti-patterns. These are the hallmarks of AI slop like the simple centered CTA,
00:03:22Lucid icons, and gradients with glassmorphic design. So once you give this prompt to Claude Code or
00:03:27whichever agent you are using, it will analyze your app and go through the implementation details. Then it will
00:03:34build the app just like the prompt described, with asymmetry because of the artistic goal and proper use of negative space.
00:03:40So level 2 is about keeping the same design across every page of the site because most agent generated apps
00:03:45fall apart the moment you leave the landing page. Often when generating whole apps with agents, you might
00:03:50have encountered exactly this. The landing page is mostly pretty good, but when you go to the other pages,
00:03:55they don't follow the UI style as coherently as they should. The dashboard ends up with different
00:04:00button styles, different spacing, different typography, almost like the agent forgot it was building the
00:04:05same app. The other pages end up looking like they're not even a part of the same site and it gives away
00:04:10that the site was generated by an agent. Sometimes the design does hold on the auth pages, but then on
00:04:15the dashboard, the style breaks completely. So for that, you need to create two of the most important
00:04:21files, Claude.md and Design.md. These two files are what keep the design consistent across the whole site.
00:04:27In Claude.md, as we've talked about many times, you only put your project information, not the design.
00:04:32This is because the file stays loaded in the session all the time and design content there will just
00:04:37distract the agent when it's working on something else, but it's still the key file because it keeps
00:04:42the context of the project which informs good design. For the design itself, we need a separate file
00:04:47which mentions everything for the visual system, the layout, the colors, the typography and all the
00:04:52details we covered in level 1. The design.md should be the kind of file that any agent could pick up and
00:04:57immediately understand what the visual system is. And just like in the previous level, you need to
00:05:03define the color system in OKLCH here too. To create these two files, we gave Claude code a detailed
00:05:09prompt covering what each file needs and it generated both files for us. The Claude.md is short, just
00:05:15containing the project's details. The design.md is longer with each and every detail, including color codes,
00:05:20typography choices, and everything else. But that isn't the end of the design.md. We need to keep
00:05:25refining it over time. So we put a line at the start, telling the agent to add any new design value
00:05:30it finds to this file. That way, every session starts from a more refined version of the design
00:05:35system than the one before it. But just letting Claude create the design.md isn't enough,
00:05:40because what it generates doesn't follow best practices properly. Google has open-sourced their
00:05:46template for the design.md file. The template also contains commands to cross-verify your design.md
00:05:51against it and flag any errors. So you can just prompt your agent to iterate using those commands
00:05:56to perfect the design.md. And this still isn't the end of level 2. To generate good enough designs at
00:06:00this level, you also need to audit them against existing design principles. For that, there are
00:06:06many open-source skills that do exactly this. You can use any of them, but we use VersaLab's skill,
00:06:11because instead of hard-coding all the principles inside the skill, it points to an external source
00:06:16that they're actively maintaining. So the principles stay up to date with current best practices instead
00:06:21of being frozen at whatever was state-of-the-art when the skill was first written. You install this skill
00:06:25in the project, run it, and your design comes out in way better shape than it was before. But before we
00:06:30move forwards, let's have a word by our sponsor. So I recently started using ZillysCloud and let me tell
00:06:35you why. Most RAG apps work fine with a handful of docs, but the moment you throw in real data,
00:06:40they start falling apart because the setup just wasn't designed to handle that kind of load.
00:06:46Milvus is the most starred open-source vector database on GitHub with over 44,000 stars,
00:06:51and it's built to handle that kind of load, but self-hosting means managing infrastructure yourself.
00:06:56So that's where ZillysCloud comes in, the fully managed version with the same API that's up to
00:07:0010 times faster, and you can set it up in minutes without changing a single line of code.
00:07:05So we ran a semantic search query on ZillysCloud, and the results are actually relevant because it
00:07:11understands meaning not just keywords, and the response time is almost instant even with a large
00:07:16dataset. We also ran a recommendation query given one article. It found the five most similar ones
00:07:21across the entire dataset ranked by similarity in under a second. And the dashboard tracks your cluster
00:07:27无需信用卡，只需点击置顶评论中的链接即可免费体验 ZillysCloud。
00:07:31So level three is about testing the design programmatically, the same way engineers verify
00:07:36code with TDD. Now we know you can't visually write tests the way you do with code. With code,
00:07:41there are clear inputs and outputs for everything. Design doesn't have that because it's more subjective
00:07:46and can't be quantified like code can, but just because it's subjective doesn't mean we can't write
00:07:51tests for it. The reason TDD works for code is that the test pins down what the behavior should be,
00:07:57and the implementation has to satisfy that pin. The same idea applies to design just with different
00:08:01kinds of pins. In the app we were building, the first step was the same as before, to create the
00:08:05clod.md and design.md files before even thinking about implementation. Now tests should always be
00:08:12written before the code, that way the implementation can actually be tested against them. If we write tests
00:08:17after the implementation, the agent slacks off. It just writes test cases that optimize toward the
00:08:22existing code, because that code is already in its context. Writing the test first forces the
00:08:27implementation to fit the test instead of the test fitting the implementation. So we use the design
00:08:32files as the source of truth for the tests because these files contain all the anti-patterns that we can
00:08:37programmatically verify against. Every anti-pattern in design.md becomes a test case. Every color rule,
00:08:44every spacing constraint, every typography choice gets a programmatic check. We gave Claude Code a
00:08:49detailed prompt to write the test cases specifying every section it should focus on. Also if you are
00:08:54enjoying our content, consider pressing the high button because it helps us create more content like
00:08:59this and reach out to more people. With your prompt, it will write all the test cases for the design
00:09:04of the app. It writes multiple types of tests. There are the static tests, which directly check for the
00:09:09anti-patterns we mentioned in the prompt. Then there's the visual testing, which basically uses
00:09:14play right underneath and runs regression testing to make the site incrementally better. It will also
00:09:19write test cases for other components and helper functions like scan and report. Now these tests
00:09:24check for the static anti-patterns, but design testing needs something else. For that, there is
00:09:28another tool called Visly Test, which is basically a CLI that conducts TDD for UI. The way it works is
00:09:34that it runs local TDD, where you can check the design as the code changes. So you can monitor the
00:09:39diffs yourself instead of relying on the agent's self-monitoring. You also get a better diff with
00:09:44metadata and other details, which makes review faster. Without that metadata, you are just comparing two
00:09:49screenshots side-by-side and hoping you spot the difference. With it, Visly tells you exactly which
00:09:54pixels changed and by how much. To use it, first install the CLI by running the install command from the
00:10:00docs. Once it's set up and initialized, it's ready to go. Now just open Claude code and tell it to use
00:10:05TDD and implement whichever part of the UI you want using the Visly CLI as the testing medium. When
00:10:10you run the Visly TDD command, a local server starts and monitors the screenshot changes. To send the
00:10:16screenshots, Claude basically writes separate tests with the name Visly. These tests use playwright
00:10:21screenshotting mechanisms to push the images to the viewer on the server. From there, you can approve or deny the
00:10:27design and view diffs comparing it to the previous version. Each rejected diff becomes feedback the
00:10:32agent uses to adjust the next pass. Over a few iterations, the design converges to what you actually
00:10:37want instead of what the agent thinks you want. Now the prompts used here can be found in AI Labs Pro
00:10:43for this video and for all our previous videos from where you can download and use it for your own
00:10:47projects. If you've found value in what we do and want to support the channel, this is the best way to do it. The
00:10:52links in the description. That brings us to the end of this video. If you'd like to support the channel
00:10:57and help us keep making videos like this, you can do so by using the super thanks button below. As
00:11:02always, thank you for watching and I'll see you in the next one.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video