踩坑后找到把Figma Make设计还原到项目中的靠谱路径

这段时间一直被 UI 设计折腾。

坦率的讲，测评好几款UI 类 AI 工具，目前做 UI 最靠谱的就是Figma Make，实际效果已经非常接近一个能进生产环境的设计稿了。至少在我试过的一堆方案里，它是少数那种会让我觉得，诶，这玩意好像真能用起来的东西。

但问题也是无处不在。

Figma Make 把页面做漂亮了，不代表你能把它稳稳还原进项目里。

这中间差着一个很难受的坑，哭诉下我在还原 UI 页面过程中踩过的坑们。

看着 Figma 里挺好，交给 Codex 一改，页面就开始变形：按钮比例不对、阴影变粗、元素被遮挡重叠、屏幕适配乱掉、顶部栏高度怪怪的、输入框间距也不对，太多了细数不过来。

比如下面这张是 Figma 中设计的登录页效果：

Codex 自动还原后的效果在下面：

这效果真就是狗看了都摇头的程度。。。

更离谱的是，有时候它还会非常自信地把原来的业务逻辑一起改了。

直接无语...UI 是变新了，项目也快被顺手拆了。

后来我折腾了一圈，发现比较可靠的路线，不是把 Figma Make 生成的代码直接搬进项目，也不是只丢一张截图让 Codex 猜，而是让 Codex 直接读 Figma，也就是把 Figma MCP 接到 Codex 里。

很多朋友可能会下意识觉得，一张截图不就够了吗？我把目标页面截给 Codex，再把当前运行页面也截给它，让它对着改，不就行了？

理论上听着很合理。

但真做起来你会发现，截图只告诉它「长什么样」，却没告诉它「为什么长成这样」。

页面里的层级关系、组件结构、变量、颜色 token、字体层级、布局约束，这些东西在截图里可能都是被压扁的。Codex 只能靠视觉猜，猜对了就是运气好，猜错了就会出现各种微妙的偏差。

比如一个按钮到底是 44 高，还是 48 高；左右两块区域是按比例分，还是固定宽度加自适应；阴影是设计系统里的 elevation，还是 Figma Make 随手生成的一层效果。

这些信息，截图里都有影子，但没有结构。

而 Figma MCP 的价值就在这里。

它可以让 Codex 读取 Figma 页面里的组件、变量、布局数据和资源。不是隔着玻璃看一张图，而是能摸到骨架。

我这两周的经验发现一条算是比较靠谱的路径，我拆解了下具体的流程步骤：Figma 连接 Codex 引导检查对比 开始构建测试 反复检查确认。

Figma 连接 Codex

第一步把 Figma MCP 连接到 Codex，让 Codex直接读取 Figma Make 的页面结构、组件、变量和布局，然后在现有代码基础上逐页改 UI。不建议只给 Codex 一张截图，也不建议直接把 Figma Make 生成的整套代码覆盖进现有项目。

首先需要使用Codex 桌面版，目前 Figma 官方推荐使用远程 MCP，网页版 Figma 也可以，不要求安装 Figma 桌面版。

在 Codex 中点击左上角插件。

找到Figma，点击旁边的“+”进行安装，浏览器会打开 Figma 授权页面。 再返回 Codex，检查确认 Figma 插件显示已连接。

这一步完成之后，你就可以把 Figma Make 产出的页面链接交给 Codex。

引导检查对比

如果你上来把 figma make 的连接丢给 Codex，并让他帮你还原设计。

真正的坑就开始出现了，大概率你会让你的项目直接崩掉。

千万不要一上来就说，帮我还原这个 Figma 的设计项目。

我自己现在比较推荐的流程，是一页一页来，不要把整套 Figma Make 页面一次性丢进去，不要让 Codex 批量改！！页面之间的公共组件、路由、状态、接口、样式文件，很容易被它搅在一起。

更稳的方式是，先选一个最关键的页面，比如登录页、首页先跑通。

另外一定要把边界讲清楚，我反复测试后效率和效果翻倍的办法就先让它去比对给出修改方案。

我使用的拆解流程的提示词也直接放在下面了，大家可以自行提取复用：

请通过已连接的 Figma MCP 读取下面这个 Figma 项目中的XX 页：

【粘贴 Figma 链接，并告诉他在 Figma 中对应的页面】

请将它与当前项目中的XX页面进行对比，并按照 Figma 设计修改现有XX页。要求：

1.只修改XX页以及该页面必要的公共样式文件。2.保留现有业务逻辑、页面跳转和业务状态。3.不要重写整个项目，不要替换现有技术栈。4.优先复用现有组件；只有现有组件无法满足设计时才新建组件。5.按照 Figma 实现：- 页面尺寸与整体布局- 顶部导航栏- 颜色- 字体层级- 圆角- 阴影- 间距- 图标和按钮状态6.不要使用绝对坐标堆砌页面，要适配不同尺寸设备。7.修改前先列出：- 需要修改的文件- 准备新增的文件- 当前页面与 Figma 的主要差异8.我确认后再开始修改代码。

这段话的重点不是「改得漂亮」，重点是「别乱动」，因为把设计还原进项目，最危险的从来不是 UI 不够像，而是它为了像，顺手把工程结构改崩，Codex 很强，但你要给它一个明确的工作边界。

开始构建测试

确认后再让他继续开展下一步工作，这个步骤要让它运行项目构建和相关测试，修复编译错误，再输出修改文件清单。更重要的是，要让它说明哪些地方已经和 Figma 对齐，哪些地方还存在差异。

按照刚才的计划开始修改。

修改完成后请：

1.运行项目构建和相关测试。2.修复编译错误。3.不修改与XX页面无关的业务代码。4.输出修改文件清单。5.说明哪些地方已经与 Figma 对齐。6.说明仍然存在的差异。7.不要提交 Git commit，先等待我检查。

反复检查确认

改完还没结束，过往正常的工作流程是：我自己编译后，使用真机运行的效果和 figma 设计稿反复比对，看看哪些地方还存在明显的问题再这个基础上继续完善。

现在我会多一步，让 AI 帮我先跑一遍，让它自行编译截图比对并给我一份检查的问题清单并进行修复。

不出所料的会发现还存在的问题，继续进行修复。

请运行当前项目并打开XX页，对照 Figma 页面逐项检查：

1.页面整体比例2.顶部栏高度3.左右区域宽度4.分割线位置5.输入框大小和间距6.按钮尺寸7.字号和字重8.圆角和阴影9.背景色10.不同点击状态

请列出视觉差异并直接修复明显问题，不得修改现有业务逻辑。

如果到了这一步还是有问题，我可能就会自己在真机上截图，再发一段提示词给他：

图片是当前运行效果，链接是 Figma 目标设计，请对比两者，只修复视觉差异。

我实际测试下来，这个路径流程非常稳，还原度能提升非常多。

我越来越觉得，现在用 AI 做产品，关键已经不是会不会写 prompt，而是你能不能把工作流拆清楚。

就像这个工作，要明白哪里让 Figma Make 发挥，哪里让 Figma MCP 传递结构，哪里让 Codex 修改代码，哪里必须保留人来确认。

这些边界想清楚了，AI 才像一个靠谱的协作者。

边界想不清楚，它就像一个过度热情的实习生，啥都想帮你干，最后把你 Git diff 干到不敢点开。

回到这套工作流，我觉得最适合记住的其实就几句话。

不要只给截图，要给 Figma Frame 链接。

不要覆盖项目，要在现有代码上逐页修改。

不要让 Codex 直接开干，要先让它列文件、列差异、列计划。

不要只看生成结果，要运行项目，对照 Figma 一项项检查。

一开始可能会觉得慢，但你相信我，这种慢是值得的。

它不神秘，也不性感，但它把 Figma Make 从「看起来很厉害的玩具」，变成了一个真的能进入工程流程的设计入口。

这件事让我挺兴奋的，我觉得这才是比较健康的 AI 工作流。

真正能把 AI 工具用到飞起来的高手，不是让 AI 替他乱改一切，而是要懂得让 AI 在正确的位置，做正确的事。

既然已经看到了这里，正好也对 AI 感兴趣，不如点一个关注哇，有趣有料的AI一手掌握，也欢迎点赞、转发🫴和推荐～