我可以一个下午就搭建好后端：认证、数据层、API 路由，Claude Code 在我描述需求时就能处理所有事。前端的部分才是真正让人头疼的。每个界面都能编译、能运行，但看起来就像四个不同的人各自拼凑了一部分，彼此之间完全没见过面。
这不是模型的问题。Moonchild，这个以设计系统为先的工具，用一句话就点明了问题：没有设计系统的团队，最终只会得到"随机 UI"。
模型之所以会在像素层面自行发挥，是因为它没有其他可参照的标准。它在这里挑个颜色，在那里选个间距，但这些元素之间毫无关联。
所以我给模型设定了一个标准。我用 Moonchild 花了一个下午构建了一套设计系统，下载下来，然后交给 Claude Code 作为输入。接着，我用同一个项目——一个用于监控 AI 应用的通用分析仪表盘，共十个界面——重建了两次：一次让 Claude Code 自由发挥，另一次让它基于我提供的设计系统来构建。
结果对比：首次生成就符合品牌风格的界面从 2/10 提升到了 9/10。调整样式的时间从 大约 6 小时减少到了大约 40 分钟。Claude Code 自行编造而非重复使用的单次十六进制颜色值从 19 个降到了 0 个。
下面，我会介绍：作为输入的设计系统到底是什么，构建并将其交给 Claude Code 的精确提示词，以及浪费了我第一个下午的三个错误。
如果你想跳过说明直接复制使用，完整的流程在文章末尾。
为什么每个界面看起来都不一样
大多数 AI 设计工具，以及大多数向 Claude Code 提供 UI 提示的人，工作方式都如出一辙：你描述一个界面，AI 画出一个界面。完成。
问题在第二个界面就暴露了。你描述下一个界面，AI 从头开始画，但它根本不记得第一次做过的决策。所以它会重新决定。
一个新的蓝色。一个新的卡片圆角。一个关于间距的新想法。将这种情况乘以十个界面，你得到的就不是一个产品，而是恰好放在同一个文件夹里的十张独立画作。
Claude Code 是一个真正优秀的执行者。"给我建一个设置页面"——它会给你一个能正常工作的设置页面。这是一个将意图转化为代码的正确工具。
但意图本身并不是设计语言，一个能正常工作但与其他界面格格不入的页面，依然是等待返工的重灾区。缺失的从来不是技能，而是一个唯一的事实来源。
这个来源需要明确说明：这是主色、这是按钮、这是按钮的四种状态、这是间距比例、以及何时该用抽屉而非模态框。把这个交给模型，它就不再自行编造了。它会去参照。
Moonchild 的全部目标就是彻底扭转这种默认状态。它把设计系统从可选的后缀升级为塑造每一次生成结果的约束条件，从第一个界面开始。
这就是一个"画画"的工具和一个"构建一致产品"的工具之间的全部区别。
作为输入的设计系统到底是什么
作为代码工具的输入，设计系统是一个可移植的包，包含三部分：
- Token：你实际使用的颜色、间距和字体比例。
- 组件：你的按钮，以及它的变体和状态。
- 指南：这些元素如何组合的规则。
在 Moonchild 中，它被组织成几个部分：基础、主题、样式、组件、指南、图库和资源。对本文而言，关键点在于你可以将整个系统导出为代码工具能够读取的格式。
这就是关键所在。一张截图会让 Claude Code 去猜测。一份 Token 包则会让它去参照。相同的模型，完全不同的输出，因为你提供给它的是一个需要遵守的系统，而不是一张需要解读的图片。
你可以通过两种方式将系统导入 Moonchild：导入现有系统（最佳读取 HTML 和 Figma SVG，最差读取 PNG，因为结构优于像素），或者通过在聊天中根据需求概要创建。
我选择从需求概要创建，所以我将展示这一路径。
端到端的构建流程
1. 从需求概要构建系统，而非凭感觉
在 Moonchild 中，"新建项目" -> "新建设计系统" 会进入一个聊天界面，系统会根据你的描述逐步构建。最终产出的质量几乎完全取决于你提供的需求概要的质量。
1为一个 AI 工程工具构建一套以深色为主的仪表盘设计系统。深蓝色界面主色，主操作按钮使用一种高对比度强调色，所有文字使用 Inter 字体，数据密度高，大量使用图表和状态标签。需要这些组件：卡片、数据表格、选项卡、状态徽章、KPI 指标块。包含何时使用抽屉 vs 模态框的指南，以及空状态和加载状态的展示方式。
关键点： 我最初的需求概要只有四个字——"一个 AI 仪表盘"。结果我得到了一个通用系统，它可以属于互联网上的任何产品，也就是说，它什么都没解决。
上面经过修改的概要——明确了密度、强调色、字体和具体组件——才产生了一个我能真正用来构建的系统。早期的具体性至关重要：模糊的概要只会带来模糊的系统，而模糊的系统又会让 AI 回到猜测状态，只不过把问题上升了一个层级。
2. 关联系统生成界面，而非事后补救
在项目中，"关联设计系统" 会将你的系统绑定到每一次生成中。从这时起，AI 绘制的每一个界面都会引用你的 Token，而不是自行编造新的。
1使用关联的设计系统，生成仪表盘的 10 个核心界面：概览、按模型分析成本、延迟、Token 使用量、Agent 状态、告警、单个 Agent 详情、设置、账单、以及空状态/首次运行。确保导航栏、卡片和图表样式在所有十个界面中保持一致。
关键点： 重建同样的十个界面，9 个在首次生成时就符合品牌风格。相比之下，之前没有设计系统时只有 2 个。同样的提示语言，使用同一个模型。
所有界面上的导航栏完全相同。KPI 指标块使用同一种卡片样式，而非五种。图表共用同一套配色。我不再是调整样式，而是在审查——这是完全不同也更简短的工作。
3. 下载系统并交给 Claude Code
在"发布"按钮旁边有一个下载按钮。它会导出整个系统——Token、组件规格、指南、资源——格式是外部工具可以读取的。这个导出文件就是你要交给 Claude Code 的东西。
1这是我们设计系统（已附上）。请将“按模型分析成本”界面构建为一个 React 组件。只使用系统中定义的 Token、组件和间距。不要引入新的颜色、圆角或字体大小。如果某些需求系统未覆盖，请停下来询问，而不是自行编造。
关键点： 我第一次在没有设计系统的情况下构建这个界面时，Claude Code 在整个项目中编造了 19 个十六进制值——各种一次性使用的灰色和强调色，虽然接近但我从未指定的品牌色。
有了关联的系统加上那条指令——"不要引入新的颜色，停下来询问"——它会引用 Token，编造的数量为零。"停下来询问"这条条款起了关键作用：它将模型填补空白的本能，转化为标记空白的本能。
4. 持续约束构建，防止偏离
下载的系统只在每个任务都实际引用它时才有效。哪怕跳过了一个界面，那个界面也会立刻回到猜测状态。
1对于本项目中的每一个新界面或组件，首先引用已关联的设计系统。在编写任何颜色、间距或字体值之前，检查系统中是否已定义该值。标记任何系统设计未能覆盖到的需求。
关键点： 我发布过一个偏离的界面——颜色不对的标签，不匹配的圆角——因为我仓促地描述了它，并且没有再让 Claude Code 指向系统。
在项目层面，一次性加入上面这条持续指令，问题就被解决了。系统不是一次性的粘贴内容。它是整个构建过程中需要持续遵守的规则。
对于 Cursor 来说，解决方法类似但更简单：将下载的系统放到项目中，并告诉它"使用我们的设计系统来构建"，编辑器中的 AI 就会将 Token 和规格当作规范来读取。
两种构建方式，量化对比
相同的十个界面的仪表盘，构建了两次。一次是 Claude Code 根据描述工作，一次是使用设计系统作为输入。以下是变化，无系统对比使用系统作为输入：
- 首次生成即符合品牌风格的界面： 2/10 -> 9/10
- 整个构建过程中的样式调整时间： 约 6 小时 -> 约 40 分钟
- AI 编造的一次性颜色数量： 19 -> 0
- 界面间的品牌风格漂移： 持续存在 -> 没有
重要的不是节省了多少小时，而是工作重心的转移。
没有系统时，我的时间都花在了样式调整上：微调颜色、修正间距、让界面七看起来像界面二。
有了系统，这项工作只发生一次——在设计系统本身中——之后每个界面都无需重复。我不再编辑像素，而是编辑规则；一条规则可以同时修正所有界面。
我第一个下午浪费在哪里
第一个下午主要都在摸索系统需要具备什么才有用。
- 使用 PNG 导入。 我尝试用旧项目的截图来构建系统。Moonchild 读取的是结构，所以 HTML 和 Figma SVG 能提供真实的 Token 和层级结构，而 PNG 只是一张它需要解读的图片。PNG 导入产生了一个粗略的近似值。SVG 导入则产生了一个非常接近我实际样式的系统。
- 泛泛的需求概要。 这是最常见的浪费，也是我首先踩的坑：一个过于泛泛、无法进行任何约束的概要只会把猜测问题向上推一级，而非消除它。
- 跳过某个任务中的系统引用。 就是前面提到的漂移问题：开发者从不引用的包，不会对结果产生任何改变。"先检查再编写"的规则才是让它起作用的基石。
系统无法解决的问题
三个诚实的局限性，因为将设计系统作为输入并非万能药。
- 输出结果仍需审查。 基于你系统的 Claude Code 构建速度更快、一致性也高得多，但它仍然是在生成代码。需要测试它、审查它，将其视为一个强大的初稿而非最终成品，尤其是在处理逻辑时。
- 系统的质量取决于你的付出。 如果 Moonchild 中的设计系统本身单薄或泛泛，那么导出的系统也会单薄和泛泛，下游的每个工具都会继承这一点。你原本用于调整样式的时间转移到了构建一个真正的系统上。这是更好的权衡，但并非免费。
- 纪律不会自行生效。 持续指令会有所帮助，但在团队中，代码审查仍然需要检查界面使用的是否是 Token，而不是那些碰巧看起来很接近的硬编码值。
完整流程，供你复制
三个提示词和一个下载。构建系统、关联系统、交给你的代码工具。
1# 1. 构建系统（在 Moonchild 中：新建项目 -> 新建设计系统）2为 [用一句话具体描述的产品] 构建一个设计系统。界面颜色和强调色：[具体描述]。字体：[字体名称]。密度：[低/高]。组件：[列出你实际使用的组件]。包含抽屉 vs 模态框以及空状态和加载状态的指南。34# 2. 关联系统生成界面（项目 -> 关联设计系统）5使用关联的设计系统，生成 [N] 个界面：[列出界面]。在所有界面中保持导航栏、卡片和核心组件一致。67# 3. 下载系统（“发布”按钮旁的按钮），然后交给 Claude Code 或 Cursor：8这是我们设计系统（已附上）。请使用系统中定义的 Token、组件和间距来构建 [界面/组件]。不要引入新的颜色、圆角或字体大小。如果系统未覆盖某些需求，请停下来询问，而不是自行编造。910# 4. 将其设为持续规则以防止漂移11对于每一个新界面或组件，首先引用已关联的设计系统。在编写任何颜色、间距或字体值之前，检查系统中是否已定义该值。标记任何系统未能覆盖的内容。
在 Moonchild 中设定
在 Moonchild 中："新建项目" -> "新建设计系统"。你会看到两个选项：
- "我们帮你导入"：这意味着 Moonchild 团队会（通常一天内）与你通话，将现有的系统从 Figma、Storybook 或代码中干净地导入到工具中。
- "自己构建"：使用上面的路径，进入聊天界面，从需求概要开始构建一个系统。
无论选择哪种方式，最终你都会得到相同的东西：一个结构化的系统，你可以通过"关联设计系统"将其关联到任何项目，并通过"发布"按钮旁的按钮下载。
版本控制是内置功能：每次"发布"都是一个新版本，你可以回滚，因此试验设计系统的成本为零。
别再要求"界面"了
你一直在要求你的 AI 生成"界面"。一个界面是一个输出结果。让它生成十个，你就会得到十个互不关联的输出结果，因为没有什么东西将它们联系起来。
相反，给它一个设计系统，你就改变了你提供的东西：不是请求，而是一个输入。
一份契约。
那些 Token、组件、规则——以机器可以遵守的方式定义了"你的产品"看起来应该是什么样子。基于这份契约生成的每一个界面，都属于同一个产品，因为它们都指向同一个唯一的事实来源，而非十次全新的猜测。
这就是转变，也正因如此，这并非一项纯粹的设计技能。你不需要知道如何平衡字体比例或挑选无障碍的色板。
你只需要用擅长此道的工具构建一次系统，然后确保每一次生成都从中读取数据。对于会写代码的人来说，设计从来不是最难的部分。真正难的，是那块本该存在系统却空白的区域。
只写一次逻辑
我可以构建逻辑。很多能交付软件的人都可以构建逻辑。
前端一直在拖后腿，不是因为我们缺乏审美，而是因为我们交给 AI 的只有描述，却要求它在没有书面记录的情况下，一个界面接着一个界面地在脑子里记住整套视觉语言。
将它一次性以系统形式写下来，用模型能够读取的格式，猜测就会停止。十个界面中只有两个品牌一致变成了九个。六个小时的样式调整缩短到了四十分钟。
不是工作变得更聪明了，而是它拥有了一个唯一的事实来源。
