别再让AI随机生图了！教你用设计系统稳定生成高一致性UI界面！

编者按：一致性控制可能是从 AI 生图开始到现在，困扰着所有人的问题。在 AI 生成 UI 上，这类问题同样突出。今天这篇来自推特用户 @Mnilax 的文章，分享了他使用 MoonChild 中的设计系统，来辅助他生成成体系、高一致性作品的经验，他不仅提供了提示词，还有使用过程中的技巧和注意事项，应该可以帮助各位同学解决一直以来的巨大困扰。下面是正文。

一、全文速览

后端开发对我来说通常不是大问题，从认证、数据层到 API 路由，我只需描述需求，Claude Code 基本都能一手包办。前端才是真正让我头疼的地方。而且 AI 生成的每个页面单独都能编译通过、功能正常，只是看起来像是四个素不相识的人各自独立完成的。

这不是模型的问题。专注于设计系统的工具 Moonchild 用一句话道破了症结所在：没有设计系统的团队产出的只是「随机 UI」。

官方网站：https://moonchild.ai/

模型在像素层面逐一做决策，因为它没有别的参照。颜色随手一选，间距随缘定个值，所有元素之间毫无关联。

于是我给它建立了一套规范。我用一个下午在 Moonchild 里构建了一套设计系统，导出后交给 Claude Code 作为输入。然后用同一个项目做了两次对比实验，是供 AI 应用监控的中控分析仪表盘，共十个页面：一个是让 Claude Code 自由发挥，一个是让它读取设计系统。

结果一目了然：首次生成即符合品牌规范的页面，第一波 10 个里只有 2 个，加上约束之后符合标准页面的提升到了 9 个；重新调整样式所需的时间从约 6 小时缩短至约 40 分钟；Claude Code 自行发明的一次性十六进制色值从 19 个降为 0。

接下来我会为给你分享这个过程，哪些素材可作为输入的设计系统、构建设计系统并移交给 Claude Code ，以及具体的提示词，还有我第一个下午踩过的三个坑。

如果你想跳过原理说明直接复制粘贴我的提示词，那么可以直接跳转到文末。

二、为什么每个页面都长得不一样？

大多数 AI 设计工具，以及大多数用 Claude Code 生成 UI 的人，工作方式都一样：你描述一个页面，AI 画出一个页面，完事。

但是问题在第二个页面就暴露了。你描述下一个页面，AI 又会从零开始绘制，对上一次做过的决策毫无记忆。于是它又重新做决策。

新的蓝色。新的卡片圆角。新的间距思路。如果你按照这样的方式做十个页面，你得到的不是一个产品，而是十张碰巧存在同一个文件夹里的设计稿。

Claude Code 是个真正优秀的执行者。「帮我做一个设置页面」，你就能得到一个可用的设置页面，这是将意图转化为代码的正确操作。

但意图不是设计语言，一个功能完善却与其他页面毫无关联的页面，不过是日后等待返工的技术债。所以，真正缺失的从来不是 AI 的执行落地能力，而是一个可靠的参照源。

所以，需要一个地方明确地规定：这是主色，这是按钮，它有这四种状态，这是间距比例，以及什么情况下用抽屉而不是弹窗。把这些告诉模型，它就不再自我发明，而是照章查阅。

Moonchild 押注的正是这种思路转变：与其把设计系统当成可有可无、事后补上的东西，不如让系统成为约束每一次生成的先决条件，从第一个页面起就开始生效。

这就是一个「会画图的工具」和一个「能构建连贯成体系产品的工具」之间的关键差异。

三、用来输入给 AI 的设计系统

作为代码工具的输入组件，设计系统应该是一个可供移植的体系，包含三个部分：

• Token（设计令牌）：你的实际颜色、间距和字体比例。
• 组件：你的按钮，含各种变体和状态。
• 规范：这些元素组合使用的规则。

在 Moonchild 里，它被组织成几个板块：基础、主题、样式、组件、规范、画廊和资产。在我的这篇文章，关键在于你可以将整套设计系统，导出为代码工具能够读取的格式。

这是是最核心的关键。截图只能让 Claude Code 去猜测，但是 设计令牌/Token 包则让它有据可查。同一个模型，输出截然不同的结果，因为前者给了它一张待解读的图片，后者给了它一套必须遵守的系统。

将系统导入 Moonchild 有两条路：导入已有系统（它对 HTML 和 Figma SVG 的解析效果最佳，PNG 最差，因为结构优于像素），或者从对话中的简报/提示词开始构建。

我是从简报/提示词开始构建的，所以下面展示的是这条路径。

四、端到端的构建过程

4.1. 从提示词出发构建系统

在 Moonchild 中，「新建项目 -> 新建设计系统」会进入一个对话界面，你在描述的过程中设计系统会同步生成。输出质量几乎完全取决于你所撰写的简报/提示词的质量。

build a design system for a dark-first analytics dashboard for an AI engineering tool. deep navy surface, one high-contrast accent for primary actions, Inter for everything, high data density, generous use of charts and status pills. components: cards, data tables, tabs, status badges, KPI tiles. include guidelines for when to use a drawer vs a modal and how empty and loading states look.

为一个 AI 工程工具的分析仪表盘构建设计系统，以深色为主。深海军蓝背景，主要交互使用一个高对比度强调色，字体全部使用 Inter，数据密度高，大量使用图表和状态标签。组件包括：卡片、数据表格、标签页、状态徽章、KPI 指标模块。包含抽屉与弹窗的使用规范，以及空状态和加载状态的设计规范。

关键经验： 我的第一版简报只有简单的要求——「给 AI 用的仪表盘」。我得到的是一套任何互联网产品都能套用的通用设计系统，也就是说，它其实什么问题都没解决。

而上面这个重写版本，明确了信息密度、强调色、字体和具体组件，才产出了一套真正能用来构建的系统。提示词要具体，就是全部的秘诀：模糊的提示词得到模糊的设计系统，模糊的设计系统让 AI 在下一层继续猜测。

4.2. 附带系统生成，而非事后补救

在项目内，「添加设计系统」会用你的设计系统约束此后的每一次生成。从这时起，AI 绘制的每个页面都参照你的 设计令牌/Token，而不是每次都 AI 自己发明。

generate the 10 core screens for the dashboard using the attached design system: overview, cost-by-model, latency, token usage, agent status, alerts, a single-agent detail, settings, billing, and empty/first-run. keep the nav, cards, and chart styles consistent across all ten.

使用已上传添加的设计系统生成仪表盘的 10 个核心页面：概览、模型成本列表、延迟、Token 用量、Agent 状态、报错信息、单个 Agent 详情、设置、账单，以及空状态/首次运行页面。保持导航栏、卡片和图表样式在所有十个页面上的一致性。

关键经验： 同样重建这十个页面，9 个在首次生成时就符合品牌规范，而没有设计系统约束时能达标的只有 2 个。相同的提示词力度，相同的模型。

导航栏在每个页面上都完全一致。KPI 指标模块使用了同一种卡片样式，而不是五种不同的。图表共享同一套颜色体系。我不再需要逐一调整样式，只需要做一下审查——这是一种截然不同且省时得多的工作方式。

4.3. 下载系统并移交给 Claude Code

「发布」按钮旁边有一个下载按钮，可以将整套设计系统——Token、组件规范、使用规范、资产——以外部工具可读取的格式导出。这份导出文件就是你交给 Claude Code 的东西。

here is our design system (attached). build the cost-by-model screen as a React component. use only the tokens, components, and spacing defined in the system. do not introduce new colors, radii, or font sizes. if something isn't covered by the system, stop and ask instead of inventing it.

这是我们的设计系统（已添加）。将 cost-by-model 页面构建为 React 组件，只使用设计系统中定义的 Token、组件和间距。不得引入新的颜色、圆角或字体大小。如果系统未覆盖某项需求，请停下来询问，而不是自行发明。

关键经验： 第一次构建这个页面时没有设计系统，Claude Code 在整个项目中发明了 19 个十六进制色值——一些与我的品牌色相近却始终不一致的灰色和强调色。

添加设计系统并加上那一条指令——「不得引入新颜色，遇到问题请询问」——之后，它完全遵照 Token 执行，不再自主创造任何一个计划外的色值。「请询问」这个要求真正起了作用：它将模型自动填补空白的本能，转变为主动标记问题的本能。

4.4. 保持构建规则，防止设计系统偏移

下载的设计系统只有在每个任务都真正参照它来执行时才有意义。某个页面跳过了它，那个页面就立刻回到随机猜测的状态。

for every new screen or component in this project, reference the attached design system first. before writing any color, spacing, or type value, check whether the system already defines it. flag any case where the design doesn't cover what you need.

本项目中每个新页面和组件，都必须首先参照添加的设计系统。在写任何颜色、间距或字体值之前，先确认系统是否已有定义。标记出所有设计系统未覆盖到的情形。

关键经验： 我确实有一个页面出现了偏移——色标不对、圆角不匹配——因为我在描述时太仓促，没有让设计系统指向 Claude Code。

在项目级别的提示词中，一次性加入上面这条常驻指令，就可以解决问题。设计系统不是一次性粘贴的东西，它是整个构建过程必须持续遵守的规则。

对于 Cursor，方式完全相同，一句话搞定：将下载的系统放入项目，告诉它「按照我们的设计系统构建」，编辑器里的 AI 就会将 Token /设计令牌 和规范作为规格说明来读取。

五、两次构建的数据对比

同一个十页仪表盘，构建了两次。一次 Claude Code 依靠描述工作，一次以设计系统为输入。变化情况（无系统 → 有设计系统）：

Screens on-brand, first generation: 2 of 10 -> 9 of 10
Restyle time across the build: ~6 hr -> ~40 min
One-off colors the AI invented: 19 -> 0
Brand drift across screens: constant -> none

这里最关键的不是节省了多少小时，而是工作性质的转变。

没有设计系统时，我的时间都花在了调整样式上：微调颜色、修正间距、事后让第七个页面和第二个页面对齐。

有了设计系统，这些工作只需做一次，在系统里完成，之后每个页面都不必再重复。我不再是做像素级调整，而是在修改规则，通过一条规则同时修正所有页面。

六、第一个下午踩过的坑

那个下午基本上是在摸索系统究竟需要具备哪些条件才能真正有用。

1. 用 PNG 导入。 我尝试用旧项目的截图来初始化系统。Moonchild 读取的是结构，所以 HTML 和 Figma SVG 能为它提供真实的 Token /设计令牌 和层级关系，而 PNG 只是一张需要猜测解读的图片。PNG 导入的结果是一个粗略的近似版本，SVG 导入的结果才接近我的实际样式。

2. 提示词过于笼统。 太过笼统的提示词约束不了任何东西，只是把 AI 猜测的层级往上移了一层，而不是消除了AI 的自我发挥。

3. 会有页面绕过设计系统。 前文提到过偏移的情况，有一个页面没有参考设计系统就直接出了页面。「写之前先检查」这条规则，才是让它真正起作用的关键。

七、设计系统解决不了的问题

存在 3 个客观限制，因为设计系统作为输入并非万能。

1. AI 生成的结果仍需要审查。 Claude Code 依据你的系统构建会更快、更一致，但它仍然是在生成代码。你一定要测试它、审查它，把它当作初稿而非成品——尤其是在逻辑层面。

2. 系统的质量取决于你的投入。 如果 Moonchild 里的设计系统内容单薄或过于通用，导出物同样单薄，所有下游工具都会继承这一缺陷。原本花在重新调整样式上的时间，变成你提前构建一套真正的系统。这是更值得的投入，当然它并不是免费的。

3. 规则不会自我执行。 常驻的提示词指令是有帮助的，但在团队协作中，代码审查仍然需要，你得检查页面是否使用了 Token/设计令牌，而不是看起来差不多却写死的色值。

八、完整的流程，可直接复制

三个提示词加一次下载。构建设计系统，然后下载系统，最后移交给代码工具。

# 1. 构建系统（Moonchild：新建项目 -> 新建设计系统）
为 [用一句具体的话描述你的产品] 构建一套设计系统。
背景色和强调色：[具体说明]。
字体：[字体名称]。
密度：[低/高]。
组件：[列出你实际使用的组件]。
包含抽屉与弹窗的使用规范，以及空状态和加载状态的设计规范。

# 2. 附加设计系统生成页面（项目 -> 添加 DS）
使用已附加的设计系统生成 [N] 个页面：[列出页面]。
保持导航栏、卡片和核心组件在所有页面上的一致性。

# 3. 下载系统（「发布「旁边的按钮），然后在 Claude Code 或 Cursor 中：
这是我们的设计系统（已附加）。使用系统中定义的 Token、组件和间距构建 [页面/组件]。
不得引入新的颜色、圆角或字体大小。如果系统未覆盖某项需求，请停下来询问，而不是自行发明。

# 4. 设为常驻规则，防止漂移
每个新页面或组件，都必须首先参照附加的设计系统。
在写任何颜色、间距或字体值之前，先确认系统是否已有定义。标记出所有未覆盖的情况。

# 1. build the system (Moonchild: New Project -> New Design System)
build a design system for [your product in one specific sentence]. surface and accent colors: [specifics]. type: [font]. density: [low/high]. components: [list the ones you actually use]. include guidelines for drawer vs modal and for empty and loading states.

# 2. generate screens with it attached (project -> Add DS)
generate [N] screens using the attached design system: [list screens]. keep nav, cards, and core components consistent across all of them.

# 3. download the system (button next to Publish), then in Claude Code or Cursor:
here is our design system (attached). build [screen/component] using only the tokens, components, and spacing it defines. do not introduce new colors, radii, or font sizes. if the system doesn't cover something, stop and ask instead of inventing it.

# 4. set it as a standing rule so it doesn't drift
for every new screen or component, reference the attached design system first. before writing any color, spacing, or type value, check whether the system defines it. flag anything it doesn't cover.

九、从 Moonchild 开始

在 Moonchild 中：新建项目 -> 新建设计系统。你有两条路：

• 「让我们帮你导入」：由 Moonchild 团队（通常在一天内）通过通话，将你现有的系统从 Figma、Storybook 或代码库干净地迁移到工具中。
• 「自己构建」：进入对话界面，用提示词从头构建，也就是上面展示的那条路。

两条路最终落在同一个地方：一套结构化的系统，可以通过「添加 设计系统」添加到任意项目，并通过「发布」旁边的按钮下载。

版本控制已内置：每次发布都是一个新版本，可以随时回滚，所以对系统的探索和修改毫无成本。

十、不要只向 AI 索要页面

你一直在向 AI 索要页面。页面是输出物。索要十个，你得到十个毫无关联的输出——因为没有任何东西将它们连接在一起。

换一种方式：交给它一套设计系统，你改变的是你给它的东西：不再是一个请求，而是一份契约。

Token/设计令牌、组件、规范——那些以机器可以遵守的语言，说明「你的产品」是什么样子的东西。每一个依据这份契约生成的页面都属于同一个产品，因为它们都是对同一个可靠来源的引用，而不是十次各自为战的随机猜测。

这就是核心转变，也是为什么这本质上不是一项设计技能。你不需要懂得如何平衡字体比例，或选出对视障用户友好的色板。

你只需要用一个擅长于此的工具，把系统构建一次，然后让每一次生成都从它那里读取规范。设计从来不是难题，难题在于初始的空白状态，那个本该存在设计系统缺位了。