三个月前我把 Claude Code 当成日常主力工具顺手把社区里能见到的 Skill 都装了一轮。当时的感觉很像逛打折超市不管用不用得上先放到购物车里再说。结果三个月过去我的 Skill 目录膨胀到上百个真正在用的不超过十个。上周末我花了半天时间做了一次大扫除删掉了 80% 的 Skill。这篇文章就把我删东西的标准、清理的步骤、以及踩过的坑原原本本讲一遍希望能给正在折腾 Claude Code Skill 的朋友一点参考。你可能会好奇Skill 不是越多越强吗跳过那些包装华丽的神仙 Skill时你真的知道它里面装的是什么吗我会用三个月的真实使用记录来回答这些问题。如果你也在纠结这个 Skill 到底要不要留看完应该会有自己的答案。1. 我为什么一口气装了一百多个 Skill1.1 被社区热词和神仙 Skill种草的过程一切要从一次搜索开始。当时我在研究 Claude Code 的玩法看到不少人说装上某个 Skill 之后编码效率翻倍这个 Skill 能让 Claude 自动执行终端命令甚至还有去 AI 味 Skill 编码 247狗头军师 Skill这种一听就很夸张的名字。社区里随便一翻就是几十个 Skill 推荐帖每个帖子下面都有人回复实测好用已收藏。我当时的心理很简单反正是文件夹里放点东西的事又不花钱装一个也不亏。于是从book to skill到workbuddy skill从superpower skill到hermes skill只要看到有人推荐我就往下拉安装说明复制目录、粘贴配置、重启会话一气呵成。那段时间我的 Claude Code 配置里塞满了各种来源的 Skill分别来自 GitHub 仓库、公众号文章、付费社群分享和网友私包的压缩包。现在回头看这种装了就当做过了的状态非常典型。Skill 的安装成本太低了低到你根本不会去思考它是否真的有必要。我甚至在一天之内装了二十多个 Skill连它们各自做什么都没来得及看。目录里出现了一堆以作者昵称或者心情命名的文件夹比如haha skillcola skill仓颉 skill里面是什么内容我完全不清楚。1.2 三个月后让我崩溃的三个信号真正让我意识到问题严重的是三个非常具体的崩溃瞬间。第一个瞬间发生在一次普通的代码重构任务里。我让 Claude Code 帮忙把一个 Python 模块拆成两个文件结果它思考了一会儿之后突然在输出里插入了一段类似根据打斗动作提示词 skill 的规则我应该先描述环境再描述动作的内容。我根本没有提任何打斗场景它却因为某个 Skill 的规则被触发而跑偏了。第二个瞬间是上下文被塞满。我查看一次会话的 token 统计发现系统提示词和 Skill 相关指令占了相当大的比例。Claude 每次思考都要把一大堆 Skill 的规则读一遍即使这次任务跟它们毫无关系。这就像你让一个同事帮忙倒杯水他先花十分钟翻了一遍办公室所有人的岗位说明书。第三个瞬间是冲突。我同时装了三个代码审查类 Skill它们对输出格式的要求完全不同。一个要求先给问题清单一个要求按严重级别排序另一个要求附带修改后的完整代码。Claude Code 只能选择其中一套或者把三套混在一起生成一个四不像的答案。那天我意识到Skill 装多了不是增强而是精神分裂。1.3 删除前的心理斗争与决策点真正动手删除之前我纠结了很久。一方面觉得这些 Skill 都是花时间找到的万一以后用得上呢另一方面又担心删除之后某些自动化流程会失效。后来我给自己定了一个决策点只保留过去三个月里实际用过两次以上的 Skill。为了得到这个数据我翻了一遍 Claude Code 的会话记录把自己手动触发过和明确感知到生效的 Skill 全部列出来。结果非常残酷上百个 Skill 里实际被激活并且带来正面效果的不到十五个。剩下的大部分处在装了但从未被触发或偶尔触发但影响很弱的状态。删除那一刻反而很轻松。真正难的是承认自己在收藏而不是使用。我建议你也做一次这样的盘点不要问这个 Skill 有没有价值而要问过去三个月我有没有真的用过它。2. Skill 的真实结构以及装了就后悔的典型坑2.1 Skill 到底是什么提示词 脚本 目录规则的组合想搞清楚为什么某些 Skill 该删先得明白 Skill 的本质。社区里流传的 Skill 大多数不是官方发布的复杂插件而是一套特定目录结构里面放着几个文件主要包含 SKILL.md 之类的说明文档里面写了触发条件、使用步骤、输出格式要求有时候还会带上几个可执行的脚本。你可以把它理解成给 Claude 准备的一份岗位说明书当对话内容符合某个触发条件时Claude 就会把这份说明书读进来按照里面写好的流程去工作。因为安装方式通常就是把一个文件夹放到 Skill 目录下所以门槛特别低但也因此留下了很多隐患。第一个隐患是来源不可控。很多 Skill 是从互联网上随便下载的你根本不知道里面的指令是否安全、是否会把你的对话记录发送到外部服务。虽然大部分只是文本规则但也有一些 Skill 会指示 Claude 执行终端命令这就存在风险。我后来删掉的一个测试 Skill里面居然让 Claude 在遇到任何问题的时候都先运行 sudo 命令检查系统状态这显然不是个好主意。第二个隐患是规则之间互相干扰。Claude Code 在每轮对话中会做大量上下文拼接多个 Skill 的规则如果同时加载彼此之间可能产生逻辑冲突。尤其是那些设置了无论何时都要…开头的强指令会把 Claude 的注意力拉向完全无关的方向。2.2 Skill 编码 247、193 和去 AI 味背后的包装套路热词里有一串 Skill 编码比如skill 编码 247skill 编码 193还有流行的去 AI 味 Skill。我一开始以为是什么官方的分类编码后来才发现这其实是社区里的一种命名文化作者给自己的写作风格调优包编个号宣传成让你的 AI 输出自然得像人类。这类 Skill 的典型卖点是告诉你只要装上它Claude 写出来的文字就会摆脱首先、其次、总之、随着发展之类的 AI 腔调。听起来非常诱人尤其是对需要大量写文案的人来说。我也装过两三个不同版本的去 AI 味 Skill测试的结果却很有意思单独测试的时候确实能感觉到输出风格更口语化但只要同时加载两个版本Claude 就会在两个风格要求之间摇摆甚至出现说好要自然却又冒出了总结性结尾的怪现象。我后来把这类 Skill 全部删掉了并不是说它们没效果而是因为它们可以被一条简单的用户指令替代。想让文章不像 AI 写的与其加载一堆互相竞争的风格规则不如直接在对话里写清楚不要用总结句式用短句多用具体场景结尾停在具体动作上。这样既简单又可控也不会污染其他任务。2.3 那些名字很唬人的 Skill狗头军师、workbuddy、superpower、hermes很多 Skill 的真实内容跟名字没有任何关系。我装过狗头军师 skill看名字以为是帮人做决策分析的打开才发现里面是一套非常主观的话术模板要求 Claude 在回答任何问题前先给出五条非常规建议。第一次用还挺新鲜第二次开始就让人觉得烦因为真正的技术问题根本不需要什么奇思妙想只需要准确的答案。再比如workbuddy skill看名字像是一个综合效率助手实际上它的核心内容是让 Claude 按照某种特定格式管理待办清单。如果你日常不用那个清单模板这个 Skill 不仅不会帮你还会反复建议你把任务转化成它的格式反而打断了正常对话节奏。superpower skill和hermes skill也有类似问题。它们往往是一大套多功能指令的合集表面上什么都能干实际上每一项都很泛。我试过其中某个号称超级代理的 Skill它在一次简单的读取文件并按行数统计任务里先规划了五步流程又调用了两个不存在的工具最后还给出了一个错误的统计结果。装这类 Skill等于给 Claude 套了一个很厚的话术壳而它真正需要的是轻装上阵。2.4 为什么装得越多Claude 越笨冲突、稀释与上下文灾难这是整篇文章里我最想强调的一点Skill 越多Claude 的不是越聪明而是越分裂。原因可以从三个层面理解。首先是触发膨胀。Claude Code 需要根据对话内容判断要不要加载某个 Skill装得越多判断空间就越大被误触发的概率也越高。你本来在写 Python结果因为你提到了计划两个字某个项目管理 Skill 跳出来接管了对话这种体验相当糟糕。其次是注意力稀释。大语言模型处理上下文的能力有限当上下文里挤满了各种 Skill 的规则、示例、禁忌之后真正和任务相关的信息占比会被压得很低。你可以想象自己在一个会议室里开会旁边同时有十个人塞给你各自的流程文档你连当前议题都看不清了。最后是规则冲突。不同 Skill 之间经常出现互相矛盾的指令比如一个说所有回答都要给出多个选项另一个说直接给出唯一答案。Claude Code 遇到这种情况往往不做优先级判断而是两边都取一部分最终产出四不像结果。这类问题在你只装几个 Skill 的时候几乎不会遇到一旦超过二十个就会出现得很频繁。我删掉 80% 的 Skill 之后Claude Code 的响应速度变快了回答也更稳定了。这不是玄学而是上下文里乱七八糟的东西少了模型能把注意力放到真正重要的事情上。3. 我用什么标准删掉了 80%最后留下了哪些 Skill3.1 删与留的三条硬标准决定删除之前我给自己定了三条硬标准每条都必须是是才能留下。第一条是高频使用。所谓高频不是将来可能会用而是过去三个月的真实会话里至少出现过两次。比如我写周报的时候固定会让 Claude 汇总代码变更那这就值得留下。反之像素动画生成这种听起来好玩但三个月没碰过一次的直接删。第二条是不可替代。如果这个 Skill 做的事情可以靠一条 Prompt、一个脚本或者一个 MCP 工具轻松完成那就不值得占地方。比如很多编码规范检查的 Skill说白了就是让 Claude 读一遍项目里的 .eslintrc 再给建议这种东西我用一条自定义指令就能做到没必要让 Skill 常驻。第三条是结果可验证。对于代码类、测试类 Skill我会用具体任务跑一遍看输出是否稳定正确。如果同一个任务跑三次得到三种不同结果或者结果里明显有错那这个 Skill 就没有保留价值。太多看起来很专业的 Skill 恰恰栽在这一条上它们擅长给出流程却不擅长把事情做对。3.2 最后留下的 20% 清单真实示例经过筛选我的 Skill 目录从上到下一共留下了几个它们都有一个共同点解决的是我在特定场景里的重复劳动。第一个是book to skill相关的拆书总结。我读技术书的时候会随手把章节笔记丢给 Claude让它按固定格式生成卡片式摘要。这个 Skill 里只规定了摘要的结构和关键词提取方式不涉及任何花哨的处理所以很稳定我用的频率也很高。第二个是测试 Skill。它专门用来给 Python 函数生成单元测试骨架输出格式固定为 pytest 风格并且会先列出测试场景再写代码。我删掉了其他三个同类型的 Skill因为这个是我测试下来错误率最低、输出最符合项目习惯的。第三个是代码审查类但只留了一个轻量版本。它的全部规则只有三条先列严重问题再列建议最后给出修改示例。没有长篇大论的分级标准也没有强制要求调用外部工具。正是因为轻它基本不会误伤其他任务。第四个是一套AI 备课相关的 Skill用于把技术会议纪要转成简短的问答卡片。我平时要给团队做分享这套流程几乎每周都会用。它里面只有输入格式和输出格式两个约束简单可靠。其他留下的还有几个负责特定领域格式转换的 Skill比如把 Markdown 表格转成 Excel 可粘贴的格式以及在终端命令输出里提取关键路径。它们的共同特征是规则少、依赖少、使用场景非常清晰。3.3 我删掉但没有完全删掉的东西从 Skill 到 Prompt 的降级删除不等于抛弃。当我发现某些 Skill 的思想有价值但它的完整规则包太重时我会把它降级成一条 Prompt 或者一个自定义命令。举个具体例子社区流行的狗头军师 Skill被打包得很大里面要求 Claude 在回答前进行多轮自我追问还要生成几条非常规建议。我没有整体保留它而是提取出在给决策类问题时额外给出一个反直觉方案这一条合并进我的常用 Prompt 里。效果类似但副作用少了很多。再比如一些去 AI 味 Skill 里的写作规则我会挑两三条最实用的比如删除总结性段落允许用短句结尾落在具体事物上直接写进系统提示词或者对话开头。这样既能影响输出风格又不会让一大段规则常驻上下文。这种从 Skill 到 Prompt 的降级是我这次清理中收获最大的方法。Skill 适合承载复杂、多步骤、需要固定模板的工作流而简单、单点的偏好完全可以用 Prompt 来表达。4. Skill 清理实操盘点、备份、禁用、验证4.1 盘点已装 Skill 的具体方法动手清理之前先要搞清楚自己到底装了什么。以我常用的本地配置为例Claude Code 的 Skill 通常存放在用户目录下的.claude/skills文件夹里有时候项目目录下的.claude/skills也会有。你可以用终端命令直接查看ls -la ~/.claude/skills如果之前配置过自定义目录也可以用 find 命令全盘扫一下find ~/.claude -type d -name *skill* -o -type d -name *Skill* 2/dev/null这一步的关键不只是看目录名还要打开每个目录里的 SKILL.md 文件看看里面的触发条件、核心指令和外部依赖。很多 Skill 的说明文档写得很漂亮实际内容却只有几十行规则。我会把每个 Skill 的名称、功能、最近使用情况记在一个临时表格里方便后面统一决策。4.2 安全备份与软删除策略不要直接按 Delete 删除所有不想要的 Skill万一删完发现自己还需要某个功能恢复起来会麻烦。我采用的方法是移动到备份目录相当于软删除。mkdir -p ~/skill_backup_2025 mv ~/.claude/skills/某个skill名称 ~/skill_backup_2025/这比直接删除多了一步但给了自己一个缓冲期。我把所有不确定的 Skill 都移到备份目录里然后正常使用 Claude Code 一周。这一周里如果完全没有感觉到某个 Skill 缺失那它就可以彻底删掉了如果某个功能需求又出现了我可以单独把那个 Skill 恢复回去。另外要注意有些 Skill 可能不是放在默认目录而是通过配置文件里的路径引用的。清理的时候可以打开 Claude Code 的配置文件检查一下避免备份了目录但配置还被残留引用。真正删干净的方法是同时清理目录和配置项。4.3 用对比测试判断 Skill 的价值对于犹豫不决的 Skill我会做一个简单的对比测试。选一个这个 Skill 声称能处理的任务分别在有 Skill 和无 Skill 的条件下让 Claude 执行对比输出的正确率、格式稳定性和额外消耗。例如测试代码审查类 Skill我会拿同一个包含三个明显 bug 的函数去问 Claude先加载 Skill 让它审查再清空会话后让它直接审查最后把两份结果放在一起看。对比的时候重点看三件事第一加载 Skill 之后是不是发现了我自己没注意到的问题第二输出格式是不是真的更规范还是仅仅多了很多废话第三响应时间和 token 消耗是不是明显增加。很多 Skill 在对比测试里会露馅它们只是把一堆专业名词堆在规则里实际表现反而不如一条清晰的 Prompt。4.4 清理后的配置整理与常用命令清理掉 80% 的 Skill 之后我还顺手整理了一下配置文件。把以前为了兼容各种 Skill 而写的复杂配置简化掉删除了一些不再需要的环境变量和路径引用。Claude Code 的配置文件一般会在~/.claude/settings.json或项目级配置里我建议清理之后至少做一次配置检查。可以先用命令确认当前 Skill 列表变短了ls -la ~/.claude/skills然后重启 Claude Code在一个新会话里问它你现在加载了哪些 Skill看它的回答是否和目录一致。这一步很重要因为有时候旧会话会继续携带已经删除的 Skill 规则让你误以为清理没生效。我还会在新会话里跑一个冒烟测试分别测试编码、文件读写、终端命令执行三类基础能力是否正常。折腾完这一步整个清理过程才算真正结束心里会踏实很多。5. 删完 80% 之后我重新理解了 Claude Code 的工作方式5.1 上下文窗口是有限资源Skill 是显存而不是硬盘以前我把 Skill 当硬盘以为装得越多能干的活越多。实际用下来发现Skill 更像是显存你同时加载的每一个 Skill 都要占据上下文空间都会参与模型的注意力计算。显存是有限的装太多东西进去真正跑任务的空间就少了。一个 Skill 的规则如果很长即使它没有被明显触发也可能在系统被人为拼接的时候进入上下文。尤其是那些设置成始终可用的 Skill等于每个对话都要背着它的全部规则。我删完 80% 的 Skill 之后明显感觉到 Claude 在单轮对话里更专注了不再需要从一堆互相干扰的指令里去猜你到底想要什么。所以我的新原则是让 Skill 保持精瘦。每个 Skill 只解决一个场景规则不超过一屏不包含万能回答模板这类空话。这样哪怕未来要加新 Skill也不会把上下文塞爆。5.2 Skill、MCP、自定义指令的正确边界清理完 Skill 之后我还特意梳理了 Skill 和其他工具的关系尤其是 MCP 和自定义指令。我的理解是MCP 主要负责能力比如让 Claude 能搜索网页、读数据库、操作某个外部系统自定义指令主要负责偏好比如你希望回答用中文、希望代码风格是某种规范而 Skill 最适合承载流程也就是把一个多步骤、有固定模板的任务固化成一套可复现的方法。举个例子我需要把会议纪要转成周报这个任务需要经历读取原文、提取要点、按模板生成周报、检查格式四步那就值得做成 Skill。但如果只是回答里不要总是用总结句这就应该放进自定义指令而不是做一个庞大的 Skill。分清这三个层次之后你就不会再把所有东西都塞进 Skill 目录里了。5.3 让 Skill 变少的可持续方法场景化 轻量化经历了这次大扫除我现在对新增 Skill 的态度变得非常谨慎。想加一个新 Skill 之前我会先回答三个问题这个场景我是不是每周都会遇到现有的 Prompt 或脚本能不能实现同样的效果这个 Skill 的规则能不能控制在 20 行以内如果三个问题里有一个回答不理想我就先不装而是把想法记在一个待验证清单里。等我真的遇到第三次相同需求时再回去考虑要不要做成 Skill。这种方法听起来很保守但它防止了我再次陷入装完就忘的循环。此外我还会定期清理。每个月抽十分钟打开 Skill 目录把那些超过三十天没被触发过的 Skill 移到备份目录。这种定期瘦身让我的 Claude Code 配置一直保持在健康状态哪怕是新开项目也不会被一堆历史包袱拖慢。5.4 如果现在让我重新装 Skill我会这样做如果让我回到三个月前重新开始我会先花半小时想清楚自己最常用的五个任务是什么然后只给这五个任务找对应的 Skill。装完之后每个 Skill 都先跑一遍样例任务确认它真的有效再带入真实工作流测试一周。我不会再因为某个 Skill 在社区里被夸得天花乱坠就急着安装。社区热词反映的是别人的需求不一定是我的需求。比如打斗动作提示词 skill在写小说的人那里可能是神器对我这种主要处理代码和技术文档的人来说装它只会增加误触发概率。更重要的是我会把删除当成一件正常的事。装了 Skill 不合适就删换一个再试而不是让它在目录里躺着积灰。每次删除都是一次更好的定位三个月后留下来的那 20%才是真正值得长期共存的伙伴。最后再分享一个小技巧清理完 Skill 之后我习惯新建一个空目录把当前要用的 Skill 放进去然后在配置文件里指向这个新目录。这样每次项目切换都能很清楚地知道当前会话到底加载了什么不会出现旧 Skill阴魂不散的情况。对我来说Claude Code 最好的状态不是装满了神通广大的 Skill而是每一次对话都干净、直接、靠谱。 
长河君 · 2026/10/3 5:52:09 · 阅读 1.2k Claude Code Skill 清理实战：从上百个到 20%，效率提升的关键
三个月前我把 Claude Code 当成日常主力工具顺手把社区里能见到的 Skill 都装了一轮。当时的感觉很像逛打折超市不管用不用得上先放到购物车里再说。结果三个月过去我的 Skill 目录膨胀到上百个真正在用的不超过十个。上周末我花了半天时间做了一次大扫除删掉了 80% 的 Skill。这篇文章就把我删东西的标准、清理的步骤、以及踩过的坑原原本本讲一遍希望能给正在折腾 Claude Code Skill 的朋友一点参考。你可能会好奇Skill 不是越多越强吗跳过那些包装华丽的神仙 Skill时你真的知道它里面装的是什么吗我会用三个月的真实使用记录来回答这些问题。如果你也在纠结这个 Skill 到底要不要留看完应该会有自己的答案。1. 我为什么一口气装了一百多个 Skill1.1 被社区热词和神仙 Skill种草的过程一切要从一次搜索开始。当时我在研究 Claude Code 的玩法看到不少人说装上某个 Skill 之后编码效率翻倍这个 Skill 能让 Claude 自动执行终端命令甚至还有去 AI 味 Skill 编码 247狗头军师 Skill这种一听就很夸张的名字。社区里随便一翻就是几十个 Skill 推荐帖每个帖子下面都有人回复实测好用已收藏。我当时的心理很简单反正是文件夹里放点东西的事又不花钱装一个也不亏。于是从book to skill到workbuddy skill从superpower skill到hermes skill只要看到有人推荐我就往下拉安装说明复制目录、粘贴配置、重启会话一气呵成。那段时间我的 Claude Code 配置里塞满了各种来源的 Skill分别来自 GitHub 仓库、公众号文章、付费社群分享和网友私包的压缩包。现在回头看这种装了就当做过了的状态非常典型。Skill 的安装成本太低了低到你根本不会去思考它是否真的有必要。我甚至在一天之内装了二十多个 Skill连它们各自做什么都没来得及看。目录里出现了一堆以作者昵称或者心情命名的文件夹比如haha skillcola skill仓颉 skill里面是什么内容我完全不清楚。1.2 三个月后让我崩溃的三个信号真正让我意识到问题严重的是三个非常具体的崩溃瞬间。第一个瞬间发生在一次普通的代码重构任务里。我让 Claude Code 帮忙把一个 Python 模块拆成两个文件结果它思考了一会儿之后突然在输出里插入了一段类似根据打斗动作提示词 skill 的规则我应该先描述环境再描述动作的内容。我根本没有提任何打斗场景它却因为某个 Skill 的规则被触发而跑偏了。第二个瞬间是上下文被塞满。我查看一次会话的 token 统计发现系统提示词和 Skill 相关指令占了相当大的比例。Claude 每次思考都要把一大堆 Skill 的规则读一遍即使这次任务跟它们毫无关系。这就像你让一个同事帮忙倒杯水他先花十分钟翻了一遍办公室所有人的岗位说明书。第三个瞬间是冲突。我同时装了三个代码审查类 Skill它们对输出格式的要求完全不同。一个要求先给问题清单一个要求按严重级别排序另一个要求附带修改后的完整代码。Claude Code 只能选择其中一套或者把三套混在一起生成一个四不像的答案。那天我意识到Skill 装多了不是增强而是精神分裂。1.3 删除前的心理斗争与决策点真正动手删除之前我纠结了很久。一方面觉得这些 Skill 都是花时间找到的万一以后用得上呢另一方面又担心删除之后某些自动化流程会失效。后来我给自己定了一个决策点只保留过去三个月里实际用过两次以上的 Skill。为了得到这个数据我翻了一遍 Claude Code 的会话记录把自己手动触发过和明确感知到生效的 Skill 全部列出来。结果非常残酷上百个 Skill 里实际被激活并且带来正面效果的不到十五个。剩下的大部分处在装了但从未被触发或偶尔触发但影响很弱的状态。删除那一刻反而很轻松。真正难的是承认自己在收藏而不是使用。我建议你也做一次这样的盘点不要问这个 Skill 有没有价值而要问过去三个月我有没有真的用过它。2. Skill 的真实结构以及装了就后悔的典型坑2.1 Skill 到底是什么提示词 脚本 目录规则的组合想搞清楚为什么某些 Skill 该删先得明白 Skill 的本质。社区里流传的 Skill 大多数不是官方发布的复杂插件而是一套特定目录结构里面放着几个文件主要包含 SKILL.md 之类的说明文档里面写了触发条件、使用步骤、输出格式要求有时候还会带上几个可执行的脚本。你可以把它理解成给 Claude 准备的一份岗位说明书当对话内容符合某个触发条件时Claude 就会把这份说明书读进来按照里面写好的流程去工作。因为安装方式通常就是把一个文件夹放到 Skill 目录下所以门槛特别低但也因此留下了很多隐患。第一个隐患是来源不可控。很多 Skill 是从互联网上随便下载的你根本不知道里面的指令是否安全、是否会把你的对话记录发送到外部服务。虽然大部分只是文本规则但也有一些 Skill 会指示 Claude 执行终端命令这就存在风险。我后来删掉的一个测试 Skill里面居然让 Claude 在遇到任何问题的时候都先运行 sudo 命令检查系统状态这显然不是个好主意。第二个隐患是规则之间互相干扰。Claude Code 在每轮对话中会做大量上下文拼接多个 Skill 的规则如果同时加载彼此之间可能产生逻辑冲突。尤其是那些设置了无论何时都要…开头的强指令会把 Claude 的注意力拉向完全无关的方向。2.2 Skill 编码 247、193 和去 AI 味背后的包装套路热词里有一串 Skill 编码比如skill 编码 247skill 编码 193还有流行的去 AI 味 Skill。我一开始以为是什么官方的分类编码后来才发现这其实是社区里的一种命名文化作者给自己的写作风格调优包编个号宣传成让你的 AI 输出自然得像人类。这类 Skill 的典型卖点是告诉你只要装上它Claude 写出来的文字就会摆脱首先、其次、总之、随着发展之类的 AI 腔调。听起来非常诱人尤其是对需要大量写文案的人来说。我也装过两三个不同版本的去 AI 味 Skill测试的结果却很有意思单独测试的时候确实能感觉到输出风格更口语化但只要同时加载两个版本Claude 就会在两个风格要求之间摇摆甚至出现说好要自然却又冒出了总结性结尾的怪现象。我后来把这类 Skill 全部删掉了并不是说它们没效果而是因为它们可以被一条简单的用户指令替代。想让文章不像 AI 写的与其加载一堆互相竞争的风格规则不如直接在对话里写清楚不要用总结句式用短句多用具体场景结尾停在具体动作上。这样既简单又可控也不会污染其他任务。2.3 那些名字很唬人的 Skill狗头军师、workbuddy、superpower、hermes很多 Skill 的真实内容跟名字没有任何关系。我装过狗头军师 skill看名字以为是帮人做决策分析的打开才发现里面是一套非常主观的话术模板要求 Claude 在回答任何问题前先给出五条非常规建议。第一次用还挺新鲜第二次开始就让人觉得烦因为真正的技术问题根本不需要什么奇思妙想只需要准确的答案。再比如workbuddy skill看名字像是一个综合效率助手实际上它的核心内容是让 Claude 按照某种特定格式管理待办清单。如果你日常不用那个清单模板这个 Skill 不仅不会帮你还会反复建议你把任务转化成它的格式反而打断了正常对话节奏。superpower skill和hermes skill也有类似问题。它们往往是一大套多功能指令的合集表面上什么都能干实际上每一项都很泛。我试过其中某个号称超级代理的 Skill它在一次简单的读取文件并按行数统计任务里先规划了五步流程又调用了两个不存在的工具最后还给出了一个错误的统计结果。装这类 Skill等于给 Claude 套了一个很厚的话术壳而它真正需要的是轻装上阵。2.4 为什么装得越多Claude 越笨冲突、稀释与上下文灾难这是整篇文章里我最想强调的一点Skill 越多Claude 的不是越聪明而是越分裂。原因可以从三个层面理解。首先是触发膨胀。Claude Code 需要根据对话内容判断要不要加载某个 Skill装得越多判断空间就越大被误触发的概率也越高。你本来在写 Python结果因为你提到了计划两个字某个项目管理 Skill 跳出来接管了对话这种体验相当糟糕。其次是注意力稀释。大语言模型处理上下文的能力有限当上下文里挤满了各种 Skill 的规则、示例、禁忌之后真正和任务相关的信息占比会被压得很低。你可以想象自己在一个会议室里开会旁边同时有十个人塞给你各自的流程文档你连当前议题都看不清了。最后是规则冲突。不同 Skill 之间经常出现互相矛盾的指令比如一个说所有回答都要给出多个选项另一个说直接给出唯一答案。Claude Code 遇到这种情况往往不做优先级判断而是两边都取一部分最终产出四不像结果。这类问题在你只装几个 Skill 的时候几乎不会遇到一旦超过二十个就会出现得很频繁。我删掉 80% 的 Skill 之后Claude Code 的响应速度变快了回答也更稳定了。这不是玄学而是上下文里乱七八糟的东西少了模型能把注意力放到真正重要的事情上。3. 我用什么标准删掉了 80%最后留下了哪些 Skill3.1 删与留的三条硬标准决定删除之前我给自己定了三条硬标准每条都必须是是才能留下。第一条是高频使用。所谓高频不是将来可能会用而是过去三个月的真实会话里至少出现过两次。比如我写周报的时候固定会让 Claude 汇总代码变更那这就值得留下。反之像素动画生成这种听起来好玩但三个月没碰过一次的直接删。第二条是不可替代。如果这个 Skill 做的事情可以靠一条 Prompt、一个脚本或者一个 MCP 工具轻松完成那就不值得占地方。比如很多编码规范检查的 Skill说白了就是让 Claude 读一遍项目里的 .eslintrc 再给建议这种东西我用一条自定义指令就能做到没必要让 Skill 常驻。第三条是结果可验证。对于代码类、测试类 Skill我会用具体任务跑一遍看输出是否稳定正确。如果同一个任务跑三次得到三种不同结果或者结果里明显有错那这个 Skill 就没有保留价值。太多看起来很专业的 Skill 恰恰栽在这一条上它们擅长给出流程却不擅长把事情做对。3.2 最后留下的 20% 清单真实示例经过筛选我的 Skill 目录从上到下一共留下了几个它们都有一个共同点解决的是我在特定场景里的重复劳动。第一个是book to skill相关的拆书总结。我读技术书的时候会随手把章节笔记丢给 Claude让它按固定格式生成卡片式摘要。这个 Skill 里只规定了摘要的结构和关键词提取方式不涉及任何花哨的处理所以很稳定我用的频率也很高。第二个是测试 Skill。它专门用来给 Python 函数生成单元测试骨架输出格式固定为 pytest 风格并且会先列出测试场景再写代码。我删掉了其他三个同类型的 Skill因为这个是我测试下来错误率最低、输出最符合项目习惯的。第三个是代码审查类但只留了一个轻量版本。它的全部规则只有三条先列严重问题再列建议最后给出修改示例。没有长篇大论的分级标准也没有强制要求调用外部工具。正是因为轻它基本不会误伤其他任务。第四个是一套AI 备课相关的 Skill用于把技术会议纪要转成简短的问答卡片。我平时要给团队做分享这套流程几乎每周都会用。它里面只有输入格式和输出格式两个约束简单可靠。其他留下的还有几个负责特定领域格式转换的 Skill比如把 Markdown 表格转成 Excel 可粘贴的格式以及在终端命令输出里提取关键路径。它们的共同特征是规则少、依赖少、使用场景非常清晰。3.3 我删掉但没有完全删掉的东西从 Skill 到 Prompt 的降级删除不等于抛弃。当我发现某些 Skill 的思想有价值但它的完整规则包太重时我会把它降级成一条 Prompt 或者一个自定义命令。举个具体例子社区流行的狗头军师 Skill被打包得很大里面要求 Claude 在回答前进行多轮自我追问还要生成几条非常规建议。我没有整体保留它而是提取出在给决策类问题时额外给出一个反直觉方案这一条合并进我的常用 Prompt 里。效果类似但副作用少了很多。再比如一些去 AI 味 Skill 里的写作规则我会挑两三条最实用的比如删除总结性段落允许用短句结尾落在具体事物上直接写进系统提示词或者对话开头。这样既能影响输出风格又不会让一大段规则常驻上下文。这种从 Skill 到 Prompt 的降级是我这次清理中收获最大的方法。Skill 适合承载复杂、多步骤、需要固定模板的工作流而简单、单点的偏好完全可以用 Prompt 来表达。4. Skill 清理实操盘点、备份、禁用、验证4.1 盘点已装 Skill 的具体方法动手清理之前先要搞清楚自己到底装了什么。以我常用的本地配置为例Claude Code 的 Skill 通常存放在用户目录下的.claude/skills文件夹里有时候项目目录下的.claude/skills也会有。你可以用终端命令直接查看ls -la ~/.claude/skills如果之前配置过自定义目录也可以用 find 命令全盘扫一下find ~/.claude -type d -name *skill* -o -type d -name *Skill* 2/dev/null这一步的关键不只是看目录名还要打开每个目录里的 SKILL.md 文件看看里面的触发条件、核心指令和外部依赖。很多 Skill 的说明文档写得很漂亮实际内容却只有几十行规则。我会把每个 Skill 的名称、功能、最近使用情况记在一个临时表格里方便后面统一决策。4.2 安全备份与软删除策略不要直接按 Delete 删除所有不想要的 Skill万一删完发现自己还需要某个功能恢复起来会麻烦。我采用的方法是移动到备份目录相当于软删除。mkdir -p ~/skill_backup_2025 mv ~/.claude/skills/某个skill名称 ~/skill_backup_2025/这比直接删除多了一步但给了自己一个缓冲期。我把所有不确定的 Skill 都移到备份目录里然后正常使用 Claude Code 一周。这一周里如果完全没有感觉到某个 Skill 缺失那它就可以彻底删掉了如果某个功能需求又出现了我可以单独把那个 Skill 恢复回去。另外要注意有些 Skill 可能不是放在默认目录而是通过配置文件里的路径引用的。清理的时候可以打开 Claude Code 的配置文件检查一下避免备份了目录但配置还被残留引用。真正删干净的方法是同时清理目录和配置项。4.3 用对比测试判断 Skill 的价值对于犹豫不决的 Skill我会做一个简单的对比测试。选一个这个 Skill 声称能处理的任务分别在有 Skill 和无 Skill 的条件下让 Claude 执行对比输出的正确率、格式稳定性和额外消耗。例如测试代码审查类 Skill我会拿同一个包含三个明显 bug 的函数去问 Claude先加载 Skill 让它审查再清空会话后让它直接审查最后把两份结果放在一起看。对比的时候重点看三件事第一加载 Skill 之后是不是发现了我自己没注意到的问题第二输出格式是不是真的更规范还是仅仅多了很多废话第三响应时间和 token 消耗是不是明显增加。很多 Skill 在对比测试里会露馅它们只是把一堆专业名词堆在规则里实际表现反而不如一条清晰的 Prompt。4.4 清理后的配置整理与常用命令清理掉 80% 的 Skill 之后我还顺手整理了一下配置文件。把以前为了兼容各种 Skill 而写的复杂配置简化掉删除了一些不再需要的环境变量和路径引用。Claude Code 的配置文件一般会在~/.claude/settings.json或项目级配置里我建议清理之后至少做一次配置检查。可以先用命令确认当前 Skill 列表变短了ls -la ~/.claude/skills然后重启 Claude Code在一个新会话里问它你现在加载了哪些 Skill看它的回答是否和目录一致。这一步很重要因为有时候旧会话会继续携带已经删除的 Skill 规则让你误以为清理没生效。我还会在新会话里跑一个冒烟测试分别测试编码、文件读写、终端命令执行三类基础能力是否正常。折腾完这一步整个清理过程才算真正结束心里会踏实很多。5. 删完 80% 之后我重新理解了 Claude Code 的工作方式5.1 上下文窗口是有限资源Skill 是显存而不是硬盘以前我把 Skill 当硬盘以为装得越多能干的活越多。实际用下来发现Skill 更像是显存你同时加载的每一个 Skill 都要占据上下文空间都会参与模型的注意力计算。显存是有限的装太多东西进去真正跑任务的空间就少了。一个 Skill 的规则如果很长即使它没有被明显触发也可能在系统被人为拼接的时候进入上下文。尤其是那些设置成始终可用的 Skill等于每个对话都要背着它的全部规则。我删完 80% 的 Skill 之后明显感觉到 Claude 在单轮对话里更专注了不再需要从一堆互相干扰的指令里去猜你到底想要什么。所以我的新原则是让 Skill 保持精瘦。每个 Skill 只解决一个场景规则不超过一屏不包含万能回答模板这类空话。这样哪怕未来要加新 Skill也不会把上下文塞爆。5.2 Skill、MCP、自定义指令的正确边界清理完 Skill 之后我还特意梳理了 Skill 和其他工具的关系尤其是 MCP 和自定义指令。我的理解是MCP 主要负责能力比如让 Claude 能搜索网页、读数据库、操作某个外部系统自定义指令主要负责偏好比如你希望回答用中文、希望代码风格是某种规范而 Skill 最适合承载流程也就是把一个多步骤、有固定模板的任务固化成一套可复现的方法。举个例子我需要把会议纪要转成周报这个任务需要经历读取原文、提取要点、按模板生成周报、检查格式四步那就值得做成 Skill。但如果只是回答里不要总是用总结句这就应该放进自定义指令而不是做一个庞大的 Skill。分清这三个层次之后你就不会再把所有东西都塞进 Skill 目录里了。5.3 让 Skill 变少的可持续方法场景化 轻量化经历了这次大扫除我现在对新增 Skill 的态度变得非常谨慎。想加一个新 Skill 之前我会先回答三个问题这个场景我是不是每周都会遇到现有的 Prompt 或脚本能不能实现同样的效果这个 Skill 的规则能不能控制在 20 行以内如果三个问题里有一个回答不理想我就先不装而是把想法记在一个待验证清单里。等我真的遇到第三次相同需求时再回去考虑要不要做成 Skill。这种方法听起来很保守但它防止了我再次陷入装完就忘的循环。此外我还会定期清理。每个月抽十分钟打开 Skill 目录把那些超过三十天没被触发过的 Skill 移到备份目录。这种定期瘦身让我的 Claude Code 配置一直保持在健康状态哪怕是新开项目也不会被一堆历史包袱拖慢。5.4 如果现在让我重新装 Skill我会这样做如果让我回到三个月前重新开始我会先花半小时想清楚自己最常用的五个任务是什么然后只给这五个任务找对应的 Skill。装完之后每个 Skill 都先跑一遍样例任务确认它真的有效再带入真实工作流测试一周。我不会再因为某个 Skill 在社区里被夸得天花乱坠就急着安装。社区热词反映的是别人的需求不一定是我的需求。比如打斗动作提示词 skill在写小说的人那里可能是神器对我这种主要处理代码和技术文档的人来说装它只会增加误触发概率。更重要的是我会把删除当成一件正常的事。装了 Skill 不合适就删换一个再试而不是让它在目录里躺着积灰。每次删除都是一次更好的定位三个月后留下来的那 20%才是真正值得长期共存的伙伴。最后再分享一个小技巧清理完 Skill 之后我习惯新建一个空目录把当前要用的 Skill 放进去然后在配置文件里指向这个新目录。这样每次项目切换都能很清楚地知道当前会话到底加载了什么不会出现旧 Skill阴魂不散的情况。对我来说Claude Code 最好的状态不是装满了神通广大的 Skill而是每一次对话都干净、直接、靠谱。