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 标准二指令精准、可执行、无歧义留下来的 SkillSKILL.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.mdfrontmatter 里的 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 元数据占用过多清理低频 Skill7. 我个人的精简清单与长期维护习惯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 管理上体现得淋漓尽致。