微信小程序tabBar配置与个人信息页开发实战
2026/10/15 18:07:44
1. 从“装了一堆”到“删掉八成”：一个Skill重度用户的真实复盘
去年秋天我开始在Claude Code里折腾Skill，那会儿刚摸清SKILL.md的写法，觉得这东西简直是给AI装外挂——写代码的、写文案的、做数据分析的、甚至帮忙起名字的，看到有人分享就顺手clone下来塞进~/.claude/skills/目录。三个月下来，npx skills list能刷出四十多条，settings.json里的配置越堆越长，每次启动Claude Code都要等它挨个加载。直到某天我让它帮我改一段Python脚本，它居然先调用了一个“周报生成Skill”去分析我的需求，绕了一大圈才回到正题。那一刻我意识到：Skill不是越多越好，装得越多，AI越容易“精神分裂”。
这篇文章不聊怎么从零写一个Skill，那种教程一搜一大把。我想聊的是为什么你装了那么多Skill反而不好用，以及怎么判断哪些该留、哪些该删。如果你也在Claude Code里囤了十几个甚至几十个Skill，每次对话都要纠结用哪个，或者发现AI的行为越来越不可预测，那这篇复盘应该能帮你省下不少试错时间。核心关键词就几个：Claude Code、Skill、SKILL.md、npx skills、settings.json——但重点不在工具本身，而在使用策略。
先说结论：我最后保留了8个Skill，删掉了32个。留下来的不是功能最强的，而是触发条件最明确、职责最单一、和我日常工作流耦合最紧的那几个。下面我把整个筛选逻辑、判断标准、以及删改过程中踩过的坑，完整拆一遍。
2. 为什么Skill装多了反而坏事：三个底层机制
2.1 Skill的加载机制决定了“越多越慢越乱”
Claude Code加载Skill的方式，简单说就是启动时扫描目录、读取每个SKILL.md的元数据、构建索引。你装40个Skill，它就要解析40份描述文件，把每个Skill的name、description、trigger条件全部塞进上下文。这带来两个直接后果：
第一，启动变慢。我实测过，从8个Skill增加到40个，冷启动时间从1.2秒涨到4.7秒。单次看不明显，但你一天开几十次Claude Code，累积起来就是几分钟的纯等待。
第二，也是更致命的——上下文污染。每个Skill的description都会占用token预算。40个Skill的描述加起来轻松超过3000 token，这些token本来可以用来放你的代码、你的需求描述。更麻烦的是，当多个Skill的触发条件有重叠时，模型需要在它们之间做选择，这个选择过程本身就会引入不确定性。
注意：Skill的description不是随便写写的。它直接决定了模型在什么情况下会调用这个Skill。描述写得越宽泛，误触发的概率越高。
2.2 触发条件的模糊性是万恶之源
我删掉的32个Skill里，有21个是因为触发条件太模糊。举个例子，我装过一个叫“code-helper”的Skill，description写的是“帮助编写和优化代码”。听起来没问题对吧？但问题是，我装的另一个Skill叫“python-expert”，description是“Python代码审查与优化”。当我让Claude改一段Python时，两个Skill都觉得自己该上场，结果就是模型先调用code-helper做通用分析，再调用python-expert做专项审查，最后输出一段缝合怪一样的回复。
这种模糊性在Skill数量少的时候不明显，一旦超过15个，冲突概率急剧上升。我的经验是：如果一个Skill的description里出现了“通用”“辅助”“帮助”“优化”这类词，它大概率会和其他Skill打架。
2.3 维护成本被严重低估
装Skill只要一条npx skills add命令，但维护成本远不止于此。每次Claude Code更新版本，都可能影响Skill的兼容性；每个Skill的作者可能随时停止维护；不同Skill之间可能依赖不同版本的依赖库。我遇到过最离谱的情况是：两个Skill分别依赖同一个npm包的不同major版本，导致node_modules里出现了冲突，Claude Code直接启动失败。
删掉80%之后，我的维护清单从“每周检查一次更新”变成了“每月扫一眼”，省下来的时间足够我多写两篇文档。
3. 我的Skill筛选标准：四问淘汰法
3.1 第一问：过去30天用过几次？
这是最硬核的指标。Claude Code的日志里其实有Skill调用记录，你可以通过npx skills stats查看（不同版本命令可能略有差异，也可以直接翻~/.claude/logs/目录）。我把过去30天调用次数少于3次的Skill全部标记为“候选删除”。
结果很残酷：40个Skill里，有19个在过去30天里一次都没被调用过。它们安静地躺在目录里，占用着加载时间和上下文预算，却从未产生价值。这19个里面，有12个是我“觉得以后可能用得上”而装的，7个是看到别人推荐随手加的。
实操心得：不要相信“以后可能用得上”。如果30天内没用过，大概率未来30天也不会用。需要的时候再装，比囤着不用强一百倍。
3.2 第二问：触发条件是否唯一且明确？
通过第一轮筛选后，剩下21个Skill。接下来看每个Skill的description，问自己：这个Skill的触发场景，是否和其他Skill有重叠？
我当时的判断方法是：把每个Skill的description抄下来，两两对比。如果两个Skill的描述里出现了相同的核心动词（比如“生成”“分析”“优化”“转换”），且作用对象也相同（比如都是“代码”或都是“文档”），那它们就是竞争关系，必须删一个。
举几个我实际删掉的例子：
| 被删Skill | 删除原因 | 保留的替代方案 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| code-helper | 与python-expert触发条件重叠 | python-expert | ||||||||||||||||
| doc-writer | 与markdown-formatter功能重叠 | markdown-formatter | ||||||||||||||||
| >tar -czvf skills-backup-$(date +%Y%m%d).tar.gz ~/.claude/skills/ 然后生成一份审计清单，把每个Skill的以下信息列出来： 这份清单是你后续判断的基础。不要凭记忆做决定，记忆会骗人。 5.2 分批禁用而非直接删除我的做法是先禁用、再观察、最后删除。Claude Code支持通过 这样被禁用的Skill不会被加载，但文件还在。观察一周，如果确实没有影响，再物理删除。这个缓冲期救过我两次——有一次我禁用了一个Skill后才发现某个自动化流程依赖它，赶紧恢复了。 5.3 清理settings.json里的冗余配置删Skill的同时， 清理方法是：逐段检查 5.4 验证清理效果清理完成后，跑一次完整验证： 我的实测数据：清理前冷启动4.7秒，清理后1.3秒；上下文里Skill相关token从约3200降到约600；误触发率（AI调用了不该调的Skill）从每周5-6次降到几乎为零。 6. 常见问题与排查技巧实录6.1 Skill删了但AI还在调用，怎么回事？这是最常见的问题。原因通常是缓存没清。Claude Code会在 然后重启Claude Code。如果还不行，检查 6.2 两个Skill功能重叠但都舍不得删，怎么办？我的建议是合并成一个。把两个Skill的SKILL.md拿出来，提取共同的核心逻辑，写成一个新的Skill，description里明确写清楚“同时处理A和B两种场景”。这样既保留了功能，又避免了冲突。 如果合并成本太高，那就保留触发条件更窄的那个。窄触发意味着误触发概率低，对上下文的污染也小。 6.3 删完之后发现某个Skill其实有用，怎么恢复？这就是为什么我强调先备份、先禁用、再删除。如果备份还在，直接解压恢复： 如果备份丢了，但你还记得Skill的名字，可以尝试重新安装： 不过要注意，有些Skill的作者可能已经删库了，那就只能自己重写了。 6.4 怎么判断一个Skill的description写得好不好？好的description有三个特征：动词具体、对象明确、边界清晰。举个例子：
差的description会让模型在无数场景下都想调用它，好的description只在特定场景下触发。如果你发现某个Skill经常在不该出现的时候冒出来，先检查它的description是不是写得太宽泛了。 6.5 问题速查表
7. 删掉80%之后，我的Claude Code使用体验最直观的变化是响应变快了。以前每次对话，模型要先在40个Skill里做一轮筛选，现在8个Skill的索引小到几乎可以忽略。我实测过同一个任务（审查一段200行的Python代码），清理前平均响应时间8.3秒，清理后5.1秒，快了将近40%。 第二个变化是行为可预测了。以前我让Claude改代码，它有时候会先调用“周报生成Skill”分析需求，有时候会调用“文档格式化Skill”整理输出，行为完全不可控。现在每个Skill的职责边界清晰，模型不会“想太多”，该调什么就调什么。 第三个变化是维护负担大幅降低。以前每个月要花一两个小时检查Skill更新、处理兼容性问题，现在8个Skill里有一半是自写的，另一半是长期维护的成熟项目，基本不用操心。
最后分享一个我一直在用的小技巧：每季度做一次Skill审计。把过去90天的调用记录拉出来，按调用次数排序，末尾20%的Skill直接禁用观察。这个习惯帮我避免了“Skill仓库”变成“Skill垃圾场”。你不需要一次删到位，但需要定期清理——就像整理衣柜一样，不穿的衣服占着位置，真正常穿的那几件反而找不到。 |