Claude Code Skill管理：删掉80%后我保留了这8个

1. 从“装了一堆”到“删掉八成”：一个Skill囤积者的自白

三个月前，我的Claude Code里塞了四十多个Skill。每次看到社区里有人分享新的SKILL.md，我就忍不住clone下来，往~/.claude/skills/目录里一丢，心里想着“万一哪天用得上呢”。结果三个月后，我打开那个目录，发现真正每周都在用的，不超过八个。剩下的三十二个，要么是装完就没碰过，要么是跑了一次发现效果不如预期，要么是功能重叠得厉害——光“代码审查”这一个场景，我就装了五个不同的Skill。

这不是我一个人的问题。在Claude Code的社群里混久了，你会发现一个很普遍的现象：大家热衷于收集Skill，就像早年收集浏览器插件、VS Code扩展一样，装的时候很爽，用的时候很少。Skill本身是个好东西，它把提示词工程、工具调用、上下文管理这些零散的东西打包成一个可复用的模块，让Claude Code能针对特定场景表现出更专业的行为。但问题在于，Skill的边际价值递减得非常快。第一个代码审查Skill带来的提升是巨大的，第五个带来的增量可能只有5%，而它们占用的上下文窗口、增加的决策复杂度、以及维护成本，却是实打实的。

这篇文章不是要劝你别用Skill，而是要分享我删掉80%之后，留下的那20%长什么样，以及我是怎么判断一个Skill该留还是该删的。如果你也在Claude Code里装了一堆Skill但感觉越用越乱，或者你正准备开始配置自己的Skill体系，那接下来的内容应该能帮你少走一些弯路。我会从Skill的实际工作机制讲起，解释为什么“装得多”不等于“用得好”，然后给出我自己的筛选标准和保留清单，最后聊聊怎么用settings.json和npx skills把Skill管理这件事做得更省心。

2. Skill到底是怎么被Claude Code加载和调用的

2.1 SKILL.md的加载时机与上下文占用

很多人以为Skill是“按需加载”的——只有当你提到某个关键词时，Claude Code才会去读对应的SKILL.md。这个理解只对了一半。实际情况是，Claude Code在启动时会扫描skills目录，读取每个Skill的元数据（名称、描述、触发条件），把这些元数据注入到系统提示里。真正的SKILL.md正文，是在Skill被触发时才完整加载的。

这意味着什么呢？意味着你装的每一个Skill，即使从来没被触发过，它的元数据也在持续占用你的上下文窗口。一个Skill的元数据可能只有几十个token，但四十个Skill加起来，就是一两千个token的固定开销。这个开销在单次对话里看起来不大，但Claude Code的上下文窗口是有限的，尤其是在处理大型代码库或者长对话时，这些“僵尸Skill”的元数据会挤占本该留给实际任务的空间。

更麻烦的是触发条件的冲突。假设你装了两个Skill，一个叫code-review，描述是“对代码进行审查”，另一个叫security-audit，描述是“检查代码安全问题”。当你让Claude Code“审查一下这段代码”时，它该触发哪个？两个都触发？还是随机选一个？实际测试下来，Claude Code倾向于触发描述更具体、匹配度更高的那个，但如果你装了五个功能相近的Skill，触发行为就会变得不可预测。我遇到过最离谱的情况是，让Claude Code“帮我看看这个函数有没有问题”，它触发了一个叫python-style-checker的Skill，而那个Skill只检查PEP8格式，完全不看逻辑问题。

2.2 触发机制的模糊地带：为什么有些Skill从来不生效

Skill的触发依赖于Claude Code对用户意图和Skill描述的匹配。这里有个容易被忽略的细节：Skill的描述写得越宽泛，越容易被误触发；写得越窄，越容易被漏触发。我装过一个叫refactor-helper的Skill，描述是“帮助重构代码”。结果每次我提到“重构”这个词，哪怕只是说“这个模块以后可能要重构”，它都会跳出来给一堆建议。后来我把它删了，换成了一个描述更具体的extract-function，只在明确要求“把这个代码块抽成函数”时才触发，准确率高了很多。

另一个常见问题是Skill之间的依赖关系。有些Skill假设你已经装了另一个Skill，或者假设你的项目里有特定的配置文件。比如我装过一个test-generator，它默认你的项目用pytest，并且有conftest.py。但我的项目用的是unittest，结果它生成的测试代码根本跑不起来。这种隐式依赖在SKILL.md里往往不会写清楚，只有实际用了才会发现。

2.3 一个Skill的完整生命周期：从触发到执行

理解Skill的生命周期，有助于你判断哪些环节可能出问题。一个Skill被触发后，大致经历这几个阶段：

1. 意图匹配：Claude Code根据你的输入和Skill元数据，决定是否触发该Skill。
2. 上下文注入：被触发Skill的SKILL.md正文被加载到当前对话的上下文中。
3. 指令执行：Claude Code按照SKILL.md里的指令，结合你的具体输入，生成响应或调用工具。
4. 结果输出：响应返回给你，Skill的上下文可能被保留也可能被丢弃，取决于实现。

问题通常出在第1步和第3步。第1步的匹配不准，会导致该触发的没触发、不该触发的乱触发。第3步的执行偏差，往往是因为SKILL.md里的指令和你的实际项目环境不匹配。我删掉的很多Skill，都是因为第3步——它们的指令写得太“通用”了，放到具体项目里就水土不服。

3. 我删掉的四类Skill，以及它们为什么该被删

3.1 功能重叠的“同类项”：五个代码审查Skill的教训

我最多的时候装了五个和代码审查相关的Skill：code-review、pr-reviewer、security-check、best-practices、lint-helper。它们的描述各不相同，但实际用起来，重叠度极高。code-review和pr-reviewer都会检查命名规范、函数长度、注释完整性；security-check和lint-helper都会看输入验证和边界条件。

这种重叠带来的直接后果是：当我让Claude Code审查代码时，它可能触发其中任意一个，而每个Skill的审查标准还不完全一致。有时候它用code-review的标准说“这个函数太长了”，有时候用best-practices的标准说“这个函数长度可以接受”。这种不一致让我对审查结果失去了信任。

删掉四个，只留一个之后，情况立刻好转。我保留的是自己改过的code-review，把其他Skill里我觉得有价值的检查项合并了进去。现在每次审查，标准都是统一的，我也知道该期待什么样的输出。

经验：同类Skill只留一个，把其他Skill里你真正在意的检查项手动合并进去。合并的成本远低于维护多个Skill的心智负担。

3.2 触发条件过于宽泛的“万能Skill”

有一类Skill，描述写得特别宏大，比如“帮助解决任何编程问题”“提升代码质量”“优化开发流程”。这种Skill听起来很美好，但实际上几乎从不触发，或者触发了也给不出有针对性的建议。原因很简单：Claude Code的触发机制需要明确的匹配信号，而“任何编程问题”这种描述，和用户的具体输入之间很难建立强关联。

我装过一个叫dev-assistant的Skill，描述是“作为开发助手，提供全方位的编程支持”。三个月里，它被触发的次数是零。不是因为它没用，而是因为它的描述太泛了，Claude Code根本不知道什么时候该用它。相比之下，我后来装的一个叫explain-error-message的Skill，描述是“当用户粘贴报错信息并询问原因时，解释报错含义并给出修复建议”，触发率极高，而且每次触发都很准。

3.3 与当前项目技术栈不匹配的“水土不服型”

这类Skill本身质量可能很高，但和你的实际技术栈不匹配。比如你主要写Python，但装了一个专门针对JavaScript的eslint-fixer；或者你用PostgreSQL，但装了一个针对MySQL的query-optimizer。这些Skill在你的环境里要么不触发，要么触发了也给出错误的建议。

我删掉的一个典型是react-component-generator。我确实偶尔写前端，但主力是后端Python。这个Skill在我写Python时从来不触发，在我偶尔写React时又因为项目配置不同（我用的是Vite，它假设是Create React App）而给出过时的建议。留着它，除了占元数据空间，没有任何实际价值。

3.4 维护成本高于使用价值的“一次性Skill”

有些Skill是为了某个特定任务临时写的，任务完成后就再也没有用过。比如我曾经为了把一个老项目的代码从Python 2迁移到Python 3，写了一个py2to3-helper。迁移完成后，这个Skill就彻底闲置了。类似的还有migration-assistant、one-time-refactor之类的。

这类Skill的问题不在于它们不好，而在于它们的适用场景太窄，窄到在你的日常工作中几乎不会再次出现。留着它们，除了让你在skills目录里看到一堆文件时感到焦虑，没有任何正面作用。

4. 留下来的20%：我的Skill保留清单与筛选标准

4.1 筛选标准：三个问题决定去留

删掉80%之后，我总结了一个简单的筛选流程。每次想装新Skill，或者想清理旧Skill时，问自己三个问题：

1. 过去两周内，这个Skill被触发过吗？如果答案是否定的，而且不是因为这两周没做相关工作，那它大概率该删。
2. 如果删掉它，我会立刻感到不便吗？如果不会，说明它的价值还没有高到需要保留。
3. 它的功能，能不能被另一个更通用的Skill覆盖？如果能，就合并；如果不能，再考虑单独保留。

这三个问题看起来简单，但能过滤掉绝大多数“看起来有用”的Skill。我现在的保留清单里，只有八个Skill，每一个都通过了这三个问题的考验。

4.2 我保留的八类Skill及其实际使用场景

下面是我目前保留的Skill清单，以及它们在我日常工作里的实际触发场景。注意，这些Skill的名字可能和社区里流行的版本不同，因为我大多根据自己的需求改过。

这八个Skill覆盖了我日常工作的绝大部分场景。它们之间没有功能重叠，触发条件都很明确，而且每个都经过了我的手动调整，以匹配我的项目环境。

4.3 一个被保留Skill的SKILL.md长什么样

以code-review为例，我改过的SKILL.md大致是这样的结构：

--- name: code-review description: 当用户要求审查代码、检查代码质量、或询问代码是否有问题时触发。适用于Python和TypeScript。 --- # 代码审查 ## 审查范围 - 命名规范：变量、函数、类名是否清晰且符合语言惯例 - 函数长度：超过50行的函数需要标记 - 边界条件：空值、空列表、极端输入是否处理 - 错误处理：异常是否被合理捕获和处理 - 注释：复杂逻辑是否有注释说明 ## 输出格式 按严重程度分级：Critical / Warning / Suggestion 每条问题给出具体行号和修改建议 ## 不检查的内容 - 代码格式（交给linter） - 性能问题（除非明显低效） - 架构设计（超出单次审查范围）

这个SKILL.md的关键在于：明确写了不检查什么。这看起来是小事，但实际上极大地提高了审查的准确率。以前没有这一条时，Claude Code经常在审查时扯到架构设计上去，给出一些大而空的建议。加上“不检查的内容”之后，它的输出聚焦了很多。

5. 用settings.json和npx skills把管理成本降下来

5.1 settings.json里的Skill相关配置

Claude Code的settings.json里，和Skill相关的配置项不多，但每一个都值得注意。我目前的配置大致是这样的：

{ "skills": { "directory": "~/.claude/skills", "autoLoad": true, "maxActive": 10 } }

maxActive这个参数是我自己加的（通过社区插件实现），用来限制同时加载的Skill数量。虽然Claude Code本身没有这个原生配置，但通过一些社区工具可以实现类似效果。它的作用是：当激活的Skill超过10个时，自动禁用最久未使用的那些。这个机制强迫我保持Skill的精简，避免再次陷入“装了一堆”的状态。

另一个值得关注的配置是directory。默认情况下，Skill是全局加载的，所有项目共用一套Skill。但如果你同时维护多个技术栈差异很大的项目，全局Skill就会带来问题。我的做法是：全局目录只放最通用的Skill（比如commit-msg、explain-error），项目特定的Skill放在项目根目录的.claude/skills/下。这样切换项目时，加载的Skill集合会自动变化。

5.2 用npx skills做批量管理和版本控制

npx skills是一个社区维护的CLI工具，用来管理Claude Code的Skill。它最实用的功能是list和prune：

# 列出所有已安装的Skill及其最后使用时间 npx skills list # 删除超过30天未使用的Skill npx skills prune --days 30 # 从GitHub安装Skill npx skills install https://github.com/user/skill-repo

prune命令是我定期清理的主要工具。它根据Skill的最后触发时间来判断是否该删除，比手动翻目录高效得多。不过要注意，prune的判断依据是触发记录，如果你某个Skill确实有用但恰好一个月没触发，可能会被误删。我的做法是先用list看一眼，确认没有误伤再执行prune。

5.3 版本控制：把Skill目录纳入Git

Skill的另一个管理痛点是版本控制。你改了一个SKILL.md，过段时间想回滚，或者想看看某个Skill是什么时候加的，如果没有版本控制，这些信息就丢了。我的做法是把~/.claude/skills目录做成一个Git仓库，每次增删改Skill都提交一次。

cd ~/.claude/skills git init git add . git commit -m "add code-review skill"

这样做的好处是：第一，可以随时回滚到之前的版本；第二，通过git log能看到每个Skill的变更历史；第三，换电脑时直接clone这个仓库，Skill配置就迁移过去了。唯一需要注意的是，有些Skill可能包含敏感信息（比如API密钥），提交前要检查一下。

6. 删掉80%之后，我的Claude Code使用体验发生了什么变化

6.1 触发准确率的提升

最直观的变化是触发准确率。以前装了四十多个Skill时，我经常遇到“该触发的不触发，不该触发的乱触发”的情况。删到八个之后，几乎每次触发都是准确的。原因很简单：候选集小了，Claude Code的匹配算法更容易找到正确的目标。这就像在一个嘈杂的房间里找人，房间里只有八个人时，你一眼就能认出要找的那个；有四十个人时，你得一个个看过去。

6.2 响应速度与上下文效率

响应速度的提升也很明显。虽然Skill的元数据占用的token不多，但四十个Skill的元数据加起来，加上触发时的上下文注入，对响应速度还是有影响的。删到八个之后，同样的任务，Claude Code的响应时间大概缩短了15%到20%。这个提升在处理大型代码库时尤其明显，因为上下文窗口更充裕了。

6.3 心智负担的减轻

但最大的变化，其实是心智负担的减轻。以前每次让Claude Code做点什么，我都会下意识地想“它会触发哪个Skill”“那个Skill会不会给出奇怪的输出”。这种不确定性让人很累。现在我知道每个Skill的触发条件和输出风格，用起来很放心。这种“确定性”带来的效率提升，比任何单个Skill的功能都重要。

6.4 一个具体的对比案例

举个具体的例子。以前我要让Claude Code审查一段代码，流程是这样的：输入“帮我审查这段代码”，然后等它触发某个不确定的Skill，然后看输出，如果输出不符合预期，再手动补充要求，比如“重点看边界条件”“不要提架构建议”。整个过程可能要来回三四次。

现在，我输入“帮我审查这段代码”，code-review被稳定触发，输出直接按Critical/Warning/Suggestion分级，边界条件一定会被检查，架构建议一定不会出现。一次搞定。这个效率差异，在每天多次审查的情况下，累积起来非常可观。

7. 如果你也想清理Skill，从这三步开始

7.1 第一步：导出当前Skill清单和使用记录

在动手删之前，先搞清楚现状。用npx skills list导出所有Skill的名称和最后使用时间，或者直接看~/.claude/skills目录下的文件夹列表。然后回顾一下过去两周的工作，标记出哪些Skill你确实用过。没用过的，先放到“待删除”列表里。

7.2 第二步：按“三个问题”逐个筛选

对每个“待删除”列表里的Skill，问那三个问题：过去两周触发过吗？删掉会立刻不便吗？能被其他Skill覆盖吗？三个问题里有两个答案是“否”，就删。如果拿不准，先移到备份目录，观察一周，一周后还是没用过，就彻底删掉。

7.3 第三步：合并同类项，重写保留Skill的SKILL.md

对于决定保留的Skill，检查一下有没有功能重叠。如果有，选一个作为基础，把其他Skill里你真正在意的部分合并进去。然后重写SKILL.md，重点加上“不检查的内容”这一节。这一步花的时间最多，但收益也最大。一个精心调过的Skill，价值超过十个随便装的Skill。

注意：删Skill之前，先确认没有其他项目或脚本依赖它。有些Skill可能被CI流程或者自动化脚本调用，删掉会导致意外失败。检查方法很简单：在项目里搜一下Skill的名字，看看有没有引用。

8. 关于Skill管理，我踩过的几个坑

第一个坑是盲目跟风装Skill。社区里有人分享了一个“超强代码审查Skill”，我立刻装上，结果发现它的审查标准和我团队的规范冲突，反而添乱。后来我学乖了：装任何Skill之前，先读一遍它的SKILL.md，确认它的假设和我的环境匹配。

第二个坑是改了SKILL.md但没记录。有次我改了一个Skill的触发条件，过了一个月完全忘了改过什么，导致行为不符合预期时排查了很久。现在每次改SKILL.md，我都会在Git提交信息里写清楚改了什么、为什么改。

第三个坑是把Skill当成万能药。有段时间我遇到任何问题都想“写个Skill来解决”，结果Skill越写越多，问题却没少多少。后来我意识到，Skill适合解决“重复性的、有明确模式的”任务，不适合解决“一次性的、需要创造性思考的”任务。把后者也做成Skill，纯属浪费时间。

第四个坑是忽略Skill之间的相互影响。有两个Skill，单独用都没问题，但同时激活时，一个Skill的输出会被另一个Skill的指令干扰。这种问题很难排查，因为单独测试时一切正常。我的应对方法是：每次只激活当前任务需要的Skill，任务完成后立即禁用。虽然麻烦一点，但避免了这种隐蔽的冲突。

9. 最后分享几个让Skill真正好用的实操技巧

技巧一：给Skill写“负面清单”。前面提过，在SKILL.md里明确写“不检查什么”“不做什么”，比写“要做什么”更能提高输出质量。Claude Code倾向于过度发挥，负面清单能把它拉回正轨。

技巧二：用注释标记Skill的版本和修改日期。在SKILL.md开头加一行<!-- v2.1, 2025-03-15, 调整了触发条件 -->，方便日后回溯。这个习惯看起来微不足道，但在排查问题时能省很多时间。

技巧三：定期做“Skill审计”。我每个月花十分钟，用npx skills list看一眼所有Skill的使用情况，把超过30天没触发的标记出来。连续两个月被标记的，直接删。这个习惯让我从“装了一堆”变成了“只留有用的”。

技巧四：不要追求“完美Skill”。我见过有人为了写一个完美的代码审查Skill，反复改了二十多版，花了大量时间。但实际用起来，一个80分的Skill和一个95分的Skill，在日常工作中的差异远没有想象中那么大。把时间花在写Skill上，不如花在写代码上。Skill是工具，不是目的。

技巧五：保留一个“实验性Skill”的位置。我允许自己同时只有一个实验性Skill，用来尝试新的想法。如果两周内它证明了自己的价值，就转正；如果没有，就删掉。这个机制让我既能探索新可能，又不会让Skill列表失控。

删掉80%的Skill之后，我最大的体会是：少即是多。Skill的价值不在于数量，而在于每一个都能在正确的时机、以正确的方式、给出正确的输出。与其装四十个半吊子Skill，不如精心维护八个真正好用的。这个道理，放在工具选择、代码设计、甚至日常生活的很多方面，都成立。