做设计的朋友应该都有过这样的体验好不容易用 AI 生成了一张满意的视觉稿结果让 AI “微调一下按钮颜色”之后整张图的风格直接跑偏或者前端同事想让 AI 按设计规范把 UI 转成代码结果每次都要把“主色 #2F54EB、圆角 8px、间距保持 4 的倍数”这段提示词复制粘贴一遍。提示词越来越长效果却越来越不稳定团队里很难沉淀出统一的 AI 设计工作流。最近被设计圈反复讨论的 AI Skills正好就是为了解决这一类问题而出现的。很多人都把 Skills 简单理解成“更长更结构化的提示词”实际上它是一个更完整的技能封装机制既包含让 AI 按什么流程工作的指令也包含可复用的设计规范、参考资料以及可执行的校验脚本。这篇文章会从概念讲起带你亲手做一个 UI 设计系统技能和一个 UI 转前端代码技能最后聊清楚“为什么这种机制会让设计界重视”以及团队落地时容易踩的坑。1. AI Skills 是什么设计场景带来的真正价值1.1 从“聊天式提示词”到“技能包”先给一个通俗理解AI Skills 就像给 AI 安装了一份“岗位说明书 工具箱”。过去我们让 AI 干活是每次在对话框里重复说明需求比如“你是一个资深 UI 设计师”“请按照 Material Design 规范”“使用蓝色系”等。这些指令完全依赖人反复描述换了对话窗口之后AI 立刻失忆。Skills 改变了这个路径。你把某个领域的完整工作方式封装成一个文件夹里面包括 SKILL.md 主指令、参考资料和辅助脚本。之后 AI 会根据任务内容自动判断是否调用这个技能不需要你再次解释领域背景和执行步骤。从技术定义上看Agent Skills 是一组以 SKILL.md 为核心的、可复用的能力包。SKILL.md 使用 Markdown 格式编写头部包含 YAML 元信息正文是给 AI 的结构化指令。与普通提示词相比它有三个明显区别对比维度普通提示词AI Skills使用方式每次手动粘贴一次配置AI 自动触发能力范围纯文本指令可携带脚本、模板、参考文件复用性难以跨项目复用可作为资产沉淀和团队共享一致性依赖用户每次描述技能内部有一套固定标准1.2 设计领域为什么天然适合 Skills设计是一个非常依赖规范的领域。一个成熟的设计团队通常有品牌色板、字体层级、间距规则、圆角规范、栅格系统甚至阴影和动效节奏。这些内容有两个特点一是高度标准化二是容易写成 Markdown 或 JSON 文件。同时设计工作流也很固定。接到需求后通常要经历“需求拆解-风格探索-规范制定-组件输出-前端还原”几个步骤。这些步骤正好可以被 Skills 固化成 AI 的执行流程。所以你会看到一个有趣的现象早期讨论 Skills 最多的是开发者因为 Claude Code 这类终端工具最早支持它。但真正让 Skills 产生“震撼感”的反而是设计团队。因为当设计规范可以被 AI 稳定执行时设计交付物的一致性和前端还原度都会明显提升团队的重复劳动也会大幅减少。1.3 Skill 的典型目录结构一个安全、可维护的技能包通常是这样组织的my-design-skills/ ├── ui-design-system/ │ ├── SKILL.md │ ├── references/ │ │ ├── color-tokens.md │ │ └── typography-scale.md │ └── scripts/ │ └── check_contrast.py └── ui-to-code/ └── SKILL.md其中 SKILL.md 是必选文件references 和 scripts 是可选目录。references 用于存放模型需要引用的设计规范scripts 用于存放需要实际执行的计算脚本。这种“主指令 参考资料 可执行脚本”的结构让 AI 不再只是“记住规范”而是真正可以“检查和计算规范”。2. 环境准备与版本说明2.1 需要准备什么工具本文示例以当前主流支持 Agent Skills 的客户端为例包括 Claude 桌面客户端和 Claude Code 这类命令行工具。如果你使用的是其他支持 SKILL.md 格式的平台配置思路基本一致只是技能目录的读取位置可能不同。建议准备以下环境一个支持 Agent Skills 的 AI 客户端具体以你使用的软件版本为准VS Code 或其他支持 Markdown 预览的编辑器Python 3.10 及以上版本用于运行对比度校验脚本Git用于对技能包做版本管理。2.2 版本说明不要写死细节需要特别提醒的是Agent Skills 功能目前迭代非常快。不同版本对技能目录、命令入口、元信息字段的支持可能存在差异。本文不会写死具体版本号而是重点演示“如何组织一份可用的技能包”。当你实际操作时如果发现某个字段或目录名不生效优先查阅当前使用客户端的官方文档。2.3 两种加载方式从使用场景上看有两种加载方式比较常见项目级加载在某个前端项目的.claude/skills/目录下放入技能包只有当前项目生效适合与具体产品设计规范绑定用户级加载放到用户的全局技能目录下所有项目都可以访问适合放置通用型设计技能比如“UI 设计系统”“前端切图助手”。如果你使用的是图形化客户端通常还需要在设置中开启 Skills 功能然后导入技能文件夹或压缩包。不同入口名称不同但核心都是让客户端能扫描到 SKILL.md 文件。3. 设计类 Skill 的配置原理3.1 SKILL.md 的 frontmatter 怎么写SKILL.md 头部通常有一段 YAML frontmatter里面至少包含两个关键字段name 和 description。--- name: ui-design-system description: 当用户需要设计界面、制定 UI 规范、生成组件库、检查视觉一致性时使用。也可以在处理需要遵循品牌色的页面时调用。 ---这里有一个非常关键的经验description 一定要写清楚“什么时候该调用”。因为模型是根据任务描述来自动判断要不要加载这个技能的。如果 description 写得过于泛化比如“一个设计技能”模型很难在具体任务中想到调用它如果写得过于限定又可能误触发。建议在 description 中写出典型的触发场景例如“当用户提到‘设计规范’‘设计系统’‘组件库’‘登录页设计’‘Dashboard UI’等需求时使用”。这样既能提高识别准确率也能避免无关任务被技能干扰。3.2 正文指令推荐的“六段法”在 SKILL.md 的正文部分建议按照以下顺序组织内容角色定义告诉 AI 它现在扮演什么角色输入理解列出用户可能给出的输入形式和需要提取的关键信息执行流程把工作拆成明确步骤步骤之间要有先后顺序输出格式说明最终输出的文件、结构或交付物格式验收标准让 AI 在输出前自查是否满足规范禁止事项明确列出不该做的行为例如“不要使用自定义颜色”“不要随意添加投影”。这套结构的好处是AI 执行任务时有了一个稳定的“思考路径”不会因为用户的表述变化而跑偏。设计类技能尤其需要这样因为设计判断非常主观只有给出明确约束才能保证输出质量稳定。3.3 参考资料和脚本如何配合设计类技能的另一大优势是“指令与数据分离”。指令写在 SKILL.md 里数据放在 references 中。比如一套品牌色板# 品牌色令牌 - --color-primary: #2F54EB - --color-success: #52C41A - --color-warning: #FAAD14 - --color-error: #FF4D4F - --color-text-primary: rgba(0, 0, 0, 0.88) - --color-bg-page: #F5F7FA当 AI 需要生成界面时它可以打开这个文件取色而不是从训练记忆里猜一个“蓝色”。这比把颜色写死在提示词里更可靠因为模型在处理长文本时对后文内容的注意力可能衰减但打开参考文件读取则是定向获取信息。如果要做更严格的校验比如检查两个颜色之间的对比度是否满足可访问性标准就可以利用 scripts 目录下的 Python 脚本。后续实战案例中会给出一个可直接运行的对比度检测脚本。4. 实战一制作一个 UI 设计系统技能4.1 创建项目结构首先在本地创建一个干净的技能目录。mkdir -p my-design-skills/ui-design-system/references mkdir -p my-design-skills/ui-design-system/scripts你可以在任意位置创建这个目录后续再把它放到客户端能扫描到的技能目录中。4.2 编写 SKILL.md在ui-design-system/SKILL.md中写入以下内容--- name: ui-design-system description: 当用户需要设计界面、制定 UI 设计规范、生成组件库、输出设计系统文档或者希望 AI 严格按照品牌色板与字体规范完成任务时使用。典型触发词包括“设计系统”“UI 规范”“设计规范”“组件库”“配色方案”“设计稿”。 --- # UI 设计系统技能 你是一名经验丰富的高级 UI 设计师擅长设计系统建设、B 端产品界面和品牌视觉规范。你有一套稳定、可复用、强调一致性的设计方法。 ## 任务目标 根据用户给出的产品描述、页面类型和品牌背景输出一套完整、可落地的 UI 设计方案或设计规范。 ## 执行流程 1. **需求拆解** - 明确产品类型B 端管理系统、C 端营销页、移动端 App 还是数据可视化大屏 - 提取关键页面登录页、Dashboard、表单页、列表页、详情页等 - 确认用户偏好如果用户对风格有明确描述优先遵循。 2. **读取设计令牌** - 打开 references/color-tokens.md使用其中定义的颜色 - 打开 references/typography-scale.md使用其中定义的字体层级 - 如果存在用户给出的品牌色则优先使用用户色板但需要将色号补充进输出规范中。 3. **制定设计规范** - 输出色板包括主色、功能色、中性色和背景色 - 输出字体层级包括标题、正文、辅助文字的字号和字重 - 输出间距单位建议使用 4px 或 8px 为基础单位 - 输出圆角规范、阴影规范和栅格建议。 4. **产出设计成果** - 如果用户需要组件库输出核心组件列表及其状态说明 - 如果用户需要页面设计按“布局结构-视觉规范-关键交互”三个层次描述 - 如果用户需要设计系统文档整理成 Markdown 格式输出。 ## 验收标准 - 所有颜色必须来自色板令牌不得凭空自定义 - 所有字号必须来自字体层级 - 常规文本与背景色的对比度应达到 WCAG AA 级别 - 组件状态至少包含默认、悬停、禁用和错误态 - 输出内容必须体现一致性不允许同一组件在不同场景中使用不同尺寸或颜色。 ## 禁止事项 - 不要在未说明的情况下使用品牌色板之外的近似颜色 - 不要随意添加复杂的渐变、夸张的投影或过大的圆角 - 不要只给一句话结论必须输出完整的设计规范说明 - 不要忽略移动端适配如果页面可能在移动端打开需要给出响应式建议。这个 SKILL.md 的核心能力是让 AI 拿到需求后先读取参考资料再按照固定流程输出规范。你可以在“禁止事项”中继续补充团队内反感的设计风格。4.3 添加颜色与字体参考资料在references/color-tokens.md中写入# 颜色令牌 ## 品牌主色 - --color-primary: #2F54EB - --color-primary-hover: #597EF7 - --color-primary-active: #1D39C4 - --color-primary-bg: #F0F5FF ## 功能色 - --color-success: #52C41A - --color-warning: #FAAD14 - --color-error: #FF4D4F - --color-info: #1890FF ## 中性色 - --color-text-primary: rgba(0, 0, 0, 0.88) - --color-text-regular: rgba(0, 0, 0, 0.65) - --color-text-secondary: rgba(0, 0, 0, 0.45) - --color-border: #D9D9D9 - --color-bg-page: #F5F7FA - --color-bg-container: #FFFFFF在references/typography-scale.md中写入# 字体层级 - 大标题28px / 36px字重 600 - 标题一24px / 32px字重 600 - 标题二20px / 28px字重 600 - 标题三16px / 24px字重 500 - 正文14px / 22px字重 400 - 辅助文字12px / 20px字重 400 - 小号标签12px字重 500可用于按钮或标签这里的字体层级参考的是常见 B 端设计系统你可以按团队实际规范替换。4.4 添加对比度校验脚本在scripts/check_contrast.py中写入# -*- coding: utf-8 -*- 计算两个十六进制颜色之间的对比度并判断是否达到 WCAG AA 标准。 用法 python check_contrast.py #2F54EB #FFFFFF import sys import re def hex_to_rgb(color: str) - tuple: color color.strip().lstrip(#) if len(color) 3: color .join([c * 2 for c in color]) if len(color) ! 6: raise ValueError(f无法解析颜色值: {color}) return tuple(int(color[i:i 2], 16) for i in (0, 2, 4)) def luminance(rgb: tuple) - float: def channel_value(c: int) - float: c c / 255.0 if c 0.03928: return c / 12.92 return ((c 0.055) / 1.055) ** 2.4 r, g, b rgb return 0.2126 * channel_value(r) 0.7152 * channel_value(g) 0.0722 * channel_value(b) def contrast_ratio(color1: str, color2: str) - float: l1 luminance(hex_to_rgb(color1)) l2 luminance(hex_to_rgb(color2)) if l1 l2: l1, l2 l2, l1 return (l1 0.05) / (l2 0.05) def verify_wcag(ratio: float) - str: aa_normal ratio 4.5 aa_large ratio 3.0 aaa_normal ratio 7.0 result [] result.append(f对比度{ratio:.2f}:1) result.append(fWCAG AA 普通文本{通过 if aa_normal else 不通过}) result.append(fWCAG AA 大文本{通过 if aa_large else 不通过}) result.append(fWCAG AAA 普通文本{通过 if aaa_normal else 不通过}) return \n.join(result) if __name__ __main__: if len(sys.argv) ! 3: print(用法python check_contrast.py #2F54EB #FFFFFF) sys.exit(1) color_a sys.argv[1] color_b sys.argv[2] try: ratio contrast_ratio(color_a, color_b) except ValueError as exc: print(f颜色格式错误{exc}) sys.exit(1) print(verify_wcag(ratio))运行脚本测试cd my-design-skills/ui-design-system python scripts/check_contrast.py #2F54EB #FFFFFF脚本会基于 WCAG 标准输出对比度结果。你可以在 SKILL.md 的“验收标准”中要求 AI 在完成配色方案后主动调用这个脚本校验可读性。4.5 加载技能并验证把这个ui-design-system文件夹放入客户端对应的技能目录。例如在 Claude Code 中可以创建一个skills目录将整个ui-design-system文件夹放进去然后在项目中输入帮我用 ui-design-system 技能生成一个后台登录页的设计规范。如果配置正确AI 会主动读取references/color-tokens.md中的色板并按 SKILL.md 中的流程输出一份规范。你可以观察输出里是否存在“品牌主色 #2F54EB”和“字体层级”这些关键内容来判断技能是否真正被加载。5. 实战二做一个 UI 转前端代码技能5.1 这个技能解决什么问题设计交付到前端时经常出现“设计稿和代码不一致”的问题。设计师的标记文件里明明写的是 8px 圆角前端却用了 12px设计稿里按钮主色是 #2F54EB代码里写成了 #1D39C4。表面看是沟通问题本质上是“规范没有贯穿设计到代码的整个链路”。AI 可以帮忙把设计描述直接转换成前端代码但如果只是让 AI“随便写”它往往会自由发挥生成的结果和团队现有组件库完全脱节。UI 转前端代码技能就是把“项目技术栈、组件命名方式、状态定义、响应式规则”全部固化下来让 AI 生成代码时有章可循。5.2 编写 SKILL.md在my-design-skills/ui-to-code/SKILL.md中创建--- name: ui-to-code description: 当用户提供设计稿、设计描述、原型图说明或组件规范希望转换为 React、Vue 等前端代码时使用。典型触发词包括“转成前端代码”“实现这个页面”“写一个组件”“还原设计稿”。 --- # UI 转前端代码技能 你是一名专业的前端工程师擅长将设计稿还原为高质量、可维护的组件化代码。 ## 技术栈约束 - 默认使用 React 18 TypeScript Tailwind CSS - 如果用户指定 Vue 或项目技术栈则遵循用户要求 - 优先使用函数组件不使用 class 组件 - 样式优先使用 Tailwind 工具类不使用内联样式。 ## 执行流程 1. **解析设计输入** - 如果用户提供文本描述提取页面区域、布局结构和交互要求 - 如果用户提供截图或设计稿先描述页面视觉结构再转化为代码。 2. **拆解组件结构** - 将页面拆分为可复用组件 - 输出组件树例如Page - Header FormArea Footer - 每个组件单独生成一个文件。 3. **生成代码** - 组件命名使用 PascalCase - 变量和函数命名使用 camelCase - 样式类名使用 kebab-case - 必须包含必要注释解释关键区块的作用。 4. **输出文件** - 按目录结构输出代码例如 src/components/Header.tsx - 如果代码量较大先列出文件清单再逐文件输出 - 涉及表单时使用受控组件并给出状态管理示例。 ## 验收标准 - 页面结构与设计稿保持一致 - 点击区域和按钮交互完备 - 组件拆分合理不把整个页面写成一个巨大组件 - 代码没有未定义的变量或死代码 - 对布局容器给出必要的响应式样式。 ## 禁止事项 - 不要使用未在技术栈约束中出现的组件库除非用户明确要求 - 不要忽略表单校验和边界状态 - 不要把所有样式塞进一个 div 上需要合理使用语义化标签 - 不要生成无法直接编译的残缺代码。5.3 运行与验证在客户端中把ui-to-code技能准备好后可以尝试输入请使用 ui-to-code 技能把下面这个登录页描述转换成 React 组件 页面中央有一个白色卡片左侧是品牌 Logo右侧是登录表单。表单包含手机号和验证码两个输入框下方有一个“登录”按钮按钮左侧有一个“记住账号”勾选框。期望 AI 输出类似下面的组件结构说明而不会只是一段凌乱的 JSX- src/pages/LoginPage.tsx页面布局 - src/components/LoginCard.tsx登录卡片容器 - src/components/PhoneInput.tsx手机号输入框 - src/components/CodeInput.tsx验证码输入框 - src/components/LoginButton.tsx登录按钮当你发现 AI 输出的代码开始稳定遵循组件化拆分、命名规范和响应式规则时说明这个技能已经生效了。6. 为什么这种技能会让设计界“震撼”6.1 规范从“人肉遵守”变成“模型内化”过去设计规范主要靠设计师自觉或者靠设计评审时人工检查。AI 生成内容时如果每次都要临时读一段长提示词很容易出现“前面记得住后面开始自由发挥”的问题。Skills 把规范放进了 AI 的工作路径里等于让模型在完成设计任务时“自带一份内部规范”。它不需要你反复提醒就会主动读取色板、字体层级和组件规则。体验过的人会明显感觉AI 输出的设计方案不再是“看起来差不多”的通用设计而是“这个团队的设计语言”下的产物。这种一致性才是让设计团队愿意长期使用 AI 的根本原因。6.2 技能包成为团队资产提示词是写在一个聊天窗口里的很难沉淀但技能包是一个个 Markdown 文件和脚本可以放进 Git 仓库可以做版本管理也可以供整个团队共享。这意味着当团队更新了品牌色板只需要修改color-tokens.md所有使用这个技能的成员都会自动获得新的色彩规范。前端和设计师之间也可以共用同一个“设计系统技能”从设计到代码的链路变得非常顺畅。社区里已经出现了一些技能集仓库比如 Superpower Skills 这类聚合了大量技能的合集也有一些开发者把技能包发布到共享仓库中。使用时需要注意来源安全性尽量选择可信的官方或社区维护仓库。6.3 为自动化设计流水线打下基础如果你把 Skills 和 Agent 结合就可以把设计工作流进一步自动化。比如一个 Agent 负责解析产品需求产出页面结构一个 Agent 调用设计系统技能补充视觉规范一个 Agent 调用 UI 转代码技能生成前端代码一个 Agent 调用测试相关技能检查代码是否符合可访问性标准或组件状态是否完整。这种结构正在从“AI 聊天助手”进一步走向“AI 协作团队”。设计师的角色也会从“手动完成设计”变成“定义设计标准和审核 AI 产出”。7. 常见问题与排查思路在实际使用 AI Skills 的过程中比较容易遇到下面几个问题问题现象常见原因解决思路技能没有被自动调用description 触发条件写得太宽或太窄优化 description明确具体任务和关键词AI 输出风格不稳定SKILL.md 缺少“禁止事项”增加明确约束如“不要使用自定义颜色”中文内容乱码SKILL.md 或脚本未使用 UTF-8 编码统一保存为 UTF-8Python 文件头部加编码声明脚本无法运行缺少依赖或 Python 版本不对添加 requirements.txt明确 Python 版本技能加载后不生效目录结构不符合客户端要求确认 SKILL.md 是否位于技能文件夹根目录输出代码缺少设计 token技能中没有引用色板文件在 SKILL.md 中写明必须读取 references 文件误触发其他技能多个技能 description 相近细化 description给每个技能加上明确领域边界排查这类问题时建议按照“先看目录结构再看 description 触发条件再看正文指令”的顺序。因为很多问题不是技能内容写得不对而是 AI 根本没有正确加载技能。如果某项技能一直没有触发可以在对话中直接点名技能名称例如“请使用 ui-design-system 技能处理这个需求”。这样可以判断是技能本身的问题还是自动触发机制的问题。8. 最佳实践与工程建议8.1 一个技能只做一件事技能包和函数一样职责越单一越容易维护。不要把“UI 设计规范”和“UI 转代码”写进同一个 SKILL.md否则 AI 在执行任务时容易出现流程混乱。建议每个技能聚焦一个完整工作流比如“设计规范生成”“前端代码生成”“对比度检查”“设计评审”。8.2 把参考资料和指令分离不要把所有颜色、字体、间距都写进 SKILL.md 正文。正文越长AI 对关键指令的注意力越容易分散。把设计令牌放到 references 目录让 AI 在需要时去读取这样既清晰又便于更新。8.3 每一次修改都做冒烟测试修改技能后一定要用同一个测试用例重新跑一遍。比如“生成登录页设计规范”这句话每次修改后都输入一次观察输出是否有预期变化。这样可以快速定位是技能内容问题还是自动触发问题。8.4 用 Git 管理技能版本技能包本质上是一份代码资产建议纳入 Git 管理。这样当某个版本的技能导致输出质量下降时可以快速回滚到上一个稳定版本。提交信息建议写成“调整色板令牌”“补充禁止事项”等方便后续回溯。8.5 安全边界与敏感信息技能包中不要写入任何硬编码密钥、内部系统地址或敏感个人信息。如果技能需要对外共享请先检查 references 目录中是否有公司内部资料。还有一点很重要不要在技能脚本中写高危操作命令比如删除文件、执行不可信链接等。AI 在客户端中运行脚本时权限控制也是一个需要关注的安全边界尽量只给技能最小权限。8.6 从真实的失败案例中迭代我第一次做设计技能时把“输出一份设计规范”写成了一句话指令结果 AI 只返回了三行话完全没有组件状态和色彩层级。后来我在正文中加入了“任务目标-执行流程-验收标准-禁止事项”四部分并把参考文件明确绑定输出质量才稳定下来。经验是AI 技能并不是“写越多越好”而是要写清“必须做什么、禁止做什么、如何自我检查”。9. 总结与学习路线本文围绕 AI Skills 在设计领域的应用展开从概念、环境准备、配置原理到两个完整的实战案例讲解了 SKILL.md 的编写方式、参考资料和脚本的组织方式以及常见问题的排查方法。核心收获可以总结成三点AI Skills 是一种比提示词更稳定、更可复用的能力封装方式设计类技能的关键在于把规范、流程和校验脚本拆分开让 AI 能自动加载并执行技能包需要像代码一样管理持续迭代、做版本控制、注意安全边界。下一步建议你先从自己的日常设计任务中选择一个最重复、最依赖规范的场景尝试做一个最小技能包。可以是“页面配色方案生成”可以是“组件状态说明生成”也可以是“设计稿转前端代码”。当你熟练掌握 SKILL.md 的编写后再进一步学习 Agent 编排和多个技能组合使用把设计流程真正自动化起来。如果你对 AI skills 开发感兴趣也可以多关注社区中的技能合集仓库和各类实战案例。不过一定要记住别人分享的技能包只能作为参考最终要调整成符合你自己团队规范和项目上下文的版本才能真正发挥价值。