1. 从“skills”这个热词说起它到底是什么为什么突然火了最近几个月不管是在技术社区还是各种开发者群里“skills”这个词出现的频率高得离谱。很多人第一次看到它会以为是某种新出的编程语言或者框架其实不是。这里的skills特指围绕 Claude 生态尤其是 Claude Code、Claude Desktop构建的一套可复用的能力模块。你可以把它理解成给 AI 助手装的“插件包”或者“技能卡”——每一张卡定义了一类具体任务的处理方式AI 在遇到对应场景时就会自动调用这套预设好的流程。我最早接触这个概念是在折腾 Claude Code 的时候。当时想让它在终端里帮我处理一些重复性的代码审查工作结果发现每次都要重新描述需求效率很低。后来看到有人提到SKILL.md这个文件才意识到原来可以把一套完整的操作规范写成一个 skill让 AI 按固定套路执行。这个发现直接改变了我使用 AI 编码助手的方式。那 skills 到底能做什么简单来说它解决的是AI 能力复用的问题。没有 skills 的时候你每次让 AI 做一件事都得从头解释背景、步骤、输出格式有了 skills你只需要说“用那个 skill 处理一下”AI 就知道该走什么流程、输出什么结构。适合谁来学我觉得三类人最需要一是每天跟 AI 编码工具打交道的开发者二是需要批量处理文档或数据的运营人员三是想把自己的一套工作方法论沉淀下来、让 AI 替自己执行的人。提示skills 不是 Claude 独有的概念其他 AI 工具生态里也有类似机制但 Claude 系的 SKILL.md 格式目前最成熟、社区资源最多。2. skills 的核心机制拆解SKILL.md 到底怎么写才管用2.1 SKILL.md 的文件结构与字段含义一个标准的 skill 通常以一个SKILL.md文件为核心。这个文件不是随便写写就行的它有一套约定俗成的结构。我拆过十几个社区里流传的 skill 文件发现能稳定工作的那些基本都包含以下几个部分nameskill 的唯一标识名建议用英文小写加连字符比如code-review-python。description一句话说明这个 skill 干什么用AI 会靠这句话判断什么时候该调用它。trigger触发条件可以是关键词、文件类型、或者用户显式指定的命令。instructions核心部分详细描述执行步骤、注意事项、输出格式。examples可选但强烈建议加给 AI 几个输入输出的样例能大幅提升执行准确率。我试过只写 instructions 不写 examples结果 AI 经常在输出格式上跑偏。后来补了两个例子进去同样的任务输出稳定性明显提升。这个经验告诉我examples 不是装饰是约束。2.2 为什么 description 和 trigger 决定了 skill 的生死很多人写 skill 的时候把精力全花在 instructions 上description 随便写一句“处理代码”trigger 也不设。结果就是 AI 根本不知道什么时候该用这个 skill或者在不该用的时候乱用。我的做法是description 要写得像给同事介绍这个工具说清楚“什么场景下用、解决什么问题、输出什么”。比如不要写“代码审查”而要写“对 Python 函数进行静态审查检查命名规范、异常处理和类型注解输出问题列表和修改建议”。trigger 则要尽量具体可以用文件扩展名、目录路径、或者用户输入中的特定短语来限定。注意trigger 写得太宽泛会导致 skill 被频繁误触发写得太窄又可能永远不被调用。建议先用宽一点的 trigger 跑几天观察日志后再收窄。2.3 instructions 的写法把 AI 当成一个需要详细交接的新人instructions 部分是最考验功力的。我的体会是不要假设 AI 知道任何背景。你觉得理所当然的步骤它可能完全忽略。所以 instructions 要写得像给一个刚入职的新人做交接——每一步做什么、用什么工具、遇到什么情况怎么处理、输出成什么格式全部写清楚。举个例子我写过一个处理 CSV 数据的 skillinstructions 里明确规定了先检查文件编码如果是 GBK 就转 UTF-8然后检查列名是否包含中文如果有就生成英文映射表最后输出时保留原始列顺序。这些细节如果不写AI 每次处理的结果都不一样。另外instructions 里可以用条件分支的写法。比如“如果输入是目录则遍历所有 .py 文件如果是单个文件则只处理该文件”。这种写法能让一个 skill 适配多种输入场景复用率更高。3. 从零开始搭建一个可用的 skill完整实操流程3.1 环境准备与目录结构规划在动手写之前先要把目录结构定好。我目前的习惯是在项目根目录下建一个.claude/skills/文件夹每个 skill 一个子目录里面放 SKILL.md 和相关的辅助文件。这样做的好处是版本控制方便迁移的时候整个文件夹拷走就行。如果你用的是 Claude Code它默认会扫描特定路径下的 skill 文件。具体路径可以在配置里改但我建议就用默认的省得后面出问题。Windows 用户要注意路径分隔符的问题我踩过一次坑在 SKILL.md 里写了相对路径用反斜杠结果在 Linux 环境下跑不起来。后来统一改成正斜杠跨平台就没问题了。3.2 编写第一个 skill以“代码审查”为例我拿一个实际用过的代码审查 skill 来演示。这个 skill 的目标是对指定的 Python 文件进行审查输出问题清单和修改建议。首先建目录.claude/skills/code-review-python/然后在里面创建SKILL.md。文件内容大致如下--- name: code-review-python description: 对 Python 文件进行静态审查检查命名规范、异常处理、类型注解和潜在 bug输出问题列表和修改建议。 trigger: 用户提到审查代码或指定 .py 文件时触发 --- ## 执行步骤 1. 读取目标文件内容如果文件超过 500 行分段读取。 2. 检查以下维度 - 函数和变量命名是否符合 PEP 8 - 是否有裸 except 或过宽的异常捕获 - 公开函数是否有类型注解 - 是否有明显的资源未释放如文件句柄 3. 对每个问题记录行号、问题类型、严重程度高/中/低。 4. 输出格式 - 先给一个汇总表行号 | 类型 | 严重程度 | 简述 - 再给详细说明和修改建议 ## 注意事项 - 不要修改原文件只输出建议 - 如果文件语法错误无法解析直接报告错误位置 - 严重程度判断标准会导致运行时报错的为高影响可读性的为中风格问题为低写完这个文件后我在 Claude Code 里测试了几次。第一次跑的时候它把一些风格问题标成了“高”明显不符合我的预期。后来我在 instructions 里补了一句“风格问题一律标为低除非团队规范明确要求”再跑就正常了。3.3 测试与迭代怎么判断一个 skill 是否合格测试 skill 不能只跑一次就完事。我的做法是准备一组边界用例空文件、超长文件、语法错误的文件、包含中文注释的文件分别跑一遍看输出是否稳定。如果某个用例下 AI 的表现和预期差距大就回去改 instructions把那个场景明确写进去。还有一个技巧在 skill 里加一个self-check步骤。比如让 AI 在输出前自己检查一遍“是否所有问题都标了严重程度”“汇总表和详细说明是否一致”。这个步骤看起来多余但实测能减少很多低级错误。提示skill 的迭代周期一般是“写一版 → 跑五个用例 → 改一版 → 再跑”循环三四次基本就能稳定下来。4. 进阶玩法让 skills 组合起来解决复杂问题4.1 skill 之间的调用与编排单个 skill 能解决的问题有限真正有意思的是把多个 skill 串起来。比如我有一个“数据清洗”skill 和一个“生成报告”skill单独用都还行但每次都要手动跑两次。后来我在“生成报告”的 instructions 里加了一句“如果输入数据未清洗先调用>