企业官网建设流程全解析

1. 为什么我劝你别再直接改 Prefab 了

做游戏 UI 这行十来年，我见过太多团队在 Prefab 上反复折腾到崩溃。美术在 Figma 里调了一版按钮圆角，程序打开 Unity 一个个 Prefab 手动改；策划说列表间距要统一加 4 像素，结果三个界面三种间距；更别提 Godot 和 Cocos 项目并行的时候，同一套 UI 要在三套引擎里各维护一份，改一处漏两处。这不是能力问题，是工作流本身就有结构性缺陷。

这篇要聊的核心思路就一句话：把 UI 的设计源头从引擎 Prefab 里抽出来，放到画布上，让画布成为唯一事实来源，再通过导出管线把结构、样式、资源映射到 Unity、Godot、Cocos 三个引擎。Prefab 从"手写的资产"变成"生成物"，你不再直接编辑它，而是编辑画布，然后重新导出。

这套方法解决的是三个具体问题。第一，多引擎并行时的 UI 一致性，同一套设计稿导出到不同引擎，视觉和结构不会漂移。第二，设计与实现的协作断层，美术改画布，程序重新导出即可，不需要口头传达"哪个按钮改了什么"。第三，Prefab 的维护成本，尤其是那种几十个界面、上百个变体的项目，手改 Prefab 的边际成本高得离谱。

适合谁来参考？如果你正在做多端游戏、或者团队里有专门的美术出 UI 稿、又或者你被 Prefab 的合并冲突折磨过，这套流程值得认真看。纯手搓一两个界面的小项目，说实话没必要上这套，杀鸡用牛刀。但只要界面数量超过二十个、或者引擎不止一个，收益会非常明显。

我先把结论摆在这：画布导出不是银弹，它是一套工程约束。你得接受"Prefab 不可手改"这个纪律，才能换来一致性和可维护性。下面我把整套思路、关键细节、实操流程和踩过的坑，一条条拆开讲。

2. 整体设计思路与方案选型拆解

2.1 为什么是"画布"而不是"设计稿"

很多人第一反应是"我用 Figma 出稿，然后程序照着做不就行了"。问题在于，设计稿是给人看的，画布是给机器读的。Figma 的图层结构、命名、约束、自动布局，这些信息如果只是截图给程序，等于全部丢失。而画布导出要求的是：图层名即节点名、自动布局即布局组件、约束即锚点、组件即 Prefab 模板。这些语义必须完整保留，导出管线才能把它们翻译成引擎能理解的结构。

所以这里的"画布"不是随便一个画图工具，而是具备结构化图层语义的设计工具。Figma、Sketch、甚至自己用 Web 技术搭的无限画布都行，关键是它输出的中间格式（通常是 JSON）要能表达层级、样式、布局规则和资源引用。我实测下来，Figma 的 Plugin API 是最顺手的，因为它的节点模型和 Unity 的 RectTransform、Godot 的 Control、Cocos 的 Node 有天然对应关系。

2.2 中间格式：整条管线的咽喉

整条管线能不能跑通，取决于中间格式设计得好不好。我的做法是定义一份UI Schema，用 JSON 描述，包含四类信息：

• 结构层：节点树，每个节点有 id、name、type、children。
• 样式层：颜色、字体、字号、圆角、描边、阴影，全部用设计工具的原始值。
• 布局层：锚点、边距、对齐方式、自动布局方向、间距、是否撑满。
• 资源层：图片、字体、图集的引用，用逻辑名而不是绝对路径。

为什么不用设计工具的原生导出？因为原生导出是给"还原设计"用的，不是给"生成引擎资产"用的。它不会告诉你哪个图层是按钮、哪个是列表项、哪个应该被实例化成 Prefab。这些语义必须由设计规范约定，比如图层名前缀btn_、list_、item_，导出时按前缀识别类型。

提示：中间格式一定要版本化。我吃过亏，Schema 改了一版没记版本号，老项目重新导出直接崩，排查了半天才发现是字段语义变了。

2.3 三引擎的映射策略差异

Unity、Godot、Cocos 的 UI 体系差别不小，映射策略必须分开设计，不能一套逻辑硬套。

Unity 的 LayoutGroup 和 Godot 的 Container 语义接近，但 Cocos 的 Layout 在嵌套时行为有差异，尤其是resizeMode的处理。我的做法是在中间格式里用统一的布局语义，导出时各引擎适配器负责翻译。比如中间格式写layout: "vertical", spacing: 8, padding: [12,12,12,12]，Unity 导出成 VerticalLayoutGroup，Godot 导出成 VBoxContainer，Cocos 导出成 Layout 并设置对应属性。

2.4 为什么不直接生成 Prefab 而要先导出中间格式

有人会问，既然最终要 Prefab，为什么不直接从 Figma 生成 Prefab？因为中间格式是解耦层。设计工具会换、引擎版本会升级、导出规则会调整，如果直接点对点生成，任何一端变动都要重写整条管线。有了中间格式，设计工具换了只改导入端，引擎换了只改导出端，中间那层稳定不动。这是工程上非常经典的"加一层间接"思路，多写一点代码，换来长期的灵活性。

3. 核心细节解析与实操要点

3.1 图层命名规范：整套流程的地基

导出管线靠命名识别语义，命名乱了整条管线就废了。我用的规范是这样的：

• btn_xxx：按钮，导出为 Button 组件，自动挂交互脚本占位。
• list_xxx：列表容器，导出为 ScrollView + Content + Layout。
• item_xxx：列表项模板，导出为独立 Prefab，供列表实例化。
• img_xxx：图片节点，导出为 Image/TextureRect/Sprite。
• txt_xxx：文本节点，导出为 Text/Label。
• panel_xxx：面板容器，导出为普通节点 + 背景图。
• _开头：忽略，不导出，用于设计稿里的辅助线、标注。

为什么用前缀而不是后缀？因为设计工具里图层列表是按字母排序的，前缀能让同类节点聚在一起，美术找起来也方便。另外前缀识别比后缀更不容易误判，比如btn_close一眼就知道是按钮，close_btn在某些工具里可能被当成普通命名。

注意：命名规范一旦定下来，必须写进设计规范文档，并且让导出管线在遇到不符合规范的节点时报错而不是静默跳过。我早期版本是静默跳过，结果美术漏改一个命名，导出的界面少了个按钮，上线才发现。

3.2 自动布局的语义映射

自动布局是设计工具里最容易被忽略、但导出时最关键的部分。Figma 的 Auto Layout、Godot 的 Container、Unity 的 LayoutGroup，三者语义有重叠但不完全一致。我的映射规则是：

• 设计稿里用了 Auto Layout 的 Frame，导出时识别为布局容器。
• 方向horizontal映射到 Unity 的 HorizontalLayoutGroup、Godot 的 HBoxContainer、Cocos 的 Layout（type=HORIZONTAL）。
• 间距itemSpacing映射到spacing。
• 内边距padding映射到padding（Unity 是四个方向分别设，Godot 是 theme constant，Cocos 是 paddingLeft 等）。
• 对齐primaryAxisAlignItems映射到childAlignment。

这里有个坑：Unity 的 LayoutGroup 在嵌套时性能很差，尤其是列表项里再套 LayoutGroup，几十个 item 就会掉帧。我的处理是导出时对深层嵌套的布局做"扁平化"，把能合并的间距直接算进 RectTransform 的 anchoredPosition，减少 LayoutGroup 数量。这个优化在导出阶段做，比运行时做便宜得多。

3.3 资源引用与图集策略

图片资源是另一个大头。设计稿里的图片是原始 PNG，但引擎里通常要打图集。我的做法是：

1. 导出时收集所有图片节点的资源引用，生成一份资源清单。
2. 资源清单里记录逻辑名、原始路径、尺寸、是否九宫格、九宫格边距。
3. 引擎侧有一个资源映射表，把逻辑名映射到实际的图集 Sprite 或独立 Texture。
4. 导出时只写逻辑名，运行时通过映射表加载。

为什么不在导出时直接写死资源路径？因为图集策略会变。今天用一张大图集，明天可能拆成几张，如果 Prefab 里写死了路径，改图集就要重新导出所有 Prefab。用逻辑名 + 映射表，改图集只改映射表，Prefab 不动。

九宫格的处理要特别小心。设计稿里如果图片是拉伸的，导出时必须标记为九宫格，并且边距要和设计稿的圆角、描边对齐。我见过太多项目九宫格边距设错，导致按钮拉伸后圆角变形。边距的计算方式是：圆角半径 + 描边宽度 + 1 像素安全边，这个公式实测最稳。

3.4 文本与字体处理

文本导出有三个坑：字体、字号、图文混排。

字体方面，设计稿用的字体和引擎里可用的字体往往不一致。我的做法是在中间格式里只记录字体逻辑名（如font_main、font_title），引擎侧维护字体映射表。这样换字体只改映射表。

字号方面，设计稿的字号是像素值，但不同引擎的 DPI 处理不同。Unity 的 TextMeshPro 用 point size，Godot 用 pixel size，Cocos 用 fontSize。我的做法是统一按设计稿像素值导出，各引擎适配器负责换算。换算公式一般是引擎字号 = 设计字号 * (引擎参考分辨率 / 设计稿分辨率)，参考分辨率各引擎不同，Unity 默认 100，Godot 默认 1，Cocos 默认 1。

图文混排是热词里经常出现的需求。Unity 用 TextMeshPro 的 rich text 标签，Godot 用 RichTextLabel 的 BBCode，Cocos 用 RichText 的标签。三者的标签语法不同，但语义可以统一。我在中间格式里用一套简化的标记（如[b]、[color=#fff]、[img=icon]），导出时各引擎适配器翻译成自己的语法。这样设计稿里写一次，三端都能用。

4. 实操过程与核心环节实现

4.1 环境准备与工具链搭建

先说工具链。我用的组合是：Figma 作为画布，写一个 Figma Plugin 做导出，Node.js 写中间格式转换和引擎适配器，各引擎侧写一个导入脚本。

Figma Plugin 的入口很简单，manifest.json里声明main和ui，main里调figma.ui.postMessage把选中的节点树序列化后发给 UI，UI 再通过fetch或postMessage把数据传给本地服务。本地服务用 Node.js 起一个 HTTP 服务接收数据，转成中间格式，再分发给各引擎适配器。

为什么用本地服务而不是直接在 Plugin 里生成文件？因为 Figma Plugin 运行在沙箱里，文件系统访问受限，而且引擎适配器需要读引擎项目里的资源映射表，这些都在本地。本地服务是整条管线的中枢。

引擎侧导入脚本，Unity 用 Editor 脚本（C#），Godot 用 EditorPlugin（GDScript），Cocos 用扩展（TypeScript）。三者都监听一个"重新导入"的命令，读取中间格式，生成对应的 Prefab/Scene。

4.2 中间格式的具体结构

中间格式我用 JSON，结构大致如下：

{ "version": "1.2.0", "name": "MainMenu", "root": { "id": "root", "name": "panel_main", "type": "panel", "style": { "bg": "#1a1a2e", "alpha": 1 }, "layout": { "type": "vertical", "spacing": 16, "padding": [24,24,24,24] }, "children": [ { "id": "title", "name": "txt_title", "type": "text", "style": { "font": "font_title", "size": 48, "color": "#ffffff" }, "content": "主菜单" }, { "id": "btn_start", "name": "btn_start", "type": "button", "style": { "bg": "img_btn_normal", "size": [240, 64] }, "children": [ { "id": "btn_start_label", "name": "txt_label", "type": "text", "content": "开始游戏" } ] } ] } }

这个结构里，type决定导出成什么组件，style决定视觉，layout决定布局，children决定层级。资源引用用逻辑名（img_btn_normal、font_title），不写路径。

4.3 Unity 侧导出实现

Unity 侧的核心是把中间格式翻译成 GameObject 树，然后存成 Prefab。关键代码逻辑是：

GameObject BuildNode(UINode node, Transform parent) { var go = new GameObject(node.name); go.transform.SetParent(parent, false); var rt = go.AddComponent<RectTransform>(); ApplyLayout(rt, node.layout); ApplyStyle(go, node.style); switch (node.type) { case "button": go.AddComponent<Image>(); go.AddComponent<Button>(); break; case "text": var tmp = go.AddComponent<TextMeshProUGUI>(); tmp.text = node.content; break; case "image": go.AddComponent<Image>(); break; } foreach (var child in node.children) BuildNode(child, go.transform); return go; }

ApplyLayout负责设置 anchorMin/Max、anchoredPosition、sizeDelta，以及按需添加 LayoutGroup。ApplyStyle负责颜色、字体、图片。资源加载通过映射表查 Sprite 和 TMP_FontAsset。

这里有个细节：Prefab 保存前要把所有 LayoutGroup 的enabled设为 true 并强制刷新一次布局，否则保存下来的 Prefab 里子节点的位置是错的。我踩过这个坑，导出的 Prefab 打开一看全挤在一起，就是因为没刷新。

4.4 Godot 侧导出实现

Godot 侧生成.tscn文件。Godot 的场景文件是文本格式，可以直接用代码拼字符串，也可以用PackedSceneAPI 构建后保存。我推荐用 API 构建，因为文本格式的字段名容易写错。

func build_node(data: Dictionary, parent: Node) -> Node: var node: Node match data.type: "button": node = Button.new() "text": node = Label.new() "image": node = TextureRect.new() _: node = Control.new() node.name = data.name parent.add_child(node) apply_layout(node, data.layout) apply_style(node, data.style) for child in data.children: build_node(child, node) return node

Godot 的坑在于Container 的子节点不能手动设位置，位置由 Container 管。所以导出时如果节点是 Container 的子节点，就不要设position，否则会被覆盖。另外 Godot 的anchors_preset和 Unity 的 anchorMin/Max 语义不同，需要单独映射。

4.5 Cocos 侧导出实现

Cocos Creator 的扩展用 TypeScript 写，通过Editor.Message.request调用场景 API。核心逻辑和 Unity 类似，构建 Node 树，设置 UITransform、Widget、Layout、Label、Sprite 等组件。

function buildNode(data: UINode, parent: Node): Node { const node = new Node(data.name); node.parent = parent; const ui = node.addComponent(UITransform); ui.setContentSize(data.style.size[0], data.style.size[1]); if (data.layout) { const layout = node.addComponent(Layout); layout.type = data.layout.type === 'vertical' ? Layout.Type.VERTICAL : Layout.Type.HORIZONTAL; layout.spacingY = data.layout.spacing; } if (data.type === 'button') { node.addComponent(Sprite); node.addComponent(Button); } data.children.forEach(c => buildNode(c, node)); return node; }

Cocos 的坑是Layout 的resizeMode默认是 NONE，需要显式设为 CONTAINER 或 CHILDREN，否则布局不生效。另外 Cocos 的 Widget 对齐和 Unity 的锚点语义有差异，需要仔细映射。

4.6 导出流程的完整串联

把上面串起来，完整流程是：

1. 美术在 Figma 里按规范命名图层，用 Auto Layout 排版。
2. 选中要导出的 Frame，运行 Figma Plugin，数据发到本地服务。
3. 本地服务把 Figma 数据转成中间格式 JSON，存到项目目录。
4. 在 Unity/Godot/Cocos 里点"重新导入"，引擎适配器读 JSON，生成 Prefab/Scene。
5. 程序在生成的 Prefab 上挂业务脚本（脚本挂载点用命名约定，比如btn_开头的节点自动挂UIButton脚本）。
6. 美术改设计稿，重复 2-5。

第 5 步是关键：生成的 Prefab 上挂的业务脚本不能被覆盖。我的做法是导出时只生成结构和样式，业务脚本通过一个"脚本映射表"在导出后自动挂载，映射表记录节点名到脚本类型的对应关系。这样重新导出不会丢脚本。

5. 常见问题与排查技巧实录

5.1 导出后布局错乱

这是最常见的问题，原因通常有三个。第一，LayoutGroup 没刷新，Unity 侧保存前要调LayoutRebuilder.ForceRebuildLayoutImmediate。第二，锚点设置冲突，节点同时被 LayoutGroup 管又手动设了 anchoredPosition，两者打架。第三，尺寸计算依赖父节点，但父节点尺寸在导出时还没确定，导致子节点算错。

排查方法：先在引擎里手动打开导出的 Prefab，看是结构错还是样式错。结构错查中间格式的 children 层级，样式错查 style 字段。如果结构对但位置错，八成是布局刷新问题。

5.2 图片显示不出来

通常是资源映射表没配对。检查三点：逻辑名是否在映射表里、映射表指向的资源是否在引擎项目里、资源的导入设置是否正确（Unity 的 Sprite 模式、Godot 的 Texture 导入、Cocos 的 SpriteFrame）。我遇到过映射表里写的是img_btn，但实际资源叫img_button，差一个字母排查半天。

5.3 文本字体不对

字体映射表的问题。设计稿用的字体逻辑名在引擎侧没有对应项，导出时用了默认字体。解决方法是导出时如果找不到映射，报 warning 而不是静默用默认，这样能第一时间发现。

5.4 重新导出后业务脚本丢失

前面提过，业务脚本不能靠 Prefab 本身保存，要用脚本映射表在导出后重新挂载。映射表可以是一个 JSON，记录节点路径 -> 脚本类型。导出完成后遍历生成的 Prefab，按路径找节点，挂脚本。这样重新导出不会丢。

5.5 多引擎导出结果不一致

这是最头疼的问题，通常是各引擎适配器的映射规则不统一。我的做法是写一套共享的映射规则测试用例，同一份中间格式，三个引擎导出后对比关键属性（位置、尺寸、颜色、文本），有差异就查适配器。这个测试用例在 CI 里跑，能提前发现回归。

5.6 实操心得：先小范围验证再全量铺开

我建议不要一上来就把所有界面都迁到这套流程。先挑一个简单界面（比如设置面板）跑通全流程，验证中间格式、三端导出、脚本挂载都没问题，再逐步迁移。迁移过程中老 Prefab 和新导出的 Prefab 可以共存，用命名区分，避免影响正在开发的功能。

提示：导出管线一定要有"干跑"模式，只生成中间格式不写引擎文件，方便调试和对比。我早期没有干跑模式，每次调试都要重新导出，浪费时间。

6. 工具选型与扩展思路

6.1 画布工具怎么选

Figma 是首选，因为 Plugin API 成熟、节点模型清晰、社区资源多。Sketch 也可以，但 API 相对封闭。如果团队有前端能力，自己用 Web 技术搭一个无限画布也行，好处是中间格式可以完全自定义，坏处是要自己实现图层、布局、资源管理，工作量大。

选型的核心标准是：能否通过 API 拿到完整的节点树和样式信息。拿不到就别选，因为导出管线依赖这些数据。

6.2 中间格式的版本管理

中间格式一定要版本化，并且导出时校验版本。我用的规则是：主版本号变了表示不兼容，导出时直接报错；次版本号变了表示兼容新增，导出时 warning。这样老项目重新导出时能第一时间发现格式不匹配。

6.3 后续扩展方向

这套管线跑通后，可以往几个方向扩展。第一，自动生成占位脚本，导出时按节点类型生成对应的 MonoBehaviour/Node 脚本骨架，程序填逻辑即可。第二，接入 CI，设计稿更新后自动导出并跑测试，确保三端一致。第三，支持多语言，文本节点导出时只写 key，运行时按语言加载。第四，支持主题切换，样式层抽成主题变量，换主题只改变量。

我个人在实际操作中的体会是，这套流程最大的价值不是省了多少手工活，而是把 UI 的一致性从"靠人盯"变成"靠管线保证"。人总会漏，管线不会。前期投入大概两到三周搭管线，之后每个界面的维护成本能降一半以上，界面越多收益越大。最后再分享一个小技巧：导出时给每个生成的 Prefab 加一个_generated标记组件，程序一看就知道这个 Prefab 不能手改，避免有人手改后被下次导出覆盖。