Codex + Moonchild 工作流：构建不像“氛围编码”的应用

大多数开发者仍在发布那些一眼就能看出是 AI 应用的应用。用户两秒就能识破。

有些人为每个项目支付 5000 到 10000 美元给设计师，只为了让他们的 UI 看起来不那么差劲。

而还有一小部分机构和个人开发者，真正找到了解决办法。不是更好的提示词，也不是更好的模型，而是模型底层的一个系统。

在 @ignytlabs，过去一年半里我们交付了 60 多个 MVP。每个项目中，决定应用是按时发布还是拖延数周的关键因素都一样：底层的设计系统。

这是我们吃尽苦头才学到的教训。现在我们每个客户项目都采用这套流程。

如果你读过我上一篇关于 Moonchild 的文章，就会看到我们完整的 Codex + Moonchild 端到端工作流。该工作流的第一步很简单：在接触任何屏幕之前，先构建你的设计系统。

那篇文章下面的回复几乎都在问同一个问题：

“好的，但我到底该如何构建一个优秀的系统呢？”

这篇文章就是答案。

为了这个演示，我构建了 Pulse，一个健身与健康追踪移动应用。完整的设计系统，30 分钟内完成。每个组件、每种变体、每个令牌。准备好直接输入 Codex。

这是我们在 @ignytlabs 每个客户项目中使用的操作手册。

以下是完整解析。

Pulse 的所有屏幕，本文的示例应用。

Pulse 的所有屏幕，本文的示例应用。

Moonchild 到底是什么？（快速回顾）

如果你错过了第一篇文章，快速版如下：

Moonchild 是一个基于聊天的设计画布，围绕你的设计系统构建。不是空白提示，不是截图，而是你实际的系统。

你导入一个系统，粘贴一份 PRD，它会根据系统生成完整屏幕。然后通过 MCP 连接将这些设计直接送入 Codex。Codex 读取结构化的设计数据并编写代码。

第一篇文章涵盖了完整工作流，这篇文章则聚焦于别人没有解释清楚的部分：你究竟如何先在 Moonchild 内部构建一个优秀的设计系统。

左侧是 Moonchild 设计系统，右侧是 Codex CLI，两者通过 MCP 连接。

左侧是 Moonchild 设计系统，右侧是 Codex CLI，两者通过 MCP 连接。

为什么应用看起来像“氛围编码”

这是大多数开发者出错的地方。

他们认为应用看起来像“氛围编码”是因为 AI。于是他们换模型，更努力地写提示词，粘贴参考截图。输出稍微好了一点，但下一个屏幕又跑偏了。

模型不是问题所在。

Codex 不知道你的设计语言是什么。每个提示词都是全新上下文，每个屏幕都是一次猜测，每个组件都与上一个偏离。颜色偏移，字体偏移，间距偏移。到了第五个屏幕，应用看起来就像五个不同的产品拼凑在一起。

这就是人们说一个应用看起来像 AI 生成时所看到的。

解决办法在提示词的上游。你给 Codex 一个真实的系统来遵循，然后给它实际的设计来构建。

大多数工作流只给其一。Moonchild 加上 MCP 连接则两者都提供。

但如果系统本身很弱，这一切都行不通。

这就引出了真正的问题。

真正的设计系统到底是什么

大多数开发者认为他们拥有设计系统，但实际上并没有。

一个包含三个颜色令牌和两个按钮样式的 Figma 文件不是系统。一份包含品牌指南的 Notion 文档不是系统。一张你喜欢的 Dribbble 截图肯定不是系统。

一个真正的设计系统包含四个层面：

→ 令牌。 你的调色板、字体比例、间距比例和层级规则。其他一切都建立在这些原子决策之上。

→ 组件库。 你的应用所需的每个交互元素，一次设计，处处复用。按钮、卡片、徽章、输入框、导航、模态框。每个都带着全套变体。

→ 画廊视图。 每种组件的每个变体并排渲染，让你一眼看清整个家族。这是 95% 的开发者跳过的一步，也是最大的解锁点。

→ 规则。 何时使用主按钮与次要按钮，何时给卡片加层级，何时徽章为实心或轮廓。这些决策让你的应用在 50 个屏幕上保持一致。

如果你拥有全部四个，你就有了一个系统。如果你只有令牌，你只有一个起点。大多数开发者从未越过起点。

Moonchild 的任务是让你在 30 分钟内获得全部四个。

以下是具体做法。

第 1 步：选择你的输入路径

这是大多数开发者卡住的地方。你不必每次都从头开始。Moonchild 为你提供五条路径。

→ 从 Figma 导入。 如果你已经有包含令牌和组件的 Figma 文件，粘贴链接。Moonchild 读取结构并将其导入为统一系统。

→ 从 GitHub 导入。 如果你的设计令牌或组件库存在于仓库中，将 Moonchild 指向它。同理。

→ 从实时 URL 导入。 放入任何生产网站或应用。Moonchild 提取视觉语言，并在画布内重建为系统。

→ 放入设计灵感。 三到五张来自 Dribbble、Mobbin 或任何来源的截图。Moonchild 从参考中提取设计语言，从头构建系统。这就是我在第一篇文章中为 Haven 使用的。

→ 使用智能设计系统构建器。 向 Moonchild 描述你的品牌。它从书面简介中生成完整系统。当你还没有起始参考时最佳。

对于 Pulse，我选择了智能设计系统构建器。Pulse 是一个健身品牌，我脑子里有一个清晰的书面简介：大胆、以深色为主的能量感。暖奶油色画布，深炭灰色卡片浮于其上。鲜艳的橙色作为能量色，仅用于 CTA、进度和成就。Satoshi 字体以获得锐利的现代感。照片主导的英雄区块。高级运动氛围。我将这个简介放入 Moonchild，让它生成。

简介花了 30 秒写。系统生成花了 Moonchild 大约 4 分钟。

智能设计系统构建器正在运行。

智能设计系统构建器正在运行。

第 2 步：生成基础

一旦输入完成，Moonchild 会生成基础层。

这是其他一切所依赖的层。做对了，系统其余部分就顺畅；做错了，每个屏幕都会跟你作对。

对于 Pulse，Moonchild 生成了：

→ 调色板。 两个表面上下文：暖奶油色画布（从米白色到柔和米色的沙色色调）用于浅色面，深炭灰色（接近黑色）用于浮于其上的卡片和容器。鲜艳的橙色作为唯一的能量色，用于 CTA、进度填充和活动状态。状态色刻意置于橙色家族之外：青色表示成功，琥珀色表示警告，红色表示错误。每种颜色都带有十六进制值和语义名称（primary, accent, surface, danger），这样我就可以按用途而非颜色来引用它们。

→ 字体比例。 Display、H1、H2、H3、正文大号、正文、说明文字。每种都内置了行高、字重和字间距。Satoshi 作为统一字体家族，锐利的现代感，字重范围广，从微小的标签到超大的英雄数据都能应对。

→ 间距比例。 清晰的 4px 基础比例（4、8、12、16、24、32、48、64、96）。系统中所有边距和内边距都从这个比例中提取，没有魔数。

→ 层级系统。 五个层级，带有预定义的阴影规则。因此，层级 1 的卡片在每个屏幕上看起来都一样。

让我惊讶的是基础层的可预览性。大多数 AI 工具，包括我旧文章中的 Stitch，只会给你一个平面的令牌文件：颜色、字体，可能还有间距。Moonchild 则不同：它将基础层渲染到真实组件上，这样你就能看到实际效果。你在它们被交付之前就能发现对比度弱或比例失衡的问题。

这是你做修正的时刻。我将 Pulse 的炭灰色卡片调暗了一点，以增强与奶油色画布的对比，并将橙色强调色拉得更饱和一些，使其在深色表面上更突出。两行编辑，整个系统更新。

Pulse 设计系统 | 基础 + 颜色 + 字体。

Pulse 设计系统 | 基础 + 颜色 + 字体。

第 3 步：构建组件库

基础是地板，组件库是房间。

这是大多数开发者崩溃的地方。他们生成三个按钮就称之为系统。Moonchild 一次性生成完整的库。对于 Pulse，这意味着：

→ 按钮（主按钮、次要按钮、幽灵按钮、危险按钮，以及仅图标按钮和不同尺寸） → 卡片（锻炼卡片、成就卡片、排行榜卡片、统计卡片、个人资料卡片） → 徽章（活动、完成、锁定、连续、强度，以及所有尺寸） → 输入框（文本、数字、下拉、搜索，以及所有状态：默认、聚焦、错误、成功、禁用） → 导航（底部标签、顶部应用栏、分段控制、面包屑导航） → 列表（锻炼历史、好友列表、练习列表，以及分隔线和分组变体） → 图表（进度环、折线图、柱状图、热力图） → 模态框和面板（底部面板、全屏模态、吐司提示、警告框）

每个组件都带有完整的变体集和预渲染的所有状态。

这里的解锁点在于 Moonchild 不仅仅是绘制组件，而是将它们构建为实时的交互式元素。你点击按钮，它会动画；你悬停卡片，层级会变化。在任何屏幕生成之前，你就可以测试交互模式。

对于 Pulse，我花了大约 12 分钟来精炼生成的组件。让锻炼卡片图像更高，给成就卡片添加了连续计数，调整了排行榜的间距。每个精炼都更新了组件所有使用的地方，无需手动清理。

这就是真正的组件库所做的事情：一次设计，处处复用，一处精炼，更新传播。

第一次生成后的 Pulse 设计系统。按钮、卡片、徽章，每个组件都实时渲染。

第一次生成后的 Pulse 设计系统。按钮、卡片、徽章，每个组件都实时渲染。

与智能设计系统构建器反复对话后精炼的 V1。在这里至少花 10 分钟，以后能节省数小时。下面是 V2 的样子。

经过 12 分钟精炼后的同一组件库。间距更紧，变体更锐利，随时可以用于生成屏幕。

经过 12 分钟精炼后的同一组件库。间距更紧，变体更锐利，随时可以用于生成屏幕。

第 4 步：使用画廊验证

这是将一个真正的系统与一个花哨的令牌表区分开来的步骤。

Moonchild 有一个画廊视图，可以并排渲染每个组件的每种变体：每个徽章、每张卡片、每个按钮、每个输入状态。整个家族在一个画面中。

画廊是你发现问题的地方，以免问题叠加。

对于 Pulse，在并排查看徽章画廊时，我立即发现了两个问题。

连续徽章的橙色在奶油色画布上发光太强。通过将徽章背景柔化到比例中较浅的橙色阶来进行修复。

锁定状态和完成状态在深色卡片上尺寸较小时看起来太相似。通过将锁定状态改为更细的轮廓样式并带有柔和的炭灰色描边来修复。

两个修复花了 30 秒。如果我在第 40 个屏幕才发现，我就必须更新徽章出现的每个屏幕。

这是大多数开发者从未见过的解锁点：你在单个屏幕生成之前就做出明智的设计决策。你不是在猜测徽章在上下文中应该是什么样子，而是同时看到整个家族并整体评判系统。

在画廊中点击任何组件，你还会看到下面的实时代码：JavaScript、CSS、示例、依赖项。随时可以拉入代码库。这些代码稍后也会通过 MCP 连接供 Codex 读取。

这就像样式表与真正可工作系统之间的区别。

画廊视图。每个徽章和头像变体并排渲染。在交付前发现不一致的最快方式。

画廊视图。每个徽章和头像变体并排渲染。在交付前发现不一致的最快方式。

点击任何组件，下面的实时 JavaScript 和 CSS 就会显示出来。

点击任何组件，下面的实时 JavaScript 和 CSS 就会显示出来。

移交给 Codex

一旦系统稳固，工作流的其余部分就完全如我在第一篇文章中所介绍的那样。

你通过 MCP 将 Moonchild 连接到 Codex，粘贴你的 PRD，生成屏幕，然后将它们移交给 Codex。Codex 会编写与设计完全匹配的生产代码：无偏差，无垃圾，每个屏幕使用相同的组件库。

如果你还没看过完整的移交工作流，详细内容请参考我之前的 Moonchild 文章。

简短版本：在设计系统已经就位的情况下，实际的屏幕生成和代码交付对于一个完整的移动端 MVP 总共需要大约 90 分钟。没有系统，同样的工作需要设计师两周时间，再加上开发者另外两周的解释周期。

这就是杠杆效应：设计系统是前期投资，下游所有事情都变得更快。

左侧是 Moonchild 设计，右侧是已交付的 Codex 代码。

左侧是 Moonchild 设计，右侧是已交付的 Codex 代码。

额外福利：同样的工作流也适用于 Web 应用

在结束之前，快速说明一下。

本文以 Pulse（移动应用）为示例运行了工作流。但完全相同的流程也适用于 SaaS 仪表板和 Web 应用。

我们刚刚在 @ignytlabs 使用相同的 Moonchild + Codex 设置交付了一个 B2B 分析仪表板。设计系统层是相同的。组件库更大，因为仪表板有更高的密度（数据表、筛选器、侧边栏、图表容器），但构建过程是一样的：基础、组件、画廊、MCP 到 Codex、交付。

如果你为 Web 构建，这个工作流是可扩展的。移动端或桌面端，设计系统就是护城河。

使用相同 Moonchild + Codex 工作流构建的 SaaS 仪表板。

使用相同 Moonchild + Codex 工作流构建的 SaaS 仪表板。

何时构建真正的设计系统

并非每个项目都适合。要诚实判断何时适用。

构建真正系统的情况：

• 你正在交付任何存在时间超过 30 天的产品
• 你预期超过 5 个屏幕
• 品牌一致性很重要（几乎总是如此）
• 你为客户工作收费，并且你的声誉处于风险之中

跳过系统的情况：

• 周末黑客马拉松
• 你永远不会交付的一次性原型
• 永远不会增长的单屏工具
• 视觉质量确实不重要的内部实验

对于 95% 的真实项目，前期构建系统在第一周内就能收回成本。

需要注意什么

在应用于真实工作之前，这里有四个诚实的警示。

垃圾输入等于垃圾系统。模糊的简介或三张模糊的 Dribbble 截图会产生一个薄弱的系统。花 5 分钟在简介上，它在每个屏幕中都能得到回报。

不要在产品定型之前过度设计系统。一个你从未使用过的 200 组件系统，不如一个你实际交付的 30 组件系统。为当前需要的屏幕构建，随着产品增长扩展系统。

如果在项目中途进行更新且不小心，会破坏屏幕。当你更改一个基础令牌（颜色、字重、间距值）时，所有使用它的屏幕都会更新。大多数更新是好的，但有些会破坏特定屏幕的布局。在提交重大更改之前始终预览。

系统是你的品味，而不是工具的。Moonchild 生成一个强大的起点。选择合适的变体，精炼间距，删除你不需要的组件，这部分取决于你。工具产生，你引导。跳过策划步骤，你就回到了氛围设计。

这实际上意味着什么

以下是