AI主题生成标准化：拆解Theme-Factory技能，从设计令牌到工程落地

拿到这个官方 Skill 的时候，我的第一反应其实是有点怀疑的。"theme-factory"——主题工厂，听起来就像《黑客帝国》里那句"有无限多的牛肉"，意思是有无限多的主题。但真正拆开用了一遍之后，我承认之前的判断过于草率了。它解决的不是"能不能换个颜色"这种表面问题，而是把 AI 生成主题这件事，从"碰运气式的一句话调参"，变成了一套有输入协议、有校验步骤、有兜底策略的标准化流程。

如果你也跟我一样，平时要维护博客、文档站、客户端皮肤，或者干脆负责公司里的设计系统管理，这篇文章值得耐心看完。我会把 skill 的完整拆解、一次真实从零到发布的实操链路、还有我在反复测试中踩过的大量坑，一次性都讲清楚。

1. 为什么单靠"帮我换个主题"总是翻车

先说一个很多人都有过的体验：你在一款 AI 助手里输入"帮我生成一个北欧极简风主题"，出来的东西乍看很漂亮，深灰浅白、间距舒适、字重得体。但是当你真的把代码粘进项目里，问题立刻暴露：某个按钮的文字对比度只有 2.3:1，根本读不清；某一组色板只有 4 个色值，深色模式下完全不够用；更麻烦的是，变量命名体系天马行空，上一次叫primaryColor，这一次叫color-blue-500，两次对话产出的东西根本没法整合。

这不是 AI 笨，而是这类任务的本质就决定了"一句话 prompt"不可能稳定。一个完整可用的主题，背后至少包含六层知识：

• 色彩系统的构建逻辑：主色、辅助色、中性色、语义色（成功/警告/危险）怎么分层；
• 对比度合规：WCAG 标准要求正文文本至少 4.5:1，大文本和 UI 组件至少 3:1；
• 字号与字重的阶梯关系：标题、正文、辅助说明、代码片段都有不同的排印规则；
• 组件变量的映射：一个按钮牵扯到背景色、文字色、边框色、悬停态、激活态、禁用态，至少 8 个 token；
• 深色模式的切换策略：不是简单反色，而是基于色相和明度的整体重映射；
• 导出物结构：JSON 设计令牌、CSS 变量、框架主题包、文档说明，缺一不可。

这些东西如果你不预先让 AI 知道，它就只能自由发挥。而自由发挥的结果就是：视觉上永远好看，工程上永远不可用。这恰恰是 theme-factory 这个官方 Skill 存在的原因——它把上面提到的专业经验全部固化成了一段结构化指令。

实际上，我在拿到这个 Skill 的说明书之后观察到一个细节：它没有要求模型"发挥创意"，反而大量使用了"必须""禁止""默认"这种强约束词。这说明一个很好懂的事实——AI 生成主题这门手艺，瓶颈从来不在创意，而在纪律。没有纪律的生成，做得越多，返工越狠。

1.1 主题生成的三大经典失败场景

我在各种群里观察过大家分享的翻车截图，基本都是这三种：

第一种是"调色盘灾难"。模型喜欢把对比色放到相邻位置，几个颜色放在一起看还行，一旦大面积铺开，视觉噪声会直接掩盖核心内容。这背后是缺少色板生成算法，处于纯靠"经验感觉"生成的状态。

第二种是"有样式无系统"。产物里确实有 CSS 变量，但变量层级只有一层，组件 A 用了--card-bg，组件 B 自己偷偷写死了一个#F5F7FA。表面上能跑，实际按照设计系统的标准，这属于半成品。

第三种是"一次性彩票"。同一个 prompt 跑十次，每次出来一套完全不同的颜色和字体。如果给客户做演示还好，但如果你想把这套流程接到公司内部系统上，这种不确定性直接导致不可交付。

theme-factory 的存在，本质上就是为了把第三种变成确定性的动作，把第二种压缩成一次自检就能发现的问题，把第一种直接扼杀在第一步。

1.2 这个 Skill 的基本定位

用一句话概括：它是一个让 AI 在生成主题时遵循"设计系统方法论"的技能包。你给它一个目标描述、一张参考截图、或者只是一段品牌说明，它会按照固定的生产管线运作——提取风格意图、拆解色彩与排印需求、生成结构化的设计令牌和主题代码、再做一轮自检，最后输出一份可继承、可维护、可打包的主题工程。

它不是教你写 CSS（那太低级了），也不是替你完成视觉创意（那也不现实）。它更像是插在"设计意图"和"可上线代码"之间的那根质量控制器。

2. 拆包 theme-factory：技能指令、语义边界与执行触发

既然说是官方 Skill，那它的载体自然是一个标准技能包。实际内容并不复杂，核心就是一整套 SKILL.md 指令连同少数辅助模板文件。我把它拆开之后，真正有价值的部分其实在三层：输入协议、输出协议、决策规则。

2.1 技能的基本形态：指令文件与触发逻辑

Skill 的本质是一份写给大模型的"岗位说明书"。拿到模型手上后，模型会根据对话内容判断是否需要激活它。触发逻辑的关键词自然包含 theme、palette、design tokens、皮肤、配色 这些语义，但我试过直接说"帮我的博客换个好看的样子"，系统同样能调起来——说明触发条件是语义化的，不是死板的字符串匹配。

这份说明书会定义几个关键要素：

• 能力边界：什么能做，什么不能做；
• 输入要求：需要哪些参数，缺失时怎么处理；
• 工作步骤：从分析到产出一共几大步；
• 约束条件：命名规则、色彩标准、默认值；
• 输出格式：文件清单和内容结构。

有意思的是，它还会明确要求模型在执行前先做"意图理解回显"。也就是说，它不是直接开干，而是先用自己的话复述一遍任务，再列出假设和参数，让你确认之后才动手。这个设计看起来像个笨步骤，实际极大避免了"设计意图被误读五条街"的悲剧。

2.2 输入协议：先补齐参数，再谈生产

我在实际使用中总结出的核心输入字段包括这些：

我最在意的是第 4 和第 5 项。如果你只给"明亮"两个字，模型会默认走一套很安全的浅色方案，但如果你想的是"舒适的夜间阅读模式"，那必须在 constraints 里写明背景色要给低亮度值。这些参数最后会被转化成一套内部基线，供后续所有决策作锚点。

2.3 输出协议：四类产物缺一不可

它产出的不是一个 CSS 文件，而是一个文件族。默认情况下会包含：

• design-tokens.json：所有颜色、字体、间距、圆角、阴影的数值化定义；
• theme.css：基于 tokens 编译出的 CSS 变量文件，支持明暗模式切换；
• theme-guide.md：一份面向使用者的人类可读说明，包含色板展示、用法示例；
• integration-tips.json：如果目标是特定平台，会额外产出适配配置提示。

这套输出结构最大的好处在于：即使你完全不认同它的配色方案，你依然可以直接拿着 tokens 文件去改数值，而不用在几十个样式文件里海里捞针。这个"先项目化，再审美化"的顺序，是工程经验最集中的体现。

2.4 内建的决策规则与降级策略

官方 Skill 里最容易被忽视的其实是几个降级逻辑。当输入信息不足时，它不会硬着头皮瞎猜，而是按优先级触发默认规则：

• 未提供品牌色：默认使用一组中性蓝色作为主色，并显式告知这是占位色；
• 未说明目标平台：默认走 Web CSS 变量方案；
• 目标平台之间冲突：比如要求同时兼容某设计软件和 Web，它会生成两套导出物并分别标注；
• 参考图无法识别色彩：它会量化提取主色区，而不是强行逐像素去匹配。

这些降级策略让我意识到，这个技能的设计者非常清楚大模型的短板：它擅长看到语义，却不擅长憧憬未知。与其让模型放飞自我生成一套"想象中的主题"，不如让它老老实实基于可验证的基线做扩展。所以，我后来用的时候几乎都会刻意留一个参数不填，观察它如何处理缺省值——这本身就是对模型心智模式的一次很好的压力测试。

3. 一次完整实操：把一段设计意图变成可发布主题包

理论说够了，我们直接来过一遍完整的工作流。为了模拟真实场景，我这次没有用现成品牌色，而是给了一段模糊描述："一个适合中文技术博客阅读的主题，明亮但不过曝，强调内容沉浸度，代码块要清楚，需要有深色模式。"

3.1 输入材料准备与意图确认

第一轮我先丢出上面的描述，没有任何额外参数。模型首先做了意图回显，我把它理解出来的要点摘取一下：

• 色彩取向：高明度背景、低纯度中性色、模块间用阴影而非重边框分隔；
• 代码块偏好：高对比背景、等宽字体、语法高亮不能刺眼；
• 深色模式：保持同色相体系，但明度整体下移 30~40%；
• 字体策略：优先系统字体栈，中文优先使用无衬线，等宽字体用于代码。

回显出来的东西和我的本意基本一致，这是一个好信号。确认之后，它主动要求我补充两个参数：主题命名（我定了 tech-reading）和目标平台（Web），然后就进入了生产阶段。

3.2 从色彩基线到设计令牌

第一步是确定主色。由于没有品牌参考，它选取了偏冰冷的蓝灰色 #2563EB 衍生系作为强调色，中性色则是带一点点灰底的低饱和白 #F7F8FA。这里有个细节让我很满意：它不是简单地给三四个色值，而是直接生成了一个 10 阶的色阶梯度。

我后来单独问过它的取色逻辑，才发现它默认在 OKLCH 色空间里做插值。这非常重要，因为传统 HEX 颜色在渐变插值时，中间色经常发灰、偏脏，人眼感知不均匀。OKLCH 解决的是"看起来均匀"的人眼感知问题。这一点如果你是自己手动调色，几乎不会想到，但它对于生成一个专业的 10 阶色板却是决定性的。

生成的 tokens JSON 长这样：

{ "brand": { "primary": { "50": "#EEF3FE", "100": "#DCE6FC", "200": "#BBCEF9", "300": "#93AFF4", "400": "#5C88ED", "500": "#2563EB", "600": "#1D4ED8", "700": "#1E40AF", "800": "#1E3A8A", "900": "#172554" }, "neutral": { "bg": "#F7F8FA", "surface": "#FFFFFF", "border": "#E5E7EB", "text": "#111827", "muted-text": "#6B7280" } }, "semantic": { "success": "#10B981", "warning": "#F59E0B", "danger": "#EF4444", "info": "#3B82F6" }, "dark": { "bg": "#111827", "surface": "#1F2937", "border": "#374151", "text": "#F9FAFB", "muted-text": "#9CA3AF" } }

注意它把深色模式下的颜色列完整了，不只是一个dark-bg就收工，而是一整套完整的中性色阶。这就是专业系统和个人随手写的分水岭。

3.3 主题 CSS 与组件变量映射

tokens 确定之后，下一步是把它映射到 CSS 变量，并细化组件级状态。它生成的 CSS 片段里，我最喜欢的是按钮部分的实现：

:root { --th-bg: #F7F8FA; --th-surface: #FFFFFF; --th-primary: #2563EB; --th-primary-hover: #1D4ED8; --th-primary-active: #1E40AF; --th-primary-disabled: #93AFF4; --th-border: #E5E7EB; --th-text: #111827; --th-muted: #6B7280; --th-radius-md: 8px; --th-shadow-sm: 0 1px 2px rgba(0,0,0,0.05); --th-shadow-md: 0 4px 8px rgba(0,0,0,0.08); } .btn-primary { background: var(--th-primary); color: #FFFFFF; border-radius: var(--th-radius-md); box-shadow: var(--th-shadow-sm); transition: background 0.2s ease, box-shadow 0.2s ease; } .btn-primary:hover { background: var(--th-primary-hover); box-shadow: var(--th-shadow-md); } .btn-primary:disabled { background: var(--th-primary-disabled); cursor: not-allowed; }

注意--th-primary-disabled不是随便找了一个浅色调出来的，它是基于主色色阶的第 300 级，同时做了饱和度调整，避免"看起来是灰的但带一点点脏蓝"这种廉价感。悬停态用的是比主色更深的 600 级，这种语义化取色规则，完全符合设计系统里常见的"按色阶步进"模式。

3.4 对比度自检与人工复核

输出最后，它没有直接说"完成了"，而是给了一张自检清单，每一条都标了实际的对比度数值：

• 正文 #111827 在 #F7F8FA 背景上的对比度约为 14.1:1，满足 AAA 标准；
• 深色模式正文 #F9FAFB 与 #111827 背景对比度约为 15.3:1，同样满足；
• 强调色 #2563EB 作为普通 UI 组件的背景时，白色文字的对比度约为 4.6:1，满足 AA 标准；
• 但muted-text#6B7280 在白色背景上的对比度只有约 4.1:1，作为正文刚好踩线，作为小字号辅助文字则不达标。

最后一条它主动提醒我：如果辅助说明文字会比较小，建议把muted-text调深一档到 #4B5563，这样对比度会提升到约 7.1:1。这个自我纠偏动作让我很意外，因为它不是简单罗列参数，而是真正基于排版场景做了风险判断。这其实也是 skill 内置的决策规则在起作用——它被要求"在每个可能影响可读性的地方做一次额外的合理性检查"。

到这里，主题包的核心部分已经齐整了。如果你只是想自己用，theme.css和 tokens 文件就够了；如果你打算投入到生产环境，接下来还得处理我踩过的那些坑。

4. 实测翻车日志：五个高频问题与修复链路

再好的 skill 也不是免死金牌。我在重复测试中遇到过大量翻车场景，这里挑五个最有代表性的，把完整排查链路写出来。排查思路比答案本身更值得看。

4.1 近似色让 contrast 静默失守

第一次跑深色模式配色的时候，产物看起来一切正常：背景 #111827，文字 #E5E7EB。肉眼看上去对比度显然没问题，可我一测，发现某个小号辅助文字实际用的是 #9CA3AF，这个颜色在 #111827 上对比度只有大约 5:1，按 UI 组件标准是合格的，但按小号正文的 4.5:1 也勉强，如果用户把屏幕亮度调低，几乎看不清。

根因在于：技能生成 10 阶色阶时，第 400 级和第 500 级之间的差异在人眼看来非常接近，AI 把它当作"可以用作辅助文本"的色值，但实际数值上仍存在风险。

修复方法是给 skill 增加一条硬规则：所有语义文本色必须经过显式对比度计算，如果低于阈值，自动后退一档色阶。后来我还让它在输出注释里直接写上"本色值对比度通过 AA"字样，方便我在代码里一眼验证——把隐性问题变成显式注释，这个思路在任何自动化工具里都通用。

4.2 命名习惯漂移导致多组件无法对齐

有一版输出让我印象深刻：token 命名里同时出现了--font-main、--family-sans、--text-font三种写法，分别出现在 头部、正文、侧边栏 的样式里。单独看每一段都正常，合在一起就"精神分裂"。这种情况比颜色错误还阴险，因为它不报错，你自己的开发体验会非常痛苦。

出现原因是模型在一个比较长的输出流程中，一开始选定了某个命名体系，执行到后面上下文注意力衰减，又换了一套"同义但不同形"的命名。要避免这个，不能靠"记得保持一致"这种软指令，而是要靠"命名规范表"硬约束。

我在 skill 的文件里加了一个命名 Schema 强制块，把常用 token 的命名前缀做成枚举表格，禁止出现任何不在表内的变量名。效果立竿见影，后续几乎没再出现过同类问题。这一步的经验是：凡是需要跨组件保持稳定的概念，绝对不能用自然语言约束，必须用枚举结构约束。

4.3 参数缺失导致整套系统崩溃

有一次我只丢了一张截图进去，没给任何文字描述。当时预期是它能从截图里自动提取品牌色，结果产出的色板完全偏离，它把截图里暗角阴影的颜色当成了主色调，导致生成的是一个灰色调主题，跟我想要的完全相反。

排查后发现，它在"截图 → 色彩量化"这一步采用的是像素聚类取主色，但那张截图的视觉中心是亮色，角落是大面积暗影，聚类算法把暗影当成了信息量更大的区域，于是主色取成了深灰。这不能全怪模型，因为输入本身有歧义。

修复方法是我给输入协议加了一个focus-region字段：提交截图时可以用文字标注"取画面中央 50% 区域的主色块"，也可以直接框选区域。如果不标注，技能就必须向用户二次确认主色区域，而不是自作聪明。从这次之后我养成了一个习惯：凡是涉及参考图的任务，宁可多写一句区域描述，也不要省。

4.4 有了完美 CSS，组件碎片却接不上

某次生成的目标平台是 VS Code 主题，它给出了非常完整的tokenColors配置，单个看毫无问题。但当我把它导入编辑器后，发现代码注释的斜体样式莫名丢掉了，某些语法高亮层的foreground引用了一个未定义的 token 名。

这种情况的本质是"输出内部不一致"——主题主体是从设计系统基线生成的一套独立令牌，而编辑器专属映射是另一套逻辑生成的，两套逻辑在模型内部没有共享同一个中间表示。换句话说，它"分别正确"了，但没有"整体对齐"。

修复链路比想象中简单：对所有平台专属输出，技能必须先行输出一份共享中间表示（比如设计令牌 JSON），再从这个 JSON 派生出各平台的具体配置。只要该平台产物里的每个颜色都严格引用自这份 JSON，就不会出现指向不存在变量的情况。我把这一步叫"单一事实源校验"，强烈建议所有做过主题迁移的人都检查一下自己的产物是否符合这个原则。

4.5 上下文污染：上一个主题的影响渗透进下一个

连续测试多套主题时，我遇到一个很难察觉的问题：第三个主题的深色模式背景色里，混进了第一套主题的色相。从数值上看，它确实生成了新色板，但色相偏移的规律明显是拿旧主题当参考了。

原因很直接：AI 在处理连续任务时，对话上下文里前几轮的历史主题会形成"隐式先验"。如果前一套主题是个红色系，后面生成蓝色系主题时，深色模式里的蓝灰色会不自觉地偏紫。

这是所有 AI 工具在资产生产中都可能踩到的坑。我的对策是在进入新主题生成前，强制插入一条重置指令，并让技能输出一版"基线声明"——声明本次任务与前序任务的边界、本次使用的原始参数、以及确认不使用任何历史主题的颜色信息。一般来说这样一轮操作之后，颜色就能回到正常轨道。别小看这个动作，它几乎是我测试中最常重复做的一件事。

5. 把官方技能私有化：让它成为团队自己的设计系统生成器

官方 Skill 默认是一套通用方法论，但用在我们团队内部时，我会做三处定制。做完整套调整之后，它的产出才真正贴合我们的视觉语言。

5.1 扩充风格描述词库，缩小模型自由发挥空间

默认情况下，模型的风格理解非常宽泛。"现代"两个字它能联想到十几种方向，这对一个追求一致性的品牌来说是不确定的源头。所以我们做了一本"风格词汇表"，把内部认可的设计语言全部枚举出来：用了哪种色彩倾向、边界条件下偏好怎么处理、什么情况下需要加粗边框、什么情况下完全禁止渐变。

这本词汇表会被直接附加进 skill 的知识文件里。从此，"轻量现代"在我们团队内部就是一个有确定含义的词，对应明快的背景和克制的阴影；"重专业"则是深色页眉加高信息密度表格。这套自定义词表越厚，模型的产出就越贴近团队审美。

5.2 让主题包对接到自己组件库的变量层

我们团队前端用的是组件库里一套根据经验沉淀下来的变量体系，和官方 skill 默认的--th-前缀体系不一样。直接套用官方产出的 CSS 变量，意味着还要再做一层迁移，浪费工时不说，迁移过程还可能漏掉一两个变量。

我的做法是直接改写技能的输出协议：把所有默认输出前缀映射到团队已有的规范前缀，比如--th-primary改为--ui-color-brand-strong。同步在 skill 里内置了一个团队令牌映射表，起到字典的作用。这样一家通用工具的产物，一旦进入我们团队就是原生语言，不需要翻译。

5.3 增加回归验证环节：让 AI 做 AI 的质检员

这是在一次大规模主题重构后总结出来的办法。我们几十套主题并行修改时，靠人工逐个检查对比度几乎不可能。后来我写了一套约束检查 prompt，在技能生成完主题后，自动把产物立即交回给另一轮"审查员角色"做回归检测：

• 检查命名是否全部在许可枚举表内；
• 检查引用是否全部指向已定义变量；
• 检查对比度是否线性满足阈值；
• 检查深色模式和浅色模式是否使用同一套语义色映射。

如果审查员角色发现问题，它必须先描述根因、再给修复建议，然后重新提交一轮生成。实际上这等于把"作者-评审-修改-复审"这个敏捷流程整套交给 AI 来执行，其中的角色切换是通过提示词实现的。因为 skill 天然支持多轮角色切换，这个扩展比预想中轻松得多。

6. 进阶玩法：从单套主题到批量主题矩阵

如果你已经把 theme-factory 用顺手了，我建议再玩一玩它最擅长的事情：批量生产主题族，而不是一套一套手搓。这纯粹是效率层面的巨大跃迁。

6.1 一次输入，输出整个风格矩阵

我给同事们演示过一个玩法：提交一个 CSV 文件，里面每一行是一个主题的参数组合，包括不同的主色、风格标签、平台目标。我在提示词里让 skill 按照 CSV 逐行执行生成，并确保每套主题的产物都输出到独立命名空间。结果一次任务跑下来，一小时左右的时间，我们拿到 12 套主题的完整 tokens 和 CSS 文件。

这个能力对跨境电商、SaaS 多租户、或者要给不同客户品牌做皮肤定制的团队几乎没有成本，收益却巨大。以前一个前端开发一周只能交付两套精细主题，现在模型介入以后，可以把产能的瓶颈从"生成"转移到"审美验收"上，这是完全不同量级的效率。

6.2 多平台主题的一致性维护

typo——我说的是一致性。真实业务中很常见：你给 Web 端做了一套主题，还需要给客户端加一套品牌皮肤。如果两边由不同的人维护，很快会魔法般失去联系。有了这个技能以后，我习惯让它在同一份设计令牌 JSON 的基础上，同时派生 Web CSS 主题和客户端主题描述文件。这样改一个主色，全平台同步生效，从根本上避免"Web 是蓝色，客户端却变成绿色"的尴尬。

6.3 和构建流程集成：让主题生成变成自动化工序

再往前走一步，是用脚本把 skill 的输出接入到你已有的 CI 流程。比如在主题仓库里提交一个配置文件，触发器执行后自动调用 AI 生成所有缺失的模板变量，再走一遍对比度质检，输出结果作为静态资源发布到 CDN。这样做的好处是即使你不设计新主题，每次风格升级都能自动验证老主题在新规则下是否仍然合规。

当然自动化会很复杂。我的建议是先跑通手动流程，再把 review 环节固化成固定的提示模板，最后才算到自动化。不要跳过中间那一步，否则出错都不知道在哪一环。

在我自己用了三个月之后，最后想说的只有一件事：官方 skill 的价值不在于它多聪明，而在于它把"美术直觉"变成了"可执行的工程流程"。如果你现在还在用"请生成一个好看的主题"这种提示词去驱动 AI，我强烈建议你把这个技能包拿回去拆开看一眼。把它的输入协议、输出结构、审查逻辑全部剥开，你会突然明白，原来那些看起来让人眼前一亮的主题，背后其实是一整套非常冷静的判断规则。

最后再分享一个小技巧：正式投入使用之前，请记得为它准备一份你自己品牌的"基线审查清单"，并把所有硬性约束写死在技能描述里。别高估模型的自觉性，也别低估它的潜力——你给它的规则越清晰，它能转动的半径就越大。