最近逛 GitHub 的时候我发现收藏夹里多了一堆名字里带 skills 的仓库。Claude Code 怎么手动装 GitHub 上的 skills、Codex 里带数学建模技能的配置、就连做 AI 漫剧的朋友也在问常用 skills 有哪些——看起来各自聊的是不同工具但底子上都是同一件事AI 编程助手不再满足于“你问一句它答一句”而是想学会一套固定的工作方式再替你重复执行。我也算是从“手动装第一个 skills”一直折腾到“自己写 skill”的人踩过的坑加起来能写半篇事故报告。这篇文章就把 skills 的安装、选型、写法、排查一次性讲清楚不管你用的是 Claude Code、Codex 还是 opencode思路基本通用。第一次接触的话照着做就能跑通已经玩过几个的直接看我踩坑那部分。1. Skills 是什么为什么突然大家都在聊1.1 一个文件夹就是一套本事Skills 这个词在 AI 编程工具里没有想象中神秘。我第一次去翻 GitHub 上的 skills 仓库发现大多数就是一个普通的文件夹里面有SKILL.md、几个模板、可能还带几个示例文件。SKILL.md是这个技能包的入口用 Markdown 写清楚“这个技能负责什么、应该按什么流程做、有哪些硬性要求”AI 在对话中会根据描述自动决定要不要加载它。放到生活里类比普通提示词像你在路边找电工“帮我看下这个插座”而一个 skill 像电工随身带的工具箱里面有验电笔、剥线钳、绝缘胶带还有一张施工流程图。你在对话里临时描述需求AI 只能靠上下文猜你把一套完整任务写进 skill它就可以按固定步骤执行减少遗忘和自由发挥。用 Claude Code 举例技能包通常放在.claude/skills目录下。项目根目录的.claude/skills只对当前项目生效用户目录下的~/.claude/skills是全局技能所有项目都能用。其他 agent 工具没有百分之百统一的目录但设计思路一样放对位置、读到入口文件、按里面的规则干活。1.2 为什么 skills 比普通 Prompt 好用很多人问“为什么不用每轮对话把要求重复一遍”。答案在于稳定性和复用性。用普通 prompt你每次都要重新描述需求AI 一旦聊到后面很可能把前面 20 条规则忘得差不多。skill 把这些规则固化成一个可版本管理、可分享、可组合的模块。另外好的 skills 往往不只是文字说明还会带上参考示例比如一个前端 review skill 会包含“常见性能问题检查表”或“组件命名规范”。AI 读到的不是抽象口号而是可以对照执行的样例。这种带样例的技能包效果通常比“请仔细检查代码”好一个量级。从工程视角看它还解决了另一个麻烦团队协作时不用把规范写在 wiki 里等成员自觉。把一个 skill 放进项目目录团队每个人跑 AI 时拿到的都是同一套规则。代码审查、提交信息、测试标准都可以沉淀成 skill。1.3 哪几类人最该折腾 skills至少有三类人我从身边实证里看到收益。第一类是前端开发。前端项目里重复劳动非常多改组件、调样式、写测试、整理 commit message。把代码规范做成 skill 之后AI 生成的组件一开始就符合团队的 TypeScript 风格和 CSS 约束review 阶段少吵很多架。第二类是参加数模竞赛的学生。像华为杯这类比赛时间紧、报告要求格式统一、数据量大。用 Codex 或 Claude Code 配一个建模报告 skill能让 AI 自动按 LaTeX 模板组织章节、生成图表、输出数据分析结果省下来的时间可以用来打磨模型。第三类是 AI 漫剧创作者。很多团队做 AI 漫剧时最头疼的是角色一致性。你可以把角色设定、场景描述、分镜规范写进一个 skill让 AI 在生成每一步时都沿用同一套角色卡减少“上一张是黑发这一张变黄发”的翻车。不想被分类的普通开发者同样能从简单技能里受益。比如我自己写了一个“新项目初始化”skill每次开新仓库就让它按我的习惯装依赖、建目录、写 README省掉大量重复配置。2. 手动安装 GitHub 上的 skills2.1 为什么需要手动安装很多人问“Claude Code 怎么手动装 GitHub 上的 skills”。其实核心原因很现实很多仓库还没有进入官方集中市场或者官方市场的版本更新慢你想要的技能包只能从 GitHub 直接拉。还有一部分人想改细节手动安装之后可以随时改文件比在工具里点来点去更可控。我看到有人提到“skills 网页版进入”以为有个在线入口能同步技能实际上多数情况只是工具的网页控制台帮你做文件管理。底层还是那几个文件。所以我一直建议直接用命令行下载和复制这样路径清晰出问题也好排查。需要下载时不需要专门找什么“skills 下载”按钮正常git clone或者下载 zip 压缩包就行。技能包本身就是普通目录不是需要注册的闭源插件。2.2 手动安装的完整步骤以 Claude Code 为例我给出一个能跑通的流程。假设你想装一个 GitHub 上的技能包仓库名字叫awesome-ai-skills里面有一个技能叫code-reviewer。第一步进入你存放技能的目录。全局技能放在用户目录下mkdir -p ~/.claude/skills cd ~/.claude/skills第二步把仓库拉下来。我更推荐先拉到临时目录再单独复制需要的技能避免把别人的一整个仓库都塞进 skills 目录。git clone https://github.com/yourname/awesome-ai-skills.git /tmp/awesome-ai-skills cp -r /tmp/awesome-ai-skills/code-reviewer ~/.claude/skills/如果只想用项目级技能就放到当前仓库的.claude/skills下mkdir -p .claude/skills cp -r /tmp/awesome-ai-skills/code-reviewer .claude/skills/第三步不一定要重启客户端但一定要重开会话。接着在对话里问一句“列出当前可用的 skills”能看到code-reviewer就说明装进去了。Claude Code 的工具面板通常也能看到技能入口只是不同版本略有差异。Codex 或 opencode 的目录名可能不同但道理一样。你找到工具约定的技能目录把文件夹放进去就行。如果配置里扫描的是commands目录那就放进 commands。提示复制技能包之前先看仓库 README。有些技能会带依赖脚本不装依赖直接跑可能各种报错。2.3 全局还是项目级全局和项目级的选择不是随意的。存放位置作用范围适合场景~/.claude/skills当前用户的所有项目个人习惯、通用规范.claude/skills项目根目录该仓库内团队协作、项目专属流程如果同名技能同时存在以项目级为准的情况居多。我个人的习惯是主题技能全放项目里避免污染其他仓库那些“写 commit message”“代码 review”之类每个项目都通用的放全局。另外提醒一句GitHub 上不少合集仓库会带依赖文件比如需要某个 Python 脚本或者特定的模型配置。安装前先看 README别直接复制整个目录后再对着报错发懵。3. 常用 skills 推荐与场景选型3.1 前端开发 skills 怎么选前端开发场景里我推荐优先装三类技能。一是代码 review 技能它会按 React/Vue 常见问题清单核查 props、事件绑定、副作用二是组件生成技能让它按团队现有组件库规范生成代码三是样式一致性技能专门管理 design token、间距、颜色变量。我装过最实用的一个前端 skill会在生成组件时自动附带上基础的 accessibility 检查。它不会等我在 prompt 里提醒而是因为描述里写了“所有 JSX 必须包含可访问性属性”这类强制规则。实测下来给 AI 的生成结果做二次修改的工作量明显减少。还有一个许多人忽略的点前端 skill 里最好带上项目自己的代码片段。不要只写“请遵循团队规范”而放两份真实的示例文件。AI 看到reference/button.tsx后生成的代码风格会更接近你的项目而不是泛泛的“规范”。3.2 数学建模和竞赛类的 skills 推荐在知乎、GitHub 上搜“数学建模 skills 推荐”能看到很多现成技能包。它们覆盖的通常是三块数据清洗、模型选择、论文排版。以华为杯这类比赛为例最值钱的其实不是“让它猜模型”而是把报告流程固定下来。比赛时间有限写论文很占时间。一个建模报告 skill 可以这么做读取数据后先输出缺失值统计再用固定模板生成图表最后把结论写入 LaTeX 指定章节。AI 不是从零开始“写一篇论文”而是沿着章节切片一块一块补内容格式和逻辑不容易跑偏。如果你用 Codex 参赛需要注意它和 Claude Code 对技能目录的处理方式可能不一样。我的建议是不要依赖某一个现成的“华为杯技能”而是自己写一个轻量的报告 skill再把当题的数据说明、评分细则作为参考文件塞进去。这样比通用技能更能对准题目要求。另外建模技能里强烈建议放一个“版本说明”文件。因为比赛过程会不断改假设、改参数如果 skill 强制 AI 先读一眼当前版本再决定下一步动作最后报表里的模型口径不会前后矛盾。3.3 AI 漫剧和创意生产场景做 AI 漫剧的朋友经常问“常用 skills 有哪些”。AI 漫剧一般指用 AI 工具批量生成分镜图、字幕和配音再拼成短剧属于套路化很强的生产流程刚好适合技能化。我观察下来的高频需求集中在四个方向角色一致性、分镜生成、字幕风格、背景库管理。角色一致性 skill 的核心是角色卡。在SKILL.md里写明每个角色的姓名、外貌特征、服装、语气并要求每一步生成前先查角色卡。技能包里还可以放两张参考图AI 能读取图文信息时出错的概率会小很多。分镜生成 skill 可以把文字剧本转成表格输出“景别、画面描述、对话、时长”。有了这个固定结构后续交给视频生成工具时少很多沟通成本。字幕风格 skill 则更像一套字体和文案规范保证同一个剧集里字幕位置、字号、断句规则统一。创意类技能的坑在于“面粉厂式输入”如果参考文件太多太杂AI 会被细节淹没。建议一个 skill 只解决一个稳定流程角色卡和分镜规则拆成两个独立技能效果往往更好。3.4 值得收藏的 skills 源与安装注意点GitHub 上有几个方向值得关注。一是像superpower skills、typesafe ai skills这类体系化技能合集适合想学习技能设计的人二是科研写作方向也有人维护nature skills风格包的仓库重点是把论文结构、图表规范做成技能三是偏 agent 框架方向的比如opencode社区里流传的技能包本质还是文件加说明。还有一类像 Cola Skills 这种全家桶仓库命名很讨喜但直接装容易踩依赖坑我更愿意把它当学习资料拆着看。分享一个我自己的筛选方法先在 GitHub 搜skills按最近更新排序看仓库有没有完整的 README、示例文件和最近 commit。没人维护的技能包即使装了也可能和新版工具不兼容。像superpower skills这种热门合集安装方式和普通技能包没区别clone 之后把里面的技能目录拷到~/.claude/skills即可。安装合集时最忌讳“刮刮乐”心态。不要把仓库里所有技能一股脑复制到全局。装太多了AI 每次判断该用哪个时容易犹豫甚至会同时加载互相冲突的规则。我的习惯是只挑和手头工作直接相关的控制在 10 个以内。4. 自己写一个 skills从零到能用的完整流程4.1 文件结构和最小的 SKILL.md自己写 skills 没有那么高的门槛。最简单的技能就一个SKILL.md文件外加一个可选模板目录。结构大致是这样my-skill/ ├── SKILL.md ├── templates/ │ └── report.tex └── reference/ └── example.mdSKILL.md开头有两行很关键一个是name一个是description。description是 AI 判断该不该调用这份技能的依据写得越具体调用越准确。很多新手的技能不生效不是因为文件放错而是因为 description 写得太模糊比如“帮助写报告”AI 不确定什么时候该用。我以一个数学建模报告 skill 为例从头写一遍。先创建SKILL.md--- name: math-model-report description: 当用户需要撰写数学建模比赛论文、数据分析报告或 LaTeX 排版时使用 --- 按照模板写论文必须按以下顺序输出章节 1. 问题重述 2. 模型假设 3. 变量说明 4. 模型建立与求解 5. 模型检验 6. 结论 图表统一使用 templates/figure.tex 里的格式。这个文件看起来简单但已经解决了一个实际问题AI 不会再把章节搞乱也不会随手写一个没标题的纯文本报告。description 里的触发关键词“数学建模”和“LaTeX 排版”是我测试后加上的太短的时候它总会在该用的时候不调用。4.2 让技能从“能用”到“好用”只写好SKILL.md还不够。真正好用的技能通常有一套参考文件。我写 skill 的时候最常加两类东西示例和检查表。示例放在reference/下作用有点像 few-shot。你要是想让它生成符合你风格的论文摘要就扔进去三篇你认为表达好的摘要想让它生成某个组件就扔进去两个已经验收过的组件文件。AI 从具体例子中反推比从抽象描述中脑补强很多。检查表写在SKILL.md的正文里或单独一个checklist.md。比如建模报告 skill 可以在最后写一条“输出前必须先检查变量表是否跟正文一致”。这种硬性规则能显著减少低级错误。再有就是校验脚本。如果你会 Python可以在技能包里放一个小脚本让 AI 生成完后跑一遍检查文件格式、缺失字段。脚本不需要复杂能验证基础约束就行。我有个技能就是靠validate.py在 CI 里拦截了格式错误而不是靠人在对话里反复提醒。4.3 学习技能开发的三个方法如何学习 skills我见过最快的方式不是看教程而是拆解三个仓库。找一个 superpower skills 这种合集把一个技能源码读一遍理解它为什么这么组织再到一个官方文档找技能格式说明对应着改一个最小例子最后把自己最近重复做过三次以上的任务写成一个技能跑通一次就有感觉。我自己的学习路径是先抄一个简单的SKILL.md改几个字让它跑一个扫目录的任务然后试着加 reference把示例文件扔进去看效果最后才尝试写带校验脚本的技能。每一步都快速验证比一次性憋一个大而全的技能效果好得多。写的时候注意控制体积。一个技能的目标是“固定工作方式”不是“把整个项目的文档都塞进去”。如果技能包超过几 MB通常意味着边界没划好。5. 常见问题与排查技巧实录5.1 装了但没生效这是最常遇到的问题。先看技能列表里有没有对应名字没有说明目录不在扫描范围内。如果你用的是全局目录确认路径是不是~/.claude/skills如果项目里没有.claude/skills单独创建后可能需要重启会话。再看有没有SKILL.md。有的仓库把说明文件叫README.md直接放到技能目录里AI 不会把它当成技能入口。需要把入口改成SKILL.md或按工具的规范命名。最后看 description 的措辞。这类问题最隐蔽描述里没有触发词AI 觉得没必要加载。排查方法是手动在对话里说“使用 xxx 技能”如果能强制触发说明文件是好的只是自动触发条件太窄改宽 description 即可。症状可能原因处理方式技能列表看不到目录不在扫描范围移到正确目录或重启能看到但不执行description 太模糊加触发词、具体化触发场景执行了但结果不对缺少 reference 或模板补示例文件、写明硬性约束依赖报错技能需要脚本或环境按 README 安装依赖5.2 技能之间互相干扰技能装多了之后部分 description 会重叠AI 可能同时触发两个技能指令前后打架。我的处理方式是给 description 加限定场景比如“仅当用户提到前端 effect 性能时”而不是“当用户提到性能时”。触发条件越具体冲突越少。同名技能也会造成干扰。项目级和全局级同名时以项目级为准的情况较多。如果发现行为不对检查项目里是不是放了一个旧版本。干净的做法是删掉全局版本只保留项目级。实在排不清时我还有一个笨办法临时把所有技能移出目录只留一个看行为是否恢复正常。然后逐个加回来这个过程往往能暴露冲突。5.3 清理和管理技能关于清理我看到有开发者专门分享过一套方法但核心并不神秘。定期看一眼~/.claude/skills下的目录列表超过两周没用的技能直接删。不要心疼技能包几乎都可以从 GitHub 重新拉回来。如果怕手误可以先压缩备份再清理tar -czf skills-backup.tar.gz ~/.claude/skills清理的时候注意关联依赖。有些技能不是孤立的它会引用另一个技能里的脚本。删之前 grep 一下有没有别的文件在引用它的路径风险会小很多。一个经验之谈技能库需要“瘦身”但不是越少越好。留下那些能稳定改善输出的、和手头任务强相关的删掉那些“看着厉害但从未触发”的。我目前全局技能保持在 8 个左右项目级另算触发准确率高很多。6. 实战心得与建议6.1 我踩过最深的坑我最开始装了一个很大的合集里面几十个技能全塞进全局目录结果 AI 在写文档时莫名其妙会执行另一个技能里的规范改我的 Markdown 结构。排查了半天才意识到是 description 重叠。后来把全局技能砍到只有通用的几项项目里的技能才保留 3 到 5 个再也没有出现这种玄学问题。另一个坑是更新。GitHub 上的技能更新后我重新 clone 覆盖结果把本地改过的模板覆盖了。从那以后每改一个技能就先git commit或者用单独的目录区分“原版”和“我的定制版”避免哪天手滑。6.2 给新手的三个直接建议如果你现在还在“如何学习 skills”这个阶段我的建议是先装两个再拆一个最后写一个。装两个能让你理解技能为什么省事拆一个能让你看到好的技能结构写一个最基础的任务流程能让你彻底搞懂加载逻辑。写的时候从一个很小的动作开始。比如“生成一段符合我团队风格的 git commit message”比“写一个全自动代码检查系统”更容易成功。小技能跑通后再迭代加上模板、参考文件、校验脚本经验和正反馈都能滚起来。一定要把 description 当产品标题来写。用“当用户……时”开头把触发条件说清楚。这是我看很多技能包没触发、新手反复折腾后总结出的最关键一条。6.3 后续还能怎么扩展技能这事远没到天花板。我自己已经在尝试把几个小技能组合成一个“工作流”比如从数据读取到报告输出串联起来。也有人把技能和评测脚本结合跑完任务后自动记录成功率用来迭代自己的技能描述。所以不用把 skills 想得太重它本质上就是你自己工作方法的一种外置。每次发现“这句话我反复说了很多次”就值得把它写进一个 skill。慢慢积累你的 AI 会越来越懂你而你也越来越清楚哪些事情该交给它做。