用过不少AI设计工具之后，我一直有个疑问：如果不再生成一张张全新的界面，而是拿一个真实的设计项目来用，这些工具到底还能不能打？

从一句提示词生成一个漂亮的落地页，现在已经不算难事。但真正的考验是另一套流程：导入一个已有的设计，在不破坏它视觉语言的前提下做编辑，让AI智能体理解画布上的内容，再基于同一套设计系统创建另一个页面，最后把这个设计送进真实的React工作流。

打开网易新闻 查看精彩图片

这正是我想用Brilliant.design做的事。

从Figma导入真实作品集，而不是从空白画布开始

这次上手测试，我没有选择从零开始。我从Figma里挑了一个真实的开发者作品集，把它导入Brilliant。之后我手动在编辑器里调整，通过MCP接入OpenAI Codex，让Codex去检查和修改设计，再基于已有的设计系统创建第二个画布，同时测试了Brilliant内置AI配合Codex的效果，还试了它的Playground模式。

除了视觉编辑器，我也关注了Brilliant对开发者更重要的部分：设计系统、Blueprint语言、MCP工作流，以及设计转代码的选项。

先说结论里最让我喜欢的一点：AI不是只能生成一张设计图。画布上放着的是真正可编辑的设计元素，智能体可以检查它们，也可以修改它们。

这个差别对开发者来说很关键，因为设计从此可以进入和代码一样的AI辅助工作流。

AI设计工具的三层分化

在深入Brilliant之前，得先厘清“AI设计工具”这个词到底指什么。现在这个叫法被用在很多完全不同的产品上。

第一类基本是文生图生成器。你描述一个落地页、仪表盘、移动应用、标志或插画，工具给你一张视觉结果。

第二类更进一步，生成的是真正可以编辑的UI布局，你能移动、调整大小、重新设定样式，还能导出。

第三类则把AI智能体直接放进设计工作流里。在这种模式下，你可以让AI创建或修改设计的一部分，同时操作的仍然是真实的设计元素。

对开发者来说，真正有意思的是第三类。

有用的AI设计工具，不该只会生成好看的界面

一个真正有用的AI设计工具，不应该只是产出一张漂亮的界面。它还需要对几个关键问题给出响亮的“是”：能不能理解已有的设计系统？能不能在不破坏视觉语言的前提下修改？能不能把结果送进真实的代码流程？

这些差异在你做真实项目时会立刻显现。假设你已经有一个仪表盘，里面定义了字号层级、间距系统、按钮、卡片、颜色和组件。你绝不会想让一个AI工具把这些东西推倒重来，生成一套看起来不错但完全脱离现有体系的新界面。

Brilliant.design这次测试给我的感觉是，它正试图站进第三类工具的位置：让设计元素本身成为AI可以理解和操作的对象，而不是一张只能看的图。