我开发了一个能够「吃掉」其他Skill来自动升级的开源工具

当前Skill生态正在经历爆发式增长。以skills.sh为例，累计安装量已超过9万次，Vercel官方的find-skills接近80万安装量。微软、Supabase、Expo、shadcn等主流平台纷纷推出自己的Skill体系。Skill已经从极客玩具转变为AI开发者的标准装备。然而，一个根本性问题始终困扰着这个生态：大多数Skill在发布v1.0版本后就停止了进化。用户发现某个场景处理不了时，要么勉强使用，要么重新寻找其他Skill。

为什么Skill合并不是简单的复制粘贴

传统的Skill开发思路是「从零到完美」——花费大量时间一次性写完所有场景和边界条件，然后发布。但这种思路存在致命缺陷：开发者无法预见所有实际使用场景。我自己的research skill就是一个典型案例：v1版本覆盖了Reddit、X、YouTube等十几个平台，看似完整，但实际使用一个月后发现小红书抓取是残废的——轮播图只能拿第一页，评论数据丢了一半。当我想整合别人做得更好的小红书 summarizer skill时，发现技术栈完全不同（对方用playwright，我的底层是Chrome CDP），手动合并花了整整大半天。这个过程让我意识到：Skill的真正成长路径不是「一次写完」，而是「持续吞噬外部优势并进化」。

饕餮.skill的三大设计铁律

很多人以为合并两个Skill就是把好的部分搬过去。实际操作中，80%的时间花在三个坑上。第一是技术栈适配：两个Skill大概率使用不同的底层实现，一个playwright一个CDP，一个Python一个TypeScript，不能直接搬代码，需要语义级别的翻译。第二是上下文依赖：某个策略之所以有效，往往依赖它上下文中的其他指令，单独拎出来可能完全失效甚至冲突。第三也是最关键的：你要搬的不是代码，而是模式——参考Skill背后的设计思路、设计假设、策略意图。

在开发饕餮.skill之前，我系统研究了三个做「AI自我进化」的项目：Voyager（斯坦福+英伟达2023）、TextGrad（2024）、DSPy（斯坦福2023）。从它们的成功和失败中，提炼出三条核心设计原则。铁律一是「合并只发生在策略层，不碰实现层」——吞入两个Skill后，先提取参考Skill的策略意图，然后用自己的技术栈重新实现，代码层面的东西不搬，只搬思路。铁律二是「一次只改一个维度」——TextGrad和DSPy都证明，一次改5个地方结果变差时，你根本不知道哪个改动搞砸了。饕餮.skill采用渐进式注入，每次只注入一个优势模式，并输出diff报告供用户审批。铁律三是「每次注入前必须备份」——机器学习领域有「灾难性遗忘」的概念，Skill也是如此，新的指令可能覆盖旧的导致功能失效。

饕餮.skill的运行分为四个阶段。第一阶段是「双向吞入」：同时读取目标Skill和参考Skill的完整结构，包括SKILL.md、scripts目录、references目录等所有文件。第二阶段是「能力对齐」：把两个Skill的能力拆成模块，输出一张能力对比表——哪些能力我有它没有，哪些它有我没有，哪些我们都有但它做得更好。第三阶段是「优势模式提取」：这是最关键的一步，对于参考Skill做得更好的每个模块，提取的不是代码，而是它的策略意图、为什么有效、设计假设是什么。第四阶段是「渐进注入」：把提取出的模式按优先级排序，逐个注入到目标Skill，每注入一个生成diff报告，包含注入位置、改动内容、设计理由和潜在风险。

实战效果如何？以我的bggg-creator-research skill吃掉小红书summarizer skill为例。吃之前：还抓不到小红书。吃之后：实现了完整的小红书深度抓取功能——轮播图穿透指令、CDP提取代码模板、评论过滤规则、多模态分析流程，而原有的Reddit、X、YouTube等模块完全不受影响。饕餮.skill分析后发现参考Skill有4个核心优势：图文轮播穿透、多模态内容提取、主题式综合、评论垃圾过滤。关键的是技术栈适配——参考Skill依赖playwright-cli，但我的research skill底层是Chrome CDP，饕餮.skill用现有CDP能力重新实现了这些策略，零新增依赖。整个过程只用了10分钟，而上次手动做花了大半天。

如有侵权，请联系删除。