1. 从“装了一堆”到“删掉八成”：一个真实的能力管理复盘
“Claude Code 装了一堆 Skill，用了三个月，我删掉了 80%”——这句话我第一次看到的时候，心里咯噔一下，因为我自己也经历过几乎一模一样的曲线。刚开始接触 Claude Code 的 Skill 机制时，那种感觉就像突然拿到了一整面墙的工具箱，看到什么 Skill 都想装：写代码的、写文档的、做测试的、整理笔记的、甚至还有专门用来“去 AI 味”的。装完之后看着~/.claude/skills目录里密密麻麻的文件夹，心里特别踏实，觉得自己的 AI 工作流已经武装到牙齿了。
结果三个月之后，我打开那个目录，一个一个往下翻，最后真正留下来的不到两成。剩下的要么是装了从来没用过，要么是用了一两次发现还不如直接跟模型对话来得快，要么是几个 Skill 功能高度重叠、互相打架。删完之后我反而觉得整个工作流清爽了很多，响应速度也上来了，模型选对 Skill 的准确率明显提高。
这篇文章就是把这三个月踩过的坑、删掉的逻辑、留下来的标准，完整地拆一遍。如果你正在用 Claude Code，或者刚接触SKILL.md、npx skills这套机制，正在纠结“到底该装哪些 Skill”，那这篇内容应该能帮你少走不少弯路。我会从 Skill 的底层机制讲起，说清楚它为什么会被加载、为什么会互相干扰、什么样的 Skill 值得留、什么样的应该果断删，最后给出一套我自己在用的精简清单和维护方法。
核心关键词先摆出来：Claude Code、Skill、SKILL.md、npx skills、settings.json。这几个东西构成了整个 Skill 体系的骨架，后面所有讨论都围绕它们展开。
2. Skill 机制到底是怎么工作的：先搞懂原理再谈取舍
2.1 SKILL.md 不是插件，是“按需加载的说明书”
很多人对 Skill 的第一个误解，就是把它当成传统意义上的“插件”或者“扩展”。插件通常是常驻的、被动触发的，装了就在那里运行。但 Claude Code 的 Skill 完全不是这个逻辑。
一个 Skill 的本质，就是一个放在特定目录下的文件夹，里面至少有一个SKILL.md文件。这个文件用 YAML frontmatter 加 Markdown 正文的格式写成，frontmatter 里声明这个 Skill 的名字、描述、什么时候该用；正文里写具体的操作指令、步骤、注意事项。模型在启动的时候，并不会把所有 Skill 的正文全部读进上下文，它只读每个 Skill 的元数据——也就是名字和描述那一小段。
真正决定一个 Skill 会不会被“激活”的，是它的描述写得够不够精准，以及当前对话的任务跟这个描述匹不匹配。匹配上了，模型才会去读SKILL.md的完整正文，然后按照里面的指令干活。这个机制叫渐进式披露（progressive disclosure），是 Skill 体系最核心的设计。
理解这一点非常关键，因为它直接解释了为什么“装太多”会出问题：每个 Skill 的元数据都会占用上下文窗口的一小部分，装几十个 Skill，光是这些描述就吃掉了一大块上下文，模型在判断“该用哪个”的时候也更容易选错。
2.2 npx skills 装的是什么，settings.json 管的是什么
npx skills这个命令做的事情，本质上就是把某个 Skill 的文件夹下载或者链接到你的本地 Skill 目录里。常见的目录位置是用户级的~/.claude/skills，或者项目级的.claude/skills。项目级的优先级更高，适合那种只在这个项目里用的 Skill；用户级的全局生效，适合通用能力。
而settings.json管的是更上层的配置：模型选哪个、权限怎么开、哪些工具允许自动执行、环境变量怎么传。Skill 本身不直接改settings.json，但 Skill 里如果要用到某些命令或者工具，就得确保settings.json里的权限配置允许它跑。我踩过的一个坑就是：装了一个需要执行 shell 命令的 Skill，结果因为权限没开，模型每次调用都被拦下来，最后只能手动去改配置。
所以这三者的关系可以这样理解：settings.json是总闸，npx skills是安装工具，SKILL.md是每个 Skill 的说明书。装之前先想清楚总闸开没开、说明书写的场景是不是你真的会遇到的，比无脑装一堆要重要得多。
2.3 为什么“装得多”反而会变笨
这里我要展开讲一个很多人没意识到的点。假设你装了 40 个 Skill，每个 Skill 的描述平均 30 个 token，那就是 1200 个 token 常驻在上下文里。听起来不多，但问题是模型每次都要在这 40 个选项里做一次“路由判断”：当前这个任务，到底该不该触发某个 Skill，触发哪一个。
选项越多，判断越容易出错。我实测下来，当 Skill 数量超过 20 个之后，模型开始出现几种典型症状：该用 Skill 的时候不用，直接凭自己的知识回答了；或者用错了 Skill，把 A 场景的指令套到 B 场景上；再或者同时激活两三个功能重叠的 Skill，指令互相冲突，输出变得四不像。
这就像你给一个新人助理塞了 40 本操作手册，每本都告诉他“遇到 X 情况翻我”，结果他遇到问题的时候光翻目录就翻晕了。删掉 80% 之后，剩下的都是高频、边界清晰、互不重叠的，模型反而能稳定命中。
3. 我删掉的 80% 都是些什么：四类典型的“该删 Skill”
3.1 第一类：描述模糊、边界不清的“万能 Skill”
这类 Skill 的特征是描述写得特别宽泛，比如“帮助处理各种编程任务”“提升写作质量”“辅助日常办公”。看起来什么都能干，实际上什么都不精。模型看到这种描述，很难判断到底什么时候该触发它，结果就是要么永远不触发，要么在不该触发的时候乱触发。
我删掉的一个典型例子是一个号称“通用代码助手”的 Skill，描述里写着“适用于各种编程语言和场景”。问题是 Claude Code 本身就已经是很强的编程助手了，这个 Skill 并没有提供任何额外的、具体的价值，只是把一些通用建议包装了一遍。留着它，除了占上下文、增加路由噪音，没有任何实际收益。
判断标准很简单：如果一个 Skill 的描述，你没法用一句话说清楚“它在什么具体场景下、解决什么具体问题”，那它大概率就是该删的。
3.2 第二类：功能高度重叠的“近亲 Skill”
这是最容易堆积的一类。比如你可能同时装了三个都跟“代码审查”相关的 Skill，两个都跟“写测试”相关的 Skill，四个都跟“文档生成”相关的 Skill。它们各自单独看都还行，但放在一起就是灾难。
我自己的目录里曾经同时存在两个“提交信息生成”Skill，一个偏 Conventional Commits 风格，一个偏自由描述风格。结果每次提交的时候，模型有时候用这个、有时候用那个，提交历史风格完全不统一。后来我只留了一个，把另一个里我觉得好的几条规则合并进去，问题立刻消失。
处理这类 Skill 的方法不是简单删掉多余的，而是先做一次功能归并：把重叠的 Skill 列出来，对比它们的指令，找出真正有价值的差异点，合并成一个“集大成”的版本，然后删掉其余的。这样既保留了能力，又消除了冲突。
3.3 第三类：低频到几乎用不上的“收藏品 Skill”
这类 Skill 的特点是：装的时候觉得“哇这个好酷，以后肯定用得上”，结果三个月过去一次都没触发过。比如各种特定框架的迁移工具、特定格式的转换器、特定领域的专业助手。
我删掉的一个例子是一个专门处理某种冷门配置文件格式的 Skill。当时装它是因为手上正好有个项目用到，但那个项目结束后，这个 Skill 就再也没被碰过。它静静地躺在目录里，每次启动都在消耗上下文，却从来不产生价值。
这里有个很实用的判断方法：翻一下你的对话历史或者使用记录，看看每个 Skill 在过去一个月里被触发过几次。触发次数是 0 或者 1 的，基本可以无脑删。真正高频的 Skill，一周内就会被触发好几次。
3.4 第四类：指令质量差、反而拖后腿的“负资产 Skill”
这一类最隐蔽，也最该删。有些 Skill 的SKILL.md写得非常粗糙，指令含糊、步骤跳跃、甚至包含过时或者错误的做法。模型一旦触发它，不但不会提升输出质量，反而会被带偏。
我遇到过一个 Skill，它的指令里要求“总是先输出一段解释再给代码”，但我在很多场景下其实只想要代码。这个 Skill 一旦被触发，就会强行改变我的输出格式，非常烦人。还有一个 Skill 的指令里引用了已经不存在的命令，触发后直接报错。
这类 Skill 的危害在于，它们不只是“没用”，而是“有害”。它们会污染模型的判断，让本该干净利落的输出变得拖泥带水。删掉它们，是提升整体体验最直接的手段。
4. 留下来的 20% 长什么样：精简 Skill 的四个标准
4.1 标准一：场景高频且具体
留下来的 Skill，第一个共同点就是使用频率高，而且触发场景非常具体。比如我有一个专门用来“生成规范的 Git 提交信息”的 Skill，几乎每天都要用，触发条件也很明确——只要我说“帮我提交”或者“写个 commit”，它就会稳定命中。
高频意味着它值得占用那部分上下文；具体意味着模型不会误触发。这两点结合起来，就是一个 Skill 值得留下的基本盘。反过来，那些一个月都用不上一次、或者触发条件模糊的，就没有留下的理由。
4.2 标准二：指令精准、可执行、无歧义
留下来的 Skill，SKILL.md的正文质量都很高。指令写得像一份清晰的操作清单：第一步做什么、第二步做什么、遇到什么情况怎么处理、输出格式是什么样。没有模棱两可的表述，没有“视情况而定”这种让模型自由发挥的空间。
我自己的做法是，每留下一个 Skill，都会花时间把它的SKILL.md重新过一遍，把含糊的地方改具体，把多余的步骤删掉，把输出格式固定下来。一个打磨过的 Skill，价值远高于十个粗糙的 Skill。
4.3 标准三：与内置能力形成互补而非重复
Claude Code 本身已经具备很强的通用能力，所以留下来的 Skill 必须是“内置能力覆盖不到”或者“内置能力做得不够好”的部分。比如内置能力可以写代码，但可能不熟悉你们团队特定的代码规范；内置能力可以写文档，但可能不知道你们公司的文档模板长什么样。
这种“补位”性质的 Skill 才是真正有价值的。它们把团队的、个人的、特定领域的知识固化下来，让模型每次都能按照你的标准来干活。而那些只是把通用能力重新包装一遍的 Skill，删掉毫无损失。
4.4 标准四：维护成本低、不容易过时
最后一个标准是维护成本。有些 Skill 依赖特定的外部工具、特定的版本、特定的路径，一旦环境变了就失效。这类 Skill 维护起来很累，而且很容易在你不知情的情况下变成“负资产”。
留下来的 Skill 最好是那种“自包含”的——指令里不依赖太多外部假设，即使环境有变化，稍微改几个字就能继续用。我现在的习惯是，每季度做一次 Skill 审查，把那些需要频繁维护的、依赖外部状态的 Skill 标记出来，评估是否值得继续留。
5. 实操：如何系统性地清理和重建你的 Skill 库
5.1 第一步：盘点现状，导出所有 Skill 清单
清理的第一步是搞清楚自己到底装了什么。Skill 通常放在~/.claude/skills或者项目的.claude/skills目录下，每个 Skill 是一个子文件夹，里面至少有一个SKILL.md。你可以用一条命令把所有 Skill 的名字和描述列出来：
for dir in ~/.claude/skills/*/; do echo "=== $(basename "$dir") ===" head -20 "$dir/SKILL.md" 2>/dev/null | grep -A2 "description:" done这条命令会遍历每个 Skill 目录，打印出名字和描述的前几行。把输出保存到一个文件里，你就得到了一份完整的清单。看着这份清单，你大概就能感觉到哪些是熟悉的、哪些是陌生的——陌生的那些，基本就是该删的。
5.2 第二步：按使用频率打标签
接下来给每个 Skill 打一个使用频率标签。最准确的方法是翻使用记录，但如果没有记录，就凭记忆估：高频（每周都用）、中频（每月用几次）、低频（几乎不用）、从未用过。
我自己的经验是，凭记忆估出来的结果往往偏乐观——你会觉得某个 Skill “应该会用”，但实际上从来没用过。所以更靠谱的做法是，给自己定一个观察期，比如两周，在这两周里刻意留意每次触发的是哪个 Skill，两周后统计一次。数据比感觉可靠得多。
5.3 第三步：合并重叠，删除冗余
打完标签之后，把“低频”和“从未用过”的直接删掉。然后处理“中频”里功能重叠的部分：把几个功能相近的 Skill 的SKILL.md放在一起对比，找出各自的独特指令，合并成一个统一的版本。
合并的时候要注意，不要简单地把所有指令堆在一起，那样会让 Skill 变得臃肿、触发后输出冗长。正确的做法是提炼出真正有价值的、不重复的规则，用清晰的步骤组织起来。合并完成后，删掉原来的多个 Skill，只留合并后的那一个。
5.4 第四步：重写保留下来的 Skill 的 SKILL.md
对于决定保留的 Skill，花时间把SKILL.md重写一遍。重点改三处：把描述写得更精准，让触发条件更明确；把正文指令写得更具体，减少模型的自由发挥空间；把输出格式固定下来，保证每次结果一致。
一个写得好的SKILL.md，frontmatter 里的 description 应该能让人一眼看出“这个 Skill 在什么场景下用”，正文应该像一份 checklist，模型照着做就不会错。我通常会把 description 控制在两三句话以内，正文控制在几十行以内，太长反而会让模型抓不住重点。
5.5 第五步：用 settings.json 控制权限和加载范围
最后一步是检查settings.json的配置。确保保留下来的 Skill 需要的权限都开了，不需要的权限关掉，减少安全风险。如果有些 Skill 只在特定项目里用，就把它们放到项目的.claude/skills目录下，而不是全局目录，这样其他项目就不会被它们干扰。
settings.json里跟 Skill 相关的配置主要是权限部分，比如允许执行哪些命令、允许访问哪些路径。我的原则是“最小权限”：只开 Skill 真正需要的权限，多一个都不开。这样即使某个 Skill 的指令有问题，也不会造成太大的影响。
6. 常见问题与排查技巧实录
6.1 Skill 装了但从来不触发怎么办
这是最常见的问题。原因通常有三个：描述写得太模糊，模型判断不出该不该用；触发场景跟你实际的工作流不匹配；或者 Skill 数量太多，模型在路由时把它漏掉了。
排查顺序是：先看描述，能不能用一句话说清楚“什么时候用”；再看场景，你实际遇到这个场景的频率高不高；最后看数量，如果 Skill 超过 20 个，先删一批再看。我遇到的大部分“不触发”问题，删掉一批冗余 Skill 之后就自动解决了。
6.2 多个 Skill 同时触发、指令打架怎么办
这说明你有功能重叠的 Skill。模型看到当前任务同时匹配了好几个 Skill 的描述，就把它们都激活了，结果指令互相冲突。解决办法就是前面说的合并：找出重叠的 Skill，合并成一个，删掉其余的。
如果合并之后还是偶尔出现冲突，可以在保留下来的 Skill 的 description 里加一句排他性的说明，比如“仅当没有其他更具体的 Skill 适用时使用本 Skill”。这样能降低误触发的概率。
6.3 Skill 触发后输出格式不对怎么办
这通常是SKILL.md正文里没有把输出格式写死。模型在格式上有很大的自由发挥空间，你不明确规定，它就每次都不一样。解决办法是在正文里加一段明确的输出格式说明，最好给一个模板或者示例。
比如你要一个固定的提交信息格式，就在 Skill 里写清楚：第一行是类型加范围，第二行空行，第三行开始是正文，每行不超过多少字。写得越具体，输出越稳定。
6.4 删掉 Skill 之后会不会丢失能力
不会。Skill 本质上是把一些指令固化下来，删掉之后，你随时可以重新装回来，或者直接在下一次对话里把那些指令手动告诉模型。真正有价值的知识，应该沉淀在你的笔记或者文档里，而不是只存在于某个 Skill 文件夹里。
我删掉 80% 的 Skill 之后，唯一的感觉是工作流更顺了，没有任何能力上的损失。反而因为上下文更干净，模型的表现更稳定了。
6.5 常见问题速查表
| 问题现象 | 最可能的原因 | 排查动作 |
|---|---|---|
| Skill 从不触发 | 描述模糊或数量过多 | 精简描述，删减总数 |
| 多个 Skill 打架 | 功能重叠 | 合并重叠 Skill |
| 输出格式不稳定 | 正文未固定格式 | 补充格式模板 |
| 触发后报错 | 权限未开或依赖缺失 | 检查 settings.json |
| 响应变慢 | Skill 元数据占用过多 | 清理低频 Skill |
7. 我个人的精简清单与长期维护习惯
7.1 目前保留的几类 Skill
删完之后，我保留的 Skill 大致分三类。第一类是规范固化类，比如提交信息生成、代码风格检查，这类 Skill 把团队的规范写死，保证每次输出一致。第二类是流程编排类，比如“从需求到测试用例”的完整流程，这类 Skill 把多步骤的操作串起来，减少我手动指挥的次数。第三类是领域知识类，比如特定业务领域的术语和规则，这类 Skill 让模型在专业场景下不至于说外行话。
这三类的共同点是：高频、具体、互补、低维护。每一类我最多留两三个，总数控制在十个以内。这个数量下，模型的路由判断非常稳定，几乎不会出现误触发或者漏触发。
7.2 每季度做一次 Skill 审查
我现在养成了一个习惯，每个季度花半小时做一次 Skill 审查。流程很简单：列出所有 Skill，看过去三个月里每个被触发过几次，把零触发的删掉，把低频的标记出来观察，把高频的检查一下SKILL.md有没有需要更新的地方。
这个习惯的价值在于，它能防止 Skill 库重新膨胀。人的天性就是看到新东西就想装，没有定期清理的机制，三个月后又会回到“装了一堆”的状态。审查就是给这个膨胀趋势踩刹车。
7.3 新 Skill 的准入原则
现在我再装新 Skill 的时候，会先过三道关。第一关：这个场景我一个月内会遇到几次？低于三次的，不装。第二关：现有的 Skill 能不能覆盖？能覆盖的，不装。第三关：它的SKILL.md质量怎么样？描述模糊、指令粗糙的，不装。
过了这三关才装进来，装进来之后还要观察两周，两周内没触发过的，直接删。这套准入原则执行下来，我的 Skill 库一直保持在一个精简、高效的状态。
7.4 一个容易被忽略的细节：Skill 的命名
最后分享一个很小的细节，但影响挺大：Skill 的命名。名字起得越具体、越能反映它的触发场景，模型判断起来就越准。比如“commit-message”就比“git-helper”好，“api-test-generator”就比“testing”好。名字是模型做路由判断时看到的第一信息，值得多花几分钟想清楚。
我现在的命名习惯是“场景-动作”结构，比如“review-code”“gen-commit”“write-doc”。这样一眼就能看出它是干什么的，模型也不容易搞混。这个细节看起来不起眼，但在 Skill 数量多的时候，好的命名能显著降低误触发的概率。
三个月前我装了一堆 Skill，三个月后我删掉了 80%。这个过程不是能力的损失，而是能力的提纯。留下来的每一个 Skill 都是真正高频、真正有用、真正互补的。如果你也在经历“装了一堆但用不明白”的阶段，不妨按上面的方法清理一遍，你会发现，少即是多这句话在 Skill 管理上体现得淋漓尽致。
