我让一个 Skill 吃掉了另一个 Skill，几分钟后它多了一个新能力。

Skill 环境的爆炸与痛点

skills.sh 已经累计安装超过万次光 Vercel 官方的 find‑skills 就快到万次。说起来，微软、Supabase、Expo、shadcn 等都在发布自己的 Skill。社区氛围像是 AI 开发者的“标准装备”。

但大多数 Skill 发布后就停留在 v1：一波 star 后读完 README，随后就不再更新。你会遇到场景无法处理、想改却懒得动、看到别人的实现更好却不知道如何接手。Skill 环境真正的瓶颈不是“怎么写”，而是“怎么让一个 Skill 持续进化”。

从零到完美的思路致命缺陷

很多人把写 Skill 当作一次性任务：花三天写完 SKILL.md。把所有场景和边界条件都考虑进去，接下来发布。这样做有两个问题：

• 无法预见所有真实使用场景；其实，
• 上线后才发现某些功能残废。需要手动重构，

例如我的 research skill 最初覆盖 Reddit、X、YouTube 等网站。但上线一个月后才发现抓取失败——轮播图只能拿第一页，评论数据丢了一半。

合并 Skill 的三大坑

技术栈适配

不同 Skill 可能用 Playwright 与 CDP、Python 与 TypeScript 等技术栈。直接搬代码会导致语义冲突，你必须先理解对方实现。再用自己的技术栈重现一样效果。

上下文依赖

A skill 内部策略往往依赖其他指令。不过，如果把单独拎出来塞进去，可能失效或冲突。怎么说呢，例如我把「每次抓取后等待秒」的规则搬进来导致并发模式下变得极慢。其实，

只搬模式而非代码

true value 是设计思路。而不是代码本身，你需要提炼参考 Skill 的设计假设，接下来用目标 Skill 的技术栈实现这些策略。老实说，

"饕餮.skill" 的主要哲学

从铁律一来看。合并只发生在策略层，不碰实现层

Shooter 在早期把所有学到的技能塞进库里结果相互干扰。饕餮.skill 先提取参考 Skill 的策略意图，再用目标 Skill 的技术栈重新实现。

从铁律二来看，一次只改一个维度

一次性注入多个模式容易产生冲突。饕餮.skill 按优先级逐个注入。 每一步生成 diff 报告，你可以选择接受或回滚。

至于铁律三，每次注入前必须备份

为避免灾难性遗忘。每次注入前自动创建 .bak 备份，一行命令即可恢复原版。

"饕餮.skill" 内部运作流程

至于第一步先。双向吞入

读取目标和参考 Skill 的完整结构——SKILL.md、scripts、references 等目录，全盘扫描。

说到接下来。 能力对齐

将两个 Skill 的功能拆成模块，一一对应；标记哪些是独有的、哪些是更优秀的。

：优势模式提取

从第四步来看。渐进注入 & diff 审核

PATTERN 按优先级排序，一步一步注入；每一步生成 diff 报告。包括位置、改动内容与潜在风险，让你可审批或回滚。

"研究" 与 "创作" 两大案例展示效果

• bggg‑creator‑research skill → summarizer skill：
• - 新增轮播图穿透指令、CDP 提取模板、多模态分析流程等；- 原有 Reddit/X/YouTube 模块保持不变；- 整体升级仅耗时数分钟，上手手工整合需半天。

• writer skill → 垂直业务写作风格程序：
• - 补齐段落节奏控制；不过，- 保留原有 CTA 模板不被覆盖。

• illustrator skill → baoyu‑cover‑image 五维度 prompt：
• - 补充配色方案与构图规则；- 仍保持原始脚本兼容性。说起来，

"能做不到" 的局限性说明

•  Python 与 TypeScript 无法自动 脚本。只能修改 SKILL.md 指令；需要你自行调整 scripts 目录代码。
•  参考 Skill 没有清晰结构或缺乏注释时AI 分析质量下降；垃圾进垃圾出，
•  当两者底层设计完全相反时只能局部调整，无法提供整体架构决策建议。

开源地址 & 安装方式

• - GitHub 地址：
• - 安装方式：将饕餮.skill 放到 .claude/skills/ 或 .agents/skills/ 目录下就可以使用。
• 可以参考的优势模式，你可决定是否注入。其实，

从「写 Skill」到「养 Skill」