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 在特定场景下的行为。装一百个 Skill，Claude 的基础能力还是那些，只是行为被约束了一百种方式。

而且 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，如果以后真的需要，再装回来就是了。安装成本那么低，没必要为了"万一"而保留一堆噪音。