企业官网建设流程全解析

上个月我接了一个“看似简单”的任务：把一套62枚图标的UI资产库从蓝绿品牌色体系整体换成紫橙体系。按老经验，这种需求得排两天工时，逐个打开SVG、确认图层、修改fill、检查渐变、再导出深浅两套，中间还要应付那些把颜色写死在符号里的第三方图标。结果这次我只花了大概一个下午就交付了，其中真正让生成式工具跑批量重着色的纯操作时间，不到10分钟。支撑这个结果的是两样东西：Generative Recolor这个逐渐成熟的能力，以及我把图标资产重新整理成的一套“矢量矩阵流”工作法。这篇文章就从这套工作流的来龙去脉讲起，把顶层思路、实操步骤和翻车细节一次说清楚。如果你手头也有几十上百个图标和品牌图形资产，每次换主题都头皮发麻，那这篇内容大概率对你有用。

1. 先搞清楚痛点：换色从来不是“把颜色A改成颜色B”

1.1 一次品牌换色，到底要动多少东西

很多刚接触设计系统的同学会低估换色这件事的工作量。以为就是全选图层，在填充色面板里把旧的十六进制色号换成新的，完事。真这么干一回就会知道，一套稍微像样的UI资产库里，颜色不是平铺在一个图层上的。

一枚图标通常由多个图层组成：主形状、辅助形状、背景衬底、高光、阴影、描边。某些图标的渐变填充跨了三个色标，某些地方用了透明度叠加，还有一些是从第三方素材库导入的，颜色直接写死在复合路径里，连样式面板都识别不到。更麻烦的是，同一枚图标往往存在好几个状态副本：默认态、悬停态、按下态、禁用态、选中态。禁用态一般需要整体降低透明度或者换成中性灰，选中态则要突出强调色。一旦品牌换色，这些状态的颜色规则全部要跟着调整。

所以一次真正的UI资产库换皮，不是“改一个颜色”，而是“改一套颜色规则”。这条规则要同时作用于图形语义、状态语义和主题语义。任何工具如果只盯着颜色值本身，不理解这个颜色在图标中承担的角色，就一定会出错。

1.2 我踩过的手动改色翻车现场

前几年我还在老老实实用笨办法改色的时候，几乎每次都能遇到几个经典翻车现场。

第一个是漏改。某个文件夹图标的背景层改成了新版浅紫，但文件夹前面那张“纸片”的形状还留着旧版蓝色。单独看图标没问题，丢进整套资产里，视觉上总觉得哪里突兀，最后是靠逐个放大肉眼扫描才抓出来。

第二个是渐变断裂。图标主体是一个三段式渐变，手动改的时候改了第一格和第三格色标，第二格漏了，生成出来颜色过渡直接断层。这种问题在单个SVG里非常隐蔽，因为渐变面板只显示当前选中的色标，不点进去永远不知道没改完。

第三个是全局替换工具带来的灾难。有一回我图省事，用全局替换把某个旧蓝色全部替换成新紫色。结果图标里的蓝色替换对了，但产品页面里那些代表“信息提示”的语义蓝也全被替换成了品牌紫。那次之后我长了个教训：颜色替换必须带语义边界，不能凭色号一刀切。

1.3 传统批处理为什么解决不了“语义”问题

市面上其实早就有批量改色的脚本和插件，原理基本一致：扫描SVG里所有fill和stroke的色值，按照用户提供的映射表进行替换。这套逻辑对“同一颜色值在全局范围内等同处理”的场景有效，但一旦遇到两种复杂情况就抓瞎。

第一种是不同语义共用了同一个色值。比如图标主体和另一枚图标的背景衬底都用的同一款浅灰，但你要把前者改成深色、后者保留浅色。传统脚本做不到，因为它不理解“谁是主体、谁是背景”。

第二种是角色相同但色值已经不一致。多年迭代下来的资产库，经常会存在“名义上是同一个语义色，实际色号却有两三种”的情况，旧色号落在旧版规范里，新版规范出来后没人回头清理。传统脚本需要逐个色号去映射，映射表长得像流水账，还容易把团队刚清理完的规范又搞乱。

问题的根源很清楚：传统工具只能做“等值替换”，而换色真正需要的是“按语义重绘”。语义这件事，恰恰是生成式模型开始擅长的领域。

2. Generative Recolor的运作逻辑：它凭什么能理解“这是个图标”

2.1 不是调色，而是“先看懂再上色”

Generative Recolor，我去除了“生成式重新着色”。它跟PS里的“色相/饱和度调整”有本质区别。色相饱和度调整是对整张图的像素做数学变换，黄变红、红变紫，全部像素一视同仁。生成式重着色则建立在模型对画面内容的理解上：它先识别出画面里哪个是文件夹的主体，哪个是背后的衬底，哪个是描边，哪个是阴影，然后根据你给的提示词，为这些不同语义的部分分配新的颜色。

我用一个比方来解释：传统改色像用油漆滚筒把整面墙刷成同一个颜色，遇到拼色壁画就只能糊掉；生成式重着色像请了一位理解画面的画师，你把要求告诉他——背景改浅紫、前景改品牌紫、边框保留深色——他会在不动构图的前提下重新调配每个部分的颜色。

这也是为什么Generative Recolor处理多图层图标时，往往比手动改更稳定。它能理解“图层之间的主从关系”，不会出现把背景层改了、前景层漏改这样的低级失误。

2.2 输入输出边界：哪种资产适合跑，哪种不适合

这东西很强，但不是万能的。我实测下来，不同形态的资产跑Generative Recolor的靠谱程度差异很大。

最适合的资产类型是扁平化矢量图标和线性图标。这类图形语义清晰、色块边界明确、图层结构相对规范，模型容易区分前景与背景。其次是带有轻微渐变和阴影的插画类资产，只要渐变不是太复杂，模型基本能保持原有质感和方向。

不适合的资产类型我列几个：第一种是照片级位图里的小图标，模型会把它当照片内容去理解，重着色的结果不可控；第二种是图层极其复杂、上百个节点嵌套的超级组件，模型在栅格预览里根本分不清那么多细碎的元素；第三种是精细的品牌Logo，这类东西对形状和颜色有严格的法律和规范要求，不建议让生成式模型自由发挥。

所以拿到一套工作流之前，第一个动作永远是分类：哪些资产适合跑生成式重着色，哪些老老实实手动改。

2.3 三种常见换色方式的取舍对照

我把这几种方案放在一起对比过，方便大家按场景选择：

从我这次项目的经验看，最理想的组合是“先脚本地毯式清理色号，再生成式处理语义复杂的图形”。脚本负责把规范的底色打好，生成式负责把需要理解能力的那部分收尾。

3. 矢量矩阵流的底层设计：先让资产“排列整齐”，AI才接得住

3.1 矩阵的三个坐标轴：网格、状态、语义

“矢量矩阵流”这个名字听起来玄乎，其实核心思想只有一句：把零散的图标资产整理成一个有规律的多维矩阵，让AI批量处理时每一枚图标都处于同一套坐标系里。

第一个坐标轴是网格。所有图标统一落在同一画布尺寸下，比如移动端用24x24，桌面端用48x48，不混用。每枚图标的实际图形在画布中的边距、视觉权重也要尽量统一，不能一个占满画布，另一个四周留白大得惊人。

第二个坐标轴是状态。每个图标名称里明确标注它属于哪个状态变体，例如ic_folder_default、ic_folder_hover、ic_folder_disabled。状态字段单独列出来，而不是混杂在文件名里让人猜。

第三个坐标轴是语义索引。这一步是最关键的：在矢量文件中，用统一的命名和图层结构标出每个部分的颜色角色。主形状统一命名成primary，背景统一命名成background，描边统一命名成stroke，高光统一命名成highlight。

把这三个坐标轴组合起来，你的资产库就不再是“一堆图标文件”，而是一个任取一个坐标都能快速定位到具体图标的矩阵。生成式AI在批量处理时，才能真正做到“同一套规则套用到每一个单元”。

3.2 资产规范化清单：一次投入，长期受益

整理资产库的过程比较枯燥，但属于一次性投资。我做这套工作流时，花了大概一个半小时把62枚图标全部过了一遍，整理出一份规范化清单，给大家参考：

• 统一画布：所有图标移动到同一尺寸画布，图形居中，保留统一安全边距。
• 扁平化图层：能合并的路径尽量合并，减少无意义的编组嵌套。
• 规范命名：文件名、图层名、画板名三者统一，禁止出现icon_final_v2这样的历史遗留名称。
• 颜色角色标记：把主形状、背景、描边、高光等图层命名字段统一改为primary、background、stroke、highlight。
• 清理冗余样式：删除未使用的样式、重叠的透明图层、隐藏的废弃元素。
• 色板token化：将资产库用到的所有颜色，先映射到品牌Design Token的语义名称上，如color_brand_primary、color_brand_secondary。

这步做完，资产库的“可计算性”就出来了。后续不仅生成式模型能稳定使用它，普通脚本、设计规范检查工具也能在它上面跑自动化。

3.3 为什么没有矩阵流，Generative Recolor只能“一张张碰运气”

我最早试Generative Recolor的时候，直接拿旧资产库裸跑。结果惨不忍睹：有的图标识别得很好，有的图标把背景衬底染成了主色，有的图标因为命名里带了一堆杂乱的英文单词，模型上色时甚至产生了完全无关的颜色联想。

原因在于，生成式模型对图标的“理解”不仅来自视觉像素，也来自图层命名和文件结构的“提示”。如果你的资产库里图层名是乱七八糟的Path 58、Copy 4、Group 12，语义信息就完全丢掉了，模型只能靠猜。

矢量矩阵流的本质，是给AI提供了稳定的“上下文”。当所有图标都按统一语义命名、按统一画布排列时，模型在同一批次的每次生成中，看到的画布结构都是同构的，它就能稳定地执行同一套着色规则。这就像同一道菜，食材切得整整齐齐，厨师闭着眼睛也能保证每盘口味一致；食材大小不一、名称混乱，再好的厨师也得一盘一盘尝。

4. 实战流水线：从散装SVG到全套新资产库

4.1 第一步：盘点、清洗、建矩阵

动手之前先盘点全部资产。我建议先导出一份资产清单，把图标名、数量、状态变体、当前色值分布都列出来。用脚本扫一遍SVG的fill值最快，把出现过的所有颜色做一次频率统计，你立刻就能看出资产库的“健康状况”。

清洗阶段按3.2的清单逐项处理。这里提醒一句：如果资产库有几百枚图标，一次性全量整理会非常累，可以按主题模块分批来。本次要换肤的范围先建好矩阵，其余图标保持原样，避免战线拉太长。

建矩阵时，我用了一个很笨但很有效的文件夹结构：按照“主题/模块/状态/图标名”四层目录重新归档。Figma里则用Pages和Frames对应同样结构。这个结构本身不需要工具支持，普通的文件管理器就能实现。

4.2 第二步：封装可复用的提示词模板

提示词是Generative Recolor最核心的“参数配置”。我发现最稳定的写法不是散文式的描述，而是结构化的角色映射。

我在这次项目里用的模板大致是这样：

保持形状与结构不变，重新着色。 主前景形状：品牌紫色 #6C4DF6 背景衬底形状：浅紫色 #F2EEFF 描边与强调：深紫色 #2A1E5C 填充中的白色区域：保持不变，保留呼吸感 不要新增文字，不要改变图形轮廓，不要添加阴影

几个容易踩的提示词细节：

• 颜色必须写具体色值，不能只写“品牌色”。模型对自然语言的“品牌紫”理解是概率性的，对不同图标会得到不同深浅的紫。
• 要明确哪些区域保持不变。如果你不写“白色区域保持不变”，AI有时会把浅色区域也重新上色，导致图标失去层次。
• 一次只设定一套主色板。同时给五个强调色让模型自由搭配，大概率得到五彩斑斓的灾难。

4.3 第三步：批量生成与分批策略

矩阵建好、提示词定好之后，就可以批量跑了。我的策略是每批次16到24枚图标，同一个批次内使用完全相同的提示词，跑完一批检查一批，确认没有问题再继续下一批。这么做有两个原因：一是生成式模型存在随机性，批次越小越容易及时发现系统性偏差；二是如果某一类图标总是出问题，可以及时调整提示词，避免错误被复制到全部资产里。

整个生成阶段的纯操作时间确实只需要10分钟左右。但你得理解这个“10分钟”是AI在后台并行处理的时长，前期的提示词调试和资产清洗才是真正的时间大头。

4.4 第四步：用脚本+肉眼做双重回归

生成完不能直接交付，必须做回归校验。我最基本的校验步骤是：

• 用脚本导出所有SVG的fill色值，统计新出现的颜色是否在允许的新色板范围内。
• 对比生成前后的文件尺寸和路径层数，检查有没有元素被模型删除或新增。
• 肉眼扫一遍图标的视觉重量，重点看同一批里图标的描边粗细、内边距是否一致。

脚本统计这一步强烈建议做。62枚图标靠肉眼一个个看，你很容易在第40枚时产生视觉疲劳。但脚本只能捕捉颜色和结构问题，视觉协调性还是得靠人，这一步省不得。

下面是我用来统计SVG颜色的Python示例，逻辑很简单，实际跑起来很管事：

import re from pathlib import Path from collections import Counter colors = Counter() pattern = re.compile(r'#[0-9a-fA-F]{6}\b') for svg_path in Path("generated_icons").glob("*.svg"): text = svg_path.read_text(encoding="utf-8") colors.update(pattern.findall(text)) for color, count in colors.most_common(20): print(color, count)

跑完之后，把不在新色板列表里的颜色挑出来，逐个回去看是哪枚图标哪个图层出了问题。这个流程在本次项目中帮我抓到了两枚生成时把描边色改成白色的漏网之鱼。

5. 实测最容易翻车的五个细节，以及我的处理方案

5.1 批次之间色相漂移

同一个提示词，第一批生成完看着很准，第二批跑出来主体色却偏了一点点。这就是典型的色相漂移，也是我遇到的第一个问题。

后来我分析，这个问题主要出在模型对“品牌紫”这类色彩词的理解存在随机性。即便是给了具体色号，模型在渲染时也会有一些微小偏移。解决方法是两层：第一，提示词里除了写HEX，再加一句“主形状的前景色占比不低于整体面积的60%”，约束模型不要过度添加辅助色；第二，生成后跑一遍颜色统计脚本，逐个批次检查主体色色号是否在容差范围内。

5.2 禁用态、悬停态被AI“好心”上色

图标矩阵里有default、hover、disabled三套状态。我最初把三套状态放在同一个批次里跑，结果AI把disabled态的图标也上了全套彩色，完全无视了禁用态本应降低饱和度的规则。

这事的教训是：不同状态的图标必须分开跑，不同状态对应不同提示词模板。禁用态我专门设计了一套模板，明确写“整体改为灰色#B3B3B3，透明度变为40%”。把状态语义写清楚，AI的上色规则才会跟着状态走。

5.3 渐变图标生成后变成平色

资产里有几枚带渐变的图标，生成结果让非常头疼：模型的输出强行把渐变“压平”成单一颜色，原来渐变的方向和层次全部丢失。

我试过在提示词里写“保留渐变方向”，效果不稳定。最后实际采用的是两条腿走路：先用Generative Recolor生成平色版本，确认语义和配色无误之后，再把原图标的渐变控制点信息作为“样式Token”重新套回去。换句话说，AI负责配色方案，渐变的方向、角度、端点位置这些几何信息由人工设计系统负责。生成式模型擅长色彩搭配，不擅长精确控制渐变几何参数，没必要硬让它做。

5.4 生成结果包围盒偏移

有一批图标的生成结果颜色完全正确，但放入画布时明显没有对齐原来的视觉中心。这是因为生成式模型在做栅格重绘时，可能因为画布四周的留白变化，重新判定了图形边界，导致输出后图形在画布内的位置出现偏移。

处理方式是在导出后的步骤加一道自动化检查：对比每个SVG的viewBox和图形实际占位范围，如果发现偏移超过阈值，就用脚本把图形重新居中到画布中心。Model再聪明，也抵不过最后一道工程校验来得可靠。

5.5 相近品牌色让AI分不清语义

这次品牌色里有主紫#6C4DF6和辅助浅紫#F2EEFF，差距比较大，AI分得很清楚。但我之前做过一个项目，品牌主色和辅助色分别是#0077CC和#00AAEE，两个颜色视觉上很接近，AI就频繁把背景衬底涂成了主色。

解决办法是在提示词里给每个语义色编号，而不是只写颜色描述。

使用以下编号对应关系： B01：#0077CC，仅用于主前景形状 B02：#00AAEE，仅用于背景衬底 B03：#FFFFFF，仅用于留白区域

编号的好处是降低模型对自然语言歧义的感知，让它更倾向按位置和角色匹配颜色。实测下来，相近色场景的错误率降了一大截。

6. 资产管线化之后：生成结果怎么和Design Token体系衔接

6.1 把颜色结果写回语义Token

跑完Generative Recolor，得到的只是一批颜色正确的新SVG。如果做完这一步就收工，那下一次品牌换色时你又要重新整理资产、重跑一次生成式流程，资产仍然没有沉淀。

更合理的做法是把生成结果中的颜色抽离成Design Token。具体来说，在代码层面和设计系统层面，将所有图标的填充色由写死的色值改为语义Token引用。图标组件里的fill值不再直接是#6C4DF6，而是var(--color-icon-primary)。这样，如果下次要换色，你只需要修改Token变量表，整套图标的颜色就会自动跟着变，甚至不需要再跑AI。

Generative Recolor在这条管线里的角色变成了“生成第一个正确版本”的引擎，而Token让这个版本能够融入整个设计系统。两者组合起来，才真正形成了“一次重构、长期复用”的闭环。

6.2 深浅色模式与无障碍的复核清单

主题换肤不只是把颜色换成新的，还要确保新配色在深色模式、浅色模式以及各种交互状态下都可读。我每次做完批量重着色，都会按下面这份清单复核，建议你也保存一份：

• 对比度：图标主体色与背景对比度是否达到WCAG AA标准，尤其是功能型图标。
• 禁用态：禁用态的灰度是否清楚表达了不可交互状态，不要和正常态混在一起。
• 选中态：选中态的强调色是否在深浅两套主题下都保持一致识别度。
• 描边可见性：细描边图标在浅色背景上如果用了过浅的颜色，会直接“消失”。
• 渐变层次：渐变两端颜色在深色模式下是否还能区分。
• 更新Token映射后全局回归：所有使用到旧Token的页面都检查一遍，防止遗漏。

6.3 我做完这套流程之后最大的感触

工具更替很快，但真正值钱的是资产治理的思路。Generative Recolor再厉害，如果资产库本身是一个图层命名混乱、颜色写死、状态语义不明的黑箱，它也只能在局部发挥作用。反过来，当你把资产库组织成一套有规律、有语义、可编程的矩阵，AI的能力会被放大很多倍，后续任何一个新工具出现，你都能快速接上。

我也不认为生成式方法会完全取代设计系统工程师。它把机械、重复、低创造力的部分拿走了，但品牌调性的把控、色彩传达的情感、可访问性的底线，这些依然需要人来决策。我现在的习惯是：AI负责首稿，人负责终审；AI负责效率，人负责品味。两者各司其职，才能把重着色这类基础工作在10分钟内搞定，然后把省下来的时间，拿去解决那些真正需要判断力的设计问题。