Codex 做设计真的牛炸了。这才是真正有效的工作流。

Codex 加一个秘密工具，就是我们工作室现在跑的设计流程……输出效果完全是另一个档次。

我喊了几个月了。如果你的应用看起来像 AI 垃圾，那不是 Codex 的问题，那是工作流的问题。

大多数开发者都困在同一个循环里：用 AI 发布功能，后端没问题，逻辑很扎实，但界面看起来和其他所有凭感觉编码的应用一模一样。用户两秒钟就能决定它靠不靠谱。

以前的解决办法是雇一个设计师，等几周出 Figma 文件，然后看着开发者解读那些设计再用代码重新实现。等设计上线时，你已经失去了动力，还烧了不该烧的钱。

现在，整个过程都可以选择不做。

为了这次讲解，我搭建了 Haven，一个房产移动应用概念。20 分钟完成完整的设计系统。不到一小时所有界面设计完成。通过 Codex 输出生产级代码，一行 CSS 都没重写。

这就是我现在跑的流程。所有用 AI 开发的人都应该搞明白它是怎么工作的。

左边是 Moonchild 设计 UI，右边是 Codex 把它变成能用的移动应用。

左边是 Moonchild 设计 UI，右边是 Codex 把它变成能用的移动应用。

Moonchild 到底是什么

这个秘密工具就是 Moonchild。

过去一年里我几乎试过所有新推出的 AI 设计工具。大部分第一屏看着还行，但做到第二页就崩了。一致性问题。Moonchild 用一种其他工具做不到的方式解决了它。

它是一个基于对话的设计画布，从你的设计系统出发。不是从空白提示词开始，也不是从截图开始，而是从你的真实系统开始。你可以通过三种方式导入系统：

→ 从 Figma、GitHub 或在线 URL 导入

→ 向它的代理设计系统构建器描述你的品牌

→ 从 Dribbble 或其他地方放入设计灵感

一旦系统到位，你就不再像以前那样用提示词生成设计。而是粘贴一份 PRD。它会根据你的系统生成完整的界面。然后你在此基础上进行艺术指导。

而导出路径就是闭环的关键。Moonchild 提供了一个 MCP 连接器，把你设计好的东西直接以结构化输出的形式交给 Codex。不是让 Codex 去解读的截图，而是真正的设计数据：组件、设计标记、布局，所有东西。

这就是整个工作流。现在来看看具体怎么用。

Haven（我的房产移动应用）的完整 UI，在写一行代码之前就在 Moonchild 内部设计完成了。

Haven（我的房产移动应用）的完整 UI，在写一行代码之前就在 Moonchild 内部设计完成了。

大多数开发者用 AI 做设计时的问题

大多数开发者是这样做的：

他们让 Codex 构建一个新功能，发布出来，看着还行。然后让 Codex 做下一个功能，样子有点不一样。到第五个功能时，应用看起来就像五个不同产品的拼接。

这就是人们说 AI 设计很糟糕时的意思。

模型并不糟糕，糟糕的是工作流。

Codex 根本不知道你的设计语言是什么。每次提示都是一次全新的上下文，每个界面都是一次猜测，每个组件都和上一个偏离了。颜色在变，字体在变，一切都叠加在一起。

解决办法很简单：给 Codex 一个系统来遵循，然后给它真正的设计来构建。

大多数工作流只给了其中一样。而 Moonchild 加 MCP 连接同时给了两样。

第一步：永远先构建你的设计系统

这是所有人都跳过的一步，也是最重要的一步。

在 @ignytlabs，我们在动手做任何界面之前都会为每一个客户构建设计系统。以前这要花费设计师两天时间。Moonchild 大约 20 分钟就搞定了。

这次讲解我搭建了 Haven，一个房产移动应用概念。有几种方法可以把设计系统弄进 Moonchild：可以从 Figma、GitHub 或在线 URL 导入；可以向代理设计系统构建器描述你的品牌。对于 Haven，我用了自己从风格入手时的常用做法：从 Dribbble 找设计灵感。我放了三张移动房产应用的截图（它们精准地抓住了我想要的风格），加上一段关于 Haven 是做什么以及为谁做的简短描述。工具提取了设计语言，从头构建了整个系统。

让我惊讶的是所有东西都可以预览。大多数 AI 工具（包括我上一篇文章里写到的 Google Stitch 工作流）只会给你一份扁平的设计标记文件：颜色、字体、可能还有间距。但 Moonchild 不一样。它会构建一个完整的组件库和一个展示画廊。每个徽章、按钮、卡片、组件都按照在应用里实际的样子渲染出来。点击任何组件，你都能看到它的实时效果，还有控件可以测试变体和尺寸。在预览下方，你会得到该组件的实际 JavaScript、CSS、示例和依赖。随时可以拉进代码库。

画廊这部分真的会改变你设计的方式。你不再需要猜测“品牌徽章”或“评分徽章”在实际中什么样，而是把它们全部放在一起看：在售、出租、精选，整个家族一起出现。你可以在任何一个界面生成之前就做出明智的设计决策。

这就是样式表和真正系统之间的区别。

Haven 的详细设计系统。这通常是决定整个应用 UI 成败的关键部分。

Haven 的详细设计系统。这通常是决定整个应用 UI 成败的关键部分。

第二步：从 PRD 到 UI

一旦你的设计系统就位，你就不再用老方法提设计提示词了。

你直接粘贴一份 PRD。

一页的功能简介，一份产品规格，一个目标陈述——你有什么就用什么。

对于 Haven，我粘贴了一份结构化的 PRD，包含了产品介绍、目标、目标用户和角色、关键功能和 MVP 范围、完整的用户旅程、技术栈以及设计方向。大约一页纸，具体到足以给工具提供真实上下文，结构清晰到能把正确的细节分配到正确的界面。

然后我做了一件大多数人都会跳过的事。

在生成任何界面之前，我先和它进行了头脑风暴。

这就是大多数开发者没发现的关键。对话模式里有完整的 PRD 上下文。你不是把 PRD 一扔就点生成，而是先讨论产品：确认界面列表，敲定导航模式，在任何像素出现之前预先定义关键界面的层级。

对于 Haven，我问了这些问题：

→ “基于这份 PRD，你建议我们先构建哪些界面？对于一款房产应用，我有没有遗漏什么？”

→ “主导航应该用首页、搜索、收藏、个人资料这样的底部标签栏，还是别的形式？”

→ “在生成之前，先带我过一遍房源详情页的优先级顺序：先照片，再名称和价格，然后规格，接着设施，最后经纪商。确认或改进。”

→ “好的，现在请继续，按照我当前关联的设计系统，生成这些界面的浅色模式和深色模式。确保完整的用户旅程，创建所有界面。”

到我点生成的时候，工具对产品的了解已经比大多数设计师在第一次客户会之后还要深了。

现在快速说一个关于变体的要点。仔细看。

一个很棒的功能：你可以创建界面的不同变体。只需要明确告诉 Moonchild，它就会来处理。对于 Haven，我想先看到三种不同的美学方向再决定。我用的具体提示词是：

“我希望你为 Haven 生成 3 套完整的移动 UI 设计概念：

概念 1 - 温暖编辑风：奶油色背景、宽松间距、房产名用衬线标题、柔和阴影、杂志风格图片处理。

概念 2 - 大胆现代风：深色模式、高对比度、全无衬线、尖锐边角、以图片为主导的边到边图像。

概念 3 - 极致简约风：中性调色板（米白、炭灰、单一强调色）、精致字体、大量留白、精致的微交互。

以已关联的设计系统为基础，但让每个概念把系统带向不同的美学方向。生成完整界面，不只是区域。你怎么做？”

注意结尾的“你怎么做？”这个小细节让整个事情奏效。工具没有盲目地直接生成所有东西，而是先回来给了计划。

它说会先为每个概念构建 5 个有代表性的界面。我会并排查看三个方向。一旦我选定了想要的，它就会继续去设计整个应用。

这完全改变了成本结构。你不需要为三套完整实现付费，你只需要为三个快速样本付费，然后在选定的方向上做一次完整的实现。

我选了温暖编辑风。接着完整的界面集就出来了。

Moonchild 一次生成了完整的 Haven UI，包括每个界面的浅色和深色模式版本。

Moonchild 一次生成了完整的 Haven UI，包括每个界面的浅色和深色模式版本。

从三个不同概念生成的三种不同 UI 变体。选择你喜欢的风格，然后让 Moonchild 围绕它生成其余界面。

从三个不同概念生成的三种不同 UI 变体。选择你喜欢的风格，然后让 Moonchild 围绕它生成其余界面。

接下来是真正让我惊讶的部分。

Moonchild 生成的每个界面在预览模式下都是可交互的。不是静态线框图，而是真正可交互的。

你可以点击输入框，点按钮，像真实用户测试原型一样在界面之间移动。对于 Haven，我在预览中发现了两个流程问题，否则它们就会直接交到 Codex 手里。房源详情页没有明显的返回浏览路径，联系经纪商的按钮位置太靠下。如果我没有先点击一遍就把设计交给 Codex，这两个问题都会直接发出去。

这就是关键所在：你在写任何代码之前就可以测试产品。

在 Haven 房产界面上的交互预览模式。

在 Haven 房产界面上的交互预览模式。

最后一步是优化循环。

当一个界面需要修改时，你不必从头重新提示。选定这个界面，告诉工具要改什么，它会原地生成 v2。想要更有电影感的主角图？v2。想把卡片布局换成列表视图？v3。变体会堆叠起来，你可以比较并选出最强的。

对于 Haven 的房源详情页，我经历了三次迭代。v1 经纪商区块太高。v2 修正了层级，但图片库感觉太小。v3 两者都搞定了。大约 8 分钟的来回修改。

你不是在白纸上策展，而是在优化一个真实的方向。这部分最接近和高级设计师合作的感觉。

同一个界面即时生成多个变体。不断优化方向，直到找到感觉对的那个版本，然后定稿。

同一个界面即时生成多个变体。不断优化方向，直到找到感觉对的那个版本，然后定稿。

第三步：通过 MCP 连接 Moonchild 和 Codex

这才是工作流真正牛起来的地方。

设计系统给了 Codex 规则，而 MCP 连接给了 Codex 更强大的一样东西：直接访问实际设计输出。不是截图，不是对设计的文字描述，而是 Codex 可以读取并重建的结构化设计数据。

设置方法如下：

→ 进入 Moonchild 设置，然后找到 MCP

→ 根据你的设置复制安装命令

→ 打开 Codex CLI

→ 粘贴安装命令

→ 用你的 Moonchild 账户进行认证

→ 完成

连接成功后，Codex 就能看到你的设计系统和具体的 Haven 界面了。

显示 Moonchild MCP 已连接的 Codex 界面。

显示 Moonchild MCP 已连接的 Codex 界面。

第四步：Codex 输出代码

然后像这样提示 Codex：

使用 Moonchild MCP 获取 Haven 房产移动应用项目，告诉我里面有哪些界面。

第一个提示完成了两个工作：确认 MCP 正确连接，让 Codex 对你的每一个设计界面都有完整的可见性。

在让 Codex 做任何更重的活之前，有一个快速建议：保持在计划模式。Codex 会在执行之前显示它将要做的事情。每次都阅读计划。确保它理解你想要哪些界面、什么顺序以及什么精度。这是 Codex 编写你真正需要的代码和 Codex 编写它以为你需要的代码之间的区别。

一旦你审核了计划，并指定了想要的界面，Codex 就会直接从 Moonchild 拉取设计数据，引用你的设计系统，然后写代码。它甚至还会加上悬停状态、过渡和边界情况处理，因为它是在真实的设计数据上工作，而不是靠提示词猜测。

结果：在你的实际代码库中，几分钟内就得到与设计完全匹配的生产级 UI。

在 @ignytlabs，我们以前为每个客户 MVP 的设计预算两周时间：设计师构建 Figma 文件，开发者解读它，解读结果会偏离，我们修正，周而复始。有了这个工作流，整个循环压缩成一个下午的工作。同样的质量，更高的利润，少了无数上下文切换。

完整的 Moonchild 设计加 Codex 输出屏幕录制。

完整的 Moonchild 设计加 Codex 输出屏幕录制。

什么时候使用这个工作流

这个工作流并不适合每个团队。坦诚地判断何时适用。

使用场景：

→ 你是独自开发或小团队发布 MVP

→ 设计一致性在跨界面时总被打破

→ 你不想维护 Figma 到设计师再到开发者的流水线

→ 你已经有一个设计系统，希望在所有地方得到执行

跳过场景：

→ 你已经达到一定规模，拥有完整的内部设计团队和成熟的 Figma 库

→ 你需要逐像素交接的市场站点或品牌工作，每处阴影都很重要

→ 你的代码库有高度自定义的 UI 模式，需要定制设计工作

对于 80% 的开发和发布 MVP 及 SaaS 产品的人来说，这个工作流覆盖了你需要的一切。

需要注意什么

在你运行之前，有几个诚实提醒。

你的设计系统质量决定了输出质量。垃圾进，垃圾出。一个只有三个颜色标记的半成品 Figma 文件只能产生平庸的界面。一开始就在系统上花时间，它在每个界面上都会回报你。

PRD 质量很重要。模糊的简介会让你得到通用界面。一份包含用户流程、边界情况和清晰层级的特定 PRD 才能得到有用的设计。这不是工具的限制，而是思考上的限制。

你仍然需要审美。工具负责产出，你负责指导。选择正确的变体并优化它，这才是你判断力的所在。如果你跳过了策展步骤，你又回到了凭感觉设计的老路上。

某些组件需要手动微调。复杂的动画状态、自定义交互模式、任何超出设计系统的东西都需要在 Codex 中手动过一遍。MCP 能带你走到 90%，最后 10% 靠你的审美。

这实际意味着什么

以下是我诚实的看法。

用 AI 构建产品的瓶颈从来都不是代码。AI 能写代码。瓶颈一直在设计层：一致性、审美、把一切联系起来的系统。

那个瓶颈刚刚瓦解了。

在我们工作室，以前为每个客户 MVP 的设计预算两周：雇设计师、等 Figma 文件、看开发者解读、循环。以前需要两周的事情现在只需要两天。同样的质量，更快的交付，更高的利润。

这就是资金充足的团队通过 Figma 加设计师加开发者流水线已经拥有的东西。不同之处在于，现在独立开发者、独立工作室和小型工作室也能获得同样的杠杆，而不需要全队人马。这是一个单人团队的工作流。它和预算无关——只和你如何使用工具有关。