Claude Skills可能走对路了

前天Anthropic发布了Claude Skills，这是一种让AI获取新能力的全新机制。很不错的设计，包含了软件两个最主要的组成部分：程序和资源，还没有什么别的复杂性。架构看起来很合理，虽然要实际用用才能感觉出来是不是真的好用，但初步从架构设计看，感觉Claude Skills在方向上可能走对路了，整个AI行业可能走对路了。

简洁的力量：程序+资源就够了

Skills的核心概念非常简单：一个Skill就是一个文件夹，包含指令、脚本与资源。具体来说，每个Skill包含三样东西：指令(Instructions)告诉Claude该做什么、脚本(Scripts)执行具体任务、资源(Resources)提供模板和辅助内容。因为自然语言也是代码，指令和脚本其实是分不清的，都属于程序。

这种设计的合理之处在于它抓住了软件的本质。软件不就是程序和资源吗？程序负责逻辑，资源负责数据和素材。Skills把这两者有机结合，又没有引入什么别的复杂性。

更重要的是Skills的按需加载机制。Claude只会在Skill与当前任务相关时才会调用，并且采用渐进式披露：先加载元数据(约100词)，再加载https://t.co/8CjlRMvOgF主体(也比较小)，最后才是具体的资源文件。这种设计既高效又节省token，体现了对成本和性能的深度考量。

AI能力扩展的演进：从Plugin到Skills

要理解Skills的价值，需要回顾OpenAI和Anthropic在AI能力扩展上的探索历程。

OpenAI的Plugin是第一次尝试，但看起来是不成功的尝试。Plugin主要依赖API调用，虽然概念不错，但实际体验并不理想，很快就被弱化了。后来推出的GPTs允许用户定制AI的知识和行为，但本质上仍然是基于提示词工程的定制，缺乏真正的能力扩展。

最新的Apps则希望把第三方的界面直接嵌进来，感觉步子迈得有点大。让AI直接操作第三方应用的界面，这种computer use式的方案虽然听起来很酷，但实际可控性和可靠性都面临巨大挑战，而且第三方应用也不愿意被嵌入的这么深。百度很多年前想做框计算，目的是类似的，并没有成功。

Anthropic自己推出的MCP(Model Context Protocol)走的是另一条路，主要通过API调用已有服务的能力，和Skills的定位不同。MCP更多是为了连接外部系统和服务，而Skills则是为Claude赋予新的原生能力。

相比之下，Skills找到了一个更优雅的平衡点。它用Markdown这种人人都能理解的格式来描述能力，可以包含详细的使用说明和示例。开发者创建一个Skill，就像是"给Claude写一份入职手册"。而且Skills可以打包分享，形成开放的生态系统，这大大降低了开发门槛。

Anthropic一口气开源了20多个Skills，涵盖创意设计、开发技术、企业应用等各个领域。这种开放的姿态，很可能会推动一个繁荣的Skills生态的形成。资源的例子很好理解：Canvas-fonts包含很多字体文件，这样Claude在生成设计时就能直接调用。

仍需改进的地方

当然，任何新技术都不可能完美。Skills目前也存在一些明显的不足。

首先是技术门槛问题。虽然Skills用Markdown编写降低了理解难度，但官方的一些Skills仍然依赖于apt-get这样不够亲民的指令，至少对大多数Windows的用户这一步就直接挂了。普通用户希望的是一个软件包一装就灵，而不是还要装一大堆依赖。如何让Skills的创建和使用更加大众化，是Anthropic需要继续优化的方向。

其次，Skills看起来不容易拥有自己的存储和数据库。这在处理需要持久化状态的任务时可能会成为限制。比如，如果我想创建一个帮我跟踪工作进展的Skill，它需要记住之前的任务状态和历史数据，但现在的Skills架构似乎不太支持这种场景。不过或许可以在Skill里调用sqlite这样的数据库命令来实现这一点？

结语

Claude Skills的发布，为AI能力扩展提供了一个简洁而优雅的解决方案。相比OpenAI的Plugin、GPTs和Apps等尝试，以及Anthropic自己的MCP，Skills在易用性、可控性和生态开放性之间找到了更好的平衡。它避免了过度工程化的陷阱，用最小的复杂度实现了核心价值。

在AI原生应用的探索中，我们都在寻找那个平衡点：既要充分发挥AI的能力，又要保持用户体验的简洁流畅；既要提供强大的功能，又要避免不必要的复杂性。Skills在这个平衡上做出了有价值的尝试，值得我们这些AI产品从业者认真研究和借鉴。