AI skills 这个概念最近在 AI 编程和前端开发圈子里讨论得很多。但“让设计界震撼”这个说法我觉得要拆开看真正让设计相关从业者觉得有价值的部分不是 AI 突然会画画了而是它能把一套专业工作流固化成可复用的技能包。设计师给出方向、约束和判断AI 负责执行重复度高的中间步骤这才是 skills 最值得关注的地方。这篇文章不聊大而全的概念只讲清楚三件事AI skills 到底是什么它和普通提示词有什么区别在本地环境里怎么安装和验证一个现成 skills更重要的是怎么为一个设计或前端场景写一个自己的 skills并且让它稳定工作。如果你用过 Claude Code、Codex 或 OpenCode 这类 AI 编程工具想进一步控制 AI 的输出结果不想每次都把长篇背景和规则重新粘贴一遍这篇文章适合你。如果你是设计师主要用 Figma、即时设计或直接写 HTML/CSS想用 AI 做设计规范检查、配色建议或组件代码生成同样可以参考这里的思路。1. AI skills 到底改变了什么从“记住上一步”到“固化专业流程”先解决一个基础问题skills 到底是什么为什么这段时间突然被频繁提到。1.1 普通提示词和 skills 的本质差异过去我们和 AI 协作最常见的方式是在对话框里写一段提示词。比如“你是一位资深 UI 设计师请帮我检查这个页面的配色是否满足 WCAG AA 对比度要求”然后 AI 根据这段描述给出一个回答。问题是下次换一个页面你又得写一遍而且 AI 的表现会随着上下文长度、模型版本、对话顺序产生波动。skills 的思路不一样。它把一段专业任务拆成固定的输入格式、处理步骤和输出要求然后打包成一个独立文件或目录。AI 工具在遇到对应任务时会自动加载这个技能包按照里面定义的规则执行不需要你每次重新交代背景。用设计场景举例没有 skills每次都要描述“你是设计系统专家请检查卡片阴影层级是否合理背景色是…#fff边框色是…”。有 skills只要告诉 AI“帮我跑一次设计规范检查”它会自动读取规范文件、对比设计稿参数、输出不符合项列表和修改建议。核心差异不是 AI 变聪明了而是你把专业判断和操作流程沉淀下来了。这就像设计团队把个人审美变成设计规范文档AI skills 做的就是把规范文档变成可执行脚本。1.2 为什么设计、前端、测试这类场景最适合先落地观察目前社区里的 skills 讨论最容易见效的不是泛泛的文案写作而是那些有明确输入输出、有固定判断规则、有可重复检核项的任务。设计相关任务刚好符合设计稿有明确属性颜色值、字号、间距、圆角、阴影都是可以量化的参数。设计规范有明确标准比如对比度、栅格倍数、断点范围、组件状态。输出检查有明确目标要么是通过要么是不符合并给出原因。这些特征决定了 AI skills 在设计相关场景不是花架子。它适合用来做设计走查、色彩可访问性检查、前端代码风格统一、组件命名规范校验等工作。注意skills 目前更多是增强 AI 工具的任务执行能力而不是替代设计判断。真正决定结果上限的仍然是你定义的规则和流程质量。2. 不同工具对 skills 的支持差异很大先确认运行环境再动手AI skills 不是一个统一标准不同工具的实现方式、配置路径、触发机制都不一样。想把这个能力用起来第一步不是写 skills而是确认自己用的工具支持到什么程度。2.1 常见 AI 编程工具对 skills 的支持情况从目前能接触到的信息来看主流的本地 AI 编程工具大多开始支持 skills但成熟度有差异工具Skills 配置位置触发方式适用人群Claude Code.claude/skills/目录对话中 AI 根据任务自动调用前端、设计系统、文档生成场景Codex~/.codex/skills/或项目目录配置后由模型选择加载偏编程任务、命令行操作OpenCode配置目录下的 skills 文件夹AI 根据描述自动匹配本地编码和文件处理通用版 Skills 功能云端或桌面端配置手动选择或自动触发不写代码的人也能用表格里的路径在不同版本中可能变化。我建议动手前先看一眼自己工具的帮助文档或者直接查看配置目录下有没有skills文件夹。没有就先手动建一个不影响后续使用。2.2 本地运行需要什么条件如果你打算在本地环境安装和使用 AI skills不需要特别高的硬件配置但有几个前置条件要满足已经安装并能正常运行的 AI 编程工具比如 Claude Code、Codex 或 OpenCode。一个可用的模型访问通道可以是工具自带的模型接口也可以是本地部署的模型服务。能访问命令行因为大部分 skills 都是通过命令行工具加载的。如果涉及设计稿解析、截图检查或大文件处理要保证内存和磁盘空间够用。很多人看到“AI skills 推荐”就以为要配一台高显存机器这个理解有偏差。skills 本质是一个规则包真正消耗资源的是背后运行的模型。如果你用的是云端模型本地只需要负责读文件、拼题目、解析输出压力不大。踩坑提醒安装 skills 后如果发现不生效先不要怀疑模型能力先看配置目录是否被工具正确识别。很多问题出在目录拼写、文件命名和 frontmatter 格式上而不是 AI 本身。3. 安装一个现成 skills先用最小样例验证完整链路如果你从来没装过 skills不建议上来就自己写也不建议一次性装十几个热门仓库。更稳的做法是先装一个跑通单条任务确认输入、输出、日志都正常再去扩充。3.1 找一个可信的 skills 来源现在社区里可以找到不少现成 skills比如一些前端开发 skills、测试辅助 skills、学术写作 skills。搜索时可以用“skills 列表”“awesome skills”“SKILL.md 示例”这类关键词找到的仓库一般会附带 README 和安装说明。选择时留意几点仓库是否有明确的目录结构和 README。是否有作者维护和更新记录。是否包含SKILL.md主文件和必要的示例素材。是否说明了适配的 AI 工具版本。不要看到仓库 star 多就盲目安装。有些项目只写了理念没有提供真正可运行的技能包有些项目则是为特定工具写的换一个工具就不兼容。3.2 安装步骤和验证方法以本地目录型 skills 为例安装流程一般是这样# 进入你的项目目录或者全局配置目录 cd your-project # 创建 skills 目录如果不存在 mkdir -p .claude/skills # 把下载的 skills 复制到对应目录 cp -r ~/Downloads/my-skill .claude/skills/安装完成后先不要直接进入复杂任务。打开 AI 工具用一条最小问题测试请使用 my-skill 技能检查当前目录下 design-tokens.json 文件中的颜色变量是否符合对比度要求。判断是否成功看三个信号工具是否主动加载了 skills 描述而不是把你说的内容当普通对话。输出是否按照SKILL.md中规定的格式返回而不是自由发挥。日志或提示中是否出现 skills 的名称或版本标识。如果三条都满足说明安装链路没问题。如果工具完全忽略了这个技能先检查目录路径和SKILL.md的 frontmatter 字段是否完整。3.3 单条任务跑通后再考虑批量一个常见误区是skills 一装好就希望它能批量处理几十个文件。结果发现第一个文件就卡住了然后开始怀疑是 skills 写得不行。其实应该先跑单个文件、单个输入确认链路完整后再做批量。批量任务不是临时把文件列表丢给 AI 就行它涉及输入文件命名是否规范。每个文件的格式是否一致。输出结果怎么命名避免互相覆盖。某个文件失败时程序是否继续处理下一个。日志里能否区分是哪个文件生成的哪个结果。这些内容属于工程化问题和 skills 本身无关。但如果你不做规划批量任务一定会在中间某个文件上失败。4. 手写一个自己的 skills设计场景的完整示例安装现成 skills 只能帮你建立体感。真正让 skills 产生长期价值是学会自己写。下面用一个设计走查场景举例说明如何从零开始写一个可用的 skills。4.1 先定义任务边界和输入输出假设我要做一个“设计规范检查技能”它的定位是帮前端开发者和 UI 设计师检查项目里的样式代码是否遵循设计规范。先明确输入项目中的 CSS/SCSS 文件。或者一个 design tokens 数据文件。或者一组用 Tailwind 类名编写的组件代码。再明确输出不符合规范的项清单。每一项涉及的文件路径、行号、现状值、期望值。修改建议和示例代码。为什么要先定义输入输出因为 skills 本身不是一个完整的程序它是给 AI 看的行为说明书。如果你不把输入输出写清楚AI 在执行时就会猜测结果每次都不一样。4.2 创建 skills 目录和文件一个最小的 skills 通常包含两类内容SKILL.md主文件描述技能的名称、适用场景、执行步骤、输出格式。示例文件一个或多个样例输入方便 AI 理解任务格式。目录结构可以这样设计design-review-skill/ ├── SKILL.md └── examples/ ├── input.scss └── expected-output.mdSKILL.md的内容要分成几个区块。下面是一个简化示例实际使用时可以根据自己的规范补充--- name: design-review description: 检查设计稿、样式代码或设计变量是否符合指定设计规范适用于 UI 走查、前端代码审查、设计系统一致性检查。 --- # 设计规范检查技能 ## 适用场景 - 检查颜色变量是否满足 WCAG AA 对比度要求。 - 检查间距值是否使用设计规范中的间距倍数。 - 检查字体字号和行高是否符合排版规范。 - 检查组件是否存在重复定义或命名冲突。 ## 输入 - 目标文件路径或文件内容。 - 可选设计规范文件路径。 ## 执行步骤 1. 读取目标文件识别其中的样式规则。 2. 提取颜色、间距、字号、圆角、阴影等设计属性。 3. 将提取结果与设计规范逐项对比。 4. 输出不符合规范的项目列表。 5. 对每项给出修改建议。 ## 输出格式 - 检查结果通过 / 不通过。 - 问题列表文件路径、行号、当前位置、期望值。 - 修改建议代码片段或推荐参数。 ## 注意事项 - 如果规范文件中没有定义某个属性不视为问题。 - 遇到提取失败的格式在日志中记录并跳过。 - 不要在没有依据的情况下修改代码只输出建议。这个文件的核心作用不是教 AI“什么是设计规范”而是告诉 AI“拿到任务后怎么一步步执行、按什么格式输出”。AI 本身已经知道什么是颜色、什么是间距它缺的是你的流程约定。4.3 用最简单场景测试写好之后不要直接让它扫整个项目。先给它一个很小的文件// input.scss $primary: #007bff; $text-color: #666666; $spacing-md: 8px; $spacing-lg: 18px;然后发起测试请求请用 design-review 技能检查 examples/input.scss使用的设计规范为正文字号不小于 12px主色对比度需达到 AA 级间距必须使用 4px 的倍数。重点看 AI 是否能按SKILL.md里规定的格式输出。如果 AI 没有执行步骤而是直接给出了一段自由格式回答那说明 frontmatter 里的description与本次请求的匹配度不够或者工具没有正确加载技能。这个排查方式同样适用于其他场景写一个技能后先准备一个可控输入跑一次看输出再迭代描述。5. 把 skills 放进真实设计工作流从单任务到批量处理会写一个简单的 skills 之后下一步是考虑怎么把它真正用起来。这一步才是很多教程没有展开的地方单任务上去了批量怎么处理多人协作怎么维护遇到不同输入格式怎么办。5.1 设计走查场景的落地流程我接触过的常见落地方式是这样第一步把团队设计规范中的关键参数整理成独立文件比如design-tokens.json或design-tokens.yaml。不要把它们散落在各处让 skills 通过固定路径读取。第二步让 skills 同时接受“代码文件输入”和“规范文件输入”两个参数。这样它既检查了代码又读取了规范而不是临时把规范粘贴到对话里。第三步设计走查时不是直接把整个项目丢进去而是先让 AI 扫描项目结构输出样式文件清单再逐个文件执行检查。第四步把 AI 输出的问题清单导入 Issue 系统或飞书文档分配给人处理。这个流程下来一次走查的重复劳动会大幅减少。但要注意AI 输出永远需要人工确认。凡是涉及颜色对比度、组件状态、无障碍需求的判断以实际效果为准不要只看 AI 给的结论。5.2 没有代码文件时怎么用 skills 处理设计稿有些读者可能不写代码主要使用设计工具。这种场景下skills 也能用但要换一种输入形式。目前可行的做法把设计稿导出为 HTML 或 CSS 文件再用 skills 做检查。把设计稿导出为 JSON 格式的设计变量比如 Figma Tokens 插件导出的文件。用设计稿截图作为输入让 AI 基于视觉信息执行检查配合视觉模型。第一种做法最稳定因为它有结构化数据AI 容易解析。第二种做法适合有设计令牌管理流程的团队。第三种做法依赖视觉模型能力质量波动会大一些适合做初筛不适合做严谨规范验收。经验导入 JSON 设计变量比直接传截图可靠得多。如果你已经把设计规范数字化了优先选择 JSON 或 YAML 输入。5.3 多人协作时 skills 怎么维护skills 很容易出现一个现象写的时候很认真用了一周之后发现没人维护规范更新了它不更新最后被废弃。要避免这个问题从一开始就把 skills 当代码管理skills 目录纳入 Git 仓库变更走分支和提交记录。SKILL.md和规范文件分开维护。规范文件每周可能更新技能主文件尽量保持稳定。遇到规范变化时只更新规范数据文件不频繁改技能逻辑。每个技能配套一个示例文件方便新成员快速理解它的输入输出。多人协作时还容易遇到一个问题不同人复制了不同版本的 skills。建议团队内统一使用同一个仓库路径通过 Git 拉取不要用网盘或聊天工具传文件。6. skills 不生效或结果不稳定时按这个顺序排查任何工具用一段时间都会遇到问题。skills 最常见的异常包括不触发、输出格式不符合预期、中途报错、每个任务结果差异大。下面给出一个实际排查顺序按优先级从高到低执行。6.1 先看日志和路径再怀疑 AI 能力遇到 skills 没有生效我的第一反应不是模型不行而是先确认它到底有没有被读取。按下面顺序检查工具是否输出了错误日志比如“skill not found”“cannot read SKILL.md”。配置目录是否正确。~/.claude/skills/、.claude/skills/、~/.codex/skills/不要搞混。文件是不是叫SKILL.md注意大小写和扩展名。frontmatter 里的name和description是否存在格式是否为 YAML。工具版本是否支持 skills。有些老版本工具根本没有这个能力。如果这些问题都不存在再考虑是不是描述写得不够清晰导致 AI 没有自动匹配到这个技能。6.2 输出不稳定时检查输入和规则定义skills 的表现如果时好时坏最常见的原因是输入格式没有统一。比如同一个技能既能读 CSS又能读 JSON输出自然不稳定。解决办法是明确限定输入类型或者把不同格式拆成不同技能。第二个常见原因是规则定义里存在模糊表达。比如“检查颜色对比度是否达标”AI 可能不知道你要按哪个标准是 WCAG AA 还是 AAA是普通文本还是大文本。这些必须在SKILL.md里写死或者通过参数传入。第三个原因是输出格式约束不够。如果要求 AI 必须按表格输出就要在技能里写出表格模板而不是只说“整理成表格”。6.3 资源占用过高或批量任务失败时先降并发如果你在本地跑大模型并且用 skills 批量处理文件遇到卡顿或 OOM优先检查并发数。我一般会先设置单线程任务确认无异常后再增加并发而不是一次性把代码文件全部丢进去。批量处理时还要考虑输出目录是否存在。很多 skills 报错不是模型问题而是系统权限或路径没有提前建好。比如输出目录./output/reports不存在AI 无法自己创建目录任务就会失败。7. 别把 skills 当银弹边界、局限和更合适的替代方案最后聊聊边界。skills 确实能让 AI 在某些场景下更可控但它不是万能的。对这个能力期待值过高反而容易忽略更合适的方案。7.1 skills 适合做什么不适合做什么从实际使用反馈来看skills 适合以下任务步骤明确、输出格式固定的任务。需要反复执行的标准作业流程。规则可以通过文本清晰表达的场景。可以被模型上下文容纳的中小型文件处理。不适合的任务包括高度依赖主观审美判断的任务。比如“这张海报看起来是否高级”这类判断没有明确规则skills 无法固化。依赖大型数据集的搜索和分析任务。skills 本身不是数据库它只是给模型提供操作指导。需要大量长对话上下文的任务。如果任务涉及多个历史追问skills 的外部规则可能冲淡对话连续性。需要调用复杂外部 GUI 的任务。skills 可以调用命令行程序但很难稳定操作设计软件界面。7.2 什么时候用提示词什么时候用脚本什么时候用 skills很多人会把三件事混在一起。实际选择可以按复杂度判断方案适合场景优点缺点提示词单次对话、临时任务简单直接不用建文件每次都要重写结果不稳定Skills固定流程、反复执行可复用规则集中容易维护需要花时间设计规则和维护示例脚本/命令行与文件系统、外部程序紧密结合完全可控可并行可集成 CI需要写代码天然和 AI 解耦如果你的任务只需要处理一次直接用提示词。如果每周都要做一次适合用 skills。如果任务要处理大量文件且格式极端稳定写一个 Python 脚本可能比 skills 更可靠。7.3 我建议的落地路径如果你现在正准备入局 AI skills我的建议是分四步走。第一步只安装一个现成的高质量 skills跑通一次完整链路培养判断标准。 第二步写一个自己能控制的最小技能哪怕只是帮你把两个 CSS 文件里的颜色值提取出来对比。 第三步把自己最常做的事写进 skills每两周用一次根据实际输出调整规则。 第四步当遇到“想重复但总记不住完整规则”的任务再继续扩容技能包。如果只是学习不建议一开始就追求装几十个技能。真正用起来之后你会发现常用的就那么三五个。与其堆数量不如把最重要的几个维护到能用、好用、大家愿意用。AI skills 这个方向还在快速变化不同工具的实现方式也在演进。今天写的东西可能过几个月配置路径就变了。但只要把握住一条原则——把专业流程沉淀成可复用规则用结构化输入输出约束 AI 的行为——换任何工具你都能很快上手。