先说个有意思的现象。Claude Code 火了大半年我身边不少人卡在同一个阶段装好了跑通了然后不知道让它干什么。模型再强你不好好描述任务它也就是个漂亮的聊天框。直到有人甩给我一个聚合站里面七万多个现成的 Skills从给前端项目写规范的 commit message到安卓 APK 脱壳应有尽有我才意识到这东西的生态已经膨胀到超出多数人的认知了。这篇就写写这类 Skills 聚合站怎么用、怎么从 7.7 万里筛出真正要的东西、装完之后怎么在 VSCode、桌面版和终端里顺畅跑起来顺便聊聊换第三方模型之后 Skills 会不会失灵以及我建议你最后自己动手写一个的最小骨架。适合刚入坑 Claude Code 的开发者也适合已经在用但总觉得差点意思的老手。1. Skills 突然溢出之前Claude Code 生态到底发生了什么1.1 理解 Skills 之前得先理解 Claude Code 是什么Claude Code 是 Anthropic 官方出的终端 Agent 编程工具不是 IDE不是一个插件而是一个跑在命令行里的智能体。你给它一句话帮我看看这个项目里为什么登录接口偶发超时它会自己读代码、查日志、改文件、跑测试全程在终端里完成。它更像一个坐在你工位旁边的结对程序员而不是一个自动补全工具。但这里有个天然的短板模型本身没有工作习惯。今天你让它按团队规范写提交信息它可能写得花里胡哨明天你让它做前端可访问性审查它可能漏掉一半关键点。恰恰是这些重复性、流程化、带有个人经验色彩的东西比单纯写代码更值得沉淀。Skills 就是干这个的。Skills 本质上是把一个特定任务的系统提示词、参考示例、辅助脚本打包成一个可复用的技能包。装进~/.claude/skills目录它就变成全局技能装进项目的.claude/skills目录它就只对这个项目生效。Claude Code 在每次会话启动时扫描这些目录把匹配的 Skills 信息注入上下文让模型知道我有这些工具可用遇到对应场景时应该按里面约定的流程来做。1.2 从官方十几个样例到社区七万多个膨胀速度超出想象早期 Claude Code 刚开放 Skills 的时候官方文档里只有十几个示例大部分还是怎么给 Claude 写邮件这种简单场景。那时候我觉得这东西的价值不大因为它只是把提示词结构化并没有带来本质变化。转折发生在社区开始大量贡献之后。前端开发、运维排查、论文写作、安卓脱壳、区块链审计、飞书消息发送各种垂直场景的 Skills 像雨后春笋一样冒出来。数量达到一个阈值之后生态就变了你不需要自己写你要先学会找。再后来就有了我开头说的那种聚合站把分散在 GitHub 仓库、Gist、个人博客里的 Skills 集中收录、打标签、做搜索数量标记到了 7.7 万这个量级。这个量级带来的不是方便首先是混乱。你搜一个commit message能出来几十个结果名字差不多、功能有重叠、质量天差地别。所以与其说这 7.7 万是资源库不如说它是个装修市场——东西很多但你需要懂行才能淘到好货。1.3 Skills 与普通 Prompt、插件到底差在哪很多人问过我同一个问题我把一段很好的 Prompt 存进笔记里下次复制粘贴给 Claude Code这不就是 Skill 吗不是。普通 Prompt 是一次性的Skill 是结构化的、可复用、可共享的资产。区别我用一个表格说清楚。维度普通 PromptSkills载体聊天框或笔记目录 文件 可选脚本上下文注入每次手动粘贴自动扫描、按需加载可编程性无仅文本可带 Python/Shell/JS 脚本共享方式复制文本发布到市场/GitHub版本管理团队协作靠口头约定目录提交到仓库所有人同步触发时机模型随机理解规则匹配 模型判断双重触发这个区别决定了 Skills 能承担更复杂的任务不只是说一段话而是规定流程 执行脚本 校验输出。这也是为什么后来那么多人在 VSCode 配置、桌面版、LMStudio 本地模型这些话题里反复讨论 Skills——因为它已经从提示词技巧变成了真正的工程资产。2. 这个聚合站到底做了什么从大海捞针到橱窗购物2.1 聚合站的核心功能拆解先明确一下这里说的聚合站并不特指某一个网站而是这类集中收录 Skills 的平台的总称。它们通常长得很像功能也大同小异核心就四块搜索、分类、详情、安装。搜索支持关键词和语义匹配比在 GitHub 上硬搜体验好太多分类一般按场景来前端、后端、运维、安全、AI Agent、办公自动化点进去就是某个垂直领域的一堆技能详情页会展示这个 Skill 的说明文档、依赖要求、示例用法、作者信息、收藏和下载量。安装环节是这类平台最花心思的地方。多数平台会在详情页直接给出一段命令比如cc skill install 作者/仓库名或者一段git clone加目录拷贝的脚本复制到终端跑一下就能装好。我见过有的平台甚至支持一键把 Skill 配置写入项目目录连路径都不用你想。2.2 从 7.7 万 Skill 里挑出你需要的看这五个指标逛这种站最忌讳的就是像逛淘宝一样一路刷下去。我自己的筛选逻辑固定成五步分享出来你直接用。先定问题再搜索在搜索框里输入的不是技能名而是你要解决的问题。比如我要给前端项目按 Conventional Commits 规范自动生成提交信息就搜conventional commits不要搜commit skill这种宽泛词。看更新时间Claude Code 本身更新非常频繁API 和 Skills 规范也在演进超过三个月没更新的基本可以放弃。聚合站里每个 Skill 的更新时间就是生命线。看依赖描述是否清楚一个好 Skill 会在说明里明确列出依赖哪些工具。如果一个 Skill 宣称能做安卓脱壳却不提需要apktool和jadx那大概率是作者没认真写实现质量也堪忧。看示例和测试有没有给出明确的输入输出示例有没有提供自测脚本。有示例的 Skill 装上之后你能快速验证没有示例的只能靠猜。看争议和 issue 区真实用户留下的报错和反馈比 README 值钱一万倍。同一场景下issue 区活跃且有作者回应的 Skill靠谱程度远高于安静得像坟墓的那个。2.3 官方市场、聚合站、GitHub 直搜三者对比很多人问我到底该在哪儿找 Skills我的回答是三个渠道都要用但用法完全不同。渠道优势劣势适合场景官方市场质量有审核与版本兼容性好数量少更新节奏慢核心稳定场景团队统一标准第三方聚合站数量大搜索方便分类清晰质量参差需要自己判断探索新场景、找灵感GitHub 直搜一手信息能看到完整开发过程搜索体验差筛不出来深度研究特定作者或技术方案我的习惯是在聚合站发现一个感兴趣的 Skill 之后回到 GitHub 看它的仓库——看 commit 历史、看作者其他作品、看 issue 讨论确认质量没问题再装。聚合站是入口GitHub 是验货场。3. 从找到到用上安装和跨平台配置的全链路3.1 全局安装和项目级安装别搞混了Skills 的安装位置直接决定它的生效范围这是新手最容易懵的地方。全局目录是~/.claude/skills所有项目都能用适合装那些与具体代码库无关的技能比如写邮件、整理会议纪要、生成周报。项目级目录是.claude/skills只对当前项目生效适合装跟这个项目绑定的技能比如 按本项目规范生成后端接口文档。优先级上项目级 Skills 会覆盖全局同名 Skill这一点要记住。所以如果同一个 Skill 你需要不同版本项目级是覆盖机会如果你不希望项目里某个同事的配置影响你的习惯项目级目录也是隔离工具。我见过不少人把全局目录塞满了几百个 Skill结果每次会话上下文被撑爆Claude Code 变慢、响应质量下降。教训就是全局只装高频通用技能项目特定的一律进项目目录。3.2 最常见的三种安装方式按场景选第一种是直接在聚合站或 GitHub 复制安装命令一般是git clone到对应目录。这种方式可控性最高你知道自己装了什么东西想卸载就删目录。第二种是使用内置的市场安装命令比如cc skill install 名字好处是自动处理路径和依赖坏处是你对安装内容不可见遇到问题不好排查。第三种是手动创建目录、写SKILL.md、放脚本文件这是给后面要自己开发 Skill 的人准备的前面两种都有现成模板时没必要手动来。我在实际使用中大部分场景用第一种。原因很简单我想知道自己把什么放进了机器里。尤其装的 Skills 涉及脚本执行时我会先git clone下来通读一遍代码确定没有奇怪的网络请求或高危操作再放进去。这可能有点过度谨慎但装第三方技能这件事谨慎永远不亏。3.3 macOS、Windows、Ubuntu 和开发工具链里的配置差异不同平台上安装和配置 Claude Code 的方法大同小异差异主要在环境适配。macOS 和大多数 Linux 发行版比如 Ubuntu最省事直接装好 Node.js 环境然后全局安装 Claude Code 的 npm 包通过命令配置好 API 密钥就能开始用。Ubuntu 上如果缺少权限sudo npm install -g是最直接的解法但要注意如果之前用过nvm全局路径已经有冲突的话需要先确认当前 Node 版本环境。Windows 的坑相对多一些。原生终端PowerShell下使用 Claude Code 时执行策略可能默认禁止运行脚本常见的做法是给当前用户放开权限或者直接用 WSL 环境。而且 Windows 路径分隔符和类 Unix 环境不同如果 Skill 脚本里写死了/tmp之类的路径在原生环境下会失败。所以 Windows 用户我强烈建议优先用 WSL 运行 Claude Code能少踩大多数坑。VSCode 和桌面版的配置思路也一样。VSCode 里安装官方插件后要把 Claude Code 的可执行文件路径配置进插件设置确保插件调用的与你命令行里用的是同一个版本。桌面版则更图形化一些Skills 目录可以直接通过设置面板打开拖拽文件夹进去就能识别。另外注意到有人提到 Clauode Code 官方文档中有地区可用性说明如果你所在的网络环境访问官方源不稳定大概率是网络可达性的问题不是代码问题。这种情况下可以找社区维护的镜像包或第三方仓库或者干脆本地git clone官方仓库离线安装。桌面版和 VSCode 插件几乎都会暴露使用本地模型的入口我们不展开说网络问题但有一条经验是通用的安装任何跟网络有关的东西耐心检查错误日志看报错中断在哪一步比反复重装有效得多。3.4 装完怎么验证是真能用而不是看起来装了装完 Skill 第一个动作就是验证。终端命令行里敲/skills会列出当前环境扫描到的所有可用 Skills。能看到名字只是第一步关键要看它能不能被真正触发。我的验证流程是三步先在一个临时测试目录里建个demo文件然后用一句贴近该 Skill 应用场景的自然语言指令让 Claude Code 执行比如装的 commit message 规范类 Skill就用帮我看看这个 git 仓库的提交信息是否规范来触发它。最后看它有没有按照 Skill 里定义的流程输出。如果输出内容里带出了 SKILL.md 中特有的步骤或措辞说明加载成功如果它的回答跟没装 Skill 时一模一样那就是没触发先检查目录命名是否规范再看 Skill 文件是否有语法错误。4. 搜索 7.7 万个 Skills 时你不能只看名字4.1 最典型的三个坑同名竞争、依赖缺失、版本失效技能多了坑也比想象中多。第一个坑是同名不同命。你搜前端开发 skill出来的几十个结果可能根本不是同一个东西——有的是规范 HTML 语义化有的是自动化生成 React 测试还有的是 CSS 优化建议。名字都差不多功能南辕北辙。看清描述字段比看名字重要一万倍。第二个坑是依赖没有写清楚。我真实遇到过想找一个安卓脱壳相关的 Skill详情页写得天花乱坠装完才发现它默认你安装了apktool、jadx和特定版本的frida而这些依赖全都没写进说明里。等跑起来报错再回头去 GitHub 看代码才发现作者在一个藏在很深的目录里的 README 提了一句。所以我现在装任何 Skill 之前会先翻它的仓库确认依赖列表是完整的再装。不是每个作者都想让你用起来顺利的很多一键安装其实是一键开始排错。第三个坑是版本失效。Claude Code 版本迭代非常快Skills 规范也会跟着变。三个月前还能正常跑的 Skill可能因为某个 API 字段废弃就彻底失灵了。这跟库版本依赖还不一样——它可以毫无征兆。我的止损方法是装 Skill 时记录它的获取日期和版本号一旦它开始报错先去仓库看是否有针对新版本的提交记录没有就直接卸载别留恋。4.2 快速判断一个 Skill 作者靠不靠谱看这四处README 的完整度描述、依赖、示例、常见问题缺一不可的多半靠谱只有两行描述的别抱幻想。目录结构是不是标准的三件套SKILL.md、scripts、references。结构清晰说明作者理解 Skills 规范不是随手扔一个文档进来凑数。issue 区的互动作者有没有回应用户的提问遇到兼容性问题有没有发新版本。这是判断项目是否还活着的黄金指标。代码注释和脚本风格如果脚本写得规范、有注释、有异常处理说明作者是认真对待这件事的如果是一段没有注释、没有错误处理的裸代码遇到意外情况基本就废了。4.3 我的搜索心法先建需求池再进场搜在聚合站里漫无目的地翻效率极低。我自己的搜索流程是先建需求池——把最近两周高频遇到的、适合交给 Claude Code 做的事写下来列成清单。比如规范 git commit生成 Changelog为 Node 项目做安全检查。然后拿着清单一个个去搜索栏里问把每张清单对应的候选 Skills 收藏下来最后统一对比而不是当场看到哪个好就装哪个。这个习惯帮我挡掉了大量看着不错但实际用不上的冲动安装。从 7.7 万里找到对的那一个本质不是搜索技巧问题而是你知不知道自己要什么的问题。我用这个方法最终从几十个有用没用的候选里固定下来三个高频技能其余的全放下Claude Code 的表现反而比以前装了二十个的时候好了不止一个档次。5. 第三方模型接入之后Skills 会不会失灵5.1 Skills 与模型解耦的本质换模型不会禁用 Skills但效果会变Claude Code 本身是支持通过第三方 API 或本地模型来驱动的比如有人用LMStudio拉本地模型有人用cc switch把后端切换到 DeepSeek、Qwen、GLM 这类模型。很多人担心换了模型之后 Skills 就失效了这个理解对了一半。先说结论Skills 机制本身与模型无关。Skills 的本质是系统提示词 脚本 参考文件的组合Claude Code 在每次启动时把匹配的 Skills 内容注入上下文然后由模型决定怎么调用。所以换第三方 API 之后Skills 还会加载、还会触发但你实际体验到的质量会大幅波动。关键在于模型遵循指令的能力。Skills 经常会写一些复杂的流程步骤先读取 A 文件再执行 B 脚本比对输出结果如果满足 C 条件就继续否则回退到 D 方案。像 Claude 这种在指令遵循上做得好的模型能稳稳把整个链路走完换成某些本地小模型它可能走一半就忘了 C 条件或者干脆自作主张跳过 B 脚本直接给你输出一个看似合理但实际没执行过的结果。5.2 切到第三方模型时优先选结构简单的 Skill基于这个现实如果你要用第三方 API 或本地模型跑 Claude Code我的建议是三句话。第一选脚本驱动型Skill少选纯提示词型Skill。前者把核心逻辑写进了脚本模型只负责判断何时运行脚本容错率更高后者把核心逻辑全压在模型的理解和记忆上模型弱一点就全盘崩。第二选步骤短Skill。步骤越少模型偏离的概率越低。一个三步走的 Skill 和一个十二步走的 Skill在弱模型上的表现差距远超预期。第三别在本地小模型上跑那些需要大量代码阅读的 Skill。比如对整个代码库做 OWASP 安全检查这种 Skill对模型上下文长度和推理能力的要求极高换到 7B、8B 量级的本地模型上除了浪费时间就是给你错误的信心。5.3 用 cc switch 之类的切换工具时要关注什么这类工具的本质是把 Claude Code 的请求端点从 Anthropic 官方换到其他兼容服务通常是改环境变量或配置文件让 Claude Code 以为自己在和 Anihropic API 通信实际上流量走到了第三方网关或本地服务。很多人切换完之后第一件事就是挂着 ClauCode CLI 版本号去对比模型输出但我更建议把注意力放在 API 返回格式的差异上。不是所有兼容服务都百分之百实现了 Anthropic API 的字段语义。我自己遇到过一种情况某个 Skill 内部用脚本解析模型返回的 JSON 结构在官方模型下一切正常切到 Qwen 之后字段层级变了脚本直接崩。这不是 Skill 本身有问题是模型风格和输出格式的差异被低估了。所以建议在切换模型之后先跑一遍你常用的核心 Skill确认它们的脚本不依赖某个特定模型的输出格式。如果确实依赖要么换 Skill要么给模型加约束性提示词而不是幻想API 兼容就万事大吉。6. 看完 7.7 万个之后我建议你动手写一个6.1 为什么写得出来的才算真懂逛了这么久聚合站装了删、删了装我最后悔的一件事就是没有更早动手写自己的 Skill。直到有一天我需要一个把飞书群消息按项目维度自动整理成周报的技能找遍所有平台都没有特别满意的实现我决定自己写一个。写完之后我才发现真正理解 Skills 的触发机制、目录规范、脚本边界靠的是动手而不是看文档。很多 Skill 问题其实是你自己写着写着就会发现答案的。比如为什么有些 Skill 在同一个会话里不会被重复触发为什么 Claude Code 不先运行脚本而是先问你确认为什么每次对话都要重新注入一遍上下文——这些疑问在你动手写作的过程中会自然解开比你倒回去读十遍规范文档有效得多。6.2 最小可用 Skill 的骨架直接抄这个一个最小 Skill 并不复杂核心就一个SKILL.md文件和可选的一个scripts目录。先创建一个目录名字就是你的技能名比如weekly-report。然后在目录里建SKILL.md内容结构如下。--- name: weekly-report description: 将散落在飞书群/聊天记录中的本周工作内容汇总成结构化周报。当用户说“整理周报”“汇总本周工作”或提供聊天记录时使用。 --- # 周报生成 ## 适用场景 - 用户提供了散乱的工作记录要求整理成周报 - 用户要求按项目维度汇总本周进展 ## 处理流程 1. 阅读用户提供的原始素材或聊天记录 2. 按“项目/模块/本周进展/下周计划/风险与阻碍”五段结构整理 3. 遇到模糊信息时在周报末尾添加“待确认问题”清单 ## 输出格式 使用 Markdown 表格呈现项目维度每个项目单独一个二级标题description字段是触发关键。Claude Code 会在每次会话启动时扫描所有 Skill 的description当用户的当前意图与之匹配时才把这个 Skill 的完整内容加载进上下文。所以description写得太窄会导致该触发时没触发写得太宽会导致不该触发时浪费上下文需要反复调。如果需要脚本参与就在SKILL.md同级建scripts目录放你的 Python 或 Shell 脚本。Skill 允许在流程中用特定语法调用脚本并把脚本输出作为上下文的一部分。我的经验是脚本的职责越单一越好最理想的状态是模型负责决策什么时候跑脚本脚本负责把所有确定性的事情做完。6.3 写完怎么自测以及发布时要注意什么写完 Skill 马上装到项目里测试测试方法同前面说的一样用一两句贴合场景的话触发它。重点观察两件事一是它有没有被正常触发也就是看输出是否带了 SKILL.md 里的格式痕迹二是触发后读取的上下文是不是你预估的量如果只是几步操作却把大量参考文档拖进来说明description写得太宽泛了。自测通过之后如果你觉得它值得分享可以提交到聚合站或独立发到 GitHub。发布前检查三样东西name是否语义明确、description是否包含足够多的触发场景词、scripts里的依赖是否明确写进了 README。这里面name最容易被人忽略——很多人在聚合站上搜索时习惯直接搜名字所以好名字能显著提升你 Skill 被找到的概率。命名规则我建议是场景 动作结构比如commit-message-standardizer而不是git-helper。最后说一点个人感受。我在这个 7.7 万的生态里泡了这么久最大的体会是Skills 数量的多少根本不重要真正重要的是你把哪几个装进了每日工作流并且愿意花时间把属于自己工作方式的技能沉淀下来。与其囤积一百个看着有用的技能不如认真挑三个高频场景把自己从被工具支配的状态里解放出来然后自己写一个真正属于自己的东西。到那个时候你回头看就会发现这 7.7 万个与其说是资源库不如说是一群开发者在把自己踩过的坑、养成的好习惯以代码的形式留给了后来的所有人。