^__^ • 4 / 16
最近也不知道为啥，看到大家对skill的热情高涨到了一种有点离谱的程度。感觉万物都可以蒸馏，万物都可以封装成skill。我看了好几个朋友的skill库，有的装了六七十个，最离谱的甚至都破百了。昨天正好发了Harness的文章后，提到了我觉得skill就是分类学这个事，那一段出乎意料的被很多朋友转发。所以我就再展开说一下。一个好的skill，我觉得他的核心就两个词：分类和触发。一个多月前Claude还更新过一次他们的Skills生成器，我当时还专门写过一篇，新版本最重要的动作，就是怎么用反馈去不断优化一个skill的触发条件。 skill怎么触发、能不能正确触发、触发以后能干什么，才是最核心的事。之前有一篇论文发过实验数据，就是当Skills数量在20个以下时，准确率保持在90%以上，几乎不会错。超过30个准确率就不行了。到了200个的时候，准确率就剩20%了，而且速度极慢，Token消耗还爆炸。跟我自己体感差不多，我自己的的Skills常年保持在30个以下。我举个自己的例子，我之前想把NanoBanana的API封装成能被Agnet调用的skill，因为我平时有很多生图的需求，比如公众号封面图、小红书封面图、PPT配图等等。那这些应该每一个需求单独做一个skill，还是应该合成一个skill呢？我的做法就是只有一个图片生成的Skill，这个skill内部写了我的几个主流场景，在Agent触发这个skill后，根据我的上下文进行二次分析，再调用内部具体的分支画图场景，同时也能用这个skill，覆盖我其他的通用生图需求。这其实就是分类学的核心理念。从来不是只分的越细越好，是找到最合适的颗粒度。界、门、纲、目、科、属、种，生物学就是如此，一层一层穿透下去。你要是把前面全抹了，只给你留个种，你可以想象一下这个世界有多灾难。封面图和PPT配图之间的差异，不值得在最顶层各自占一个独立的skill，它们只是图片生成这个类别内部的变异。但图片生成和服务器管理之间的差异，那是真的大到需要各自占一个独立的skill。我自己判断一个skill值不值得存在，标准就三条： 1. 它对应的场景有没有明确的边界。 2. 它对应的场景是不是会高频复现。 3. 它能不能归属进已有的skill里。以及，奥卡姆剃刀原则，如无必要，勿增实体。翻译过来就是，你用不到的skill你就别装。但最重要的，还是需要你设计自己的分类系统，哪些是CLAUDE.md能处理的，哪些是skill该处理的。分类学如此。你的skill，也应如此。