上个月我接了一个“看似简单”的任务把一套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 三种常见换色方式的取舍对照我把这几种方案放在一起对比过方便大家按场景选择方案理解语义批量能力精确色值控制适合场景手动逐个修改完全靠人判断低高数量少、要求极致精修的Logo全局查找替换脚本不理解语义高高色号干净、语义单一的内部资产Generative Recolor理解前景背景与主从关系高中等偏上需校验几十上百枚图标批量换肤、多主题适配从我这次项目的经验看最理想的组合是“先脚本地毯式清理色号再生成式处理语义复杂的图形”。脚本负责把规范的底色打好生成式负责把需要理解能力的那部分收尾。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(encodingutf-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分钟内搞定然后把省下来的时间拿去解决那些真正需要判断力的设计问题。 用Generative Recolor与矢量矩阵流实现UI图标批量换色
上个月我接了一个“看似简单”的任务把一套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 三种常见换色方式的取舍对照我把这几种方案放在一起对比过方便大家按场景选择方案理解语义批量能力精确色值控制适合场景手动逐个修改完全靠人判断低高数量少、要求极致精修的Logo全局查找替换脚本不理解语义高高色号干净、语义单一的内部资产Generative Recolor理解前景背景与主从关系高中等偏上需校验几十上百枚图标批量换肤、多主题适配从我这次项目的经验看最理想的组合是“先脚本地毯式清理色号再生成式处理语义复杂的图形”。脚本负责把规范的底色打好生成式负责把需要理解能力的那部分收尾。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(encodingutf-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分钟内搞定然后把省下来的时间拿去解决那些真正需要判断力的设计问题。