如果你也经历过这样的对话——让AI写一个登录表单先解释校验规则再补一句UI风格最后还得加一条错误提示文案要友好一点换到下一个项目同样的内容又要从头讲一遍——那你大概率已经听说过skills这个词了。Claude Code、Cline、OpenCode甚至Codex都在往这套机制上靠最近数学建模群和前端群里讨论得尤其热闹从skills推荐到技能库网址再到手动装GitHub上的skills热度明显不是一两天的趋势。这篇文章是我这段时间把skills从零玩到能稳定产出的实操记录。干货集中在六个方向skills到底算什么、怎么从GitHub手动安装、怎么写自己的SKILL.md、哪些技能包值得收藏、数学建模/前端/AI漫剧这些场景怎么选技能以及最后怎么清理和维护技能库。老读者都知道我写东西不爱绕弯子原理会讲但一定配合能直接抄的步骤和踩坑记录这篇文章也一样。1. skills不是插件也不是提示词它是一份给AI的岗位操作手册先说结论skills最准确的定位是AI可自主读取的结构化操作手册。它不是一段每次要手动粘贴的提示词模板也不是需要写代码的插件扩展而是一整套以SKILL.md文件为核心、可以携带脚本和参考资料的能力包。AI在对话里根据你话中的触发点自动匹配技能、读取里面的完整说明然后按说明一步步执行。为什么这套东西偏偏在最近火起来核心原因是模型的上下文窗口和Agent能力都到位了。早几年你给AI塞一份5000字的操作手册它读到后面早就忘了前面现在上下文动不动几十万tokenAI完全可以自己打开一个目录、读完说明、照着做事。于是把老师傅的方法论交给AI按步骤执行这件事第一次变得技术可行且成本极低。1.1 为什么是现在上下文变长后方法的传递方式变了换个角度理解以前我们跟AI协作的方式是口头交代每次都要把领域知识、约束条件、输出格式从头说一遍。上下文窗口变大之后交互方式变成了让它自己去读资料。skills正好卡在这个位置上——它不是存放在你的记忆里而是存放在项目目录或全局配置里AI发现当前任务匹配某条技能描述时会主动去读SKILL.md再结合当前对话完成任务。这和多轮对话里不停追加要求有本质区别。追加要求是瞬时记忆这一轮有效下一轮就丢skills是长期记忆写在文件里下一次对话依然有效。我在团队里推广skills时用的比喻是以前你是带实习生每天重复交代流程现在你给每个实习生发一本岗位手册AI就是那个愿意每次开工前先把手册从头翻一遍的实习生。1.2 和插件、MCP、提示词模板的区别很多人把skills和插件、MCP、提示词模板混在一起聊但它们解决的问题完全不同我整理了一个对照表形态本质改造成本最佳适用场景传统插件代码级扩展高需要写程序深度集成编辑器或底层工具MCP外部工具协议中需要服务端配置实时数据获取、外部系统操作提示词模板一段静态文本低但每次要手动粘贴一次性任务、临时需求skill结构化技能包低纯Markdown可维护固定场景、反复出现的稳定方法论MCP和skills是最容易被搞混的两个。简单区分MCP解决的是AI能调用什么工具比如读数据库、操作浏览器skills解决的是AI在某个任务里应该用什么样的流程和标准来思考比如数学建模里拿到赛题先做什么、再做什么。两者可以配合skill里完全可以写建模前先用数据分析MCP工具读一遍数据统计特征。1.3 一个真实例子从每次强调到一句话触发我在前端项目里最常用的一条技能是表单生成。以前让Claude Code做一个注册页要在提示词里写清楚用户名规则、密码强度、手机号格式、校验时机、错误提示的文案风格有时候还得补一句不要用alert用我们组件库里的Message。写完这条功能下一次做订单表单以上内容原样再来一遍。后来我把这些沉淀成一条名叫register-form-checker的skill里面写好了字段校验的常见规则、组件库的错误提示用法、以及一个登录表单的完整示例。从此只需说一句新增一个带手机号和密码的表单AI就会自动加载这条技能按既定流程输出。省下来的不是那一两分钟而是每次沟通质量的波动——提示词写详细点输出质量就高写粗略点AI就自由发挥。技能把这个问题彻底消灭了。2. 从GitHub手动安装skillsClaude Code与Cline的完整操作很多人一听到手动装GitHub上的skills就觉得麻烦其实流程比装插件还简单。因为skill本质上就是一个包含SKILL.md的文件夹所谓安装就是把这个文件夹放到工具认得到的目录里。下面以Claude Code为主Cline和OpenCode思路一样但目录约定略有差异。2.1 装之前先搞清楚三件事第一确认目标skill的目录结构。一个合格的skill仓库通常长这样some-skill/ ├── SKILL.md ├── reference/ # 参考资料、示例代码 └── scripts/ # 可选的辅助脚本有的仓库根目录就是SKILL.md有的是一个仓库里塞了好几个技能。安装前先搞清楚你要装的是整个仓库还是其中一个子目录。第二决定装到哪里。Claude Code有全局和项目级两个位置全局技能放在~/.claude/skills/所有项目都能用项目级技能放在项目根目录的.claude/skills/只对当前项目生效。需要团队共享的技能走项目级自己的通用提效技能走全局。第三检查SKILL.md的YAML头是否完整。至少要包含name和description两项description写得好不好直接决定技能能不能被正确触发。有些仓库的description写得非常宽泛装完发现怎么叫都不触发这种后面我会讲怎么改。2.2 以Claude Code为例完整安装步骤手动安装的本质就是把技能文件夹放到正确位置全程在终端执行不涉及图形界面。我的流程是# 1. 创建全局技能目录如果不存在 mkdir -p ~/.claude/skills # 2. 把仓库克隆到临时目录 git clone https://github.com/xxx/some-skill-repo.git /tmp/some-skill-repo # 3. 把目标技能文件夹复制到技能目录 cp -r /tmp/some-skill-repo/some-skill ~/.claude/skills/some-skill # 4. 验证安装结果 cat ~/.claude/skills/some-skill/SKILL.md如果你只想装仓库里的某一个技能子目录第三步是关键只复制那个子目录而不是整个仓库。装完之后重启Claude Code然后在对话里用接近skill描述的说法描述任务正常情况下AI会自动加载。项目级安装同理只要把第三步的目标目录换成项目根目录下的.claude/skills/即可。我的习惯是新技能先在项目级试用一周稳定后再提升到全局目录避免一个不成熟的技能污染所有项目。这种的做法后期维护成本最低。2.3 Cline与OpenCode的相似思路Cline和OpenCode近年也都跟进了SKILL.md格式。Cline的Skills功能需要在设置里先开启技能目录通常放在项目的.cline/skills/下或者通过设置面板指定全局技能文件夹。OpenCode的社区实现一般遵循~/.config/opencode/skills或项目.opencode/skills的约定。我并不建议死记这些路径理由很简单这些工具都在快速迭代目录约定说改就改。正确的做法是去翻官方文档里的Skills章节以文档写明的路径为准。你只需要理解安装的本质是把SKILL.md所在的文件夹放进工具的识别范围内路径变了看一眼文档就能跟上。2.4 手动安装时最容易踩的四个坑按我帮别人排查问题的经验下面这几个坑占了九成第一个坑是复制层级出错。很多人clone下来之后直接执行cp -r repo ~/.claude/skills/结果技能目录变成了~/.claude/skills/repo/SKILL.md工具根本识别不到。正确做法是确保SKILL.md的上一级目录就是技能目录~/.claude/skills/some-skill/SKILL.md。第二个坑是frontmatter没写对。SKILL.md开头必须有---包裹的YAMLname不能带空格description不能为空。我用过一个技能因为name里带了空格工具始终识别为无效目录去掉空格立刻正常。第三个坑是description写得太泛。比如description写处理文件那AI几乎在所有任务里都可能触发它白白吃掉上下文。description要精确到场景和触发词这部分我会在下一节展开讲。第四个坑是权限问题。Windows用户尤其容易在复制文件夹时遇到只读属性导致AI无法读取或修改技能内的脚本。复制完顺手执行一次chmod -R r或者右键检查只读属性能省掉不少排查时间。3. 自己动手写一条skills格式拆解、写作顺序与实践避坑会装技能不算真本事能写出让自己和团队效率翻倍的技能才是这套东西的核心价值。别怕规范复杂SKILL.md就是一份带固定头部的Markdown文档半小时能学会。3.1 第一步是写description不是写步骤我的顺序和大多数人相反先写description再写步骤最后补示例。原因是description决定了你的技能什么时候被触发step写再好触发不了就全是白搭。description不是功能简介而是触发条件说明书。我用过一个失败案例description写的是帮助用户进行代码审查结果我让人家看一下这段代码有没有问题时技能触发了让人家评估一下这个功能的风险时也触发了甚至有时候闲聊都会被它劫持。问题就出在触发条件太宽。后来我改成这样当用户要求进行代码审查、评审Pull Request、或检查合并请求中的并发安全/错误处理/SQL注入风险时使用。其他普通代码提问不要使用。效果立刻改善。核心经验是把会触发它的场景列进去把不该触发的场景明确排除。3.2 一个可以直接抄的SKILL.md模板下面是我常用的模板结构上保留最核心的四个部分触发信息、背景、步骤、规则。--- name: math-model-proposal description: 当用户给出数学建模赛题、需要拆分问题并建立初步模型框架时使用。适合国赛、华为杯等建模竞赛场景。若用户只是问某个模型的概念不要使用本技能。 --- # 数学建模问题拆解与建模方案 ## 背景 本技能用于在拿到建模题目后快速产出问题拆解、建模思路和求解计划的初稿。 ## 步骤 1. 通读题目提取背景、数据、需要预测或决策的目标。 2. 输出问题拆解每个子问题标注数据类型和难度。 3. 对每个子问题推荐候选模型写明推荐理由和适用前提。 4. 检查数据是否满足模型假设不满足的给出预处理建议。 5. 输出建模求解工作计划包含里程碑和时间点。 ## 规则 - 每个模型必须写明至少一个适用的前提条件。 - 不编造数据缺失数据用[缺]标注。 - 输出格式为Markdown包含一个表格汇总模型清单。 ## 示例 输入: 预测某城市未来一周共享单车需求量 输出: 问题拆解 → 时间序列/回归模型候选 → 数据粒度检查 → 工作计划注意几个细节步骤要可执行每步都有明确输入输出规则里写的是硬约束相当于给AI划了红线示例不需要很完整够说明输入→输出的走向即可。3.3 让技能从能跑到好用的三个细节第一个细节是给步骤加验收标准。比如输出问题拆解这一步可以补一句每个拆解出的子问题必须包含数据类型、规模、与目标的关系三个信息。验收标准让AI不再敷衍让输出质量可控。我以前写的技能步骤只有一句话AI执行起来千奇百怪后来我学乖了每步都要能自检。第二个细节是把判断条件显式写出来。比如数据量小于100条且特征维度低于10时优先考虑统计模型而不是深度学习模型这类条件本质上是在帮AI把隐性的专家经验变成显性规则。模型不知道什么时候该用什么算法你要在技能里替它把决策树画清楚文字描述清楚不是真正画图。第三个细节是擅用reference目录。SKILL.md正文不用写太长把完整的案例、代码、规范文档丢进reference或scripts目录在正文里指引AI遇到X情况时去读reference/xx.md。这样技能保持轻量需要深度信息时又能调用完整资料。3.4 我写废过三条技能总结出的写作顺序最开始我习惯一次性写一大份技能文档写完发现逻辑混乱不是步骤缺东西就是规则和示例对不上。后来调整成四步走先列任务清单把自己实际做这类任务时的动作按顺序写下来不用管格式。再标出判断点例如如果数据量超过10万行先做抽样这是技能里最值钱的部分。接着只写规则和红线防止AI做出不可逆操作或产出格式混乱。最后才动手写步骤和示例因为你已经知道每一步要什么输入和输出。这样写出来的技能文档顺序自然AI执行起来不会前后矛盾。我早期写废的大多都是倒过来先写了漂亮的步骤发现卡在判断条件和规则上最后只能推倒重来。4. 哪些skills值得装官方示例、社区合集与筛选标准现在GitHub上打着AI skills旗号的仓库非常多从官方的演示技能到个人分享的领域技能应有尽有。但装得多不等于用得好我在第6节会讲清理问题这里先给出来源和筛选方法论。4.1 值得收藏的几类来源第一类是官方示例仓库。Anthropic在GitHub上有一个skills的官方示例集里面涵盖PDF处理、文档生成、SVG设计等基础技能非常适合用来理解SKILL.md的规范写法。这类仓库的价值不在多好用而在这是标准答案遇到格式疑问直接用它们对照。第二类是社区合集型仓库。GitHub上搜索awesome ai skills或者工具名skills能翻到不少整理好的技能合集。比如社区里流传较广的superpowers技能包把很多实用技能打包在一起适合愿意花时间研究原理的进阶玩家。需要注意的是合集型仓库里的技能质量参差不齐我通常只在里面挑单条迁移到自己仓库而不是整体引入。第三类是具体工具的skills市场或插件面板。Claude Code、Cline等工具的市场面板上能按热度排序看技能带下载量、更新时间和用户评价。相比GitHub面板上的技能经过一轮筛选踩坑概率低一些。第四类是技术博客和实战分享里贴出的单条技能。很多博主会在文章末尾附上自己常用的SKILL.md全文这类往往带着真实的场景理解质量常常高于仓库里的万能模板。4.2 筛选skill时的五个检查点我下载任何技能前会过五道检查全部过关才值得装description是否足够具体会不会和已有的技能冲突步骤是否带判断条件和验收标准还是只有笼统的分析数据生成报告是否依赖外部脚本或API依赖项的维护成本你能否承受最近更新时间是什么时候半年以上没更新的技能大概率跟不上模型能力变化。目录结构是否规范SKILL.md是否在技能文件夹的根目录拿这五条去筛能过滤掉至少一半的搬运式技能。社区里很多合集把几年前的提示词模板套个壳就叫skill装进去用起来还不如自己重新写。4.3 我目前的技能库配置组合我自己的技能库保持在15条左右按使用频率分成三层基础层文件整理、Markdown规范检查、代码错误分析。这三条几乎每天都在用比如整理这个文件夹里的临时文件会自动触发文件整理技能。场景层前端表单生成、API对接、数学建模论文结构器、AI漫剧分镜脚本。这一层对应我不同阶段的主要工作内容做完一个项目会淘汰掉一批。实验层新发现值得试的技能先装进来跑一周。实验层技能不放在全局目录而是放在特定项目的.claude/skills/下验证稳定后再提升。强烈不建议一次性装几十条技能。模型是根据description来决定是否加载的装太多只会让它的选择越来越随机上下文也被无效尝试吃干净。5. 按场景组合skills数学建模、前端开发与AI漫剧不同领域对skill的需求差异非常大。我挑了近期讨论热度最高的三个场景展开分别是数学建模竞赛、前端开发和AI漫剧内容创作每个场景都给出组合思路和推荐方向。5.1 数学建模与竞赛场景让整个流程都有章法数学建模竞赛包括国赛、华为杯这类赛事特别适合用skills因为参赛流程高度标准化读题拆解、数据清洗、模型选择、求解验证、论文写作每一步都可以沉淀成单独技能。我在备赛项目里配过一条组合拳。第一条是赛题拆解负责把题目转成问题清单标注数据特征和约束条件第二条是数据预处理专门处理缺失值、异常值、归一化这些脏活第三条是模型推荐根据问题类型、数据规模给出候选模型列表并解释理由最后一条是建模论文结构器按标准格式生成论文章节骨架省去排版初稿的时间。用下来的体会是建模赛场上真正耗时间的不是算法而是把问题拆清楚和把结果写清楚。前面两条技能负责前者最后一条负责后者。至于中间调包求解的部分靠模型本身的能力就足够不用刻意做成技能。有人会问Codex这类工具里的skills在建模场景能不能直接用答案是能但需要按比赛流程重写一遍适合赛题的技能。从GitHub下载的通用数学技能通常偏学术直接套进竞赛场景会发现缺了论文写作结果可视化这些比赛刚需模块。5.2 前端开发场景把重复沟通固化成技能前端大概是skills受益最明显的领域因为UI开发里的重复感极强。一个项目中要写十几个表单页面模型每次都要重新理解校验规则、组件库风格、错误提示语法而这些都是可以在技能里固定下来的。我配的前端技能组合是表单生成、API接口对接包含错误处理约定、组件样式规范化、可访问性检查。表单生成技能里我会注明电话号校验使用正则xx错误提示统一用组件库的Message模式API对接技能里会写明接口错误码分类处理规则。比较反直觉的一点是前端skills的价值不在于帮忙写代码而在于统一代码之外的口径。团队里两名开发者用同一个技能生成表单产出的代码风格一致Code Review成本直线下降。如果只是自己一个人开发技能的价值反而没那么大——你本来就知道自己要什么但是团队协作时技能就是团队规范的可执行版本。5.3 AI漫剧与内容创作稳定才是第一位的AI漫剧这类内容创作场景最大的痛点是角色一致性和分镜统一性。同一角色在第五集和第一集长得不一样观众立刻出戏。skills在这里扮演的是创意流水线的质检员角色。针对漫剧我会把技能拆成角色设定卡生成、分镜脚本生成、场景描述规范三个技能。角色设定卡技能负责在每次生成角色图时强制输出包含外貌特征的完整描述串保证后续生成沿用同一套描述分镜脚本技能负责把剧本切分成可生成的分镜表格标注情感动作和景别场景描述规范则统一了场景的环境词和视角词。内容创作类技能的写作风格和编程类有明显区别。编程技能里的规则可以写禁止修改xxx文件内容创作技能里的规则要写必须保持XX角色的语气一致不得在没有明确场景描述时生成空镜。前者约束行为后者约束风格。这类技能的description尤其要写清边界否则你让AI想个分镜它可能把整个漫剧的角色设定都给你吐出来。5.4 组合策略小技能拼流水线而不是追求万能包三个场景讲下来你会发现我的思路始终是把一条完整的生产流程拆成多个单点技能用几条技能拼成流水线而不是用一个万能包解决所有问题。万能包的问题在于它内部塞了大量判断逻辑AI在加载时很难判断该按哪条路径执行结果往往是谁的description更靠前谁就被执行资源的浪费比效率提升更明显。相比之下小技能各管一段description边界清晰AI可以在不同任务阶段加载不同技能组合出来非常灵活。我建议每个场景控制在四到六条技能。多了加载判断会乱少了覆盖不全总会回到手写提示词的老路上去。6. 技能库的清理、升级与版本管理避免越装越乱最后聊一个很多人忽略的问题技能库的维护。装技能一时爽装完之后如果不管技能库会越来越乱最终变成一个新的负担。社区里关于清理skills的最佳方法一直有讨论我自己也折腾过好几轮下面是沉淀下来的流程。6.1 出现这些迹象就该清理了最明显的信号是同一类任务AI开始触发错误的技能或者一条技能明明没有匹配AI却强行调用。这通常意味着多个技能的description存在重叠区域模型判断不准了。第二个信号是加载速度变慢。技能目录里文件太多每次对话AI都要扫描一遍description列表虽然扫描速度本身不慢但模型在选择时花在校验上的token量是实打实的。第三个信号是你发现自己手动补充提示词的频率越来越高。这说明现役技能已经偏离你的实际需求或者任务流程变了旧技能跟不上新流程。6.2 一套可复用的清理流程我的清理流程很简单三个命令加一次Review# 列出所有已安装的技能 find ~/.claude/skills -maxdepth 2 -name SKILL.md | sort # 看每个技能的大小找出异常膨胀的 du -sh ~/.claude/skills/*/ | sort -h # 把不用的技能移到归档目录不是直接删除 mkdir -p ~/archive-skills mv ~/.claude/skills/unused-skill ~/archive-skills/用移到归档目录而不是删除是我踩过坑之后养成的习惯。有一次我把一条旧的数据清洗技能直接删了半个月后新项目需要类似功能想找回来已经来不及。归档目录会保留技能的完整历史确认真的用不上后再批量清空也不迟。每季度我会留出半小时做一次技能Review对着技能清单问自己三个问题最近一个月有没有触发过如果没触发过是场景没遇到还是description写得不到位这个技能下次使用还需要调整什么Review完再决定升级还是归档。6.3 用Git管理整个技能库的进阶玩法技能本质上就是文本文件天然适合用Git管理。我会把所有的技能收进一个独立仓库然后在工具的技能目录里用软链接指过去# 初始化技能仓库 mkdir ~/my-skills cd ~/my-skills git init # 在技能目录里建立软链接 ln -sfn ~/my-skills/frontend-form ~/.claude/skills/frontend-form这样做的收益非常大。技能的每一次改动都有记录改坏了可以直接回滚换了新电脑clone一下仓库再重新建软链接十分钟恢复整套工作环境团队协作时直接把技能仓库作为共享库所有人技能版本一致。升级技能方面我建议谨慎使用git pull直接覆盖。如果Skill来自第三方仓库你先做过本地修改pull之后可能会冲突。我的习惯是先把本地修改提交到一个私有分支再合并上游更新解决冲突时能清楚地看到哪些是自己改的内容。6.4 社区清理思路和我的改良之前看社区里有人分享过一套清理思路核心主张是先禁用、后删除、定期评审。禁用的意思是把技能目录移出工具识别范围但保留文件定期评审是每月检查一次技能使用率。这套思路的优点是稳妥缺点是比较被动只清理了从来不用的技能没解决description互相打架的问题。我在这个基础上做了两点改良。第一点是动手改description而不是直接禁用。两个技能触发冲突时先看是不是描述语句太宽泛把边界写清楚往往能解决冲突而不用整个技能下线。第二点是建立技能使用日志每次AI实际加载了某条技能就在对话记录里看得到。季度Review时不是靠回忆而是翻日志统计用数据决定保留还是归档。这轮折腾下来我的技能库从顶峰时期的40多条降到了现在稳定的15条左右但效率反而提高了不少。与其说是清理技能的功劳不如说是想清楚了一件事技能的价值从来不在于数量而在于它是否精确覆盖你反复遇到的场景。我现在换新电脑时只需要clone自己的技能仓库再重建软链以前那些我好像装过这个功能但找不到的尴尬一次都没再出现过。如果你也开始积累自己的技能库我建议从今天起就用Git管理起来——这是唯一一个我从第一天开始做、至今没后悔过的决定。