1. 从“skills”这个热词说起它到底是什么为什么突然火了最近几个月不管是在技术社区还是各种开发者群里“skills”这个词出现的频率高得离谱。很多人第一次看到它会以为是某种新的编程语言或者框架其实不是。这里的skills特指围绕 Claude 生态尤其是 Claude Code、Claude Desktop 这类工具构建的一套可复用的能力模块机制。你可以把它理解成给 AI 助手装的“技能插件”——每个 skill 就是一份约定好格式的说明文件告诉模型在特定场景下该怎么做、按什么流程做、输出什么格式。核心载体是一个叫SKILL.md的文件。这个文件用 Markdown 写里面包含技能的元信息名称、触发条件、适用场景和具体的执行指令。当你在 Claude Code 里调用某个 skill 时模型会读取这份文件然后按照里面定义的步骤去完成任务。听起来简单但实际用起来它解决的是一个非常痛的问题每次让 AI 干活都要重新描述一遍需求而且每次输出的质量还不稳定。我举个自己的例子。之前做前端项目每次让 Claude 帮我写组件都要重复说“用 TypeScript、用函数式组件、样式用 Tailwind、不要用 any、导出用 named export”。说一次两次还行说二十次就烦了。后来我把这些要求写成一个frontend-component.skill.md之后只需要说“用 frontend-component skill 写一个日期选择器”输出就直接符合规范省掉了大量重复沟通。这就是 skills 最直接的价值把重复的指令固化成可复用的模块。适合谁来用三类人收益最明显。第一类是日常高频使用 Claude Code 做开发的工程师尤其是前端、后端、数据方向的skills 能显著减少 prompt 编写时间。第二类是做数学建模、数据分析的研究者热词里“数学建模 skills 推荐”“华为杯建模比赛好用的 codex skills”出现得很密集说明这个群体已经在用 skills 来标准化建模流程了。第三类是内容创作者比如做 AI 漫剧的热词里“ai 漫剧常用 skills”就是一个典型场景把分镜、角色设定、台词风格固化成 skill批量产出时一致性会好很多。需要说清楚的是skills 不是 Claude 独有的概念。OpenAI 的 Codex 生态里也有类似机制热词里“codex nature skills”“opencode skills”就是佐证。但目前在中文社区讨论度最高、资料最集中的还是 Claude 系的 skills。所以接下来我主要围绕 Claude Code 和 SKILL.md 来讲但底层思路是通用的你换成别的工具也能套用。2. skills 的整体设计与核心思路拆解2.1 为什么是 Markdown 文件而不是代码很多人第一反应会问为什么 skill 要用 Markdown 写而不是写成一个函数或者配置文件这个问题我一开始也想过后来用久了才明白设计者的意图。Markdown 的最大优势是模型天然能读懂。你写一个 JSON 配置模型还得解析字段含义你写一个 Python 函数模型得理解函数签名和逻辑。但 Markdown 是自然语言和结构的混合体模型读它就像读一段带格式的说明文档理解成本极低。而且 Markdown 对人也是友好的你随时可以打开 SKILL.md 看看这个技能到底定义了啥不需要额外的工具或文档。另一个原因是灵活性。代码是强约束的你定义了一个函数输入输出类型就固定了。但 skill 面对的任务往往是非结构化的比如“帮我审查这段代码的安全问题”这种任务的输出格式、检查维度都可能随场景变化。用 Markdown 写指令模型可以根据实际情况灵活调整而不是被死板的接口限制住。提示SKILL.md 虽然灵活但不代表可以随便写。结构越清晰、指令越具体模型执行越稳定。后面我会给出一个可参考的模板。2.2 skill 的触发机制模型怎么知道该用哪个技能这是很多人困惑的点。你写了一堆 skill 文件模型怎么知道当前该调用哪个答案是靠描述匹配。每个 SKILL.md 开头会有一段元信息通常包括name、description、when_to_use这几个字段。当你发出请求时模型会拿你的请求去和所有可用 skill 的描述做匹配找到最相关的那个来执行。这就意味着skill 的描述写得准不准直接决定了它会不会被正确触发。我踩过一个坑早期写了一个叫code-review的 skill描述只写了“代码审查”结果模型经常在我让它“优化代码”的时候也调用它因为“优化”和“审查”在语义上很接近。后来我把描述改成“当用户明确要求检查代码中的 bug、安全漏洞、性能问题时使用不用于代码重构或功能添加”触发准确率立刻上来了。所以写 skill 描述有个原则既要覆盖你想触发的场景也要明确排除不该触发的场景。这跟写正则表达式有点像你得同时考虑匹配和排除。2.3 方案选型自己写还是用现成的热词里“skills 推荐”“skills 技能库网址”“常用 skills”出现频率很高说明很多人想直接用别人写好的。我的建议是先抄后改最后自己写。刚开始用的时候去 GitHub 上搜awesome-claude-skills或者claude-skills这类仓库能找到不少现成的。比如typesafe-ai-skills这个仓库热词里出现过里面有一批 TypeScript 相关的 skill质量还不错。直接拿来用能快速体验到 skills 的价值。但用一段时间你会发现别人的 skill 总有些地方不合你的习惯。比如某个代码审查 skill 默认检查 10 个维度但你项目里只关心其中 3 个。这时候就该动手改了。改的过程其实就是学习怎么写 skill 的过程。最终阶段是自己写。当你发现自己反复在 prompt 里写同样的指令时就该把它固化成一个 skill 了。这个判断标准很实用同一段指令你写了三次以上就值得做成 skill。3. SKILL.md 的核心细节与实操要点3.1 一个可用的 SKILL.md 模板长什么样先直接给一个我实际在用的模板然后逐段解释。--- name: frontend-component description: 用于生成符合项目规范的前端组件。当用户要求创建新的 React 组件、Vue 组件或修改现有组件结构时使用。不用于纯样式调整或 bug 修复。 when_to_use: 用户提到创建组件新建组件写一个XX组件时触发 --- # 前端组件生成技能 ## 执行步骤 1. 确认组件名称和用途 2. 检查项目中是否已有类似组件可复用 3. 按以下规范生成代码 ## 代码规范 - 使用 TypeScript禁止使用 any - 使用函数式组件 Hooks - 样式使用 Tailwind CSS - 导出使用 named export - 每个组件必须包含 Props 类型定义 - 必须处理 loading 和 error 状态 ## 输出格式 先输出组件文件路径再输出完整代码最后列出使用示例。 ## 注意事项 - 如果用户没有指定组件名根据功能自动生成一个语义化的名称 - 如果涉及数据请求使用项目现有的 request 封装不要直接引入 axios这个模板分三块元信息frontmatter、执行步骤、规范与注意事项。元信息负责触发匹配执行步骤告诉模型按什么顺序做规范与注意事项是具体的约束条件。3.2 元信息字段怎么写才准name字段尽量用英文短横线命名比如frontend-component、code-review、>npm install -g anthropic-ai/claude-code装完之后在终端输入claude如果能进入交互界面就说明成功了。Windows 上坑会多一些。热词里有一条“claude 无法将 claude 项识别为 cmdlet、函数、脚本文件或可运行程序的名称”这就是典型的 PATH 没配好。npm 全局安装的包默认放在%APPDATA%\npm目录下你需要把这个目录加到系统环境变量 PATH 里。具体操作是打开“系统属性 → 高级 → 环境变量”在用户变量的 Path 里新增一条%APPDATA%\npm保存后重开终端。还有一个热词是“claudes workspace requires the virtual machine platform on windows. enable”这个提示通常出现在用 WSL 或者某些虚拟化环境的时候。解决办法是在“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”重启后即可。VSCode 里配置 Claude Code 也很常见热词“vscode 配置 claude code”“vscode 安装 claude code”。装好 CLI 之后在 VSCode 的集成终端里直接运行claude就能用。如果想更方便可以装一个终端插件把 claude 命令绑定到快捷键上。4.2 创建你的第一个 skill 文件环境好了之后找到 skill 的存放目录。Claude Code 默认会从项目根目录下的.claude/skills/文件夹读取 skill也会从用户主目录的~/.claude/skills/读取全局 skill。项目级的 skill 只对当前项目生效全局的对所有项目生效。我建议先建项目级的因为项目级的 skill 可以跟着代码仓库走团队其他人 clone 下来就能用。创建目录和文件mkdir -p .claude/skills/code-review touch .claude/skills/code-review/SKILL.md然后往 SKILL.md 里写内容。我以一个代码审查 skill 为例给出完整内容--- name: code-review description: 对代码进行审查检查 bug、安全漏洞、性能问题和代码规范。当用户要求审查代码、检查代码质量、查找问题时使用。不用于代码格式化、不用于功能开发。 when_to_use: 用户说审查这段代码帮我看看有没有问题检查一下代码质量时触发 --- # 代码审查技能 ## 审查维度 按以下顺序逐项检查每项给出具体发现 1. 正确性逻辑是否有误边界条件是否处理 2. 安全性是否有注入风险、敏感信息泄露、权限问题 3. 性能是否有明显的性能瓶颈如循环内查询、不必要的重复计算 4. 可维护性命名是否清晰函数是否过长是否有重复代码 5. 规范是否符合项目既定的代码风格 ## 输出格式 按严重程度分级输出 - 严重必须修复的问题 - 警告建议修复的问题 - 提示可选的改进建议 每个问题需包含文件位置、问题描述、修复建议。 ## 注意事项 - 不要为了凑数而报告无关紧要的问题 - 如果代码整体质量良好直接说明不要强行找问题 - 涉及安全问题时给出具体的攻击场景说明写完保存然后在 Claude Code 里测试。输入“用 code-review 审查一下 src/utils.ts”看看模型是否按你定义的格式输出。4.3 参数计算与选择skill 数量控制在多少合适这是一个很多人没想过的问题。skill 是不是越多越好我的实测结论是项目级 skill 控制在 5 到 10 个之间最合适。原因在于触发匹配机制。模型每次收到请求都要在所有可用 skill 的描述里做匹配。skill 数量少的时候匹配准确率高数量多了之后描述之间的语义重叠会增加误触发的概率上升。我试过在一个项目里放了 20 多个 skill结果经常出现“让它写组件它去调代码审查 skill”这种情况。那怎么控制数量我的做法是按任务类型合并。比如“写 React 组件”和“写 Vue 组件”可以合并成一个frontend-componentskill在内部用条件分支处理不同框架。“代码审查”和“安全审查”也可以合并安全审查作为代码审查的一个维度。如果你确实有很多独立场景可以考虑分层项目级放最常用的 5 到 10 个全局级放跨项目通用的几个剩下的按需临时启用。4.4 实操现场记录一次完整的 skill 调用过程我拿最近做的一个数据处理任务来演示。需求是“读取 sales.csv按月份统计销售额输出柱状图”。第一步我在项目里建了一个>--- name:>