企业官网建设流程全解析

做游戏UI时间久了，你会发现一个特别常见的现象：单个界面拿出来看都还行，一放到同一个游戏里就各种别扭。图标风格不统一、弹窗圆角对不上、同一个按钮在A界面是蓝的，到了B界面变成灰的、字号大小随心所欲……这种“每个界面都挺好，整体看就是乱”的问题，几乎每个项目组都经历过。解决它的思路其实不复杂，靠一套风格预设把视觉规则固化下来，让所有界面都从同一套“标准件”里取材，风格自然就统一了。这篇文章把我自己的实操经验和踩坑记录整理出来，给正在被UI风格问题折磨的策划、美术和前端同学一个可落地的参考。

我最早意识到风格预设的重要性，是在一个中大型卡牌项目里。那时候项目刚上线测试，玩家反馈说“界面看起来很杂”。排查之后发现，问题根本不是某个界面丑，而是登录界面、战斗结算、商城、背包这些页面来自不同时期，由不同设计师完成，图标大小、按钮形态、弹窗背景、文字层级全都各搞一套。单个页面单看都有亮点，放在一起就是灾难。从那之后，我开始在项目里推行风格预设方案，新界面全部从预置样式库中“取用”，老界面逐步迁移，才慢慢把整体观感拉回来。

1. 游戏UI风格为什么会乱

很多人以为风格统一靠的是“设计师审美在线”，其实不对。审美只能保证单个界面好看，系统性的统一必须靠机制和规范来兜底。我见过太多项目，前期几个核心界面都精心打磨，后期赶进度，新界面由不同的人快速产出，风格就一路滑坡。风格混乱的本质是缺少可复用的视觉规则。

1.1 混乱的根源：每个界面都在“自由发挥”

游戏UI的体量比普通网页应用大得多。一套中大型游戏，界面数量动辄几十上百个，包含主界面、商城、背包、任务、活动、设置、战斗内HUD、弹窗、飘字、loading页等等。这些界面往往由多名UI设计师分头负责，不同人审美有差异，对“蓝色”“圆角”“标题字”的理解完全不一样。

再加上时间压力，很多设计师会选择“看着好看就做了”，而不是先问“这个样式符不符合项目已有规范”。于是，同样一个次级按钮，有的人用蓝底白字，有的人用深色底加蓝色描边，有的人干脆用了一张位图按钮。图标方面更是重灾区：A同学喜欢线性图标，B同学喜欢面性图标，C同学画的图标加了大量渐变和投影，三种风格放在同一个商店界面里，用户一眼就能感觉“不舒服”，但具体哪里不舒服又说不上来。

还有一个容易被忽略的因素是版本迭代。游戏上线后要持续做活动、出新系统，每出一个新玩法就要配套新UI。如果项目没有一套明确的风格预设，后来加入的设计师根本不知道“这个游戏的按钮到底长什么样”，只能去之前的界面里截图参考，而不同时期的界面本身就不一致，截出来的参考也就五花八门。混乱就这么一级一级传下来了。

1.2 风格预设能解决什么问题

风格预设不是单纯的设计规范文档，它是一套“可以直接取用的视觉资产”。它是把颜色、字体、圆角、间距、阴影、动效、图标风格等视觉元素，提前定义成可调用的预设值，设计师做图时直接套用，开发写代码时直接调用变量。

它的核心价值有三个。

第一，降低决策成本。设计师不用每次从零想按钮长什么样，从预设库里选就对了。开发也不需要反复问“这个颜色色值是多少”，直接调预设变量就行。这一点在新人加入、外包参与、多团队协同时尤其明显。

第二，保证一致性。大家都用同一套颜色、字体、组件规格，出来的界面天然协调。即使不同的设计师做不同的系统，最终视觉是“一家人”。

第三，方便全局调整。做游戏UI的人都知道，风格调优是常态。测试之后觉得主色太艳、觉得圆角太大，如果没有预设体系，你得满项目找所有用到这个颜色的地方，一个一个改。有预设就不一样，改一个变量，所有引用它的事件全部更新。

我见过一些团队把风格预设理解成“做一个UI规范文档”，然后放在Wiki里吃灰。这是不对的。真正的风格预设必须“活”在工具和代码里，设计师打开软件就能用到，开发写代码时自动补全就有对应变量，而不是让大家先翻文档再干活。

2. 风格预设的设计：从视觉令牌到组件封装

风格预设听起来玄乎，拆开来看其实就两层：底层的视觉令牌（Design Tokens）和上层的基础组件预设。视觉令牌管材质和单元，组件预设管成品和语义。

2.1 先搭底层：颜色、字体、间距这些“视觉令牌”

视觉令牌是风格预设的最小单位，它把具体的数值和抽象的名称绑定。比如“主色-强调”对应#FF6A00，“标题字号”对应28px，“圆角-大”对应16。之所以叫“令牌”，是因为我们约定不直接使用数值，而是通过令牌名称来引用。

颜色令牌在游戏UI里要比普通Web设计更细致。建议分几组来定义：

• 品牌色组：通常来自游戏主视觉和Logo，是整套UI的基因色。品牌色最好控制在2到3个，其中明确一个主色、一个辅助色、一个点睛色。
• 功能色组：系统状态色，比如成功、失败、警告、强化、稀有度等。这一步很多项目会漏，结果就是同一个“强化成功”在不同界面里有时是绿色有时是金色。
• 中性色组：背景、分割线、文本的主要颜色层级。别小看中性色，灰得有层次，界面才会干净。我一般会定义4到6级中性色，从底色到最深文字。

字体令牌也容易被低估。中文游戏UI里字体统一特别重要，不同字体混用会立刻拉低品质。建议预定字体家族，并明确标题、正文、辅助文字、数字专用字体的字号与字重。尤其到了战斗飘字或伤害数字，字体风格直接决定打击感，不能随便。

间距、圆角、阴影、描边这些也要令牌化。间距通常按4px或8px的基数递增，圆角按小、中、大、圆四档定义，阴影区分浅投影和强投影，描边区分1像素描边和2像素描边。这些东西单独看很小，累计起来就是统一的质感。

2.2 再封装组件：按钮、弹窗、列表这些“标准件”

底层令牌定好之后，下一步是基于令牌制作基础组件预设。很多团队做到上一步就停了，结果每个界面的“边框”“背景板”看起来还是不太一样。原因是设计师虽然用了同一套颜色，但组件结构、比例、层次仍然不同。所以必须把常用组件也预设出来。

在游戏UI里，最值得预设的组件包括：常规按钮类型（主按钮、次按钮、禁用状态等）、弹窗容器（标题栏+背景板+关闭按钮）、列表条目、页签切换、进度条、输入框、图标框架、飘字与Toast、横向滚动条。组件预设要细化到推荐尺寸、推荐层次、状态样式，并且要附带组合示例。

这里分享一个经验：组件预设建议按“底、面、饰”三层来定义。“底”是组件的基础形状和背景，决定了整体的识别度；“面”是信息承载区，保证可读性；“饰”是边框、光效、装饰纹样，决定了风格感。统一风格并不需要统一“底、面、饰”的全部细节，而是统一其中一层，另外两层范围受限即可。

比如一个游戏整体走“轻科幻”风，组件预设里可以让所有按钮都是“直角微圆角、深色半透明底、高亮描边”，但具体到每个按钮的装饰纹样可以灵活调整。这样既统一又不死板。

2.3 图标和动效：最容易被忽略的统一项

图标和动效往往在风格预设里被忽略，但它们恰恰是玩家感知最直观的部分。图标风格不统一，整套UI的精致感会大打折扣。

图标预设需要定义清楚几个维度：线性还是面性、线条粗细、端点样式、圆角程度、配色规则、是否带底板、禁用与选中状态的呈现方式。最好在预设里给出一组标准参考图标，作为所有图标产出的样板。做图标时千万不要凭感觉“这个好看用这个”，一定要对照参考图标检查风格是否一致。

动效相对复杂一些，但也应该定义基础规则。常见按钮的悬停与点击反馈、弹窗出现消失的时间与曲线、界面切换的过渡方式、飘字的入场与退场节奏。把这些约束写进预设，开发特效同学有了明确参数，就不用每个界面临时设计动效。

动效曲线也建议统一。有些团队不管UI动效，用爽了就把各种弹弹跳跳曲线都用上，最后整体很“吵”。我在项目里一般固定一两个标准缓动曲线，比如“平滑出”用cubic-bezier(0.2, 0.8, 0.2, 1)，强调动效用cubic-bezier(0.34, 1.56, 0.64, 1)，其他曲线一律不用，整体节奏立刻干净很多。

3. 实操：一套风格预设的落地流程

再好的理论，落不了地就是废纸。下面是我在项目中实际跑过的流程，每一步都踩过坑，给大家拆开讲。

3.1 第一步：先做UI盘点，再定方向

拿到一个项目，先别急着定义颜色和字体。第一步是盘点。

把游戏里现有的所有界面截图整理到一个画板里，按照功能模块分组，然后认真看一遍。重点找三样东西：不一致的地方、不和谐的地方、高品质的“锚点界面”。所谓“锚点界面”，就是目前各种界面里最能代表项目风格、玩家反馈最好、你想要推广到全局的界面。

找好锚点界面后，把它的视觉语言提取出来：背景用什么质感、主色是谁、按钮圆角多大、标题怎么排版、图标是哪种风格。这一套提取出来的语言，就是风格预设的雏形。比凭空造一套“理想风格”靠谱得多，因为它是从现有产品中长出来的，玩家已经有认同感，开发成本也低。

这一步的产出物是“风格方向说明”，包括2到3张风格参考图、关键元素提炼说明、一到两段口语化的风格关键词描述，比如“深色半透明玻璃质感、青色高亮、直线条为主、信息密度偏高”。这个方向说明要和主策、主美对齐，确认无误后再继续。

3.2 第二步：定义令牌，组织命名规范

确定方向后，开始定义视觉令牌。这一步的难点不在“选什么颜色”，而在“怎么命名”。

我建议令牌命名按“类型-语义-状态”的规则来。类型指颜色、字体、间距、圆角等，语义指它在界面里承担的角色，比如颜色里的主色、辅助色、背景色、边框色，状态指normal、hover、pressed、disabled等。

举个例子，一个按钮主色的常规状态，可以命名为color-primary-normal，它的Hover状态就是color-primary-hover。字体方面，font-h1表示一级标题，font-body表示正文，font-caption表示辅助说明。间距的space-4表示4px，space-8表示8px，归一化程度越高，后期调整越轻松。

命名规范一定要写清楚，并且要放在团队所有人都能看得到、搜得到的地方。这一点对后续协作特别重要。刚开始可能会觉得麻烦，但真正做起来之后会发现，命名规范省下的是无数沟通成本。

定义令牌的同时，最好把数值和参考样例同步更新到设计稿里。以颜色为例，每个色卡旁边放上它的使用场景示例，而不是只给一个色号。因为设计师看到色号可能还是不知道怎么用，但看到“这是弹窗背景色，使用面积比较大，透明度80%”就立刻明白了。

3.3 第三步：组件封装，同步到设计和开发工具链

令牌定义完，进入组件封装阶段。

在Figma里，我把所有基础组件做成一个独立的“UI组件库”，命名为 StyleSystem。里面的每个组件都严格按照令牌来搭建，比如按钮组件里填充色引用的是color-primary-normal，圆角引用的是radius-md。这样设计端的所有实例都跟着令牌走，改令牌组件会自动更新。如果项目用的PS，建好样式库文件，主用样式和样式模板统一维护。

在开发端，如果项目是Unity，用UI Toolkit的话可以直接把样式定义到USS文件，并定义--primary-color: #FF6A00;这类变量。如果是UGUI，没有原生的样式变量体系，就需要在C#脚本里做一个静态配置类，把所有颜色、字体、间距值统一管理。Unreal UMG的话，可以在Widget Blueprint里建立通用的样式资源，或者用CommonUI插件里的CommonUI样式管理。底层原理都是类似的：建立全局的单一样式数据源，所有界面动态引用。

我自己的习惯是，除了代码里的变量，还要求每个UI Prefab复用同一个组件源。比如做一个通用的按钮Prefab，所有界面的次级按钮都从这个Prefab拉出来改文字，绝不允许某个人右键新建一个空白按钮然后自己调颜色。在Unity里，可以从预制件（Prefab）实例化新按钮，保证样式统一。这样从源头就杜绝了样式飘走。

3.4 第四步：灰度验证，小步快跑迭代

整套预设建好之后，不要立刻宣称“大功告成”，也不要马上把全部界面翻新一遍。正确的做法是灰度验证。

挑两到三个尚未完成的新界面，用新预设从头做一遍，或者挑一个最陈旧的核心界面用新预设重构一遍。做的时候记录几个数据：界面制作效率有没有变化、视觉一致性评分（可以内部拉几个人打分）、玩家反馈是否更正面。这个验证阶段通常能暴露不少问题，比如某个色值在实际场景中偏暗、某个组件尺寸在不同的页面布局里不够用、某个字体在低分辨率设备上字重不够清晰。

根据验证结果调整令牌与组件，再固化下去。一般来说，第一版预设经过两三次灰度迭代后，会稳定下来。这时候就可以定“版本冻结”，把当前预设作为项目标准基线，后续所有新UI都必须基于它制作。冻结之后还需要有更新机制，遇到确实需要添加新样式的场景，走申请流程评估后加入版本库。

4. 开发引用与团队协作的默契

风格预设建好只是开始，真正考验人的是日常执行。

4.1 设计与开发要使用同一套“语言”

我见过太多项目，设计稿和代码完全是两套系统。设计师在Figma里定义了一个名叫“主按钮-大”的组件，开发在代码里自己起了个名字叫“Btn_Main_01”。两边各用各的名字，沟通效率低下，对不上号，最后样式就悄悄走样。

这套风格预设体系想要真正生效，设计和开发必须在命名和概念上保持同步。比较好的做法是：设计稿里的组件名称、代码里的变量名称、技术文档里的术语，全部统一。比如设计稿里有个buttons/secondary?type=normal，那Unity里的Prefab也叫Button_Secondary_Normal，C#配置类里对应入口也是这个。达成统一的成本很低，只要在项目初期有人愿意主持这个事。

我在项目里制作了一张“UI样式对照表”，左边是Figma组件名，右边是代码变量和Prefab路径，贴在项目Wiki的置顶位置。任何人开发新界面时都先查这张表，找不到再问，不鼓励自己发明新样式。

4.2 代码层面要做封装，而不是复制粘贴

开发层面的执行力决定了预设能不能真正落地。最稳妥的方案是，把基础UI组件封装成公共接口，业务开发不再直接接触底层样式参数。

以Unity UGUI为例，我通常会做几个静态方法，比如创建主按钮、创建弹窗、创建列表项，内部统一加载对应的Prefab并设置好样式。业务代码只需要调用UIHelper.CreatePrimaryButton("开始游戏", onClick)就行，完全不用自己配置颜色字体。这样即使某个开发不小心传了一个非预期颜色，也会被校验拦截，或者至少在代码审查时能被发现。

对于特殊样式，比如活动界面需要节日限定皮肤，我会要求先检查是否真的无法用预设实现，如果确实无法实现再出一个一次性样式，并及时提问是否需要将其补充到预设体系里。宁可先走流程，也不要在项目里乱加散装样式，不然一年后你会得到一堆无法维护的样式杂物。

4.3 定期做UI风格走查

不管预设建得多完善，项目迭代久了之后还是会出现坍缩。建议每隔一个迭代周期做一次集中走查。

走查的方式很简单，把新增的、改动过的界面全部截图，按功能模块排列在一起，逐屏扫过去。重点看的还是之前五个维度：颜色层级、字体层级、组件尺寸、间距体系、圆角与阴影。发现问题后就地记录，能当天改的当天改，不能当天改的记入技术债清单，明确修复时间点。

走查记录一定要公开可见。我习惯把走查表格放在团队共享文档里，每行一个界面，每列一个检查维度，符合预期的打勾，偏离的标注原因和修复方案。坚持两三次之后，团队的“风格警觉性”会明显提高，大家在做新界面时会下意识地主动检查，而不是等着被走查发现问题。

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

风格预设这个方案看似简单，实际操作中会遇到不少意料之外的问题。我挑几个高频的，大家碰到时可以少走弯路。

5.1 预设太死板，界面千篇一律

担心用了风格预设会让所有界面长得一样，这是最常见的顾虑。实际上这种情况说明预设的定义层级出了问题，或者太细，限制到了布局和组件组合方式。风格预设负责统一基础视觉语言，每个玩法界面依然要有自己独特的布局节奏和信息层级。就像同一套积木，可以搭出城堡也可以搭出飞船，风格统一指的是积木一致，而不是建筑形态一致。

控制预设对布局的最小干预，它只管“长得怎么样”，不管“摆在哪里”。真要出现了“千篇一律”的问题，先检查是不是把布局也固化得太死了，再检查是不是所有界面都用了一模一样的构图模板，在合理范围内解放分区结构，问题自然缓解。

5.2 变量改不动，颜色还是不统一

颜色不统一的问题，在UGUI这类没有原生样式变量体系的工作流里尤其突出。很多项目的UI颜色是每个界面单独填写色值，不引用公共变量，导致全局改色时界面之间无法对齐。

我的习惯是，在C#里定义公共静态类，用于UI统一配置。每个UI元素初始化时都从这个静态类读取颜色和字体配置。之后再遇到“加强主色”这种需求，只改这一个类就对全部UI生效。至于老界面里已经硬编码的颜色，消耗一定时间逐一替换，替换完成前不急着上新系统。

要注意的是，这个静态配置类要放在公共模块的最底层，UI层各个子域都要引用到。如果项目是纯前端技术栈，思路一样，只是变量定义从C#挪到CSS变量或JavaScript配置文件中，原理相同。

5.3 不同美术的产出风格不一致

风格预设能约束规则，但不能约束审美。有的美术擅长做华丽质感，有的美术擅长做简洁扁平，就算用了同一套颜色和圆角，成品气质还是会有差异。

我的经验是在风格预设里加入“气质指引”，比如放几个正反案例图片，明确说“本项目想要的质感是A，不是B”。这种指引比文字描述管用得多。同时，每个新界面在进入制作前最好先出一个风格样板截图，过一遍主美的眼，确认气质对了再全面铺开。这个步骤花不了多少时间，但能避免返工消耗数日下午。

5.4 预设文档有了，但大家不看

工具链落后，规范文档必然吃灰。如果预设只能通过“查文档”来获取，任何团队都很难坚持执行。最好的防御是让工作流本身就强迫人们使用预设。

设计师打开组件库，能直接拖出来的组件优先于自己画的组件；开发进入Unity，自动加载统一的外观配置，手动改参数比较困难。当“用预设”成为唯一的便捷路径时，大家自然会遵守。这也是我一直强调“必须把预设做成工具，而不是文档”的原因。

给大家一个判断标准：如果你的预设想要生效，但前提是大家必须主动翻规范文档，那么它的执行率大概率撑不过一个版本。规范应该随取随用，让使用预设比打破预设更省事。

5.5 全局配置文件里出现的怪问题

有几种情况容易踩坑，我单独提醒一下。比如全局变量在初始化时没打patch，导致部分界面在初始化前被读取了默认值，颜色闪一下才跳到正确样式。建议在UI根节点初始化前把配置全部加载好，配合加载状态界面避开闪烁。

另外，不同UI框架对透明度的处理细节差别很大。之前做半透明背景时，出现过一处UI叠加后颜色明显浑浊的情况，排查了很久发现是底层多处叠加导致的透明度混合。遇到这类问题，别只盯着一个组件，把所有叠加层级都检查一遍再下结论。我的排查步骤是，先确认全局变量是否正常加载，再用截图对比确认问题发生的界面与模块，接着逐层禁用或替换组件，最终定位到具体是哪个样式属性导致。

写在最后

回到标题那句话，一套游戏UI如何统一风格？风格预设就是最直接的答案。但我想强调一点：风格预设不是一次性建完就结束的东西，它是一套需要持续维护、持续运营的项目基础设施。就像代码需要重构，游戏玩法规格需要迭代，UI风格预设也需要跟着版本生长。建好之后别忘了安排人负责维护，不然随着人员变动和新需求涌入，它还是会慢慢腐化。

我个人在实际操作中最深的一个体会是，风格统一的项目，不是做出来的，是管出来的。预算定了、工具链通了、团队共识达成了，剩下的就是日复一日的走查、反馈、修正。还有个小技巧分享给大家：不论团队多小，每次版本更新发布前，都安排一个人花半小时把所有新界面截图拼一张长图，打印出来贴在工位上。肉眼扫长图找风格问题，远比抠单个界面更高效。这个习惯，我用了很多年，一直有效。