AI skills 最近成了设计圈和前端圈绕不开的关键词。我在把一个“设计稿转页面结构”的流程做成可复用 skill 之前一直觉得它只是“把提示词存成文件”没什么值得深究。后来真正跑完一条完整链路才发现这个看起来很小的抽象其实把 AI 的用法从“一次问答”推进到了“能力封装”。对每天要处理设计稿、组件库、响应式适配的人来说这带来的变化不是省几分钟而是把很多不确定的重复劳动变成了一套可以长期维护的标准动作。这篇文章我从自己在 AI 编程场景里使用 skills 的经验出发说说它到底改变了什么、怎么从零写一个 skill、落地时最容易在哪几个环节出问题以及最后怎么判断它适不适合你。1. 先搞清楚 AI skills 真正解决的是哪一类重复劳动1.1 它不是“多存了几段提示词”而是把工作流固化了很多人初次看到 skills 概念会把它和提示词模板画等号。传统的提示词模板只负责把一段指令保存下来重新粘贴给 AI 时AI 仍然不知道整个任务有哪些约束、需要什么输入、输出放在哪里、失败时怎么处理。而一个可供 AI 代理加载的 skill通常会把“技能说明、使用步骤、输入输出约定、示例、可选脚本”放在一起。在常见实现里一个 skill 是放在特定目录下的一个文件夹里面有一个SKILL.md或类似的描述文件再加上一些辅助文件。AI 通过读取这个描述文件知道“什么时候该调用这个技能、执行时需要读哪些文件、生成结果后应该放到哪个目录”。这有点像团队里的“操作手册”不是告诉新人要做什么而是让新人遇到对应问题时能按手册里的约定去执行。所以AI skills 真正解决的不是“让 AI 更聪明”而是“让 AI 的聪明可以被复用、被共享、被约束”。如果你只是想让 AI 聊天聊得更好用不用 skill 差别不大。但如果你希望 AI 能稳定地完成某个固定流程skill 就会比一次性聊天可靠得多。1.2 为什么设计、前端场景最先感到“被震撼”设计相关的工作流有几个特点重复度高、规则明确、但每次处理的具体素材又不一样。比如拿到一张设计稿需要生成对应的页面结构拿到一组图标需要统一导出并转换成组件代码拿到一个设计规范需要检查现有页面是否匹配。这类工作过去要么靠人肉复制粘贴要么靠抽时间写一次性脚本。AI 编程工具出现后大家发现可以用自然语言指挥 AI 完成一部分但每次都要重新描述需求、重复说明输出格式而且结果不稳定。skills 出现后变化在于你可以把一整套约定固化下来AI 下次遇到“页面结构生成”这类任务时直接按之前验证过的方式执行。设计界关注 skills并不奇怪。设计工具导出的素材本身就是比较规整的输入AI 适合处理“输入规整、输出要求明确”的任务。很多前端开发 skills 正是围绕这类场景出现的。从工程经验看真正让设计师和前端合作效率提升的不是 AI 生成了多惊艳的页面而是“从设计稿到前端结构”这条链路由不可控变成了基本可控。这里的“震撼”不是字面意义上的炫技而是工作方式的变化。2. 从零开始写一个可用的 skill结构、目录和内容2.1 最小 skill 包含什么不管用的是 Claude Code、Codex、OpenCode 还是 Cursor这类工具对 skill 的目录约定在不同版本里会有差异。我在落地时通常会先建一个最小结构验证工具支持后再继续扩展。一个比较常见的结构是skills/ design-to-page/ SKILL.md examples/ input.png output.tsx scripts/ check_input_size.pySKILL.md是技能的“说明书”里面写清楚什么时候使用、输入是什么、输出要求是什么、执行步骤是什么。examples存放一个输入输出样例可以让 AI 更快理解目标格式。scripts用来做输入校验、结果校验、文件清理等辅助动作不是必须的但对稳定运行很有帮助。需要注意不同工具的加载规则并不完全一致。有的工具要求放在项目根目录的.claude/skills下有的工具提供独立命令安装有的工具还支持从远程仓库直接安装社区技能包。因为你无法确定所有平台都遵循同一套约定所以落地前的第一件事是打开对应工具的文档确认当前版本的目录规则。2.2 在不同工具里组织 skill 的常见方式从社区现状看skills 的组织方式大致可以分成三类。第一类是“项目内嵌型”。把 skill 放在当前项目目录下只对这个项目生效。这种方式适合团队内部约定流程比如某个项目里统一使用一套“设计稿转组件”的规则。第二类是“全局配置型”。把 skill 放在用户级目录里所有项目都能使用。这种方式适合个人沉淀通用能力比如“把图片转成可访问的 HTML 结构”这类与具体项目无关的技能。第三类是“仓库共享型”。把一堆 skill 放到 Git 仓库里然后通过命令或安装脚本拉取到本地。社区里已经有一些开发者整理的 skill 集合通常会按用途分类比如前端开发、测试、文档生成、数据分析。这类集合的好处是开箱即用坏处是质量参差不齐而且很多集合更新并不及时拿回来后往往要根据自己的工具版本做调整。所以你在搜索“find skills”“skills 推荐”这类话题时真正要判断的不是“哪个包火”而是“这个包里的每个 skill 是不是符合我的输入输出习惯”。一个安装量很高的 skill如果它的目录约定和你当前工具版本不一致落地时反而会浪费更多时间。2.3 写 SKILL.md 时要避免的两种极端实际使用中我发现很多开发者在写 skill 说明时会走向两个极端。一种是只写一句话比如“帮我把图片转成页面结构”这会导致 AI 执行时既不知道要读哪张图也不知道输出该放哪里。另一种是写成长篇论文把背景理论、设计原则、团队历史都写进去AI 反而会抓不住重点。一个合理的SKILL.md至少应该包含四个部分作用这个 skill 在什么场景下用。输入需要哪些文件、格式是什么、由谁提供。输出结果文件放在哪里命名规则是什么使用什么格式。执行步骤按顺序列出 3 到 6 个关键动作最好包含“不要做什么”。这样写的好处是AI 代理在读取说明后不需要猜测意图。它只需要按照描述去检查输入、执行步骤、生成输出。类似的写法其实也适用于 codex skills、opencode skills 等不同实现核心逻辑都是“把可重复流程描述清楚再交给代理执行”。3. 关键不是“能不能跑通”而是“能不能长期稳定使用”3.1 输入边界设计素材的格式、大小、路径都要检查一个常见的误判是单次跑通了一次“把 PDF 设计稿转成页面结构”就认为 skill 已经可用了。但下次换一张更大的图片、换成 PNG 或者多层 Figma 导出文件时模型可能突然不读了。对于设计素材我会建议在 skill 里写清楚支持的输入格式png、jpg、svg、pdf还是需要先从 Figma 导出。是否检查分辨率、尺寸、色彩模式。文件是放在固定输入目录还是由用户手工指定路径。对超大文件是否需要先压缩或切片。你可以在 skill 中加入一个输入校验脚本在 AI 处理前先检查文件是否存在、格式是否正确、大小是否超过阈值。这样至少可以让失败提前暴露出原因而不是让模型读一个异常文件后输出一堆无意义内容。3.2 输出边界让 AI 的结果能被下一个环节使用如果 skill 只面向聊天输出格式不稳定还可以手动调整。但如果你希望把它纳入一条更完整的工作流输出就必须保持一致。举例来说生成页面结构时需要约定好输出目录是output/还是generated/。文件用.tsx、.jsx还是.vue。是否需要附带一个说明文件记录本次生成所用的模型和参数。失败时是否生成error.log。从实际工程经验看很多批量任务不是 AI 本身能力不够而是“前面成功、后面失败且没有日志”导致整个任务不可恢复。给 skill 增加输出规范和校验脚本往往比换更大的模型更有效。3.3 平台间兼容性一份 skill 不一定处处可用在写 skills 时要区分三类内容通用描述说明用途、输入输出、执行步骤大多数工具都能读取。工具特定指令比如某个工具暴露出的特殊能力、系统调用、内置快捷键。脚本依赖如果 skill 依赖了 Python 包、Node 包或外部命令那换一台机器就可能失效。内容类型示例迁移是否方便通用描述输入图片输出页面结构大多数工具可以复用工具特定指令调用某种内置的图像分析接口需要按工具改造脚本依赖调用某个图像处理库需要重新安装依赖所以如果团队要在不同工具之间切换最好的做法是把 skill 拆成“说明文件 脚本”脚本尽量用常见标准库减少对单一平台的强依赖。这就是为什么说“一份 skill 写好后别默认在哪里都能直接用”。4. 设计场景落地从一个最小痛点开始不要一上来做全家桶4.1 第一步找到“每周至少重复三次”的任务不要一开始就决定把整个设计交付流程封装成一个巨型 skill。更稳妥的方式是找到一个你每周至少会重复三次的任务把它做成最小的 skill。下面这几个都值得先试设计稿转页面结构。一组图标导出并生成组件代码。根据设计规范检查页面样式是否一致。批量把 PDF 里的文案提取成结构化表格。这些任务都满足输入规整、输出明确、重复发生。如果一个任务你自己都不确定下一周还会不会遇到那就没有必要急着封装。4.2 第二步先用普通对话把流程跑通再固化成 skill很多人的直觉是先写好 skill 文件再指望 AI 按说明执行。我的建议相反先不要考虑 skill直接用对话方式把这条流程跑通观察哪些步骤最稳定、哪些地方 AI 总会重复问你。建议流程用 AI 对话完成一次完整任务手动纠正结果。把这次对话里最有效的指令整理成文字。把输入输出约定和步骤写进 SKILL.md。用一条新的输入测试 skill看 AI 是否不再需要额外解释。如果某一步不稳定再决定是否加入脚本校验。这个过程看起来慢其实是最省时间的。因为你把“一次成功对话”变成了一个可复用的“最小技能”后续每次使用都在复用你已经验证过的判断。4.3 第三步批量前先补上日志、计数器和失败记录当单个 skill 跑通之后你很容易产生批量使用的冲动。这时候最值得做的不是拉高并行数而是给 skill 增加“人类可阅读的日志”。至少需要记录每次执行开始时间和结束时间。输入文件名称。输出文件路径。生成结果是否通过基本校验。失败原因。这样即使批量任务中途失败你也能从日志里定位是哪一批文件出了问题。没有这个基础批量只会放大混乱。注意不要一上来就把并发数、批量数拉满。先用一条样例把输入、输出和日志确认正常再逐步扩大。5. 遇到问题别先怀疑 AI一个可复用的排查链路5.1 按现象、输入、环境、参数、边界逐层排查当 skill 没有按预期工作时建议按照下面的顺序排查而不是直接换一个模型或重写 prompt看现象是报错、卡住、无输出还是输出内容不对把现场信息留下来。看输入文件是否存在、格式是否匹配、路径是否带中文或空格、图片是否损坏。看环境skills 目录是否有读写权限、依赖脚本版本、工具版本是否支持该类 skill。看参数批量数、并发数、超时时间、输出路径、模型名称是否设置正确。看工具边界当前工具是否支持该 skill 类型、是否存在已知限制。设计场景里最常见的问题是输入和环境层。比如 Figma 导出的私有格式不一定能被模型读取需要先导出成 PNG/SVG再比如中文字体文件名在部分脚本里会出现编码问题。这些问题和模型聪明程度无关属于输入和环境的边界。5.2 四个值得重点检查的坑文件格式不匹配模型以为自己读的是 PNG实际是损坏文件或未解压的 PDF。输出目录不存在脚本没有自动创建目录导致结果写不进去。缺少示例AI 对“页面结构大概长什么样”没有概念输出格式漂移。没有失败重试批量任务中某一项失败后整个任务停止且没有记录。如果你把检查结果写进 skill 的日志排查会变成一件很快速的事。“它坏了”到“为什么坏”不再需要靠猜。5.3 长期维护视角skill 也要版本管理如果只是自己临时用把 skill 放在本地目录就够了。如果团队内共享建议把 skill 放进 Git 仓库并在 SKILL.md 里写清楚适用版本和依赖环境。每次修改 prompt 后先用一条固定输入做回归验证避免“以前能用的技能因为某句话改动而失效”。到了这一步从“写一个 skill”到“长期维护 skill”才形成了一个完整闭环。否则它只是一堆一次性文件时间一长就没人记得当初为什么这么写。6. 什么人在什么阶段适合用 AI skills6.1 现在真正适合的人结合真实落地场景我认为以下三类人会很快获益已经熟悉 AI 编程工具并且有固定重复工作流的人。负责设计规范和前端组件库维护的人需要让 AI 按统一标准产出。在做 AI 应用或 Agent 开发的人需要把某些能力封装成可复用单元。这类用户的共同特点不是“会用提示词”而是“有流程意识”。他们能清楚描述一个任务从输入到输出的完整路径也知道哪些环节容易出现异常。6.2 暂时不必急着上 skills 的人还没用 AI 跑通过任何一条完整任务的人。只想让 AI 聊天、写点摘要没有稳定重复任务的人。团队没有统一习惯也不打算维护文档和目录结构的人。skills 的收益来自复用。如果你没有固定流程封装 skill 反而会增加维护负担。先老老实实把普通对话用熟再考虑技能化。6.3 我的建议从一个小技能开始但今天就可以开始我不太建议把“设计界震撼”理解成 AI 已经能替代设计师。它真正的信号是设计、开发里那些既定规则明确、重复次数高的工作正在变成可以封装、可复用、可复制的最小技能单元。如果你有一个每周都要做的设计或前端任务今天就可以试着用一次对话跑通再把它固化成一个 skill。先别管复杂结构先把最小闭环跑出来。等到你再回头看时会发现真正有价值的不只是某一次生成结果而是那条被固化成 skill 的流程。它会继续稳定地替你处理相似任务并且可以被同事、团队甚至未来的项目复用。这大概才是 AI skills 最值得长期关注的原因。