1. 先搞清楚 skills 到底是什么先说个结论最近圈子里都在聊的 skills既不是传统 IDE 插件也不是普通提示词模板而是 AI 编程 Agent 的一套“可复用能力包”。你去看 GitHub 上那些仓库比如 superpower skills本质就是一堆 markdown 文件加脚本但装进 Claude Code、Codex、OpenCode 这类工具之后AI 就能突然“会”很多原来不会的复杂操作。我用一个不太严谨但很好懂的解释如果说大模型是刚毕业的实习生脑子快但没经验那 skills 就是给这个实习生配的操作手册和工具包。它不改变模型本身而是改变模型调用工具的方式、思考问题的路径、以及输出结果的格式。你给实习生一本《如何处理一份混乱的销售数据》他就能照着流程一步步把活儿干完而不是自由发挥给你一堆没法用的半成品。这也解释了为什么那么多人把 skills 称为 superpower skills。普通 prompt 是一次性的换个项目就要重新写插件则被工具的 API 框死能做的东西有限。skills 刚好卡在中间它足够轻量能用文本描述就和能维护同时又足够结构化能被 Agent 自动发现、自动加载、自动执行。装上几个好用的 skills等于给你的 AI 编程工具做了一次能力扩容。1.1 skills 不是插件也不是提示词我在实操里见过不少误解有人把 skills 当 prompt 用直接在对话里粘贴一大段“请你扮演一个资深数据分析师”这其实完全跑偏了。真正的 skill 至少包含三样东西固定的目录结构一般是一个文件夹对应一个 skill文件夹里有 SKILL.md还有 scripts、references、assets 之类的子目录结构化元信息也就是 YAML frontmatter里面写 name、description这部分是让 AI 判断“什么时候该用这个 skill”的关键可执行的步骤文档正文部分是给人看也给模型看的操作流程写得越具体模型执行越稳定换句话说一份 prompt 只是告诉 AI“你要做什么”而 skill 告诉 AI“你要做什么、按什么顺序做、每一步做到什么程度、遇到问题怎么处理、最终输出长什么样”。这个差别在复杂任务里特别明显。比如让 AI 优化一个老项目的构建配置光靠对话里的临时指令它大概率会东改一下西改一下最后构建速度没提升多少反倒引入一堆兼容性问题。但如果你装了一个“前端构建优化”skill它会先跑诊断命令收集数据再逐项分析瓶颈最后给出对比报告和回滚方案整个流程是可控的。1.2 为什么说 skills 是“superpower”还有一个很关键的点skills 可以叠加。你装一个“生成单元测试”的 skill再装一个“分析代码覆盖率”的 skillAI 就能先写测试再跑覆盖率再补充用例形成一条流水线。这种能力在之前很难实现因为普通对话里 AI 的“记忆”太短了它会忘记自己刚分析过的业务背景。skill 相当于把经验固化下来了。我举一个最直接的例子很多人用 Claude Code 整理代码仓库最头大的就是 AI 会把不该动的公共模块改掉。后来社区里有人写了一个“repo 结构感知”skill要求模型先读一遍项目文档、生成依赖关系图、标记核心文件然后才能动手。装上之后AI 的判断逻辑明显稳了很多。这不是模型变聪明了而是它被 skill 里写的“先理解再动手”流程约束住了。所以我的结论是skills 是 AI 编程工具从“聊天机器”进化为“干活 Agent”的关键中间层。它不像插件那样需要改 C 代码也不像 prompt 那样没有约束力它用一套所有人都能读懂的 markdown 格式把专家的经验变成模型的执行路径。这也是为什么现在各大 Agent 工具都在往这个方向发力。2. 手动安装 GitHub 上的 skills完整实操流程热词里有一条很具体“claude code 怎么手动装 github 上的 skills”这确实是新手最容易卡住的地方。因为不同工具的安装方式不一样有的是命令一键装有的要把仓库 clone 下来放到指定目录还有的要改配置文件。我先按工具分类拆开讲。2.1 不同工具各自认哪个目录先说 Claude Code。它的 skills 目录在~/.claude/skills/这是个隐藏目录你可以在终端里用ls -la ~/.claude看到。每个 skill 是一个独立子文件夹比如~/.claude/skills/ ├── skill-name/ │ ├── SKILL.md │ ├── scripts/ │ └── references/Codex 这边路径稍微有点不同它更习惯用~/.codex/skills/而且有些版本要求每个 skill 里还要有一个app.json之类的描述文件。OpenCode 和 Codex 类似但社区里也有直接用全局~/.config/opencode/skills/的做法。这里我建议你装之前先看一眼工具的官方文档别凭记忆套路径。为什么每个工具路径都不一样本质原因是它们对 skill 的加载机制不同。有的工具启动时会扫描目录下所有 SKILL.md把 description 解析出来建索引有的工具是在对话过程中按需查找。不管机制怎么变万变不离其宗的是你只要把 skill 文件夹放到工具认识的位置它就能被加载。2.2 手动安装的完整操作步骤我把手动安装拆成四步这个流程我自己实测过很多次踩过的坑基本都能覆盖到。第一步找一个你想装的 skills 仓库。GitHub 上直接搜“awesome claude skills”或者“codex skills”就能找到一堆合集。选的时候多留意 star 数和最近更新时间半年没更新的仓库很可能已经跟新版工具不兼容了。第二步把仓库 clone 到本地。不需要整个仓库都放进 skills 目录先 clone 到临时位置git clone https://github.com/username/some-skills-repo.git然后进入仓库目录看它的目录结构。这里有个关键经验很多合集仓库里的 skill 并不是直接平铺的而是按分类放在skills/technical/、skills/creative/这种二级目录下的。你需要复制的是包含 SKILL.md 的那个文件夹不是整个仓库。第三步复制到目标目录。以 Claude Code 为例cp -r skills/repo/some-skill ~/.claude/skills/复制完之后检查一下结构确认~/.claude/skills/some-skill/SKILL.md这个文件真实存在。我遇到过很多次复制完路径多了一层结果工具根本认不到。第四步启用并验证。如果你用的是 Claude Code需要重启会话让工具重新扫描 skills 目录。然后在对话里说一句“列出你当前可用的 skills”如果它回应了你安装的 skill 的名字说明加载成功。2.3 安装完怎么验证到底起没起作用这一步特别重要因为很多时候加载成功不等于真正生效。我见过有人装完 skill但 AI 回复里完全没用到它原因是 skill 的 description 写得太模糊模型压根没意识到该调用。验证方法分两层浅层验证直接问工具“你有哪些 skills 可用”确认文件被扫描到深层验证构造一个能触发该 skill 的真实任务。比如你装了一个“代码审查”skill就挑一段有明显问题的代码让 AI 审查看它的输出是不是按照 skill 里定义的步骤来我自己的习惯是装完任何 skill 都先跑一次深层验证不行就打开 SKILL.md 看 description 写得是否具体。很多 skill 作者 description 写得很随意比如“review code”这种太宽泛模型根本不会主动调用。你可以自己改一下 description写成“Performs comprehensive code review focusing on security performance and maintainability. Use when asked to review code or check for bugs.”效果立竿见影。3. 常用 skills 推荐与源码分析顺着热词看下来很多人想知道有哪些好用的 skills。这里我得先说一句skills 的质量参差不齐star 高的不一定好用无人维护的未必不能用。我给一套自己的筛选标准再推荐几个口碑比较稳的。3.1 值得关注的几类热门 skills按用途分类目前社区里比较成熟的大概有五类分类典型用途代表关键词代码生成与重构生成业务代码、迁移旧项目、重构模块code generator, refactor测试与质量生成单元测试、覆盖率分析、缺陷定位test generation, coverage文档与知识库生成 README、技术文档、FAQdocs, knowledge base数据处理数据清洗、Excel 报表、ETL 脚本data pipeline, spreadsheet内容创作文章、脚本、分镜、短视频文案writing, storyboard在具体仓库方面superpower skills 是绕不开的一个。它算是目前打包得最完整的 skills 合集里面覆盖了从代码分析到文档输出的一堆技能包而且每个 skill 都有对应的说明和示例。它不是所有 skill 都好用但作为学习模板来看价值特别高。另外还有 codex nature skills 和 cola skills这两个在 Codex 生态里讨论得比较多偏自然语言处理和文本分析适合做知识类任务。typesafe ai skills 则是偏 TypeScript 生态的里面有大量针对前后端项目的技能包比如生成类型定义、接口文档、数据库 schema对做 Web 开发的帮助很直接。选型上我比较看重三点第一目录结构是否规范有没有 REFERENCES 和 scripts第二description 是否写得具体可触发第三是否附带了测试脚本或示例输出。满足这三点的 skill装下来大概率是能用的。3.2 从一个 skill 源码里能学到什么我直接拆一个精简版的 SKILL.md 给你看这是社区里一个“代码审查助手” skill 的核心文件--- name: code-review description: Use when asked to review code, find bugs, suggest improvements. Focuses on security, performance, readability. --- # Code Review Assistant ## 1. Read the target file(s) first - Identify the programming language and framework - Check if a lockfile exists to understand dependency versions ## 2. Analyze common bug patterns - Unhandled null/undefined - Race conditions in async code - Memory leaks in long-running processes ## 3. Output format - Summary of overall code quality (2-3 sentences) - Critical issues table: severity, location, explanation - Refactoring suggestions with code snippets - Final verification checklist你看它的 description 写得非常具体“Use when asked to review code, find bugs, suggest improvements”而且明确提到 security、performance、readability 三个维度。模型在对话中遇到“帮我看看这段代码有什么问题”这种请求时匹配度就会非常高。正文部分更是把流程拆成了 step by step让 AI 先读文件、再分析特定 bug 模式、最后按固定格式输出报告。这比你在对话里说一万句“请你认真审查代码”都管用。装完之后我实际测试AI 输出质量明显从“随手点几个问题”变成“整体评估 优先级 修复建议”这就是 skill 的威力。4. 自己动手写一个 AI skill热词里有“ai skills 怎么写”这其实是进阶玩法。说实话装别人写的 skill 永远有适配问题你团队的代码规范、项目结构、工具链都是独有的自己写 skill 才能真正贴合实际需求。4.1 核心格式与目录规范写 skill 之前先建目录一个标准结构大概是my-skill/ ├── SKILL.md ├── scripts/ │ └── analyze.py ├── references/ │ ├── checklist.md │ └── examples.md └── assets/ └── template.txtSKILL.md 是入口必须有 YAML frontmatter包含 name 和 description 两个字段。description 尤其重要因为它决定了模型什么时候会调用这个 skill我建议写成“目的 触发条件 核心能力”的格式。比如--- name: deploy-check description: Use when preparing frontend deployments, checking build config, verifying environment variables, and generating rollback plans. Triggers on words like deploy, release, go live. ---正文部分不要写成散文要写成流程。一个高效的技巧是把任务拆成“输入 → 处理 → 输出”三个阶段每个阶段都给出具体操作指令。模型在执行时会顺着你的流程走不会自己乱发挥。scripts 目录放辅助脚本比如你想让 AI 自动统计代码行数、解析 JSON 配置把脚本写好之后在 SKILL.md 里明确指出“Run scripts/analyze.py with the target file path as argument”模型就能自己调用。references 目录放参考资料比如编码规范、接口文档摘要模型在需要时才会读取这样能省 token。4.2 frontmatter 与正文怎么写我见过很多人写 SKILL.md 正文只有一句话比如“对代码进行深入分析并给出建议”。这种 skill 装上也没用因为模型不知道该按什么顺序想。好的做法是明确写步骤编号并要求模型输出结构化结果。拿一个“数据清洗” skill 举例--- name: clean-csv description: Use when asked to clean messy CSV or Excel data, deduplicate records, standardize formats, and generate a summary report. --- # CSV Data Cleaning ## Steps 1. Load the data file and display the first 5 rows. 2. Check data types per column; identify text vs numeric fields. 3. Remove duplicates based on business key (specified by user). 4. Normalize date formats to YYYY-MM-DD. 5. Standardize missing values: use N/A rather than empty strings. 6. Save cleaned output as a new file. 7. Write a summary with: total rows before/after, columns changed, issues found. ## Notes - Do not drop rows unless the user confirms. - Keep original file untouched; write to a new file.这里有几个细节值得讲。第一“Display the first 5 rows”给了模型一个明确动作避免它凭空脑补数据内容。第二“Keep original file untouched”是约束条件防止 AI 直接覆盖原始文件。第三“Write a summary with total rows before/after”是强制输出格式让你能快速判断结果对不对。写完 skill 之后用一段脏数据实测一遍。我在实际测试中发现模型有时候会忽略步骤 3 里的业务主键只按整行去重。这种问题不需要改整个 skill只要在步骤里加一句“Check with user which column uniquely identifies a record before deduplication”就能修正。4.3 进阶参数传递与多步骤流程当你开始处理复杂任务时单个 skill 就不够用了你需要让多个 skill 协作。协作的方式很简单一个 skill 的输出格式刚好是另一个 skill 的输入要求。比如skill A“提取 TODO”扫描代码库输出所有 TODO 清单格式是“文件路径: 行号: 注释内容”skill B“生成任务看板”读取 TODO 清单按模块分类并生成 markdown 看板因为 skill A 的输出格式被写死了skill B 只需要按行解析就能得到结果。这比让 AI 自由发挥要稳定得多。我的经验是写 skill 时多花点心思设计输出模板让结果机器可读哪怕只是简单的 markdown 表格都能极大提升后续环节的处理效率。5. 场景实战建模比赛和 AI 漫剧里怎么用 skills热词里出现了“数学建模 skills”“华为杯建模比赛好用的 codex skills”“AI 漫剧常用 skills”一开始我觉得这些场景跨度挺大的但仔细想想其实背后逻辑一致它们都是高度流程化、且有固定产出形式的任务。5.1 数学建模比赛里 skills 能帮你做什么数学建模的流程非常固定选题理解 → 数据预处理 → 建立模型 → 求解验证 → 论文撰写。传统做法是这几步全靠人肉切换工具Excel、Python、LaTeX、Word 来回倒腾。有了 skills 之后这个流程可以被压缩成一个流水线。我见过有人整理了一套数模技能包包括数据探索 skill自动生成数据统计摘要、相关性热力图、缺失值报告模型选型 skill根据问题类型推荐算法并给出参数范围和验证方法论文排版 skill按 LaTeX 模板将结果组织成符合比赛要求的格式举个例子数据探索 skill 的 description 可以写成“Use when given a dataset to explore. Generate summary statistics, visualize distributions, and identify missing values.”正文里写清楚要先输出描述性统计再画图再给出数据质量结论。这样 AI 不会上来就给你整一堆花哨但没用的可视化而是按部就班地完成你真正需要的分析步骤。我自己在帮学生改论文的时候发现最耗时间的不是建模本身而是把模型结果用规范格式写进论文。一个格式转换 skill 就能解决让它读取模型输出的 numpy 数组或 JSON 结果按目标模板生成表格和描述文字。这种活模型干得又快又好人只需要检查一遍数据对不对。5.2 AI 漫剧生产里的 skills把创作流程结构化AI 漫剧是最近很热的创作方向很多人以为难点是生成画面其实真正成本高的是流程管理。一个漫剧项目涉及剧本、分镜、角色设定、场景描述、台词配音、后期剪辑信息散落在几十个文档和对话里。skills 的价值就在于把这一大堆杂乱信息组织成标准化流程。我看过的 AI 漫剧 skills 通常解决三类问题统一设定一个“角色设定”skill存有所有主要角色的外貌、性格、说话风格后续生成分镜时自动保持一致性分镜拆解一个“分镜脚本”skill按照剧本段落生成每个镜头的画面描述、景别、运镜方式风格规范一个“画面风格”skill规定作品的整体画风、色调、构图偏好避免不同镜头风格漂移这些 skill 之间通过固定的标记语言衔接。比如剧本文件里用[SCENE 1]、[CHAR: 主角]这样的标签分镜 skill 解析标签后输出 shot_id scene_id camera_angle description 的格式。这样漫剧生产就从“靠模型即兴发挥”变成“按照固定工业流程走”质量和效率都能稳定下来。6. 踩坑记录与排查技巧实录这一节我从实际操作角度整理一些常见问题都是我在给不同工具装 skills 时真实遇到过的情况。6.1 我实际遇到过的五类问题问题一版本更新导致旧 skill 失效。AI 工具更新很频繁几周不用的 skill 可能就加载不出来了。这不是你装错了而是 API 或内部机制变了。我的建议是保留 skill 的 GitHub 仓库地址定期去看有没有 commit。问题二description 写得不好模型不调用。这是最常见的问题。skill 文件明明在目录里但 AI 就是不用。排查时打开 SKILL.md看 description 是否有具体触发条件。我之前遇到过 description 写“Helps with coding”这基本等于没写模型根本不知道什么时候该用它。改成“Use when asked to optimize SQL queries or debug database performance issues” 之后立刻就能正常触发了。问题三目录层级套太深。有些合集仓库的 requirements 是把所有 skill 放在skills/repo_folder/actual_skill/这种三层结构下。如果你直接复制外层文件夹工具扫描时可能只认第一层找不到 SKILL.md。复制之后务必用find命令验证路径find ~/.claude/skills -name SKILL.md问题四skill 之间的指令冲突。装了多个 skill 之后可能出现同时被触发的情况比如“代码生成”和“代码重构”都认为自己该干活。解决办法是给 description 加更明确的边界词比如生成类用“from scratch”重构类用“modify existing code”。问题五脚本依赖缺失。很多 skill 里的 scripts 依赖 Python 包或 Node.js 库如果本地没装AI 调用时会直接报错。我在项目里会专门维护一个requirements.txt把 skill 里用到的依赖都集中管理起来。6.2 排查思路速查表我把排查链路整理成一张表照着做基本能解决九成问题症状可能原因检查项工具列表里看不到 skill目录放错 / 层级太深find确认 SKILL.md 路径能看到但不被调用description 模糊改写 description 加入触发词调用报错找不到脚本脚本权限 / 依赖缺失chmod x scripts/*安装依赖执行结果不对skill 正文步骤不清拆步骤、加输出格式约束多个 skill 冲突description 边界模糊重新描述触发条件加排斥词还有一个容易被忽略的点就是脚本权限。GitHub 上 clone 下来的脚本默认可能没有执行权限AI 调用./scripts/xxx.py时会提示 Permission denied。我在装完任何带脚本的 skill 后都会跑一遍chmod -R x ~/.claude/skills/*/scripts/这个小操作能帮你避免很多莫名其妙的报错。我个人在实际使用中最深的体会是skills 这个机制最大的门槛不是技术而是思维转变。你不再把 AI 当成一个问一句答一句的聊天框而是把它当成一个可以“培训”的执行者。你花时间把流程写成 SKILL.md它就能稳定地替你干活。而且这个经验是能积累的同一个 skill 在团队里、在不同项目里都能复用写一次收益很多次。后面你再遇到复杂需求第一反应不再是满网找现成方案而是先想这个流程能不能固化成 skill 供以后调用。