如果你最近在翻 Claude 相关的技术讨论，大概率绕不开一个词：Skills。不管是 Twitter（现在叫 X）上的 AI 玩家、GitHub 上的 prompt 工程仓库，还是各种 "awesome-claude-skills" 之类的精选列表，都在反复提这个东西。我自己的感受是，Skills 不是又一个花哨概念，它是把 Claude 从"一个很聪明的聊天框"变成"一个能稳定干活的同事"的关键一步。这篇文章我会从自己的实操经验出发，把 Skills 是什么、怎么装、怎么找、怎么写，以及踩过的坑一次讲清楚，希望能让刚接触的人少走弯路。
1. 首先得说清楚：Claude Skills 到底是个什么东西
1.1 一句话理解：Skill 就是给 Claude 的"岗位说明书"
很多人第一次看到 Skills，第一反应是"这不就是插件吗？"我一开始也这么想，但用了一段时间之后，我的理解完全变了。插件（或者说 MCP 工具）是给 Claude 接上"手和眼睛"，让它能操作外部系统，比如查数据库、调 API、控制浏览器。而 Skill 更像是给 Claude 一份"工作手册"，告诉它：当你遇到某类任务时，应该按照什么步骤来思考、用什么工具、产出什么格式的结果。
举个例子。假设你经常需要把一段会议录音转成结构化纪要。没有 Skill 的时候，你得每次在对话框里反复交代："帮我把这段话整理成四个部分，分别是议题、结论、待办、风险，语气要客观，待办要标负责人"。这套 prompt 写多了你一定会烦。有了 Skill 之后，你只要说一句"整理这份会议纪要"，Claude 会自动读取对应的 SKILL.md 文件，按照里面定义的流程去处理。本质上是把重复的指令变成可复用的资产。
所以我的定义是这样的：Skill = 针对特定任务的完整操作流程说明，它不依赖外部服务，主要靠 prompt 工程 + Claude 已有的原生能力（文件读写、代码执行、长文本理解）来完成任务。
1.2 Skill 和 MCP 的分工，别搞混
我在社区里看到最多的问题，就是把 Skills 和 MCP 混为一谈。这里我用一个比较粗糙但好记的类比：MCP 是"外接设备接口"，Skill 是"操作手册"。你的电脑接了一个打印机（MCP 服务器），但你要知道怎么设置纸张、怎么双面打印、出了卡纸怎么办，这些知识就是 Skill。
从实际使用上看，两者通常是配合关系，而不是替代关系。比如一个"自动生成周报"的 Skill，它的流程可能是：
- 读取团队成员的 Git 提交记录（这里可能会调用 MCP 工具去查 Git 服务）
- 按模板汇总成周报（纯 prompt 能力）
- 写到指定的 Markdown 文件（原生文件工具）
也就是说，Skill 负责"知道该怎么做"，MCP 负责"提供做事需要的资源"。如果你只想做一个纯知识类的 Skill，比如"帮我按某种风格改写文章"，那完全不需要 MCP，只靠 Claude 本身的文本能力就够了。
1.3 适合谁、不适合谁
Skills 最适合两类人：一类是每天有大量重复性文本/分析工作的人，比如写周报、整理文档、做代码评审；另一类是团队里负责沉淀工作方法的人，能把团队的操作规范固化下来，让每个成员用 AI 时得到一致的结果。
反过来，如果你只是偶尔问 Claude 一两个问题，或者你的需求每次都完全不一样，那 Skills 暂时对你来说可能有点"重"，不急着折腾。先了解概念，等需求出现了再上手也不迟。
2. 先跑通环境：Claude Code 的安装与 Windows 专属坑
2.1 安装前的基础准备
Skills 是 Claude Code 的功能（网页版 Claude 目前用不了），所以第一步是装好 Claude Code。我用的是 npm 安装方式，前提是你电脑上有 Node.js 环境，建议版本在 18 以上。确认 Node 版本：
node -v npm -v如果还没有 Node，去官网下载 LTS 版本装好就行，这步没什么好说的。装好之后，安装 Claude Code 有两种常见方式。第一种是 npx 直接运行：
npx @anthropic-ai/claude-code这种方式不需要全局安装，但每次调用可能都会检查版本，稍慢。第二种是全局安装，我比较推荐：
npm install -g @anthropic-ai/claude-code全局装完以后，在终端输入claude就能进入交互界面。Windows 用户注意，Claude Code 在 Windows 上默认走 WSL（Windows Subsystem for Linux）或 Git Bash 环境，纯 PowerShell 下的兼容性在早期版本有很多坑。
2.2 Windows 上"Virtual Machine Platform"报错的解决办法
如果你在 Windows 上启动 Claude Code 或者运行 WSL，遇到类似Claude's workspace requires the Virtual Machine Platform on Windows. Enable it...这样的报错，先别慌。这个问题的根源在于 WSL2 依赖 Windows 的"虚拟机平台"功能，而在某些 Windows 版本上这个功能默认没开。
解决步骤分三步：
- 打开"控制面板 -> 程序 -> 启用或关闭 Windows 功能"
- 勾选"虚拟机平台"（Virtual Machine Platform）和"适用于 Linux 的 Windows 子系统"（Windows Subsystem for Linux）
- 重启电脑，然后在管理员 PowerShell 里运行
wsl --update，确保 WSL 内核是最新的
提示：很多人只勾了 WSL 选项，漏了"虚拟机平台"，结果重启后还是报同样的错。两个功能必须同时启用。
装好之后，在 PowerShell 里输入wsl --status确认 WSL 版本是 2。如果显示的是 WSL1，可以单独给某个发行版指定版本：wsl --set-version <发行版名称> 2。
2.3 两个高频安装报错："claude 不是 cmdlet"和"native binary not installed"
热搜词里有一句很典型：claude : 无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这个报错几乎都是因为npm 全局安装目录不在系统 PATH 环境变量里。Windows 下，npm 的全局 bin 目录一般是%APPDATA%\npm，你需要确认这个路径加进了系统 PATH。检查方法：
npm bin -g然后把输出的路径添加进环境变量（系统设置 -> 高级 -> 环境变量 -> Path）。改完记得重新开一个终端窗口。
另一个高频报错是：
error: claude native binary not installed. either postinstall did not run...这个我遇到过两次，基本都发生在用 npx 首次安装时网络不稳定，postinstall 脚本没跑完。处理办法：
- 清 npm 缓存：
npm cache clean --force - 删掉 node_modules 和 package-lock.json 重新装：
npx @anthropic-ai/claude-code@latest - 如果还不行，直接用官方提供的原生安装脚本（官网有提供，会下载预编译的二进制，绕开 npm 脚本问题）
完成安装后，运行claude --version确认版本号能打印出来。顺便说一句，如果后续遇到claude api error: connection dropped (econnreset)，这种通常是网络连接不稳定导致的，检查一下网络环境是否稳定、有没有特殊的网络策略限制，然后重试即可，属于偶发问题，不代表配置错误。
2.4 VS Code 里用 Claude Code
很多人习惯在 VS Code 里写代码、顺便让 AI 帮忙看代码，那可以直接用 Claude Code 的 VS Code 扩展。打开 VS Code 扩展市场搜索 "Claude Code"，安装后按快捷键呼出侧边栏。首次使用需要登录 Anthropic 账号，这一步跟命令行是互通的。
我在 VS Code 里最常用的场景是让它解析当前项目结构、生成单元测试、解释报错。配合 Skills 的话，可以给团队做一个"代码评审"的 Skill，让 Claude 按你们团队的规范去 Review 代码，而不是每次重新描述一遍规范。这个后面详细讲。
3. 从哪儿找现成的 Skills：官方示例、GitHub 仓库、手动安装流程
3.1 值得关注的几个渠道
用"awesome-claude-skills"作为关键词去 GitHub 搜，能找到不少社区整理的 Skill 合集。不过因为 Skills 生态还没完全定型，名称和内容质量参差不齐。我的经验是，除了 GitHub 搜索，还可以去这几个地方找：
- Anthropic 官方文档和示例仓库：官方维护的示例是最靠谱的入门材料，结构规范、能跑通
- 社区 Agent Skills 讨论话题：经常有人分享自己写的 Skill 文件，选 star 数高、文档全的试
- 各类"skills 下载"聚合站：凡是需要你掏钱或者留手机号的，我劝你直接关掉
根据我的观察，Anthropic 官方对 Agent Skills 有一篇从第一性原理解读的文章，核心观点就是：Skill 设计的本质是以最低的"心智成本"让模型理解并执行任务。所以你在挑选第三方 Skill 时，也可以拿这个标准去衡量。
3.2 装一个 Skill 的完整流程，以手动安装为例
这里我以社区最常见的手动安装方式为例，演示整个流程。假设我从 GitHub 上找到了一个名为meeting-notes的 Skill 仓库，想在本地启用它：
第一步，确定 Skills 目录的位置。Claude Code 的 Skills 有两个层级：
- 用户级目录：
~/.claude/skills/，所有项目都能用 - 项目级目录：
.claude/skills/，只有当前项目能用
我的建议是：通用的 Skill 放用户级，跟项目绑定的放项目级。举个例子，我自己写了一个"周报生成器"，所有项目都适用，就放用户级；而一个专门解析你们公司接口文档的 Skill，肯定只放对应项目的.claude/skills/下。
第二步，克隆或手动复制文件：
git clone https://github.com/example/meeting-notes.git ~/.claude/skills/meeting-notes如果你下载的是压缩包，手动解压后把整个文件夹放到~/.claude/skills/下也一样，关键是确保文件夹下直接有SKILL.md文件，而不是嵌套了一层同名目录。
第三步，重新启动 Claude Code，让 Skill 被加载。然后在对话里输入/skills之类的命令，或者直接问 Claude："你现在加载了哪些 skills？"它能列出来就说明安装成功。
3.3 怎么判断一个 Skill 写得好不好
安装之前先打开它的 SKILL.md 文件看一眼，我一般会检查三件事：
| 检查项 | 好的表现 | 坏的表现 |
|---|---|---|
| description 是否具体 | 写明触发条件和适用场景，如"当用户提供会议转写文本时，整理成结构化纪要" | 只写"整理文档"这种模糊描述 |
| 步骤是否可执行 | 有清晰的输入格式、处理流程、输出模板 | 空泛地告诉模型"要仔细分析" |
| 是否声明了走查清单 | 有 check before output 之类的验证步骤 | 没有 |
如果它连description都写得含含糊糊，那基本可以断定作者自己也没想清楚这个 Skill 要解决什么问题，装进去也是浪费上下文窗口。
3.4 装完之后，验证它真的有用
装完 Skill 不等于结束，我习惯做一次"触发验证"：找一个符合其 description 描述的任务，真实地让 Claude 走一遍。比如说我刚装了会议纪要 Skill，就拿一段真实的会议转写丢进去，看它是否主动触发该 Skill 的处理流程，还是只当普通文本回答。
如果发现该触发却没有触发，原因通常是两个：要么description里描述触发条件的方式跟模型的语义理解对不上，要么 Skill 目录路径不对没被加载。前者需要你编辑 SKILL.md 把 description 写得更贴近用户的自然表达，后者检查目录结构即可。
4. 从零手写一个 Skill：SKILL.md 的结构、写法与实测心得
4.1 SKILL.md 的骨架结构
一个 Skill 核心只有两个部分组成：SKILL.md文件（必须有）和可选的辅助脚本/模板文件。我第一次写的时候觉得很难，后来发现门槛其实很低，本质就是写好一份 Markdown 文档。SKILL.md 顶部的 YAML frontmatter 是 Claude 用来识别和索引 Skill 的元信息，基本骨架：
--- name: meeting-minutes description: 将会议转写文本整理为结构化纪要，包括议题、结论、待办事项和风险点。当用户提供会议录音转写稿或粘贴会议笔记时使用。 ---name是 Skill 的唯一标识，建议用短横线连接的小写单词；description是最关键的部分，它决定 Claude 什么时候触发这个 Skill，必须写清楚触发条件和适用场景。
正文部分就是给 Claude 看的操作手册，一般按这个顺序组织：目标说明、输入要求、执行步骤、输出模板、兜底规则。写正文时有个技巧：不要只告诉 Claude "要做什么"，要尽量告诉它"你怎么判断自己做得好不好"。
4.2 完整案例：写一个"会议纪要" Skill
我拿自己实际在用的会议纪要 Skill 来拆解。这个 Skill 解决的问题是：每次开完会，把几十行杂乱的转写文本变成结构清晰、可直接发群的纪要。
目录结构：
meeting-minutes/ ├── SKILL.md └── templates/ └── minutes_template.mdSKILL.md 正文核心内容大致是：
# 会议纪要整理 ## 目标 把用户提供的会议转录或笔记整理成结构清晰的会议纪要。 ## 输入格式 用户会直接粘贴转录文本，包含发言者标签，例如"张三：我们觉得方案可行"。 ## 执行步骤 1. 先通读全文，区分讨论内容与闲聊内容 2. 按主题归纳讨论链路，整理出 3-5 个核心议题 3. 从文本中提取明确结论（有共识、有拍板） 4. 提取待办事项，每项标注负责人（若原文未提及则写"待确认"） 5. 识别风险点（延期风险、资源不足、技术不确定） 6. 按模板输出 ## 输出模板 按 templates/minutes_template.md 中的结构输出。 ## 质量规范 - 不得臆造原文中不存在的结论 - 待办事项必须有"负责人/事项/截止时间"三要素，缺失的写"待确认" - 口语语气保留，但不保留寒暄内容这里我特意加了"质量规范"这个小节，实测下来这个设计能明显减少 Claude 乱编的情况。因为模型在不确定时会倾向于"补全"，你把"不得臆造"写明白，等于给它的幻觉踩了刹车。
模板文件minutes_template.md也很简单：
## 会议主题 ## 参与人 ## 核心议题 ### 议题1 结论： ### 议题2 结论： ## 待办事项 | 事项 | 负责人 | 截止时间 | ## 风险与阻塞4.3 写 Skill 的四个心得
第一个心得是description 要写"用户会怎么说"，而不是"技能能做什么"。比如你写"当用户提供任何形式的会议文本时"，触发率就比写"本技能用于整理会议纪要"要高得多。因为模型是根据当前对话内容去匹配 description 的，它更需要的是"什么样的输入能匹配上"。
第二个心得是尽量把步骤写得像 Checklist，而不是散文。Claude 在长文本里提取关键信息的能力很强，但分步编号的格式能显著提高执行稳定性。我自己早期的 Skill 写得像说明文档，后来全部改成了编号步骤，效果立竿见影。
第三个心得是善用辅助文件。如果一个 Skill 要处理的数据格式比较复杂，可以把格式模板、Few-shot 示例单独放文件，SKILL.md 里通过引用方式把它带出来。这样 SKILL.md 本身保持精简，模型加载时不会被无关内容干扰。
第四个心得是先测试再分享。写完一个 Skill，至少要找十个不同类型的输入去测，看看边界情况。比如输入特别短、错别字多、或者中英混杂时，它还能不能稳定输出。我在真实测试中就发现，我的会议纪要 Skill 遇到纯英文转写时表现不佳，于是我在 SKILL.md 里加了一条"输入为英文时，输出标题可保留英文，但待办描述用中文"，这算是通过测试发现需求的典型例子。
5. 进阶玩法：接入本地模型、团队协作与 Skill 治理
5.1 Claude Code 接入本地模型的实验性配置
热搜里有一个词条让我很感兴趣："claude code 调用 lmstudio 的本地模型"。我自己也试过这条路，说下真实的体验。
Claude Code 支持通过环境变量修改 API 地址，所以从原理上讲，可以让它指向本地模型服务，例如 LM Studio 启动的本地 OpenAI-compatible 接口。基本配置思路是：
export ANTHROPIC_BASE_URL="http://localhost:1234/v1" export ANTHROPIC_API_KEY="lm-studio" export ANTHROPIC_MODEL="your-local-model-name"设置好之后启动claude，理论上就能跑在本地模型上。但我要泼一盆冷水：这个玩法是实验性的，体验远不如官方模型。因为 Claude Code 对模型的工具调用能力要求很高，本地小参数模型经常出现"叫它读文件它不读、叫它执行代码它乱编"的情况。我的建议是，如果你动机是"省钱"或者"数据隐私"，可以研究；如果你只是好奇，那别抱太高期望，把本地模型当作调试环境用就好。
5.2 团队场景下，Skills 要进 Git 做版本管理
如果你是团队里负责推广 Claude Code 的人，一定会遇到一个头疼的问题：每个人本地装的 Skill 版本不一样，同一个任务在不同人电脑上跑出来的结果完全不同。
解决方案很简单：把 Skills 目录纳入 Git 仓库。项目级 Skills 天然跟着代码库走，团队成员 clone 项目后自动就有对应 Skill。用户级 Skills 也可以通过一个内部仓库管理，写一个安装脚本，把仓库同步到各自~/.claude/skills/。
我在团队里还加了一个约定：SKILL.md 里必须写一个 "Version" 字段，更新 Skill 时把版本号递进，并在 README 里记录 changelog。这看起来有点笨，但实际排查问题时帮了大忙——有个同事反馈"周报 Skill 不灵了"，一查 Version 发现他本地还是老版本，问题就清晰了。
5.3 什么时候不要用 Skill，边界在哪里
最后想分享一个反直觉的经验：不是所有任务都适合做成 Skill。
第一，一次性任务不要做 Skill。比如"帮我修改这个 PPT 的文字"，做完就完了，做成 Skill 的意义不大，反而占着目录空间，每次加载还可能让模型多考虑一个不相关的选项。
第二，纯闲聊类任务不要做 Skill。Skill 是给"有明确目标和步骤的任务"用的，闲聊场景下硬套流程反而会让对话变得生硬。
第三，涉及高度动态、不可预测输入的任务，Skill 要设计得足够"宽容"。CLAUDE Code 本身是 agentic 的，Skill 不能把步骤写得太死，否则模型一旦遇到预期之外的输入就不知所措。我的经验是：在 SKILL.md 里留一条兜底规则，类似"如果输入格式与预期不符，先尝试提取核心信息，若完全无法处理，请主动向用户提问澄清"。这会让 Skill 的鲁棒性上一个台阶。
从我个人经验来说，玩 Skills 最大的收获不是"让 Claude 变得更聪明"，而是强迫我把自己做事的流程重新梳理了一遍。很多任务你以为自己很熟，真到了要写成步骤清晰的文档时才发现，里面有不少模糊地带和靠直觉判断的部分。Skills 相当于用 AI 能理解的方式，把隐性的个人经验转化成了显性的团队资产。这也是我看好这个东西的核心理由——它让 AI 的使用方式从"每一次都从头教"，变成了"一次沉淀，反复使用"，长期积累下去，这些 Skill 文件本身就会成为团队最宝贵的知识库。
