1. 从“skills”这个热词说起它到底是什么为什么突然火了最近几个月不管是在技术社区、AI 工具群还是各种折腾命令行工具的圈子里“skills”这个词出现的频率高得离谱。很多人第一次看到它脑子里冒出来的问号是这跟“技能”有什么关系是某个新出的 App还是某个游戏里的天赋树其实都不是。在当下这个语境里skills 指的是一套围绕 AI 编程助手尤其是 Claude Code 这类命令行智能体构建的可复用能力模块。你可以把它理解成给 AI 助手装的“插件包”或者“技能卡”——每一张卡定义了一类特定任务的执行方式、上下文规则和工具调用逻辑AI 在遇到对应场景时就会自动加载并按照预设的方式干活。我最早接触这个概念是在折腾 Claude Code 的时候。当时我的需求很具体每次让它帮我写前端组件它总是按自己的习惯来一会儿用这个目录结构一会儿用那个命名规范来回反复沟通成本极高。后来有人丢给我一个SKILL.md文件说“你把这个放到项目里试试”。我照做之后效果立竿见影——AI 开始按照我预设的组件拆分方式、样式方案、甚至注释风格来输出代码。那一刻我才意识到skills 解决的核心问题不是“AI 能不能做”而是“AI 能不能按你的规矩做”。这套机制的本质是把“提示词工程”从一次性的对话技巧升级成了可版本化、可共享、可组合的工程资产。以前你写好一段提示词只能自己用换个项目就得重新调现在你可以把它固化成 skill 文件提交到仓库里团队成员拉下来就能用甚至开源出去让陌生人也能受益。这也是为什么热词里会出现“skills 推荐”“常用 skills”“数学建模 skills”“AI 漫剧常用 skills”这些细分方向——不同领域的人都在把自己的领域知识封装成 skill形成一个个小而美的能力库。这篇文章适合谁看如果你是刚听说 Claude Code、还没搞明白 skills 是什么的新手我会从最基础的概念和安装讲起如果你已经在用 Claude Code但每次都要重复交代一堆规则我会告诉你怎么用 skill 把这些规则固化下来如果你已经在写自己的 skill我会分享一些关于结构设计、触发条件和调试技巧的实操经验。整篇内容基于我自己的使用和踩坑经历结合社区里常见的做法整理而成不保证是唯一正确答案但保证是能跑通的方案。2. 核心机制拆解SKILL.md 到底是怎么被 AI 读懂的2.1 一个 skill 的最小构成文件、元数据、触发条件要理解 skills 怎么工作先得看它的物理形态。一个 skill 在文件系统里通常就是一个目录目录名就是 skill 的名字里面至少有一个SKILL.md文件。这个 Markdown 文件不是普通的说明文档它被 AI 助手当作“行为指令”来解析。文件开头一般有一段类似 YAML front matter 的元数据区域用来声明这个 skill 叫什么、什么时候该被激活、需要哪些工具权限。我拿一个实际的前端组件 skill 举例它的SKILL.md开头大概长这样--- name: react-component-generator description: 当用户要求创建新的 React 组件时使用此 skill按照团队规范生成组件文件、样式文件和测试文件 tools: - file_write - file_read - shell ---下面才是正文部分用自然语言描述具体的执行规则比如“组件必须使用函数式写法”“样式统一用 CSS Modules”“每个组件必须附带一个同名的.test.tsx文件”等等。AI 在收到用户请求时会先扫描当前可用的 skill 列表把每个 skill 的description和用户意图做匹配命中之后就加载对应的SKILL.md正文把它作为额外的系统指令注入到当前对话上下文中。这里有个关键点很多人会忽略description的写法直接决定了 skill 能不能被正确触发。我见过有人把 description 写成“一个很有用的 skill”结果 AI 根本不知道什么时候该用它。好的 description 应该像一段精准的路由规则把“什么场景”“什么动作”“什么对象”都交代清楚。比如“当用户要求生成数学建模论文中的灵敏度分析章节时使用”就比“处理数学建模相关任务”要有效得多。2.2 触发逻辑AI 是怎么决定“现在该用哪个 skill”的Claude Code 这类工具在启动时会扫描特定目录下的所有 skill 文件夹把每个 skill 的元数据读进内存形成一个“技能索引”。当你输入一条指令比如“帮我写一个登录页面”AI 会拿这条指令去和索引里每个 skill 的 description 做语义匹配。匹配不是简单的关键词搜索而是基于语言模型的理解能力所以即使你的描述和 skill 的 description 用词不完全一样只要语义接近也能触发。但这里有个坑如果多个 skill 的 description 语义重叠AI 可能会选错或者干脆都加载进来导致指令冲突。我就遇到过同时装了“React 组件生成”和“Vue 组件生成”两个 skill结果我说“写个组件”的时候AI 把两个都加载了生成出来的代码一半是 JSX 一半是 template场面非常混乱。后来我的做法是在 description 里加上明确的技术栈限定词比如“仅当项目使用 React 且用户明确要求创建 React 组件时使用”这样就能把触发范围收窄。另一个影响触发的因素是 skill 的存放位置。不同工具对 skill 目录的约定不一样有的放在项目根目录的.skills/下有的放在用户主目录的全局配置里。项目级的 skill 只对当前项目生效全局级的 skill 对所有项目生效。我的建议是通用性强的 skill比如代码格式化、提交信息生成放全局项目特有的 skill比如这个项目的 API 调用规范放项目里。这样既能复用又不会让全局 skill 列表膨胀到 AI 匹配不过来。2.3 与普通提示词的区别为什么值得多花时间写 skill有人可能会问我直接在对话里把要求说清楚不就行了为什么要费劲写一个 skill 文件这个问题我一开始也想过直到我统计了一下自己在某个项目里重复交代同一套规则的次数——光是“组件用函数式写法、样式用 CSS Modules、测试文件放同级目录”这句话我在两周内说了不下三十遍。每次都要打这么多字而且偶尔还会漏掉一两条导致 AI 生成的代码需要返工。Skill 的第一个价值就是消除重复沟通。写一次之后所有对话自动生效不用再念叨。第二个价值是保证一致性。人会说漏但文件不会。只要SKILL.md里写清楚了每次触发的行为都是完全一样的不会因为今天心情好多说一句、明天赶时间少说一句而产生差异。第三个价值是可传承。团队里来了新人不用口口相传“我们这里 AI 要这么用”直接把 skill 仓库拉下来就行。第四个价值是可组合。你可以写一个“基础代码规范”skill再写一个“React 特定规范”skill后者可以引用前者形成层次化的规则体系。从工程角度看skill 把提示词从“对话消耗品”变成了“代码资产”。它可以进版本控制可以 code review可以打 tag 发版本。这个转变的意义不亚于当年把散落在各处的 shell 脚本收进 Makefile。3. 从零开始安装 Claude Code 并跑通第一个 skill3.1 环境准备不同系统下的安装路径选择在聊 skill 的具体写法之前得先有一个能跑 skill 的环境。目前最主流的载体是 Claude Code它是一个命令行工具安装方式根据操作系统有所不同。我分别在 Windows、macOS 和 Linux 上都装过踩过的坑不太一样这里分别说一下。macOS 和 Linux 相对简单官方推荐的方式是通过 npm 全局安装。前提是你机器上已经有 Node.js 环境版本建议在 18 以上。命令就是一行npm install -g anthropic-ai/claude-code装完之后在终端输入claude如果能看到交互界面就说明成功了。如果提示“command not found”大概率是 npm 的全局 bin 目录没有加到 PATH 里可以用npm config get prefix看一下路径然后手动加进环境变量。Windows 的情况要复杂一些。如果你用的是 PowerShell安装命令是一样的但可能会遇到两个典型问题。第一个是执行策略限制PowerShell 默认不允许运行未签名的脚本需要先执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser把策略放宽。第二个是某些依赖需要虚拟化平台支持如果系统提示需要启用相关功能去“启用或关闭 Windows 功能”里把对应的选项勾上重启之后就能继续。我自己在 Windows 上更推荐用 WSL2把 Claude Code 装在 Linux 子系统里省去很多路径和权限的麻烦。提示安装过程中如果遇到网络相关的报错优先检查本机的包管理器和 Node 版本绝大多数安装失败都源于环境不匹配而不是工具本身的问题。3.2 验证安装与首次配置让 claude 命令真正可用装完之后别急着写 skill先确认基础功能是通的。在终端里输入claude --version能输出版本号就说明二进制文件已经就位。然后输入claude进入交互模式随便问一个简单问题比如“用一句话解释什么是递归”看它能不能正常回复。这一步的目的是排除认证和网络配置的问题。如果这一步卡住了常见的原因有几个。一是 API 密钥没有配置需要在环境变量里设置对应的 key或者通过工具提供的登录流程完成认证。二是终端编码问题在某些 Windows 终端里中文会显示成乱码换成 UTF-8 编码的终端就好。三是代理设置如果你所在的网络环境需要经过代理才能访问外部服务得在环境变量里配置好HTTP_PROXY和HTTPS_PROXY否则请求会超时。确认基础对话没问题之后可以看一下 skill 的默认存放目录。不同版本的 Claude Code 对目录的约定略有差异但通常会在用户主目录下有一个配置文件夹里面有一个skills子目录。你可以用claude的交互命令问它“我的 skill 目录在哪里”它会告诉你具体路径。知道这个路径很重要因为后面放 skill 文件就靠它。3.3 手动安装一个社区 skill以 GitHub 上的开源 skill 为例社区里已经有不少人把自己写的 skill 开源出来了热词里提到的“claude code 怎么手动装 github 上的 skills”就是很多人的实际需求。手动安装的流程其实不复杂核心就是把 skill 目录放到正确的位置。假设你在 GitHub 上看到一个 skill 仓库里面有一个skills文件夹下面有若干子目录每个子目录是一个独立的 skill。安装步骤如下把仓库克隆到本地任意位置比如git clone 仓库地址 /tmp/skill-repo。进入仓库找到skills目录看看里面有哪些 skill 文件夹。把你需要的那个 skill 文件夹整个复制到 Claude Code 的 skill 目录下。比如cp -r /tmp/skill-repo/skills/my-skill ~/.claude/skills/。重启 Claude Code或者在交互模式里执行重新加载 skill 的命令。用一条能触发该 skill 的指令测试一下看行为是否符合预期。这里有个细节复制的时候要确保SKILL.md在文件夹的根层级不要多套一层目录。我见过有人复制完之后路径变成~/.claude/skills/my-skill/my-skill/SKILL.md结果 AI 扫描不到白白折腾半天。另外如果 skill 依赖额外的脚本或模板文件也要一并复制过去保持目录结构完整。注意从社区安装 skill 之前建议先打开SKILL.md读一遍确认它声明的工具权限和实际行为是你可接受的。skill 本质上是一段会被 AI 执行的指令来源不明的 skill 存在风险。4. 自己动手写一个 skill结构、写法与调试4.1 确定 skill 的边界一个 skill 只做一件事写 skill 最容易犯的错误就是把它写成一个大而全的“万能规则文件”。我一开始也是这样把代码规范、提交规范、测试规范、文档规范全塞进一个SKILL.md里结果 AI 每次触发都加载一大堆无关内容既浪费上下文窗口又容易让指令之间互相干扰。后来我学乖了一个 skill 只负责一类任务边界要清晰到能用一句话说清楚。怎么判断边界是否合适我的标准是如果这个 skill 的 description 里出现了“以及”“还有”“顺便”这类词就说明它管得太宽了应该拆。比如“生成 React 组件以及编写对应的单元测试以及更新导出文件”就应该拆成三个 skill或者至少把“更新导出文件”这种附带动作交给 AI 自己判断不写进 skill。拆细之后还有一个好处可以按需组合。比如我有一个“基础 TypeScript 规范”skill一个“React 组件结构”skill一个“测试文件模板”skill。当我要生成一个组件时AI 会同时触发这三个各管各的互不冲突。如果哪天我换用 Vue只需要把“React 组件结构”换成“Vue 组件结构”其他两个照常工作。4.2 写好 description让 AI 在正确的时候想起你前面提过 description 的重要性这里展开讲一下具体怎么写。一个好的 description 应该包含三个要素触发场景、任务类型、限定条件。触发场景回答“什么时候用”比如“当用户要求创建新的前端页面时”。任务类型回答“做什么”比如“按照团队规范生成页面组件、路由配置和样式文件”。限定条件回答“在什么范围内用”比如“仅适用于使用 React Router 的项目”。把这三者组合起来就是一个合格的 description当用户要求创建新的前端页面且项目使用 React Router 时使用此 skill按照团队规范生成页面组件、路由配置和样式文件。对比一下常见的错误写法“前端页面生成 skill”——太模糊AI 不知道什么时候该触发“用于生成 React 页面”——缺少限定条件可能在 Vue 项目里也被触发“一个帮助开发者提高效率的 skill”——完全没信息量。我自己的习惯是写完 description 之后拿几条典型的用户指令在心里过一遍看这个 description 能不能准确匹配到该匹配的、排除掉不该匹配的。如果发现某条指令模棱两可就回去改 description直到边界清晰为止。4.3 正文写法用自然语言写清楚“怎么做”和“不要做什么”SKILL.md的正文部分没有严格的格式要求本质上就是一段给 AI 看的指令。但根据我的经验结构化的写法比一大段散文效果要好得多。我通常会用几个小标题把正文分成“执行步骤”“输出格式”“禁止事项”三块。“执行步骤”用有序列表写清楚第一步做什么、第二步做什么。比如生成 React 组件的 skill步骤可能是先读取项目里的组件模板文件然后根据用户提供的组件名生成文件路径接着按照模板填充内容最后更新导出文件。每一步都写得具体AI 执行起来就不容易跑偏。“输出格式”用代码块给出期望的输出样例。比如你希望 AI 生成的组件文件长什么样就直接在 skill 里贴一个示例代码块。AI 看到具体样例之后模仿的准确率会大幅提升。这比用文字描述“使用函数式写法、导出默认组件”要有效得多。“禁止事项”用无序列表列出绝对不允许出现的行为。比如“不要使用 class 组件”“不要引入未在 package.json 中声明的依赖”“不要在组件内部直接写死 API 地址”。这些禁止项往往是踩过坑之后总结出来的写进去能避免 AI 重复犯错。提示正文里可以引用项目里的其他文件比如“参考docs/coding-style.md中的命名规范”。AI 会去读被引用的文件这样可以把一些通用的规范抽出去单独维护skill 本身保持精简。4.4 调试 skill怎么知道它有没有生效写完 skill 之后怎么验证它真的被触发了最直接的方法是看 AI 的输出是否符合 skill 里定义的规则。如果不符合先别急着改 skill按下面的顺序排查。第一步确认 skill 文件被正确加载了。在 Claude Code 里问它“当前有哪些可用的 skill”看列表里有没有你刚写的那个。如果没有检查文件路径和目录结构是否正确。第二步确认 description 能匹配到你的测试指令。换几种不同的说法试试看是不是某些说法能触发、某些不能。如果发现触发不稳定说明 description 写得不够明确需要调整。第三步确认 skill 正文的指令没有和系统默认行为冲突。有时候 AI 不按 skill 来是因为 skill 里的要求和它自身的默认倾向矛盾而它选择了后者。这时候可以在 skill 里把要求写得更强硬一些比如用“必须”“严禁”这样的词。第四步看上下文窗口是不是被占满了。如果对话已经很长skill 的内容可能被挤出了有效上下文导致 AI “忘记”了规则。这种情况开一个新对话通常就能解决。我自己的调试习惯是每写完一个 skill就用三到五条不同的指令去测它覆盖“应该触发”和“不应该触发”两种情况。只有两边都符合预期才算这个 skill 写到位了。5. 常见问题与排查技巧实录5.1 安装与识别类问题速查问题现象可能原因排查方向终端提示找不到 claude 命令全局 bin 目录未加入 PATH检查 npm 全局路径并配置环境变量安装时提示需要虚拟化平台系统功能未启用在系统设置中启用对应功能并重启skill 列表里看不到自己放的 skill目录层级多套了一层确认 SKILL.md 在 skill 文件夹根层级AI 不按 skill 规则执行description 匹配失败或指令冲突换说法测试触发检查 skill 正文措辞多个 skill 同时触发导致输出混乱description 语义重叠在 description 中加技术栈限定词收窄范围这张表里的每一条都是我实际遇到过的。其中“目录层级多套一层”这个坑我踩过两次第一次折腾了半小时才反应过来是路径问题。后来我养成了一个习惯放完 skill 之后先用ls命令看一眼目标目录下的结构确认SKILL.md就在第一层。5.2 触发不稳定与行为漂移的处理经验触发不稳定是写 skill 过程中最让人头疼的问题。同样的指令有时候能触发有时候不能。我观察下来原因主要有三类。第一类是 description 的语义覆盖不够。比如你写的是“生成 React 组件”但用户说的是“帮我搞一个卡片组件”如果 description 里没有“卡片”“UI 元素”这类近义词AI 可能匹配不上。解决办法是在 description 里多列几个同义场景或者用更上位的词比如“生成 React UI 组件”。第二类是上下文干扰。如果当前对话里已经有很多其他指令AI 的注意力会被分散skill 的优先级可能被压低。这种情况我通常会在指令里显式提一句“按照项目里的组件规范来做”相当于手动给 skill 加一个触发信号。第三类是 skill 之间的优先级冲突。当两个 skill 都声称自己适用于当前场景时AI 可能随机选一个或者各取一部分。解决办法是在 description 里写清楚优先级关系比如“当同时存在通用组件规范和特定组件规范时优先使用本 skill”。行为漂移则是另一个层面的问题skill 触发了但 AI 执行到一半开始偏离规则。这通常是因为 skill 正文太长AI 读到后面忘了前面。我的应对方法是把最重要的规则放在正文最前面并且用加粗或列表的方式突出显示。另外把长 skill 拆成多个短 skill 也比一个巨型 skill 更稳定。5.3 我踩过的三个典型坑与修复过程第一个坑是在 skill 里写了太多“建议”而不是“要求”。我一开始写规则喜欢用“建议使用”“最好采用”这样的措辞结果 AI 把这些当成可选项经常不执行。后来全部改成“必须”“严禁”“一律”执行率明显上升。AI 对指令的服从度和措辞的强硬程度是正相关的这一点在写 skill 时尤其明显。第二个坑是skill 里引用了不存在的文件路径。我在 skill 正文里写“参考templates/component.tsx”但那个文件其实放在另一个目录下AI 去找的时候找不到整个 skill 的执行就卡住了。修复方法是在写引用之前先用绝对路径或相对于项目根目录的路径确认文件确实存在。第三个坑是没有给 skill 设版本。我改了一版 skill 之后发现新版本在某些场景下不如旧版本好用但旧版本已经被覆盖了找不回来。后来我养成了给 skill 目录加版本号的习惯比如react-component-v1、react-component-v2切换的时候改一下目录名就行。如果配合 Git 管理那就更稳妥了。5.4 关于 skill 分享与复用的几点建议当你写出一批好用的 skill 之后自然会想分享给团队或者开源出去。分享之前有几件事值得做。一是清理敏感信息。skill 里可能包含你项目的内部路径、私有依赖名、甚至 API 端点分享前要全部替换成占位符。我见过有人把公司内部接口地址写进 skill 然后推到公开仓库虽然不是什么大事故但总归不妥。二是补一份 README。SKILL.md是给 AI 看的README 是给人看的。在 README 里说明这个 skill 解决什么问题、适用于什么技术栈、怎么安装、怎么验证能大幅降低别人的使用门槛。三是标注兼容性。不同版本的 Claude Code 对 skill 格式的支持可能有差异在 README 里写清楚你测试过的版本范围能帮别人省去很多试错时间。四是接受反馈并迭代。skill 这种东西自己用和给别人用遇到的场景不一样别人可能会发现你没想到的边界情况。开放 issue 或者讨论区收集反馈之后定期更新skill 的质量会越来越高。6. 进阶方向把 skill 组合成工作流6.1 多 skill 协同让 AI 按流水线方式干活单个 skill 解决的是单点问题但实际开发往往是一连串动作。比如“新建一个页面”这件事拆开来看包括创建页面组件文件、创建对应的样式文件、在路由配置里注册、在导航菜单里加一项、写一个基础的测试文件。如果每个动作都是一个独立 skillAI 在触发时会依次加载并执行形成一条流水线。我目前的做法是把这条流水线里的每个环节都写成独立 skill然后在最上层的“页面生成”skill 里用自然语言描述执行顺序“先调用组件生成 skill 创建文件再调用路由注册 skill 更新配置最后调用测试生成 skill 创建测试文件。”AI 读到这段描述后会按顺序触发对应的子 skill。这样既保持了每个 skill 的独立性又能组合出复杂的工作流。这种组合方式的好处是灵活。如果哪天我换了一种路由方案只需要替换“路由注册”这个 skill其他环节不受影响。如果某个环节暂时不需要比如项目初期不写测试把对应的 skill 禁用就行不用改上层逻辑。6.2 领域专用 skill 的写法以数学建模和 AI 漫剧为例热词里出现了“数学建模 skills 推荐”和“AI 漫剧常用 skills”说明 skill 的玩法已经渗透到垂直领域了。我虽然主要做前端但也帮朋友看过几个数学建模方向的 skill这里说一下领域专用 skill 的写法特点。数学建模的 skill 和前端 skill 最大的区别在于它的输出不是代码文件而是论文段落、图表或者计算脚本。所以这类 skill 的正文里重点要放在“分析框架”和“表达规范”上。比如一个“灵敏度分析”skill需要告诉 AI先确定需要分析的参数然后设计扰动范围接着计算输出变化最后用规范的语言描述结论并生成对比图表。这些步骤用自然语言写清楚AI 就能按照建模论文的套路来输出。AI 漫剧方向的 skill 则更侧重创意流程的标准化。比如角色设定 skill 要规定角色卡的字段结构分镜 skill 要规定镜头描述的格式配音 skill 要规定语气和节奏的标注方式。这类 skill 的价值在于把创作者的隐性经验显性化让 AI 产出的内容保持统一的风格和水准。写领域 skill 的关键是找到该领域里那些“老师傅会做但新人不知道”的隐性规则把它们用明确的语言写出来。这需要你对领域本身有足够深的理解光懂 AI 工具是不够的。6.3 维护 skill 库的长期策略当 skill 数量超过十个之后管理就成了问题。我的做法是建一个专门的 Git 仓库来放 skill按领域分目录比如frontend/、backend/、writing/、data/。每个 skill 一个文件夹文件夹名就是 skill 名。仓库根目录放一个索引文件列出所有 skill 的名称、用途和适用场景方便快速查找。版本管理方面我给每个 skill 打 tag格式是skill-name/v1.0.0。当某个 skill 有破坏性变更时升大版本号新增功能升小版本号修 bug 升补丁号。这样在项目里引用 skill 时可以锁定版本避免上游更新导致行为突变。定期清理也很重要。有些 skill 可能只在特定项目里用过一次之后就再也没触发过。这类 skill 我会先归档到一个archive/目录观察一段时间如果确实不再需要就删掉。skill 库和代码库一样不清理就会越来越臃肿最终影响 AI 的匹配效率。6.4 关于 skill 生态的一点个人观察从我自己使用和观察社区的情况来看skill 这个机制目前还处于比较早期的阶段。好处是灵活几乎什么都能封装坏处是缺乏统一标准不同人写的 skill 质量参差不齐组合使用时经常需要手动调整。我预计接下来会出现一些约定俗成的规范比如 description 的写法模板、skill 之间的依赖声明方式、权限声明的粒度等等。对于现在就想上手的人来说我的建议是不要等标准出来再动手。先写几个自己最常用的 skill在实际使用中打磨等社区规范成熟了再往上面靠。skill 的核心价值在于把你的领域知识固化下来这个动作本身什么时候做都不亏。而且写得多了你对“什么样的指令 AI 能听懂”这件事的直觉会越来越准这个能力迁移到其他 AI 工具上同样适用。最后分享一个我最近在用的技巧把 skill 当成“给未来的自己写的备忘录”。每次我在某个问题上跟 AI 来回沟通超过三轮才得到满意结果我就会停下来想一想这个沟通模式能不能固化成一个 skill。能固化的就当场写下来下次直接触发省下的时间积少成多相当可观。
Claude Code Skills 实战：从安装到编写可复用 AI 能力模块
1. 从“skills”这个热词说起它到底是什么为什么突然火了最近几个月不管是在技术社区、AI 工具群还是各种折腾命令行工具的圈子里“skills”这个词出现的频率高得离谱。很多人第一次看到它脑子里冒出来的问号是这跟“技能”有什么关系是某个新出的 App还是某个游戏里的天赋树其实都不是。在当下这个语境里skills 指的是一套围绕 AI 编程助手尤其是 Claude Code 这类命令行智能体构建的可复用能力模块。你可以把它理解成给 AI 助手装的“插件包”或者“技能卡”——每一张卡定义了一类特定任务的执行方式、上下文规则和工具调用逻辑AI 在遇到对应场景时就会自动加载并按照预设的方式干活。我最早接触这个概念是在折腾 Claude Code 的时候。当时我的需求很具体每次让它帮我写前端组件它总是按自己的习惯来一会儿用这个目录结构一会儿用那个命名规范来回反复沟通成本极高。后来有人丢给我一个SKILL.md文件说“你把这个放到项目里试试”。我照做之后效果立竿见影——AI 开始按照我预设的组件拆分方式、样式方案、甚至注释风格来输出代码。那一刻我才意识到skills 解决的核心问题不是“AI 能不能做”而是“AI 能不能按你的规矩做”。这套机制的本质是把“提示词工程”从一次性的对话技巧升级成了可版本化、可共享、可组合的工程资产。以前你写好一段提示词只能自己用换个项目就得重新调现在你可以把它固化成 skill 文件提交到仓库里团队成员拉下来就能用甚至开源出去让陌生人也能受益。这也是为什么热词里会出现“skills 推荐”“常用 skills”“数学建模 skills”“AI 漫剧常用 skills”这些细分方向——不同领域的人都在把自己的领域知识封装成 skill形成一个个小而美的能力库。这篇文章适合谁看如果你是刚听说 Claude Code、还没搞明白 skills 是什么的新手我会从最基础的概念和安装讲起如果你已经在用 Claude Code但每次都要重复交代一堆规则我会告诉你怎么用 skill 把这些规则固化下来如果你已经在写自己的 skill我会分享一些关于结构设计、触发条件和调试技巧的实操经验。整篇内容基于我自己的使用和踩坑经历结合社区里常见的做法整理而成不保证是唯一正确答案但保证是能跑通的方案。2. 核心机制拆解SKILL.md 到底是怎么被 AI 读懂的2.1 一个 skill 的最小构成文件、元数据、触发条件要理解 skills 怎么工作先得看它的物理形态。一个 skill 在文件系统里通常就是一个目录目录名就是 skill 的名字里面至少有一个SKILL.md文件。这个 Markdown 文件不是普通的说明文档它被 AI 助手当作“行为指令”来解析。文件开头一般有一段类似 YAML front matter 的元数据区域用来声明这个 skill 叫什么、什么时候该被激活、需要哪些工具权限。我拿一个实际的前端组件 skill 举例它的SKILL.md开头大概长这样--- name: react-component-generator description: 当用户要求创建新的 React 组件时使用此 skill按照团队规范生成组件文件、样式文件和测试文件 tools: - file_write - file_read - shell ---下面才是正文部分用自然语言描述具体的执行规则比如“组件必须使用函数式写法”“样式统一用 CSS Modules”“每个组件必须附带一个同名的.test.tsx文件”等等。AI 在收到用户请求时会先扫描当前可用的 skill 列表把每个 skill 的description和用户意图做匹配命中之后就加载对应的SKILL.md正文把它作为额外的系统指令注入到当前对话上下文中。这里有个关键点很多人会忽略description的写法直接决定了 skill 能不能被正确触发。我见过有人把 description 写成“一个很有用的 skill”结果 AI 根本不知道什么时候该用它。好的 description 应该像一段精准的路由规则把“什么场景”“什么动作”“什么对象”都交代清楚。比如“当用户要求生成数学建模论文中的灵敏度分析章节时使用”就比“处理数学建模相关任务”要有效得多。2.2 触发逻辑AI 是怎么决定“现在该用哪个 skill”的Claude Code 这类工具在启动时会扫描特定目录下的所有 skill 文件夹把每个 skill 的元数据读进内存形成一个“技能索引”。当你输入一条指令比如“帮我写一个登录页面”AI 会拿这条指令去和索引里每个 skill 的 description 做语义匹配。匹配不是简单的关键词搜索而是基于语言模型的理解能力所以即使你的描述和 skill 的 description 用词不完全一样只要语义接近也能触发。但这里有个坑如果多个 skill 的 description 语义重叠AI 可能会选错或者干脆都加载进来导致指令冲突。我就遇到过同时装了“React 组件生成”和“Vue 组件生成”两个 skill结果我说“写个组件”的时候AI 把两个都加载了生成出来的代码一半是 JSX 一半是 template场面非常混乱。后来我的做法是在 description 里加上明确的技术栈限定词比如“仅当项目使用 React 且用户明确要求创建 React 组件时使用”这样就能把触发范围收窄。另一个影响触发的因素是 skill 的存放位置。不同工具对 skill 目录的约定不一样有的放在项目根目录的.skills/下有的放在用户主目录的全局配置里。项目级的 skill 只对当前项目生效全局级的 skill 对所有项目生效。我的建议是通用性强的 skill比如代码格式化、提交信息生成放全局项目特有的 skill比如这个项目的 API 调用规范放项目里。这样既能复用又不会让全局 skill 列表膨胀到 AI 匹配不过来。2.3 与普通提示词的区别为什么值得多花时间写 skill有人可能会问我直接在对话里把要求说清楚不就行了为什么要费劲写一个 skill 文件这个问题我一开始也想过直到我统计了一下自己在某个项目里重复交代同一套规则的次数——光是“组件用函数式写法、样式用 CSS Modules、测试文件放同级目录”这句话我在两周内说了不下三十遍。每次都要打这么多字而且偶尔还会漏掉一两条导致 AI 生成的代码需要返工。Skill 的第一个价值就是消除重复沟通。写一次之后所有对话自动生效不用再念叨。第二个价值是保证一致性。人会说漏但文件不会。只要SKILL.md里写清楚了每次触发的行为都是完全一样的不会因为今天心情好多说一句、明天赶时间少说一句而产生差异。第三个价值是可传承。团队里来了新人不用口口相传“我们这里 AI 要这么用”直接把 skill 仓库拉下来就行。第四个价值是可组合。你可以写一个“基础代码规范”skill再写一个“React 特定规范”skill后者可以引用前者形成层次化的规则体系。从工程角度看skill 把提示词从“对话消耗品”变成了“代码资产”。它可以进版本控制可以 code review可以打 tag 发版本。这个转变的意义不亚于当年把散落在各处的 shell 脚本收进 Makefile。3. 从零开始安装 Claude Code 并跑通第一个 skill3.1 环境准备不同系统下的安装路径选择在聊 skill 的具体写法之前得先有一个能跑 skill 的环境。目前最主流的载体是 Claude Code它是一个命令行工具安装方式根据操作系统有所不同。我分别在 Windows、macOS 和 Linux 上都装过踩过的坑不太一样这里分别说一下。macOS 和 Linux 相对简单官方推荐的方式是通过 npm 全局安装。前提是你机器上已经有 Node.js 环境版本建议在 18 以上。命令就是一行npm install -g anthropic-ai/claude-code装完之后在终端输入claude如果能看到交互界面就说明成功了。如果提示“command not found”大概率是 npm 的全局 bin 目录没有加到 PATH 里可以用npm config get prefix看一下路径然后手动加进环境变量。Windows 的情况要复杂一些。如果你用的是 PowerShell安装命令是一样的但可能会遇到两个典型问题。第一个是执行策略限制PowerShell 默认不允许运行未签名的脚本需要先执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser把策略放宽。第二个是某些依赖需要虚拟化平台支持如果系统提示需要启用相关功能去“启用或关闭 Windows 功能”里把对应的选项勾上重启之后就能继续。我自己在 Windows 上更推荐用 WSL2把 Claude Code 装在 Linux 子系统里省去很多路径和权限的麻烦。提示安装过程中如果遇到网络相关的报错优先检查本机的包管理器和 Node 版本绝大多数安装失败都源于环境不匹配而不是工具本身的问题。3.2 验证安装与首次配置让 claude 命令真正可用装完之后别急着写 skill先确认基础功能是通的。在终端里输入claude --version能输出版本号就说明二进制文件已经就位。然后输入claude进入交互模式随便问一个简单问题比如“用一句话解释什么是递归”看它能不能正常回复。这一步的目的是排除认证和网络配置的问题。如果这一步卡住了常见的原因有几个。一是 API 密钥没有配置需要在环境变量里设置对应的 key或者通过工具提供的登录流程完成认证。二是终端编码问题在某些 Windows 终端里中文会显示成乱码换成 UTF-8 编码的终端就好。三是代理设置如果你所在的网络环境需要经过代理才能访问外部服务得在环境变量里配置好HTTP_PROXY和HTTPS_PROXY否则请求会超时。确认基础对话没问题之后可以看一下 skill 的默认存放目录。不同版本的 Claude Code 对目录的约定略有差异但通常会在用户主目录下有一个配置文件夹里面有一个skills子目录。你可以用claude的交互命令问它“我的 skill 目录在哪里”它会告诉你具体路径。知道这个路径很重要因为后面放 skill 文件就靠它。3.3 手动安装一个社区 skill以 GitHub 上的开源 skill 为例社区里已经有不少人把自己写的 skill 开源出来了热词里提到的“claude code 怎么手动装 github 上的 skills”就是很多人的实际需求。手动安装的流程其实不复杂核心就是把 skill 目录放到正确的位置。假设你在 GitHub 上看到一个 skill 仓库里面有一个skills文件夹下面有若干子目录每个子目录是一个独立的 skill。安装步骤如下把仓库克隆到本地任意位置比如git clone 仓库地址 /tmp/skill-repo。进入仓库找到skills目录看看里面有哪些 skill 文件夹。把你需要的那个 skill 文件夹整个复制到 Claude Code 的 skill 目录下。比如cp -r /tmp/skill-repo/skills/my-skill ~/.claude/skills/。重启 Claude Code或者在交互模式里执行重新加载 skill 的命令。用一条能触发该 skill 的指令测试一下看行为是否符合预期。这里有个细节复制的时候要确保SKILL.md在文件夹的根层级不要多套一层目录。我见过有人复制完之后路径变成~/.claude/skills/my-skill/my-skill/SKILL.md结果 AI 扫描不到白白折腾半天。另外如果 skill 依赖额外的脚本或模板文件也要一并复制过去保持目录结构完整。注意从社区安装 skill 之前建议先打开SKILL.md读一遍确认它声明的工具权限和实际行为是你可接受的。skill 本质上是一段会被 AI 执行的指令来源不明的 skill 存在风险。4. 自己动手写一个 skill结构、写法与调试4.1 确定 skill 的边界一个 skill 只做一件事写 skill 最容易犯的错误就是把它写成一个大而全的“万能规则文件”。我一开始也是这样把代码规范、提交规范、测试规范、文档规范全塞进一个SKILL.md里结果 AI 每次触发都加载一大堆无关内容既浪费上下文窗口又容易让指令之间互相干扰。后来我学乖了一个 skill 只负责一类任务边界要清晰到能用一句话说清楚。怎么判断边界是否合适我的标准是如果这个 skill 的 description 里出现了“以及”“还有”“顺便”这类词就说明它管得太宽了应该拆。比如“生成 React 组件以及编写对应的单元测试以及更新导出文件”就应该拆成三个 skill或者至少把“更新导出文件”这种附带动作交给 AI 自己判断不写进 skill。拆细之后还有一个好处可以按需组合。比如我有一个“基础 TypeScript 规范”skill一个“React 组件结构”skill一个“测试文件模板”skill。当我要生成一个组件时AI 会同时触发这三个各管各的互不冲突。如果哪天我换用 Vue只需要把“React 组件结构”换成“Vue 组件结构”其他两个照常工作。4.2 写好 description让 AI 在正确的时候想起你前面提过 description 的重要性这里展开讲一下具体怎么写。一个好的 description 应该包含三个要素触发场景、任务类型、限定条件。触发场景回答“什么时候用”比如“当用户要求创建新的前端页面时”。任务类型回答“做什么”比如“按照团队规范生成页面组件、路由配置和样式文件”。限定条件回答“在什么范围内用”比如“仅适用于使用 React Router 的项目”。把这三者组合起来就是一个合格的 description当用户要求创建新的前端页面且项目使用 React Router 时使用此 skill按照团队规范生成页面组件、路由配置和样式文件。对比一下常见的错误写法“前端页面生成 skill”——太模糊AI 不知道什么时候该触发“用于生成 React 页面”——缺少限定条件可能在 Vue 项目里也被触发“一个帮助开发者提高效率的 skill”——完全没信息量。我自己的习惯是写完 description 之后拿几条典型的用户指令在心里过一遍看这个 description 能不能准确匹配到该匹配的、排除掉不该匹配的。如果发现某条指令模棱两可就回去改 description直到边界清晰为止。4.3 正文写法用自然语言写清楚“怎么做”和“不要做什么”SKILL.md的正文部分没有严格的格式要求本质上就是一段给 AI 看的指令。但根据我的经验结构化的写法比一大段散文效果要好得多。我通常会用几个小标题把正文分成“执行步骤”“输出格式”“禁止事项”三块。“执行步骤”用有序列表写清楚第一步做什么、第二步做什么。比如生成 React 组件的 skill步骤可能是先读取项目里的组件模板文件然后根据用户提供的组件名生成文件路径接着按照模板填充内容最后更新导出文件。每一步都写得具体AI 执行起来就不容易跑偏。“输出格式”用代码块给出期望的输出样例。比如你希望 AI 生成的组件文件长什么样就直接在 skill 里贴一个示例代码块。AI 看到具体样例之后模仿的准确率会大幅提升。这比用文字描述“使用函数式写法、导出默认组件”要有效得多。“禁止事项”用无序列表列出绝对不允许出现的行为。比如“不要使用 class 组件”“不要引入未在 package.json 中声明的依赖”“不要在组件内部直接写死 API 地址”。这些禁止项往往是踩过坑之后总结出来的写进去能避免 AI 重复犯错。提示正文里可以引用项目里的其他文件比如“参考docs/coding-style.md中的命名规范”。AI 会去读被引用的文件这样可以把一些通用的规范抽出去单独维护skill 本身保持精简。4.4 调试 skill怎么知道它有没有生效写完 skill 之后怎么验证它真的被触发了最直接的方法是看 AI 的输出是否符合 skill 里定义的规则。如果不符合先别急着改 skill按下面的顺序排查。第一步确认 skill 文件被正确加载了。在 Claude Code 里问它“当前有哪些可用的 skill”看列表里有没有你刚写的那个。如果没有检查文件路径和目录结构是否正确。第二步确认 description 能匹配到你的测试指令。换几种不同的说法试试看是不是某些说法能触发、某些不能。如果发现触发不稳定说明 description 写得不够明确需要调整。第三步确认 skill 正文的指令没有和系统默认行为冲突。有时候 AI 不按 skill 来是因为 skill 里的要求和它自身的默认倾向矛盾而它选择了后者。这时候可以在 skill 里把要求写得更强硬一些比如用“必须”“严禁”这样的词。第四步看上下文窗口是不是被占满了。如果对话已经很长skill 的内容可能被挤出了有效上下文导致 AI “忘记”了规则。这种情况开一个新对话通常就能解决。我自己的调试习惯是每写完一个 skill就用三到五条不同的指令去测它覆盖“应该触发”和“不应该触发”两种情况。只有两边都符合预期才算这个 skill 写到位了。5. 常见问题与排查技巧实录5.1 安装与识别类问题速查问题现象可能原因排查方向终端提示找不到 claude 命令全局 bin 目录未加入 PATH检查 npm 全局路径并配置环境变量安装时提示需要虚拟化平台系统功能未启用在系统设置中启用对应功能并重启skill 列表里看不到自己放的 skill目录层级多套了一层确认 SKILL.md 在 skill 文件夹根层级AI 不按 skill 规则执行description 匹配失败或指令冲突换说法测试触发检查 skill 正文措辞多个 skill 同时触发导致输出混乱description 语义重叠在 description 中加技术栈限定词收窄范围这张表里的每一条都是我实际遇到过的。其中“目录层级多套一层”这个坑我踩过两次第一次折腾了半小时才反应过来是路径问题。后来我养成了一个习惯放完 skill 之后先用ls命令看一眼目标目录下的结构确认SKILL.md就在第一层。5.2 触发不稳定与行为漂移的处理经验触发不稳定是写 skill 过程中最让人头疼的问题。同样的指令有时候能触发有时候不能。我观察下来原因主要有三类。第一类是 description 的语义覆盖不够。比如你写的是“生成 React 组件”但用户说的是“帮我搞一个卡片组件”如果 description 里没有“卡片”“UI 元素”这类近义词AI 可能匹配不上。解决办法是在 description 里多列几个同义场景或者用更上位的词比如“生成 React UI 组件”。第二类是上下文干扰。如果当前对话里已经有很多其他指令AI 的注意力会被分散skill 的优先级可能被压低。这种情况我通常会在指令里显式提一句“按照项目里的组件规范来做”相当于手动给 skill 加一个触发信号。第三类是 skill 之间的优先级冲突。当两个 skill 都声称自己适用于当前场景时AI 可能随机选一个或者各取一部分。解决办法是在 description 里写清楚优先级关系比如“当同时存在通用组件规范和特定组件规范时优先使用本 skill”。行为漂移则是另一个层面的问题skill 触发了但 AI 执行到一半开始偏离规则。这通常是因为 skill 正文太长AI 读到后面忘了前面。我的应对方法是把最重要的规则放在正文最前面并且用加粗或列表的方式突出显示。另外把长 skill 拆成多个短 skill 也比一个巨型 skill 更稳定。5.3 我踩过的三个典型坑与修复过程第一个坑是在 skill 里写了太多“建议”而不是“要求”。我一开始写规则喜欢用“建议使用”“最好采用”这样的措辞结果 AI 把这些当成可选项经常不执行。后来全部改成“必须”“严禁”“一律”执行率明显上升。AI 对指令的服从度和措辞的强硬程度是正相关的这一点在写 skill 时尤其明显。第二个坑是skill 里引用了不存在的文件路径。我在 skill 正文里写“参考templates/component.tsx”但那个文件其实放在另一个目录下AI 去找的时候找不到整个 skill 的执行就卡住了。修复方法是在写引用之前先用绝对路径或相对于项目根目录的路径确认文件确实存在。第三个坑是没有给 skill 设版本。我改了一版 skill 之后发现新版本在某些场景下不如旧版本好用但旧版本已经被覆盖了找不回来。后来我养成了给 skill 目录加版本号的习惯比如react-component-v1、react-component-v2切换的时候改一下目录名就行。如果配合 Git 管理那就更稳妥了。5.4 关于 skill 分享与复用的几点建议当你写出一批好用的 skill 之后自然会想分享给团队或者开源出去。分享之前有几件事值得做。一是清理敏感信息。skill 里可能包含你项目的内部路径、私有依赖名、甚至 API 端点分享前要全部替换成占位符。我见过有人把公司内部接口地址写进 skill 然后推到公开仓库虽然不是什么大事故但总归不妥。二是补一份 README。SKILL.md是给 AI 看的README 是给人看的。在 README 里说明这个 skill 解决什么问题、适用于什么技术栈、怎么安装、怎么验证能大幅降低别人的使用门槛。三是标注兼容性。不同版本的 Claude Code 对 skill 格式的支持可能有差异在 README 里写清楚你测试过的版本范围能帮别人省去很多试错时间。四是接受反馈并迭代。skill 这种东西自己用和给别人用遇到的场景不一样别人可能会发现你没想到的边界情况。开放 issue 或者讨论区收集反馈之后定期更新skill 的质量会越来越高。6. 进阶方向把 skill 组合成工作流6.1 多 skill 协同让 AI 按流水线方式干活单个 skill 解决的是单点问题但实际开发往往是一连串动作。比如“新建一个页面”这件事拆开来看包括创建页面组件文件、创建对应的样式文件、在路由配置里注册、在导航菜单里加一项、写一个基础的测试文件。如果每个动作都是一个独立 skillAI 在触发时会依次加载并执行形成一条流水线。我目前的做法是把这条流水线里的每个环节都写成独立 skill然后在最上层的“页面生成”skill 里用自然语言描述执行顺序“先调用组件生成 skill 创建文件再调用路由注册 skill 更新配置最后调用测试生成 skill 创建测试文件。”AI 读到这段描述后会按顺序触发对应的子 skill。这样既保持了每个 skill 的独立性又能组合出复杂的工作流。这种组合方式的好处是灵活。如果哪天我换了一种路由方案只需要替换“路由注册”这个 skill其他环节不受影响。如果某个环节暂时不需要比如项目初期不写测试把对应的 skill 禁用就行不用改上层逻辑。6.2 领域专用 skill 的写法以数学建模和 AI 漫剧为例热词里出现了“数学建模 skills 推荐”和“AI 漫剧常用 skills”说明 skill 的玩法已经渗透到垂直领域了。我虽然主要做前端但也帮朋友看过几个数学建模方向的 skill这里说一下领域专用 skill 的写法特点。数学建模的 skill 和前端 skill 最大的区别在于它的输出不是代码文件而是论文段落、图表或者计算脚本。所以这类 skill 的正文里重点要放在“分析框架”和“表达规范”上。比如一个“灵敏度分析”skill需要告诉 AI先确定需要分析的参数然后设计扰动范围接着计算输出变化最后用规范的语言描述结论并生成对比图表。这些步骤用自然语言写清楚AI 就能按照建模论文的套路来输出。AI 漫剧方向的 skill 则更侧重创意流程的标准化。比如角色设定 skill 要规定角色卡的字段结构分镜 skill 要规定镜头描述的格式配音 skill 要规定语气和节奏的标注方式。这类 skill 的价值在于把创作者的隐性经验显性化让 AI 产出的内容保持统一的风格和水准。写领域 skill 的关键是找到该领域里那些“老师傅会做但新人不知道”的隐性规则把它们用明确的语言写出来。这需要你对领域本身有足够深的理解光懂 AI 工具是不够的。6.3 维护 skill 库的长期策略当 skill 数量超过十个之后管理就成了问题。我的做法是建一个专门的 Git 仓库来放 skill按领域分目录比如frontend/、backend/、writing/、data/。每个 skill 一个文件夹文件夹名就是 skill 名。仓库根目录放一个索引文件列出所有 skill 的名称、用途和适用场景方便快速查找。版本管理方面我给每个 skill 打 tag格式是skill-name/v1.0.0。当某个 skill 有破坏性变更时升大版本号新增功能升小版本号修 bug 升补丁号。这样在项目里引用 skill 时可以锁定版本避免上游更新导致行为突变。定期清理也很重要。有些 skill 可能只在特定项目里用过一次之后就再也没触发过。这类 skill 我会先归档到一个archive/目录观察一段时间如果确实不再需要就删掉。skill 库和代码库一样不清理就会越来越臃肿最终影响 AI 的匹配效率。6.4 关于 skill 生态的一点个人观察从我自己使用和观察社区的情况来看skill 这个机制目前还处于比较早期的阶段。好处是灵活几乎什么都能封装坏处是缺乏统一标准不同人写的 skill 质量参差不齐组合使用时经常需要手动调整。我预计接下来会出现一些约定俗成的规范比如 description 的写法模板、skill 之间的依赖声明方式、权限声明的粒度等等。对于现在就想上手的人来说我的建议是不要等标准出来再动手。先写几个自己最常用的 skill在实际使用中打磨等社区规范成熟了再往上面靠。skill 的核心价值在于把你的领域知识固化下来这个动作本身什么时候做都不亏。而且写得多了你对“什么样的指令 AI 能听懂”这件事的直觉会越来越准这个能力迁移到其他 AI 工具上同样适用。最后分享一个我最近在用的技巧把 skill 当成“给未来的自己写的备忘录”。每次我在某个问题上跟 AI 来回沟通超过三轮才得到满意结果我就会停下来想一想这个沟通模式能不能固化成一个 skill。能固化的就当场写下来下次直接触发省下的时间积少成多相当可观。
