1. 从“skills”这个热词说起它到底是什么为什么突然火了最近几个月不管是在技术社区还是各种开发者群里“skills”这个词出现的频率高得离谱。很多人第一次看到它会以为是某种新出的编程语言或者框架其实不是。这里的skills特指围绕 Claude 生态尤其是 Claude Code、Claude Desktop 这类工具构建的一套可复用的能力模块机制。你可以把它理解成给 AI 助手装的“技能插件”——每个 skill 就是一份结构化的说明文件告诉模型在特定场景下该怎么思考、该调用什么工具、该遵循什么流程。我最早接触这个概念是因为身边做前端的朋友在群里晒他的SKILL.md文件说配好之后 Claude Code 写 React 组件的风格突然就“对味”了。后来自己上手折腾了一段时间才发现这东西的价值远不止“让 AI 听话”这么简单。它真正解决的是一个老问题通用大模型什么都会一点但在具体领域里总差那么一口气。skills 就是把这“一口气”补上的手段。这篇文章适合几类人看一是刚听说 Claude Code、想搞清楚 skills 到底怎么用的新手二是已经在用 Claude 但觉得输出不够稳定、想通过 skills 做定制的老用户三是做数学建模、前端开发、AI 内容创作这类具体工作想找现成 skills 直接抄作业的从业者。我会从设计思路讲到实操细节再到踩过的坑尽量把我知道的都倒出来。需要先说明一点skills 不是某个官方垄断的东西它的核心就是一份 Markdown 格式的说明文件通常叫SKILL.md加上可选的辅助脚本和资源。这意味着它的门槛极低你不需要会写复杂的代码只要能把“我希望 AI 在这个场景下怎么做”用清晰的语言描述出来就能做出一个能用的 skill。这也是它能在短时间内爆发的根本原因。2. skills 的整体设计思路为什么是 Markdown而不是插件系统2.1 核心机制拆解一份文件如何改变模型行为要理解 skills 为什么这么设计得先明白大模型的一个基本特性它对上下文里的指令极其敏感。你在对话开头塞一段“你是一个资深前端工程师写代码时优先使用函数式组件”的说明模型的输出风格立刻就会变。skills 本质上就是把这个“塞说明”的动作标准化、持久化了。一个典型的 skill 目录结构大概是这样my-skill/ ├── SKILL.md # 核心说明文件必须有 ├── scripts/ # 可选放辅助脚本 │ └── helper.py └── resources/ # 可选放参考文档、模板 └── template.mdSKILL.md是整个 skill 的灵魂。它通常包含几个部分元信息名称、描述、适用场景、行为指令模型应该遵循的规则、工具调用说明如果需要调用外部工具、示例输入输出样例。模型在加载这个 skill 后会把这些内容作为系统级上下文的一部分从而在后续对话中持续遵循。为什么用 Markdown 而不是 JSON 或 YAML我的理解是Markdown 对模型来说是最“自然”的格式。大模型的训练数据里充斥着大量 Markdown 文档它对标题层级、列表、代码块的理解非常到位。你用 Markdown 写指令模型几乎不会误读换成严格的 JSON schema反而可能因为格式问题导致解析失败。这是一个非常务实的选择。2.2 和其他方案对比为什么不用传统插件或微调有人会问要做定制化为什么不直接微调模型或者写一个传统的插件系统这里有几个现实考量。微调的成本太高了。且不说需要大量标注数据光是训练和部署的资源投入就不是个人开发者能轻松承担的。而且微调后的模型是“死”的场景一变就得重新训。skills 则是“活”的改几行文字就能调整行为迭代成本几乎为零。传统插件系统比如某些平台的 function calling要求你定义严格的接口模型只能在你划定的框框里调用。skills 更灵活它不仅能定义工具调用还能定义思维方式。比如你可以写一个“数学建模 skill”里面规定模型必须先分析问题类型、再选择模型、最后做敏感性分析。这种流程性的指导传统插件很难表达。还有一个关键点skills 是可组合的。你可以同时加载多个 skill让模型在不同场景下切换不同的能力。比如一个“前端开发 skill”加一个“代码审查 skill”写代码时用前者review 时用后者。这种灵活性是单一微调模型做不到的。2.3 适用场景判断什么时候该写 skill什么时候不该不是所有场景都值得写 skill。我的经验是满足以下条件之一才考虑重复性高同一个任务你会反复让 AI 做比如每周都要生成周报、每次都要按固定格式写组件。要求稳定你对输出格式、风格有严格要求不能每次都不一样。有领域知识任务涉及特定领域的规则、术语、流程通用模型容易出错。反过来如果只是一次性的、探索性的任务直接对话就行没必要写 skill。写 skill 本身也是要花时间的别为了用而用。3. 核心细节解析一个高质量 SKILL.md 该怎么写3.1 元信息部分名称和描述决定模型会不会用对元信息看起来简单其实很关键。模型在决定是否激活某个 skill 时主要看的就是名称和描述。名称要具体不要叫“helper”这种模糊的词叫“react-component-generator”就清楚多了。描述要写清楚什么时候用而不是这是什么。举个例子差的描述是“这是一个用于生成 React 组件的 skill”。好的描述是“当用户需要创建新的 React 函数式组件、且项目使用 TypeScript 和 Tailwind CSS 时使用此 skill”。后者给了模型明确的触发条件避免在不该用的时候乱用。我踩过的一个坑是早期写 skill 时描述太宽泛结果模型在任何涉及代码的对话里都试图激活它反而干扰了正常交流。后来把触发条件写具体问题就解决了。3.2 行为指令部分把“潜规则”显式化这是 SKILL.md 里最需要花心思的部分。你要把平时靠经验积累的“潜规则”全部写出来。比如写前端组件你心里知道“不要用 any 类型”“样式优先用 Tailwind 而不是内联”“组件要拆得足够小”这些都要明确写进指令里。指令的写法有几个技巧。第一用肯定句而不是否定句。与其说“不要使用 class 组件”不如说“始终使用函数式组件配合 Hooks”。模型对肯定指令的遵循度更高。第二给出理由。模型在理解“为什么”之后泛化能力会更强。比如“使用 Tailwind 是因为项目统一了设计系统避免样式碎片化”。第三分优先级。如果规则很多标注哪些是必须遵守的哪些是建议。一个实用的结构是用三级标题分块### 必须遵守 - 始终使用 TypeScript 严格模式 - 组件文件使用 PascalCase 命名 ### 建议做法 - 优先拆分可复用逻辑到自定义 Hook - 样式使用 Tailwind 类名3.3 示例部分少而精覆盖边界情况示例是模型学习行为模式的重要参考。但不要堆砌大量相似例子那样反而会让模型抓不住重点。我的做法是给2 到 3 个例子一个标准情况一个边界情况一个错误示范。错误示范特别有用。你可以写“以下是不推荐的写法”然后给出反例再说明为什么不好。模型通过对比能更准确地理解你的意图。这比单纯说“要这样做”效果好得多。3.4 工具调用说明什么时候需要怎么写如果你的 skill 需要调用外部工具比如执行脚本、读取文件就要在 SKILL.md 里说明。这部分要写清楚什么时候调用、传什么参数、怎么处理返回值。比如一个“数据清洗 skill”可能需要调用 Python 脚本当用户提供 CSV 文件路径时调用 scripts/clean_data.py 传入文件路径作为第一个参数。脚本会返回清洗后的文件路径 后续分析基于清洗后的数据。注意不要写得太技术化模型需要的是“意图层面”的说明而不是完整的 API 文档。把调用时机和目的说清楚就够了。4. 实操过程从零搭建一个可用的 skill4.1 环境准备Claude Code 的安装与配置在写 skill 之前得先把运行环境搭好。Claude Code 是官方提供的命令行工具安装方式根据系统不同有所差异。在 macOS 或 Linux 上通常通过包管理器安装Windows 用户需要注意某些功能可能依赖虚拟化平台安装过程中如果提示需要启用相关组件按提示操作即可。安装完成后第一次运行需要完成认证配置。这里有个常见问题如果提示命令无法识别多半是环境变量没配好。检查一下安装路径是否加进了 PATH。另外部分地区可能遇到服务不可用的情况这是正常的网络限制需要自行确认所在区域的支持情况。配置完成后你可以通过claude命令进入交互模式。建议先跑一个简单的对话测试确认基础功能正常再开始折腾 skills。4.2 创建第一个 skill从需求到文件假设我要做一个“数学建模辅助 skill”用于比赛时快速生成建模思路。步骤如下第一步确定 skill 的存放位置。Claude Code 通常会在特定目录下查找 skills具体路径可以在配置文件中查看。一般是用户主目录下的某个隐藏文件夹。第二步创建目录和文件mkdir -p ~/.claude/skills/math-modeling touch ~/.claude/skills/math-modeling/SKILL.md第三步编写 SKILL.md 内容。我会先写元信息再写行为指令最后加示例。行为指令部分重点写先判断问题类型优化、预测、评价等再推荐合适的模型最后要求给出敏感性分析。这些都是数学建模的“套路”写进去之后模型输出会专业很多。第四步测试。重启 Claude Code在对话里提一个建模问题观察模型是否按照 skill 的指令来回答。如果没生效检查文件路径和格式是否正确。4.3 参数与配置让 skill 更精准的几个关键点有几个配置项会显著影响 skill 的效果。触发阈值决定了模型多“积极”地使用这个 skill设太高会漏用设太低会滥用。优先级在多个 skill 冲突时起作用比如同时加载了“简洁回答”和“详细解释”两个 skill得指定谁优先。还有一个容易被忽略的点skill 的加载顺序。后加载的 skill 可能会覆盖先加载的部分指令。如果发现行为不符合预期可以调整加载顺序试试。我在配置数学建模 skill 时特意把“必须给出模型假设”这条放在指令最前面因为这是建模里最容易被忽略但最重要的部分。实测下来放在前面的规则被遵循的概率明显更高。4.4 验证与迭代怎么判断 skill 写得好不好写完不是结束得验证。我的方法是准备一组测试用例覆盖典型场景和边界场景每次修改 skill 后都跑一遍看输出是否稳定。比如数学建模 skill我会准备三个问题一个优化问题、一个预测问题、一个评价问题。好的 skill 应该能让模型对这三类问题都给出结构化的、符合建模规范的回答。如果某一类表现差就针对性调整指令。迭代时要注意一次只改一个变量。同时改多处出了问题都不知道是哪里的锅。改完记录一下改动内容和效果积累几次之后你就对“什么样的指令有效”有感觉了。5. 常见问题与排查技巧实录5.1 skill 不生效的几种典型原因这是新手最常遇到的问题。根据我的排查经验原因通常集中在以下几类现象可能原因排查方法完全没反应文件路径错误确认 skill 放在正确的目录下偶尔生效描述不够具体检查元信息里的触发条件是否明确行为混乱指令冲突检查是否有多个 skill 规则矛盾格式报错Markdown 语法问题用 Markdown 预览工具检查我遇到最多的是路径问题。不同版本的 Claude Code 可能从不同位置读取 skills建议先查官方文档确认当前版本的约定路径。另外文件名必须是SKILL.md大小写敏感写成skill.md可能识别不了。5.2 输出不稳定的调试思路有时候 skill 生效了但输出时好时坏。这通常是因为指令本身有歧义。比如你写“尽量简洁”模型对“简洁”的理解可能每次都不一样。改成“回答控制在三句话以内”就明确多了。另一个原因是上下文干扰。如果对话历史很长早期的内容可能会稀释 skill 的影响力。解决办法是在关键节点重新强调 skill 的规则或者开新对话。还有一个技巧在 skill 里加入自检指令。比如“在给出最终答案前确认是否满足以下所有要求”。模型在执行自检时会更严格地遵循规则。5.3 多个 skill 冲突时的处理当你加载了多个 skill它们之间可能打架。比如一个说“用中文回答”另一个说“用英文回答”。这时候模型会随机选一个结果就是不稳定。处理原则是明确优先级。在配置里指定哪个 skill 优先或者在 skill 的元信息里标注适用范围。更好的做法是合并相关 skill把不冲突的部分整合到一个文件里减少冲突面。我个人的习惯是功能相近的 skill 尽量合并保持加载的 skill 数量在三个以内。太多 skill 不仅容易冲突还会拖慢响应速度。5.4 性能与资源占用的注意事项skill 本身是文本文件占用资源可以忽略。但如果 skill 里引用了大量外部资源比如大文件、复杂脚本就可能影响性能。建议把非必要的资源做成按需加载不要一股脑塞进 skill 目录。另外skill 里的指令越长消耗的上下文窗口越多。如果你的对话本来就长再加上冗长的 skill可能会触及上下文上限。所以指令要精炼把最重要的规则放在前面。6. 进阶玩法让 skills 真正融入工作流6.1 组合使用前端开发加代码审查的联动单独一个 skill 能解决的问题有限真正提效的是组合。我现在的配置是一个“前端组件生成 skill”负责写代码一个“代码审查 skill”负责检查。写完组件后直接让模型用审查 skill 过一遍能抓出不少低级问题。组合的关键是职责清晰。生成 skill 只管生成审查 skill 只管审查不要互相越界。如果生成 skill 里也写了审查规则两边就会重复甚至矛盾。6.2 团队协作skill 的共享与版本管理如果是团队使用skill 最好纳入版本管理。把 skill 目录放进 Git 仓库每个人拉取最新版本。这样能保证团队成员的 AI 行为一致避免“你生成的代码风格和我生成的不一样”这种问题。共享时要注意脱敏。skill 里可能包含项目特定的路径、密钥、内部规范共享前检查一遍别把敏感信息带出去。6.3 持续优化根据使用反馈迭代 skillskill 不是写完就完事的。用一段时间后你会发现某些指令没效果某些场景没覆盖到。这时候就迭代。我的习惯是每次遇到不满意的输出就想想“如果 skill 里加一条什么规则能避免”然后加上去。积累几个月后你的 skill 会越来越贴合自己的需求变成一个真正个性化的“AI 工作伙伴”。这个过程本身也是对自己工作流程的梳理挺有意思的。6.4 从 skills 到个人知识库的延伸再往深了想skills 其实可以和个人知识库结合。比如把你常用的代码片段、设计模式、业务规则都整理成 skill 的一部分模型在需要时就能直接调用。这相当于把你的经验“外化”成了可执行的指令。我现在维护着一个“个人开发规范 skill”里面记录了我这些年积累的各种最佳实践。每次开新项目加载这个 skillAI 就能按照我的习惯来工作省去了大量重复解释的时间。这大概就是 skills 这个机制最有价值的地方——它让 AI 真正开始“懂你”。