擅长Skill编排，compound有持续学习机制，装在一起之后触发条件开始互相打架，两个Skill同时match同一个pattern，系统就不知道该听谁的了。

励志帝

【Harness Engineering的混乱期：装了几十个Skill还是干不过一个好的CLAUDE.md】

快速阅读： Claude Code的Skill生态正在经历类似去年MCP爆火时的混乱。核心问题不是框架太多，而是缺乏自己的过滤逻辑。以一个基础框架为底，把其他框架的亮点合并进来，比无限安装要稳得多。

---

superpowers、compound-engineering、gstack，每一个看起来都有道理，装进去之后Skill数量蹭蹭涨到几十个，然后你发现AI开始犯迷糊，触发逻辑越来越不稳定。这是很多人最近都在经历的事。

问题的结构其实很像操作系统里的驱动冲突。每个框架都是对Harness Engineering最佳实践的独立探索，各有亮点，但能力覆盖有交集。superpowers擅长Skill编排，compound有持续学习机制，装在一起之后触发条件开始互相打架，两个Skill同时match同一个pattern，系统就不知道该听谁的了。

有网友分析自己本地积累了两三百个Skill，让AI扫描之后发现大量同质化内容，CEO advisor、CTO advisor、PM skill挤在一起，本质上是同一件事写了三遍。另一位开发者做了个skill-optimizer，挖session数据分析每个Skill的实际触发率，最后发现一半从没被触发过。

目前多数Skill管理工具的思路是"屏蔽复杂度"，比如提供启用/停用开关。这条路走不通，因为复杂度还在那里，只是被藏起来了，一旦上下文稍微复杂，系统就抖起来。

有观点认为，解法在于先写好自己的CLAUDE.md作为过滤器，有了明确的运行规则，装完一个Skill就能判断该不该留，而不是在装了删、删了装的循环里耗着。还有观点指出，当前混乱的深层原因是Skill本身缺乏标准定义、分类和参数体系，这是过渡期必然要经历的阶段，就像导航出现之前每个人都有自己的一套路线记忆法。

实践层面，一个相对稳定的做法是：以一个框架为底，把其他框架的亮点拆出来合并进去，用Skill管理Skill本身的合并和测试。这样至少能控制膨胀的速度。

每个Skill只管一个窄领域，不要重叠，让基础框架负责路由分发，而不是把决策权全部抛给AI自己去猜。这不是最优解，但它至少是可维护的。

还有多少Skill是你装了但从来没被触发过的？大概值得花一个下午去挖一下这个数字。

ref: x.com/kasong2048/status/2038599301618889042

##