拓冰网站定制 
刚接触 AI 编程助手的同学可能对这些名字并不陌生Claude Code、Cursor、Codex、OpenCode还包括各种“AI Skills”的分享和下载。但很多人印象里skills 还是“提示词模板的升级版”或者“能让 AI 写代码更听话的工具”。如果我告诉你把 skills 用对方向它能直接改变设计师和前端工程师之间的协作方式甚至改变整个 UI/UX 交付流程你会不会觉得有点夸张这篇文章不打算停留在概念层而是想从一名开发者的视角拆解“AI skills”到底是什么、它与普通提示词有什么本质区别以及如何设计一套能真正“震撼设计界”的 AI skills——不只是帮你生成设计稿而是把设计审查、设计走查、UI 代码生成、设计系统合规检查这些流程全部自动化。全文会给出完整的环境准备、技能包目录结构、SKILL.md 写法、配套脚本和常见问题排查适合正在学习 AI Agent 开发的开发者也适合设计团队中的前端同学照着落地。1. 什么是 AI Skills先理解“技能包”这个概念1.1 从“提示词”到“技能”过去我们用 AI 辅助设计或开发时通常是复制一段很长的 Prompt比如你是一名资深 UI 设计师请根据以下设计稿生成对应的 HTML/CSS 代码要求使用 Tailwind CSS保持响应式布局……这种方式的痛点很明显提示词很难复用每次都要重新维护。提示词只是“文字约束”AI 无法主动调用工具完成验证。不同项目之间的规范无法统一换一个模型表现差异很大。而“AI Skills”的核心思路是把“提示词 工具调用 上下文规范 示例输出”打包成一个可复用的技能包。当 Agent 在执行任务时它能自动加载这个技能包里的技能定义、指令和约束再配合底层模型和工具完成一个相对完整的工作流。用我自己的话概括就是提示词是告诉 AI“怎么做”技能是告诉 AI“你是一个会做这件事的人”并且还给它配好了工具箱和工作流程。1.2 Agent Skills 与 Rules / MCP 的关系在实际工具链中目前主流 AI 编程助手都在往“技能化”方向发展但叫法不太一样工具技能机制说明Claude CodeSkills / SKILL.md以 Markdown 文件定义技能支持脚本和工具调用CursorRules / .mdc以规则文件约束 AI 行为类似增强版项目说明CodexAGENTS.md / 自定义指令OpenAI 编码代理的自定义指令体系OpenCodeSkills / 插件机制开源 CLI 编码代理支持技能目录另外还有一个很容易混淆的概念MCPModel Context Protocol模型上下文协议。简单理解MCP 是给 AI 接外部工具的“接口协议”比如让它能读取 Figma 文件、执行浏览器测试、调用设计系统组件库而 Skills 是对 AI 行为的“能力封装”。两者不冲突通常一个完整的技能需要同时依赖 MCP 工具和良好的指令定义。1.3 为什么设计场景特别需要技能包设计领域有一个长期存在的“翻译损耗”问题设计师产出 Figma 稿前端工程师拿到设计标注后要手动还原期间还要不断确认间距、字号、圆角、颜色 token、断点行为。这个过程中AI 如果只是“理解提示词”很难稳定输出符合设计系统的代码。但如果我们把“设计审查”“设计 token 提取”“UI 转代码”“无障碍检查”这些流程做成技能包AI 就不只是“看一张图写一段代码”而是变成了一条自动化的设计交付流水线读取设计稿。提取设计变量和组件规范。生成符合设计系统的前端代码。自动检查对比度、交互状态、响应式规则。输出审查报告和修改建议。这才是 AI skills 能让设计界“震撼”的真正原因。2. AI Skills 对设计工作流的冲击点不止是“生成一张图”2.1 设计交付流程中的技能化改造传统设计交付链路大致是这样的设计师在 Figma / Sketch 输出设计稿。手动标注设计规范。前端开发根据标注写页面。UI 走查阶段人工检查还原度。反复沟通修改。把 AI skills 引入后链路可以变成设计师继续在 Figma 输出设计稿。AI 从设计稿中读取结构、样式变量、组件状态。AI 生成符合设计系统的组件代码。AI 自动执行视觉走查输出还原度报告。前端只需要处理少量动态交互逻辑。也就是说skills 解决的不只是“代码生成”而是把设计规范、审查标准、输出格式这些“隐性知识”显性化到技能包里。任何一个新成员加入项目只要加载同一套 skills就能保持一致的输出质量。2.2 可直接落地到设计团队的 4 类技能根据我最近半年在项目里的实践下面四类技能最值得优先开发设计审查技能Design Review Skill接收设计稿或页面截图按设计原则、间距系统、配色规范、层级关系进行审查输出问题清单和修改建议。UI 转代码技能UI to Code Skill把设计稿转换为 HTML/Tailwind、React/Vue 组件自动生成响应式代码并保留设计 token 映射。设计 Token 提取技能Design Token Extractor从设计稿或 CSS 文件中提取颜色、字体、间距、阴影等变量生成统一的 token JSON 文件。无障碍与合规检查技能A11y / Compliance Skill自动检查文本对比度、可点击区域大小、ARIA 标签、焦点状态等无障碍问题输出合规报告。2.3 工具链现状这里不展开所有工具的详细安装先给一个宏观判断Claude Code 的技能机制最适合做“复杂工作流型技能”因为它支持多步骤工具调用和脚本执行。Cursor 的 Rules 更适合做“代码风格约束型技能”例如输出组件时必须使用某个组件库。Codex 和 OpenCode 的生态还在快速迭代如果你本身就是 CLI 爱好者可以跟进它们最新版本的 Skills 文档。后面实战部分我会以“技能包目录结构 SKILL.md”为主线讲解因为它是一种比较通用的组织方式其他工具只要做少量适配也能复用。3. 环境准备与技能包文件结构3.1 运行环境先说明一下本文示例环境操作系统macOS 或 LinuxWindows 建议使用 WSL2。编程语言Python 3.10用于编写辅助脚本。运行时Node.js 18部分工具脚本需要。AI 编程助手Claude Code 或 Cursor版本以你实际情况为准本文重点是结构和思路。这些版本不需要完全一致因为技能包的核心是“文件组织 指令模板”具有较强的可迁移性。实际使用时请根据自己的模型版本调整。3.2 技能包目录结构一个标准的设计类技能包建议按下面的目录结构组织design-skills/ ├── design-review/ │ ├── SKILL.md │ ├── scripts/ │ │ └── check_contrast.py │ └── examples/ │ └── review-report.md ├── ui-to-code/ │ ├── SKILL.md │ ├── prompts/ │ │ └── react-component.md │ ├── templates/ │ │ └── component.tsx │ └── examples/ │ └── sample-output.tsx ├── design-tokens/ │ ├── SKILL.md │ ├── scripts/ │ │ └── extract_tokens.py │ └── schemas/ │ └── token.schema.json └── a11y-check/ ├── SKILL.md ├── scripts/ │ └── run_axe.py └── rules/ └── wcag-rules.md关键文件说明SKILL.md技能的主文件定义技能的用途、触发条件、工作流程、输出规范。scripts/配套脚本用于执行确定性检查例如对比度计算、token 提取。examples/示例输出帮助 Agent 理解理想结果长什么样。prompts/或templates/更细分的指令模板适合大型技能包。3.3 SKILL.md 的常见写法SKILL.md 本质上是一个“结构化 Markdown 文档”它不需要很复杂但信息必须清晰。下面是 design-review 技能的主文件示例# Design Review Skill ## 技能用途 用于对 UI 设计稿或页面截图进行设计走查输出结构化审查报告。 ## 适用场景 - 产品发布前 UI 走查 - 设计师交付前的自检 - 前端开发完成后的还原度检查 ## 输入要求 - 设计稿图片路径或 URL - 设计规范 JSON 文件可选 ## 工作流程 1. 读取设计稿或截图。 2. 提取页面中的颜色、字体、间距、圆角等视觉属性。 3. 与输入的设计规范进行比对。 4. 检查对比度、层级、间距一致性、对齐方式。 5. 输出 Markdown 格式审查报告。 ## 输出规范 审查报告必须包含 - 概述本次审查范围和时间 - 问题清单按严重程度分为 P0 / P1 / P2 - 每个问题的截图位置或坐标 - 修复建议 - 若所有项目通过输出“通过” ## 注意事项 - 不修改原始设计文件。 - 不确定的属性不要臆测标记为“需要确认”。 - 对比度计算请调用 scripts/check_contrast.js。这段文件看起来不复杂但它已经把 Agent 的工作范围限制得很清楚。实战中技能包越详细AI 输出的稳定性就越高。初学者最容易犯的错误是只写“请你检查一下这个设计稿”结果 AI 输出非常随机。正确做法是像上面这样把输入、流程、输出规范全部写死。4. 实战一设计审查技能Design Review Skill4.1 需求拆解我们希望实现一个“设计审查技能”它接收一张网页截图或设计稿能做以下事情识别页面主要 UI 元素。提取关键样式属性。对比设计规范。输出结构化审查报告。为了不让 AI 完全凭“感觉”判断对比度我们准备一个 Python 脚本计算 WCAG 对比度AI 在审查时调用脚本获得可靠数值。4.2 编写技能定义文件路径design-skills/design-review/SKILL.md# Design Review Skill ## 技能用途 对 UI 设计稿、页面截图进行设计走查输出结构化审查报告。 ## 适用场景 - UI 走查 / 视觉验收 - 设计交付前自检 - 前端还原度检查 ## 输入要求 - 图片路径设计稿或网页截图 - 可选设计规范 JSON 文件包含 color / spacing / font 定义 ## 工作流程 ### 步骤 1读取并理解设计稿 - 如果输入是图片描述页面整体布局、主要区块和组件。 - 如果输入是 HTML 或代码文件直接分析 DOM 结构和样式。 ### 步骤 2提取视觉属性 - 记录页面中出现的颜色值。 - 记录主要间距、圆角、字号。 - 记录元素之间的对齐关系。 ### 步骤 3对比设计规范 - 如果提供了设计规范 JSON逐项比对。 - 如果没有提供规范则基于常见设计原则做人工判断。 ### 步骤 4计算对比度 - 对文本颜色与背景颜色调用 python3 scripts/check_contrast.py color1 color2。 - 根据 WCAG AA 标准判断是否通过。 - 普通文本对比度 4.5:1 - 大号文本对比度 3:1 ### 步骤 5输出审查报告 报告必须包含 1. 审查范围概述 2. 问题清单P0 / P1 / P2 3. 每个问题的位置、截图坐标、说明 4. 修复建议 5. 最终结论通过 / 需修改 ## 报告模板 markdown ## 设计审查报告 - 审查对象: {页面名称} - 审查时间: {当前时间} - 审查人员: AI Design Reviewer ### 问题清单 | 级别 | 位置 | 问题描述 | 建议 | | --- | --- | --- | --- | | P1 | 顶部导航 | 文本对比度为 3.2:1低于 WCAG AA 标准 | 将文字颜色调整为 #1A1A1A | ### 通过项 - 间距系统符合 8px 网格规则 - 圆角与 design token 一致 **结论需修改**注意事项不修改任何源文件。对颜色值不确定时标为“需要人工确认”。对比度计算必须使用脚本不能凭目测估计。这里有一个很关键的设计我们要求 AI 必须调用脚本计算对比度而不是自己“估算”。这是技能包与普通提示词的显著区别它把确定性计算回归到了代码从而减少模型幻觉。 ### 4.3 配套脚本 文件路径design-skills/design-review/scripts/check_contrast.py python #!/usr/bin/env python3 计算两个十六进制颜色之间的 WCAG 对比度。 用法python3 check_contrast.py #FFFFFF #000000 import sys import re def hex_to_rgb(hex_color: str) - tuple: 将 #RRGGBB 转为 (r, g, b) 元组取值 0~255。 hex_color hex_color.strip().lstrip(#) if len(hex_color) ! 6: raise ValueError(f无效颜色值{hex_color}请输入 #RRGGBB 格式) return tuple(int(hex_color[i:i2], 16) for i in (0, 2, 4)) def relative_luminance(rgb: tuple) - float: 计算相对亮度WCAG 2.x 标准。 vals [] for c in rgb: c c / 255.0 if c 0.03928: vals.append(c / 12.92) else: vals.append(((c 0.055) / 1.055) ** 2.4) return 0.2126 * vals[0] 0.7152 * vals[1] 0.0722 * vals[2] def contrast_ratio(color1: str, color2: str) - float: 计算两个颜色之间的对比度。 lum1 relative_luminance(hex_to_rgb(color1)) lum2 relative_luminance(hex_to_rgb(color2)) lighter max(lum1, lum2) darker min(lum1, lum2) return (lighter 0.05) / (darker 0.05) def main(): if len(sys.argv) ! 3: print(用法python3 check_contrast.py color1 color2) sys.exit(1) c1 sys.argv[1] c2 sys.argv[2] try: ratio contrast_ratio(c1, c2) except ValueError as e: print(f错误{e}) sys.exit(1) print(f对比度{ratio:.2f}:1) if ratio 4.5: print(结果通过WCAG AA 普通文本) elif ratio 3.0: print(结果通过WCAG AA 大号文本) else: print(结果不通过) if __name__ __main__: main()运行方式python3 check_contrast.py #FFFFFF #333333预期输出对比度12.63:1 结果通过WCAG AA 普通文本4.4 运行与验证把上面的技能包加载到 Claude Code 或 Cursor 后你可以这样触发输入请使用 design-review 技能检查一下 examples/homepage.png并和 design-tokens.json 对比。技能会先读取图片再按 SKILL.md 里的步骤执行。遇到颜色对比度判断时调用 Python 脚本。最后输出 Markdown 报告。注意不同 AI 工具的加载方式可能不同比如 Claude Code 可能会要求你把技能包放到指定目录Cursor 则可能通过 Rules 文件描述。建议先读官方文档确认不能用本文的目录结构硬套所有工具。5. 实战二UI 转代码技能UI to Code Skill5.1 为什么这会让设计界震撼如果说设计审查是“辅助检查”那“UI 转代码”就是直接冲击设计师与工程师协作边界的能力。过去一个设计稿还原成代码需要前端工程师投入大量手动工作。而当你给 AI 配上 UI to Code 技能后它能读取设计稿或设计稿导出图。分析视觉层级和布局。生成符合项目技术栈的代码。自动绑定设计 token。输出响应式和可访问性友好的组件。下面我们定义一个“UI to Code”技能以 React TypeScript Tailwind 环境为例。5.2 技能文件文件路径design-skills/ui-to-code/SKILL.md# UI to Code Skill ## 技能用途 将设计稿转换为高质量 React TypeScript 组件代码。 ## 适用场景 - 根据 Figma 设计稿生成前端组件 - 设计系统组件扩展 - 前端原型快速搭建 ## 输入要求 - 设计稿图片路径或设计稿导出的 HTML 结构 - 可选设计 token JSON 文件 - 可选组件库约定例如 shadcn/uiAnt Design ## 技术栈默认配置 - React 18 - TypeScript 5 - Tailwind CSS 3 - 可选shadcn/ui 组件 ## 工作流程 ### 步骤 1解析设计稿 - 识别页面整体布局结构。 - 将设计稿按视觉区块拆分Header、Hero、Feature、Footer 等。 - 命名组件时使用语义化名称。 ### 步骤 2映射设计 Token - 如果有 token JSON颜色、间距、字号必须引用 token不能硬编码。 - 如果没有 token JSON在组件顶部生成一个 const tokens {...} 用于集中管理。 ### 步骤 3生成组件代码 - 每个区块生成独立的组件文件。 - 组件内使用 Tailwind 类名实现样式。 - 对有状态交互的控件下拉框、弹窗标注 需要额外实现。 ### 步骤 4添加无障碍属性 - 图片必须包含 alt。 - 按钮必须有可读文本或 aria-label。 - 使用语义化标签header / nav / main / section / footer。 ### 步骤 5输出 - 输出文件清单和每个组件的完整代码。 - 组件之间使用默认导出。 - 最后输出一个 index.tsx 汇总入口。 ## 输出规范 每个组件文件必须包含 - 技术栈说明注释 - 组件 props 类型定义 - 完整的 JSX 结构 - Tailwind class ## 注意事项 - 没有把握的交互逻辑不要硬写输出 TODO 注释。 - 必须保证 TypeScript 类型完整。 - 不引入未说明的第三方依赖。5.3 设计 Token 示例在实际生成前你可以让 AI 参考下面这样的 token JSON{ colors: { primary: #2563EB, background: #FFFFFF, text: #1A1A1A, muted: #6B7280 }, spacing: { xs: 4px, sm: 8px, md: 16px, lg: 24px, xl: 48px }, font: { body: Inter, sans-serif, heading: Inter, sans-serif, size-sm: 14px, size-base: 16px, size-lg: 24px }, radius: { sm: 4px, md: 8px, lg: 12px } }配合 token 文件的技能生成出来的代码不会出现“硬编码颜色”的问题。这也是好评与差评之间的一道分水岭好的 UI 转代码技能生成的是“符合设计系统的组件”差的则是“八竿子打不着的临时样式”。5.4 运行流程给 AI 提供一张卡片组件的设计稿图并输入请使用 ui-to-code 技能把这张设计稿转换成 React 组件参考资料为 design-tokens.json。预期输出可能包含// Card.tsx import React from react; interface CardProps { title: string; description: string; imageUrl?: string; actions?: React.ReactNode; } const tokens { colorPrimary: #2563EB, colorBackground: #FFFFFF, colorText: #1A1A1A, spacingMd: 16px, spacingLg: 24px, radiusLg: 12px, }; export default function Card({ title, description, imageUrl, actions }: CardProps) { return ( div classNamebg-white rounded-xl shadow-sm style{{ backgroundColor: tokens.colorBackground, borderRadius: tokens.radiusLg, padding: tokens.spacingLg, }} {imageUrl ( img src{imageUrl} alt{title} classNamew-full h-48 object-cover rounded-lg / )} h3 classNamemt-4 text-lg font-semibold style{{ color: tokens.colorText }} {title} /h3 p classNamemt-2 text-sm style{{ color: tokens.colorMuted }} {description} /p {actions div classNamemt-4{actions}/div} /div ); }注意示例代码只是一个“技能演示”实际生成结果会根据设计稿内容变化。上面这段代码已经能看出 token 映射的痕迹也保留了语义化结构和图片 alt体现了技能约束的效果。6. 实战三设计系统与无障碍检查技能6.1 技能用途很多团队已经有设计系统组件库但缺少自动化的“合规检查”。我们可以配置一个 A11y 检查技能让 AI 自动检查页面中的无障碍问题。6.2 配置文件路径design-skills/a11y-check/SKILL.md# A11y Check Skill ## 技能用途 对 HTML / React 页面进行无障碍检查输出 WCAG 2.1 AA 合规报告。 ## 输入要求 - HTML 文件路径或 React 组件代码 - 可选页面 URL需要浏览器工具联动 ## 检查项 1. 图片是否有 alt 属性 2. 表单控件是否有 label 3. 文本颜色对比度是否达标 4. 可点击元素是否有键盘焦点样式 5. 按钮是否使用 button 标签而非 div 6. ARIA 属性使用是否正确 ## 工作流程 1. 解析输入。 2. 逐项检查。 3. 无法静态判断的项标记为“需要人工验证”。 4. 输出合规报告。配合脚本时可以用 axe-core 这类工具做 DOM 级扫描AI 再结合扫描结果生成报告。这样就避免了 AI 只看代码片段、忽略真实渲染结果的问题。6.3 与浏览器工具联动如果使用 Claude Code 或支持 MCP 的工具可以接入 Playwright MCP Server让 AI 自动打开页面、执行点击操作、提取真实 DOM。通过这种方式A11y 检查不再局限于“静态代码”而是可以做端到端的真实交互检查。典型流程AI 使用技能包中的指令。AI 调用 Playwright 工具打开页面。Playwright 执行 axe 扫描。扫描结果回传给 AI。AI 输出报告标记严重级别。这里的配置方式因工具而异我不展开具体命令行安装步骤以免版本差异导致误导。核心思路是技能负责“规则和报告结构”MCP 负责“连接外部工具”两者结合才能发挥最大作用。7. 常见问题与排查思路在实践 AI skills 的过程中最容易踩到下面这些坑问题现象常见原因解决思路技能没有生效技能包目录结构不正确或 SKILL.md 命名错误确认工具要求的目录和命名规范输出仍然很随机技能指令太模糊缺少工作流程和输出规范像写测试用例一样完善 SKILL.md颜色对比度判断错误AI 直接估算没有调用脚本在 SKILL.md 中强制要求调用脚本生成代码硬编码颜色没有提供 token 文件或技能未强制映射提供 token JSON并在指令中写死技能包无法跨工具使用不同工具对技能格式支持不一致以核心 SKILL.md 为主按工具适配上下文太长导致效果下降技能包过大加载了太多无用内容拆分成多个小技能按需加载脚本执行权限失败缺少 python 依赖或脚本没有可执行权限检查 Python 环境和 chmod 权限如果你不确定问题出在哪建议按下面的顺序排查先确认技能文件是否被正确加载。很多工具会打印加载日志或者你可以故意在 SKILL.md 里写一个错误指令看 AI 会不会执行。再确认技能指令是否明确。输出规范越明确结果越稳定。接着检查脚本是否可独立运行。如果脚本本身失败AI 就会跳过调用直接靠直觉输出。最后看示例输出。技能包里的 examples 文件能显著提升 AI 的模仿质量。8. 最佳实践与工程建议8.1 命名与目录规范技能命名尽量使用“动作 对象”的格式例如design-reviewui-to-codetoken-extracta11y-check避免使用“ai-design-agent-v1-final”这种名字时间一长就很难维护。每个技能包内部建议保持统一结构SKILL.mdscripts/examples/三个目录是底线。8.2 版本管理与测试技能包也是代码应该纳入 Git 版本管理。每当你修改 SKILL.md 或脚本建议使用独立的 Git 分支。用一组固定的测试用例验证输出。把测试用例也放在技能包目录的tests/下。以 design-review 为例测试用例可以是这样import subprocess def test_contrast(): result subprocess.run( [python3, scripts/check_contrast.py, #FFFFFF, #333333], capture_outputTrue, textTrue, checkFalse, ) assert 通过 in result.stdout有了测试团队其他人修改技能包时就不容易破坏原有行为。8.3 安全与合规边界把 AI skills 应用到设计场景时有几点安全建议API Token 权限最小化如果技能需要读取 Figma、代码仓库或云服务建议使用只读 Token并设置短时效。不自动修改源文件设计审查类技能默认不要修改原始设计稿。避免上传敏感设计稿如果设计稿包含未公开产品原型或客户数据不要直接发送给云端模型。优先选择私有化部署或脱敏处理。版权与授权生成 UI 代码时若要参考第三方设计资源、图标库或组件库必须先确认授权范围。不要从设计稿逆向提取字体文件或素材包。区分 AI 辅助与人工确认无障碍合规审查、品牌规范检查这些环节AI 报告只能作为辅助材料最终应由负责人确认。8.4 团队共享与文档化建议把技能包作为团队内部的开源项目维护一个仓库统一管理所有设计类技能。每个技能包带 README说明适用场景、调用方式、输出示例。新成员加入时只需要拉取仓库并在 AI 工具中配置就能获得同样的“设计加持”。最终目标是形成一套团队级的“设计语言”不管是谁来写前端代码加载同一套技能后AI 生成的代码会保持高度一致。9. 后续可以继续优化的方向到这里设计类 AI skills 的完整思路已经比较清晰了我们从“提示词”聊到了“技能包”。从设计审查、UI 转代码、无障碍检查三个实战案例看到了 AI 自动化设计交付的可能性。同时我们也清楚认识到AI 并不是万能钥匙它的有效性高度依赖技能文件的质量、配套脚本的可靠性以及团队是否遵守安全与合规边界。如果你接下来想深入可以从这几个方向继续把 design-tokens 技能做成 Figma API 联动自动拉取设计变量。给 ui-to-code 技能增加组件库适配例如让输出直接对接 shadcn/ui 或 Ant Design。使用 Playwright 做更完整的视觉回归测试让 AI 定期自动走查页面并生成比对报告。把技能包发布到团队内部仓库或公共资源平台形成一个可持续迭代的“设计 AI 插件生态”。AI skills 并不神秘它的价值也不在于“一次性生成完美结果”而在于把你和团队的设计经验沉淀成可复用、可测试、可演进的能力包。希望这篇文章能帮你在“AI 替代一部分设计工作”的浪潮里掌握主动权而不是被动接受工具的变化。如果后面有时间我再单独拆解 Figma API 对接、Playwright 视觉回归和团队私有化技能仓库的落地细节。你也可以先在本地把设计审查技能跑通感受一下“AI 从只会聊天到真正会干活”的差别。 AI Skills如何重塑设计与前端协作：从提示词到自动化设计交付
刚接触 AI 编程助手的同学可能对这些名字并不陌生Claude Code、Cursor、Codex、OpenCode还包括各种“AI Skills”的分享和下载。但很多人印象里skills 还是“提示词模板的升级版”或者“能让 AI 写代码更听话的工具”。如果我告诉你把 skills 用对方向它能直接改变设计师和前端工程师之间的协作方式甚至改变整个 UI/UX 交付流程你会不会觉得有点夸张这篇文章不打算停留在概念层而是想从一名开发者的视角拆解“AI skills”到底是什么、它与普通提示词有什么本质区别以及如何设计一套能真正“震撼设计界”的 AI skills——不只是帮你生成设计稿而是把设计审查、设计走查、UI 代码生成、设计系统合规检查这些流程全部自动化。全文会给出完整的环境准备、技能包目录结构、SKILL.md 写法、配套脚本和常见问题排查适合正在学习 AI Agent 开发的开发者也适合设计团队中的前端同学照着落地。1. 什么是 AI Skills先理解“技能包”这个概念1.1 从“提示词”到“技能”过去我们用 AI 辅助设计或开发时通常是复制一段很长的 Prompt比如你是一名资深 UI 设计师请根据以下设计稿生成对应的 HTML/CSS 代码要求使用 Tailwind CSS保持响应式布局……这种方式的痛点很明显提示词很难复用每次都要重新维护。提示词只是“文字约束”AI 无法主动调用工具完成验证。不同项目之间的规范无法统一换一个模型表现差异很大。而“AI Skills”的核心思路是把“提示词 工具调用 上下文规范 示例输出”打包成一个可复用的技能包。当 Agent 在执行任务时它能自动加载这个技能包里的技能定义、指令和约束再配合底层模型和工具完成一个相对完整的工作流。用我自己的话概括就是提示词是告诉 AI“怎么做”技能是告诉 AI“你是一个会做这件事的人”并且还给它配好了工具箱和工作流程。1.2 Agent Skills 与 Rules / MCP 的关系在实际工具链中目前主流 AI 编程助手都在往“技能化”方向发展但叫法不太一样工具技能机制说明Claude CodeSkills / SKILL.md以 Markdown 文件定义技能支持脚本和工具调用CursorRules / .mdc以规则文件约束 AI 行为类似增强版项目说明CodexAGENTS.md / 自定义指令OpenAI 编码代理的自定义指令体系OpenCodeSkills / 插件机制开源 CLI 编码代理支持技能目录另外还有一个很容易混淆的概念MCPModel Context Protocol模型上下文协议。简单理解MCP 是给 AI 接外部工具的“接口协议”比如让它能读取 Figma 文件、执行浏览器测试、调用设计系统组件库而 Skills 是对 AI 行为的“能力封装”。两者不冲突通常一个完整的技能需要同时依赖 MCP 工具和良好的指令定义。1.3 为什么设计场景特别需要技能包设计领域有一个长期存在的“翻译损耗”问题设计师产出 Figma 稿前端工程师拿到设计标注后要手动还原期间还要不断确认间距、字号、圆角、颜色 token、断点行为。这个过程中AI 如果只是“理解提示词”很难稳定输出符合设计系统的代码。但如果我们把“设计审查”“设计 token 提取”“UI 转代码”“无障碍检查”这些流程做成技能包AI 就不只是“看一张图写一段代码”而是变成了一条自动化的设计交付流水线读取设计稿。提取设计变量和组件规范。生成符合设计系统的前端代码。自动检查对比度、交互状态、响应式规则。输出审查报告和修改建议。这才是 AI skills 能让设计界“震撼”的真正原因。2. AI Skills 对设计工作流的冲击点不止是“生成一张图”2.1 设计交付流程中的技能化改造传统设计交付链路大致是这样的设计师在 Figma / Sketch 输出设计稿。手动标注设计规范。前端开发根据标注写页面。UI 走查阶段人工检查还原度。反复沟通修改。把 AI skills 引入后链路可以变成设计师继续在 Figma 输出设计稿。AI 从设计稿中读取结构、样式变量、组件状态。AI 生成符合设计系统的组件代码。AI 自动执行视觉走查输出还原度报告。前端只需要处理少量动态交互逻辑。也就是说skills 解决的不只是“代码生成”而是把设计规范、审查标准、输出格式这些“隐性知识”显性化到技能包里。任何一个新成员加入项目只要加载同一套 skills就能保持一致的输出质量。2.2 可直接落地到设计团队的 4 类技能根据我最近半年在项目里的实践下面四类技能最值得优先开发设计审查技能Design Review Skill接收设计稿或页面截图按设计原则、间距系统、配色规范、层级关系进行审查输出问题清单和修改建议。UI 转代码技能UI to Code Skill把设计稿转换为 HTML/Tailwind、React/Vue 组件自动生成响应式代码并保留设计 token 映射。设计 Token 提取技能Design Token Extractor从设计稿或 CSS 文件中提取颜色、字体、间距、阴影等变量生成统一的 token JSON 文件。无障碍与合规检查技能A11y / Compliance Skill自动检查文本对比度、可点击区域大小、ARIA 标签、焦点状态等无障碍问题输出合规报告。2.3 工具链现状这里不展开所有工具的详细安装先给一个宏观判断Claude Code 的技能机制最适合做“复杂工作流型技能”因为它支持多步骤工具调用和脚本执行。Cursor 的 Rules 更适合做“代码风格约束型技能”例如输出组件时必须使用某个组件库。Codex 和 OpenCode 的生态还在快速迭代如果你本身就是 CLI 爱好者可以跟进它们最新版本的 Skills 文档。后面实战部分我会以“技能包目录结构 SKILL.md”为主线讲解因为它是一种比较通用的组织方式其他工具只要做少量适配也能复用。3. 环境准备与技能包文件结构3.1 运行环境先说明一下本文示例环境操作系统macOS 或 LinuxWindows 建议使用 WSL2。编程语言Python 3.10用于编写辅助脚本。运行时Node.js 18部分工具脚本需要。AI 编程助手Claude Code 或 Cursor版本以你实际情况为准本文重点是结构和思路。这些版本不需要完全一致因为技能包的核心是“文件组织 指令模板”具有较强的可迁移性。实际使用时请根据自己的模型版本调整。3.2 技能包目录结构一个标准的设计类技能包建议按下面的目录结构组织design-skills/ ├── design-review/ │ ├── SKILL.md │ ├── scripts/ │ │ └── check_contrast.py │ └── examples/ │ └── review-report.md ├── ui-to-code/ │ ├── SKILL.md │ ├── prompts/ │ │ └── react-component.md │ ├── templates/ │ │ └── component.tsx │ └── examples/ │ └── sample-output.tsx ├── design-tokens/ │ ├── SKILL.md │ ├── scripts/ │ │ └── extract_tokens.py │ └── schemas/ │ └── token.schema.json └── a11y-check/ ├── SKILL.md ├── scripts/ │ └── run_axe.py └── rules/ └── wcag-rules.md关键文件说明SKILL.md技能的主文件定义技能的用途、触发条件、工作流程、输出规范。scripts/配套脚本用于执行确定性检查例如对比度计算、token 提取。examples/示例输出帮助 Agent 理解理想结果长什么样。prompts/或templates/更细分的指令模板适合大型技能包。3.3 SKILL.md 的常见写法SKILL.md 本质上是一个“结构化 Markdown 文档”它不需要很复杂但信息必须清晰。下面是 design-review 技能的主文件示例# Design Review Skill ## 技能用途 用于对 UI 设计稿或页面截图进行设计走查输出结构化审查报告。 ## 适用场景 - 产品发布前 UI 走查 - 设计师交付前的自检 - 前端开发完成后的还原度检查 ## 输入要求 - 设计稿图片路径或 URL - 设计规范 JSON 文件可选 ## 工作流程 1. 读取设计稿或截图。 2. 提取页面中的颜色、字体、间距、圆角等视觉属性。 3. 与输入的设计规范进行比对。 4. 检查对比度、层级、间距一致性、对齐方式。 5. 输出 Markdown 格式审查报告。 ## 输出规范 审查报告必须包含 - 概述本次审查范围和时间 - 问题清单按严重程度分为 P0 / P1 / P2 - 每个问题的截图位置或坐标 - 修复建议 - 若所有项目通过输出“通过” ## 注意事项 - 不修改原始设计文件。 - 不确定的属性不要臆测标记为“需要确认”。 - 对比度计算请调用 scripts/check_contrast.js。这段文件看起来不复杂但它已经把 Agent 的工作范围限制得很清楚。实战中技能包越详细AI 输出的稳定性就越高。初学者最容易犯的错误是只写“请你检查一下这个设计稿”结果 AI 输出非常随机。正确做法是像上面这样把输入、流程、输出规范全部写死。4. 实战一设计审查技能Design Review Skill4.1 需求拆解我们希望实现一个“设计审查技能”它接收一张网页截图或设计稿能做以下事情识别页面主要 UI 元素。提取关键样式属性。对比设计规范。输出结构化审查报告。为了不让 AI 完全凭“感觉”判断对比度我们准备一个 Python 脚本计算 WCAG 对比度AI 在审查时调用脚本获得可靠数值。4.2 编写技能定义文件路径design-skills/design-review/SKILL.md# Design Review Skill ## 技能用途 对 UI 设计稿、页面截图进行设计走查输出结构化审查报告。 ## 适用场景 - UI 走查 / 视觉验收 - 设计交付前自检 - 前端还原度检查 ## 输入要求 - 图片路径设计稿或网页截图 - 可选设计规范 JSON 文件包含 color / spacing / font 定义 ## 工作流程 ### 步骤 1读取并理解设计稿 - 如果输入是图片描述页面整体布局、主要区块和组件。 - 如果输入是 HTML 或代码文件直接分析 DOM 结构和样式。 ### 步骤 2提取视觉属性 - 记录页面中出现的颜色值。 - 记录主要间距、圆角、字号。 - 记录元素之间的对齐关系。 ### 步骤 3对比设计规范 - 如果提供了设计规范 JSON逐项比对。 - 如果没有提供规范则基于常见设计原则做人工判断。 ### 步骤 4计算对比度 - 对文本颜色与背景颜色调用 python3 scripts/check_contrast.py color1 color2。 - 根据 WCAG AA 标准判断是否通过。 - 普通文本对比度 4.5:1 - 大号文本对比度 3:1 ### 步骤 5输出审查报告 报告必须包含 1. 审查范围概述 2. 问题清单P0 / P1 / P2 3. 每个问题的位置、截图坐标、说明 4. 修复建议 5. 最终结论通过 / 需修改 ## 报告模板 markdown ## 设计审查报告 - 审查对象: {页面名称} - 审查时间: {当前时间} - 审查人员: AI Design Reviewer ### 问题清单 | 级别 | 位置 | 问题描述 | 建议 | | --- | --- | --- | --- | | P1 | 顶部导航 | 文本对比度为 3.2:1低于 WCAG AA 标准 | 将文字颜色调整为 #1A1A1A | ### 通过项 - 间距系统符合 8px 网格规则 - 圆角与 design token 一致 **结论需修改**注意事项不修改任何源文件。对颜色值不确定时标为“需要人工确认”。对比度计算必须使用脚本不能凭目测估计。这里有一个很关键的设计我们要求 AI 必须调用脚本计算对比度而不是自己“估算”。这是技能包与普通提示词的显著区别它把确定性计算回归到了代码从而减少模型幻觉。 ### 4.3 配套脚本 文件路径design-skills/design-review/scripts/check_contrast.py python #!/usr/bin/env python3 计算两个十六进制颜色之间的 WCAG 对比度。 用法python3 check_contrast.py #FFFFFF #000000 import sys import re def hex_to_rgb(hex_color: str) - tuple: 将 #RRGGBB 转为 (r, g, b) 元组取值 0~255。 hex_color hex_color.strip().lstrip(#) if len(hex_color) ! 6: raise ValueError(f无效颜色值{hex_color}请输入 #RRGGBB 格式) return tuple(int(hex_color[i:i2], 16) for i in (0, 2, 4)) def relative_luminance(rgb: tuple) - float: 计算相对亮度WCAG 2.x 标准。 vals [] for c in rgb: c c / 255.0 if c 0.03928: vals.append(c / 12.92) else: vals.append(((c 0.055) / 1.055) ** 2.4) return 0.2126 * vals[0] 0.7152 * vals[1] 0.0722 * vals[2] def contrast_ratio(color1: str, color2: str) - float: 计算两个颜色之间的对比度。 lum1 relative_luminance(hex_to_rgb(color1)) lum2 relative_luminance(hex_to_rgb(color2)) lighter max(lum1, lum2) darker min(lum1, lum2) return (lighter 0.05) / (darker 0.05) def main(): if len(sys.argv) ! 3: print(用法python3 check_contrast.py color1 color2) sys.exit(1) c1 sys.argv[1] c2 sys.argv[2] try: ratio contrast_ratio(c1, c2) except ValueError as e: print(f错误{e}) sys.exit(1) print(f对比度{ratio:.2f}:1) if ratio 4.5: print(结果通过WCAG AA 普通文本) elif ratio 3.0: print(结果通过WCAG AA 大号文本) else: print(结果不通过) if __name__ __main__: main()运行方式python3 check_contrast.py #FFFFFF #333333预期输出对比度12.63:1 结果通过WCAG AA 普通文本4.4 运行与验证把上面的技能包加载到 Claude Code 或 Cursor 后你可以这样触发输入请使用 design-review 技能检查一下 examples/homepage.png并和 design-tokens.json 对比。技能会先读取图片再按 SKILL.md 里的步骤执行。遇到颜色对比度判断时调用 Python 脚本。最后输出 Markdown 报告。注意不同 AI 工具的加载方式可能不同比如 Claude Code 可能会要求你把技能包放到指定目录Cursor 则可能通过 Rules 文件描述。建议先读官方文档确认不能用本文的目录结构硬套所有工具。5. 实战二UI 转代码技能UI to Code Skill5.1 为什么这会让设计界震撼如果说设计审查是“辅助检查”那“UI 转代码”就是直接冲击设计师与工程师协作边界的能力。过去一个设计稿还原成代码需要前端工程师投入大量手动工作。而当你给 AI 配上 UI to Code 技能后它能读取设计稿或设计稿导出图。分析视觉层级和布局。生成符合项目技术栈的代码。自动绑定设计 token。输出响应式和可访问性友好的组件。下面我们定义一个“UI to Code”技能以 React TypeScript Tailwind 环境为例。5.2 技能文件文件路径design-skills/ui-to-code/SKILL.md# UI to Code Skill ## 技能用途 将设计稿转换为高质量 React TypeScript 组件代码。 ## 适用场景 - 根据 Figma 设计稿生成前端组件 - 设计系统组件扩展 - 前端原型快速搭建 ## 输入要求 - 设计稿图片路径或设计稿导出的 HTML 结构 - 可选设计 token JSON 文件 - 可选组件库约定例如 shadcn/uiAnt Design ## 技术栈默认配置 - React 18 - TypeScript 5 - Tailwind CSS 3 - 可选shadcn/ui 组件 ## 工作流程 ### 步骤 1解析设计稿 - 识别页面整体布局结构。 - 将设计稿按视觉区块拆分Header、Hero、Feature、Footer 等。 - 命名组件时使用语义化名称。 ### 步骤 2映射设计 Token - 如果有 token JSON颜色、间距、字号必须引用 token不能硬编码。 - 如果没有 token JSON在组件顶部生成一个 const tokens {...} 用于集中管理。 ### 步骤 3生成组件代码 - 每个区块生成独立的组件文件。 - 组件内使用 Tailwind 类名实现样式。 - 对有状态交互的控件下拉框、弹窗标注 需要额外实现。 ### 步骤 4添加无障碍属性 - 图片必须包含 alt。 - 按钮必须有可读文本或 aria-label。 - 使用语义化标签header / nav / main / section / footer。 ### 步骤 5输出 - 输出文件清单和每个组件的完整代码。 - 组件之间使用默认导出。 - 最后输出一个 index.tsx 汇总入口。 ## 输出规范 每个组件文件必须包含 - 技术栈说明注释 - 组件 props 类型定义 - 完整的 JSX 结构 - Tailwind class ## 注意事项 - 没有把握的交互逻辑不要硬写输出 TODO 注释。 - 必须保证 TypeScript 类型完整。 - 不引入未说明的第三方依赖。5.3 设计 Token 示例在实际生成前你可以让 AI 参考下面这样的 token JSON{ colors: { primary: #2563EB, background: #FFFFFF, text: #1A1A1A, muted: #6B7280 }, spacing: { xs: 4px, sm: 8px, md: 16px, lg: 24px, xl: 48px }, font: { body: Inter, sans-serif, heading: Inter, sans-serif, size-sm: 14px, size-base: 16px, size-lg: 24px }, radius: { sm: 4px, md: 8px, lg: 12px } }配合 token 文件的技能生成出来的代码不会出现“硬编码颜色”的问题。这也是好评与差评之间的一道分水岭好的 UI 转代码技能生成的是“符合设计系统的组件”差的则是“八竿子打不着的临时样式”。5.4 运行流程给 AI 提供一张卡片组件的设计稿图并输入请使用 ui-to-code 技能把这张设计稿转换成 React 组件参考资料为 design-tokens.json。预期输出可能包含// Card.tsx import React from react; interface CardProps { title: string; description: string; imageUrl?: string; actions?: React.ReactNode; } const tokens { colorPrimary: #2563EB, colorBackground: #FFFFFF, colorText: #1A1A1A, spacingMd: 16px, spacingLg: 24px, radiusLg: 12px, }; export default function Card({ title, description, imageUrl, actions }: CardProps) { return ( div classNamebg-white rounded-xl shadow-sm style{{ backgroundColor: tokens.colorBackground, borderRadius: tokens.radiusLg, padding: tokens.spacingLg, }} {imageUrl ( img src{imageUrl} alt{title} classNamew-full h-48 object-cover rounded-lg / )} h3 classNamemt-4 text-lg font-semibold style{{ color: tokens.colorText }} {title} /h3 p classNamemt-2 text-sm style{{ color: tokens.colorMuted }} {description} /p {actions div classNamemt-4{actions}/div} /div ); }注意示例代码只是一个“技能演示”实际生成结果会根据设计稿内容变化。上面这段代码已经能看出 token 映射的痕迹也保留了语义化结构和图片 alt体现了技能约束的效果。6. 实战三设计系统与无障碍检查技能6.1 技能用途很多团队已经有设计系统组件库但缺少自动化的“合规检查”。我们可以配置一个 A11y 检查技能让 AI 自动检查页面中的无障碍问题。6.2 配置文件路径design-skills/a11y-check/SKILL.md# A11y Check Skill ## 技能用途 对 HTML / React 页面进行无障碍检查输出 WCAG 2.1 AA 合规报告。 ## 输入要求 - HTML 文件路径或 React 组件代码 - 可选页面 URL需要浏览器工具联动 ## 检查项 1. 图片是否有 alt 属性 2. 表单控件是否有 label 3. 文本颜色对比度是否达标 4. 可点击元素是否有键盘焦点样式 5. 按钮是否使用 button 标签而非 div 6. ARIA 属性使用是否正确 ## 工作流程 1. 解析输入。 2. 逐项检查。 3. 无法静态判断的项标记为“需要人工验证”。 4. 输出合规报告。配合脚本时可以用 axe-core 这类工具做 DOM 级扫描AI 再结合扫描结果生成报告。这样就避免了 AI 只看代码片段、忽略真实渲染结果的问题。6.3 与浏览器工具联动如果使用 Claude Code 或支持 MCP 的工具可以接入 Playwright MCP Server让 AI 自动打开页面、执行点击操作、提取真实 DOM。通过这种方式A11y 检查不再局限于“静态代码”而是可以做端到端的真实交互检查。典型流程AI 使用技能包中的指令。AI 调用 Playwright 工具打开页面。Playwright 执行 axe 扫描。扫描结果回传给 AI。AI 输出报告标记严重级别。这里的配置方式因工具而异我不展开具体命令行安装步骤以免版本差异导致误导。核心思路是技能负责“规则和报告结构”MCP 负责“连接外部工具”两者结合才能发挥最大作用。7. 常见问题与排查思路在实践 AI skills 的过程中最容易踩到下面这些坑问题现象常见原因解决思路技能没有生效技能包目录结构不正确或 SKILL.md 命名错误确认工具要求的目录和命名规范输出仍然很随机技能指令太模糊缺少工作流程和输出规范像写测试用例一样完善 SKILL.md颜色对比度判断错误AI 直接估算没有调用脚本在 SKILL.md 中强制要求调用脚本生成代码硬编码颜色没有提供 token 文件或技能未强制映射提供 token JSON并在指令中写死技能包无法跨工具使用不同工具对技能格式支持不一致以核心 SKILL.md 为主按工具适配上下文太长导致效果下降技能包过大加载了太多无用内容拆分成多个小技能按需加载脚本执行权限失败缺少 python 依赖或脚本没有可执行权限检查 Python 环境和 chmod 权限如果你不确定问题出在哪建议按下面的顺序排查先确认技能文件是否被正确加载。很多工具会打印加载日志或者你可以故意在 SKILL.md 里写一个错误指令看 AI 会不会执行。再确认技能指令是否明确。输出规范越明确结果越稳定。接着检查脚本是否可独立运行。如果脚本本身失败AI 就会跳过调用直接靠直觉输出。最后看示例输出。技能包里的 examples 文件能显著提升 AI 的模仿质量。8. 最佳实践与工程建议8.1 命名与目录规范技能命名尽量使用“动作 对象”的格式例如design-reviewui-to-codetoken-extracta11y-check避免使用“ai-design-agent-v1-final”这种名字时间一长就很难维护。每个技能包内部建议保持统一结构SKILL.mdscripts/examples/三个目录是底线。8.2 版本管理与测试技能包也是代码应该纳入 Git 版本管理。每当你修改 SKILL.md 或脚本建议使用独立的 Git 分支。用一组固定的测试用例验证输出。把测试用例也放在技能包目录的tests/下。以 design-review 为例测试用例可以是这样import subprocess def test_contrast(): result subprocess.run( [python3, scripts/check_contrast.py, #FFFFFF, #333333], capture_outputTrue, textTrue, checkFalse, ) assert 通过 in result.stdout有了测试团队其他人修改技能包时就不容易破坏原有行为。8.3 安全与合规边界把 AI skills 应用到设计场景时有几点安全建议API Token 权限最小化如果技能需要读取 Figma、代码仓库或云服务建议使用只读 Token并设置短时效。不自动修改源文件设计审查类技能默认不要修改原始设计稿。避免上传敏感设计稿如果设计稿包含未公开产品原型或客户数据不要直接发送给云端模型。优先选择私有化部署或脱敏处理。版权与授权生成 UI 代码时若要参考第三方设计资源、图标库或组件库必须先确认授权范围。不要从设计稿逆向提取字体文件或素材包。区分 AI 辅助与人工确认无障碍合规审查、品牌规范检查这些环节AI 报告只能作为辅助材料最终应由负责人确认。8.4 团队共享与文档化建议把技能包作为团队内部的开源项目维护一个仓库统一管理所有设计类技能。每个技能包带 README说明适用场景、调用方式、输出示例。新成员加入时只需要拉取仓库并在 AI 工具中配置就能获得同样的“设计加持”。最终目标是形成一套团队级的“设计语言”不管是谁来写前端代码加载同一套技能后AI 生成的代码会保持高度一致。9. 后续可以继续优化的方向到这里设计类 AI skills 的完整思路已经比较清晰了我们从“提示词”聊到了“技能包”。从设计审查、UI 转代码、无障碍检查三个实战案例看到了 AI 自动化设计交付的可能性。同时我们也清楚认识到AI 并不是万能钥匙它的有效性高度依赖技能文件的质量、配套脚本的可靠性以及团队是否遵守安全与合规边界。如果你接下来想深入可以从这几个方向继续把 design-tokens 技能做成 Figma API 联动自动拉取设计变量。给 ui-to-code 技能增加组件库适配例如让输出直接对接 shadcn/ui 或 Ant Design。使用 Playwright 做更完整的视觉回归测试让 AI 定期自动走查页面并生成比对报告。把技能包发布到团队内部仓库或公共资源平台形成一个可持续迭代的“设计 AI 插件生态”。AI skills 并不神秘它的价值也不在于“一次性生成完美结果”而在于把你和团队的设计经验沉淀成可复用、可测试、可演进的能力包。希望这篇文章能帮你在“AI 替代一部分设计工作”的浪潮里掌握主动权而不是被动接受工具的变化。如果后面有时间我再单独拆解 Figma API 对接、Playwright 视觉回归和团队私有化技能仓库的落地细节。你也可以先在本地把设计审查技能跑通感受一下“AI 从只会聊天到真正会干活”的差别。