事情得从一次前端还原需求说起。当时我用 Claude Code 处理一个设计稿转页面的任务正琢磨怎么把“照着 Figma 自动写代码”这活儿做得更稳有朋友甩了个链接让我去 GitHub 上找一个 UI 相关的 skills 包。我半信半疑地把它塞进.claude/skills目录结果同一个模型干活的水平完全变了——它不再是一步步问我“需要我怎么处理”而是自己先把设计稿切片、识别颜色变量、拆组件层级然后直接生成可跑的响应式页面。那一刻我算明白了skills 这个东西看起来只是个 Markdown 文件实际上是给 AI Agent 装了一套“工作方法论”。这篇文章我就围绕 skills 展开从它到底是什么、怎么手动安装 GitHub 上的第三方 skills到哪些技能库值得收藏、怎么自己写一套再到装多了之后的清理和管理一次性聊透。无论你是刚接触 AI 编程的新手还是已经在用 Claude Code、Codex、OpenCode 的资深玩家这篇都值得看完。1. Agent Skills 的运行逻辑为什么一个 Markdown 文件能改变模型表现很多人的第一反应是skills 不就是把一段 prompt 写进文件里吗我原来也这么想直到自己拆了几个高质量技能包才发现它和普通 prompt 完全是两码事。1.1 SKILL.md 是给 Agent 的“速查手册”而非“对话开场白”普通 prompt 是你每次对话时重新输入的指令模型读完就忘了下次还得重新讲一遍。而 SKILL.md 是一个放在固定目录下的结构化文档Agent 会在启动时或任务命中某个主题时自动加载它。你可以把它理解成给一位新同事的“岗位手册”里面写清楚了这个岗位的职责边界、标准作业流程、产出物格式、常见坑和工具用法。同事手册不需要你每次见面都复述一遍他遇到对应任务时会自己翻手册。一个完整 skills 文件通常长这样my-skill/ ├── SKILL.md # 核心说明书Agent 优先读取 ├── scripts/ # 可执行的辅助脚本 ├── assets/ # 模板、示例、参考文件 └── references/ # 进阶文档按需查看关键在于SKILL.md 内部的结构。它一般包含 YAML 格式的 frontmattername、description和正文 Instructions。description 是给模型“索引”用的决定了它在什么场景下会调用这个技能Instructions 则是真正指导模型工作流程的内容。所以说白了skills 是一个“可被检索、按需加载、带执行脚本”的能力模块而不是一条躺在那里的 prompt。1.2 skills 和普通 prompt 的核心差别为了让你更直观地理解我整理了一张对比表维度普通 PromptAgent Skill加载方式每次对话框手动输入Agent 自动按需加载生命周期单次对话常驻目录跨项目复用可扩展性纯文本可附带脚本、模板、参考文档协作方式个人编辑不易版本管理目录即仓库可用 Git 管理场景绑定靠人描述场景靠 description 自动触发普通 prompt 适合一次性任务比如“帮我把这段话润色一下”。但如果你做的是一整套规范化的活儿比如前端组件开发、数学建模论文排版、AI 漫剧分镜脚本生成每次都要重复描述你的流程模板那就太低效了。skills 的价值在于把流程沉淀成文件让 Agent 形成固定的“肌肉记忆”。1.3 三类最常见的 skills先知道它们解决什么问题根据我在社区里翻仓库和实际使用的经验市面上的 skills 大致分成三类第一类是工具调用型。它主要是把某个 CLI 工具或 API 的用法封装成 Agent 能正确执行的步骤。比如代码审查技能Agent 加载后会先跑 lint、再跑测试、再检查依赖安全或者文档生成技能加载后自动调用项目的注释生成工具。这类 skills 的典型特征是有大量 scripts 目录内容。第二类是任务流程型。它解决的是“怎么一步步把活干完”的问题。例如前端页面还原技能会规定先分析设计稿布局再提取设计 token再搭建组件树最后做响应式适配。这类技能是当前社区最主流、也最实用的基本就是一套带步骤说明的标准作业程序。第三类是领域知识型。它把某个领域的高密度知识沉淀成可查询的文档。比如数学建模技能里会包含常见模型分类、获奖论文结构、画图配色规范AI 漫剧技能里会包含镜头语言、分镜模板、角色一致性设定方法。Agent 在任务命中时会先在 references 目录里检索相关知识再结合任务生成内容。理解这三类之后你再看网上那些 skills 推荐就不会一头雾水了。接下来重点说实操——怎么把 GitHub 上的 skills 手动装进 Claude Code。2. Claude Code 手动安装 GitHub Skills 的完整流程安装 skills 这件事官方文档其实写得比较简略而且界面版本迭代快导致很多人在“装不上”“不生效”“找不到路径”这几个问题上来回折腾。我把自己实测过的两种方法全部拆开讲。2.1 先搞清楚 skills 该放在哪个目录Claude Code 的 skills 分两个层级个人级目录~/.claude/skills/所有项目都能用。适合放你个人常用的通用型技能比如代码审查、Commit 信息生成、文档规范化。项目级目录你的项目根目录/.claude/skills/只在该项目里生效。适合放和业务强相关的技能比如“公司内网接口对接”“特定框架的组件生成规范”。还有一类是通过 marketplace 安装的会出现在插件管理目录下本质差别不大但从哪里装决定了它在哪个作用域生效。手动安装 GitHub 上的 skills我推荐直接放进个人级目录这样最通用也方便跨项目复用。注意如果你用的是团队共享机器或者项目里有 CI 流程项目级目录也是不错的方案跟随 Git 仓库走团队成员 clone 下来即可共享技能。2.2 方法一git clone 装进个人技能目录最稳这是最“手工”也最不容易出错的方式。步骤如下# 1. 进入个人 skills 目录没有就创建 mkdir -p ~/.claude/skills cd ~/.claude/skills # 2. 克隆你找到的 skills 仓库 git clone https://github.com/xxx/xxx-skill.git # 3. 确认目录结构是否正确 ls -la ~/.claude/skills/xxx-skill/关键检查点克隆下来的仓库根目录里必须有SKILL.md文件。如果你发现仓库把技能文件套了好几层子目录例如repo-name/skills/frontend-dev/SKILL.md那你需要把frontend-dev这个目录整个复制到~/.claude/skills/下而不是直接把仓库根目录扔进去。# 进入多级目录仓库时 cd ~/.claude/skills git clone https://github.com/xxx/xxx-skill.git cp -r xxx-skill/skills/frontend-dev ./ rm -rf xxx-skill很多技能包下载下来不生效十有八九是路径层级错了。Agent 扫描 skills 目录时找的就是“该目录下的直接子目录里有没有 SKILL.md”多套一层它就识别不到。2.3 方法二通过 marketplace 添加带自动更新如果你留意到仓库名带有-skills后缀且 README 里提到 “marketplace” 或 “plugin” 这类字眼那它通常是一个支持 marketplace 安装的技能集。这种方式的好处是后续可以自动更新不用手动重新 clone。在 Claude Code 里执行/plugin marketplace add owner/repo示例/plugin marketplace add antlir/antlir-skills /plugin marketplace add typesafe-ai/typesafe-skills添加之后再输入/plugin install business-plan这里的business-plan是技能集里的某个具体技能名称。装完重启会话输入/plugin list可以查看当前已安装的插件。这两种方式本质是同一个技能的两种分发渠道。单仓库单技能用 clone 更直接合集型技能集用 marketplace 更好管理。我第一次装 Superpowers 的时候两种方法都试过最后老老实实走了 marketplace因为那个仓库里有几十个技能手动 clone 再一个个整理路径太消耗精力。2.4 装完立刻验证别再等“玄学生效”很多人装完 skills 之后没有立刻验证等真正用的时候发现没加载白白浪费时间排查。我现在的验证流程很固定先确认目录位置正确ls ~/.claude/skills/你的技能名/SKILL.md打开 Claude Code重新启动一个新会话因为技能扫描基本发生在会话初始化阶段。老会话里动态加载能力虽然也在完善但别依赖它直接新会话最省心。直接问一句“你有没有 xxx 这个技能的说明”如果 Agent 没反应就检查 SKILL.md 里 frontmatter 的 description 是否是我们常用的中文表述。很多第三方技能包用英文描述你在中文对话环境下触发不到它这是特别常见的问题处理办法是打开 SKILL.md 把 description 改成中英双语或者在任务里明确提到技能名。验证通过之后你会发现同一件事的执行质量明显提升。但前提是你装对了包接下来我说说哪几个 skills 仓库值得装。3. 值得收藏的 Skills 仓库与源网站清单GitHub 上带skills标签的仓库越来越多但质量参差不齐。我按自己的实测体验挑几个代表性资源展开说。3.1 Superpowers社区里绕不开的巨型技能集Superpowers 是这个圈子里的“瑞士军刀”。它由多个子技能组成覆盖了代码提交、Web 开发、文档撰写、代码审查等常见场景。这个仓库最打动我的地方不在于某个技能有多惊艳而在于它的工程规范沉淀——它对每个技能的适用边界讲得很清楚不会出现所有场景都硬套一个技能的情况。安装方式/plugin marketplace add obra/superpowers装完之后你会在技能目录里看到一堆细分技能。我个人用得较多的是superpowers-code-review和superpowers-commit。前者能帮我自动审查代码里的逻辑漏洞和风格问题后者能根据 diff 自动生成符合 Conventional Commits 规范的提交信息。这个技能集也有它的问题它追求覆盖广度所以单个技能的颗粒度偏粗。如果你需要非常细的领域能力还是得去找垂直场景的专项技能。3.2 TypeSafe AI Skills工程实践向的高质量合集TypeSafe AI 出的 skills 集是我见过的最“像软件工程”的技能包。它的目录设计、文档完整度、示例密度都做得很好特别适合用来学习“别人怎么写技能”。里面有些技能的流程设计堪称教科书级。安装方式/plugin marketplace add typesafe-ai/typesafe-ai-skills和 Superpowers 相比TypeSafe 的技能更讲究“可验证性”。它里面的技能通常会附带测试脚本和验收标准这让我这种习惯写测试的开发者非常有好感。比如你要求它生成一个 API 服务它不会直接把代码甩给你而是会先列接口设计、再写单元测试、最后才补齐实现流程上和真正的开发过程保持一致。3.3 其他常用源网站和下载渠道除了这两个头部仓库还有几个获取 skills 的渠道值得常备GitHub Topics 直接搜索搜索claude-skills、agent-skills、codex-skills等标签按 Star 数排序能挖出不少小众但高质量的项目。社区聚合站目前有几个站点专门做 AI Skills 的导航和索引类似早期找好用的 Chrome 插件你可以在上面按场景、按工具过滤。这类站点通常在标题里直接带“skills 技能库”字样用搜索引擎一查一大片重点是学会看收录标准和更新时间。同行的公开配置不少开发者在 GitHub 上公开了个人.claude目录配置直接去看他们的 skills 清单收获往往比看推荐清单更大。毕竟“他真在用”比“他推荐”重要得多。3.4 怎么判断一个 skills 仓库值不值得装我总结了一套 1 分钟判断法省得一个个仓库试错判断维度高质量信号低质量信号更新时间近 3 个月内有提交一年没动静目录结构SKILL.md scripts references 分层清晰只有一个孤立 Markdown示例密度有 demo、有案例、有截图纯文字描述描述精准度description 写明触发条件与不适用场景描述写得太泛像 SEO 文案社区反馈有 issues 讨论、有实际使用记录只有 author 自嗨看两个信号基本就不会栽大跟头。首先是 SKILL.md 的 description 部分——如果它没有写清楚“什么场景下使用”和“什么场景下不建议使用”说明作者没有深入思考这类技能装了也容易误触发。其次是仓库里有没有 references 目录——一个有复杂逻辑的技能必然有分层文档来支撑主文件只有单一文件说明作者没把场景想全。4. 场景实测前端开发、数学建模、AI 漫剧里的 Skills 到底怎么用热词里有一批非常具体的场景前端开发 skills、数学建模 skills、AI 漫剧常用 skills。我把这三个分别展开说说实际用法。4.1 前端开发 skills让 Agent 从“写代码”升级成“做页面”前端技能的典型适用场景是设计稿还原。好的前端开发技能包会内置一套完整的页面还原流程而不是让你在对话里反复描述“字体大小”“间距多少”。它会让 Agent 这么做先解析设计稿整体布局识别区块类型再抽取颜色、字体、间距形成设计变量然后规划组件树决定哪些部分可复用最后生成代码并且要求同时输出移动端适配方案。我在装过一套社区里的前端技能之后实测了三个页面还原度从原来的“八成像”提升到“九成五以上”。原因在于技能里带了响应式断点规范和处理经验Agent 不再需要靠猜来判断你的断点设置直接按约定执行。适合新手的搭配是前端开发技能 浏览器自动化技能。前者负责页面代码生成后者负责自动截图验证页面效果形成一个“生成—验证—修复”的闭环。4.2 数学建模 skills竞赛场景下的效率增幅器数学建模是对效率极其敏感的竞赛场景。三天时间要把题目分析、模型建立、求解、论文排版全走完每一环节的人力都金贵。社区里流传的数学建模 skills大多是围绕“华为杯”“国赛”这些场景设计的核心能力集中在三块选题决策技能内置一整套题目分析框架让 Agent 快速拆解每个题目的难点、可用模型类型、数据需求辅助团队判断哪一题更适合自己。建模流程规范把“先数据清洗、再探索性分析、再模型选择、再调参验证”这个过程固化成步骤防止在压力下漏掉关键环节。论文排版与可视化内置获奖论文的章节结构、图表规范、配色建议生成出来的结果接近出版水准。这类技能给团队带来最明显的变化不是模型变聪明了而是把竞赛中的“标准化动作”全部外包给了 Agent让人把精力集中在真正的创造性思维上。这种“外包标准化动作”的思路在所有竞赛类场景里都适用。4.3 AI 漫剧 skills内容创作里的流程层层拆解AI 漫剧是最近冒出来的内容创作新玩法它同样受惠于 skills。漫剧创作存在大量重复的标准化环节角色设定、分镜脚本、风格参考、一致性维护。这些环节如果每次都用对话框手写 prompt生成质量非常不稳定。一套成熟的 AI 漫剧技能大概长这样SKILL.md # 说明漫剧创作流程与触发条件 assets/character-template.md # 角色卡模板 assets/story-board-template.md # 分镜表模板 scripts/roll_dice.py # 辅助抽签或用例分配的脚本它会让 Agent 在创作前先初始化角色卡包括外貌描述、性格关键词、禁用设定然后在后续每个分镜请求里自动引用角色卡这样就能大幅缓解“每次生成的人物长相都不一样”的问题。同时分镜技能会把“镜号、画面描述、景别、运镜方式、角色动作、背景、对白”这些字段拆成表格让后续的视频生成模型更容易理解。4.4 场景经验的共同点这三个场景看似不搭边背后的逻辑完全一致先拆解流程再固化经验最后变成可复用的技能文件。前端开发固化的经验是响应式适配规则数学建模固化的经验是竞赛节奏和排版规范AI 漫剧固化的是角色一致性和分镜结构。任何你重复做三遍以上的工作都值得把它变成一个技能。5. 从 0 写一套自己的 SKILL.md结构、规范与常见坑看再多的现成技能都不如自己动手写一套。写技能的门槛并不高但要写得让 Agent “爱用”还得注意几个关键点。5.1 标准目录结构与 frontmatter先看一个标准目录结构ui-page-builder/ ├── SKILL.md ├── scripts/ │ ├── extract_colors.py │ └── screenshot_verify.js └── references/ └── responsive-rules.mdSKILL.md 的开头是 YAML frontmatter--- name: ui-page-builder description: 根据设计稿生成高还原度响应式页面。只在用户提供设计稿、页面截图或要求“页面还原”时使用。如果任务是纯逻辑组件开发请勿使用此技能。 ---这里有两个细节特别值得注意。第一name要用短横线命名法方便引用第二description一定要写清楚“什么时候用”和“什么时候不用”。负面描述尤其重要它防止 Agent 在不该用的时候误加载技能。我发现很多自写技能出问题就是因为 description 写得太宽泛导致 Agent 什么任务都往里面套结果反而拖慢普通任务。5.2 Instructions 部分的质量决定技能上限Instructions 部分是技能的灵魂。通过这段时间写技能和拆解别人技能的经验我发现高质量 Instructions 通常具备三个特征第一用编号步骤明确工作流。例如告诉 Agent “按以下顺序执行1. 解析设计稿结构2. 提取设计变量3. 搭建组件树4. 生成代码5. 输出响应式验证清单”。没有编号流程的 Instructions 会让 Agent 在复杂任务里反复试探。第二提供具体示例而不是抽象描述。与其写“组件命名要有意义”不如给出两三个好组件名和坏组件名的对比表格。Agent 对具体例子的模仿能力远强于对抽象规则的理解能力。第三给定验收标准。告诉 Agent“这份技能输出的成果必须包含哪些内容、达到什么标准才算完成”。比如“每个组件必须有测试用例页面必须在小屏/中屏/大屏三档验证过”。验收标准能防止 Agent 在模糊任务里偷工减料。5.3 写技能容易踩的三个坑第一个坑是把技能写成一本“百科全书”。我曾经把一个 SEO 写作技能写了两千多字把所有可能涉及的规则都堆进去结果 Agent 在真正执行时反而抓不住重点输出质量比不用技能还差。后来我精简到四百字只保留最关键的执行步骤和验收标准效果立刻上来了。第二个坑是忘了写“不适用场景”。技能不是万能的每一份技能都应该明确告诉 Agent这个技能在什么条件下不适合使用。比如我的备案审查技能description 里会写“如果是纯前端项目请直接跳过”。有一个领域让我特别犯怵——如果你在写技能的时候发现某些表述得不太对劲那就说明这块内容本身就不是技能该管的范围。这就是我不太碰所谓“网络加速类技能”的原因一是这类东西边界不清二是容易掺和灰色地带直接把范围收缩到本职工作最安全。第三个坑是技能文件命名和内部引用不一致。我早期写的技能里脚本文件路径写错了大小写Agent 执行时找不到脚本直接全过程失败。现在我的习惯是每个脚本都在 SKILL.md 里给出一个“自检命令”让 Agent 在执行前先验证脚本可运行。5.4 自己写完后的验证闭环写完技能别急着去干活先做一轮自验证新建一个测试项目把技能放进项目级.claude/skills目录直接用中文描述一次完整任务看它是否自动调用技能检查技能的每一步是否按预期执行记录卡住的环节执行完检查输出是否符合验收标准回到 SKILL.md 修补问题重新启动会话再测。这个闭环我每次都会跑别嫌麻烦。一次没跑通后面每次用都是半吊子状态数不清要浪费多少时间。自己在测试中改了三轮的技能和直接照搬别人但没做过任何适配的技能在使用体验上差距巨大。6. 装多了之后的清理、管理与团队协作很多人一开始和我一样见到什么技能都往目录里塞一个月之后~/.claude/skills下躺了几十个目录。然后问题来了Agent 加载技能时面临大量选择反而会犹豫甚至误触发不相关技能最终拖慢任务。6.1 tibo 式清理法盘点、分级、移出社区里整理了一套清理方法我管它叫“tibo 式三段清”核心就是三步第一步全面盘点。用这条命令列出所有技能以及最后修改时间find ~/.claude/skills -name SKILL.md -exec stat --format%y %n {} | sort第二步按使用频率分级。过去两周内用过的技能保留在目录内偶尔手动触发的技能移到独立目录做“备胎区”超过半年没碰过、且不属于你当前业务方向的技能直接删除。删除前记得看看是不是原仓库还能再拉回来能拉回来的都可以放心删。第三步合并同类项。社区里存在大量功能重叠的技能比如“代码审查-reviewers”“git-commit-message-format”这类。我一般会保留功能最全、维护最勤的那一个然后把其他的从加载目录中移出。如果你担心以后用得上就丢进~/.claude/skills-archive/目录既不影响加载也不会丢。6.2 版本的锁定与团队共享skills 毕竟是代码仓库有版本问题。如果团队里共用一套技能直接用最新版很危险——今天更新了脚本逻辑明天大家的 Agent 行为变了之前的产出风格全乱套。我的经验是固定到具体 commit。比如技能集仓库在某个时间点验证最优那么团队 README 里明确写出当时安装的 commit id新成员一律安装指定 id而不是自己拉最新的。cd ~/.claude/skills git clone repo-url git checkout commit-hash团队共享方面我更推荐把技能集放进一个独立的内部仓库然后通过 marketplace 的方式统一管理。这样一个技能更新了只需要维护仓库本身其他成员用/plugin update拉一下即可不用挨个机器去同步文件。6.3 我自己踩过的坑同名冲突与自动加载失灵挑三个我觉得最有代表性的给正在折腾的人提个醒。第一个坑是同名技能冲突。我之前装了两个都叫code-review的技能一个来自 Superpowers一个来自另一个个人仓库。Claude Code 加载时只加载了其中一个而另一个的个性化配置完全没生效。排查了半天才发现是同名覆盖问题。现在我的原则是同一功能向只保留一个技能非留不可时会把其中一个改名并同步改掉 frontmatter 里的 name。第二个坑是目录层级不对导致加载失灵。我把一个从网上下载的技能包直接解压到~/.claude/skills/没注意解压出来多包了一层目录。结果 Agent 扫描的时候发现下面没有 SKILL.md只有一堆子目录整个技能直接变成无效目录。第三个坑是忽略技能仓库里自带的依赖。有些技能包带 scripts 的 Python 依赖需要pip install -r requirements.txt。技能说明文档通常写得很清楚但着急用的时候很容易跳过。之后 Agent 调用脚本时直接报 ModuleNotFoundError。现在我把所有用到脚本的技能都记录在案装完立刻跑一次自检命令。6.4 给 sets 的“最小可用配置”建议如果你不想一开始就上手折腾这么多我建议按这个最小化方案起步装 1 个代码审查技能 1 个 Commit 信息生成技能 1 个你业务最核心的流程技能即可。再多就容易陷入我刚才说的“技能多但触发不稳定”的怪圈。先用最小配置跑通一个完整项目理解 Agent 在加载技能时的行为然后再按需扩充。记住技能的价值是让你重复的工作流程得到固化而不是让你陷入技能管理的泥潭。一个能让你一天少花两小时整理流程的技能集比一百个装在目录里吃灰的技能有用得多。这些年我用 AI 编程工具有一个很深的体会模型能力决定了水平下限而 skills 的配置质量决定了水平上限。与其花大量时间去找“更聪明的模型”不如把手头这套技能体系打磨好。装几个值得信任的技能包自己再按业务场景写几套再把目录清理得井井有条这个过程中获得的理解比单纯追新版本工具值钱得多。
Agent Skills完全指南：从安装到定制，解锁AI编程效率上限
事情得从一次前端还原需求说起。当时我用 Claude Code 处理一个设计稿转页面的任务正琢磨怎么把“照着 Figma 自动写代码”这活儿做得更稳有朋友甩了个链接让我去 GitHub 上找一个 UI 相关的 skills 包。我半信半疑地把它塞进.claude/skills目录结果同一个模型干活的水平完全变了——它不再是一步步问我“需要我怎么处理”而是自己先把设计稿切片、识别颜色变量、拆组件层级然后直接生成可跑的响应式页面。那一刻我算明白了skills 这个东西看起来只是个 Markdown 文件实际上是给 AI Agent 装了一套“工作方法论”。这篇文章我就围绕 skills 展开从它到底是什么、怎么手动安装 GitHub 上的第三方 skills到哪些技能库值得收藏、怎么自己写一套再到装多了之后的清理和管理一次性聊透。无论你是刚接触 AI 编程的新手还是已经在用 Claude Code、Codex、OpenCode 的资深玩家这篇都值得看完。1. Agent Skills 的运行逻辑为什么一个 Markdown 文件能改变模型表现很多人的第一反应是skills 不就是把一段 prompt 写进文件里吗我原来也这么想直到自己拆了几个高质量技能包才发现它和普通 prompt 完全是两码事。1.1 SKILL.md 是给 Agent 的“速查手册”而非“对话开场白”普通 prompt 是你每次对话时重新输入的指令模型读完就忘了下次还得重新讲一遍。而 SKILL.md 是一个放在固定目录下的结构化文档Agent 会在启动时或任务命中某个主题时自动加载它。你可以把它理解成给一位新同事的“岗位手册”里面写清楚了这个岗位的职责边界、标准作业流程、产出物格式、常见坑和工具用法。同事手册不需要你每次见面都复述一遍他遇到对应任务时会自己翻手册。一个完整 skills 文件通常长这样my-skill/ ├── SKILL.md # 核心说明书Agent 优先读取 ├── scripts/ # 可执行的辅助脚本 ├── assets/ # 模板、示例、参考文件 └── references/ # 进阶文档按需查看关键在于SKILL.md 内部的结构。它一般包含 YAML 格式的 frontmattername、description和正文 Instructions。description 是给模型“索引”用的决定了它在什么场景下会调用这个技能Instructions 则是真正指导模型工作流程的内容。所以说白了skills 是一个“可被检索、按需加载、带执行脚本”的能力模块而不是一条躺在那里的 prompt。1.2 skills 和普通 prompt 的核心差别为了让你更直观地理解我整理了一张对比表维度普通 PromptAgent Skill加载方式每次对话框手动输入Agent 自动按需加载生命周期单次对话常驻目录跨项目复用可扩展性纯文本可附带脚本、模板、参考文档协作方式个人编辑不易版本管理目录即仓库可用 Git 管理场景绑定靠人描述场景靠 description 自动触发普通 prompt 适合一次性任务比如“帮我把这段话润色一下”。但如果你做的是一整套规范化的活儿比如前端组件开发、数学建模论文排版、AI 漫剧分镜脚本生成每次都要重复描述你的流程模板那就太低效了。skills 的价值在于把流程沉淀成文件让 Agent 形成固定的“肌肉记忆”。1.3 三类最常见的 skills先知道它们解决什么问题根据我在社区里翻仓库和实际使用的经验市面上的 skills 大致分成三类第一类是工具调用型。它主要是把某个 CLI 工具或 API 的用法封装成 Agent 能正确执行的步骤。比如代码审查技能Agent 加载后会先跑 lint、再跑测试、再检查依赖安全或者文档生成技能加载后自动调用项目的注释生成工具。这类 skills 的典型特征是有大量 scripts 目录内容。第二类是任务流程型。它解决的是“怎么一步步把活干完”的问题。例如前端页面还原技能会规定先分析设计稿布局再提取设计 token再搭建组件树最后做响应式适配。这类技能是当前社区最主流、也最实用的基本就是一套带步骤说明的标准作业程序。第三类是领域知识型。它把某个领域的高密度知识沉淀成可查询的文档。比如数学建模技能里会包含常见模型分类、获奖论文结构、画图配色规范AI 漫剧技能里会包含镜头语言、分镜模板、角色一致性设定方法。Agent 在任务命中时会先在 references 目录里检索相关知识再结合任务生成内容。理解这三类之后你再看网上那些 skills 推荐就不会一头雾水了。接下来重点说实操——怎么把 GitHub 上的 skills 手动装进 Claude Code。2. Claude Code 手动安装 GitHub Skills 的完整流程安装 skills 这件事官方文档其实写得比较简略而且界面版本迭代快导致很多人在“装不上”“不生效”“找不到路径”这几个问题上来回折腾。我把自己实测过的两种方法全部拆开讲。2.1 先搞清楚 skills 该放在哪个目录Claude Code 的 skills 分两个层级个人级目录~/.claude/skills/所有项目都能用。适合放你个人常用的通用型技能比如代码审查、Commit 信息生成、文档规范化。项目级目录你的项目根目录/.claude/skills/只在该项目里生效。适合放和业务强相关的技能比如“公司内网接口对接”“特定框架的组件生成规范”。还有一类是通过 marketplace 安装的会出现在插件管理目录下本质差别不大但从哪里装决定了它在哪个作用域生效。手动安装 GitHub 上的 skills我推荐直接放进个人级目录这样最通用也方便跨项目复用。注意如果你用的是团队共享机器或者项目里有 CI 流程项目级目录也是不错的方案跟随 Git 仓库走团队成员 clone 下来即可共享技能。2.2 方法一git clone 装进个人技能目录最稳这是最“手工”也最不容易出错的方式。步骤如下# 1. 进入个人 skills 目录没有就创建 mkdir -p ~/.claude/skills cd ~/.claude/skills # 2. 克隆你找到的 skills 仓库 git clone https://github.com/xxx/xxx-skill.git # 3. 确认目录结构是否正确 ls -la ~/.claude/skills/xxx-skill/关键检查点克隆下来的仓库根目录里必须有SKILL.md文件。如果你发现仓库把技能文件套了好几层子目录例如repo-name/skills/frontend-dev/SKILL.md那你需要把frontend-dev这个目录整个复制到~/.claude/skills/下而不是直接把仓库根目录扔进去。# 进入多级目录仓库时 cd ~/.claude/skills git clone https://github.com/xxx/xxx-skill.git cp -r xxx-skill/skills/frontend-dev ./ rm -rf xxx-skill很多技能包下载下来不生效十有八九是路径层级错了。Agent 扫描 skills 目录时找的就是“该目录下的直接子目录里有没有 SKILL.md”多套一层它就识别不到。2.3 方法二通过 marketplace 添加带自动更新如果你留意到仓库名带有-skills后缀且 README 里提到 “marketplace” 或 “plugin” 这类字眼那它通常是一个支持 marketplace 安装的技能集。这种方式的好处是后续可以自动更新不用手动重新 clone。在 Claude Code 里执行/plugin marketplace add owner/repo示例/plugin marketplace add antlir/antlir-skills /plugin marketplace add typesafe-ai/typesafe-skills添加之后再输入/plugin install business-plan这里的business-plan是技能集里的某个具体技能名称。装完重启会话输入/plugin list可以查看当前已安装的插件。这两种方式本质是同一个技能的两种分发渠道。单仓库单技能用 clone 更直接合集型技能集用 marketplace 更好管理。我第一次装 Superpowers 的时候两种方法都试过最后老老实实走了 marketplace因为那个仓库里有几十个技能手动 clone 再一个个整理路径太消耗精力。2.4 装完立刻验证别再等“玄学生效”很多人装完 skills 之后没有立刻验证等真正用的时候发现没加载白白浪费时间排查。我现在的验证流程很固定先确认目录位置正确ls ~/.claude/skills/你的技能名/SKILL.md打开 Claude Code重新启动一个新会话因为技能扫描基本发生在会话初始化阶段。老会话里动态加载能力虽然也在完善但别依赖它直接新会话最省心。直接问一句“你有没有 xxx 这个技能的说明”如果 Agent 没反应就检查 SKILL.md 里 frontmatter 的 description 是否是我们常用的中文表述。很多第三方技能包用英文描述你在中文对话环境下触发不到它这是特别常见的问题处理办法是打开 SKILL.md 把 description 改成中英双语或者在任务里明确提到技能名。验证通过之后你会发现同一件事的执行质量明显提升。但前提是你装对了包接下来我说说哪几个 skills 仓库值得装。3. 值得收藏的 Skills 仓库与源网站清单GitHub 上带skills标签的仓库越来越多但质量参差不齐。我按自己的实测体验挑几个代表性资源展开说。3.1 Superpowers社区里绕不开的巨型技能集Superpowers 是这个圈子里的“瑞士军刀”。它由多个子技能组成覆盖了代码提交、Web 开发、文档撰写、代码审查等常见场景。这个仓库最打动我的地方不在于某个技能有多惊艳而在于它的工程规范沉淀——它对每个技能的适用边界讲得很清楚不会出现所有场景都硬套一个技能的情况。安装方式/plugin marketplace add obra/superpowers装完之后你会在技能目录里看到一堆细分技能。我个人用得较多的是superpowers-code-review和superpowers-commit。前者能帮我自动审查代码里的逻辑漏洞和风格问题后者能根据 diff 自动生成符合 Conventional Commits 规范的提交信息。这个技能集也有它的问题它追求覆盖广度所以单个技能的颗粒度偏粗。如果你需要非常细的领域能力还是得去找垂直场景的专项技能。3.2 TypeSafe AI Skills工程实践向的高质量合集TypeSafe AI 出的 skills 集是我见过的最“像软件工程”的技能包。它的目录设计、文档完整度、示例密度都做得很好特别适合用来学习“别人怎么写技能”。里面有些技能的流程设计堪称教科书级。安装方式/plugin marketplace add typesafe-ai/typesafe-ai-skills和 Superpowers 相比TypeSafe 的技能更讲究“可验证性”。它里面的技能通常会附带测试脚本和验收标准这让我这种习惯写测试的开发者非常有好感。比如你要求它生成一个 API 服务它不会直接把代码甩给你而是会先列接口设计、再写单元测试、最后才补齐实现流程上和真正的开发过程保持一致。3.3 其他常用源网站和下载渠道除了这两个头部仓库还有几个获取 skills 的渠道值得常备GitHub Topics 直接搜索搜索claude-skills、agent-skills、codex-skills等标签按 Star 数排序能挖出不少小众但高质量的项目。社区聚合站目前有几个站点专门做 AI Skills 的导航和索引类似早期找好用的 Chrome 插件你可以在上面按场景、按工具过滤。这类站点通常在标题里直接带“skills 技能库”字样用搜索引擎一查一大片重点是学会看收录标准和更新时间。同行的公开配置不少开发者在 GitHub 上公开了个人.claude目录配置直接去看他们的 skills 清单收获往往比看推荐清单更大。毕竟“他真在用”比“他推荐”重要得多。3.4 怎么判断一个 skills 仓库值不值得装我总结了一套 1 分钟判断法省得一个个仓库试错判断维度高质量信号低质量信号更新时间近 3 个月内有提交一年没动静目录结构SKILL.md scripts references 分层清晰只有一个孤立 Markdown示例密度有 demo、有案例、有截图纯文字描述描述精准度description 写明触发条件与不适用场景描述写得太泛像 SEO 文案社区反馈有 issues 讨论、有实际使用记录只有 author 自嗨看两个信号基本就不会栽大跟头。首先是 SKILL.md 的 description 部分——如果它没有写清楚“什么场景下使用”和“什么场景下不建议使用”说明作者没有深入思考这类技能装了也容易误触发。其次是仓库里有没有 references 目录——一个有复杂逻辑的技能必然有分层文档来支撑主文件只有单一文件说明作者没把场景想全。4. 场景实测前端开发、数学建模、AI 漫剧里的 Skills 到底怎么用热词里有一批非常具体的场景前端开发 skills、数学建模 skills、AI 漫剧常用 skills。我把这三个分别展开说说实际用法。4.1 前端开发 skills让 Agent 从“写代码”升级成“做页面”前端技能的典型适用场景是设计稿还原。好的前端开发技能包会内置一套完整的页面还原流程而不是让你在对话里反复描述“字体大小”“间距多少”。它会让 Agent 这么做先解析设计稿整体布局识别区块类型再抽取颜色、字体、间距形成设计变量然后规划组件树决定哪些部分可复用最后生成代码并且要求同时输出移动端适配方案。我在装过一套社区里的前端技能之后实测了三个页面还原度从原来的“八成像”提升到“九成五以上”。原因在于技能里带了响应式断点规范和处理经验Agent 不再需要靠猜来判断你的断点设置直接按约定执行。适合新手的搭配是前端开发技能 浏览器自动化技能。前者负责页面代码生成后者负责自动截图验证页面效果形成一个“生成—验证—修复”的闭环。4.2 数学建模 skills竞赛场景下的效率增幅器数学建模是对效率极其敏感的竞赛场景。三天时间要把题目分析、模型建立、求解、论文排版全走完每一环节的人力都金贵。社区里流传的数学建模 skills大多是围绕“华为杯”“国赛”这些场景设计的核心能力集中在三块选题决策技能内置一整套题目分析框架让 Agent 快速拆解每个题目的难点、可用模型类型、数据需求辅助团队判断哪一题更适合自己。建模流程规范把“先数据清洗、再探索性分析、再模型选择、再调参验证”这个过程固化成步骤防止在压力下漏掉关键环节。论文排版与可视化内置获奖论文的章节结构、图表规范、配色建议生成出来的结果接近出版水准。这类技能给团队带来最明显的变化不是模型变聪明了而是把竞赛中的“标准化动作”全部外包给了 Agent让人把精力集中在真正的创造性思维上。这种“外包标准化动作”的思路在所有竞赛类场景里都适用。4.3 AI 漫剧 skills内容创作里的流程层层拆解AI 漫剧是最近冒出来的内容创作新玩法它同样受惠于 skills。漫剧创作存在大量重复的标准化环节角色设定、分镜脚本、风格参考、一致性维护。这些环节如果每次都用对话框手写 prompt生成质量非常不稳定。一套成熟的 AI 漫剧技能大概长这样SKILL.md # 说明漫剧创作流程与触发条件 assets/character-template.md # 角色卡模板 assets/story-board-template.md # 分镜表模板 scripts/roll_dice.py # 辅助抽签或用例分配的脚本它会让 Agent 在创作前先初始化角色卡包括外貌描述、性格关键词、禁用设定然后在后续每个分镜请求里自动引用角色卡这样就能大幅缓解“每次生成的人物长相都不一样”的问题。同时分镜技能会把“镜号、画面描述、景别、运镜方式、角色动作、背景、对白”这些字段拆成表格让后续的视频生成模型更容易理解。4.4 场景经验的共同点这三个场景看似不搭边背后的逻辑完全一致先拆解流程再固化经验最后变成可复用的技能文件。前端开发固化的经验是响应式适配规则数学建模固化的经验是竞赛节奏和排版规范AI 漫剧固化的是角色一致性和分镜结构。任何你重复做三遍以上的工作都值得把它变成一个技能。5. 从 0 写一套自己的 SKILL.md结构、规范与常见坑看再多的现成技能都不如自己动手写一套。写技能的门槛并不高但要写得让 Agent “爱用”还得注意几个关键点。5.1 标准目录结构与 frontmatter先看一个标准目录结构ui-page-builder/ ├── SKILL.md ├── scripts/ │ ├── extract_colors.py │ └── screenshot_verify.js └── references/ └── responsive-rules.mdSKILL.md 的开头是 YAML frontmatter--- name: ui-page-builder description: 根据设计稿生成高还原度响应式页面。只在用户提供设计稿、页面截图或要求“页面还原”时使用。如果任务是纯逻辑组件开发请勿使用此技能。 ---这里有两个细节特别值得注意。第一name要用短横线命名法方便引用第二description一定要写清楚“什么时候用”和“什么时候不用”。负面描述尤其重要它防止 Agent 在不该用的时候误加载技能。我发现很多自写技能出问题就是因为 description 写得太宽泛导致 Agent 什么任务都往里面套结果反而拖慢普通任务。5.2 Instructions 部分的质量决定技能上限Instructions 部分是技能的灵魂。通过这段时间写技能和拆解别人技能的经验我发现高质量 Instructions 通常具备三个特征第一用编号步骤明确工作流。例如告诉 Agent “按以下顺序执行1. 解析设计稿结构2. 提取设计变量3. 搭建组件树4. 生成代码5. 输出响应式验证清单”。没有编号流程的 Instructions 会让 Agent 在复杂任务里反复试探。第二提供具体示例而不是抽象描述。与其写“组件命名要有意义”不如给出两三个好组件名和坏组件名的对比表格。Agent 对具体例子的模仿能力远强于对抽象规则的理解能力。第三给定验收标准。告诉 Agent“这份技能输出的成果必须包含哪些内容、达到什么标准才算完成”。比如“每个组件必须有测试用例页面必须在小屏/中屏/大屏三档验证过”。验收标准能防止 Agent 在模糊任务里偷工减料。5.3 写技能容易踩的三个坑第一个坑是把技能写成一本“百科全书”。我曾经把一个 SEO 写作技能写了两千多字把所有可能涉及的规则都堆进去结果 Agent 在真正执行时反而抓不住重点输出质量比不用技能还差。后来我精简到四百字只保留最关键的执行步骤和验收标准效果立刻上来了。第二个坑是忘了写“不适用场景”。技能不是万能的每一份技能都应该明确告诉 Agent这个技能在什么条件下不适合使用。比如我的备案审查技能description 里会写“如果是纯前端项目请直接跳过”。有一个领域让我特别犯怵——如果你在写技能的时候发现某些表述得不太对劲那就说明这块内容本身就不是技能该管的范围。这就是我不太碰所谓“网络加速类技能”的原因一是这类东西边界不清二是容易掺和灰色地带直接把范围收缩到本职工作最安全。第三个坑是技能文件命名和内部引用不一致。我早期写的技能里脚本文件路径写错了大小写Agent 执行时找不到脚本直接全过程失败。现在我的习惯是每个脚本都在 SKILL.md 里给出一个“自检命令”让 Agent 在执行前先验证脚本可运行。5.4 自己写完后的验证闭环写完技能别急着去干活先做一轮自验证新建一个测试项目把技能放进项目级.claude/skills目录直接用中文描述一次完整任务看它是否自动调用技能检查技能的每一步是否按预期执行记录卡住的环节执行完检查输出是否符合验收标准回到 SKILL.md 修补问题重新启动会话再测。这个闭环我每次都会跑别嫌麻烦。一次没跑通后面每次用都是半吊子状态数不清要浪费多少时间。自己在测试中改了三轮的技能和直接照搬别人但没做过任何适配的技能在使用体验上差距巨大。6. 装多了之后的清理、管理与团队协作很多人一开始和我一样见到什么技能都往目录里塞一个月之后~/.claude/skills下躺了几十个目录。然后问题来了Agent 加载技能时面临大量选择反而会犹豫甚至误触发不相关技能最终拖慢任务。6.1 tibo 式清理法盘点、分级、移出社区里整理了一套清理方法我管它叫“tibo 式三段清”核心就是三步第一步全面盘点。用这条命令列出所有技能以及最后修改时间find ~/.claude/skills -name SKILL.md -exec stat --format%y %n {} | sort第二步按使用频率分级。过去两周内用过的技能保留在目录内偶尔手动触发的技能移到独立目录做“备胎区”超过半年没碰过、且不属于你当前业务方向的技能直接删除。删除前记得看看是不是原仓库还能再拉回来能拉回来的都可以放心删。第三步合并同类项。社区里存在大量功能重叠的技能比如“代码审查-reviewers”“git-commit-message-format”这类。我一般会保留功能最全、维护最勤的那一个然后把其他的从加载目录中移出。如果你担心以后用得上就丢进~/.claude/skills-archive/目录既不影响加载也不会丢。6.2 版本的锁定与团队共享skills 毕竟是代码仓库有版本问题。如果团队里共用一套技能直接用最新版很危险——今天更新了脚本逻辑明天大家的 Agent 行为变了之前的产出风格全乱套。我的经验是固定到具体 commit。比如技能集仓库在某个时间点验证最优那么团队 README 里明确写出当时安装的 commit id新成员一律安装指定 id而不是自己拉最新的。cd ~/.claude/skills git clone repo-url git checkout commit-hash团队共享方面我更推荐把技能集放进一个独立的内部仓库然后通过 marketplace 的方式统一管理。这样一个技能更新了只需要维护仓库本身其他成员用/plugin update拉一下即可不用挨个机器去同步文件。6.3 我自己踩过的坑同名冲突与自动加载失灵挑三个我觉得最有代表性的给正在折腾的人提个醒。第一个坑是同名技能冲突。我之前装了两个都叫code-review的技能一个来自 Superpowers一个来自另一个个人仓库。Claude Code 加载时只加载了其中一个而另一个的个性化配置完全没生效。排查了半天才发现是同名覆盖问题。现在我的原则是同一功能向只保留一个技能非留不可时会把其中一个改名并同步改掉 frontmatter 里的 name。第二个坑是目录层级不对导致加载失灵。我把一个从网上下载的技能包直接解压到~/.claude/skills/没注意解压出来多包了一层目录。结果 Agent 扫描的时候发现下面没有 SKILL.md只有一堆子目录整个技能直接变成无效目录。第三个坑是忽略技能仓库里自带的依赖。有些技能包带 scripts 的 Python 依赖需要pip install -r requirements.txt。技能说明文档通常写得很清楚但着急用的时候很容易跳过。之后 Agent 调用脚本时直接报 ModuleNotFoundError。现在我把所有用到脚本的技能都记录在案装完立刻跑一次自检命令。6.4 给 sets 的“最小可用配置”建议如果你不想一开始就上手折腾这么多我建议按这个最小化方案起步装 1 个代码审查技能 1 个 Commit 信息生成技能 1 个你业务最核心的流程技能即可。再多就容易陷入我刚才说的“技能多但触发不稳定”的怪圈。先用最小配置跑通一个完整项目理解 Agent 在加载技能时的行为然后再按需扩充。记住技能的价值是让你重复的工作流程得到固化而不是让你陷入技能管理的泥潭。一个能让你一天少花两小时整理流程的技能集比一百个装在目录里吃灰的技能有用得多。这些年我用 AI 编程工具有一个很深的体会模型能力决定了水平下限而 skills 的配置质量决定了水平上限。与其花大量时间去找“更聪明的模型”不如把手头这套技能体系打磨好。装几个值得信任的技能包自己再按业务场景写几套再把目录清理得井井有条这个过程中获得的理解比单纯追新版本工具值钱得多。