最近这半年“skills”这个词在AI编程领域几乎成了绕不开的高频词。你不管打开Claude Code还是Codex、OpenCode都会在配置目录里看到它的存在去GitHub搜一圈以“skills”为后缀的仓库更是多到翻不完。我最早以为这不过是提示词换了个马甲直到在一次实际落地中被它真正救了场才意识到Skills把“教AI干活”这件事从玄学变成了工程。这篇文章我不会讲什么高大上的概念就把我从安装、开发、清理到场景选型一路趟过来的东西整理出来。无论你是刚准备入坑的新手还是已经在用Skills但总觉得“差点意思”的开发者应该都能从中找到点能直接落地的内容。1. 先搞明白Skills到底解决了什么问题1.1 从“临时提示词”到“可复用技能包”聊Skills之前得先说一个我自己反复踩过的现象。早先在Claude Code里做代码审查我每次都得重新输入一大段提示词规定“你要注意安全漏洞、性能问题、命名规范输出要分优先级要有修改建议”。那时候的“技巧”就是把提示词存成Markdown文件要用的时候拖进会话里。但问题很快就暴露了提示词越长模型执行越不稳定而且每次都要手动加载换一个项目重新复制粘贴效率极低。后来看到Anthropic提出的Agent Skills方案思路完全不一样。它把“指令参考代码执行脚本”打包成一个独立文件夹放进指定的skills目录AI在遇到匹配任务时会自己去读。这就好比以前你请了个经验丰富的帮手每次干活前都要电话交代半天现在你直接给他一本操作手册和一套现成工具箱他接到任务就能按手册干活。1.2 Skills与MCP是两回事别混为一谈这是我最想强调的一点。很多朋友一聊依赖性工具就习惯性往MCP上靠但实际上Skills和MCP解决的是两个完全不同的层面的问题。MCP是给AI装“眼睛和手”本质是连接外部数据与工具的管道。比如你想让Claude直接读数据库、操作浏览器、调用GitHub API靠的是MCP Server去暴露可访问的资源。它解决的是“AI能访问什么”的问题。Skills则是给AI装“SOP手册与专业知识图谱”解决的是“拿到任务之后具体怎么干活”的问题。它不负责联网不负责读外部数据它就装在本地把一套流程知识打包好比如“当我需要做代码审查时按这个顺序检查这几类问题参考这个标准文件”。对比项MCPSkills核心作用扩展AI的外部访问能力扩展AI的任务执行流程与判断标准形态外部服务需要配置URL、鉴权本地目录包含SKILL.md和脚本、参考文件依赖依赖网络、API、鉴权等无网络依赖纯本地读取适合场景数据库查询、文件读写、API联动代码审查、代码生成、文档撰写、特定领域任务理解清楚了这一点你就不会总问“Skills要不要联网”或者“Skills和MCP能不能互相替代”这种问题了。它们可以一起用互补。2. 手动安装GitHub上的Skills从克隆到生效2.1 先搞清楚安装位置装Skills的第一步是搞明白你的工具去哪个目录找技能。目前主流三个工具的做法比较接近但路径和优先级略有不同。以Claude Code为例它有两个层级的skills目录个人级~/.claude/skills/所有项目都能用的通用技能放这里项目级.claude/skills/在你的项目根目录下只给当前项目用的专属技能放这里优先级是项目级覆盖个人级。也就是说同名技能如果在两个目录都存在项目目录里的那个会生效。这个设计很实用同一个技能你可以维护通用版和定制版不需要平行复制多份。2.2 Claude Code里装一个GitHub技能的完整流程我在GitHub上找一个技能仓库来演示。整个流程分三步。第一步把仓库克隆到对应目录git clone https://github.com/your-name/some-awesome-skill.git ~/.claude/skills/some-awesome-skill如果你拿到的不是Git仓库而是一个压缩包那就手动解压把解压出来的文件夹整个放进~/.claude/skills/目录效果是一样的。第二步重启Claude Code。这一步很关键官方文档说支持热加载但我在实际使用中遇到过几次旧会话里识别不灵的情况。干脆重启会话最保险也就几秒钟的事。第三步验证。在对话里直接输入一句类似“用这个技能帮我处理xxx”如果配置成功Claude会自动读取SKILL.md并按照里面的流程执行。更直接的验证方法我放到2.4讲。2.3 Codex与OpenCode的安装参考Claude Code之外另外两个主流工具的安装套路也大同小异。Codex的skills目录默认在~/.codex/skills/同样是克隆Git仓库进去然后重启CLI。OpenCode这边稍微不同它更推荐用命令行方式安装比如opencode skill add your-name/your-skill-repo这个命令会直接帮你克隆到OpenCode管理的skills目录并且自动做配置登记比手动拷贝要省事很多。各工具路径汇总工具个人级目录项目级目录安装方式Claude Code~/.claude/skills/.claude/skills/手动克隆或解压Codex CLI~/.codex/skills/.codex/skills/手动克隆或解压OpenCode由opencode管理项目配置opencode skill add2.4 装完之后怎么确认真的生效了很多新手在这步栽跟头装完了觉得没反应就以为Skills没用。实际上Skills的触发机制是“模型判断该用的时候才用”它不是每条命令都会主动去读技能包。这就会出现一种情况你明明装了技能但让它干活的时候它还是按普通方式处理你以为是安装失败。我给你的建议是按下面两步来验证直接指定技能名。不要泛泛地说“帮我处理代码”而是说“用代码审查skill帮我看看这个文件”。显式指名通常能强行走一遍加载流程。看日志。Claude Code用--debug模式启动能打印完整的工具调用记录日志里如果出现了read SKILL.md或者类似的记录说明技能已经加载成功。确定加载没问题之后后面使用就不用管它了等模型自己判断触发时机就好。3. 开发自己的Skills目录结构、配置文件与写作心法3.1 一个最小可用的Skills长什么样GitHub上那些眼花缭乱的技能仓库拆开看骨架都是一样的my-skill/ ├── SKILL.md ├── scripts/ │ └── run.py ├── references/ │ └── best-practices.md └── assets/ └── templates/SKILL.md是这个技能包的入口AI读取技能时第一个找的就是这个文件。scripts/放可执行脚本用来处理重复性高的动作references/放参考资料相当于给AI准备的“查阅手册”让它遇到不确定时能翻一翻assets/放模板、样例之类的附属资源。初学者最容易犯的错是一上来就想写一个功能齐全的“全家桶”把什么都往一个文件夹里塞。我的建议相反先做一个20行的最小技能包跑通了再逐步加内容。3.2 SKILL.md的YAML头和正文怎么写SKILL.md的结构其实很简单就是YAML frontmatter加一段Markdown正文。--- name: code-reviewer description: 仅当用户要求对代码进行审查、检查代码质量时使用。 --- # 代码审查流程 当接到代码审查任务时请严格按以下步骤执行 1. 先读取目标文件的完整内容 2. 按以下优先级检查问题安全问题、性能问题、逻辑错误、可维护性问题 3. 参考 references/best-practices.md 中的规范逐项比对 4. 输出结果为三级列表严重问题、建议优化、可选改进这里有三个写作细节值得多说两句。第一个是description字段别小看它。模型是否决定调用这个技能基本就是看这个描述跟你当前请求的匹配度。写得宽泛了无关任务也会触发浪费上下文额度写得太窄该触发时不触发。好的写法是“仅当……时使用”这种句式把边界框清楚。第二个是正文中的操作步骤。这里的核心原则是“像写给新手看的SOP一样去写”每一步都要具体、可执行不要写“评估代码质量”这种空话要写“先检查未处理的异常再检查全局变量污染最后核对错误日志的覆盖范围”这种具体指令。第三个是“让参考文件替模型省脑”。模型本身有知识储备但特定团队的代码规范、特定框架的踩坑清单这些未必可靠把它们写进references中确实比在提示词里反复强调更稳定。而且references里的文件不会被全部加载只有在主指令提到时才会被查阅这就省下了大量上下文空间。3.3 让技能真正“好用”的几条写作心法我拆了不少优质开源技能总结下来真正用得顺手的都有这么几条共性。第一能用脚本兜底就不要让模型空想。比如你让AI生成某个固定格式的配置与其在SKILL.md里写“按以下规则填写”不如在scripts里放一个生成脚本让它直接调用。脚本的结果是确定的模型半路跑偏的概率会小很多。第二一个技能只干一件事。我最初写过一个“代码质量全家桶”既能审查、又能重构、还能生成单元测试结果模型经常选错流程一会儿按审查的方式做重构一会儿又在审查时直接改代码。拆成三个独立技能之后一切正常了。这就是“单职责原则”在Skills里的体现。第三好名字和ico非常加分。技能名称最好用snake_case命名一眼就能看出用途例如git-branch-manager、latex-formatter这样的不要用cv这种含糊名字模型判断时也会高看一眼。第四版本管理直接交给Git不用费劲想版本号。把skills仓库维护成一个公开GitHub仓库每次改动提交时写清说明以后回滚就方便很多。4. 用不上的Skills怎么清理存量管理与冷归档4.1 为什么要定期清理Skills这个问题通常得等到你发现自己那台电脑上的技能越积越多才意识到。我见过不少朋友装的时候兴奋装完一次没用过过段时间文件夹里几十个技能包堆在那里。Skills堆积的问题不是吃硬盘空间而是污染注意力。AI在每次会话开始时都会扫描可用技能列表并读取元信息来决定是否调用技能数量越多、描述写得越含糊误判的概率就越大。真正需要某个技能的时候模型反而可能挑了另一个不那么合适的“邻居”。另外同名、近义技能之间的冲突处理也是成本最后连你自己都分不清该留哪个。4.2 清理流程先审计再冷归档最后删除我在社区看到一位开发者的清理思路很值得借鉴后来我按照这个思路整理出了一套自己的流程大致分三步。第一步审计现状。在skills目录下执行一条命令把每个技能包的名称和描述导出来看一遍for d in ~/.claude/skills/*/; do echo $d head -n 5 $d/SKILL.md done看看哪些技能是你记得住的哪些已经想不起来是干什么用的。记不住的那些大概率也不会被用到。第二步冷归档而不是直接删除。建立一个skills_disabled目录把暂时用不到但以后可能用的技能移过去mkdir -p ~/.claude/skills_disabled mv ~/.claude/skills/dead-skill ~/.claude/skills_disabled/这一步的好处是你不用为“删了以后后悔”纠结反正被移出skills目录后AI就不会再扫描到它效果等同于禁用。等真正想用的时候再移回来顺便还会重新思考一次“我是不是真的需要它”。第三步确认一段时间后确实没再想起过它再删除。我个人习惯是冷归档放一个季度以上才会考虑彻底删除。4.3 清理时容易踩的坑这里有一个非常隐蔽的坑要提醒你不少人以为“把SKILL.md内容清空”就算禁用了其实大错特错。模型扫描到空描述或者格式错误的SKILL.md可能触发异常行为甚至会在日志里反复报错。禁用技能的正确做法就是目录级别的移除不要让空文件留在原位。还有一个坑是路径搞错。项目级和用户级同名技能会互相覆盖清理的时候如果只处理了个人级目录项目里还留着一个同名旧技能你以为删了其实还在生效。所以每次清理完记得在项目里也检查一遍。5. 分场景的Skills推荐前端开发、数学建模、内容创作与源网站5.1 前端开发类Skills怎么选前端是Skills应用最活跃的领域之一。GitHub上热门的前端技能主要集中在几个方向UI生成与审查、组件库代码生成、样式重构、接口联调辅助。以UI审查类技能为例好的技能包里通常包含一份设计规范checklistAI拿到页面截图或代码后会按布局、间距、色彩对比度、可访问性等维度逐项审查输出问题清单。比起单纯让AI“看一眼有什么问题”这种有明确标准的审查可靠得多。类似的还有React/Vue组件生成技能里面附了项目现有组件的代码风格规范生成的代码才能和项目代码风格保持一致。如果你想在项目里试水我建议优先装一个“前端代码审查”加一个“组件生成”这两个最容易见效也最能帮你理解Skills的运作方式。5.2 数学建模与比赛场景的Skills配置数学建模比如华为杯这类比赛对Skills的需求挺独特因为比赛流程相对固定时间又紧一套好用的技能包能压缩大量重复工作。比赛场景里大家比较推崇的技能大致有四类数据处理与清洗、特征工程、常见模型实现与调参、论文LaTeX排版。数据处理技能包里一般包含缺失值处理、异常值检测的脚本AI接手数据后直接调用脚本完成清洗比在对话里一步步打命令靠谱得多。LaTeX排版技能则会在写作Debrief阶段把论文结构、公式格式、图表排版规范一次性打包给AI让它在写正文时就按比赛的格式要求输出后期能省下大量调格式的时间。有个容易被忽视的技巧是比赛开始前先建一个项目级.claude/skills/目录把比赛用的技能全部放进去比赛期间AI会优先读取项目级技能不会跟日常个人技能混在一起。同时项目级技能随项目走提交成果、换一台电脑技能也跟着走省心。5.3 内容创作与AI漫剧场景AI漫剧这类内容创作场景这两年很火相关的Skills也在快速涌现。这个场景里的核心需求通常有三块分镜脚本生成、文生图提示词生成、人物与场景一致性控制。分镜脚本类技能会接收你的一段剧情描述按镜头格式输出脚本包含景别、时长、画面描述、台词、转场方式等字段。比起直接在对话框里让AI“写个分镜”技能包里预置的格式模板和镜头语言参考能让输出直接进下一步工作流不需要二次整理。文生图提示词类技能则内置了主流图像模型的提示词结构能把分镜里的画面描述扩写成高细节的正向提示词。如果你想在创作流程里引入Skills我建议从分镜脚本这个环节切入替换掉原本零散、每次都要重新描述的提示词方式。效果会立竿见影。5.4 找高质量Skills的几个源网站和技巧GitHub上好的Skills仓库很多但怎么找是门学问。一个比较省力的途径是直接搜awesome-claude-skills这类awesome列表社区维护者会把各类技能按领域分类排列质量相对可控。另一个途径是直接搜xxx-skill比如搜code-review-skill、latex-skill看star数和最近更新日期基本能判断是不是有人维护的活技能。个人建议远离那些半年没更新的仓库AI迭代速度太快旧技能包里的步骤或参考很可能已经失效。找到中意的仓库后不要整个克隆了事先打开SKILL.md读一遍确认它的触发描述和处理流程符合你的预期再装。这个“装前先读”的习惯能帮你减少大量无效技能堆积。最后想说的几句体会技能装得越多不等于效率越高。我自己从早期“收集癖”阶段一路折腾过来现在桌面固定常驻的技能反而只有三四个但每一个都是高频使用的。Skills这个机制真正的价值是把那些你已经验证过“这样做最靠谱”的流程固化下来让AI每次都能稳定地交出符合预期的东西。如果你正打算入坑我的建议很明确先手动装一个单仓库技能跑通流程然后打开SKILL.md从头读一遍看看别人是怎么组织流程的接着自己动手改造一个简单的技能改成符合自己习惯的样子。这一圈走下来你对Skills的理解会完全不一样。等到用顺手了再慢慢建立自己的清理习惯和技术债管理流程。这个东西跟做工程一样先跑通最小闭环再谈规模化。