1. 从堆满 Skill 到删掉八成我到底经历了什么三个月前我的 Claude Code 配置目录里塞了四十多个 Skill。每次打开项目settings.json里挂着一长串技能引用SKILL.md文件散落在各个子目录npx skills列表拉出来能滚三屏。那时候我的心态很简单多装一个技能就多一种能力反正又不占内存留着总有用得上的时候。三个月后我删掉了其中八成。剩下的不到十个才是我真正每天在用的。这个数字听起来夸张但你如果也在 Claude Code 里折腾过 Skill大概率会有同感。Skill 这个东西刚接触的时候特别容易上头因为它看起来像是给 AI 装插件——装一个会写小说的装一个会做代码审查的装一个能帮你备课的装一个能生成打斗动作提示词的甚至还有帮你去 AI 味的。每一个都像是打开了新世界的大门于是你不停地装不停地试最后发现真正高频使用的就那么几个剩下的全是装完即弃。我写这篇东西不是要劝你别装 Skill而是想把我这三个月踩过的坑、总结出来的筛选逻辑、以及最后留下来的那几个 Skill 到底为什么值得留完整地讲一遍。如果你正在 Claude Code 里疯狂装 Skill或者刚入门不知道该怎么选这篇应该能帮你省下不少时间。先说结论Skill 的价值不在于数量而在于它是否嵌入了你的日常工作流。一个 Skill 如果一周都用不上一次那它对你来说就是噪音不是能力。这个判断标准听起来简单但真正执行起来需要你对自己的工作方式有足够清醒的认识。2. Skill 到底是什么以及为什么它容易让人上瘾2.1 Skill 的运行机制它不是插件是提示词工程的结构化封装很多人第一次接触 Skill 的时候会把它理解成给 Claude Code 装插件。这个理解不算错但不够准确。Skill 的本质是一组结构化的提示词加上可选的脚本文件通过SKILL.md定义触发条件、行为逻辑和输出格式然后在 Claude Code 运行时被动态加载。你可以把它想象成给一个经验丰富的助手递了一张工作卡片。这张卡片上写着当你遇到某类任务时按照这个流程来做注意这几个要点输出成这个格式。助手本身的能力没变但有了这张卡片它在特定任务上的表现会更稳定、更符合你的预期。关键点在于Skill 不会让 Claude 变聪明它只是让 Claude 在特定场景下更听话。这个认知非常重要。很多人装了一堆 Skill 之后发现效果没有想象中好就是因为期待错了——他们以为 Skill 是能力增强实际上 Skill 是行为约束。SKILL.md文件的结构通常包含几个部分技能名称和描述、触发条件、执行步骤、输出格式要求、以及可选的参考文件或脚本。当你通过npx skills安装一个 Skill 时它本质上就是把这些文件放到你的配置目录里然后在settings.json里注册引用。2.2 为什么你会忍不住一直装Skill 让人上瘾的原因有三个我逐个拆解。第一个原因是安装成本极低。一条npx skills add命令几秒钟就装好了。不需要配置环境变量不需要处理依赖冲突不需要重启服务。这种低门槛让你产生了一种试试又不亏的心理于是你看到一个有意思的 Skill 就装一个。第二个原因是每个 Skill 都承诺了一个美好场景。写小说的 Skill 承诺帮你构思情节代码审查的 Skill 承诺帮你发现 bug备课的 Skill 承诺帮你生成教案。这些承诺在你安装的那一刻是潜在可能性而人类天生对潜在可能性有过度乐观的估计。你觉得自己以后会用上但实际上以后永远不会来。第三个原因是收集本身带来的满足感。这跟买书不读是一个心理机制。你装了一个 Skill就感觉自己拥有了这项能力哪怕你从来没用过。这种拥有感是虚假的但它确实能带来短暂的满足。我自己的经历就是典型。最开始我装了一个代码审查Skill觉得以后写代码肯定用得上。结果三个月里我真正触发它的次数不超过五次因为大部分代码问题我在写的时候就已经发现了不需要额外的审查流程。这个 Skill 对我来说就是典型的看起来有用但实际上没嵌入工作流。2.3 装多了之后发生了什么当你的 Skill 数量超过二十个之后问题开始显现。首先是触发冲突。多个 Skill 的触发条件可能重叠导致 Claude Code 在遇到某个任务时不知道该用哪个 Skill或者同时加载多个 Skill 导致行为混乱。我遇到过最离谱的一次是一个代码优化Skill 和一个代码审查Skill 同时被触发结果 Claude 在审查代码的同时开始重构输出了一大堆我没要求它改的东西。其次是上下文污染。每个被加载的 Skill 都会占用上下文窗口。当你同时挂载十几个 Skill 时真正用于处理你任务的上下文空间被大幅压缩Claude 的表现反而会下降。这就像你给一个助手同时递了十几张工作卡片他光看卡片就花光了所有注意力真正干活的时候反而没精力了。第三个问题是维护负担。Skill 不是装完就不管的。Claude Code 版本更新后部分 Skill 可能失效你自己的项目结构变化后某些 Skill 的路径引用可能出错不同 Skill 之间的settings.json配置可能冲突。我每个月至少要花一两个小时处理这些维护问题而这些时间完全没有产生价值。3. 我是怎么给 Skill 做减法的3.1 第一步统计真实使用频率删 Skill 不能凭感觉得有数据。我做的第一件事是翻查过去三个月的使用记录统计每个 Skill 的实际触发次数。具体做法很简单Claude Code 的日志里会记录每次 Skill 的加载和触发。我把这些日志导出来按 Skill 名称分组统计。结果很残酷——四十多个 Skill 里触发次数超过十次的只有六个触发次数在三次到十次之间的有八个剩下三十多个的触发次数都在三次以下其中有一半从来没被触发过。这个数据让我意识到一个事实我以为我会用的 Skill和我实际会用的 Skill完全是两回事。那些以后可能用得上的 Skill在三个月的真实使用中一次都没被触发。3.2 第二步按工作流嵌入度分类光看频率还不够因为有些 Skill 虽然用得少但每次用都很关键。比如一个处理特定格式文件的 Skill你可能一个月才用一次但那次如果没有它你就得手动折腾半小时。所以我用了第二个维度工作流嵌入度。具体分三档嵌入度判断标准处理方式深度嵌入每周至少用一次且不用会明显影响效率保留场景触发特定场景下必用但场景本身不频繁保留但精简配置可有可无用也行不用也行不用也不会觉得缺什么删除从未触发装了之后一次没用过立即删除按照这个标准过一遍四十多个 Skill 里深度嵌入的有五个场景触发的有四个剩下的全部归入后两类。3.3 第三步合并同类项删完之后我发现剩下九个 Skill 里有两个功能高度重叠。一个是通用的代码格式化Skill一个是针对特定语言的代码风格检查Skill。这两个在实际使用中经常同时触发输出内容也有大量重复。我把它们合并成了一个 Skill在SKILL.md里用条件分支处理不同语言的格式化需求。合并之后不仅减少了触发冲突维护起来也简单多了——只需要维护一个文件不用在两个文件之间同步配置。同类项合并的原则是如果两个 Skill 的触发场景有超过百分之五十的重叠就应该考虑合并。合并的方式可以是在一个SKILL.md里写多个分支也可以是提取公共逻辑做成一个基础 Skill然后让其他 Skill 引用它。3.4 第四步建立试用期机制删完之后我给自己定了一个规矩任何新 Skill 都要经过两周试用期试用期内如果触发次数少于三次直接删除。这个机制解决了我之前装了就不舍得删的问题。以前我总觉得删了可惜万一以后用得上呢。现在有了明确的试用期和量化标准决策就变得简单了——数据说话不用纠结。试用期机制还有一个好处它迫使我在装 Skill 之前先想清楚我到底要用它解决什么问题。如果我说不出一个具体的、高频的使用场景那我就不装。这个前置思考本身就过滤掉了大量冲动安装。4. 留下来的那几个 Skill凭什么值得留4.1 留下来的共同特征我最后留下的九个 Skill回头看它们有几个共同特征。第一个特征是解决的是高频重复问题。比如我有一个 Skill 是专门处理项目初始化配置的每次新建项目都要用一周至少触发两三次。这种高频重复的任务Skill 带来的效率提升是实实在在的。第二个特征是输出格式有严格要求。比如我有一个 Skill 是生成特定格式的周报的它规定了固定的结构、字段和措辞风格。这种任务如果不用 Skill我每次都要手动调整格式很烦。用了 Skill 之后一句话就能生成符合要求的输出。第三个特征是包含了我个人的经验沉淀。比如我有一个 Skill 里写了很多我自己总结的代码审查要点这些要点是通用的代码审查工具不会告诉我的是我在具体项目中踩坑总结出来的。这种带有个人经验的 Skill价值远高于通用的、从网上随便下载的 Skill。4.2 一个具体案例我的项目初始化Skill拿我的项目初始化Skill 举例说说它为什么值得留。这个 Skill 做的事情很简单当我新建一个项目时它会自动生成一套标准的目录结构、配置文件、以及初始的 README。听起来没什么特别的但关键在于它包含了我过去几年积累的一套项目规范。比如目录结构我会根据项目类型自动选择不同的模板——前端项目用一套后端项目用另一套全栈项目用第三套。配置文件里预置了我常用的 lint 规则、格式化配置、以及 CI 模板。README 里自动填充了项目名称、描述、以及我惯用的章节结构。这个 Skill 我每周至少用两次每次能省下大概十五分钟的初始化时间。一个月就是两个小时三个月就是六个小时。这六个小时是实打实省下来的而且省下来的时间我用在了更有价值的事情上。更重要的是这个 Skill 保证了我所有项目的结构一致性。以前我手动初始化项目的时候每次都会有些细微差别时间长了之后维护起来很痛苦。现在有了统一的 Skill所有项目从第一天起就是一致的。4.3 另一个案例我的去 AI 味Skill去 AI 味这个需求在热词里出现过我也有一个类似的 Skill但我的做法可能跟大多数人不一样。大多数去 AI 味Skill 的做法是给一堆规则比如不要用总之不要用综上所述不要用通过...可以...。这些规则有用但不够。因为 AI 味不只是词汇问题更是节奏问题和逻辑问题。我的 Skill 里除了词汇黑名单还加了几条更本质的规则段落长度要参差不齐不能每段都是四五行逻辑连接要自然不能每段开头都是首先其次最后要有个人视角不能全是客观陈述。这几条规则是我在大量实践中总结出来的。单纯删掉几个词文章读起来还是像 AI 写的。只有把节奏和视角也调整了才能真正去掉 AI 味。这个 Skill 我几乎每天都在用因为它嵌入到了我所有的写作流程里。4.4 被删掉的那些问题出在哪反过来看被删掉的那些 Skill问题主要出在三个地方。第一个问题是场景太窄。比如我装过一个生成特定格式的会议纪要的 Skill但我一个月才开两三次需要正式纪要的会而且每次的格式要求还不一样。这个 Skill 的触发频率太低维护成本却很高最后只能删掉。第二个问题是通用性太强反而没用。我装过一个通用代码优化Skill它的规则很宽泛比如减少重复代码提高可读性。这些建议我自己就知道不需要 Skill 来提醒。真正有用的 Skill 应该是针对具体场景的比如优化 React 组件的重渲染问题而不是泛泛的优化代码。第三个问题是跟我的工作流不匹配。我装过一个自动生成测试用例的 Skill但我的项目里测试用例的写法有特定规范这个 Skill 生成的用例不符合规范我每次都要手动改。改的时间比我自己写还长那这个 Skill 就是负价值。5. 如果你现在也在疯狂装 Skill我的建议5.1 先想清楚你的高频场景是什么在装任何 Skill 之前先花十分钟想清楚我每天、每周重复做的事情有哪些。把这些事情列出来然后看哪些是可以用 Skill 来优化的。比如你每天都要写代码注释那一个生成规范注释的 Skill 就值得装。比如你每周都要写周报那一个生成周报的 Skill 就值得装。但如果你只是偶尔写一次小说那写小说的 Skill 就不值得装——哪怕它看起来很有趣。这个前置思考能过滤掉百分之八十的冲动安装。我现在的做法是看到一个有意思的 Skill先记在备忘录里过一周再看。如果一周后我还觉得需要它并且能说出具体的使用场景我才去装。大部分 Skill 在这一周里就被我遗忘了说明它们本来就不重要。5.2 从装转向写用了一段时间之后你会发现从网上装的 Skill 永远不如自己写的 Skill 好用。因为网上的 Skill 是通用方案而你的工作流是独特的。我现在留下来的九个 Skill 里有六个是我自己写的。这些自己写的 Skill 之所以好用是因为它们精确地匹配了我的工作习惯。比如我的项目初始化Skill里面的目录结构、配置模板、README 格式全是我自己多年积累下来的网上找不到一模一样的。写 Skill 的门槛其实不高。SKILL.md本质上就是一个结构化的提示词文件你只要能把你的工作流程用清晰的步骤描述出来就能写成一个 Skill。我建议你从最简单的开始——把你最常做的一件事的步骤写下来整理成SKILL.md的格式就是一个可用的 Skill 了。5.3 定期清理保持精简Skill 不是装得越多越好而是越精越好。我现在的做法是每个月做一次清理检查每个 Skill 的触发频率把低频的删掉。清理的时候有一个判断标准很好用如果这个 Skill 消失了我会不会觉得不方便。如果答案是不会那就删掉。如果答案是会我得手动做很多事那就留着。这个标准比看触发频率更准确因为它直接衡量了 Skill 的实际价值。有些 Skill 触发频率不高但每次触发都省了很多事这种就值得留。有些 Skill 触发频率很高但每次触发省的事很少这种也可以考虑删掉。5.4 注意 Skill 之间的冲突当你同时使用多个 Skill 时要注意它们之间可能存在的冲突。最常见的冲突是触发条件重叠和输出格式冲突。触发条件重叠的解决方法是明确优先级。在settings.json里可以配置 Skill 的加载顺序把更重要的 Skill 放在前面。或者在SKILL.md里写更精确的触发条件避免跟其他 Skill 撞车。输出格式冲突的解决方法是统一格式规范。如果你有多个 Skill 都会生成 Markdown 输出那就在所有 Skill 里使用同一套格式规范避免一个 Skill 输出用##另一个用###这种混乱。我自己的做法是维护一个格式规范文档所有自己写的 Skill 都引用这个文档里的格式要求。这样即使 Skill 数量增加输出格式也能保持一致。6. 删掉八成之后我的实际感受6.1 效率反而提高了删掉八成 Skill 之后我最直观的感受是 Claude Code 的响应变快了。之前挂载十几个 Skill 的时候每次启动都要加载一大堆配置上下文窗口被占用了不少。现在只剩九个 Skill启动快了很多处理任务时也更专注了。另一个感受是输出质量变稳定了。之前多个 Skill 同时触发的时候输出经常出现混乱——一会儿按这个 Skill 的格式一会儿按那个 Skill 的格式。现在 Skill 少了冲突少了输出质量反而更稳定了。6.2 对 Skill 的理解更深了删 Skill 的过程也是重新理解 Skill 的过程。我现在把 Skill 分成两类流程型 Skill和知识型 Skill。流程型 Skill 是帮你执行固定流程的比如项目初始化、代码格式化、周报生成。这类 Skill 的价值在于标准化和自动化适合高频重复的任务。知识型 Skill 是帮你应用特定知识的比如代码审查要点、写作规范、领域专业知识。这类 Skill 的价值在于把隐性知识显性化适合需要专业判断的任务。这两类 Skill 的维护方式不同。流程型 Skill 要随着流程变化及时更新知识型 Skill 要随着经验积累不断补充。分清楚类型之后管理起来就清晰多了。6.3 一个意外的收获删 Skill 的过程中我意外地发现了一个收获我开始更认真地对待每一个留下来的 Skill。以前 Skill 多的时候我对每个 Skill 都是差不多就行的态度。现在 Skill 少了我会认真打磨每一个留下来的 Skill把SKILL.md写得更精确把触发条件调得更准把输出格式定得更规范。这种少而精的态度反而让每个 Skill 的价值都最大化了。我现在用的这九个 Skill每一个都是我反复打磨过的用起来非常顺手。这比之前四十多个半吊子 Skill 的体验好太多了。7. 给不同阶段使用者的具体建议7.1 刚入门先别急着装如果你刚开始用 Claude Code我的建议是先别急着装 Skill。先用原生的 Claude Code 工作一到两周感受一下它的默认行为看看哪些地方让你觉得不方便。这一到两周的裸奔体验非常重要因为它帮你建立了基准线。有了基准线之后你才知道哪些 Skill 是真正能帮到你的哪些是可有可无的。我见过太多人一上来就装几十个 Skill结果根本分不清哪些 Skill 在起作用哪些在捣乱。先裸奔再按需装这个顺序不能反。7.2 进阶从写自己的 Skill 开始如果你已经用了一段时间对 Claude Code 的行为比较熟悉了那就可以开始写自己的 Skill 了。从最简单的开始——把你最常做的一件事的步骤写下来整理成SKILL.md。不用追求完美先跑通再说。跑通之后你会发现自己写的 Skill 比网上装的更贴合你的需求。写 Skill 的过程中你会被迫把自己的工作流程梳理清楚。这个梳理过程本身就有价值即使最后 Skill 没写成你对工作流程的理解也会更深。7.3 重度用户建立 Skill 管理体系如果你已经是一个重度用户Skill 数量超过二十个那我建议你建立一套管理体系。这套体系包括定期清理机制每月检查触发频率、版本控制用 git 管理你的 Skill 文件、格式规范统一所有 Skill 的输出格式、冲突检测定期检查 Skill 之间的触发冲突。这套体系听起来麻烦但一旦建立起来维护成本会大幅降低。我现在每个月花在 Skill 管理上的时间不超过半小时但省下来的效率提升是巨大的。8. 关于 Skill 的几个常见误区8.1 误区一Skill 越多能力越强这是最大的误区。Skill 不会增强 Claude 的基础能力它只是约束 Claude 在特定场景下的行为。装一百个 SkillClaude 的基础能力还是那些只是行为被约束了一百种方式。而且 Skill 多了之后约束之间会互相冲突反而导致行为混乱。所以 Skill 的价值不在数量在质量。8.2 误区二网上的 Skill 拿来就能用网上的 Skill 是别人根据自己的工作流写的跟你的工作流大概率不匹配。直接拿来用往往需要大量调整才能适配。我的建议是把网上的 Skill 当参考不要当成品。看看别人是怎么组织SKILL.md的怎么定义触发条件的怎么设计输出格式的。学到方法之后写自己的 Skill。8.3 误区三Skill 装完就不用管了Skill 是需要维护的。Claude Code 版本更新、你的工作流变化、项目结构调整都可能导致 Skill 失效或效果下降。我现在每个月会花半小时检查所有 Skill 的状态确保它们还能正常工作。这个维护成本是必须的不维护的话Skill 会慢慢变成负担。8.4 误区四所有任务都适合用 Skill不是所有任务都适合用 Skill。Skill 最适合的是高频、重复、有固定流程的任务。对于一次性的、需要灵活判断的任务用 Skill 反而会限制 Claude 的发挥。比如写一篇创意文案这种任务需要灵活性和创造性用 Skill 约束反而不好。但如果是生成一份固定格式的报告那用 Skill 就非常合适。判断标准很简单如果这个任务你每次的做法都差不多那就适合用 Skill如果每次的做法都不一样那就不适合。9. 我现在的 Skill 配置长什么样9.1 目录结构我现在的 Skill 目录结构是这样的~/.claude/skills/ ├── project-init/ │ ├── SKILL.md │ └── templates/ ├── code-review/ │ └── SKILL.md ├── weekly-report/ │ ├── SKILL.md │ └── template.md ├── deai-writing/ │ └── SKILL.md ├── format-code/ │ └── SKILL.md ├── doc-generator/ │ ├── SKILL.md │ └── templates/ ├── test-helper/ │ └── SKILL.md ├── git-commit/ │ └── SKILL.md └── meeting-notes/ ├── SKILL.md └── template.md九个 Skill每个都有明确的职责互不重叠。settings.json里按优先级顺序引用这些 Skill确保触发时不会冲突。9.2 每个 Skill 的定位简单说一下每个 Skill 的定位project-init新建项目时自动生成标准结构每周用两三次code-review代码审查包含我个人总结的审查要点每天用weekly-report生成周报每周用一次deai-writing去 AI 味写作辅助每天用format-code代码格式化每天用doc-generator生成项目文档每周用一两次test-helper辅助写测试用例每周用两三次git-commit生成规范的 commit message每天用meeting-notes整理会议纪要每周用一两次这九个 Skill 覆盖了我日常工作的主要场景每个都有明确的使用频率和场景。没有一个是可能用得上的全都是确实在用的。9.3 配置文件的精简settings.json里我只保留了必要的配置。之前挂载四十多个 Skill 的时候配置文件有上百行现在精简到了三十行左右。精简配置的好处不只是好看更重要的是减少了出错的可能。配置文件越复杂越容易出问题。现在这个配置我一眼就能看完有什么问题也能快速定位。10. 最后说几句实在的Skill 这个东西本质上是一个效率工具。工具的价值在于使用不在于拥有。你装了四十个 Skill 但只用其中五个那另外三十五个对你来说就是负担不是资产。我这三个月最大的收获不是学会了怎么装 Skill而是学会了怎么删 Skill。删的过程比装的过程更有价值因为它迫使你面对一个事实你真正需要的东西比你以为的少得多。如果你现在也在疯狂装 Skill我建议你停下来翻翻过去一个月的使用记录看看哪些 Skill 真正被触发过。然后狠下心把那些没被触发的删掉。删完之后你会发现不仅效率没下降反而因为干扰少了工作更专注了。至于那些被删掉的 Skill如果以后真的需要再装回来就是了。安装成本那么低没必要为了万一而保留一堆噪音。