Figma2Prefab工作流实践博客

从 Figma 到 Unity Prefab：一套可落地的 AI UI 工作流实践

本文整理自《捕鱼达人千炮版 Figma2Prefab 工作流分享》，重点介绍如何把 Figma 初稿稳定转化为符合项目规范的 Unity UGUI Prefab，并总结 AI 参与 UI 工程化时的边界设计方法。

一、为什么需要 Figma2Prefab 工作流

在传统 UI 开发中，设计稿完成后，程序需要手动完成节点搭建、资源绑定、层级调整、布局适配和交互接入。这个过程重复劳动多，设计与实现之间还容易产生偏差。

Figma2Prefab 的目标，是在人工完成 Figma 导入后，让 AI 接手后续的工程化工作：理解需求和设计稿、检查导入结果、识别返工项、输出改造方案，并通过 UnityMCP 或 Unity Editor API 完成 Prefab 制作，最后由人工验收和微调。实践中可以减少约 80% 的重复工作量，最终产物完成度可达到约 90%。

二、整体流程：两阶段完成交付

阶段一：准备 Figma 导入场景

人工完成 Figma 账号绑定、设计稿导入、导入配置调整，并检查资源、节点和基础层级。导入阶段的质量会直接影响后续 AI 执行。

阶段二：AI 拆分、整合与工程化改造

  1. 核对需求：确认页面用途、交互范围、Prefab 边界和项目规范。
  2. 分析设计稿：识别页面结构、功能区域、重复组件和资源依赖。
  3. 输出改造方案：明确节点的保留、拆分、合并或替换策略。
  4. 执行节点处理：完成层级整理、组件绑定、资源关联和布局调整。
  5. 生成 Prefab：通过 UnityMCP 或 Unity Editor API 写入工程。
  6. 人工验收：检查视觉还原、节点结构、路径、组件引用和交互基础。
  7. 局部微调：处理自动化流程难以覆盖的细节问题。

三、AI 应该负责什么

AI 最适合处理需要理解和判断的工作，包括页面和组件拆分、节点绑定关系、返工识别、规范冲突判断、组件复用建议以及风险识别。

四、哪些内容必须交给工具

路径、坐标、节点结构等内容属于工程事实，应由工具读取或生成。建议固定由工具完成资源路径检查、节点坐标和层级提取、组件创建与属性写入、Prefab 保存、工程状态校验以及验收结果生成。

这样可以把“判断”和“执行”分开：AI 决定做什么，工具保证准确完成。

五、原工作流的问题

早期流程给了 AI 过大的自由度，容易出现资源路径错误、节点被误删、产物与预期漂移以及执行链路不稳定等问题。本质原因是工作流没有明确事实来源、执行边界和验收标准。

六、优化后的核心原则

1. 先定义最终交付物

明确需要交付哪些 Prefab、根节点和层级边界、必须绑定的资源、需要保留的交互，以及允许人工收尾的范围。

2. 固定唯一事实源

路径、坐标、层级和组件信息必须来自明确的工具输出或当前工程状态，禁止 AI 根据名称猜测资源位置。

3. AI 只输出决策类内容

AI 可以判断保留、拆分、绑定、替换和风险等级，但具体路径、坐标和节点创建应由工具执行。

4. 建立标准化中间产物

在设计稿和 Prefab 之间增加页面节点清单、资源映射表、组件绑定表、改造任务列表和风险验收清单，让每一步都可检查、可追踪。

5. 执行和验收使用固定工具链

统一使用 UnityMCP 或 Unity Editor API 执行，统一检查结构、引用、路径和视觉结果，保证流程可复现。

七、一套可复用的提示词结构

提示词可以按“背景、目标、输入事实、允许的决策、禁止事项、执行顺序、验收标准”组织。重点不是写得更长，而是让输入事实、职责边界和验收条件足够明确。

八、如何衡量流程是否有效

可以从四个维度评估：还原度、工程质量、可复现性和人工成本。只有同时满足这四项，才能说明工作流真正实现了提效，而不是把工作从手动搭建变成反复修正 AI 结果。

九、总结

Figma2Prefab 的关键不只是让 AI 生成 Prefab，而是重新设计 UI 到程序的协作流程：人工准备正确输入，AI 负责拆分、绑定和风险判断，工具负责读取事实、执行修改和保存产物，固定流程负责验收，人工完成最终确认和少量微调。

当 AI 的自由度被限制在决策范围内，路径、坐标、节点和执行过程由工具控制，UI 自动化才能从偶尔有效变成稳定交付。这套方法同样适用于其他 AI 工程化场景：先明确最终产物，固定唯一事实源，再把 AI 放在适合它的位置上，让工具保证结果的准确性和可复现性。

十、资源地址与使用边界

1. Figma 官方资源

建议优先使用团队统一的 Figma 组织账号和桌面客户端，避免因个人账号、字体或插件版本不同造成导入结果不一致。

2. Unity 官方资源

Unity 版本、渲染管线、UI 框架和项目插件应以团队项目锁定版本为准，不要直接使用最新版替换现有工程。

3. UnityMCP 与项目内部工具

原文提到通过 UnityMCP / Unity Editor API 执行 Prefab 制作，但没有公开对应的仓库地址。实际使用时应向项目负责人获取：

  • UnityMCP 服务端或插件仓库；
  • MCP 客户端配置示例；
  • Unity 工程允许调用的工具清单；
  • 项目资源根目录和 Prefab 输出目录；
  • 自动验收脚本及运行方式。

如果团队没有 UnityMCP，也可以先使用 Unity Editor API 编写受控的 Editor 工具，把“读取事实、修改节点、保存 Prefab、输出验收结果”封装成固定命令。

十一、从零开始的下载与安装流程

第一步：准备 Figma

  1. 打开 Figma 下载页。
  2. 安装桌面端，或使用浏览器版本。
  3. 登录团队账号。
  4. 打开目标设计文件，确认可以查看和编辑。
  5. 检查字体是否安装，缺失字体会导致尺寸和换行变化。
  6. 确认设计稿中的图片、图标、渐变和特殊效果有可导出的源文件。

第二步：准备 Unity

  1. 从 Unity Hub 安装 Unity Hub。
  2. 使用项目要求的 Unity Editor 版本打开工程。
  3. 等待 Package Manager、脚本和资源完成导入。
  4. 确认项目可以正常编译，没有阻断性的 Console Error。
  5. 确认目标 Canvas、UI 根节点和项目资源目录。
  6. 建议在独立分支或临时场景中进行第一次转换，避免污染主场景。

第三步：准备 UnityMCP 或 Editor 工具

  1. 从团队内部获取 UnityMCP 插件或 Editor 工具。
  2. 按项目文档配置 MCP 服务端、客户端和 Unity 连接。
  3. 在 Unity 中打开 MCP 所需的窗口或服务。
  4. 用一个只读任务验证连接，例如读取当前场景名称、Canvas 层级和选中对象。
  5. 验证成功后，再开放创建节点、修改属性和保存 Prefab 的权限。
  6. 把资源读取、节点修改和验收工具固定为工作流允许的唯一入口。

第四步：准备输入目录

建议建立如下目录：

```text
Assets/
Art/
UI/
FigmaExport/ # Figma 导出的原始资源
UI/
Imported/ # Figma 导入后的临时结果
Prefabs/ # 最终 Prefab
Screenshots/ # 验收截图
Editor/
Figma2Prefab/ # 读取、执行、验收脚本
```

目录名称可以按项目规范调整，但必须提前固定，不能让 AI 在执行时自行猜路径。

十二、Figma 设计稿的准备规范

页面和组件命名

建议使用能表达用途的命名，例如：

  • `LobbyPanel`
  • `RoomListItem`
  • `CoinLabel`
  • `CloseButton`

避免使用大量 `Frame 123`、`Group 45` 之类无法表达意图的默认名称。

节点层级

建议把页面拆分为背景、内容区、交互区和装饰区，并保持层级与最终 Prefab 结构接近。不要把所有元素都放在同一层级，也不要把交互节点与纯装饰节点混在一起。

导出资源

  • 位图导出统一尺寸和格式；
  • 图标优先保留 SVG 或高分辨率源文件；
  • 九宫格、切片图和重复纹理标记清楚；
  • 资源名称与 Unity 内部命名保持一致；
  • 避免只在 Figma 中存在、但没有可交付源文件的图片。

设计变量

颜色、字号、间距和圆角尽量使用统一变量或样式，便于后续映射到 Unity 的主题配置和组件参数。

十三、实际操作流程

1. 导入前检查

先记录以下事实：

  • 设计文件链接和版本；
  • 目标页面名称；
  • 需要生成的 Prefab；
  • 目标 Canvas 分辨率和缩放模式；
  • 资源导出目录；
  • 交互节点列表；
  • 不允许删除的节点。

2. Figma 导入

使用项目既定的 Figma 导入方式完成初稿导入。导入后先人工检查，不要直接让 AI 修改：

  • Canvas 和根节点是否正确；
  • 图片和字体是否存在；
  • 节点数量是否大致匹配；
  • 关键层级是否完整；
  • 设计稿中的组件是否被拆成合理节点。

3. 生成结构化中间产物

让工具读取当前 Unity 状态，输出以下文件或结果：

  • `nodes.json`：节点路径、名称、类型、位置、尺寸和层级；
  • `assets.json`：资源路径、类型、尺寸和引用关系；
  • `bindings.json`：节点与脚本字段的绑定建议；
  • `risk-report.md`：缺失资源、异常节点和需要人工确认的项目。

这些数据应来自 Unity 当前工程，而不是由 AI 手工编写。

4. AI 方案评审

AI 只根据结构化事实输出：

  • 页面拆分方案；
  • Prefab 边界；
  • 组件绑定方案；
  • 可复用组件建议；
  • 高风险变更清单；
  • 需要人工确认的问题。

此时先不允许修改工程。人工确认方案后再进入执行阶段。

5. 工具执行

执行工具按固定顺序完成：

  1. 创建或复制目标节点；
  2. 设置父子关系；
  3. 设置 RectTransform；
  4. 添加并配置组件；
  5. 写入资源引用；
  6. 写入脚本绑定；
  7. 保存 Prefab；
  8. 输出修改日志。

每一步都应记录输入、输出和失败原因，方便回滚和定位。

6. 视觉与结构验收

至少检查以下内容：

  • 页面尺寸和锚点；
  • 文字字号、颜色和对齐；
  • 图片比例和清晰度；
  • 层级遮挡关系；
  • Button、Toggle、ScrollRect 等组件；
  • 资源引用是否为空；
  • 脚本字段是否正确绑定；
  • Prefab 是否能在目标场景实例化；
  • 不同分辨率下是否出现明显错位。

十四、常见问题与排查顺序

路径不存在

先由工具重新扫描资源目录，再检查命名大小写、扩展名和目录映射。不要让 AI 直接猜一个“看起来合理”的路径。

字体或文字错位

检查字体是否安装、字体资源是否被正确导入、Canvas 缩放模式是否一致，以及文本组件的换行和溢出设置。

节点被误删

恢复到上一次 Prefab 或场景版本，重新生成节点清单，并把不可删除节点加入保护名单。后续执行工具应采用白名单修改，而不是全量重建。

视觉结果与 Figma 不一致

按背景、容器、文字、图标、间距、阴影的顺序逐层比对。先确认尺寸和锚点，再处理颜色和装饰细节。

组件引用为空

检查脚本字段名、节点路径和组件类型，优先使用工具生成的绑定表，避免 AI 根据节点名称自由匹配。

AI 反复绕路

缩短任务范围，一次只处理一个页面或一个组件；明确禁止修改未授权节点，并要求先输出计划、等待方案确认后再执行。

十五、设计思想：把 AI 放在正确的位置

这套工作流的核心不是“让 AI 自动完成所有事情”，而是把工作拆成三类：

工作类型 责任方 原因
拆分、整合、风险判断 AI 需要理解上下文和设计意图
路径、坐标、层级、组件事实 工具 必须准确、可复现
最终视觉和业务验收 人工 需要结合产品体验和项目约束

这种设计可以概括为：AI 做决策，工具做事实，人做验收。

十六、落地收益与适用范围

适合使用这套方法的场景包括：

  • 大量结构相似的 UI 页面；
  • 需要频繁从设计稿同步到 Unity 的项目；
  • 有明确资源目录和组件规范的团队；
  • 希望把 UI 制作过程标准化、可复现化的项目。

不适合完全自动化的场景包括：

  • 设计稿本身尚未确定；
  • 资源命名和目录没有规范；
  • 需要大量手绘、特效或复杂动画；
  • 业务交互仍在频繁变化；
  • 项目没有稳定的 Unity 工具链。

最终目标不是追求“零人工”，而是把人工时间集中在设计判断、业务确认和高价值细节上。

posted @ 2026-09-11 18:13  猫猫可爱捏  阅读(8)  评论(0)    收藏  举报