Skill怎么写、怎么用、怎么迭代？把我踩过的坑和方法全交代了！

一、全文速览图

之前写过一篇关于怎么把公司里的设计规范变成skill？的教程，没想到热度一直居高不下，直到现在还有不少人找我发当时文章里我写的skill文件模版。

也有人问我，除了这个，还有哪些skill是我经常用的？

也有人想让我再详细讲讲，skill到底要怎么写，写完怎么安装，为什么有时候AI不听话。

说实话，这些问题我在群里一个一个回复过好多遍了。干脆今天再花点时间，把skill这个东西从头到尾聊透，从我自己是怎么接触skill的，到怎么写出第一个，再到踩了哪些坑，一次性全交代清楚。希望是等下次群友们再有疑问，来翻翻我这篇文章直接就能解决。

我也不知道对所有人都管不管用，但至少把我目前摸索出来的东西毫无保留地分享出来。你看完之后能自己写出一个适合你业务的skill，那就是最好的结果了。

二、skill到底是个什么东西？

别被这个名字吓住了。skill其实就是一个文件夹，里面装着一个叫 SKILL.md 的文本文件，有时候还会带一些参考资料、脚本之类的辅助文件。例如github上的这个

它的核心就是那个 SKILL.md。你可以把它理解成一份写给AI的工作手册，告诉AI，你帮我做这个事情的时候，要遵守哪些规矩，什么能做什么不能做。

一个特别形象的比喻是，skill就像你给新来的实习生准备的入职须知。你跟他说，帮我整理文件的时候不要加小标题，不要用破折号，语气自然一点，别搞得跟写论文一样。skill干的就是这个事。区别在于，你不用每次都重复说，AI自己就知道了。

从Anthropic在2025年底把skill作为开放标准发布以来，这个格式已经被Claude Code、、Cursor、OpenClaw等等主流工具支持了。所以你写的skill，基本上可以跨工具用，不局限于某一个平台。但同样的skill，在使用效果上并不完全相同，后面会说。

skill的类型大概可以分成两种。一种是能力增强型，给AI加上它本来没有的能力，比如让它能自动化浏览器操作、生成PPT、抓取网页数据，可以理解是给软件产品打补丁。另一种是偏好编码型，AI本来就会做这件事，但你希望它按你的方式来做，比如你的写作风格、设计规范、代码习惯。我自己用得最多的是第二种，因为AI的能力已经够用了，问题在于它不知道我的标准是什么。

三、拿我自己写的skill做个演示

说到这里可能还是有点抽象。我直接拿我自己写的一个真实skill来给你看，你就能懂了。

我一直有一个习惯，就是在平时走路、坐地铁之类的零碎时间，脑子里冒出啥想法就赶紧码字记录下来，老读者应该都知道，我有经常跟你们说。现在因为语音输入法很成熟，比如豆包输入法识别非常准，那我会习惯用语音快速把脑子里的想法说出来，记录到flomo上。但我还需要用手逐字逐句的去调整，然后再发到我的知识星球打卡，也挺麻烦的。

以前为了记录更快我还专门学了双拼输入法，但现在有了语音+AI+skill这套组合，我的记录变得更轻量了。

但之前我把我的零碎想法发给AI，让它帮我重新优化，效果总是不大好。一开始的时候，我必须用很多提示词约束它，不然每次让AI帮我整理语音转文字内容的时候，它总是会加一堆破折号，动不动就来个冒号分点列举，整出来的东西一股子AI味，跟我想说的内容差距甚远。我每次都得跟它说，别用破折号，别用冒号，别加小标题，就挺烦的。

后来我就想，行了，我把这些规则写成一个文件吧，专门放到记事本里存下来，每次复制用一下。后面发现claude可以把这个提示词规则直接写进skill里，连复制这一步都帮我省了。

这就是我的语音笔记整理skill。

我也把它放到了github上，你可以下载来用。

地址是：

拿来记录零碎想法，用语音快速写日记，都是非常方便的。记得星标下，我有空会继续优化更新。

我把完整的文件内容贴在这里，你可以直接看一下它长什么样。

你看，skill内容也不长，整个SKILL.md文件就分成两个部分。

上面那一块灰色包起来的区域叫frontmatter，就是这个skill的基本信息。name是名字，description是功能描述和触发条件。这块你可以理解为一张名片，告诉AI这个skill是干什么的，什么时候应该用它。description特别重要，因为AI在决定要不要调用一个skill的时候，最先读到的就是这个字段，你写得越清楚，它触发得越准。其他的就是一些补充信息，可写可不写。

下面那一大段就是正文了，具体的规则和要求。我来拆解一下我到底写了些什么。

第一块是核心原则。忠于原意、像用户自己写的、逻辑补全、适度增删。这四条就是在画底线，告诉AI什么能改什么不能改。这个很关键，因为AI特别爱自作主张加东西进去，你不给它画线，它就按自己的理解来。

第二块是格式和风格要求。不用破折号，少用冒号，不用模板化的连接词，不加小标题。这些每一条都是我在反复使用中踩出来的坑。每次AI犯一个毛病，我就往这个列表里加一条。

第三块是处理流程。通读全文、梳理逻辑、重新表达、检查偏离。告诉AI先干什么后干什么。

第四块是输出要求。最关键的一条，直接输出结果，不要说任何废话。AI特别喜欢在前面加一句以下是整理后的内容，这句话完全多余。

你可能已经发现了，写skill其实就是在回答一个问题，你希望AI做这件事的时候遵守哪些规矩？把你脑子里的规矩一条一条写出来，就是一个skill了。

顺着这个再多说几句。写得好的skill，除了SKILL.md之外，往往还会带一些辅助文件。比如一个references文件夹放参考资料，一个examples文件夹放输入输出的示例，甚至还可以带scripts文件夹放脚本。你在GitHub上看到那些star很高的skill仓库，很多都是这种目录结构。不过对于大多数人来说，一个写得清楚的SKILL.md就完全够用了，别被复杂的目录结构吓到。

四、用了skill和没用，区别有多大？

好，原理讲完了，但光说原理可能没什么感觉。

我直接拿一段真实的语音转文字内容，分别让AI在有skill和没有skill的情况下整理一遍，你自己看。

我用一个我日常语音记录中的一小段来演示，原始语音转文字内容是这样的：

就是那个，我觉得管理这个事情吧，其实最重要的就是你得，你得找到那个最大公约数，就是你手上同时有好几个项目的时候，你不能每个都想得很细，你要找到它们之间那个共通的东西，然后抓住那个就行了，对，就是这样，嗯，就是化繁为简嘛

没有用skill，Claude默认输出是这样的，

用了我的语音整理skill之后，输出变成了这样，

看到区别了吗？

没用skill的那个版本，尽管claude已经改的还不错了，但对比用了skill的还是擅自删改了我说的内容，而且还会把改动思路加上，这样我在复制结果的时候依然需要手动删掉多余的内容。

这还只是拿了一个最简单的例子来说明，可能你还不一定能感受到它的神奇。如果是说的内容比较多的情况，用了skill后，它还会自动帮我整理逻辑，自动分好段落，表达的更通顺有逻辑，对我的日常记录真的帮助非常大了，尤其是在手机上操作，整个过程有多丝滑，你只要用了就能懂。

五、什么时候该用skill？

我的判断标准很简单，如果你发现同样的规则跟AI说了3次以上，那就该写一个skill了。3次是一个临界点。说一两次还能忍，3次就说明这个需求是反复出现的，值得花十分钟把它固定下来。

固定的写作风格、固定的设计规范、固定的代码习惯、反复出现的数据处理流程，这些都是适合做skill的场景。

不擅长的地方也要坦率的讲。skill解决不了创意问题，它管的是怎么说，管不了说什么。skill也不适合一次性任务，如果一个需求只做一次，直接在对话里说清楚就行，没必要专门写个skill。而且有些特别复杂或者模糊的规则，AI理解起来不一定精准，这时候你还是得在对话中额外补充。

至于怎么安装，其实比你想象的简单得多。最省心的方法就是直接把skill文件发给AI，跟它说帮我安装一下这个skill。

它就能自动给你装好了。

六、换个模型，为什么效果差那么多？

这里说真的我得多聊几句，因为我自己觉得挺痛苦的一个事，那就是同一个skill，搭配不同的大模型，输出效果真的差太多了。

我在Claude里用我的语音整理skill，它基本上能严格遵守每一条规则，不用冒号就真的不用冒号，不加小标题就真的不加。但同样的skill换一个模型跑，效果差距大到我一度以为skill没生效。

比如经常担心claude好用是好用，万一哪天把我的号给封了咋办？所以我很想找到一个能平替的办法，所以我经常性的把claude中我写的skill备份出来，然后在比如codex 中用同样的skill，但效果差的太多了。

为什么会这样？

我自己的理解是，不同的模型对指令的遵循能力差距很大。Claude的指令遵循能力是我用过的里面最强的，skill的规则会被当作高优先级的约束来执行。你可以理解为，Claude在处理你的请求之前，会先把skill的规则过一遍，然后再开始干活。再加上它的脑子本来就好使，所以结果出奇的好。

其他一些模型或者工具，设计重心不太一样。有些更偏向任务完成，对于风格层面的细节约束就没那么敏感。就像一个程序员，你跟他说功能逻辑要怎样他听得很认真，但你跟他说文字排版不要用冒号，他的注意力不一定分得过来。

怎么解决？几个我自己摸出来的办法

把最重要的规则放在SKILL.md的最前面。AI对靠前的内容注意力更集中。规则写得越具体越好，不要写语气自然一点这种模糊的要求，而是写不使用破折号，不使用冒号，这种比较具体的要求。还有就是，对于风格要求很严格的任务，优先用Claude来跑，别省这个钱。工具的选择本身就是skill能力发挥的一部分。

七、怎么迭代skill？

写出一个skill只是开始，让它变得好用需要不断打磨。

我自己的做法是这样的。每次Claude帮我整理完一段语音内容之后，我会自己看情况改一遍。改完之后，我把Claude的版本和我改过的版本一起发给它，跟它说，你看看我改了哪些地方，这些修改背后的规律是什么，帮我总结一下。

然后再让它把这些规律写进skill文件里，作为新增的规则。

这个过程就像训练一个人。你不是一上来就能把所有规矩都想清楚的，很多规矩是在实际干活的过程中才发现的。skill的迭代就是把这些发现不断沉淀下来。我这个语音整理skill从最初的版本到现在已经改过很多次了，每次改动都不大，可能就加一条规则或者调一下措辞，但积累下来效果提升非常明显。

分享一个可以直接照着做的迭代流程：

1. 用skill让AI处理一段内容
2. 自己对输出进行修改
3. 把两个版本一起发给AI让它分析差异
4. 把分析出来的规律写进skill
5. 再跑一次看效果

重复这个循环就行。

这样操作特别有效。因为你的每一次修改都代表了你的真实偏好，让AI从你的实际行为中学习，比你凭空想规则要靠谱得多。

八、几个容易踩的坑

顺便聊几个你可能不知道的事情。

frontmatter里的字段不只是摆设，就是skill里前面那个灰色声明区域。比如 allowed-tools 可以限制这个skill允许调用哪些工具，disable-model-invocation 设为true可以防止AI自动触发它，必须你手动调用才行。这些在一些需要严格控制的场景下很有用。

skill还可以互相配合。你可以有一个管写作风格的skill和一个管排版格式的skill，同时生效。但如果两个skill的规则打架，AI会不知道该听谁的，这是个坑。

还有一个特别重要的事，不要装太多skill。你想想看，每个skill都会占用AI的上下文窗口，装太多了留给实际对话的空间就变少了，AI的注意力也会被分散。skill之间可能有规则冲突，触发逻辑也会变复杂。而且skill的加载机制是这样的，AI一开始只读description来判断要不要用，但一旦触发，整个SKILL.md的内容就会被加载进来。所以skill太多的时候，很容易一下子把上下文塞满。

我的建议是装几个常用的就够了，我自己到现在也就几个在用的。

宁可一个skill做得很精，也不要搞一堆半成品。你真正在日常工作中反复用到的场景，才值得做成skill。跟收藏设计素材和教程一样，收藏了不等于有用，装了不等于会用。

九、从哪找到好的skill？

自己写当然是最好的，但看看别人写的也很有启发，至少能知道原来还可以这么用。

skillsmp（ ）是目前最大的skill聚合平台，从GitHub上索引了上百万个skill，按用途分了类，可以直接搜你需要的场景。

lobehub（ ）是LobeHub的skill市场，中文内容比较多，还有评分和安装量可以参考。

GitHub（ ）上直接搜skill关键词也能找到不少，好处是你可以看到别人的完整目录结构和迭代历史。

国内的话，modelscope（ ）也有skills专区，还有一些面向中文场景的专项skill。

我自己经常做的事情是，在这些平台上看到一个不错的skill，先不急着装。

我会先仔细读它到底能做什么，看看示例，然后点开它的SKILL.md仔细读一遍，看看别人的规则是怎么写的，目录结构是怎么组织的，有没有什么我没想到的角度。然后把有用的部分融入到我自己的skill里。反正我觉得，这种学习的价值比直接套用大得多。

十、写在最后

skill这个东西，说到底就是你和AI之间的一份工作约定。它不神奇，也不复杂，但它能帮你把那些重复的沟通成本降到接近0。

我一直觉得，AI时代最重要的能力之一，在于你能不能把自己的工作方式、审美偏好、质量标准这些隐性的东西，变成可执行、可复用、可传承的显性规则。用好某个工具只是表层，把自己的标准沉淀下来才是深层。

做设计的人应该特别能理解这件事。我们做组件库的时候不也是在干同样的事情吗？把散落在各个文件各个页面里的设计决策，收拢成一套可复用的系统。skill不过是把同样的思路用在了你和AI的协作上。

而且这个过程本身也很有意思。当你试着把脑子里那些模糊的偏好和标准写成具体的规则时，你会发现自己对很多事情的理解其实比想象中清晰得多。写skill的过程，也是一次审视自己工作习惯和思维方式的机会。

就像我从学双拼输入法到现在用语音+AI+skill，记录的形式一直在变，但背后那个不变的东西是，我想把脑子里好的想法留住。工具永远在迭代，但把好想法留下来这件事，什么时候开始都不晚，就像我一直坚持在星球里每天打卡记录一样。