要说清楚一件事：最近半年，“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，装进去，用一周，再迭代。这条路比看几十份推荐清单都有效。
