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被触发后大致经历这几个阶段意图匹配Claude Code根据你的输入和Skill元数据决定是否触发该Skill。上下文注入被触发Skill的SKILL.md正文被加载到当前对话的上下文中。指令执行Claude Code按照SKILL.md里的指令结合你的具体输入生成响应或调用工具。结果输出响应返回给你Skill的上下文可能被保留也可能被丢弃取决于实现。问题通常出在第1步和第3步。第1步的匹配不准会导致该触发的没触发、不该触发的乱触发。第3步的执行偏差往往是因为SKILL.md里的指令和你的实际项目环境不匹配。我删掉的很多Skill都是因为第3步——它们的指令写得太“通用”了放到具体项目里就水土不服。3. 我删掉的四类Skill以及它们为什么该被删3.1 功能重叠的“同类项”五个代码审查Skill的教训我最多的时候装了五个和代码审查相关的Skillcode-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时问自己三个问题过去两周内这个Skill被触发过吗如果答案是否定的而且不是因为这两周没做相关工作那它大概率该删。如果删掉它我会立刻感到不便吗如果不会说明它的价值还没有高到需要保留。它的功能能不能被另一个更通用的Skill覆盖如果能就合并如果不能再考虑单独保留。这三个问题看起来简单但能过滤掉绝大多数“看起来有用”的Skill。我现在的保留清单里只有八个Skill每一个都通过了这三个问题的考验。4.2 我保留的八类Skill及其实际使用场景下面是我目前保留的Skill清单以及它们在我日常工作里的实际触发场景。注意这些Skill的名字可能和社区里流行的版本不同因为我大多根据自己的需求改过。Skill名称触发场景使用频率核心价值code-review要求审查代码时每天多次统一的审查标准覆盖命名、逻辑、边界条件explain-error粘贴报错信息时每天多次快速定位报错原因给出修复方向test-writer要求为函数写测试时每天1-2次生成符合项目测试框架的用例commit-msg要求生成提交信息时每天多次按团队规范生成commit messagedoc-string要求补文档时每周几次生成符合项目风格的docstringsql-optimize要求优化SQL时每周几次针对PostgreSQL的查询优化建议regex-helper要求写正则时每周几次生成并解释正则表达式api-design设计新接口时每周1-2次检查RESTful规范给出命名建议这八个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-repoprune命令是我定期清理的主要工具。它根据Skill的最后触发时间来判断是否该删除比手动翻目录高效得多。不过要注意prune的判断依据是触发记录如果你某个Skill确实有用但恰好一个月没触发可能会被误删。我的做法是先用list看一眼确认没有误伤再执行prune。5.3 版本控制把Skill目录纳入GitSkill的另一个管理痛点是版本控制。你改了一个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不如精心维护八个真正好用的。这个道理放在工具选择、代码设计、甚至日常生活的很多方面都成立。
