最近AI编程圈子里“skills”这个词算是彻底火了。很多人第一反应是这不就是给AI写个Prompt模板吗或者干脆把它理解成一种新的插件。我最初也是这么想的直到自己动手开发了几个、踩了一堆坑之后才意识到Skills解决的根本不是“多存几个提示词”的问题而是把AI从一个“你每次都得重新教一遍的实习生”变成“你交代过一次就能长期复用干活的老手”。这篇文章我想从第一性原理出发把Skills究竟是什么、它和Prompt/插件/MCP的区别、如何从零开发一个可用Skill、以及安装测试中的实际经验一次性讲透。内容更适合已经用过AI编程助手、但对Skills机制还没彻底搞明白的人。如果你是刚接触也没关系我会尽量把每个概念都用大白话拆开讲。1. 从第一性原理看Skills它不是模板是工作流封装1.1 Skills、Prompt、插件和MCP到底有什么区别要理解Skills最有效的方式不是背定义而是对比。我做了张表把几个容易混淆的概念放在一起看概念本质生命周期典型使用方式举例Prompt一段对话指令单次对话、用完即走复制粘贴/输入“帮我检查这段代码”Skill一组可复用的指令资源步骤长期存在、可自动召回安装一次AI识别场景后自己调用“前端代码审查Skill”MCP/工具连接外部系统的执行器按需连接由AI调用完成读写/搜索等动作数据库查询、浏览器操作插件打包分发的完整功能集合长期存在用户主动开启一个PDF处理套件核心差异在“知识放在哪里”。传统Prompt是把知识塞进一次对话里说完就没了下次再想用要么翻历史记录要么重新粘贴。而Skill是把“完整的工作方法”固化成一个独立模块——它包含步骤说明、参考规范甚至能调用脚本和模板文件。AI读到SKILL.md之后会按照里面定义的流程执行任务而不是凭感觉发挥。我用一个生活化类比解释Prompt像是你每次出门前口头告诉朋友“记得带钥匙、带充电宝、带纸巾”Skill则是你直接给他一个打包好的旅行清单清单上不只写着带什么还写着遇到雨天怎么办、几点出门最合适、走哪条路线不堵车。AI拿到Skill后就不再需要你操心执行细节了。1.2 为什么AI编程助手都在推Skills从我自己的使用体验看AI编程助手在没有Skills机制前存在三个特别难受的痛点。第一个痛点是“对话漂移”。用Claude或Codex长对话时开头交代的格式要求、编码规范聊到后半段经常被遗忘。明明第一轮告诉它“注释用中文”五轮之后它又给你冒出英文注释。不是AI变笨了而是上下文太长早期的约束被稀释了。Skills把约束固化在独立的指令文件里每次调用都重新加载稳定性高得多。第二个痛点是“重复教学”。假设你每天都要做一个固定任务比如“按公司规范写前端组件”你每天都要花五分钟把规范粘贴给AI。这些规范可能长达几百行占用了大量上下文窗口还会打断对话节奏。Skills相当于把这个教学成本一次性付清之后AI自己就能识别“这个任务应该用那个Skill”你不需要再复制任何内容。第三个痛点是“隐性知识无法沉淀”。团队里厉害的人通常有一套自己的审查清单、编码习惯、测试策略但这些东西基本都在脑子里。Skills第一次让这些隐性知识有了标准容器——一个目录、一个SKILL.md、若干个脚本和参考文件。它可以被复制、分享、上传到社区也就具备了“积累和传播”的属性。从这个角度看Skills的意义不只是工具层面的更是知识管理层面的。2. 一个Skill的组成SKILL.md与目录结构的规范细节2.1 SKILL.md里到底写什么一个Skill的本质是一个目录目录里最关键的文件叫SKILL.md。这个名字是约定俗成的代表“入口文件”。AI接到任务后会先扫描Skill目录找到SKILL.md读取里面的元信息和指令。SKILL.md的结构非常有讲究。头部是一个YAML格式的frontmatter有点像Hugo或Jekyll博客的头部信息里面是AI用来“判断什么时候用这个Skill”的关键字段。我常用的最小配置是这样--- name: code-review-frontend description: 用于对前端JavaScript/TypeScript代码进行系统审查。当用户要求检查代码质量、发现潜在bug、评估可维护性或代码风格一致性时使用。 ---这里有两个字段极其重要。name是Skill的唯一标识安装后别和其他Skill重名。我的习惯是“动词-领域”格式比如create-blog-post、analyze-server-log一眼就能看出是干什么的。description是整个Skill里最考验功力的部分。AI判断“要不要调用这个Skill”靠的就是这个字段的文本匹配。写得太泛比如“用于代码审查”那用户问“这段代码有问题吗”它可能触发问“这个函数是干什么的”也可能误触发。写得太窄比如“仅用于React函数组件审查”那用户用Vue项目时它就识别不出来。我的经验是description要包含任务领域 触发条件 典型场景。比如“当用户要求检查JavaScript/TypeScript代码质量、优化性能、排查bug或统一代码风格时使用。适用于前端项目代码审查、Pull Request评审、重构风险评估。”这句话覆盖了任务类型和常见表达方式命中率高很多。when_to_use字段我也经常用它作为description的补充告诉AI“什么时候不要用”。比如规范里可以写“不要用于Python后端代码审查除非用户明确要求对标ESLint规则。”这个字段能有效减少误触发。frontmatter下面就是正文部分正文才是真正的工作指令。这里的原则是用明确的祈使句列出可执行的步骤而不是写一堆抽象建议。我见过很多人把正文写成了“请仔细审查代码注意潜在问题”这种空话AI读完等于没读。有效写法是# 执行步骤 1. 先读取目标目录下所有 .js/.ts/.jsx/.tsx 文件。 2. 按以下维度逐项审查安全漏洞、边界条件、错误处理、性能瓶颈、命名规范、模块耦合度。 3. 对每个发现标记严重等级P0必须修复、P1建议修复、P2可选优化。 4. 输出Markdown报告按等级排序每条发现需标注文件名与行号。 5. 如果发现高风险问题附上最小可复现代码建议。这种写法AI执行得特别精准因为每一步都是可验证的。我实测下来同样的审查任务用空泛指示的结果和用步骤化指示的结果质量差距非常大。2.2 目录结构和资源引用SKILL.md写完之后一个成熟的Skill通常还会带配套资源。我的标准目录结构长这样my-skill/ ├── SKILL.md ├── scripts/ │ ├── extract-todos.py │ └── scan-deps.sh ├── references/ │ └── eslint-rules-summary.md └── templates/ └── report-template.mdscripts目录放可执行脚本比如你想让AI运行一个代码扫描工具、批量处理文件都可以提前写好脚本放进这里。references目录放参考资料比如规则摘要、API文档、样例输出。templates目录放模板文件比如AI生成报告时需要套的Markdown模板。这里有一个关键约定在SKILL.md中引用这些资源时要用$SKILL_PATH这个环境变量来定位。这是一个内置的绝对路径变量指向Skill的安装根目录这样无论Skill放在哪个平台、哪个目录AI都能稳定找到文件。我的正文里会写使用 scripts/extract-todos.py 提取代码中的 TODO 注释。执行方式 python $SKILL_PATH/scripts/extract-todos.py 目标目录为什么推荐把资源做成独立文件而不是写进正文因为SKILL.md的正文长度是有限的写得太长会挤占上下文窗口让AI在处理核心任务时“精力分散”。脚本和参考资料作为外部文件按需加载既保证了指令简洁又让AI能拿到完整信息。这个设计思路和软件工程里的“关注点分离”一模一样。3. 手把手开发一个Skill从前端代码审查到分镜脚本3.1 场景拆解把一件事讲成AI能执行的流程开发Skill的第一步永远不是写SKILL.md而是拆解你的目标任务。我通常问自己三个问题这个任务输入是什么输出是什么中间要经过哪些步骤我拿一个高频场景举例——前端代码审查Skill。这是社区里最流行的Skills之一因为它恰好是AI擅长、但人容易遗漏的工作。人工审查一份前端代码时我们的关注点大致有安全性有没有XSS注入点、错误处理fetch失败有没有兜底、性能有没有重复渲染、大对象嵌套、可维护性组件有没有拆得太碎或者太臃肿。但问题在于每个人审查的深度和维度都不一样今天看了安全、明天忘了性能全凭状态。把这件事固化成Skill的时候就得把这些维度固定下来。我最终确定的执行流程是先扫描目录文件清单然后分四轮审查——第一轮查安全隐患第二轮查错误处理与边界条件第三轮查性能问题第四轮查代码风格与可维护性。每轮独立输出发现最后一并汇总成报告。这样拆完之后SKILL.md的正文写起来就顺理成章了。我实际写出来的部分是# 审查维度 按以下优先级审查 1. 安全DOM操作是否经过转义、是否有危险的fetch URL拼接、是否使用innerHTML注入用户内容。 2. 健壮性async/await是否缺少try/catch、可选链是否覆盖深层访问、空数组时是否崩溃。 3. 性能useEffect依赖是否稳定、列表渲染是否有key、setState是否放在循环内。 4. 风格命名是否语义化、函数是否单一职责、是否存在明显重复代码。注意看我每条都写成了“具体检查点什么”而不是“注意安全”。AI执行时就能按图索骥精准定位问题。3.2 从零写到MVP开发一个分镜助手Skill除了代码审查这种偏工程类的SkillSkills还能用于内容创作场景。最近社区里热度很高的分镜Skill就是一个很好的例子。很多人用AI做短视频、做动画但AI生成的分镜脚本往往很“平”缺少镜头语言的专业感。分镜Skill要做的就是把“导演分镜”的隐性知识封装起来。我先拆解这个任务输入是一段故事脚本或文案输出是一张分镜表包含场次号、景别、运镜方式、画面描述、台词、音效建议、估算时长。中间的步骤我定义为拆分叙事单元、确定主次镜头、标注情绪节奏、估算镜头时长。这套逻辑来自基础视听语言并不复杂但绝大多数人自己写的时候根本想不到要把“情绪节奏”单列一列。然后我把这些定义写进SKILL.md核心段落是这样的# 分镜生成规则 输入的故事内容按以下规则输出分镜表 - 每个场景拆分为独立场次用 SC-01, SC-02 编号。 - 景别标记远景/全景/中景/近景/特写。 - 运镜标记固定、推、拉、摇、移、跟、升降。 - 每行镜头必须包含“画面内容”“情绪指向”“时长(秒)”三列。 - 时长估算规则固定镜头 3-5 秒运动镜头 5-8 秒重要对话镜头 2-3 秒。 - 所有画面描述使用视觉语言禁止使用心理描写或无法拍摄的抽象词汇。这个Skill跑起来的效果非常直观。我拿一个简单的文案测试过AI输出的分镜表已经接近小团队初稿水平了。后来我又在上面迭代了一个版本加入了“声画对位”的检查规则AI会检查画面变化点有没有配上音乐变化标记这个细节是很多新手导演最容易忽略的。所以开发Skill的过程本质上就是在把你脑子里“怎么做这件事”的隐性知识一点一点显性化。而AI的执行能力会让这套流程的产出效率远远超过你手动操作。3.3 开发中的三个常见坑开发Skill我踩过不少坑挑三个最典型的说。第一个坑是description写得太泛导致AI频繁误触发。我给一个日志分析Skill写的描述是“用于分析日志文件”。结果用户让AI总结一段聊天记录时它居然也调用了这个Skill因为“聊天记录”被它看成了“日志”。后来我把描述改成“用于分析服务器运行产生的日志文件包括错误日志、访问日志、应用调试日志。适用于排查服务异常、统计错误频率、追踪调用链。不用于分析普通文本对话。”加了“服务器”“错误日志”“追踪调用链”这些强特征词后误触发率直线下降。第二个坑是步骤写得像建议而不是指令。我以前写“审查代码时可以关注一下安全性”AI执行时就“可以”了一下根本没有。后来把所有模棱两可的词全部去掉改成“必须逐行检查所有用户输入是否经过转义”执行力立刻上来了。AI是一个指令跟随者你给它留选择余地它就会选最容易的路。第三个坑是资源文件没有打包导致换机器就失效。早期我做Skill喜欢把脚本放在电脑的某个角落路径里SKILL.md里写的是绝对路径。结果分享给朋友之后他的机器上根本找不到这个文件。后来统一改用$SKILL_PATH相对引用所有资源都塞进Skill自己的目录里这个问题就不再出现了。现在我做任何Skill都坚持“开箱即用”原则下载、安装、运行三步到位绝不依赖外部环境。4. 安装、调用与测试把Skill真正用起来4.1 从哪找现成Skill官方市场与社区仓库自己做Skill之前我建议先去社区里逛逛看看别人怎么做、哪些流程已经被封装好了。现在找Skills的渠道主要分成三类。第一类是官方市场。部分AI编程助手内置了Skill市场比如Claude官方市场里的Skills分类可以搜索、一键安装。这类渠道的优势是经过官方审核质量和安全性有保障推荐新手从这里下手。第二类是GitHub。在GitHub上搜索“awesome-claude-skills”这类汇总仓库或者直接搜“topic: skills”能找到大量社区开发者维护的Skills。社区里有个不成文的规矩好Skill都会附带一个清晰的README和演示截图下载之前先看两点——最近更新时间是否超过一年以及fork和star的数量是否正常。长期没更新的Skill大概率对新版本不兼容。第三类是独立博客和技术社区。很多开发者会把自己辛苦做出来的Skill写成帖子分享附带下载方式。这类Skill往往带有很强的个人实践痕迹质量参差不齐但也常常能发现惊喜比如有人把“小红书文案生成”“PPT结构生成”都做成了Skill。找Skill时有个容易被忽略的点留意许可证。有些Skill用的是MIT协议你可以随意改有些则是“只允许个人使用”或者带有非商业条款。如果你打算把Skill用在公司项目里这一步一定要看清。4.2 安装与一键测试不同平台的安装方式略有差异但整体逻辑是通用的——把你的Skill目录放到指定的Skills根目录下。以我用的Claude为例安装流程简单说就是找到Setup或Skills管理页面选择“Install a Skill”然后指向Skill所在的目录或压缩包AI会自动扫描并注册。安装完之后我强烈建议立刻做一轮“一键测试”。所谓一键测试就是构造一条包含触发关键词的指令比如我装完前端审查Skill之后会直接发一句“请用code-review-frontend技能审查一下当前项目src目录下的代码”。如果AI正确调用了Skill并按照SKILL.md的步骤输出结果说明安装成功。如果AI回复“我没有这个技能”或者“我没有安装该插件”那就需要检查目录路径是否正确、SKILL.md的frontmatter是否解析失败、以及Skill名称是否和文档一致。还有一种更精细的测试方法叫快照对比。先在没装Skill的情况下让AI执行一次任务记录输出再装上Skill执行同样的任务对比两次输出差异。这个差异越大说明Skill对AI行为的影响越明显。这个方法尤其适合验证“我的Skill到底有没有起作用”。4.3 调试和回归测试调试Skill是一个反复迭代的过程。我的调试流程基本是跑一次测试用例观察输出定位偏差修改SKILL.md再跑一次。关键点在于测试用例要有针对性。我通常会准备三组测试用例。第一组是标准用例——完全匹配description中描述的典型请求测试AI能否正确触发。第二组是边界用例——请求里绕了点弯子比如“帮我看看这个文件夹有没有明显的问题”测试AI能不能识别出这个需求本质上属于前端审查。第三组是负向用例——故意发一个完全无关的请求比如“帮我写一首诗”测试AI会不会错误触发。这三组用例跑完基本能判断一个Skill的“判别力”和“执行力”是否合格。我见过很多半成品Skill标准用例能过边界用例就抓瞎负向用例更是疯狂误触发。出现这种情况十有八九都是description没写好其次是正文里的触发条件写得太宽泛。还有一个容易被忽视的调试技巧检查AI的思考过程。很多编程助手支持展开查看“AI推理摘要”或“调用日志”里面会记录它为什么选择调用这个Skill、加载了哪些文件、执行了哪些步骤。调试时看这个日志能发现很多输出层看不到的线索比如AI明明读了report-template.md但没有套用模板说明正文里“必须使用模板输出”这个指令的语气还不够硬。5. 一张表解决90%的问题常见故障排查实录用Skills的时间越长遇到的问题类型越集中。我把这些问题整理成了一张排查表遇到情况时照着定位就行。症状可能原因排查思路解决办法AI完全无视Skill直接回答description不匹配Skill未正确安装检查Skills管理页面是否列出了该Skill检查触发指令是否包含description中的场景词重写description加入更多强特征词重新安装AI调用了Skill但执行方式不符合预期SKILL.md正文指令不够明确查看AI调用日志确认它读了哪些部分把“可以”改成“必须”把模糊描述改成具体步骤编号Skill里的脚本不执行脚本权限问题解释器路径错误手动跑一次脚本验证检查是否用了$SKILL_PATHchmod x在正文中明确写清执行命令Skill导入后报frontmatter解析错误YAML格式有误比如缺少冒号或缩进错误用YAML校验工具检查头部修正格式注意冒号后必须有空格项目代码一换位置Skill就失效SKILL.md里用了相对路径或硬编码路径检查所有文件引用方式统一改为$SKILL_PATH开头更新Skill后行为没有变化缓存或会话未刷新重启会话确认新版本覆盖了旧目录完全删除旧目录再重新安装误触发频繁无关任务也调用description写得太宽泛观察误触发场景的共同特征在when_to_use里明确写出“不适用场景”这张表里最常出问题的两项一个是description质量一个是脚本执行权限。description的问题前面已经说过脚本执行的问题则是个“隐藏杀手”——很多人写了非常棒的辅助脚本但在正文里只写了“运行脚本”而没有写清楚用什么解释器执行、脚本是否有可执行权限。结果AI调用了Skill脚本却跑不起来整个流程就卡死了。我现在写SKILL.md时都会在脚本调用那一节固定加上三行解释器路径、执行命令示例、预期输出格式。这样即使AI没有任何相关经验也能照葫芦画瓢把脚本跑起来。排查完上面所有问题之后还有一个终极兜底手段把Skill目录删了从零开始用一段精心构造的Prompt完成同样任务。如果两者的执行效果差距不大那说明这个Skill的封装没有真正提升AI的效率该重新设计而不是继续打补丁。这个方法听起来有点极端但确实能逼着你把注意力从“修bug”拉回到“核心价值”上。我个人最近一个比较满意的Skill是“短视频分镜助手”从最初只有一段分镜规则到后来加入了景别对照表、运镜参数模板、经典电影案例分析三个references文件前后迭代了差不多两周时间。每次迭代都在前一次的实际输出上找问题改的不是文字而是“AI到底在什么地方理解偏了”。这个过程让我对Skills的理解深了很多——它本质上是一个沟通器让人类的隐性经验变成AI可以执行的结构化协议。如果你也想试试我建议从自己日常工作里最重复的那个任务开始不要贪大先做一个小而美的Skill跑通了再慢慢加功能。等你真正上手之后会发现这玩意儿确实会让AI从一个问答工具变成一个能被你持续调教的执行体。