最近一段时间我身边的同事、社群里的朋友几乎都在折腾同一样东西AI编程工具里的skills。Claude Code装完你大概率会被建议去配几个skillsCodex、opencode这类工具也在跟进就连做数学建模比赛、AI漫剧创作的同学都在问“哪几个skills最好用”“GitHub上的skills怎么手动装”。如果你也正处于“听说了很久、但还没真正用起来”的状态这篇文章应该能把最关键的问题讲清楚skills到底是什么以及装好了它之后你的工具使用体验会发生什么变化。我用了一个多月把几十个skills翻来覆去地装、用、删也从一开始只会复制别人配置的纯新手变成现在能按自己的需求写SKILL.md。整个过程里踩的坑不少但收获更大。下面是我觉得最值得沉淀下来的内容从原理讲到手动安装、从推荐清单到自研模板一步步来。1. 先搞懂skills和普通prompt的差别这决定了你会不会用1.1 一句话解释skills把老手干活的方式固化下来先说最直观的理解。skills本质上不是一个插件也不是一个独立运行的程序它是一套给AI模型看的“工作手册”正式点说就是“系统级提示词示例流程约束”的集合体。举个例子你让AI给你写一个React组件。裸用prompt模型的反应是“你让我写我就按我脑子里常见的方式写”结果经常是能用但不符合你项目里的规范没有测试、没有类型定义、文档风格也对不上。而你装了一个“前端组件生成skill”之后模型在接到“写一个Button组件”这个请求时会被skill里的说明引导着做三件事先看项目里的组件规范再按规范生成包含类型定义和测试的完整文件最后按项目模板输出文档。整个过程像不像一个刚入职的新人突然拿到了一本老员工写的《从需求到上线的标准操作手册》这就是skills的核心价值。所以千万别把skills和普通prompt关键词混为一谈。普通prompt是“一次性请求”而skill是“一次定义、多次复用的整套方法论”。当你把某个领域的全部know-how写进SKILL.md再让AI在需要的时候主动加载它这个AI就从一个“什么都会一点的通才”变成了某个岗位上的“熟练工”。1.2 skills、prompt和MCP三者的边界在哪里很多人把skills和MCP搞混我在刚开始用的时候也没少闹笑话。这里用一张表格把它们的区别说清楚维度skills普通promptMCP工具调用协议本质结构化工作流程说明一次性指令能力接口是否常驻按需加载临时独立服务解决的问题怎么做做什么能做什么一个类比公司的SOP文档给下属派活时的口头交代水、电、网络等基础设施MCP相当于给AI接上了“手和脚”——比如让它能查数据库、发请求、操作文件skills则相当于给AI配了“大脑里的工作逻辑”——告诉它拿到工具之后按什么节奏做。两者配合起来效果最好但skills的准入门槛更低因为它本质上就是一个按特定格式写的Markdown文件不需要单独写服务器也不用处理什么鉴权协议。1.3 为什么说skill数量的质量基本等于你的AI生产力上限这里我想多说一句可能反直觉的话决定AI编程工具上限的不是模型版本新不新而是你给它配的技能体系全不全。同一个模型装上合适的skills之后在特定任务上的表现能拉开一个档次。比如“从设计稿还原页面”这个场景。没有skill时AI会老老实实给你写一堆看起来差不多、但细节经不起推敲的HTML/CSS有了一个包含常见设计系统、响应式断点、样式命名规范的skill之后它输出的代码审美和工程规范都会立刻在线。我自己感受最深的变化是“代码审查”这个任务手工让AI审查它总是蜻蜓点水好像什么都看了一遍又什么都没看装了一个专门做code review的skill后它会按架构、性能、可维护性、安全隐患几个维度逐项排查输出的问题清单比很多同事提的意见还细。1.4 SKILL.md内部到底长什么样所有skill的核心文件都叫SKILL.md一般长这样--- name: frontend-component-builder description: 根据需求生成生产级前端组件。当用户需要新建组件、还原设计稿、生成UI代码时优先使用本技能。 --- # 组件生成流程 1. 先确认技术栈与组件库。 2. 查阅项目中的样式规范与命名约定。 3. 输出TypeScript类型定义、组件实现、样式文件和单元测试。 4. 补充Props文档与使用示例。 ## 输出要求 - 组件必须包含类型注释。 - 测试必须覆盖正常状态和空状态。 - 禁止使用内联样式除非组件需要动态变量。文件头部用三根短横线包起来的部分是frontmattername字段是技能的唯一标识description字段极其重要因为AI就是靠读description里的描述来决定当前任务要不要调用这个skill。后面的正文部分就是给模型看的工作流程、约束和输出规范。理解了这一层结构后面手动安装和自研就都顺理成章了。2. 手动安装GitHub上的skills没有图形界面入口时最稳的路径2.1 安装前先确认工具认哪个目录不同工具对自己的skills目录约定不完全一样但基本都是固定路径安装前要心里有数。我整理了一份目前主流工具常用的目录位置你按自己用的工具对照一下工具默认skills目录说明Claude Code~/.claude/skills/用户级所有项目都可用Claude Code项目级项目目录/.claude/skills/仅当前项目生效Codex~/.codex/skills/规则遵循类似目录opencode~/.config/opencode/skills/配置文件路径下面如果你用的工具版本更新导致路径变了直接在官方文档里搜“skills directory”就能找到。装了多个AI编程工具的同学建议别偷懒每个工具的路径都单独建目录养成习惯后面管理不慌。2.2 手动安装的四个标准步骤以GitHub上最常见的skills仓库为例手动安装不需要什么特殊工具纯命令行操作。核心逻辑就是把skill文件下载下来放进对应的skills目录里。第一步先确认你已经登录了GitHub CLI或配置好了个人访问令牌。如果你之前从来没配过用下面的命令快速搞定登录gh auth login按提示选择浏览器授权或粘贴token看到Logged in as的字样就说明没问题。如果不方便用gh也可以手动复制整个仓库zip包再解压到目标目录同样可行。第二步进入你的目标skills目录把GitHub上那个仓库clone下来cd ~/.claude/skills git clone https://github.com/anthropics/skills.git这是我比较推荐的方式因为anthropics/skills这个仓库是官方维护的里面有大量示例级skill结构规范适合当“种子库”用。如果你想装的技能不在这个仓库里那就把URL换成对应的仓库地址。第三步处理“每个skill应该单独占一个目录”的问题。很多GitHub仓库是“一个仓库里装了十几个skills”但AI工具默认只会去skills文件夹的直接子目录里找SKILL.md。如果直接把整个仓库clone进skills目录可能会导致一堆技能没被识别。稳妥的做法是克隆之后进仓库里看看结构把单个skill的文件夹复制到~/.claude/skills/下cp -r ~/.claude/skills/anthropics-skills/skills/xxx-skill ~/.claude/skills/如果整个仓库本身就是单一的skill顶层直接是SKILL.md就不需要这步了。第四步验证目录结构。完事之后要看一眼ls ~/.claude/skills/正常应该看到形如skill-name/SKILL.md这样的结构每个skill一个独立文件夹里面有SKILL.md和配套的示例文件。2.3 装完后怎么验证真的生效了目录里有了文件不代表就一定能被AI自动识别。我自己的验证方法特别土但也特别有效重启一次工具会话然后用一句能触发该skill描述的话去问。举个例子如果装的skill描述里写的是“当用户需要设计数据库表结构时使用”那我就直接输入“帮我设计三张业务表的库表结构包含索引和关联关系”。如果工具在答复前自动加载了对应技能或者给出了明显带有该skill风格的输出比如遵循了里面的步骤要求就说明生效了。有的工具会显示“加载了xxx技能”之类的提示看到了基本就稳了。如果发现AI完全没提这个skill大概率是description写得不够明显或者目录位置放错了。重新调整描述第一句话或者把它挪到更标准的路径再试一次。2.4 卸载和清理要注意的事卸载skill其实没什么好纠结的直接删掉对应目录即可rm -rf ~/.claude/skills/某个不需要的skill但有两件事必须提醒。其一github仓库更新之后你本地clone的旧版本不会自己同步需要定期git pull。尤其是那些热门仓库作者更新很勤不同步就跟不上了。其二千万不要图省事用“整站同步脚本”一股脑把所有GitHub仓库都拉下来skills装太多之后AI每次调用都要在庞大的库里做匹配反而影响响应质量还可能在多个skill描述之间产生冲突。我的经验是精装5-8个核心领域技能效果远好于囤100个。3. 哪些skills值得优先装按使用场景挑别贪多3.1 前端开发组件生成与UI还原类这一块是GitHub上skills最多的赛道也是新手最容易“装了就后悔”的区域——因为很多skills写得很水只是把prompt换了个壳。真正好用的前端skill至少要包含三样东西项目技术栈说明、组件库规范、测试要求。比如让他生成组件时会主动问你是用Tailwind还是纯CSS会约束props必须带类型会自动套Storybook格式的文档。如果你主要用Claude Code或者Codex做前端页面优先找“react-component-generator”“frontend-craft”这类命名的skill。用的时候也有讲究别指望一个skill覆盖你所有场景“生成组件”和“设计稿转代码”最好拆开各管一摊。3.2 代码审查与安全扫描类第二个我非常推荐的方向是代码审查类。手动让AI审查代码最大的痛点是它“太客气”总是先说代码写得好然后象征性提几个小建议。好的review skill会强制AI按固定维度输出架构问题、性能风险、安全隐患、可维护性、测试覆盖每条给出具体行号和修改建议。装了这个以后你再让AI“review这段代码”出来的结果会专业得多基本可以直接当团队评审材料用。选择这类skill时优先看仓库里有没有现成的“输出模板”文件。有模板的skill通常说明作者真的思考过“如何让输出可执行”而不只是让AI自由发挥。3.3 数学建模与竞赛类为什么这类skill特别受学生欢迎最近“华为杯”“国赛”这些比赛季数学建模skills的需求量突然就上来了。我自己虽然不参赛但看社区里的讨论很有感触。数学建模赛题一般分三种类型偏物理机理的、偏数据分析的、偏优化决策的。对应的skill要解决的问题其实很明确如何把一道开放性赛题快速拆解成“问题重述、假设、符号说明、模型建立、求解、灵敏度分析、论文框架”这样的标准流程以及如何把整个思路用LaTeX格式输出。这类skill建议去GitHub搜索“math-modeling”或“MCM/ICM”关键词很多是往年参赛学生开源出来的里面通常还带着赛题模板和排版示例。但说句正经话——skill能帮你把论文框架和代码组织得更好不能替代你自己完成建模推导和实验验证。比赛要的是理解问题、亲手求解的能力AI只是帮手这个边界自己心里要有数。3.4 内容创作与AI漫剧类你可能会意外“AI漫剧”居然也是skills的高频使用场景。说白了做漫剧最头疼的不是“能不能生成一张图”而是角色一致性和分镜连贯性。没有skill的时候每次让AI生成都像在开盲盒配了专做漫剧脚本与分镜的skill后通常在目录里维护一份角色设定表、场景描述库、分镜模板SKILL.md则规定每次生成前先确认主人公外貌、服装、场景关键词然后再出图。如果你也是做创作内容的可以在skills库里搜索“comic-script”“storyboard”相关字眼。装完之后要有意识地往里面填充你自己的角色设定因为再好的skill也只是框架真正让角色“长在”项目里的是你喂给它的设定文件。3.5 数据处理与分析类最后一个高频方向是数据处理。写Python处理Excel、清洗csv、做透视表这些工作本身不复杂但每次都要从头梳理“数据里有什么缺失值、类型对不对、异常值怎么筛”总觉得很繁琐。一个成熟的数据分析skill会让AI先输出变量探查结果再和你确认清洗规则最后统一生成代码和可读图表。相当于给数据处理流程加了一层“先计划再动手”的缓冲分析质量会稳很多。4. 自己写一个skill其实不难按这套模板来十分钟搞定4.1 动手之前先想清楚你要固化的是一个什么流程很多人觉得写skill是件高级的事其实不然。我建议第一次尝试的人选一个自己日常工作里重复频率最高的任务最好是一个你已经形成固定方法的流程。比如“接到一个需求怎么拆任务、排优先级”就是一个很好的切入点。你越是熟悉这个流程就越容易写出能让AI照做的指令。如果把“写good skill”比作“教实习生干活”你就明白问题在哪了光说“认真一点”没用你得告诉实习生“先看什么再做什么什么情况下做什么什么情况下不做什么”。skill正文里这些东西写得越具体AI的表现越好。4.2 SKILL.md的骨架模板直接抄我实际用下来觉得最顺手的模板是这样--- name: task-splitter description: 将一段杂乱的需求描述拆解成可执行的任务清单。当用户需要规划、拆解需求、整理任务列表时优先使用本技能。 --- # 任务拆解流程 1. 读取用户输入区分“目标”“约束”“已有资源”三类信息。 2. 如果需求边界模糊先用最多三个问题向用户确认不要自行猜测。 3. 将目标拆成独立可交付的任务每个任务包含验收标准。 4. 按依赖关系排序标注可并行任务。 5. 输出Markdown清单包含优先级、预估顺序、依赖。 ## 场景示例 输入做一个登录页面 输出任务1-确认登录方式手机号/邮箱/第三方...记住三个关键点。第一name要短容易记忆。第二description前三行要写清触发条件AI靠它判断是否启用这个技能。第三正文里要有“步骤输出格式”不能让AI自由发挥否则skill就退化成普通prompt了。4.3 配套的示例文件与参考输出别省只有SKILL.md也能跑但效果会差很多因为模型缺少“好结果长什么样”的参照。所以我现在写skill习惯给每个skill建一个examples子目录里面放1-2个输入输出对。比如任务拆解skill的例子文件里我放了一段用户原始输入配一份拆好的任务清单AI看到之后就更容易模仿输出形式。结构大致这样task-splitter/ ├── SKILL.md ├── examples/ │ ├── input.md │ └── output.md这个方法对任何领域的skill都管用。AI模型本质上是“看到好例子才好办事”的给它喂一个具体的高质量输出胜过你在指令里解释一百句。4.4 写完调试的三个质量检查项写完之后别急着用先做一轮自查。我总结了三个质量标准指令够具体吗如果正文里充斥着“合理地规划”“高效地分析”这种形容词那就等于啥都没说。改成“先检查数据缺失值再确认字段类型最后输出三个独立表格”这种可执行动词。过程可迭代吗好的skill不会一步到底而是会在关键节点停下来和用户确认。写skill时主动留出“确认点”的位置比如“完成阶段一后向用户展示结果确认无误再继续”。输出可验证吗如果任务输出是代码、文档、表格就把格式要求写清楚。代码要有类型、文档要带目录、表格要说明字段来源。否则输出漂移问题会折磨你。我自己第一次写的“数据处理skill”就是因为输出格式写得不够死结果AI每次都给我吐不同风格的代码直到把输出规范细化到“函数名用下划线、dataframe输入、返回统计摘要”这种颗粒度才真正稳定下来。5. 维护与清理skills装多了之后踩过的坑5.1 用目录和命名建立你自己的“技能库”用了一阵子之后你会发现skills的维护其实和代码库管理很像。我现在的做法是建立了一个~/.claude/skills/大目录里面按领域分类建子目录每个skill自带README写上来源仓库地址、最后更新时间、用途说明。刚开始觉得这步多余但等你的skills数量过十几个之后没有备注绝对会认不出哪个是哪个。我还习惯用Git管理这个skills目录本身。如果有重要修改就提交一次版本记录这样哪天改坏了还能回滚。对非程序员朋友只要记住“把skill文件夹当成普通文件来备份管理”就完全够用了。5.2 GitHub仓库的时效性旧skill比没有skill更可怕这是我最想强调的一个点。AI工具迭代很快以前写出来的skill描述风格、文件结构新版本可能已经不完全匹配了。比如一些早期的skill还在用旧版的frontmatter字段新工具虽然能解析但触发效果会打折扣。建议每两周抽空检查一遍常用仓库的更新记录看到“breaking changes”提醒就及时看看说明。同时针对那些“超多star但长期没人维护”的仓库我现在的态度是直接不用。skill的价值在于它和当前工具的契合度仓库停在两年前里面写的流程很可能已经过时AI建模逻辑一变旧指令还会干扰新输出。清理掉它们比留着当心理安慰更有用。5.3 一个个人爱好给自己的常用工作流写一套“微技能”如果你已经把现有skills用顺手了我还有一个建议除了那些大而全的领域技能试着给自己的工作流写一些只有几十行的“微技能”。比如我给自己写了一个“消息回复快译”的micro skill规定任何领导发来模糊的“这事儿你再看看”一律先归类、再拆分、最后给出“已确认/待确认/需补充”三栏回复。这个skill不到三十行但每天帮我省下的心智成本比任何大skill都多。skills的价值不在于装得多、装得新奇而在于它是不是真的贴合你的高频工作场景。从官方仓库复制再从自己的重复劳动里提炼两条路同时走你很快就能配出一套属于自己的、高生产力的技能组合。