要说清楚一件事最近半年“skills”这个看似普通的英文单词在开发者圈子里彻底火成了黑话。你搜“skills推荐”搜“skills开发”搜“claude code怎么手动装github上的skills”背后其实是一回事——AI编码代理的可复用技能。它既不是Prompt模板也不完全等于插件更像是一套能被AI自动理解、按需加载的“行为包”。这篇内容我打算从概念、安装、编写、选源、清理维护一路讲到场景化用法尽量让你看完就能自己上手。1. 为什么“skills”突然成了编程助手的新关键词1.1 从提示词到可复用行为的演进过去我们用AI编程基本思路是“把需求敲进对话框”给它一段上下文它给你一段代码。这种模式没有沉淀今天调通了一个React组件明天换个项目照样得重新交代背景。于是出现了各种Prompt库大家存模板、复制粘贴但模板进不了模型的工作记忆它只在对话那一刻起作用。Skills的出现解决了“上下文不能复用”的问题。它本质上是一套带着说明文件、示例和约束条件的目录Agent在运行时会读到这些内容并根据当前任务判断“该不该把这套技能加载进来”。你可以把它理解成给AI准备的一套工具箱——不打开的时候不占位置一遇到对应场景模型就会自己去翻箱倒柜。最早让我有直观感受的是在Claude Code里跑一个前端项目时的变化。之前每次都要粘贴一遍公司的代码规范它还是会忘把规范写进一个skill下一次它自己就找过来用了而且准确率明显高很多。这背后其实是把“一次性对话里的知识”固化成了“长期记忆里的能力”。1.2 它和MCP、插件、Agent到底什么区别很多新手一上来就被这套概念绕晕。我的理解是这样MCP是给Agent接外部工具和数据的管道比如连接数据库、调用浏览器Skills是给Agent用的知识、流程和约束更像“说明书”而Agent是负责调度这一切的“人”。插件这个词在不同产品里的定义太含糊有的插件本质就是一整套SKILL工具绑定不用太纠结叫法。打个比方MCP像给厨师一个冰箱和灶台skill则是菜谱和操作习惯。你换了个新厨房冰箱灶台都要重新接但菜谱可以随身带到哪都能用。这就是为什么skills可以跨项目、跨目录甚至在不同支持该标准的工具之间迁移。1.3 怎样的场景真正适合引入技能并不是所有需求都该做成skill。我自己踩过不少坑一开始恨不得把所有Prompt都包装成技能结果技能列表越攒越长Agent在选择时反而犹豫了。适合做成技能的通常有这么几个特征任务流程相对固定、判断标准明确、步骤较多、需要重复执行。典型例子是“按公司规范创建新组件”“批量处理Markdown表格”“跑数学建模的题目分析”。那种只回答一次、没有固定流程的事情比如“帮我解释这段代码”做成skill纯属浪费。另外如果你发现某类任务你每次都要花十分钟重新跟模型讲背景那就是最值得技能化的候选。2. 从零安装一套可用技能以Claude Code手动装GitHub技能为例2.1 动手前先确认工作目录很多人卡在第一步技能到底放在哪里不同工具的路径不完全一样但逻辑是共通的。Claude Code支持两种级别的技能目录一种是用户级作用范围覆盖你所有项目一种是项目级只在当前项目里生效。用户级技能目录在~/.claude/skills项目级则是项目根目录下的.claude/skills。具体放哪一级取决于技能的通用程度。像“代码审查”这种放用户级没问题但“华为杯建模流程”这种明显跟特定竞赛绑定的放在对应项目的.claude/skills里更干净省得每次跟AI对话时一堆无关技能干扰它判断。2.2 GitHub技能库的常见结构如果你在GitHub上看到一个仓库名字里带skills点进去别急着整个克隆。先看它的目录结构。标准的skill由三部分组成SKILL.md主文件是核心里面包含YAML头部元数据和正文说明scripts/或data/存辅助脚本和参考数据examples/放示例让模型照着学。看清楚这三部分你才能判断它是否需要外部依赖。有的技能看似一个Markdown其实内部要跑Python脚本如果你的环境缺依赖装完也只能看不能用。我见到最多的安装失败案例都是有人拿了个带scripts的skill却只拷了一个SKILL.md出来。2.3 手动安装的完整步骤不借助第三方工具、纯手工安装其实就三步。首先把仓库克隆到本地注意不要整仓乱放最好先建立一个临时目录git clone https://github.com/某用户/某技能仓库.git /tmp/skills-temp然后看一眼里面有没有现成的skills子目录有就整个复制没有就按目录名把每个技能分别复制。复制目标路径按前面说的来用户级就放~/.claude/skills下cp -r /tmp/skills-temp/skills/某技能 ~/.claude/skills/最后一步最容易忽略重启会话。Claude Code不会在会话进行中动态扫描新技能你必须开一个新的对话它才会重新读取技能列表。装完之后可以用斜杠命令看一下当前会话能识别哪些技能确认加载成功。2.4 验收与触发方式技能装好后怎么验证一个简单方法是开个新会话提一个“正好用到这个技能”的请求并让AI把思考过程说出来。重点看两件事它有没有自己提到该技能的名字以及执行步骤是否严格参考了SKILL.md里的流程。如果你问完它完全没反应先检查SKILL.md的frontmatter格式。很多技能失效都是因为YAML解析失败name字段带了空格或中文引号模型读不出来自然就不会用。另一种情况是描述写得不够“任务导向”。模型是靠description判断要不要加载某个技能的所以描述里应当写清楚“什么时候用、解决什么问题、输出什么”比如“当用户要求创建可复用的Vue组件时使用”而不是“这是一个Vue组件技能”。3. 学会自己开发AI Skill从SKILL.md到可运行的行为包3.1 先学会写一份完整的SKILL.md自己动手做技能最重要的不是写代码而是梳理流程。一个SKILL.md通常分成两部分frontmatter里放name和description正文里写步骤、规则、示例和注意事项。下面是一个可以照抄的骨架我拿“数学建模题目分析”举例--- name: math-modeling-analysis description: 当用户给出数学建模竞赛题目需要完成问题理解、假设提出、模型选择和结果分析时使用。尤其适合华为杯、国赛等场景。 --- # 数学建模题目分析 ## 目标 在规定时间内产出一份可评审的建模问题分析报告。 ## 操作步骤 1. 阅读题目全文提取约束条件和评价指标。 2. 列出至少3种可能建模方法对比复杂度与适用性。 3. 结合数据规模推荐首选方案。 4. 明确假设、变量、方程或算法流程。 5. 输出Markdown报告包含模型、优缺点、可行性评估。 ## 注意事项 - 不要直接写完整代码先确定模型。 - 所有假设必须标注依据。 - 如果题目数据异常优先建议数据清洗。你发现没有这本质上写的是一个“决策流程”不是让AI背课文。Skills的精髓就在于你把经验中的判断顺序写清楚了模型拿到以后才能按这套顺序思考。3.2 为Skills设计“最小可用范围”开发技能最常见的错误是把范围铺得太大。有人写一个“全栈开发助手”技能从后端写到前端再到部署结果模型每次加载它都会迷茫因为它的描述太宽泛第一步该干什么根本判断不了。我更推荐的思路是“小步快跑”先做一个只处理“创建新页面”的技能跑通了再扩展成“页面接口联调”。范围小的另一个好处是好测试。技能出了问题你很快能定位是哪个步骤的规则写错了。范围一大锅都分不清楚。3.3 前端开发场景的实用技能设计前端大概是目前可复用技能最活跃的领域因为从规范到构建路径都很固定。我自己的一个小组件技能是这样设计的它要求AI先看现有项目的目录结构再根据组件类型选模板最后必须产出一个包含测试文件的提交包。注意一个细节技能正文除了步骤最好附上“反面样例”。模型看正面例子容易照抄但你给它看两三段“经常写错”的代码并标明为什么错它反而能建立更稳的判断边界。这一点也是我对比过大量输出质量之后的经验。3.4 调优与迭代技能不是一次写成的写完技能只能算开始。我会建议你每次真实使用后把暴露出来的问题直接补进“注意事项”里。比如我的技能一开始没规定“CSS变量必须走设计系统”结果AI几轮迭代后自己造了一堆颜色值我才补上这条约束。迭代时要特别注意descriptions的表述。同一个技能你改了正文不改描述AI还是可能根据旧描述错误地触发。最佳实践是每次改了行为就顺手更新一下description让描述和实际行为保持同步。我自己就吃过这个亏一个技能内部逻辑已经大改description还写着“处理简单数据校验”结果该触发的高级流程一次都没启动过。4. 技能库从哪找、怎么选绕开源网站不乱踩坑4.1 常见技能源与检索技巧现在技能源主要分几类聚合型网站、GitHub优质仓库和个人博客分享。你搜“skills技能库网址”能找到一堆但质量参差。我个人比较偏好GitHub上的开源仓库因为它能看到commit记录知道项目是不是在维护。在GitHub搜技能仓库有个小技巧别只搜skills搜claude-skills、codex-skills、opencode-skills这类带工具名的词容易找到更对口的仓库。另外看仓库时要先去issues选项卡扫一眼如果一堆人反馈“技能不生效”而作者长期不回复直接放弃。还要注意仓库是否带LICENSE有的仓库技能可以免费使用但不允许改写后分发如果你准备二次开发这点必须确认。4.2 判断一个技能质量的硬指标我判断一个技能值不值得装主要看四个维度说明是否具体、有没有示例、依赖是否可控、版本是否活跃。说明只写“XX技能库”四个字的基本可以跳过了因为模型靠description工作作者连描述都懒得写行为大概率也好不到哪去。有examples目录的技能通常质量更稳它给了模型模仿的锚点。依赖方面能用纯文本、纯脚本实现的技能优先一上来就引一堆npm包或者要求访问外部服务的技能要多留个心眼除了安装麻烦也存在权限风险。4.3 那些知名技能仓库和Tibo清理法提到skill分享绕不开一个项目叫superpowers它给Claude Code做了很多高质量技能核心是“给技能开发技能”的元技能适合想深度定制的人。还有typesafe-ai-skills这类更严谨的工程化技能集适合放进正规业务线用。我不赞成看到仓库就整仓安装。一个三四十个技能的仓库真正适配你业务的可能就三四个。这里正好说下目前社区常说的“Tibo清理法”——大意是装完技能后只保留你过去一周真实用过的其余全部移出目录用的时候再装回来。这听着保守但确实治好了我“技能存了一堆一个不用”的老毛病。5. 按热门场景配置技能前端、数学建模、AI漫剧5.1 前端开发让技能去对齐标准而非堆代码前端场景下技能最该发挥的价值是“对齐标准”而不是写得快。一个优秀的前端技能应该明确说清楚组件放哪个目录、样式用什么方案、命名用什么风格、测试要不要覆盖边界。你可以把团队规范塞进技能里但别把整个设计系统文档都放进SKILL.md模型一次读不完。如果你经常用Claude Code做前端我建议至少配两个技能一个负责“创建可复用组件”另一个负责“按设计稿切片实现页面”。前者重规范后者重转化合并成一个反而容易被跨页面数据流问题带偏。实际开发中我借助技能把普通页面从十几分钟压到五分钟左右但这五分钟里我每个人都会检查它是否遵守了目录规范。5.2 数学建模竞赛把运气变成流程数学建模是技能的高价值场景因为它时间紧、步骤多、评判标准相对固定。你搜“华为杯建模比赛好用的codex skills”本质上大家要的是一套能把“读题-建模-求解-写论文”串起来的流程控制而不是一个能解所有题的神器。我的设计是把建模拆成独立技能审题与假设、模型库检索、代码生成、结果验证、论文草稿。各技能之间靠产物衔接比如审题技能的输出是一份“要点清单”代码生成技能只认这个清单。用Codex这类工具时它每次处理一个环节不会因为一次任务过重而中途跑偏。5.3 AI漫剧内容创作者的技能思路AI漫剧现在很火但做好其实很繁琐剧本分镜、角色一致性、提示词批次生成、剪辑脚本。这里面“角色一致性”最适合做成skill因为它是标准固定、重复度高的流程。你可以在技能里让AI先提取角色的核心特征描述再把特征固化成每次生图都要携带的“锚点”而不是靠记忆力。我试着帮一位做漫剧的朋友写了这个技能正文里给了三段不同风格的角色描述模板并要求模型在每个镜头提示词里保留特征锚点。跑完几集后他反馈角色漂移问题改善了很多。这给我的启发是任何重复性的内容生产流程都值得用技能的思路重做一遍。5.4 技能网页版与其他工具的适配最近还看到有人问“skills网页版入口”这类需求多半是希望不用命令行也能管理技能。市面上陆续出现了一些视觉化管理工具能画出技能目录并上传新内容。但我提醒一句网页版通常只是帮你管理文件会不会被模型正常加载最终还是要看这套工具生成的目录结构是否符合目标工具的规范。用这类工具时我建议先用一个测试skill跑通再批量导入。6. 技能越多越好吗清理与维护才是稳定使用的前提6.1 什么时候该清理skill库技能堆积到一定数量后会反过来拖慢判断。模型每次根据description做筛选技能越多误匹配概率越高。特别是描述写得含糊的技能经常在不对的场景冒出来干扰主任务。我的经验是如果某个技能连续一个月没被触发过就从当前目录移走如果连续三个月没被触发基本可以删除源文件了。有个更轻量的办法把技能分成“常驻”“按需”“归档”三级只有常驻技能留在默认目录里按需技能的说明写进一个“可用技能列表”文档归档技能丢到单独目录。这样既不影响可用性又能减少Agent的决策噪音。6.2 更新与版本管理技能同样需要版本管理。你在开发期可以放肆改一旦用进真实项目建议每个技能目录里放一个CHANGELOG.md记录每次改动。这看起来多余但当技能的行为直接影响代码正确性时回滚的需求就非常现实。我用Git管理技能库的时候会刻意把“行为变化”和“描述变化”分成两次提交。这样一来哪次提交导致AI触发时机变了一查便知。我见过很多团队技能挂了却不清楚原因最后查出来是有人顺手改了description里的关键词导致触发条件大变。6.3 技能清理的具体操作清理其实很简单核心就是“移出去而不是删掉”。先用TGrep或者编辑器直接查找技能目录里每个SKILL.md的description关键词建立一张“技能行为清单”再照着清单做二次筛选比纯粹凭记忆判断靠谱得多。删除/移动之后记得跑一次“技能自检”开个新会话让AI列出当前可识别出的全部技能并对照你期望保留的清单确认没有多也没漏。这一步能及时发现那些description遗漏导致的“幽灵技能”——文件还存在但模型永远不加载它或者反过来总在错误时机加载它。对清理有顾虑的朋友可以放心技能不像代码不会因为移除就影响旧项目运行。它只影响未来对话里的行为所以大胆做减法留着干净目录等于减少Agent每次思考时的认知负担。最后说点实际操作中的体会从最初看到“skills”以为又是某个营销术语到如今把它当成自己工作流的核心模块我最大的感受是技能的本质不是“教AI做事”而是“让AI按你的标准做事”。那些效果稳定的技能往往不是写得最复杂的而是把一件事的边界画得清清楚楚的。所以如果你现在正要开始接触技能体系别先急着囤仓库先挑一个你每周都会做的重复性任务写一个极小的SKILL.md装进去用一周再迭代。这条路比看几十份推荐清单都有效。