如果你也玩 Claude Code大概率见过这种状态看到一个 Skill 觉得“这不就是我需要的吗”装群里有人发了个新 Skill 链接装官方文档提了一句最佳实践装。三个月前我差不多把社区里热门的 Skill 都塞进了自己的环境前前后后加起来有三十多个。三个月过去我删掉了其中 80%留下的不到十个。这篇文章不是劝你别装 Skill而是把我从“装到停不下来”到“删到只剩骨干”的完整过程、判断标准、删除顺序和踩过的坑都复盘一遍给同样在跟这堆插件缠斗的人做个参考。先说清楚两个概念。Claude Code 是跑在终端里的 AI 编程助手你可以在命令行里让它读代码、改文件、跑测试、解释日志。Skill 是给它追加的“能力包”一个 Skill 通常由说明文档、脚本和约定组成在对应任务出现时被自动或手动调用。Skill 本身不神秘装多了以后真正的问题也不是磁盘空间而是注意力、上下文和协作方式的失控。1. 三个月前我为什么装了一堆 Skill1.1 从第一条 Skill 开始效率焦虑与尝鲜心理我装的第一条 Skill 是终端命令解释器。当时的需求很朴素我经常忘记一些非常规命令的感受干脆让 Claude 根据我的意图给出一串命令并解释每个参数。这个 Skill 确实好用但也是从这里开始我走上了一条“看见 Skill 就想装”的路。复盘那个阶段的心理我总结出三个驱动力。第一是效率焦虑。总觉得自己手动做某些重复操作太慢看到别人说“这个 Skill 能一口气完成代码审查、生成 PR 描述、补测试”就会立刻觉得不装就落后了。第二是社区热度带来的从众感。热门仓库、高赞帖子、朋友圈里的截图都会让人产生“大家都在用我也得试试”的错觉。第三是安装太容易。大部分 Skill 就是一个文件夹克隆、放目录、改个配置就能用零门槛导致决策成本极低装错了也不心疼。现在回头看效率焦虑是真的但热度和从众感完全是噪音。工具的价值应该由使用频率和产出质量决定而不是由下载量决定。这个道理写出来很浅白实际操作中我就是花了三个月才真正接受。1.2 我都装了哪些类型的 Skill当时我的 skills 目录里大致是这么几类每一类都对应我某个阶段自以为刚需的场景命令类终端命令解释、Bash 脚本生成、Git 提交信息生成、Git 历史分析。代码类代码审查、单元测试补全、正则表达式生成、重构建议、依赖升级检查。文档类README 生成、PR 描述模板、Changelog 生成、日报/周报起草。调试类日志分析、错误栈解读、性能排查、数据库查询优化。工作流类前端组件搭建、API 接口调试、Docker 命令整理。还有一批“尝鲜型”小说生成、打斗动作提示词、备课文案、职场沟通话术等。数一下就能发现光代码审查类的我就装了三个不同来源的版本日志分析类的也装了两个。同一类能力重复安装本身就是一种资源浪费更不用说这些 Skill 之间还存在潜在的指令冲突。到了清理阶段这一批重复和近似项是最先被淘汰的。2. 时间一长这堆 Skill 的真实账单出来了2.1 用得最多的 20%高频场景画像三个月后我做了个简单的使用统计就是把 Claude Code 的会话记录和调用日志翻出来看每个 Skill 实际被触发或手动调用的次数。结果非常符合二八定律真正被反复使用、并且每次都能稳定产出好结果的 Skill不超过总数的 20%。我用得最多的是这几类场景终端里的难命令解释、Git 提交信息的整理、日志错误快速定位、小范围代码重构建议。这四个场景有一个共同点——它们都是“短平快”的任务一个 Skill 能在十几秒内给出可执行的答案而且答案质量可以立刻判断。反过来看那些低频 Skill不是质量差而是触发场景太窄。比如某个“API 接口调试”的 Skill它要求你按固定格式把请求参数填进去然后它帮你拼接 curl 命令。但实际开发中我更多是直接在终端里问一句“帮我用 Python 调这个接口超时设置 10 秒”效果也差不多。窄场景 Skill 很容易被自然语言对话替代这是它们被淘汰的第一个信号。2.2 被悄悄淘汰的 80% 去哪了删除不等于这些 Skill 毫无价值。我把它们分成四种情况一次性尝鲜型装的时候觉得新鲜用了一两次就再也没碰过比如打斗动作提示词、小说生成。自然语言可替代型与其调用 Skill 的固定模板不如直接描述需求AI 给出的结果反而更贴合上下文。质量不稳定型同一个 Skill 有时候效果好有时候逻辑混乱无法建立信任后来宁可手动处理也不愿意调它。重复冗余型多个人都写了功能相似的 Skill最后只留一个维护最好的。这四类加起来占了绝大多数。真正让我下决心删的不是它们“不好用”而是我发现它们会持续产生隐性成本。每一个 Skill 都可能在对话开始时被加载进上下文或者被 Agent 自动扫描装得越多模型每次思考时要考虑的“多余分支”就越多。表现就是响应变慢、跑题变多、偶尔还出现两个 Skill 同时对同一个需求给出相反建议的情况。2.3 删除背后的三大核心原因长期使用下来我认为囤 Skill 最大的问题有三个按破坏力排序第一是上下文膨胀。Claude Code 每次会话都带着一堆 Skill 说明哪怕这些说明只有几 KB几十个加起来也会挤占模型的注意力。更麻烦的是很多 Skill 为了让 AI“听懂”会写很长的触发规则和示例这些内容在不需要它出场的会话中也占着位置。第二是指令冲突。不同 Skill 可能对相似场景给出不同处理方式比如 A 要求 AI 在回答前先列要点B 要求直接给最终结果。两个 Skill 同时在场时AI 的行为会变得随机原本的稳定工作流被打破。第三是维护成本。Claude Code 版本更新后一些 Skill 的写法就不兼容了你得挨个检查要不要改。我三个月里光是在升级后维护这堆模板就花了不少时间那段时间真的完全抵消了它们带来的效率提升。这三点加在一起让“装得多”变成了一种负资产。真正经历过这种失控感的人应该能明白那句“我删掉了 80%”背后不是嫌弃而是止损。3. 我是怎么筛选和判断一个 Skill 值不值得留下3.1 三条硬指标可复用、可组合、可解释开始清理之前我先给自己定了三条硬指标。一个 Skill 必须同时满足才能进入“保留观察区”。可复用指的是这个 Skill 对应的任务场景至少要在一周内自然出现一次以上。不是“我偶尔会遇到”而是“我稳定会遇到”。以写周报为例如果团队的周报频率是每周一次那这个 Skill 天然满足高频条件而“写小说”这个场景对我的日常工作来说根本不成立直接删。可组合指的是这个 Skill 能否跟我已有的工作流搭在一起而不是孤立存在。我的终端命令解释 Skill 就经常跟 Git 分析、Docker 排错组合使用而某个“生成表情包文案”的 Skill 跟整个开发流程毫无关系属于完全孤立的能力再怎么有趣也留不住。可解释指的是我得清楚这个 Skill 内部做了什么。凡是我打开 SKILL.md 看了半天也看不懂它在干什么、为什么这么写的一律不加信任。我不要求每个人都去读源码但至少要知道这个 Skill 会给 AI 注入什么规则、会调用什么外部命令。黑盒 Skill 出了问题你连排查方向都没有这种工具留着是隐患。3.2 Skill 的“唯一职责”原则与现实冲突刚开始囤 Skill 的时候我特别喜欢那种“一个 Skill 干五件事”的设计觉得这才是高性价比。后来发现这种设计几乎都有问题。一个 Skill 涉及的命令越多、场景跨度越大它的提示词就越复杂AI 在实际使用时就越容易混乱。反而是那种只负责一件小事的 Skill触发准确、输出稳定。最典型的是我装过的一个“前端开发全能” Skill号称能处理组件生成、样式调整、代码检查、构建打包。理想很丰满现实是它每次触发都会加载一大段前置规则实际生成的组件代码却很平庸。后来我删掉它换成一个只负责“按项目现有组件的代码风格生成新组件”的轻量 Skill效果立刻提升。这个对比让我确定了一件事Skill 应该像代码里的函数一个函数最好只做一件事职责越单一越好维护。当然唯一职责也不意味着越短越好。如果某个 Skill 的说明文件只有几十行但里面全是含糊的“根据情况灵活处理”那它在实际场景里大概率也会失控。好的 Skill 是在“职责清晰”和“指令明确”之间找到平衡点——告诉 AI 什么时候用、怎么输入、输出什么格式但不越权去管其他事情。3.3 成本核算每一次调用到底花了多少判断 Skill 值不值得留一定要算成本账。成本不完全等于 token 数量还包括“多轮交互成本”。举个例子我原来装了一个“自动补测试”的 Skill。它的流程是先生成测试计划再让我确认再逐文件补全整个过程要来回四五轮。看起来功能很强但每次用下来消耗的 token 是直接对话方式的三倍而且遇到复杂项目还得反复纠正它的计划。后来我删掉它改成直接描述需求让 Claude 自己决定怎么补测试反而更快。原因很简单那个 Skill 把“交互流程”写得太死限制了 AI 的灵活性。我建议在清理时都过一遍这个成本账如果一个 Skill 在你每次使用时平均要多花 2 轮以上的对话才能完成任务那它必须带来足够强的质量提升才值得保留。如果它只是为了让 AI 按照一个死板的模板走流程那大概率是负优化。4. 我的最终清理方案与落地步骤4.1 清理前的快照与用量统计方法我先推大家做一个动作清理前一定要备份。我当时的做法是先把整个 skills 目录压成一个压缩包再导出当前的 Claude Code 配置然后才动手。这不是怂是给你自己留后路。人的记忆会骗人三个月前某个 Skill 可能确实帮过大忙但你已经不记得了删完第二天又开始懊恼的情况并不少见。备份之后我用一个笨办法统计真实用量翻历史会话把每个 Skill 名字对应的调用次数记下来。Claude Code 的日志文件里能找到每次调用的记录虽然不能做到精准统计但足以区分出“高频使用”“低频使用”“从未使用”三档。对于从未使用的不用犹豫第一批就删对于低频使用的再结合下面这条路判断。4.2 先禁用再删除一套安全的减法操作法我的建议是不要一次性把 80% 都删掉而是分三步。第一步把明确无用的先移出目录。什么叫明确无用三个月调用次数为零的、重复功能的低配版、跟当前项目完全无关的直接移到一个skills_archive文件夹里相当于是软删除。第二步进入两周的“禁用观察期”。这时候你的环境里已经没有那些大概率不需要的 Skill 了正常干活两周。过程中如果发现哪个任务明显变难了、或者频繁想起某个被移走的 Skill就把它放回来如果没有这种感觉它基本可以确认不是刚需。第三步观察期结束后把skills_archive里剩余的一键删除。这一步我之前也怕但实际做完之后没有任何一个“复活”需求。删完再看自己的目录清爽得让人上瘾。我给这个流程取名叫“先禁后删”它跟断舍离的逻辑一样真正重要的东西你不会忘记会被忘记的往往从一开始就没那么关键。4.3 留下的 20%我现在保留的 Skill 组合清理完以后我的 SKILLS 目录里长期保留的大概是这样的组合分类具体 Skill使用频率保留理由命令辅助终端命令解释与安全确认每周 5 次短平快输出可验证还能顺带解释参数Git 协作提交信息与 Code Review 辅助每周 4 次统一了团队提交格式减少返工日志排查日志异常定位与根因分析每周 3 次能快速过滤海量日志中的关键错误代码重构轻量级小步重构建议每周 2 次规则简单输出可靠很少出现跑题文档生成README / 变更记录模板偶尔只提供结构不写内容灵活度高这里面没有一个是“全能型”Skill全是小而准的工具。它们都有一个共同特点输入很清楚输出很直接几乎不需要我再多绕弯子。这个组合支撑了我三个月的日常开发目前还没出现“缺了某个功能”的焦虑。5. 清理之后三个月的反思与改良习惯5.1 从“囤插件”到“搭积木”的心态转变清理完 Skill 之后最大的变化不是环境变快了而是我调用工具时的思维方式变了。以前我是“先装一堆期待某个场景下它能自动生效”现在是“先想清楚这个场景我多久遇到一次再决定要不要为它加一个固定动作”。这个转变其实很接近写代码时的模块化思维你不会为了一个工具类里的某一个函数引入整个框架同样也不该为了偶尔一次的任务装一个重型的 Skill。Skill 和脚本、提示词、配置项之间应该保持着一种可替换的关系而不是一劳永逸的依赖。我现在的原则很简单能用一次提示词解决的问题不写 Skill同样的问题出现第二次考虑把提示词存成简单的模板出现第三次才动手做成一个完整的 Skill。这个“三次原则”帮我拦住了至少一半的剁手冲动。5.2 我给自己定下的新 Skill 入场标准经历过这次清理以后我给新 Skill 设定了一套“准入门槛”不会再因为看着新鲜就装。第一必须填写一个“使用场景说明”要具体到能说出它会在哪类任务中发挥作用而不是“可能用得上”。第二安装前打开它的说明文件完整读一遍看不懂或者内容空洞的直接不装。第三装完先保持默认不启用状态直到我真正遇到那个场景三次以上才把它激活。第四激活后给一个月的试用期如果这一个月里使用次数少于两次直接移出。这套门槛看起来很麻烦但它把安装这件事从“两秒钟的冲动”变成了“一个需要审慎确认的动作”。门槛高的好处是能进入你环境的都是已经提前筛过一遍的候选者而不是抱着试一试心态塞进来的路人。5.3 给同样在清理 Skill 的人一些实操心得最后分享几个我踩坑踩出来的小技巧不一定对所有人都适用但至少能让你在清理时少走弯路。第一别只看 Installation 文档一定要看 SKILL.md 或者它的核心配置文件。很多 Skill 的问题在安装说明里根本看不出来只有看内容才知道它给你的 AI 灌了哪些规则。灌得越多的越要警惕。第二清理完以后给每个保留的 Skill 写一句“人话注释”记录它当初是干什么的、为什么留下来。三个月后再看这个注释你就不会又犯囤新 Skill 的毛病。第三给整个 SKILLS 目录做版本控制用 Git 管起来。想试新东西就开分支不行就丢弃不用再有“删了后悔怎么办”的心理负担。第四定期设一个“Skill 回收日”每两周花十分钟检查一次使用日志。能坚持做这个动作的人基本不会再回到囤积巅峰的状态。这套方法执行下来我自己的感受是真正好用的 Skill 从来不是靠数量堆出来的。哪怕只剩几个简简单单的工具只要能精准覆盖日常高频场景带来的实际效率提升都远超当初三十多个插件互相打架的时候。说到底Skill 是给人用的设计约束不是必需品的收藏品。我的建议就是“先删为敬”删掉那些不真正服务于你的东西剩下的是什么样用一段时间自然会有答案。