如何用设计系统稳定生成高一致性UI界面，告别AI随机生图

时间：2026-08-16 16:40

为AI生成UI提供设计系统可显著提升一致性。用MoonChild构建设计系统（含令牌、组件、规范），导出后供ClaudeCode参照。对比十页仪表盘：无系统时仅2页首次符合品牌规范，AI自创19个色值；有系统后9页达标，色值零新增，样式调整时间从6小时缩至40分钟。

编者按：从 AI 生图兴起至今，“一致性控制”始终是困扰大量用户的核心难题之一。在 AI 生成 UI 设计与前端页面时，这个问题同样尤为明显。今天这篇来自推特用户 @Mnilax 的文章，分享了他如何借助 MoonChild 中的设计系统，辅助 AI 生成结构完整、风格统一、高一致性的作品。不仅有可直接参考的提示词，还总结了实操过程中的方法、技巧与注意事项，或许能帮助大家解决长期以来在 AI 生成界面设计中的一致性难题。下面是正文。

一、全文速览

后端开发一直都不算真正的难点——从认证、数据层到 API 路由，只要把需求描述清楚，Claude Code 基本都能较完整地承接并实现。真正麻烦的，往往是前端界面。AI 生成的每个页面单独看都能正常编译、功能也没问题，但放到同一个产品里时，整体观感却像是四个互不相识的人分别做完后硬拼在一起。

这其实未必是模型本身的能力问题。专注设计系统的工具 Moonchild 用一句话点出了关键：没有设计系统的团队，最终产出的往往只是“随机 UI”。

模型会在像素级别不断自行做决策，因为它缺少稳定的参照标准。颜色可能随手选，间距可能临时定，组件之间也缺乏明确关联和统一规则。

所以，解决方案就是先给它建立一套可执行的规范。作者用一个下午在 Moonchild 里搭建了一套设计系统，导出后再交给 Claude Code 作为输入。随后，他围绕同一个项目做了两轮对比实验——一个用于 AI 应用监控的中控分析仪表盘，共 10 个页面：第一次让 Claude Code 自由生成，第二次则要求它读取设计系统再输出。

结果非常直观：首次生成就符合品牌规范的页面数量，从 10 个里只有 2 个，提升到了 9 个；后续重新调整样式所需的时间，从大约 6 小时缩短到约 40 分钟；Claude Code 自行“发明”的一次性十六进制色值，也从 19 个直接降到了 0。

接下来会详细分享整个方法：哪些素材可以作为 AI 可读的设计系统输入、如何在 Moonchild 中构建设计系统并交给 Claude Code，以及具体可复用的提示词，还有作者在第一个下午实际踩过的三个坑。

如果你更想跳过原理部分，直接复制可用提示词，也可以直接拉到文末查看。

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

大多数 AI 设计工具，以及大多数使用 Claude Code 生成 UI 界面的人，实际工作流都差不多：你描述一个页面，AI 就生成一个页面，然后任务结束。

但问题通常从第二个页面就开始暴露。你继续描述下一个页面，AI 又会从零开始重新绘制，对上一次的设计决策几乎没有持续记忆，于是它只能再次重新判断。

新的蓝色，新的卡片圆角，新的间距逻辑。如果按照这种方式连续做 10 个页面，最后得到的并不是一个统一产品，而更像是 10 张恰好被放在同一文件夹里的独立设计稿。

Claude Code 本质上是一个非常优秀的执行工具。你说“帮我做一个设置页面”，它通常确实能给出一个可用的设置页面，这代表它在“把意图转成代码”这件事上做得不错。

但意图并不等于设计语言。一个功能完整、却和其他页面没有任何视觉关联的页面，本质上只是未来等待返工的技术债。因此，真正缺少的往往不是 AI 的落地能力，而是一个持续可引用、可执行的统一参照源。

你需要有一个地方明确规定：主色是什么、按钮长什么样、按钮有哪些状态、间距按什么比例走、什么场景用抽屉、什么场景该用弹窗。把这些设计规则明确告诉模型，它才不会继续自行脑补，而是按规范查阅和执行。

Moonchild 押注的正是这种思路变化：与其把设计系统视为可有可无、事后再补的东西，不如直接把它变成约束每一次 AI 生成的前提条件，从第一个页面开始就生效。

这正是“一个会画页面的工具”和“一个能够构建连贯产品体系的工具”之间最关键的差别。

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

如果把设计系统作为代码工具或 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 na vy 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 用的仪表盘”。最终生成的是一套几乎任何互联网产品都能套上的通用设计系统，换句话说，它并没有真正解决问题。

而上面这个重写后的版本，则明确了信息密度、强调色、字体选择以及具体组件类型，因此产出的才是一套真正能落地、能指导后续 UI 生成的系统。提示词越具体，设计系统越可用，这几乎就是全部秘诀：模糊提示词只会得到模糊系统，而模糊系统又会让 AI 在下一层继续猜测。

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

在项目内使用“添加设计系统”后，这套设计系统会直接约束此后的每一次页面生成。从这一刻起，AI 绘制的每个页面都会参考你的设计令牌 / Token，而不再是每次都重新自行发明样式。

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 na v, cards, and chart styles consistent across all ten.
使用已上传添加的设计系统生成仪表盘的 10 个核心页面：概览、模型成本列表、延迟、Token 用量、Agent 状态、报错信息、单个 Agent 详情、设置、账单，以及空状态/首次运行页面。保持导航栏、卡片和图表样式在所有十个页面上的一致性。

关键经验在于：同样是重建这 10 个页面，带设计系统约束时，有 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. 保持构建规则，防止设计系统偏移

下载下来的设计系统，只有在每一次任务中都被真正引用和执行时，才有实际意义。只要某个页面跳过了这套系统，它就会立刻回到“随机生成 UI”的状态。

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 先参照设计系统。

因此，只要在项目级提示词里一次性加入这条常驻规则，问题通常就能明显减少。设计系统不是一次复制粘贴后就结束的内容，而是整个 AI 生成流程里必须持续遵守的设计规范。

对于 Cursor，方法其实完全一样，一句话就够：把下载好的设计系统放进项目，然后告诉它“按我们的设计系统构建”。这样编辑器中的 AI 就会把 Token / 设计令牌和使用规范当作产品规格来读取。

五、两次构建的数据对比

同一个 10 页仪表盘，作者完整构建了两次。第一次让 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

这里最值得关注的，其实不只是节省了多少时间，而是整个工作的性质发生了变化。

没有设计系统时，大量时间都浪费在样式返工上：微调颜色、修正间距、事后让第 7 个页面和第 2 个页面尽量统一。

而有了设计系统之后，这些工作只需要做一次，并且是在系统层面完成，后续每个页面都不需要重复返工。你不再是在做零散的像素级修补，而是在修改规则，并通过一条规则同步修正所有页面。

六、第一个下午踩过的坑

那个下午基本都在摸索：一个真正可用的 AI 设计系统，究竟需要具备哪些前提条件。

1. 用 PNG 导入。作者曾尝试用旧项目截图初始化系统，但 Moonchild 读取的是结构化信息，因此 HTML 和 Figma SVG 能提供真实的 Token / 设计令牌与层级关系，而 PNG 只是需要被猜测的一张图片。最终结果是：PNG 导入得到的只是粗略近似，SVG 导入才更接近真实样式。

2. 提示词太笼统。过于宽泛的提示词根本无法形成有效约束，它只是把 AI 猜测的层级往上挪了一层，并没有真正减少 AI 的自由发挥。

3. 页面可能绕过设计系统。前面提到的样式偏移就是这种情况：某个页面没有参考设计系统，就直接被生成出来了。“写之前先检查系统”这条规则，才是让设计系统真正生效的关键。

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

当然，设计系统作为输入也不是万能方案，它仍然存在 3 个客观限制。

1. AI 生成结果依旧需要审查。Claude Code 在依据设计系统构建页面时，确实会更快，也会更统一，但它本质上仍然是在生成代码。你依然需要测试、审查，并把它视作高质量初稿，而不是可以直接上线的最终成品——特别是在交互逻辑和业务逻辑层面。

2. 系统质量取决于前期投入。如果 Moonchild 里的设计系统本身内容很薄、过于泛化，那么导出的结果同样会很薄，后续所有下游工具都会继承这个问题。原本花在样式返工上的时间，只是被前置成了“提前构建一套真正有用的设计系统”。这当然更值得，但也绝不是零成本。

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

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

整体流程其实很清晰：三个提示词，加一次下载。先构建设计系统，再下载系统，最后移交给 Claude Code、Cursor 等代码工具使用。

# 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 na v, 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.