Skill 不仅是给 Claude 的操作手册，更是提升 AI 协作效率的利器。本文将深入拆解 Skill 的三层结构，揭示 description 这 100 字如何决定 Skill 的生死，并通过真实案例分享创建过程中的四个关键问题和三轮测试经验，带你掌握从理论到实践的完整方法论。

拖了挺久的一件事

其实关于Skill的文章，很早之前就已经写完了，但总是感觉缺点什么，所以拖了很久没有发出来。后面也刷到了一篇关于写作方法的文章，里面讲了写文章最重要的一点就是要“我”的存在。我才清楚了自己的文章差在哪一点。比起写一篇Skill的科普文章，更应该把自己的学习过程和感悟分享出来。于是我重新写了这篇基于我真实学习过程的文章，里面有我踩过的坑、总结的经验以及跟Claude学习的真实过程。

关于Skill我之前在公众号、抖音、推特，断断续续刷到过很多次，也认真看过几篇文章，问我Skill是什么，我能说出个一二三。但说完总觉得哪里差一口气，好像有什么东西还没真正搞明白。

直到那天，我直接打开Claude问它，你能教我怎么创建一个Skill吗？

接下来发生的事，比我想象的简单很多。

也比我想象的，有意思很多。

一句话说清楚它是什么

用一句话说清楚Skill是什么，其实挺容易，就是你给Claude写的操作手册。把你的工作习惯、风格要求、判断标准写进去，做成一个文件，上传给Claude。以后每次遇到对应的任务，它自己就知道该怎么做，不用你每次重新解释背景。

我平时做抖音视频，看到好的视频文案，经常让Claude帮我改写成自己的风格。原来的做法是，在同一个窗口里，每次把相同的提示词重复发给它，这是一个典型的、蠢蠢的重复性动作。Skill解决的就是这件事，把你每次都要重复说的话，固化成一个文件，让Claude一直记着。

就这一件事。

三层结构，最重要的在第一层

但说清楚了还不够，更重要的是理解它的结构。

每个Skill都有三层，拿我做的抖音文案改写Skill来说，第一层是元数据，就是name和description，其中description是一段一百字左右的文字，规定了什么情况下Claude会调用这个Skill。第二层是SKILL.md正文，你的操作指令、风格要求、输出格式都写在这里，但它不是一直在线的，只有Claude通过description判断需要触发的时候，才会去读它。第三层是附属资源，脚本、参考文档、模板文件这些，Claude不会一次性全读，根据SKILL.md里的指引，需要的时候才去读对应的文件。

理解这三层之后，有件事变得非常清晰。

我跟Claude聊到description的时候，问它，description最重要的原因是什么。它说，它能决定这个Skill到底调不调用。我说为什么它能决定？Claude说，它处于第一层，Claude接到你的提示词之后，会先去读所有Skill的description，然后再决定调不调用。

这段话让我一下子想通了，第二层写得再好，第三层资源再丰富，如果第一层的description没有匹配上，Claude根本不会去读后面的内容。就好比你投简历，HR先看的是简历摘要，觉得对了才会打开详细内容，摘要写得不够好，后面写得再详细也没用。

所以Skill里最关键的，不是那几百行的操作指令，而是那不到一百个字的description。

这个认知，后来对我帮助很大。

description，决定Skill生死的那100个字

说到description，我专门多说几句，因为我自己踩过坑。

很多人创建Skill的时候，会把大部分精力放在SKILL.md正文上，写了很详细的操作指令，设计了很完整的输出格式，但description随便写了几个字，结果Skill根本不触发，或者在不该触发的时候触发了。

description有两个核心任务，让Claude在该触发的时候触发，在不该触发的时候不触发。听起来很简单，但有两条原则必须记住。

第一条，覆盖你真实会说的表达方式。我在学的时候，Claude问我，你创建的这个改写抖音脚本的Skill，你真实说话的时候，会用「抖音脚本」这个词吗？还是可能会说「短视频文案」、「口播稿子」？

我愣了一下，确实，我平时说话很少用「抖音脚本」，更多会说「文案」、「稿子」、「口播」。你写的是你认为「正确」的表达，但用的时候说的是「真实」的表达，两者不一样，Claude就匹配不上。所以我最终把触发条件写成了，只要收到一段抖音脚本、短视频文案、抖音自媒体文案、文案内容、口播稿子等相关描述，并有改写要求。把我可能说的几种表达都覆盖进去。

第二条，语气要够强制。Claude有一个天然的倾向，就是觉得自己能处理的任务会直接回答，不去触发Skill，对简单任务尤其明显。所以description不能只描述触发场景，还要明确告诉Claude，这种情况你必须用Skill，不能自己搞。具体怎么写，加上这样的句子，「必须立即触发此Skill，不得自行处理」。听起来有点强硬，但这就是让Skill稳定触发的方式。

但有个地方要注意，强制不等于无限制触发。我的AI辅助写作Skill在这里踩过坑，触发条件如果只写「收到写作相关内容」，范围就太宽了，我平时给Claude发一个话题聊天，或者发一篇文章让它帮我分析，都可能被误触发。所以对容易误触发的Skill，还需要加关键词限制。我最终加了「必须包含『帮我写』、『我想写』、『写一篇』等关键词才触发」这样的限制。

description不只是让Skill触发，更重要的是让它在正确的时候触发，在不正确的时候不触发。这两件事，同样重要。

动手之前，先想清楚这四个问题

好，知道怎么写description了。但在动手之前，还有一件更重要的事，想清楚你要创建的Skill到底是什么。

这个阶段需要回答四个问题。

第一个，这个Skill做什么。听起来简单，但要说清楚不容易。「帮我改写文章」和「把别人的抖音脚本改写成我的风格」，前者太宽，后者才是真正有用的定义。

第二个，什么时候触发。要结合你真实的使用习惯来回答，不能只想「这个Skill应该在什么情况下用」，要想「我真实说话的时候会怎么描述这个需求」。

第三个，输出什么格式。是一段文字还是一份文档，Markdown格式还是纯文本，这些要提前想好写进SKILL.md。

第四个，怎么判断输出好不好。这个问题最难，也最容易被忽略。我当时的第一反应是「让数据变好」，做抖音嘛，播放量、完播率是最直接的。但Claude直接指出，这条标准能不能转化成一个看文字本身就能判断的条件？

这个问题让我想了一会儿。后来我说，或许可以参考这个框架，钩子→痛点→解决方案→金句→CTA。Claude说，对，这就把「数据好不好」这个无法在测试时验证的结果，转化成了看文字就

能打分的结构性标准。

这个转化很重要。Skill的评估标准必须是「即时可判断」的，你拿到输出，马上就能判断好不好，不需要等外部反馈。「数据变好」做不到，因为你测试Skill的时候还没发布，根本没有数据。而「符合钩子→痛点→解决方案→金句→CTA的结构」做得到，因为看文字就能判断。

四个问题回答完，把它们整成一张表，做什么、何时触发、输出格式、好坏标准。有了这张表，写SKILL.md就不是在凭感觉写了，是在把这四个答案翻译成Claude能理解的指令。

写SKILL.md：把四个答案翻译成指令

写SKILL.md本身其实不是最难的，把上面四个问题想清楚之后，SKILL.md的内容基本就出来了，改写要求、输出结构、参考风格、输出格式，四个模块。

这里有一个认知很重要，参考风格这个模块，很多人会忽略，但它极其关键。你用文字描述风格要求，永远没有直接给样本来得准确。「朗朗上口、有网感」这八个字，一百个人有一百种理解，但你给三个真实的高质量样本，Claude能直接感受到你要的是什么感觉。我放了三个真实发布过的脚本内容作为参考风格，都是我自己觉得质量比较好的。

但写完第一版，它一定不是最好的版本。

SKILL.md不是写完就完事的东西，它是一个需要不断迭代的活文档。

三轮测试，每轮都踩了不同的坑

我自己做了三轮比较完整的测试，说一下每轮发现了什么。

第一轮，钩子太夸张。Claude生成了一个钩子，「一个插件，能让你的Gemini直接进化成另一个物种」。我看到这句话的第一反应是，有点夸张。然后认真想了一下，这个插件的功能是去水印、加时间轴、加文件管理器，都是体验优化类的小功能，说「进化成另一个物种」，和后面的内容完全不匹配，观众看完会有被骗的感觉。这次测试之后，我在改写要求里加了一条，钩子要有悬念感，但不能夸大，钩子的承诺必须和后面的内容相匹配。

第二轮，缺对比句，节奏平。我把有问题的句子发给Claude，它帮我拆解了原因，中间功能描述部分缺对比句，只是在描述功能，没有对比，所以读起来平。它给了一个很具体的句式，用「以前XXX，现在XXX」或「不用XXX，直接XXX」，在描述功能的时候同时说出它解决的问题。这次测试之后，我把这个对比句的要求加进了改写规则里。

第三轮，连句问题。有一句话是「一键下载无水印原画质不用安装任何东西，网页打开就能用」，两句话粘在一起，中间没有断点，读起来绕。改成「一键下载无水印原画质。不用安装任何东西，网页打开就能用」，立刻顺了。同一轮还发现了另一个问题，「以前需要费时费力的操作」，操作什么？读者会懵，加上宾语「下载素材」之后变成「以前下载素材费时费力」，完整了，也更清楚。

三轮测试下来，SKILL.md里的改写要求从最开始的三四条，扩展到了七条。每一条都不是凭空想出来的，都是测试过程中真实发现的问题。这就是为什么我说，Skill是用出来的，不是写出来的。

加一个自检机制，让Claude先审自己

迭代了几轮之后，我想到了另一个问题，每次输出有问题，都需要我去发现、去反馈、去更新。如果能让Claude在输出之前自己检查一遍，是不是可以减少一部分明显的低级错误？

这就是自检机制的来源。

在SKILL.md里加一个模块，列出所有评估标准，要求Claude在输出之前逐条对照，不达标就重写。我加了这样的要求，输出前必须逐条检查，朗朗上口有网感、与输入内容强相关、钩子承诺和内容实际价值匹配没有夸大、句与句之间有明确断点、每句话逻辑完整不缺主语宾语，全部通过才能输出。

加了自检机制之后，那些第三轮测试才发现的连句问题、缺宾语问题，开始在输出里消失了。有明确判断标准的问题，Claude自己就能发现和修正，不再需要每次都等我发现了再反馈。

但自检机制不是万能的，坦率的讲。它能解决的是有明确标准的问题，比如有没有连句、有没有缺宾语。那些更主观的问题，比如「网感够不够」、「节奏是否自然」，还是需要你自己去感受和判断。自检机制是辅助工具，不是替代你判断的东西。

会创建，不等于真正用好了

学完这一天，我问了自己一个问题，会创建Skill，算不算真正懂Skill？

想了一下，觉得不算。

会创建是基础，但真正用好Skill，还差很多东西。差在能不能把任何重复性工作都抽象成Skill，只要发现自己在重复给Claude解释同样的东西，马上就能把这件事抽象成一个Skill，这种敏感度需要时间培养。也差在能不能判断别人的Skill好不好，学完之后再去看别人写的SKILL.md，会下意识检查，description触发条件是不是够清晰，评估标准是不是即时可判断的，有没有自检机制。这种判断能力，是创建过程中自然获得的副产品。

我现在有两个Skill，能感受到的变化还比较有限，我自己也在摸索中。但能想象，当Skill积累到十个、二十个，覆盖了工作中大部分重复性场景之后，和Claude交互的方式会完全不一样，不再每次解释背景，不再每次纠正输出格式，直接说任务，Claude自动匹配对应的Skill去执行。

那个阶段，才算是真正用好了Skill。

找到你的第一个场景，然后动手

写到最后，说一件事。

Skill这个东西，不适合「研究明白了再动手」。真正让你理解它的，不是读文章，不是看教程，是你自己动手创建第一个，然后去测试，去发现问题，去迭代。

你现在就可以想一个问题，我在什么场景下，会重复给Claude解释同样的背景？

那个场景，就是你第一个Skill的起点。可能是每次让Claude帮你写邮件，都要说一遍你的邮件风格。可能是每次让Claude帮你分析数据，都要解释一遍你的分析框架。可能是每次让Claude帮你改文案，都要说一遍你的受众和调性。

找到那个场景，回答四个问题，做什么、何时触发、输出格式、好坏标准。然后打开Claude，把这四个答案告诉它，让它帮你整理成SKILL.md，上传，测试，迭代。

第一次可能不完美，第二次会好一点，第三次再好一点。

比你想象的简单很多，而且做出来之后那种感觉，我跟你说，真的很爽。