1. 从装了一堆到删掉八成Skill 泛滥的真实代价三个月前我的 Claude Code 里塞了四十多个 Skill现在只剩八个。这个数字不是拍脑袋定的是我一个个用下来、一个个删出来的结果。如果你也正在经历看到好用的 Skill 就想装的阶段那这篇东西大概率能帮你省下不少折腾的时间。先说清楚 Skill 到底是什么。在 Claude Code 的体系里Skill 本质上是一个带SKILL.md描述文件的目录里面可以放脚本、模板、参考文档Claude 在合适的时机自动加载并调用它。它跟普通的 prompt 模板不一样——Skill 是能力包是让 Claude 在特定场景下多出一套可执行动作的东西。你可以把它理解成给一个通用助手装插件装对了它在你这个领域立刻变专业装多了它反而不知道该听谁的。我最初的心态很典型看到有人分享这个 Skill 写周报绝了装看到这个 Skill 能自动整理会议纪要装看到这个 Skill 做代码审查特别细装。装到后来我打开 Claude Code 输入一个请求它有时候会同时命中三四个 Skill 的描述然后开始做一件我没让它做的事。最离谱的一次我只是想让它帮我改一段文案它却调用了某个文档结构化的 Skill把整段话拆成了带标题的列表——完全不是我要的。这就是 Skill 泛滥的第一个代价触发冲突。每个 Skill 的SKILL.md里都有一段 descriptionClaude 靠这段描述判断当前任务要不要用这个 Skill。当你的 Skill 数量超过一定阈值描述之间的语义重叠就会变多Claude 的匹配就会变得不稳定。你以为装的是能力实际上装的是干扰。第二个代价更隐蔽上下文挤占。Skill 不是凭空生效的它的描述、它的附属文件、它被调用后产生的中间内容都会占用上下文窗口。我做过一个粗略的对比同样一段两千字的代码审查任务在只装三个 Skill 的环境下Claude 能完整读完文件并给出逐行建议在装了二十多个 Skill 的环境下它经常读到一半就开始总结性发言因为上下文被 Skill 的元信息吃掉了一部分。第三个代价是维护成本。Skill 会过期。你依赖的某个脚本路径变了、某个 API 的返回格式改了、某个模板的字段对不上了这个 Skill 就从帮手变成坑。四十多个 Skill我每个月至少要花两三个小时去排查为什么这个 Skill 今天不工作了。删到八个之后这部分时间基本归零。所以删掉 80%不是一个断舍离的姿态而是一次基于实际使用数据的清理。下面我把这个过程拆开讲包括我怎么判断一个 Skill 该不该留、留下来的八个是什么类型、以及如果你现在 Skill 还不多应该怎么从一开始就避免踩这个坑。2. 我是怎么给 Skill 做使用率审计的2.1 先别急着删先记录两周的真实调用很多人一冲动就开始删 Skill删完发现某个 Skill 其实每周都在用只是自己没意识到。我的做法是先做两周的调用记录不做任何删减。具体操作很简单在 Claude Code 的会话里每次它调用了某个 Skill我就在一个本地 markdown 文件里记一笔格式就是日期 | Skill 名称 | 任务类型 | 是否有用。两周下来我拿到了四十多个 Skill 的真实调用数据。结果很打脸有二十三个 Skill 在这两周里一次都没被触发过有九个只触发了一两次而且效果一般真正高频使用的只有六个。这里有个细节要注意没被触发和没被需要是两回事。有些 Skill 你可能确实需要但因为它的 description 写得不好Claude 根本没匹配上。所以我在记录的时候会额外标注一列我是否主动想过要用它。如果某个 Skill 我一次都没想过要用那它大概率就是冗余的。2.2 用三个维度给每个 Skill 打分两周数据拿到之后我给每个 Skill 按三个维度打分每个维度 1 到 5 分维度含义打分依据触发准确率该触发时是否触发不该触发时是否安静误触发多则低分结果可用度调用后产出是否直接能用需要大量返工则低分不可替代性去掉它之后是否有别的 Skill 或原生能力能顶上能被替代则低分三项加起来低于 9 分的直接进删除候选。9 到 11 分的进入观察区再留两周看表现。12 分以上的保留。这套打分看起来有点重但实际操作起来一个 Skill 也就一两分钟。四十多个 Skill一个下午就能过一遍。关键是它把我觉得这个 Skill 挺好这种模糊判断变成了可比较的数字。2.3 删除不是终点归档才是我删 Skill 的方式不是直接rm -rf而是把它们移到一个_archived_skills目录里。原因很简单有些 Skill 是季节性的比如季度总结模板这种平时用不上但到了季度末你就想它了。归档而不是删除既清理了活跃环境又保留了后悔药。归档目录不参与 Claude Code 的 Skill 加载所以它不会造成触发冲突和上下文挤占。等真的需要的时候把对应目录移回 skills 目录就行。我现在的归档目录里有三十多个 Skill三个月里我只从里面捞回来过两个。提示归档时建议在目录名前面加上归档日期比如20250115_quarterly-report这样半年后你还能判断这个 Skill 是不是已经过时了。3. 留下来的八个 Skill分别解决了什么问题删完之后剩下的八个我按功能分成了四类。这里不是让你照抄我的清单而是让你看清楚什么样的 Skill 值得长期留着。3.1 代码类只留了两个一个是代码审查 Skill它的核心价值是有一套固定的检查清单——空指针、边界条件、错误处理、日志埋点每次审查都按这个清单走不会漏项。另一个是提交信息生成 Skill它读取git diff然后按团队规范生成 commit message。这两个的共同点是规则明确、输出格式固定、我每周至少用五次。我删掉的代码类 Skill 包括自动重构建议依赖升级检查测试用例生成这几个。删它们的原因不是不好用而是它们的能力已经被 Claude 原生能力覆盖了——我不装 Skill直接描述需求Claude 也能做而且做得更灵活。Skill 的价值在于固化流程如果流程本身就不固定那 Skill 反而是束缚。3.2 文档类留了一个模板 Skill文档类我只留了一个就是技术方案模板 Skill。它里面放了我们团队技术方案的标准结构背景、目标、方案对比、选型理由、风险、排期。每次写方案Claude 会按这个结构帮我填充我只需要补内容。删掉的文档类 Skill 有一大堆周报、会议纪要、需求文档、复盘报告……这些被我删掉的原因是它们的结构其实每次都不一样固化成 Skill 之后反而要花时间去改模板。现在我直接用一段简短的 prompt 描述结构效果一样好还更灵活。3.3 数据处理类留了两个一个是CSV 清洗 Skill里面封装了一套固定的清洗步骤去重、空值处理、格式统一、异常值标记。另一个是日志分析 Skill针对我们服务的日志格式做了专门的解析脚本。这两个的共同点是处理逻辑复杂且重复每次手写 prompt 描述清洗规则太累固化成 Skill 之后一句话就能触发。3.4 个人效率类留了三个一个是会议记录整理 Skill把录音转写文本整理成带行动项的纪要。一个是周计划 Skill每周一早上用它把上周遗留事项和本周目标排成计划。还有一个是读书笔记 Skill把划线内容整理成结构化的笔记。这三个之所以留着是因为它们的使用频率极高而且每次的输入输出格式都很稳定。会议记录每周至少三次周计划每周一次读书笔记看阅读量但基本每周都有。高频加稳定就是 Skill 值得留的黄金标准。4. 那些被我删掉的 Skill到底踩了什么坑4.1 看起来很美型描述写得天花乱坠实际用起来鸡肋这类 Skill 最典型的就是各种全能助手。它们的SKILL.md描述里写着可以帮你处理任何文档任务适用于所有编程语言听起来什么都能干实际用起来什么都不精。我删掉的一个通用写作 Skill就是这样它的描述覆盖了文案、报告、邮件、总结结果每次触发之后产出的东西都是四平八稳的套话还不如我直接写 prompt。这类 Skill 的问题在于描述过于宽泛导致触发泛滥。Claude 看到任何文档任务这种描述只要你的请求沾一点边就会调用它然后产出一个通用但无用的结果。判断标准很简单如果一个 Skill 的描述里出现了任何所有通用这类词基本可以判定它不值得留。4.2 重复造轮子型原生能力已经覆盖我删掉的测试用例生成 Skill就是典型。它的逻辑是读取函数签名然后生成对应的测试用例。但 Claude 本身就能做这件事而且做得更好——它会结合函数的实际实现来生成有针对性的用例而不是只看签名。Skill 在这里反而限制了 Claude 的发挥。判断一个 Skill 是不是重复造轮子方法很简单把它删掉然后用一段自然语言描述同样的需求看 Claude 能不能做。如果能做且效果不差那这个 Skill 就没有存在的必要。4.3 配置脆弱型依赖外部路径或接口动不动就挂这类 Skill 通常包含脚本脚本里写死了某个文件路径、某个 API 地址、某个工具的版本。我删掉的一个自动截图 Skill就是这样它依赖一个本地截图工具的特定版本工具一升级Skill 就报错。每次报错我还要去翻它的脚本看问题出在哪维护成本远大于它带来的便利。这类 Skill 的判断标准是过去一个月它有没有因为外部原因失效过。如果有而且失效后你需要花超过十分钟去修那它就不值得留。4.4 低频长尾型一年用两次占着位置添乱这类 Skill 最容易被忽略因为它们确实有用只是用得少。我删掉的年度总结 Skill简历更新 Skill合同模板 Skill都属于这类。它们的问题不在于质量而在于低频 Skill 的触发描述会长期占用上下文而且在你偶尔需要它们的时候你往往已经忘了它们的存在直接手写 prompt 了。对于这类 Skill我的处理方式是归档而不是删除。归档之后它们不再参与加载需要的时候再捞回来。5. 如果你现在 Skill 还不多怎么从一开始就不踩坑5.1 装之前先问三个问题我现在装任何 Skill 之前都会问自己三个问题这个任务我每周至少做一次吗如果频率低于每周一次先不装等真的做了几次再说。这个任务的流程是固定的吗如果每次流程都不一样那 Skill 固化下来的结构反而会碍事。Claude 原生能力做不了吗如果原生能做先不装用一段时间看看到底缺什么。三个问题里有一个答案是否我就不装。这套标准帮我挡掉了至少二十个看起来不错的 Skill。5.2 给 Skill 设一个数量上限我给自己定的上限是十个。超过十个就必须先删一个才能装新的。这个上限的作用不是限制而是强迫我做取舍。当你只能留十个的时候你会认真想这个 Skill 真的比我现在有的那个更好吗而不是无脑装。上限的具体数字因人而异但原则是上限要低于你想装的数量。如果你觉得十个太少那就定十五个关键是有一个明确的数字而不是无限扩张。5.3 定期做Skill 体检我现在每个月最后一个周五下午会花半小时做一次 Skill 体检。流程就是前面说的看调用记录、打分、归档低分 Skill。半小时的投入换来的是下个月更干净的触发环境和更少的维护麻烦。体检的时候有一个容易被忽略的点检查 Skill 的 description 是否还准确。有些 Skill 你装的时候是干 A 事的后来你改了它的脚本让它干 B 事但 description 没改结果 Claude 还是按 A 事的场景触发它。这种情况我遇到过两次都是靠体检发现的。5.4 优先选自带脚本的 Skill而不是纯 prompt的 Skill纯 prompt 的 Skill 本质上就是一段预设的提示词这种 Skill 你自己写一段 prompt 就能替代没必要装。真正值得装的是自带脚本或模板文件的 Skill因为脚本能做 Claude 原生做不了的事——比如调用本地工具、处理特定格式的文件、执行固定的数据转换。判断方法很简单打开 Skill 目录看里面除了SKILL.md还有没有别的文件。如果只有SKILL.md那它大概率可以被一段 prompt 替代。6. 删完之后我的 Claude Code 发生了什么变化最直观的变化是响应变准了。以前输入一个请求Claude 有时候会先思考很久然后调用一个我没预期的 Skill。现在它基本能直接理解我要什么该用 Skill 的时候用不该用的时候安静地直接做。第二个变化是上下文更充裕了。同样长度的任务现在 Claude 能处理更长的输入因为它不用花上下文去加载一堆 Skill 的描述。我实测过一个场景审查一个八百行的文件删 Skill 之前它读到六百行左右就开始总结删之后能完整读完并给出逐行意见。第三个变化是维护时间归零。以前每个月都要花时间修 Skill现在八个 Skill 里有两个是纯模板、三个是稳定脚本、三个是高频 prompt 封装基本不需要维护。第四个变化可能有点反直觉我开始更频繁地手写 prompt 了。因为 Skill 少了之后我被迫去想要怎么用自然语言把需求描述清楚这个过程反而让我对 Claude 的能力边界更清楚了。以前遇到问题第一反应是有没有对应的 Skill现在第一反应是我该怎么描述这个需求。7. 关于 Skill 的几个常见误解7.1 Skill 越多Claude 越强这是最大的误解。Skill 不是能力叠加而是注意力分配。每个 Skill 都在争夺 Claude 的注意力Skill 越多单个 Skill 能分到的注意力越少。真正让 Claude 变强的不是 Skill 数量而是你描述需求的清晰度和你对任务的理解深度。7.2 好用的 Skill 应该一直留着Skill 的好用是有时效的。你三个月前觉得好用的 Skill可能因为你工作内容变了、Claude 版本升级了、依赖的工具更新了现在已经不好用了。定期清理不是浪费而是保持环境健康。7.3 删了之后想用怎么办归档机制就是为这个问题准备的。删不是永久删除是移出活跃环境。想用的时候移回来就行成本几乎为零。真正的问题是你归档之后三个月都没捞回来过那说明它本来就不该留。7.4 别人的 Skill 清单可以直接抄不能。Skill 的价值高度依赖你的工作流。别人留着的 Skill 可能是因为他每天做那件事你留着可能一年用一次。参考别人的清单可以但一定要用自己的使用数据去验证。8. 一个具体的清理操作流程如果你现在就想动手清理可以按这个流程走备份先把整个 skills 目录复制一份命名成skills_backup_日期。这一步是保险别省。记录接下来两周每次 Claude 调用 Skill 就记一笔格式日期 | Skill | 任务 | 是否有用。打分两周后按触发准确率、结果可用度、不可替代性三个维度打分每项 1 到 5 分。归档总分低于 9 分的移到_archived_skills目录9 到 11 分的标记观察12 分以上保留。验证归档之后用一周看有没有出现想用某个 Skill 但发现被归档了的情况。如果有把它捞回来。定上限给自己定一个 Skill 数量上限以后装新的必须先归档一个旧的。月度体检每月固定时间做一次快速体检重点看 description 是否还准确、有没有 Skill 因为外部依赖失效。这套流程走下来大概需要两周的记录期加一个下午的整理时间。投入不大但换来的是一个干净、可预测、低维护的 Claude Code 环境。9. 我在清理过程中总结的几条经验第一条Skill 的 description 比 Skill 的内容更重要。因为 Claude 是靠 description 决定要不要用这个 Skill 的。description 写得模糊Skill 内容再好也白搭description 写得精准哪怕 Skill 内容简单也能在正确的时机被调用。我留下来的八个 Skilldescription 都改过至少一遍。第二条不要因为这个 Skill 是我自己写的就舍不得删。我删掉的 Skill 里有五个是我自己写的写的时候花了不少时间。但沉没成本不是保留的理由用不上就是用不上。第三条Skill 和 prompt 的边界要清楚。固定流程用 Skill灵活任务用 prompt。我见过有人把帮我起个变量名都做成了 Skill这就属于边界不清。变量命名这种事每次情况都不一样做成 Skill 只会增加触发噪音。第四条定期看 Claude Code 的更新日志。有些 Skill 之所以变得多余是因为 Claude 原生能力升级了。比如某个版本之后 Claude 对长文档的处理能力大幅提升我原来用来做文档分块的 Skill 就变得没必要了。关注更新日志能帮你及时发现自己环境里的冗余。第五条Skill 目录结构保持扁平。我见过有人把 Skill 按类别放在多层子目录里结果 Claude 加载的时候找不到。Skill 目录最好是扁平的每个 Skill 一个顶层目录目录名就是 Skill 名。这样加载最稳定排查问题也最方便。最后分享一个我自己的小习惯每次归档一个 Skill我会在归档目录里留一个why_archived.md写一句话说明为什么归档它。三个月后回头看这些记录能很清楚地看到自己的工作流是怎么变化的也能避免把同一个 Skill 反复装了又删。这个习惯看起来有点多余但在我身上至少避免了三次这个 Skill 我是不是删过的重复决策。