用 Skill 封装单色系设计规范：从 Prompt 到可校验的 AI 设计技能包

如果你最近在关注 AI Agent 与设计工具的结合应该会发现一个明显变化设计类能力正在从“对话里的临时约定”变成“可安装、可复用的技能包”。妍妍老师发布的 Mono-color Design Skill就是这类实践里很有代表性的一个案例。标题里的 Mono-color 对应“单色系”设计Skill 则是当前 AI Agent 生态中非常关键的一种扩展方式。乍看之下它只是把“单色系设计”这一条规则封装成技能。但真正值得关注的不是某一个具体配色方案而是 Skill 机制带来的工作方式转变以前你让 AI 做一张单色海报需要从色板、排版、对比度、风格一遍遍补充要求现在只要挂载一个 SkillAI 就会自动按照预设的设计规范执行。换句话说设计师沉淀下来的不只是提示词而是一套可复用、可校验、可持续迭代的流程资产。这篇文章会把这个案例拆开讲清楚。我会先用开发者的视角解释 Skill 到底是什么再讲 Mono-color 单色系设计的方法论然后给出一个可以直接模仿的 Skill 文件结构、完整配置和校验脚本。读完你可以照着做一个属于自己的“XX 设计 Skill”也可以把这套思路迁移到品牌规范、数据可视化配色、前端 Design Token 管理等工作场景中。1. 这篇文章真正要解决的问题很多人第一次接触设计类 Skill 时会有一个错觉这不就是把一段“设计规范提示词”保存到一个文件里吗如果只是这样那确实不值得单独写一篇文章。真正的问题在于设计规范和普通提示词有本质区别。普通提示词是告诉 AI“你要做什么”设计规范则必须回答“你按什么标准做、做到什么程度算合格、出错了如何修正”。在实际项目里设计规范往往有大量隐性知识。比如“主色旁边的浅色不能太灰”“文本色和背景色的对比度不能低于某个值”“同一套方案里的色相偏差不能超过多少度”。这些细节如果只放在对话里AI 每次都要重新理解结果就是输出不稳定同一个主色换个会话生成的结果风格完全对不上。妍妍老师发布 Mono-color Design Skill 这个案例真正解决的问题是把一套单色系设计规则固化成 AI Agent 可以自动加载的“能力模块”。它让 AI 在生成设计前先读取规则生成后用参考数据和脚本进行校验最终输出的是有依据、有结构、可以被评审的结果。什么样的读者最应该关注这篇文章设计师希望把品牌配色规范交给 AI 执行而不是反复手动修改图片。前端工程师在做 Design Token 或主题系统时需要从主色生成整套色阶。AI Agent 开发者想理解 Skill 的文件结构、编写方法和调试方式而不是只会写 Prompt。数据可视化同学希望图表配色保持统一品牌色相不再靠肉眼挑色号。一句话总结第一章设计类 Skill 的价值不在于“写了一段提示词”而在于把设计判断力编码成了可复用资产。2. Skill 机制设计类 AI 能力的新载体2.1 什么是 SkillSkill 是 AI Agent 生态中用来扩展模型能力的一种标准方式。通俗来说它是一组文件包含“技能说明”和“参考资源”放在指定目录后AI 客户端或开发框架会在合适的时机自动加载这些内容。对模型来说Skill 相当于一份可以随任务调用的“岗位说明书”对使用者来说Skill 相当于一个可以安装、卸载、版本管理的技能插件。以当前主流 Skill 机制为例一个 Skill 通常以目录形式存在mono-color-design-skill/ ├── SKILL.md └── references/ └── mono-color-scale.jsonSKILL.md是核心文件描述技能的目标、触发条件、执行步骤和输出格式。references目录存放模型需要查询的参考数据比如色阶表、设计格栅、品牌字体等。当用户在对话中输入“请生成一套单色系方案”时Agent 会根据技能描述判断是否需要加载该 Skill。如果匹配它会把 SKILL.md 和参考文件内容一并送入上下文再生成回答。不同平台的文件规范略有差异但整体思路非常相似。2.2 Skill 与普通 Prompt、Plugin 的区别理解 Skill 的最好方式是把三者放在一起对比对比维度普通 PromptSkill 技能包Plugin 插件知识存放靠用户每次描述随技能文件加载通过 API 获取外部服务规则稳定性每次重新约定统一加载结果稳定偏执行能力可测试性靠人工肉眼判断可配合脚本校验依赖服务可用性复用性低可跨项目挂载可跨应用使用团队协作依赖个人经验可版本管理、评审需要服务端部署普通 Prompt 是“一次性约定”Skill 是“持久化约定”Plugin 则是“外部能力接入”。设计规范这类知识型内容天然适合放在 Skill 中而不是写成 Plugin。因为设计规范本质上是文档和判断规则不是需要连接数据库或调用第三方 API 的强逻辑服务。2.3 为什么说 Skill 适合承载设计规范设计规范有三个特点可标准化、强约束、需要参考样例。可标准化意味着我们可以把“文本对比度至少 4.5:1”写成规则强约束意味着 AI 不能在浅色背景上放浅色文字需要参考样例意味着单一自然语言描述不足以覆盖所有边界情况。Skill 恰好同时满足这三点。SKILL.md里的规则文本解决前两点references目录里的色阶 JSON 解决第三点。更重要的是Skill 可以随项目一起放在 Git 仓库中。每次调整色阶或规则都能留下变更记录这对团队协作非常关键。这也解释了为什么设计类 Skill 会越来越多它把原本存在于设计师脑海中的判断标准变成了组织可以沉淀的资产。3. Mono-color 设计的核心方法论3.1 单色系设计的难点如果只看“单色系”这个名称很容易误以为让 AI 生成单色设计很简单只要用一种颜色就行。但真实情况恰恰相反单色系设计是最容易“翻车”的配色方案之一。原因在于去掉多色对比后只能靠明度和饱和度的变化来区分信息层级。如果色阶设计不好整套界面会变得很平或者看起来脏兮兮的。举个常见例子AI 生成的单色系方案往往只有两三个深浅不同的蓝色放在一起层次缺失用户根本无法判断哪个是主按钮、哪个是辅助按钮。所以让 AI 学会单色系设计不是在 Prompt 里写一句“使用单色系风格”而是要教会它一套完整的色彩系统构建方法。3.2 色相、明度与纯度单色系设计基于同一色相通过控制两个维度来形成层次明度颜色的明暗程度。明度越高越接近白色越低越接近黑色。纯度颜色的鲜艳程度。纯度越高越鲜艳越低越接近灰色。在 HSB/HSV 色彩模型中色相决定了“这是蓝色还是红色”饱和度和明度则决定“这个蓝色是深还是浅、是鲜还是灰”。单色系方案的基本原则是保持色相不变让饱和度和明度按梯度变化。这里最容易踩坑的地方是很多 AI 模型在生成视觉图时并不会严格保持同一色相。比如用户指定主色为蓝色结果 AI 输出里出现了一些偏紫或偏青的颜色。这在专业设计里是不可接受的。因此一份合格的 Mono-color 设计 Skill必须包含“色相一致性校验”规则。3.3 从主色到色彩系统色阶表怎么设计在实际项目中我们很少直接使用单个主色而是从主色衍生出一整套色阶。最常见的做法是设计 50 到 900 共 10 个层级类似很多设计系统里的中性色板{ baseColor: #2563EB, colorScale: [ { step: 50, hex: #EFF6FF }, { step: 100, hex: #DBEAFE }, { step: 200, hex: #BFDBFE }, { step: 300, hex: #93C5FD }, { step: 400, hex: #60A5FA }, { step: 500, hex: #3B82F6 }, { step: 600, hex: #2563EB }, { step: 700, hex: #1D4ED8 }, { step: 800, hex: #1E40AF }, { step: 900, hex: #1E3A8A } ] }这个示例以#2563EB作为主色从浅到深生成 10 个层级。浅色用于页面背景、分隔区域、状态提示中色用于图标、辅助按钮、边框深色用于正文、主按钮、强调内容。如果输入材料没有给出现成色阶Skill 也应该具备生成能力从主色出发按固定步长调整饱和度和明度输出一套可用的色阶。关键是所有层级必须保持同一色相。3.4 对比度与文本可读性单色系设计第二个核心难点是文本可读性。因为同一色相的颜色在视觉上的差异没有互补色那么明显浅蓝背景配深蓝文字通常没问题但浅蓝背景配中蓝文字就很容易看不清。判断文本可读性最常用的标准是 WCAG 对比度。普通正文文本要求对比度不低于 4.5:1大号文本不低于 3:1。在 Skill 中这些数值可以直接写成规则让 AI 在生成方案时自动避开低对比度组合。更稳妥的做法是同时提供校验脚本用 Python 或 Node.js 读取生成的色阶 JSON自动计算文本色与背景色的对比度。如果某项组合不达标脚本直接输出警告。这样就把“设计审美”变成了“可检查的工程质量问题”。4. 环境准备与前置条件在实际动手编写 Skill 之前先确认你的运行环境。本文的示例以通用 Skill 目录结构为准不绑定某个特定平台的版本。如果你使用的是支持 Agent Skill 机制的客户端或开源框架通常需要满足以下条件一个支持 Skill 机制的 AI Agent 客户端或开发框架具体名称和版本以你使用的工具为准。一个代码编辑器推荐 VS Code方便查看 JSON、Markdown 和 Python 文件。本地环境建议安装 Python 3.8 或以上版本用于运行校验脚本。如果不想装 Python也可以用 Node.js 或在线 JSON 工具做亮度校验。一个测试用主色 HEX 值例如#2563EB后续示例都基于它展开。版本方面我不建议把某个具体版本号写死。Skill 文件格式和框架调用方式还处于快速变化阶段今天可用的字段明天可能被兼容性更好的新字段替代。你更应该掌握的是“目录结构 SKILL.md references 校验脚本”这套最小可运行组合。环境准备完成后我们进入核心部分手动创建一个 Mono-color Design Skill。5. 完整示例创建一个 Mono-color Design Skill5.1 目录结构与文件清单我们创建一个最小但完整的 Skill 目录包含 4 类文件mono-color-design-skill/ ├── SKILL.md ├── references/ │ └── mono-color-scale.json ├── scripts/ │ └── check_mono_palette.py └── examples/ └── prompt-example.mdSKILL.md技能主文件包含元信息、设计规则、执行流程。references/mono-color-scale.json标准色阶参考数据供模型查询。scripts/check_mono_palette.py校验脚本用于验证生成结果的色相一致性和对比度。examples/prompt-example.md调用示例方便团队成员理解怎么使用这个 Skill。5.2 编写 SKILL.md这是整个 Skill 最核心的文件。你可以在SKILL.md中描述技能的目标、触发条件和输出格式让 AI Agent 知道什么时候该加载它以及加载后按什么流程执行。--- name: mono-color-design-skill description: 基于单一主色生成完整单色系色彩方案包括色阶、界面配色和设计说明。 version: 1.0.0 metadata: author: demo-team tags: [design, mono-color, ui] --- # Mono-color Design Skill ## Skill 目标 当用户要求执行“单色系设计”“Mono-color Design”或“生成单色配色方案”时加载本技能输出一套符合品牌规范的完整单色系色彩系统。 ## 输入要求 - 主色 HEX由用户提供或从用户给出的品牌色、图片中提取。 - 应用场景UI 界面、数据可视化、海报、PPT 等。 - 输出语言默认中文。 ## 设计规则 1. 色相一致性所有色块与主色的色相偏差不超过 8 度。 2. 色阶层级优先参考 references/mono-color-scale.json按 50-900 共 10 级输出。 3. 对比度要求正文文本与背景对比度不低于 4.5:1大号文本不低于 3:1。 4. 输出结构必须包含 - 主色 HEX 与说明 - 10 级色阶表 - 各场景下的配色建议 - 文本可读性校验结果 5. 禁止生成与主色色相偏差较大的颜色作为同类色阶。这段 SKILL.md 做了三件事定义触发条件、给出输入约束、明确输出结构。AI 只有在任务匹配时才会加载它加载后也不需要用户再重复设计规范。如果你使用的平台支持自定义字段可以参考这个结构调整。5.3 准备色阶参考文件参考文件的价值是让模型不需要“凭空想象”一套色阶而是能直接基于已有数据做适配。下面是一个标准蓝色系的 JSON 色阶参考文件。{ baseColor: #2563EB, description: 示例主色 #2563EB 的 10 级单色色阶仅作为训练参考数据, colorScale: [ { step: 50, hex: #EFF6FF }, { step: 100, hex: #DBEAFE }, { step: 200, hex: #BFDBFE }, { step: 300, hex: #93C5FD }, { step: 400, hex: #60A5FA }, { step: 500, hex: #3B82F6 }, { step: 600, hex: #2563EB }, { step: 700, hex: #1D4ED8 }, { step: 800, hex: #1E40AF }, { step: 900, hex: #1E3A8A } ], usage: { background: [50, 100], border: [200, 300], secondaryAction: [400, 500], primaryAction: [600], text: [700, 800, 900] } }{ recommendedTextPairs: [ { background: #EFF6FF, text: #1E3A8A, contrastRatio: 10.1:1 }, { background: #DBEAFE, text: #1E40AF, contrastRatio: 8.6:1 }, { background: #FFFFFF, text: #2563EB, contrastRatio: 5.2:1 } ] }实际使用时你可以把第二个 JSON 文件放到references目录中也可以合并到同一个文件里。参考数据的价值在于给模型一个“安全区”避免它随意组合出低对比度配色。上面标注的对比度数值是示意值实际数值取决于你的色值计算方式建议运行脚本验证。5.4 设计校验脚本有了规则和参考数据还需要一个“裁判员”。下面的 Python 脚本可以读取色阶文件逐一检查每个色块与主色的色相偏差并提示对比度风险。# 文件路径mono-color-design-skill/scripts/check_mono_palette.py import sys import json import colorsys def hex_to_rgb(hex_color: str): hex_color hex_color.lstrip(#) if len(hex_color) ! 6: raise ValueError(finvalid hex color: {hex_color}) return tuple(int(hex_color[i:i2], 16) / 255.0 for i in (0, 2, 4)) def rgb_to_hsv(rgb): return colorsys.rgb_to_hsv(rgb[0], rgb[1], rgb[2]) def main(palette_path: str, base_hex: str, hue_tolerance: float 8.0): with open(palette_path, r, encodingutf-8) as f: palette json.load(f) base_hsv rgb_to_hsv(hex_to_rgb(base_hex)) base_hue base_hsv[0] * 360 print(fbase hue: {base_hue:.1f}) for item in palette[colorScale]: step item[step] hex_color item[hex] hsv rgb_to_hsv(hex_to_rgb(hex_color)) hue_deg hsv[0] * 360 hue_diff abs(hue_deg - base_hue) if hue_diff 180: hue_diff 360 - hue_diff ok hue_diff hue_tolerance status OK if ok else WARN print(fstep {step:3} {hex_color} hue{hue_deg:6.1f} {status}) if not ok: print(f warning: hue difference {hue_diff:.1f} exceeds tolerance) if __name__ __main__: if len(sys.argv) ! 3: print(usage: python check_mono_palette.py palette.json base_hex) sys.exit(1) main(sys.argv[1], sys.argv[2])运行方式python scripts/check_mono_palette.py references/mono-color-scale.json #2563EB如果所有色块的色相偏差都在 8 度以内脚本输出 OK如果某个色块偏色会输出 WARN 并给出偏差值。这个脚本的边界能力有限但已经足够作为设计质量门禁之一。5.5 在 AI 客户端中调用Skill 文件准备好后把它放到你使用的 AI Agent 可以识别的位置。不同工具对 Skill 目录的存放位置要求不同这里只演示调用思路请加载 mono-color-design-skill主色为 #2563EB应用场景是数据看板 UI输出一套包含主色、深浅色阶、功能状态色的单色系方案。AI 收到请求后会先判断任务与 Skill 是否匹配再读取规则和参考数据最后按 SKILL.md 规定的结构输出结果。如果你发现 AI 没有加载 Skill优先检查目录位置和 SKILL.md 中的触发描述是否准确。6. 运行验证与效果检查一个 Skill 是否真的可用不能只靠“看起来挺好看”来判断。下面给出三个最小验证用例你可以按顺序执行。6.1 验证用例一基础色阶生成输入请加载 mono-color-design-skill主色 #2563EB应用场景为网页 UI。检查点是否输出了至少 10 级色阶。色阶中的浅色端和深色端是否存在明显明度差异。是否包含文本对比度的说明。如果 AI 只输出了一两个蓝色色值说明 SKILL.md 中的“色阶层级”规则没有被完整加载。此时可以检查描述是否写入了触发条件或者当前 Agent 平台的上下文长度是否不足。6.2 验证用例二色相一致性与校验脚本用参考文件运行校验脚本python scripts/check_mono_palette.py references/mono-color-scale.json #2563EB预期结果是所有 step 都输出 OK。如果某个 step 出现 WARN说明该色块不是标准单色色阶需要重新生成参考数据。这个步骤的意义在于它把“是否偏色”从感觉判断变成了可重复执行的客观检查。6.3 验证用例三低对比度拦截输入一个极端情况请加载 mono-color-design-skill主色为浅黄色 #FDE68A背景用最浅色文字用中等黄色。此时 Skill 规则应要求 AI 明确指出对比度不足并自动选择 700 到 900 等深色作为文本色。如果 AI 仍然生成了低对比度方案说明对比度规则的表达不够具体建议在 SKILL.md 中把“4.5:1”和“3:1”这两条数值写得更显著。验证失败的排查顺序可以这样走先确认 Skill 目录是否放对位置。再确认 SKILL.md 中触发描述是否包含用户输入中的关键词。然后查看生成结果是否参考了 references 文件。最后检查规则本身是否不够量化比如“对比度要足够高”就不如“对比度不低于 4.5:1”可执行。7. 常见问题与排查思路问题现象可能原因排查方式解决方案AI 没有识别 SkillSkill 目录未放在工具指定位置查看客户端帮助文档确认目录结构将 Skill 目录移到指定路径重新加载会话SKILL.md 内容不生效触发描述过于宽泛或过于狭窄打印实际加载日志调整 description用明确关键词覆盖“单色系”“Mono-color”等输出颜色不是同一色相模型没有使用参考色阶文件检查 references 路径是否正确在 SKILL.md 中写明 references 路径并放入示例数据色阶层级太浅层次不明显明度梯度设置不够大用脚本输出 HSV 明度值增大相邻 step 的明度差深色端调整到接近 10% 明度文本对比度不达标规则中缺少量化标准检查输出中的对比度说明明确写入 4.5:1 与 3:1 两个阈值同一 Skill 在不同平台表现不同平台对 Skill 规范的支持程度有差异使用最小目录做兼容性测试优先使用通用字段不使用平台私有扩展字段生成的方案“灰扑扑”保饱和度过低或全部使用低饱和色查看输出色阶的饱和度值在规则中补充“主体区域保持一定饱和度”的建议表格中的排查思路适用于大多数 Skill 类项目。你在实践中遇到新问题可以先记录问题现象、复现方法和修复方案逐步形成团队的排错手册。8. 最佳实践与工程建议8.1 让设计规则显性化设计 Skill 能否生效很大程度上取决于规则是否可量化。像“美观”“高级感”这类描述模型很难稳定理解“文本对比度不低于 4.5:1”“色相偏差不超过 8 度”则可以被验证。建议在 SKILL.md 中把所有规则分成“必须遵守”和“建议参考”两类。必须遵守的规则写入校验脚本建议参考的规则保留在文本说明中。这样既保证了下限也保留了设计的灵活性。8.2 用数据文件管理色彩资产不要把所有颜色硬编码在 SKILL.md 里。更好的做法是把色阶、推荐文本组合、功能色定义放到 JSON 或 YAML 文件中由 SKILL.md 通过路径引用。这样做的好处是结构清晰、方便替换也让校验脚本可以直接读取数据文件。项目中可以维护一份标准的 color-token 数据文件前端生产环境使用时直接从这个文件生成 CSS 变量或设计令牌设计成果就能真正进入代码工程。8.3 团队协作与版本管理Skill 文件是普通文本文件完全可以用 Git 管理。建议每个 Skill 独立一个仓库或目录并在提交时附带示例输出截图或说明。这样当 AI 生成结果出现回归时可以快速定位是规则修改还是参考数据变更导致的。更好的做法是设置评审流程设计师负责制定规则开发者负责实现校验脚本测试同学用真实项目场景验证输出结果。经过几次迭代后这个 Skill 会越来越像一个标准化的内部工具而不是某个人私藏的一段提示词。8.4 安全与使用边界有一点必须强调设计类 Skill 不能替代人对品牌调性的最终判断。AI 可以按照规则生成色阶、计算对比度但它不理解品牌背后的商业含义。在使用任何 AI 生成设计结果前都需要经过设计师或品牌负责人的确认。同时如果 Skill 涉及公司内部品牌色、字体、素材需要在团队知识库中明确版权和授权边界。不要把未授权的商业素材直接放入 references 目录。另一个容易忽略的问题是风险操作如果 Skill 调用外部图像生成服务建议先在测试环境验证参数避免直接在生产环境批量生成不可回退的素材。8.5 从小场景开始做给团队落地设计 Skill 时不要一上来就做一个“全能设计助手”。建议从一个非常窄的场景开始比如“数据看板单色配色”跑通后再加上“海报单色配色”“PPT 单色配色”。窄场景的好处是边界清晰容易编写规则也容易验证效果。多跑几个窄场景之后你再回头抽象公共规则会发现思路清晰很多。9. 总结与后续学习方向妍妍老师发布 Mono-color Design Skill 这件事放到整个 AI Agent 发展进程中看是一个典型信号设计能力正在从“对话辅助”转向“工程资产”。Skill 把设计师的经验、规则与参考数据打包成可加载、可校验、可维护的文件让 AI 在设计任务上的表现不再依赖运气。本文真正讲清楚的几件事是Skill 机制与普通 Prompt/Plugin 的区别单色系设计为什么难以及色相、明度、对比度如何变成可执行规则如何用 SKILL.md、JSON 参考文件和 Python 校验脚本搭建一个最小 Skill以及在团队项目中如何安全、可控地落地这类能力。如果你已经照着示例跑通了一个最小 Skill下一步可以继续深入几个方向把色阶生成逻辑迁移到 Design Token 工程让前端直接消费 JSON 数据。增加进阶校验能力比如饱和度下限、无障碍颜色组合建议。尝试把同一套 Skill 挂载到不同 Agent 平台整理一份兼容性清单。从单色系扩展到双色系、渐变系抽象出更通用的配色规则库。对实际项目的提醒只有一点设计 Skill 的规则不是一次性写出来的而是通过真实项目不断改出来的。每发现一次输出不达标就补一条规则每新增一个场景就更新一次参考数据。先做最小版本再慢慢演进这会比幻想一个“万能设计神器”靠谱得多。