少即是多：与其囤一堆 skill，不如吃透一组
最近半年一直很重看 EveryInc 出品的 compound-engineering-plugin，它也一口气装了 29 个 skill（命令都以 /ce- 开头），我持续跟进它的更新；同时，和我工作流不搭的 skill 我都主动卸了——superpowers 这种同性质的工程插件，还有 supabase、vercel、next.js、refine 这些纯语言/框架的 skill，要么和这一组重叠，要么根本不在我的流里。因为我越用越清楚一件事：skill 的本质，不是装得多，而是吃得透、懂原理。
（我数过，那 29 个里，真正每次都走的只有 6 个核心 skill，剩下二十几个是按需挂的"侧门"。）
先说为什么装一堆反而用不好，再说什么才叫"吃透一组"，以及进阶的用法。
一、装得多，真的用得好吗？
第一，能被真正激活的其实有限。 像 Codex 这类产品，会对 skill 的 description 做缩减。你装得越多，某个 skill 能被准确识别、在恰当时机被触发的概率反而越低。装了一墙按钮，真正能被"叫醒"的也就那么几个——数量上去了，命中率反而下来了。（这个就是skill的激活率问题）。
第二，平白浪费上下文。 skill 包通常一组一组地来，动辄几十个。可你日常真正用到的就几个。剩下的那些，你既不手动召唤，平时也不会被自动触发，只是安静地占着上下文预算。装了等于没装，还白白搭进去成本。哪怕是渐进式披露的skill，为了提升被动激活率，许多skill的激活词也写得非常泛滥。
第三，最麻烦的是行为说不清。 同一份结果，常常搞不清到底是哪一个 skill 在背后起作用。尤其是两个几乎一样的任务，自动串起来的 skill 却不一样：同一个意图，走了不同路径，产出对不上。这种不可解释，比"不会用"更让人困惑。比如只做代码评审的 /ce-code-review，它自己从不改代码，得靠调用方去落实结论；而更重的 /ce-dogfood 干脆被设成禁止自动调用，因为副作用太重。表面上看像是同一个 AI 在干活，背后触发的链路却各不相同——这才是最磨人的地方。
二、什么才叫"吃透一组"？
以我常用的 compound-engineering-plugin 为例。它那 29 个 skill，分核心 skill 和附带 skill。
核心 skill 是整个开发流程里的一组：/ce-brainstorm（想清楚）→ /ce-plan（计划）→ /ce-work（干）→ /ce-simplify-code（简化）→ /ce-code-review（评审）→ /ce-compound（沉淀）。它们之间不是并列摆着，而是互相调用。比如 /lfg 这条全自动流水线，能把"计划 → 写代码 → 简化 → 评审 → 测试 → 开 PR"一气串起来；而负责"沉淀"的 /ce-compound，会把每轮学到的东西写回方案库，下一轮规划时再被当基地读回去。官方对它的评价很直白：“那根回流的箭头，才是全部的意义。”
所以关键不是"会不会敲单个命令"，而是：知道这一组从哪开始、谁调谁、边界在哪里。这要求不只读文档，还要理解它们之间背后的关系和区别。
真懂原理，才分得清微妙的差别。 我这组里有两个测试相关的 skill：/ce-test-browser 做差异化测试，只测改动触及的页面，测完报结果，不修、也不提交；/ce-dogfood 做的更重，是那种会自己跑完的 QA。它也只盯 diff 触及的流程，但会在末尾跑一遍项目既有的测试套件当"就绪门"，还会自己修小 bug、补回归测试、留下可追溯的文档报告，而且必须手动调用。两者差别微妙，要分清"什么时候用哪个"，靠的不是记住命令名，而是反复读它们的 skill 内容，把根本原理和区别吃透——光看名字，分不出这俩。
三、吃透之后，你能拿它做什么？
懂了原理，才能把它改造成自己的。 掌握了底层结构，还能再往前走一步：把两三个 skill 组合起来用，再用提示词微调它中间的行为。还是拿 /lfg 说，它默认从需求一路跑到开 PR、盯 CI。但如果你这轮只想在本地收尾，懂了它是一条"计划 → 写代码 → 简化 → 评审 → 测试 → 提交 → 开 PR"的流水线，就可以直接告诉它：别开 PR，本地提交就行。它就会停在你想要的地方。这种"组合 + 用提示词改行为"的玩法，是吃透原理之后才有的进阶自由度。
我的结论：少即是多
所以问题从来不是"你装了多少"，而是"你真正吃透了几条"。
装一堆，你拥有的是一份多半用不上的清单，外加一堆说不清来源的行为；吃透一组常用的、懂其原理的，你才真正拥有了一套能跑起来、还能自我复利的系统。少装，常用，吃透，再及时跟进它的最新更新，掌握背后的方法论，最终打造自己的个性化的skill才是适合AI builder的路。
