1. 从堆满 Skill 到删掉八成，我到底经历了什么

去年年底我开始重度使用 Claude Code，那会儿刚摸清SKILL.md的写法，整个人处于一种“万物皆可 Skill”的亢奋状态。看到有人分享一个自动整理会议纪要的 Skill，装；刷到一个能生成周报的 Skill，装；听说某个 Skill 可以帮我写 SQL 注释，也装。三个月下来，.claude/skills目录里塞了四十多个文件夹，settings.json里的配置项越堆越长，每次启动 Claude Code 都要等它扫描一遍所有 Skill 的元数据。

结果呢？真正高频使用的不到八个。剩下的要么是功能重叠，要么是触发条件太窄根本想不起来用，要么是维护成本高到每次改完还要同步更新文档。最离谱的是有几个 Skill 之间还会互相干扰——比如两个都监听“帮我写”这个触发词，Claude 有时候会选错，输出一堆莫名其妙的东西。

所以上个月我做了一次彻底清理，删掉了大约 80% 的 Skill，只留下真正经得起日常考验的那几个。这篇文章不是教你“怎么装 Skill”，而是想聊聊怎么判断一个 Skill 值不值得留，以及我在这个过程中总结出的一套筛选逻辑。如果你也在用 Claude Code，或者正在折腾npx skills那一套工具链，这篇应该能帮你少走点弯路。

2. 先搞清楚 Skill 到底解决了什么问题

2.1 Skill 的本质是“预置上下文 + 触发规则”

很多人把 Skill 当成插件来理解，其实不太准确。Claude Code 的 Skill 机制核心就两件事：一是通过SKILL.md给模型注入一段预设的指令和知识，二是通过触发词或文件匹配规则决定什么时候加载这段上下文。它不执行代码，不调用外部 API，本质上是在改变模型在特定场景下的行为模式。

举个例子，我写过一个“代码审查”Skill，SKILL.md里规定了审查时要检查命名规范、错误处理、边界条件、性能隐患这几个维度，并且要求输出格式统一为“问题描述 + 严重程度 + 修改建议”。这样每次我让 Claude 审查代码时，它就会按照这个框架来，而不是泛泛地说“这段代码看起来不错”。

理解这一点很关键，因为它决定了你判断一个 Skill 是否值得保留的标准：它是否在某个高频场景下，稳定地提升了输出质量或减少了你的沟通成本。如果答案是否定的，那这个 Skill 就是负担。

2.2 为什么我们会忍不住装一堆 Skill

我复盘了一下自己当初疯狂装 Skill 的心理，大概有这么几种：

• FOMO（错失恐惧）：看到别人分享一个看起来很厉害的 Skill，觉得不装就亏了。
• 过度设计：为一个可能一个月才用一次的场景专门写个 Skill，美其名曰“自动化”。
• 功能重叠不自知：装了三个都能生成 commit message 的 Skill，其实用哪个都一样。
• 收藏癖：把 Skill 当成书签，觉得“先存着以后肯定用得上”。

这些心理导致的直接后果就是：.claude/skills目录越来越臃肿，启动变慢，触发冲突变多，维护成本飙升。更隐蔽的问题是，当 Skill 太多时，你会逐渐失去对模型行为的掌控感——你不再清楚它为什么在这个场景下选择了那个 Skill，输出不符合预期时也不知道该从哪里排查。

2.3 删掉 80% 之后，我留下了什么

目前我保留的 Skill 大概有七个，覆盖了以下几类场景：

这些 Skill 的共同特点是：每周至少用三次以上，触发条件明确，输出格式稳定，维护成本低。剩下的那些，要么被合并进了这几个，要么直接删掉用普通 prompt 替代。

3. 我是怎么筛选和清理 Skill 的

3.1 第一步：统计真实使用频率

别靠感觉，靠数据。Claude Code 本身不提供 Skill 使用统计，但你可以通过几个间接方式来判断：

• 翻聊天记录，搜索每个 Skill 的触发词，看过去一个月出现了多少次。
• 检查.claude/skills下每个文件夹的SKILL.md最后修改时间，超过两个月没动过的基本可以标记为“待观察”。
• 回忆最近两周的工作流，哪些环节你主动想到“这里该用那个 Skill”。

我当时的做法是拉了一个表格，把每个 Skill 的名称、触发词、最后使用日期、使用频率（高/中/低/几乎不用）列出来。结果很直观：四十多个 Skill 里，高频的只有六个，中频的四个，剩下的全是低频或几乎不用。

注意：有些 Skill 是“季节性”的，比如季度总结模板，可能三个月才用一次。这类不要急着删，先标记为“保留观察”，等下一个周期到了再看。

3.2 第二步：识别功能重叠和触发冲突

功能重叠很好理解，就是两个 Skill 干的事差不多。比如我有三个 Skill 都能生成 commit message，区别只是格式略有不同。这种直接保留最好的那个，其余删掉。

触发冲突更隐蔽，也更危险。Claude Code 在匹配 Skill 时，如果多个 Skill 的触发条件都满足，它会选择一个来加载，但选择逻辑并不总是符合你的预期。我遇到过最典型的情况是：一个“代码解释”Skill 和一个“代码审查”Skill 都监听“看看这段代码”，结果我想审查的时候它给我解释了一遍，我想解释的时候它给我挑了一堆毛病。

排查方法很简单：把所有 Skill 的触发词列出来，看看有没有重复或高度相似的。如果有，要么合并，要么把触发词改得更精确。

3.3 第三步：评估维护成本

一个 Skill 的维护成本包括：

• SKILL.md的内容是否需要随项目变化而更新
• 是否依赖特定的文件结构或配置
• 是否与其他 Skill 或settings.json中的配置有耦合
• 出问题时排查难度有多大

我删掉的一个典型例子是一个“自动生成 API 文档”的 Skill。它需要我维护一个额外的 YAML 配置文件来描述接口结构，每次接口变了都要同步更新。用了两次之后我就发现，直接让 Claude 读代码生成文档反而更快，而且不需要维护额外文件。这种就是典型的“维护成本高于收益”。

3.4 第四步：合并与重构

有些 Skill 不是没用，而是粒度太细。比如我原来有“生成函数注释”“生成类注释”“生成模块注释”三个 Skill，后来合并成一个“代码注释生成”Skill，通过参数区分场景。这样既减少了数量，又降低了触发冲突的概率。

合并的原则是：同一类任务、同一套输出规范、同一组触发场景的 Skill，尽量合并。合并后SKILL.md会变长，但维护点从三个变成一个，总体成本是下降的。

4. 留下来的 Skill 长什么样

4.1 一个合格 Skill 的SKILL.md结构

我现在的SKILL.md模板大概长这样：

--- name: code-review description: 对代码进行结构化审查，输出问题清单和修改建议 trigger: 审查代码、review、检查这段代码 --- ## 审查维度 1. 命名规范：变量、函数、类名是否清晰且符合项目约定 2. 错误处理：是否覆盖了边界条件和异常路径 3. 性能隐患：是否有不必要的循环、重复计算、内存泄漏风险 4. 可读性：逻辑是否清晰，注释是否到位 ## 输出格式 按严重程度分组，每条包含： - 问题描述 - 所在位置 - 修改建议 - 严重程度（高/中/低） ## 注意事项 - 不要泛泛而谈，每条建议必须具体到代码行 - 如果代码整体质量较高，也要指出可以进一步优化的点

这个结构的关键在于：触发词精确、审查维度明确、输出格式固定、注意事项清晰。这样每次触发时，Claude 的行为都是可预期的。

4.2 触发词的设计技巧

触发词太宽泛会导致误触发，太窄又会导致想用的时候触发不了。我的经验是：

• 用动词 + 对象的组合，比如“审查代码”“整理纪要”“生成 SQL”，而不是单独一个“审查”或“整理”。
• 避免使用日常对话中高频出现的词，比如“帮我”“看看”“写一下”。
• 如果有多个 Skill 可能被同一句话触发，给每个 Skill 加上独特的限定词。

我现在的做法是，每个 Skill 的触发词都经过实际测试：在 Claude Code 里输入各种可能的表达方式，看它是否稳定触发目标 Skill。测试通过后才正式启用。

4.3 用settings.json控制加载行为

settings.json里可以配置 Skill 的加载策略。我目前用的是按需加载模式，只有触发词匹配时才加载对应的SKILL.md，而不是启动时全部加载。这样启动速度明显变快，而且减少了 Skill 之间的干扰。

具体配置项因版本而异，但核心思路是：不要让所有 Skill 都处于常驻状态。把低频 Skill 设为按需加载，高频 Skill 可以设为常驻，但总数控制在十个以内。

5. 那些被我删掉的 Skill，问题出在哪

5.1 场景太窄，一个月用不了一次

我删掉过一个“生成数据库迁移脚本”的 Skill。当时觉得这个场景很专业，值得单独做一个。但实际上，我一个月可能就写一两次迁移脚本，而且每次的表结构都不一样，Skill 里预置的模板反而限制了灵活性。后来直接用普通 prompt 描述需求，效果一样好。

这类 Skill 的问题是：为了一个低频场景增加了长期的维护负担。除非这个场景极其复杂且重复性极高，否则不值得做成 Skill。

5.2 输出格式太死，反而不好用

有一个“周报生成”Skill，我给它规定了固定的模板：本周完成、下周计划、风险与阻塞、需要支持。结果用了两次就发现，有些周报需要突出数据，有些需要详细描述技术方案，固定模板反而让我每次都要额外调整。后来改成用一个简单的 prompt 框架，让 Claude 根据内容自动选择结构，灵活多了。

5.3 与其他 Skill 冲突，排查成本高

前面提到的“代码解释”和“代码审查”冲突就是典型例子。两个 Skill 单独用都没问题，但同时存在时就会互相干扰。我当时的排查过程是：先禁用其中一个，测试另一个是否正常；然后反过来；最后确认是触发词重叠导致的。这个过程花了将近一个小时，而这两个 Skill 的价值加起来也不值得这个排查成本。

5.4 依赖外部文件，同步麻烦

有一个“API 文档生成”Skill 需要读取一个单独的api-schema.yaml文件。每次接口变更，我都要先更新这个 YAML，再让 Claude 生成文档。后来发现，直接让 Claude 读代码里的类型定义和注释，生成的文档质量差不多，还省去了维护 YAML 的步骤。这种依赖外部文件的 Skill，除非外部文件本身有独立价值，否则不如不做。

6. 清理之后的工作流变化

6.1 启动更快，干扰更少

删掉 80% 的 Skill 之后，最直观的变化是 Claude Code 启动速度明显提升。之前启动时要扫描四十多个 Skill 的元数据，现在只有七个，几乎秒开。更重要的是，触发冲突几乎消失了，Claude 的行为变得可预测很多。

6.2 从“找 Skill”变成“写 Prompt”

以前遇到一个任务，我会先想“有没有对应的 Skill”。现在我会先想“这个任务需要什么上下文和输出格式”，然后直接写 prompt。很多时候，一个精心设计的 prompt 比一个 Skill 更灵活、更高效。Skill 只在那些高频、格式固定、需要长期保持一致的场景下才有优势。

6.3 维护清单从四十项变成七项

我现在每个月会花十分钟检查一下保留的 Skill：SKILL.md是否需要更新、触发词是否仍然准确、输出格式是否还符合当前需求。七项检查起来很快，四十项就是灾难。

7. 常见问题与排查技巧

7.1 Skill 不触发怎么办

先检查触发词是否精确。在 Claude Code 里输入你期望触发的那句话，看它实际加载了哪个 Skill。如果没加载目标 Skill，可能是触发词不匹配，或者被其他 Skill 抢先匹配了。解决办法是调整触发词，或者临时禁用其他 Skill 来排查。

7.2 Skill 触发了但输出不对

检查SKILL.md里的指令是否清晰。常见问题是指令太模糊，比如“输出格式要清晰”这种话等于没说。要具体到“按以下格式输出：第一行是标题，第二行是摘要，第三行开始是正文”。另外，检查是否有其他 Skill 的上下文混进来了。

7.3 多个 Skill 冲突怎么排查

用二分法：先禁用一半 Skill，测试问题是否复现；然后逐步缩小范围。找到冲突的两个 Skill 后，要么合并，要么修改触发词让它们互斥。如果两个 Skill 功能高度重叠，直接删掉一个。

7.4 怎么判断一个 Skill 该不该删

问自己三个问题：

1. 过去一个月我用了几次？
2. 如果删掉它，我用普通 prompt 能不能达到类似效果？
3. 维护它需要我额外做什么？

如果第一个问题答案是“少于三次”，第二个答案是“能”，第三个答案是“需要额外维护文件或配置”，那就删。

7.5npx skills安装的 Skill 怎么管理

npx skills是个方便的工具，可以快速安装社区分享的 Skill。但装完之后一定要检查SKILL.md的内容，看看触发词是否与现有 Skill 冲突，输出格式是否符合你的习惯。不要装完就用，更不要装完就忘。我现在的做法是：装完一个新 Skill，先放在“试用区”观察两周，两周内用不到三次就删。

8. 给还在堆 Skill 的人几句实在话

Skill 不是越多越好，这跟代码库不是越大越好是一个道理。每一个 Skill 都是一个需要维护的资产，它的价值等于“使用频率 × 单次收益 - 维护成本”。当这个值为负时，它就是在拖后腿。

我现在保留的七个 Skill，每一个都经过了至少两个月的实际使用检验。它们覆盖了我日常工作中最高频、最需要保持一致性的场景。剩下的需求，我用 prompt 解决，灵活且没有维护负担。

如果你现在.claude/skills目录里也塞了一堆东西，不妨花半个小时做一次清理。统计使用频率、识别功能重叠、评估维护成本，然后果断删掉那些“看起来有用”但实际很少碰的 Skill。删完之后你会发现，Claude Code 用起来反而更顺手了。

最后分享一个小技巧：每次想装新 Skill 之前，先问自己“这个需求我用 prompt 能不能解决”。如果能，就别装。如果确实不能，再考虑做成 Skill，并且从第一天起就记录它的使用情况。三个月后回头看，你会感谢当时克制的自己。