装上40个 Skill 后，我才算真正会用 Claude Code

如果你也在用 Claude Code先别急着说我标题党。过去我一直把它当成一个“能看懂项目代码的终端助手”让它写点脚本、改个 bug、跑个测试感觉已经挺香了。但直到我花了一个周末陆陆续续给 Claude Code 装了 40 个 Skill我才发现之前的用法基本等于白给——明明工具箱里全是电钻我却一直拿它当锤子使。这篇文章把我从“装 Skill 之前”到“装完 40 个 Skill 之后”的完整路径捋一遍包括 Skill 和 Agent 到底什么区别、优质 Skill 去哪儿找、怎么手动把 GitHub 上的 Skill 搬进本地、哪些 Skill 装上以后是真香、哪些纯属凑数以及我翻车之后总结的排查技巧。适合刚接触 Claude Code 的萌新也适合已经用了一段时间但一直把 Skill 当普通提示词的老用户更适合理想在 VSCode 里把 Claude Code 变成主力开发环境的实践派。1. 先搞清楚 Skill 是什么别拿它当高级提示词1.1 Skill 与普通提示词的本质差异很多人第一次接触 Skill 的时候第一反应是这不就是预设提示词吗我刚开始也这么想但真正用下来才发现提示词是“说给模型听的一句话”而 Skill 是一整套“带约束、带流程、带输出规范的可执行知识包”。打个比方提示词像是你临时告诉厨师“今天做个辣一点的川菜”而 Skill 是直接递给厨师一本装订好的菜谱里面除了配方还有食材采购清单、处理顺序、火候要求、摆盘标准甚至验收标准。在 Claude Code 的环境里Skill 通常落到一个目录中目录里不仅有一个 SKILL.md 作为说明书还会带上示例文件、模板、脚本、参考文档等等。激活之后模型不仅知道你要求它做什么还知道完成这件事的完整上下文、公司内部约定、命令用法和检查清单。这种“上下文密度”的提升是单纯在输入框里堆字没办法比的。1.2 Skill 和 Agent 的分工边界装 Skill 的过程中经常有人问这跟 Agent 有什么区别这里我说一下自己的理解。Agent 强调的是“自动决策和执行闭环”——给它一个目标它可以自己拆任务、调工具、看结果、决定下一步。Skill 则更像“能力包”或者“经验包”——它不强调自主决策而是强调把某类任务的方法论沉淀下来让模型调用时按固定套路输出高质量结果。所以这两者不是二选一的关系。Agent 可以用 Skill 作为自己的“工具箱”Skill 也可以内嵌一些 Agent 式的指令来完成自动化环节。比如我自建的仓颉类型项目里有一个专门负责代码评审的 Skill它会先跑静态检查、再看仓库约定、最后按评分表输出评审意见每一步都是自动执行但从结构上讲它依然是一个 Skill。理解了这个边界你就不会再去纠结“到底要不要把所有东西都改成 Agent”而是会自然地按任务类型去选择合适的载体。1.3 我给 40 个 Skill 做的分类装 40 个 Skill 之前我给自己定了一个原则不允许重复造轮子同一个方向只保留一个最合适的。我大致分了六类——开发与编码类包括前端最佳实践、后端脚手架、代码评审、TypeScript 迁移、自动化测试生成这类。写作与内容类包括技术博客、中英文润色、SEO 标题、书籍结构化整理之类。效率与工作流类比如会议纪要、任务拆解、信息检索、知识库整理、时间管理。科研与学术类数学建模、论文检索、文献综述、公式排版、数据可视化图表规范。演示与设计类PPT 结构生成、原型说明、架构图绘制、流程图绘制。语言与学习类语言学习陪练、术语对照、翻译审校、口语化改写等。分类这个过程本身就很有价值因为你装完 Skill 之后真正决定好不好用的不是数量而是“模型能不能快速找到合适的那个”。后面我会专门讲怎么给 Skill 写描述让它在正确场景下能被自动匹配到。2. 40 个 Skill 从哪里来官方源、社区源和 GitHub 手动安装2.1 Skill 的目录结构与安装原理先别急着到处找“一键安装包”你得先理解它为什么能生效。Claude Code 在启动时会扫描指定的 Skill 目录然后把这些目录里的 SKILL.md 描述信息加载进模型可感知的范围。换句话说Skill 不是编译进程序里的而是“运行时被检索到”的。检索的依据主要是文件名、描述字段和目录名里的关键词。常见目录结构是这样的skills/ ├── code-review/ │ ├── SKILL.md │ ├── rules.md │ └── templates/review_template.md ├── blog-writing/ │ ├── SKILL.md │ └── examples/example_post.md └── meeting-notes/ ├── SKILL.md └── scripts/format_notes.py每个子目录就是一个 Skill目录名就是它的唯一标识。SKILL.md 里一般写三块内容它是什么、什么时候用、怎么用。有些社区 Skill 还自带 script 或 template模型在执行过程中可以调用这些文件而不是把一堆东西硬塞进上下文里。2.2 从 GitHub 手动安装 Skill 的完整步骤我实测下来手动装一个 GitHub 上的 Skill流程一般是这样的先在 GitHub 上找到目标仓库确认它的目录里有没有 SKILL.md以及最近是否还在更新。把仓库 clone 到本地或者直接下载 ZIP 包。在 Claude Code 配置里指定 skills 目录比如~/.claude/skills然后把你需要的 Skill 子目录复制进去。重启 Claude Code让它重新扫描 Skill 目录。在会话里用自然语言描述你的需求观察它是否自动匹配到这个 Skill。听起来挺简单但实际容易翻车的地方在于很多仓库是“一个仓库放几十个 Skill”你直接整个 clone 下来里面可能混着大量示例、脚本、测试文件。这时候你就需要手动挑选只把带 SKILL.md 的子目录放进你的 skills 目录。2.3 怎么判断一个 Skill 靠不靠谱装多了你就会发现社区里 Skill 质量参差不齐。我现在一般用四个标准过滤描述写没写清楚如果 SKILL.md 第一段就告诉我适用场景、输入格式、输出格式那它大概率靠谱。有没有示例好的 Skill 会附一个 example 或 demo能直接看出模型调用后的效果。维护时间超过三个月没更新、issues 没人回建议直接放弃。有没有依赖外部服务有些 Skill 需要调第三方 API 才跑得动如果接口文档不明确我建议别碰否则后期排查问题会很痛苦。这个筛选标准帮我避免了大量垃圾 Skill。40 个看似很多但我是从上百个候选里挑出来的。3. 真正值得装的 6 类 Skill 推荐40 个里挑重点说3.1 开发向vue-best-practices、codex 这类为什么必装如果你是前端开发者vue-best-practices 这类 Skill 装上以后Claude Code 生成的 Vue 代码会自动遵循组件命名规范、props 校验、状态管理分层等约定而不是每次都给你一套“能跑但很难维护”的代码。这个 Skill 的效果不在于它有多聪明而在于它把团队规范前置了模型每次生成都带着“标准答案”来写。codex skill 可能很多人也听说过。它本质上不是让 Claude Code 去调用 OpenAI 的 Codex而是定义了一套“在 Claude 环境里模拟 Codex 式任务拆解和代码检索”的思路。对我这种需要同时对比不同模型输出风格的人来说它最大的价值是提供了一种结构化的任务分解模板让复杂需求不会漏掉某个环节。3.2 写作与内容向book to skill、impeccable 的使用感受book to skill 是我最近发现的一个很有意思的项目名字带点“把书变成技能”的意思。它的思路是把一本专业书里的核心方法论提炼成结构化 Skill 文件比如把《金字塔原理》变成“结构化表达 Skill”以后你写方案、写汇报时模型会自动按结论先行、分类分组、逻辑递进的方式来组织内容。这对靠写文档吃饭的人来说简直是刚需。impeccable skill 则更像一个“内容质检员”。它主要用来校对你的英文表达、语法、标点和语气。我试过让它润色一篇技术博客摘要它不只会改语法错误还会把同一句话按“正式版、口语版、严谨学术版”各给一版让你自己选。这个设计很聪明因为它的目标不是取代人而是减少你从头写的时间。3.3 效率与工作流向ponytail、workbuddy、仓颉分别解决什么问题ponytail 这个 Skill 光看名字你可能猜不到它干嘛它更像一个“上下文记忆增强器”。它的核心能力是帮你整理一段对话里的关键信息生成结构化摘要并把待办事项、决策结论单独拎出来。我一般会在开完长会后用它做总结比我自己翻聊天记录快得多。workbuddy 是偏“工作流编排”的 Skill。它能把一个复杂任务拆成若干子任务并按依赖关系排好序。比如“做一个项目周报”它会自动把信息收集、数据分析、图表生成、报告排版拆成四步每一步还可以单独执行。这个 Skill 适合那种“需求很大、无从下手”的场景先把骨架搭出来再往里面填肉。仓颉 Skill 是我在中文项目里用得比较多的一个主要作用是规范中文技术文档的写作风格。它会让模型注意专有名词大小写、中文和英文之间是否加空格、避免“的、地、得”误用、统一技术名词翻译等等。对中文开发者社区来说这类 Skill 的实用价值很高因为它解决的是细节但很烦人的问题。3.4 科研与学术向数学建模、论文检索类 Skill 怎么配合科研方向的人装 Skill 一定不要只看“论文生成”类的更要看“论文检索”和“论文结构化理解”类的。比如我在做文献综述时会让 Skill 先按“问题定义—方法分类—实验对比—结论总结”的框架去读一篇 PDF而不是直接把全文扔给模型让它“总结一下”。后者虽然也能输出摘要但前者能直接把内容拆成可引用的结构化笔记。数学建模类 Skill 也很实用它内置了一套“建模问题求解流程”先明确变量和约束条件再选择模型类型然后给出求解方案和参数敏感性分析。用这种 Skill 生成的内容比直接让模型“帮我解这道题”要严谨得多因为模型会主动检查单位是否一致、边界条件是否完整。3.5 演示与可视化向show me、grill 这类怎么快速出图show me 这类 Skill 核心是“把文字变成可视化表达”。你给它一段流程说明它能生成架构图、流程图或者幻灯片大纲。我用它做技术方案汇报时最常用的是“把这段需求描述转成一张系统架构图”输出可能是 Mermaid 语法也可能是 HTML 页面模板。它的好处不是图多精美而是结构不会漏因为它是按逻辑关系一步一步描述出来的。grill 这个 Skill 比较有意思名字像“烧烤”实际是“追问和拷问”的意思。它会在你给出方案后站在反方角度提出一堆质疑帮你把方案里模糊的地方提前暴露出来。我用它做技术选型评审时非常上瘾因为它能把 “为什么选这个数据库”“容灾方案是什么”“成本增长曲线怎么评估”这些问题全问出来逼着你想清楚再动手。3.6 语言学习与特色向哪些 Skill 是氛围组哪些是真能落地语言学习类的 Skill 我装过几个效果最稳定的反而是那种“角色扮演 语法纠错”的组合型 Skill。它会把对话场景固定下来比如模拟面试、模拟客户沟通同时在对话结束后集中给一份语法修改反馈。缺点是它没法真正解决发音和听力问题所以更适合用来练口语表达逻辑。还有些 Skill 属于“氛围组”装上以后基本想不起来用比如一些过于娱乐化、或者纯粹为了展示技术堆叠的 Skill。我的建议是如果你发现某个 Skill 连续两周都没被触发过直接删掉。40 个听着多但真正高频使用的可能不到 15 个。4. 装完 40 个 Skill 后Claude Code 的正确打开方式4.1 工作流的变化从“手动命令”到“Skill 调度”装 Skill 之前我的使用习惯是打开 Claude Code 之后手动敲命令告诉它“帮我看看这个文件哪里有问题”。装完之后我发现自己变成“调度员”了我会直接说“用代码评审 Skill 看这个 PR”或者“用周报 Skill 把这几天的 commit 整理一下”。这个转变很微妙但效率提升是实打实的。因为 Skill 里已经写清了全套流程模型不需要一步步问你“要不要跑测试”“要不要检查 lint”它会按照 SKILL.md 里的步骤自动把该做的检查做完最后给你一份结构化报告。你只需要在最开始把需求说清楚后面基本不用管。4.2 VSCode 里配置 Claude Code 与 Skill 联动如果你跟我一样主要用 VSCode我发现把 Skill 和 Claude Code 的 VSCode 扩展配合起来体验会好很多。操作上没有想象中复杂在 VSCode 扩展市场安装 Claude Code 官方扩展并确认命令行里 claude 命令可用。在项目根目录或用户目录下创建skills文件夹。把 Skill 子目录放进去并在 Claude Code 配置里指定该目录。在 VSCode 打开项目后直接用 Ctrl 唤起终端运行 Claude Code让它在项目上下文里自动扫描 Skill。如果是多项目同时开发我建议把通用类 Skill 放在用户级目录把项目专属 Skill 放在项目级目录避免互相污染。这样配好之后你选中一段代码直接在 Claude Code 里说“用 best-practices Skill 帮我 review 这段”它会把整个仓库约定、Skill 规范和当前选区一起拿来做分析上下文完整度比开一个独立网页版高很多。4.3 让 Skill 和不同模型源配合使用关于 Claude Code 接入 DeepSeek 这件事我多说一句很多人担心换模型之后 Skill 就失效了其实不是。Skill 本质上是一套纯文本的规范文件模型只要支持读取文件内容并理解指令就都能配合。DeepSeek 这类模型在代码理解上并不弱用同一套 Skill 也能跑通。不过我也发现一个差异不同模型对 Skill 的“服从程度”不一样。有的模型会老老实实按 SKILL.md 的步骤走有的模型则会“自由发挥”跳过一些步骤。遇到这种情况我的解决办法是在 SKILL.md 里增加一个“执行顺序检查清单”并且要求模型在输出开头先声明自己会按哪些步骤执行。你可以在描述里写清楚“如果没有特殊情况必须严格按照以下顺序执行不得跳过”语气可以硬一点。5. 踩坑实录Skill 不生效、路径错误、版本冲突怎么办5.1 最常见的问题与排查表我装完 40 个 Skill 之后遇到过的问题基本可以归成四类直接整理成了一张速查表症状可能原因解决办法Skill 完全不生效模型像没见过它目录名不对或者 SKILL.md 文件命名不匹配检查目录下是否为 SKILL.md注意大小写描述能看见但模型从不主动调用描述里关键词太泛模型匹配不到重写描述加入触发场景、关键词和输入示例调用之后执行步骤乱SKILL.md 缺少强制顺序说明增加“执行顺序”和“不得跳过”的硬约束装了新 Skill 之后其他 Skill 受影响目录冲突或者在同一个目录里塞了多个 Skill保持一目录一 Skill重启会话再试如果出现完全加载不到的情况可以先在 Claude Code 里输入“列出当前可用的 Skill”看它能不能把你刚装的 Skill 显示出来。这一步能快速判断是路径问题还是文件问题。5.2 我踩过的 3 个典型坑第一个坑是大小写问题。Skill 文件必须叫 SKILL.md不能用小写 skill.md也不要叫 README.md。我第一次装的时候没注意复制进去一个 README.md结果模型完全感知不到。第二个坑是“Skill 堆太多导致上下文被撑爆”。40 个 Skill 的描述加起来不短有时会在会话开始阶段占用不少 token。我的解决办法是把那些低频 Skill 的描述写短一点把关键触发词和输出格式写在最前面这样模型扫描时开销小匹配也更准确。第三个坑是“旧会话里不生效”。如果你在一个已经开了很久的会话里追加 Skill它可能不会立刻加载。这时候别硬试退出会话重新进一下让目录重新被扫描基本就能解决。5.3 避坑小技巧维护自己的 Skill 清单装完 40 个之后我现在每周会花十分钟做一次“Skill 大扫除”。具体做三件事看使用频率翻一下这周的会话记录哪些 Skill 从头到尾没被触发过删。看使用效果如果某个 Skill 输出质量明显不如预期考虑是描述写得不好还是 Skill 本身设计有问题能改描述就改描述改不了就换。看依赖是否失效有些 Skill 依赖外部工具如果升级了环境之后跑不起来了及时更新或替换。这一点我觉得很重要。很多人陷入“装得越多越好”的心态结果就是模型经常匹配错 Skill反而比自己写提示词还慢。Skill 的正确用法不是堆数量而是像一个打理得很好的工具架每样工具都在它该在的位置你伸手就能拿到。写在最后把 40 个 Skill 全部装完并且实际跑了一轮之后我最大的感受是Claude Code 本身只是一把锋利的刀Skill 则是各种刀法。没有刀法之前我拿它切什么都费劲有了刀法之后我只需要判断眼前的食材适合哪种切法剩下的交给它来办。如果你现在还在把 Claude Code 当普通聊天框使我建议你花一个下午挑三五个真正贴合自己场景的 Skill 装上先把流程跑通再慢慢扩到 40 个甚至更多。等你真的用顺手了大概率也会冒出跟我一样的想法以前那些手动敲提示词的日子确实是白过了。