1. 我先说结论：只留下那些“被调用过”的技能
三个月前我给 Claude Code 装了 30 多个 Skill，几乎每天都在装新的；三个月后我删掉了 80%，而 Claude Code 反而变得比之前更顺手。
很多朋友一听到 Skill，第一反应是给 Claude 加点能力，像游戏里安装技能书一样。实际上，Claude Code 的 Skill 是一个偏静态的 Prompt 包：一个 SKILL.md 文件里写清楚使用场景、执行步骤和注意事项，模型在需要时读取它并按流程走。听起来很干净，但当你装了几十个之后，它会变成一个“候选名单”问题——Claude 每次决策“要不要用某个技能”的时候，都要去扫一遍这些列表，而列表里那些描述写得模棱两可的人，就是误触发的来源。
1.1 我当时到底装了多少
先交代背景：我日常用 Claude Code 做的东西比较杂，前端项目维护、文档整理、小工具脚本、偶尔写点数据处理脚本。当时看到 GitHub 上有各路大神整理的 Skill 合集，或者看到别人发的“一个 Skill 让 Claude 自动做某件事”的帖子，就会顺手装一个。当时觉得这不就是给 Claude 加能力吗，多一点总不会有坏处。
结果到了第三个月，~/.claude/skills/下面挂了几十个目录，名称五花八门：有的负责生成日报，有的负责整理周报模板，有的叫 book-to-skill，有的叫 workbuddy，还有 AI 备课、科研绘图、项目复盘之类的。最离谱的是我装了两个功能几乎一模一样的技能，一个是“把 Markdown 表格转成 JSON”，另一个是“从文档里提取结构化数据”——名字不一样，描述差不多，实际能干的活也高度重合。
1.2 删除后最明显的变化
删除前的工作状态是：经常会看到一个技能被无关任务误触发。比如我正在改一个前端组件，Claude Code 突然开始按某个 Skill 的模板走“项目复盘”流程，搞得我一脸懵。问题不全怪 Skill 本身，而是在我的命令行环境里，同时存在太多“描述模糊、适用范围太宽”的技能，Claude 在选择要不要调用技能时，很容易被这类泛泛的描述带偏。
删掉那 80% 之后，最直观的变化有两个。第一，误触发明显变少，对话里不再出现那种“插进来一段不应该存在的固定流程”。第二，输出的稳定性提升了，以前偶尔会在毫无必要的场景下套用什么格式模板，现在干净多了。如果只看功能覆盖，我觉得删掉的技能没有一个是“必需”的——那些真正重要的能力，要么可以用几行提示词做到，要么本来就应该走 MCP 插件或项目里的规范配置。
2. 那些被删掉的技能长什么样：三类典型的“假需求”
与其拍脑袋说“Skill 没用”，不如先复盘一下我删掉的东西到底是什么。真正没用的不是机制，而是我当时对“什么时候该用技能”完全没有判断。现在回头看，被删掉的基本可以归成三类。
2.1 被一学就会、用完即弃的“一次性任务型技能”
第一类最好认：来自某个教程或者灵感，但你实际上根本没有稳定的流程需要定期重复。举个例子，我装过一个“AI 备课”方向的 Skill，当时想的是以后可以帮我把课程大纲转成讲义文本。结果三个月里一次都没用过，因为我根本不是老师，只是偶尔帮朋友整理一次材料。那一次整理材料我用普通对话就完成了，技能反而帮不上忙。
“科研绘图”和“每周读书笔记”也属于这一类。它们本身写得不错，但本质上只是把你的一个想法包装成了固定流程。如果没有每星期、每天都稳定出现的重复任务，这种技能就是“自我安慰型资产”：装完以后觉得很充实，实际调用的次数一只手数得过来。真正需要它们的那一回，临时写一段提示词完全来得及。
2.2 和 MCP 插件重复、只是换个马甲的技能
第二类更隐蔽：和 MCP 插件或现有项目配置高度重复。Claude Code 支持加载 MCP 服务器，也支持通过/plugin安装插件。有些能力交给 MCP 更合适，比如联网搜索、调用某些外部 API、读取本地数据库。但如果你用一个 Skill 去描述“你应该怎样使用 Web 搜索”或“你应该怎样调用某 API”，那效果往往没有专门的 MCP 工具好，因为技能只是文字指令，它不会自己变成工具。
我删掉过一个“网页搜索”的 Skill。当时我很迷信它里面写的搜索步骤，以为让它“一步步先搜索再汇总”就能得到稳定结果。后来发现同一个网络搜索 MCP 服务已经配好了，Skill 还要额外占用上下文，描述还容易和默认行为打架。两相对比，MCP 更透明，参数可控，响应也稳定。
同理，我装过一个“读取并分析本地 CSV”的技能，但项目里本来就有很成熟的数据处理脚本，直接调用python脚本比让 Claude 按 SKILL.md 的流程绕一圈更可靠。这种技能存在的意义，就是给“明明可以直接跑脚本”增加一层中间人。
2.3 定义模糊，反而造成误触发的技能
第三类是最应该警惕的，也是我删除的时候最果断的。有些 SKILL.md 的description写得特别宽泛，比如“帮助用户完成各种写作任务”“帮助优化代码结构”“帮助整理项目信息”。听上去无所不能，但 Claude Code 调用技能的判断依据就是description和当前任务的匹配度。一个描述得事事都可能匹配的技能，在大量无关任务中都会被盯上。
我就有一个定位类似 workbuddy 的技能，description 写着“帮助用户处理日常工作流中的各种任务，提供高效的工作方法”。这句话等于没说。结果就是我在写代码的时候它跑出来，我在整理文档的时候它跑出来，我甚至在调试报错的时候它也要凑上来。最后我删掉它，拿那段工作流里真正需要的固定流程重新写了一个窄口径技能。
3. 删与留的评判框架：四条标准足够用
删掉那么多之后，我最大的收获是一套判断标准。以后再遇到一个 Skill，我不会先想“它有没有用”，而是先想“它值不值得长期住在我这里”。这套标准就四条。
3.1 调用频率：看日志而不是看感觉
去留判断的第一条，是看真实的调用频率，不要凭“我当时装它的时候觉得它很重要”。我翻了 Claude Code 的项目会话记录，把过去一个月真的被触发过的 Skill 列出来。那些一次都没出现过的，先进入待删区。
有人可能会说，一次都没出现不代表没用，也许只是没遇到合适的任务。我的观点正好相反：一个技能如果一个月内连一次被调用的机会都没有，那说明你对它的需求要么不存在，要么你早就不需要了。真有需要的时候再写也不迟，而且是重新写一个，比维护一个不知道自己什么时候会用的技能要轻松得多。
3.2 任务结构：可重复流程才值得做成技能
第二条标准，是判断这个任务有没有“固定的流程结构”。技能的本质是把一个可以稳定重复的做事方法固化下来，比如“按照公司模板输出项目周报”这种每个星期一都要做的事。这类任务适合做成 SKILL.md，因为你不必把十几条规则反复粘进提示词。
反过来，那些“帮我看看这个报错到底怎么回事”“帮我把这段文字改得更流畅”之类的任务，没必要做成技能。它们是开放性的，没有固定步骤，每次需要的输入输出都不一样。你把它做成技能，反而是给 Claude 套上了一条僵硬的裤子，它还得花 token 去理解什么是你的意图。
我留下了一个用来生成 changelog 的技能。它每周都会被调用两三次，而且规则非常固定：从 git log 里提取 commit，按类型归类，再按版本号汇总。这类任务太适合技能了，拆成描述和步骤模板后，输出稳定而且几乎不用改。
3.3 维护成本：SKILL.md 的篇幅就是长期税
第三条是维护成本。SKILL.md 越写越长，不代表越有价值，反而说明你可能把一个本可以直接在提示词里写清楚的事情复杂化了。我的经验是，如果装好之后还要反复修改里面的步骤才能用，那就说明这个任务对你来说还没有稳定到适合做成技能。
有个我删掉的“数据整理”技能，内容长达两千多行，里面甚至还有调用外部脚本的多种分支。我每次用都要先看它文档，否则不知道应该怎么配合。后来我干脆把最核心的那段流程压缩成一个两百行的 SKILL.md，其余全部删掉。效果比以前好，原因很简单：Claude 加载和执行的前提是文本尽量短、步骤尽量少，指令越精确，被误解的风险越小。
3.4 触发范围：描述写得越窄越不容易闯祸
第四条标准，也是最容易被忽略的：YAML front matter 里的description字段。别把它当成简介写，它是触发条件。一个描述如果包含“各种”“任意”“综合”“高效”这类词，几乎注定会误触发。
我留下的技能，description 都刻意写得窄。比如生成 changelog 的技能，描述写成这样：
--- name: changelog description: 仅当用户明确要求生成 changelog 或更新版本变更记录时使用。其他情况一律忽略。 ---听起来有点啰嗦，但实际效果是它被触发的次数大幅减少，而且触发的时机基本都对。真正好用的技能，不是什么都懂，而是知道自己什么时候不该出现。
4. 删除动作背后的两个坑：依赖残留与配置残留
按常识，删除一个技能好像是删掉一个文件夹的事。但 Skill 在实际使用里不是孤岛，特别是那些从第三方仓库安装的，往往还会依赖本地脚本、虚拟环境里的依赖、自定义 hook 或其他插件。我删第一波技能的时候，就吃过一次大亏。
4.1 坑一：技能不是独立的，删了技能断了插件
我发现有一个“文档转换”技能删掉之后，项目里的图片压缩脚本也跟着报错了。查了半天才明白，这个技能安装的时候把一个小工具链写进了项目的scripts/目录，而 SKILL.md 只是它的说明书，真正干活的是那些外部脚本。
所以我的建议是删除之前，先顺着 SKILL.md 里的引用把所有关联文件摸一遍。重点看它有没有写到.claude/hooks/、有没有在settings.json里注册什么东西、有没有依赖某个 MCP server。如果依赖了，而且你还想保留这个依赖，那就把依赖单独提出来，不要跟着技能一起删。
4.2 坑二：安装脚本会在 settings.json 和 CLAUDE.md 里留残渣
第二个坑更隐蔽。很多 Skill 是通过一键安装脚本进的系统，安装器不会只往~/.claude/skills/里放文件，它还会顺手改其他配置。比如在~/.claude/settings.json里加入一些环境变量，或者在项目的CLAUDE.md里追加几行“项目规范”，甚至在.claude目录里注册 hook。
这样导致一个结果：你以为把 skill 目录移除了，但实际上 Claude Code 启动时还是会读到那些残留配置，行为并不会完全恢复。我删完以后跑claude --debug才发现，某些早该消失的指令还在上下文里。
删除前我养成了一个习惯：在所有被删技能可能触过的配置里做一次全文搜索。搜关键词就用技能名和描述里出现的独特单词，比如：
grep -rn "workbuddy" ~/.claude/ 2>/dev/null grep -rn "workbuddy" .claude/ 2>/dev/null搜出来的每一处都看一下，如果确认是安装器留下的，就手动清理。这一步不能省，省了之后你就不知道自己到底还开着多少后门。
4.3 记录清理步骤：先禁用，再删除
我把整个清理流程变成了一张半自动化清单，每次都照着走：
- 先把要删的技能目录移动到一个
_disabled/文件夹，而不是直接rm。这样万一发现误删还能恢复，Claude Code 也只读取skills/下的目录，不会把_disabled/里的东西当成技能。 - 搜索所有配置文件，排除可见的引用。命令行用的是
grep，Windows 上也可以用rg，或者直接在编辑器里全局搜。 - 重启一次 Claude Code 会话，开启
--debug日志，确认启动时加载的技能列表已经不含目标技能。 - 把项目里最常见的三个任务各跑一遍，观察有没有出现“缺少某指令”“行为异常”“退出码报错”这类情况。
也许你会觉得第四步太麻烦，但我在实际删的过程中就是这么走过来的。前两轮没有跑功能回归，删完没过多久就发现有些流程开始不对，最后又要翻回来查依赖。第三轮老老实实按这套走，总算一次干净。
5. 清理之后，我现在如何维护和管理技能
删掉 80% 之后，我现在对技能的管理方式也彻底变了。以前的思路是“多装点扩展”，现在的思路是“少放点东西进来”。
5.1 数量红线：全局技能不超过六个，项目技能就近放
现在我对全局技能的数量有一个明确红线：全局~/.claude/skills/目录下最多只有六个。超过这个数，多出来的必然要么是重复，要么是低频，要么是描述过宽。全局技能应该是你最核心、每周都在用的工作流，而不是一股脑塞进去的功能库。
项目级的技能则放进项目自己的.claude/skills/目录，跟项目一起走，不会污染其他项目。比如某个项目长期要做特定格式的日志检查，我就会只在这个项目里加一个对应技能。项目克隆到别的机器，技能也跟着项目走；项目不做了，删除项目文件夹，技能也不会残留在全局环境里。
5.2 新增技能的“冷静期”流程
现在我再看到一篇很有启发的 Skill 文章，不会直接装。我把它收藏到一个临时笔记里，先想想：过去一个月，我有没有遇到过三次以上需要这件事的场景？如果有，再评估它是不是已经有现成的 MCP 插件或脚本能完成。如果两个答案都指向“需要”，我才会创建一个轻量版本放进项目技能文件夹里，先试用两周，两周内如果一次都没调用，就直接删除。
这个冷静期流程帮我挡掉了至少十个“看起来不错但根本不适合我”的技能。本质上，它把“装技能”这个动作从消费行为变成了投资行为：你不是在看一个好东西，而是在决定要不要给自己的工作流增加一个长期维护项。
5.3 定期复盘节奏和日常使用建议
现在的维护节奏也很简单：每个月做一次半小时的技能体检，打开~/.claude/skills/和项目里的.claude/skills/，看一遍调用频率、SKILL.md 篇幅、description 是否仍然贴合当前任务。凡是回答不了“最近用它做了什么”的技能，直接进_disabled/。
我现在不再追求技能库的数量了，反而觉得，能在一个干净环境里随手写一段提示词，比从一个庞大目录里翻技能更快。删掉八成技能之后，最大的收获不是省了多少 token，而是我终于能看清 Claude Code 到底在为什么任务消耗注意力。只有当你砍掉那些“看起来有用”的冗余，留下来的东西才会被真正频繁使用。
