最近这两周“AI skills”这个词在开发者社区里的热度上升得非常快而且第一批被吸引过来的不只是程序员还有大量设计师和前端工程师。原因并不复杂过去我们和 AI 对话它只能“回答问题”或者“生成一段代码”一旦任务稍微复杂一点——比如“依据设计稿里的 Design Token 生成一整份主题配置再校验一遍命名是否规范”——AI 就会开始东一句西一句输出质量完全随机。而 Skills 机制出现之后这类多步骤、需要专业判断和固定规范的任务第一次可以被稳定地封装、复用和分发。这篇文章不打算复述一遍官方文档而是想讲清楚三件事第一AI Skills 到底是什么它和普通 Prompt、和 AI Agent 有什么区别第二为什么它会率先在设计相关的工作流里引发关注第三作为开发者或设计师你可以怎样编写、安装和使用一个真正能落地的 Skill。文章最后会给出完整示例代码你复制到本地就能跑通一个最小流程。如果你最近正在研究 AI Agent、Claude Code skills、Codex skills 或者前端开发 skills这篇文章应该能帮你把概念和实操一次性理顺。1. AI Skills 到底是什么为什么设计界会关注它很多人第一次听到“AI skills”第一反应是这不就是更长的 Prompt 吗这个理解只对了一半。AI Skills 的完整形态其实是一个“结构化的技能包”。它不只是几句提示词而是把任务描述、执行步骤、参考示例、可运行脚本、验证规则打包在一起放在一个独立的目录里。当 AI Agent 接到相关任务时它会主动读取这个技能包按照里面定义好的流程去执行而不是临时凭感觉发挥。举一个设计场景的例子。假设你负责一套企业级 UI 组件库的维护设计团队每次更新 Design Token前端都要手动把 Figma 导出的 JSON 转换成 CSS 变量、Tailwind 主题配置或者小程序样式文件。这个过程看起来不复杂但实际做起来很麻烦命名风格要统一颜色要转成 hsl 或 oklch圆角要映射到正确的语义层级深色模式还要额外处理一套变量。如果直接让 AI 来做它可能第一次生成得不错第二次就换了一套命名规则第三次连缩进都变了。有了 Skill 之后你可以把“Design Token 转主题配置”这一整套经验写成一份技能包里面写明输入文件是什么样的、输出文件必须用哪套命名规范、转换脚本放在哪个路径、结果校验需要跑哪条命令。Agent 每次启动任务时会加载这份技能包输出稳定到像执行一次自动化流水线。设计界会关注 AI Skills核心原因就是它解决了 AI 生成结果“不稳定”的问题。设计师和前端配合时最怕的不是 AI 不会写代码而是 AI 每次给出的结果都不一样无法沉淀成团队资产。Skills 机制第一次把“人的经验”变成了“AI 的可执行模块”这东西对设计规范落地、UI 还原、前端联调这类任务来说价值是直接且明显的。2. Skills、Prompt、Agent 三者的边界要真正理解 Skills最好把几个高频概念放到一起对比。概念本质发挥作用的方式简单类比Prompt一次性指令每次对话时临时输入告诉 AI 本次要做什么给实习生的口头任务Agent自主执行体一个大模型驱动的“员工”能拆解任务、调用工具、逐步执行一个可以独立干活的实习生Skill技能包/工作手册给 Agent 提供的结构化知识库和可执行脚本让它稳定完成某类任务实习生手里拿到的“岗位 SOP 工具箱”从这个角度看Skills 并不是 Prompt 的替代品而是 Agent 的“能力底座”。没有 Skills 的 Agent像一个有悟性但没有经验的实习生。你给它一个模糊任务它能做但质量不稳定。你夸它一句“做得不错”它下次可能换个思路你批评一次它可能改得过头。有了 SkillsAgent 就相当于拿到了一份写清楚“干什么、怎么干、用什么工具干、干完怎么验证”的岗位手册表现会稳定很多。在技术实现上目前主流的 AI 编程工具包括 Claude Code、Codex、Cursor以及国内一些 AI 编程助手都在往这个方向走。不同工具的 Skills 目录结构和加载方式略有差异但核心思路一致在项目里放一个skills或.claude/skills目录里面每个子目录就是一个技能包包含说明文件、脚本和资源。Agent 在对话中识别到相关任务时会去读取这些技能包。这里要划一个重点Skills 不是魔法它不会让 AI 突然学会一个它本来就不会的能力。它的作用是“约束过程”和“注入经验”。AI 本身依然是那个大模型但 Skill 提供了更好的上下文、更明确的步骤、更可靠的校验方式所以最终结果的质量和稳定性会显著提升。3. AI Skills 对设计工作流的真实改变设计行业和软件工程的交界地带一直有很多“看似简单、实则重复”的工作。它们不需要特别高的创造力但需要严格遵守规范比如设计稿还原、Design Token 转换、切图命名、组件状态整理、视觉走查。这些工作恰恰是 AI Skills 最容易发挥价值的地方。3.1 设计稿转代码从“一次性生成”变成“反复可用”过去我们用 AI 做设计稿转代码是一个“一次性对话”的体验上传设计稿截图让 AI 生成 HTML/CSS然后复制到项目里微调。下一次再做类似页面又得重新描述一遍需求AI 又是从零开始发挥。Skill 改变的是这个流程。你可以把团队的前端代码规范、组件库用法、样式方案写进技能包。后续每次做页面还原Agent 会自动加载这份规范生成的代码从一开始就符合团队约定而不是生成完了再改。3.2 设计系统维护从“人工搬砖”变成“自动同步”设计系统最核心的资产是 Design Token。设计侧改了主色、间距、字体大小前端侧需要同步更新多处配置文件。用 Skill 后整个同步过程可以变成一个命令npx ai-token-sync ./design-tokens.json ./src/theme这条命令背后Agent 会读取技能包执行转换脚本自动生成或更新主题文件并根据规则校验颜色对比度、命名规范等。传统需要半小时的同步工作压缩到了几分钟而且过程可重复。3.3 视觉走查从“人眼比对”变成“规则校验”设计师最怕的是前端还原出来的页面颜色差一点、圆角差一点、间距差一点。用 AI 做视觉走查时如果只是简单地把设计稿和截图丢给 AI 看它给出的结论往往比较模糊。但如果写一个视觉走查 Skill把团队的误差容忍度、重点检查清单、常见问题库都写进去AI 就能产出格式统一的走查报告甚至能自动定位到具体元素和样式代码。这种变化的本质是把过去存在于资深设计师脑子里的“隐性经验”变成 AI 可以反复调用的“显性规则”。AI 没有取代设计师的判断力但它让判断力的传递和复用变得更便宜了。4. AI Skills 的标准结构与编写方法目前社区里主流的 Skill 结构基本可以概括为“一个目录 一个说明文件 若干脚本/资源”。下面是一个最常见的最小目录结构my-skill/ ├── SKILL.md ├── scripts/ │ └── convert_tokens.py ├── assets/ │ └── example-input.json └── README.md4.1 SKILL.md 是技能包的核心SKILL.md是整个技能包的大脑。它通常包含两部分内容开头的 YAML frontmatter 和正文。YAML frontmatter 里最重要字段是name和description。description尤其关键因为 Agent 会通过它来判断“当前用户的请求是否应该触发这个技能包”。如果 description 写得太宽泛Agent 可能会在无关任务时也加载它浪费上下文写得太狭窄Agent 又识别不出来Skill 形同虚设。正文部分需要写清楚的事情包括这个 Skill 适用于什么场景不适用于什么场景输入是什么输出是什么执行步骤是什么先后顺序如何需要调用哪些脚本脚本的输入参数如何传递输出结果如何校验什么样的结果算合格。听起来像写技术方案但实际上这就是把一次高质量人工任务的做事流程完整地“教”给了 AI。4.2 一个最小 SKILL.md 示例假设我们要写一个“Design Token 转 Tailwind 主题配置”的 SkillSKILL.md可以这样写--- name: design-token-to-tailwind description: 将设计团队的 Design Token JSON 文件转换为 Tailwind CSS 主题配置。当用户提供 design-tokens.json 或提到“同步设计变量”“生成 tailwind 主题”“转换 token”时使用。 --- # Design Token 转 Tailwind 主题配置 将输入的设计 Token JSON 转换为 Tailwind CSS 的 tailwind.config.js 中 theme.extend 可用的配置片段。 ## 使用场景 - 设计团队更新了 Design Token需要同步前端主题配置 - 需要从零为项目生成 Tailwind 主题基础变量 ## 不适用场景 - 不需要处理组件级样式代码 - 不负责图片资源压缩 ## 输入 - Design Token JSON 文件格式参考 assets/example-input.json ## 执行步骤 1. 读取 Design Token JSON。 2. 运行 python scripts/convert_tokens.py input.json output.js 转换文件。 3. 检查生成的 JS 文件是否符合输出规范。 ## 输出规范 - 颜色统一使用 hsl 格式。 - 命名采用 camelCase。 - 每个 token 注释中标注原始 token 名方便追溯。 ## 校验方式 运行 node -e require(./output.js)确保没有语法错误。4.3 脚本放在 scripts 目录Skill 的优势在于它可以调用真正的脚本来完成 AI 不擅长的工作。比如格式转换、批量文件处理、数据校验和计算这些任务用传统编程脚本做更可靠。AI 主要负责理解用户意图、拼接上下文、调用脚本最后整理输出结果。这其实是 AI Skills 一个很容易被忽视的设计思想不要让 AI 做它不擅长的事而是让 AI 把任务拆解给合适的工具。对于设计 Token 转换这种需要精确计算和稳定格式的任务脚本比大模型更可靠。5. 完整示例把 Design Tokens 转成 Tailwind 主题配置下面这个示例你可以直接复制到本地跑通。它能帮你直观理解 Skill 从编写到使用的全过程。5.1 准备项目目录先创建一个项目目录并建立以下结构mkdir -p design-token-skill/{scripts,assets} cd design-token-skill最终目录结构design-token-skill/ ├── SKILL.md ├── scripts/ │ └── convert_tokens.py └── assets/ └── example-input.json5.2 编写输入样例assets/example-input.json{ color: { primary: { default: #3B82F6, hover: #2563EB, disabled: #93C5FD }, neutral: { background: #F9FAFB, text: #111827, border: #E5E7EB } }, radius: { sm: 4px, md: 8px, lg: 12px }, spacing: { page: 24px, section: 16px, item: 8px } }这个样例模拟了设计团队导出的一份简化版 Design Token包含颜色、圆角、间距三类变量。5.3 编写转换脚本scripts/convert_tokens.py的作用是读取输入 JSON输出一份 Tailwind 配置片段。这里我们用 Python 标准库实现不依赖第三方包#!/usr/bin/env python3 # scripts/convert_tokens.py import json import sys from pathlib import Path def hex_to_hsl(hex_color: str) - str: 将 HEX 颜色转换为 hsl() 字符串。 hex_color hex_color.lstrip(#) if len(hex_color) ! 6: return hex_color r int(hex_color[0:2], 16) / 255 g int(hex_color[2:4], 16) / 255 b int(hex_color[4:6], 16) / 255 max_c max(r, g, b) min_c min(r, g, b) delta max_c - min_c if delta 0: h 0 elif max_c r: h 60 * (((g - b) / delta) % 6) elif max_c g: h 60 * (((b - r) / delta) 2) else: h 60 * (((r - g) / delta) 4) l (max_c min_c) / 2 if delta 0: s 0 else: s delta / (1 - abs(2 * l - 1)) return fhsl({round(h)}, {round(s * 100)}%, {round(l * 100)}%) def convert_token_group(group: dict, output: dict, prefix: str ) - None: 递归转换 token 分组生成扁平化且保留分组的输出结构。 for key, value in group.items(): current_key f{prefix}{key} if prefix else key if isinstance(value, dict): output[current_key] {} convert_token_group(value, output[current_key], prefix) elif key default: output[key] value else: output[prefix key] value def main(): if len(sys.argv) ! 3: print(用法: python scripts/convert_tokens.py input.json output.js) sys.exit(1) input_path Path(sys.argv[1]) output_path Path(sys.argv[2]) with input_path.open(r, encodingutf-8) as f: tokens json.load(f) theme {} if color in tokens: theme[colors] {} for color_group, color_values in tokens[color].items(): theme[colors][color_group] {} for shade, hex_value in color_values.items(): theme[colors][color_group][shade] hex_to_hsl(hex_value) if radius in tokens: theme[borderRadius] {} for size, radius_value in tokens[radius].items(): theme[borderRadius][size] radius_value if spacing in tokens: theme[spacing] {} for size, spacing_value in tokens[spacing].items(): theme[spacing][size] spacing_value js_content // 自动生成请勿手动编辑\n// 来源: design-tokens.json\n\n js_content module.exports json.dumps(theme, indent2, ensure_asciiFalse) ;\n output_path.write_text(js_content, encodingutf-8) print(f转换完成输出文件: {output_path}) if __name__ __main__: main()这段脚本的核心逻辑是把颜色值统一转成hsl()格式然后按colors、borderRadius、spacing三个分组生成 Tailwind 配置。设计团队改一次 token前端跑一次脚本就能重新生成主题配置避免了手动改 CSS 变量时容易出现的漏改和标注不一致。5.4 运行并验证在项目目录下执行python scripts/convert_tokens.py assets/example-input.json output.js预期生成的output.js大致如下// 自动生成请勿手动编辑 // 来源: design-tokens.json module.exports { colors: { primary: { default: hsl(217, 91%, 60%), hover: hsl(221, 83%, 53%), disabled: hsl(214, 95%, 78%) }, neutral: { background: hsl(0, 0%, 98%), text: hsl(220, 9%, 20%), border: hsl(220, 13%, 91%) } }, borderRadius: { sm: 4px, md: 8px, lg: 12px }, spacing: { page: 24px, section: 16px, item: 8px } };验证命令node -e const theme require(./output.js); console.log(theme.colors.primary.default);如果输出hsl(217, 91%, 60%)说明脚本和输出文件都是正常的。这一步也是 Skill 描述里“校验方式”可以复用的做法。6. 如何安装和使用 AI Skills写完一个 Skill 之后还需要让 AI Agent 能加载到它。这里以主流的 AI 编程工具为例介绍通用的安装和配置思路。不同工具的目录名会有差异但底层逻辑基本一致把 Skill 放到 Agent 会扫描的目录里或者在项目配置中声明 skills 目录。6.1 放置到 Agent 的 Skills 目录以 Claude Code 这类工具常见的项目结构为例你可以在项目根目录创建mkdir -p .claude/skills/design-token-to-tailwind然后将前面写好的SKILL.md、scripts、assets拷贝到这个目录下cp -r SKILL.md scripts assets .claude/skills/design-token-to-tailwind/此时目录结构为你的项目/ ├── .claude/ │ └── skills/ │ └── design-token-to-tailwind/ │ ├── SKILL.md │ ├── scripts/ │ │ └── convert_tokens.py │ └── assets/ │ └── example-input.json ├── design-tokens.json └── src/把design-tokens.json放到项目里后你只需要在对话中告诉 Agent“根据 design-tokens.json 生成 Tailwind 主题。”Agent 如果正确识别到这个请求就会自动加载design-token-to-tailwind这个技能包按SKILL.md里定义的步骤执行转换脚本并输出结果。6.2 在全局配置中声明 Skills如果你希望某个 Skill 对所有项目全局生效一般可以将它放到用户目录下的 Skills 目录中例如mkdir -p ~/.claude/skills/design-token-to-tailwind cp -r SKILL.md scripts assets ~/.claude/skills/design-token-to-tailwind/不同 AI 编程工具的全局目录名称不太一样有些使用~/.codex/skills有些使用~/.cursor/skills还有团队会习惯放在内部代码仓库统一维护。使用前先确认一下你所用工具的文档或者直接看社区里分享的安装方式。稳妥的做法是先在项目级目录里跑通再决定是否要全局安装这样可以减少误触发。6.3 通过命令行快速启用如果你的 Skill 本身带有命令行入口也可以直接在项目脚本里配置。比如在package.json中添加一个 npm script{ scripts: { tokens:sync: python .claude/skills/design-token-to-tailwind/scripts/convert_tokens.py design-tokens.json src/theme/generated.js } }这样团队成员不需要了解 Agent 交互直接执行npm run tokens:sync也能完成同样的转换任务。也就是说Skill 里的脚本不一定只能由 AI Agent 调用它本身也是一个可复用的工程化工具。这种“Agent 可调用人也可直接运行”的双重属性是 Skill 比普通 Prompt 更工程化的关键。7. 常见问题与排查思路在编写和使用 AI Skills 的过程中有些问题几乎每个人都会遇到。下面这张表汇总了最高频的几类问题和排查方向。问题现象可能原因排查方式解决方案Agent 识别不到 Skill始终按普通对话响应SKILL.md中description描述不到位检查描述中是否包含触发场景的关键词在对话中尝试用更明确的任务表述重写description覆盖常见任务描述避免使用过于宽泛的词汇Skill 被加载了但 Agent 不执行脚本脚本路径配置错误或 Agent 没有执行权限查看 Agent 日志确认工作目录尝试手动运行脚本在SKILL.md中写清脚本路径用绝对路径或相对项目根的路径脚本运行报错提示找不到文件输入文件路径与脚本预期不一致检查当前工作目录确认输入 JSON 是否存在在SKILL.md中明确输入文件位置脚本内增加路径参数校验输出结果不是预期的格式脚本逻辑与SKILL.md中的输出规范不一致检查脚本转换逻辑用样例文件逐步调试先用assets/example-input.json跑通脚本再处理真实输入同一个 Skill 在不同项目里表现不同技能包没有固定版本或依赖了项目内路径检查项目内是否覆盖了全局 Skill确认脚本是否有硬编码路径使用目录相对路径Skill 纳入独立 git 仓库通过 tag 做版本管理Agent 执行了 Skill但结果不稳定SKILL.md描述不够具体AI 有机会自行发挥复盘执行记录看 AI 是在哪一步偏离了规范细分执行步骤对关键输出增加自动校验命令最需要提醒的是Skill 的核心价值在“规范”两个字。如果你的SKILL.md写得很模糊那么 AI 的表现自然也会模糊。写 Skill 跟写需求文档一样细节越清晰结果越可控。8. 最佳实践与工程建议当你准备把 AI Skills 用到实际项目或团队协作中时下面这些建议值得提前考虑。8.1 Skill 描述要写在“触发条件”description不是简单介绍这个功能而是写给 Agent 的“触发识别器”。建议用这样的句式当用户【提供什么输入】或【表达什么意图】时使用本技能。不要用“这是一个转换工具”这种泛泛的话术而要用“设计 Token 转 Tailwind”“同步设计变量”“生成主题配置”这类任务导向的描述。8.2 脚本保持幂等和简洁Skill 里的脚本应该做到重复执行多次结果一致不依赖执行者的个人环境不产生意外的副作用。输出文件最好标注“自动生成请勿手动编辑”必要的时候可以生成临时文件预览确认无误后再覆盖正式文件。8.3 考虑安全边界让 Agent 自动执行脚本相当于赋予了它调用本机命令的能力。因此 Skill 脚本里要遵守最小权限原则只在明确指定的目录内读写文件不主动删除文件不读取环境变量以外的敏感信息。如果你希望 Skill 支持自动化写回文件建议先输出到目标目录的临时文件经人确认后再替换。任何涉及数据删除、覆盖或认证信息的操作都要经过合法授权并在测试环境验证后再用于生产。这一点在团队协作时尤其重要否则一个写得不严谨的 Skill 可能会误改团队公共配置。8.4 把 Skill 当作代码来管理Skill 有目录、有文件、有脚本、有版本本质上就是一个代码工程。团队内部使用多个 Skill 时建议单独建一个仓库维护使用语义化版本号。Skill 的更新要走代码评审而不是改完就广播。设计团队的 Style Guide 更新后Skill 里的转换规则和示例样例也要同步更新否则会出现“设计规范已经变了但 AI 还在沿用旧规则”的情况。8.5 先跑通最小示例再扩展复杂度如果你是第一次接触 AI Skills不建议一上来就写一个庞大的技能包。先复制本文第 5 节的示例在你的 Agent 工具里跑通一次确认加载机制、脚本调用路径都正常再逐步加入校验命令、多场景分支、参考样例。这个顺序能帮你快速建立对 Skill 工作方式的直觉也更容易定位问题。9. 下一步可以做些什么如果你已经理解了 AI Skills 的机制下一步最值得做的事情是从你自己最讨厌的那类重复工作里抽一个出来写成 Skill。设计师可以从“导图规范命名”开始前端可以从“接口数据转 TypeScript 类型”开始测试同学可以从“按缺陷模板生成 Bug 报告”开始。一个 Skill 不需要覆盖很大的场景只需要把一个小任务做到稳定、可复用它的价值就已经超过了大部分泛泛而谈的 AI 使用技巧。Skill 的本质不是魔法而是把过去散落在人脑里的经验压缩成一个 Agent 可以稳定执行的工作包。设计界的下一步也许不是让 AI 取代设计师而是让每一位设计师都能把自己的判断写成 Skill。当这些技能包慢慢沉淀下来设计系统维护、设计稿还原、前端联调这些琐碎工作才会真正变轻。 AI Skills 实战：从 Prompt 到可复用能力包，重构设计工作流
最近这两周“AI skills”这个词在开发者社区里的热度上升得非常快而且第一批被吸引过来的不只是程序员还有大量设计师和前端工程师。原因并不复杂过去我们和 AI 对话它只能“回答问题”或者“生成一段代码”一旦任务稍微复杂一点——比如“依据设计稿里的 Design Token 生成一整份主题配置再校验一遍命名是否规范”——AI 就会开始东一句西一句输出质量完全随机。而 Skills 机制出现之后这类多步骤、需要专业判断和固定规范的任务第一次可以被稳定地封装、复用和分发。这篇文章不打算复述一遍官方文档而是想讲清楚三件事第一AI Skills 到底是什么它和普通 Prompt、和 AI Agent 有什么区别第二为什么它会率先在设计相关的工作流里引发关注第三作为开发者或设计师你可以怎样编写、安装和使用一个真正能落地的 Skill。文章最后会给出完整示例代码你复制到本地就能跑通一个最小流程。如果你最近正在研究 AI Agent、Claude Code skills、Codex skills 或者前端开发 skills这篇文章应该能帮你把概念和实操一次性理顺。1. AI Skills 到底是什么为什么设计界会关注它很多人第一次听到“AI skills”第一反应是这不就是更长的 Prompt 吗这个理解只对了一半。AI Skills 的完整形态其实是一个“结构化的技能包”。它不只是几句提示词而是把任务描述、执行步骤、参考示例、可运行脚本、验证规则打包在一起放在一个独立的目录里。当 AI Agent 接到相关任务时它会主动读取这个技能包按照里面定义好的流程去执行而不是临时凭感觉发挥。举一个设计场景的例子。假设你负责一套企业级 UI 组件库的维护设计团队每次更新 Design Token前端都要手动把 Figma 导出的 JSON 转换成 CSS 变量、Tailwind 主题配置或者小程序样式文件。这个过程看起来不复杂但实际做起来很麻烦命名风格要统一颜色要转成 hsl 或 oklch圆角要映射到正确的语义层级深色模式还要额外处理一套变量。如果直接让 AI 来做它可能第一次生成得不错第二次就换了一套命名规则第三次连缩进都变了。有了 Skill 之后你可以把“Design Token 转主题配置”这一整套经验写成一份技能包里面写明输入文件是什么样的、输出文件必须用哪套命名规范、转换脚本放在哪个路径、结果校验需要跑哪条命令。Agent 每次启动任务时会加载这份技能包输出稳定到像执行一次自动化流水线。设计界会关注 AI Skills核心原因就是它解决了 AI 生成结果“不稳定”的问题。设计师和前端配合时最怕的不是 AI 不会写代码而是 AI 每次给出的结果都不一样无法沉淀成团队资产。Skills 机制第一次把“人的经验”变成了“AI 的可执行模块”这东西对设计规范落地、UI 还原、前端联调这类任务来说价值是直接且明显的。2. Skills、Prompt、Agent 三者的边界要真正理解 Skills最好把几个高频概念放到一起对比。概念本质发挥作用的方式简单类比Prompt一次性指令每次对话时临时输入告诉 AI 本次要做什么给实习生的口头任务Agent自主执行体一个大模型驱动的“员工”能拆解任务、调用工具、逐步执行一个可以独立干活的实习生Skill技能包/工作手册给 Agent 提供的结构化知识库和可执行脚本让它稳定完成某类任务实习生手里拿到的“岗位 SOP 工具箱”从这个角度看Skills 并不是 Prompt 的替代品而是 Agent 的“能力底座”。没有 Skills 的 Agent像一个有悟性但没有经验的实习生。你给它一个模糊任务它能做但质量不稳定。你夸它一句“做得不错”它下次可能换个思路你批评一次它可能改得过头。有了 SkillsAgent 就相当于拿到了一份写清楚“干什么、怎么干、用什么工具干、干完怎么验证”的岗位手册表现会稳定很多。在技术实现上目前主流的 AI 编程工具包括 Claude Code、Codex、Cursor以及国内一些 AI 编程助手都在往这个方向走。不同工具的 Skills 目录结构和加载方式略有差异但核心思路一致在项目里放一个skills或.claude/skills目录里面每个子目录就是一个技能包包含说明文件、脚本和资源。Agent 在对话中识别到相关任务时会去读取这些技能包。这里要划一个重点Skills 不是魔法它不会让 AI 突然学会一个它本来就不会的能力。它的作用是“约束过程”和“注入经验”。AI 本身依然是那个大模型但 Skill 提供了更好的上下文、更明确的步骤、更可靠的校验方式所以最终结果的质量和稳定性会显著提升。3. AI Skills 对设计工作流的真实改变设计行业和软件工程的交界地带一直有很多“看似简单、实则重复”的工作。它们不需要特别高的创造力但需要严格遵守规范比如设计稿还原、Design Token 转换、切图命名、组件状态整理、视觉走查。这些工作恰恰是 AI Skills 最容易发挥价值的地方。3.1 设计稿转代码从“一次性生成”变成“反复可用”过去我们用 AI 做设计稿转代码是一个“一次性对话”的体验上传设计稿截图让 AI 生成 HTML/CSS然后复制到项目里微调。下一次再做类似页面又得重新描述一遍需求AI 又是从零开始发挥。Skill 改变的是这个流程。你可以把团队的前端代码规范、组件库用法、样式方案写进技能包。后续每次做页面还原Agent 会自动加载这份规范生成的代码从一开始就符合团队约定而不是生成完了再改。3.2 设计系统维护从“人工搬砖”变成“自动同步”设计系统最核心的资产是 Design Token。设计侧改了主色、间距、字体大小前端侧需要同步更新多处配置文件。用 Skill 后整个同步过程可以变成一个命令npx ai-token-sync ./design-tokens.json ./src/theme这条命令背后Agent 会读取技能包执行转换脚本自动生成或更新主题文件并根据规则校验颜色对比度、命名规范等。传统需要半小时的同步工作压缩到了几分钟而且过程可重复。3.3 视觉走查从“人眼比对”变成“规则校验”设计师最怕的是前端还原出来的页面颜色差一点、圆角差一点、间距差一点。用 AI 做视觉走查时如果只是简单地把设计稿和截图丢给 AI 看它给出的结论往往比较模糊。但如果写一个视觉走查 Skill把团队的误差容忍度、重点检查清单、常见问题库都写进去AI 就能产出格式统一的走查报告甚至能自动定位到具体元素和样式代码。这种变化的本质是把过去存在于资深设计师脑子里的“隐性经验”变成 AI 可以反复调用的“显性规则”。AI 没有取代设计师的判断力但它让判断力的传递和复用变得更便宜了。4. AI Skills 的标准结构与编写方法目前社区里主流的 Skill 结构基本可以概括为“一个目录 一个说明文件 若干脚本/资源”。下面是一个最常见的最小目录结构my-skill/ ├── SKILL.md ├── scripts/ │ └── convert_tokens.py ├── assets/ │ └── example-input.json └── README.md4.1 SKILL.md 是技能包的核心SKILL.md是整个技能包的大脑。它通常包含两部分内容开头的 YAML frontmatter 和正文。YAML frontmatter 里最重要字段是name和description。description尤其关键因为 Agent 会通过它来判断“当前用户的请求是否应该触发这个技能包”。如果 description 写得太宽泛Agent 可能会在无关任务时也加载它浪费上下文写得太狭窄Agent 又识别不出来Skill 形同虚设。正文部分需要写清楚的事情包括这个 Skill 适用于什么场景不适用于什么场景输入是什么输出是什么执行步骤是什么先后顺序如何需要调用哪些脚本脚本的输入参数如何传递输出结果如何校验什么样的结果算合格。听起来像写技术方案但实际上这就是把一次高质量人工任务的做事流程完整地“教”给了 AI。4.2 一个最小 SKILL.md 示例假设我们要写一个“Design Token 转 Tailwind 主题配置”的 SkillSKILL.md可以这样写--- name: design-token-to-tailwind description: 将设计团队的 Design Token JSON 文件转换为 Tailwind CSS 主题配置。当用户提供 design-tokens.json 或提到“同步设计变量”“生成 tailwind 主题”“转换 token”时使用。 --- # Design Token 转 Tailwind 主题配置 将输入的设计 Token JSON 转换为 Tailwind CSS 的 tailwind.config.js 中 theme.extend 可用的配置片段。 ## 使用场景 - 设计团队更新了 Design Token需要同步前端主题配置 - 需要从零为项目生成 Tailwind 主题基础变量 ## 不适用场景 - 不需要处理组件级样式代码 - 不负责图片资源压缩 ## 输入 - Design Token JSON 文件格式参考 assets/example-input.json ## 执行步骤 1. 读取 Design Token JSON。 2. 运行 python scripts/convert_tokens.py input.json output.js 转换文件。 3. 检查生成的 JS 文件是否符合输出规范。 ## 输出规范 - 颜色统一使用 hsl 格式。 - 命名采用 camelCase。 - 每个 token 注释中标注原始 token 名方便追溯。 ## 校验方式 运行 node -e require(./output.js)确保没有语法错误。4.3 脚本放在 scripts 目录Skill 的优势在于它可以调用真正的脚本来完成 AI 不擅长的工作。比如格式转换、批量文件处理、数据校验和计算这些任务用传统编程脚本做更可靠。AI 主要负责理解用户意图、拼接上下文、调用脚本最后整理输出结果。这其实是 AI Skills 一个很容易被忽视的设计思想不要让 AI 做它不擅长的事而是让 AI 把任务拆解给合适的工具。对于设计 Token 转换这种需要精确计算和稳定格式的任务脚本比大模型更可靠。5. 完整示例把 Design Tokens 转成 Tailwind 主题配置下面这个示例你可以直接复制到本地跑通。它能帮你直观理解 Skill 从编写到使用的全过程。5.1 准备项目目录先创建一个项目目录并建立以下结构mkdir -p design-token-skill/{scripts,assets} cd design-token-skill最终目录结构design-token-skill/ ├── SKILL.md ├── scripts/ │ └── convert_tokens.py └── assets/ └── example-input.json5.2 编写输入样例assets/example-input.json{ color: { primary: { default: #3B82F6, hover: #2563EB, disabled: #93C5FD }, neutral: { background: #F9FAFB, text: #111827, border: #E5E7EB } }, radius: { sm: 4px, md: 8px, lg: 12px }, spacing: { page: 24px, section: 16px, item: 8px } }这个样例模拟了设计团队导出的一份简化版 Design Token包含颜色、圆角、间距三类变量。5.3 编写转换脚本scripts/convert_tokens.py的作用是读取输入 JSON输出一份 Tailwind 配置片段。这里我们用 Python 标准库实现不依赖第三方包#!/usr/bin/env python3 # scripts/convert_tokens.py import json import sys from pathlib import Path def hex_to_hsl(hex_color: str) - str: 将 HEX 颜色转换为 hsl() 字符串。 hex_color hex_color.lstrip(#) if len(hex_color) ! 6: return hex_color r int(hex_color[0:2], 16) / 255 g int(hex_color[2:4], 16) / 255 b int(hex_color[4:6], 16) / 255 max_c max(r, g, b) min_c min(r, g, b) delta max_c - min_c if delta 0: h 0 elif max_c r: h 60 * (((g - b) / delta) % 6) elif max_c g: h 60 * (((b - r) / delta) 2) else: h 60 * (((r - g) / delta) 4) l (max_c min_c) / 2 if delta 0: s 0 else: s delta / (1 - abs(2 * l - 1)) return fhsl({round(h)}, {round(s * 100)}%, {round(l * 100)}%) def convert_token_group(group: dict, output: dict, prefix: str ) - None: 递归转换 token 分组生成扁平化且保留分组的输出结构。 for key, value in group.items(): current_key f{prefix}{key} if prefix else key if isinstance(value, dict): output[current_key] {} convert_token_group(value, output[current_key], prefix) elif key default: output[key] value else: output[prefix key] value def main(): if len(sys.argv) ! 3: print(用法: python scripts/convert_tokens.py input.json output.js) sys.exit(1) input_path Path(sys.argv[1]) output_path Path(sys.argv[2]) with input_path.open(r, encodingutf-8) as f: tokens json.load(f) theme {} if color in tokens: theme[colors] {} for color_group, color_values in tokens[color].items(): theme[colors][color_group] {} for shade, hex_value in color_values.items(): theme[colors][color_group][shade] hex_to_hsl(hex_value) if radius in tokens: theme[borderRadius] {} for size, radius_value in tokens[radius].items(): theme[borderRadius][size] radius_value if spacing in tokens: theme[spacing] {} for size, spacing_value in tokens[spacing].items(): theme[spacing][size] spacing_value js_content // 自动生成请勿手动编辑\n// 来源: design-tokens.json\n\n js_content module.exports json.dumps(theme, indent2, ensure_asciiFalse) ;\n output_path.write_text(js_content, encodingutf-8) print(f转换完成输出文件: {output_path}) if __name__ __main__: main()这段脚本的核心逻辑是把颜色值统一转成hsl()格式然后按colors、borderRadius、spacing三个分组生成 Tailwind 配置。设计团队改一次 token前端跑一次脚本就能重新生成主题配置避免了手动改 CSS 变量时容易出现的漏改和标注不一致。5.4 运行并验证在项目目录下执行python scripts/convert_tokens.py assets/example-input.json output.js预期生成的output.js大致如下// 自动生成请勿手动编辑 // 来源: design-tokens.json module.exports { colors: { primary: { default: hsl(217, 91%, 60%), hover: hsl(221, 83%, 53%), disabled: hsl(214, 95%, 78%) }, neutral: { background: hsl(0, 0%, 98%), text: hsl(220, 9%, 20%), border: hsl(220, 13%, 91%) } }, borderRadius: { sm: 4px, md: 8px, lg: 12px }, spacing: { page: 24px, section: 16px, item: 8px } };验证命令node -e const theme require(./output.js); console.log(theme.colors.primary.default);如果输出hsl(217, 91%, 60%)说明脚本和输出文件都是正常的。这一步也是 Skill 描述里“校验方式”可以复用的做法。6. 如何安装和使用 AI Skills写完一个 Skill 之后还需要让 AI Agent 能加载到它。这里以主流的 AI 编程工具为例介绍通用的安装和配置思路。不同工具的目录名会有差异但底层逻辑基本一致把 Skill 放到 Agent 会扫描的目录里或者在项目配置中声明 skills 目录。6.1 放置到 Agent 的 Skills 目录以 Claude Code 这类工具常见的项目结构为例你可以在项目根目录创建mkdir -p .claude/skills/design-token-to-tailwind然后将前面写好的SKILL.md、scripts、assets拷贝到这个目录下cp -r SKILL.md scripts assets .claude/skills/design-token-to-tailwind/此时目录结构为你的项目/ ├── .claude/ │ └── skills/ │ └── design-token-to-tailwind/ │ ├── SKILL.md │ ├── scripts/ │ │ └── convert_tokens.py │ └── assets/ │ └── example-input.json ├── design-tokens.json └── src/把design-tokens.json放到项目里后你只需要在对话中告诉 Agent“根据 design-tokens.json 生成 Tailwind 主题。”Agent 如果正确识别到这个请求就会自动加载design-token-to-tailwind这个技能包按SKILL.md里定义的步骤执行转换脚本并输出结果。6.2 在全局配置中声明 Skills如果你希望某个 Skill 对所有项目全局生效一般可以将它放到用户目录下的 Skills 目录中例如mkdir -p ~/.claude/skills/design-token-to-tailwind cp -r SKILL.md scripts assets ~/.claude/skills/design-token-to-tailwind/不同 AI 编程工具的全局目录名称不太一样有些使用~/.codex/skills有些使用~/.cursor/skills还有团队会习惯放在内部代码仓库统一维护。使用前先确认一下你所用工具的文档或者直接看社区里分享的安装方式。稳妥的做法是先在项目级目录里跑通再决定是否要全局安装这样可以减少误触发。6.3 通过命令行快速启用如果你的 Skill 本身带有命令行入口也可以直接在项目脚本里配置。比如在package.json中添加一个 npm script{ scripts: { tokens:sync: python .claude/skills/design-token-to-tailwind/scripts/convert_tokens.py design-tokens.json src/theme/generated.js } }这样团队成员不需要了解 Agent 交互直接执行npm run tokens:sync也能完成同样的转换任务。也就是说Skill 里的脚本不一定只能由 AI Agent 调用它本身也是一个可复用的工程化工具。这种“Agent 可调用人也可直接运行”的双重属性是 Skill 比普通 Prompt 更工程化的关键。7. 常见问题与排查思路在编写和使用 AI Skills 的过程中有些问题几乎每个人都会遇到。下面这张表汇总了最高频的几类问题和排查方向。问题现象可能原因排查方式解决方案Agent 识别不到 Skill始终按普通对话响应SKILL.md中description描述不到位检查描述中是否包含触发场景的关键词在对话中尝试用更明确的任务表述重写description覆盖常见任务描述避免使用过于宽泛的词汇Skill 被加载了但 Agent 不执行脚本脚本路径配置错误或 Agent 没有执行权限查看 Agent 日志确认工作目录尝试手动运行脚本在SKILL.md中写清脚本路径用绝对路径或相对项目根的路径脚本运行报错提示找不到文件输入文件路径与脚本预期不一致检查当前工作目录确认输入 JSON 是否存在在SKILL.md中明确输入文件位置脚本内增加路径参数校验输出结果不是预期的格式脚本逻辑与SKILL.md中的输出规范不一致检查脚本转换逻辑用样例文件逐步调试先用assets/example-input.json跑通脚本再处理真实输入同一个 Skill 在不同项目里表现不同技能包没有固定版本或依赖了项目内路径检查项目内是否覆盖了全局 Skill确认脚本是否有硬编码路径使用目录相对路径Skill 纳入独立 git 仓库通过 tag 做版本管理Agent 执行了 Skill但结果不稳定SKILL.md描述不够具体AI 有机会自行发挥复盘执行记录看 AI 是在哪一步偏离了规范细分执行步骤对关键输出增加自动校验命令最需要提醒的是Skill 的核心价值在“规范”两个字。如果你的SKILL.md写得很模糊那么 AI 的表现自然也会模糊。写 Skill 跟写需求文档一样细节越清晰结果越可控。8. 最佳实践与工程建议当你准备把 AI Skills 用到实际项目或团队协作中时下面这些建议值得提前考虑。8.1 Skill 描述要写在“触发条件”description不是简单介绍这个功能而是写给 Agent 的“触发识别器”。建议用这样的句式当用户【提供什么输入】或【表达什么意图】时使用本技能。不要用“这是一个转换工具”这种泛泛的话术而要用“设计 Token 转 Tailwind”“同步设计变量”“生成主题配置”这类任务导向的描述。8.2 脚本保持幂等和简洁Skill 里的脚本应该做到重复执行多次结果一致不依赖执行者的个人环境不产生意外的副作用。输出文件最好标注“自动生成请勿手动编辑”必要的时候可以生成临时文件预览确认无误后再覆盖正式文件。8.3 考虑安全边界让 Agent 自动执行脚本相当于赋予了它调用本机命令的能力。因此 Skill 脚本里要遵守最小权限原则只在明确指定的目录内读写文件不主动删除文件不读取环境变量以外的敏感信息。如果你希望 Skill 支持自动化写回文件建议先输出到目标目录的临时文件经人确认后再替换。任何涉及数据删除、覆盖或认证信息的操作都要经过合法授权并在测试环境验证后再用于生产。这一点在团队协作时尤其重要否则一个写得不严谨的 Skill 可能会误改团队公共配置。8.4 把 Skill 当作代码来管理Skill 有目录、有文件、有脚本、有版本本质上就是一个代码工程。团队内部使用多个 Skill 时建议单独建一个仓库维护使用语义化版本号。Skill 的更新要走代码评审而不是改完就广播。设计团队的 Style Guide 更新后Skill 里的转换规则和示例样例也要同步更新否则会出现“设计规范已经变了但 AI 还在沿用旧规则”的情况。8.5 先跑通最小示例再扩展复杂度如果你是第一次接触 AI Skills不建议一上来就写一个庞大的技能包。先复制本文第 5 节的示例在你的 Agent 工具里跑通一次确认加载机制、脚本调用路径都正常再逐步加入校验命令、多场景分支、参考样例。这个顺序能帮你快速建立对 Skill 工作方式的直觉也更容易定位问题。9. 下一步可以做些什么如果你已经理解了 AI Skills 的机制下一步最值得做的事情是从你自己最讨厌的那类重复工作里抽一个出来写成 Skill。设计师可以从“导图规范命名”开始前端可以从“接口数据转 TypeScript 类型”开始测试同学可以从“按缺陷模板生成 Bug 报告”开始。一个 Skill 不需要覆盖很大的场景只需要把一个小任务做到稳定、可复用它的价值就已经超过了大部分泛泛而谈的 AI 使用技巧。Skill 的本质不是魔法而是把过去散落在人脑里的经验压缩成一个 Agent 可以稳定执行的工作包。设计界的下一步也许不是让 AI 取代设计师而是让每一位设计师都能把自己的判断写成 Skill。当这些技能包慢慢沉淀下来设计系统维护、设计稿还原、前端联调这些琐碎工作才会真正变轻。