1. 从装Skill上瘾到删到只剩骨架一个真实的心路历程三个月前我的 Claude Code 配置目录里躺着四十多个 Skill。每次看到社区里有人分享新的 SKILL.md我就忍不住 clone 下来塞进~/.claude/skills/。那段时间我的状态可以用四个字概括——收藏即学会。直到某天我让 Claude Code 帮我改一个正则表达式它居然先调用了一个代码风格检查 Skill又触发了一个文档生成 Skill最后还试图用一个Git 提交规范 Skill来给我写 commit message。一个本该三十秒解决的问题硬是绕了两分钟。那一刻我意识到Skill 不是越多越好而是越精准越好。于是我花了整整一个周末把四十多个 Skill 逐一审查、测试、归类最终只保留了 8 个。删掉的 80% 里有的是功能重复有的是触发条件过于宽泛导致误触发有的纯粹是我当时觉得有用但三个月一次都没真正用上。这篇文章就是那次大清理的完整复盘。我会讲清楚Skill 的触发机制到底是怎么回事、为什么装多了反而会互相干扰、怎么判断一个 Skill 该留还是该删、保留下来的那 8 个分别解决了什么问题以及settings.json和SKILL.md里那些容易被忽略但极其关键的配置细节。如果你也在用 Claude Code 并且 Skill 目录已经开始膨胀这篇内容应该能帮你省下不少试错时间。2. Skill 的触发机制为什么装多了会互相打架2.1 SKILL.md 的 description 字段才是真正的开关很多人以为 Skill 是靠名字来匹配的其实不是。Claude Code 在决定是否调用某个 Skill 时主要依据的是SKILL.md文件头部 YAML frontmatter 里的description字段。这个字段的写法直接决定了 Skill 的触发范围。我举个真实的例子。之前我装了一个叫code-review的 Skill它的 description 写的是帮助审查代码质量。看起来没问题对吧但实际使用中只要我让 Claude Code 看任何一段代码它都会触发这个 Skill。因为看代码和审查代码在语义上太接近了模型无法区分我只是想让它读一下代码还是要做质量审查。后来我把 description 改成了当用户明确要求进行代码审查、检查代码规范、或寻找潜在 bug 时使用触发频率立刻降到了合理水平。description 的写法本质上是在给模型划边界——你划得越模糊误触发就越多。2.2 多个 Skill 同时命中时的优先级混乱当你装了多个 Skill且它们的 description 存在语义重叠时Claude Code 并不会智能地选一个最合适的而是可能同时加载多个 Skill 的上下文。这就导致了一个严重问题上下文窗口被大量 Skill 指令占据真正用于处理你任务的 token 反而变少了。我实测过一组数据。在装 40 个 Skill 的情况下一次简单的帮我写个 Python 脚本读取 CSV请求Claude Code 加载了 3 个 Skill 的完整内容消耗了大约 4000 个 token 在 Skill 指令上。删到 8 个之后同样的请求只加载了 0 到 1 个 Skilltoken 消耗降到 500 以内。这意味着留给实际任务的上下文空间多了 3500 token对于复杂任务来说这个差距非常明显。2.3 那些看起来有用但实际从不触发的 Skill删掉的 32 个 Skill 里有将近一半属于装了但从没被触发过的类型。比如我装过一个生成 API 文档的 Skill但我平时写文档都是用专门的文档工具根本不会在 Claude Code 里做这件事。还有一个数据库迁移脚本生成的 Skill我三个月里只做过一次数据库迁移而且那次用的还是手写 SQL。这类 Skill 的问题在于它们占据了我的认知带宽却没有产生实际价值。每次打开 Skill 目录看到它们我都会想这个以后可能会用到但以后从来没有来过。判断标准很简单如果一个 Skill 在过去一个月里没有被触发过且你也想不出下周会在什么场景下用到它那它就该被删掉。3. 我保留的 8 个 Skill 及各自的不可替代性3.1 代码格式化与 lint 修复 Skill这是使用频率最高的一个。它的 description 我写得很窄当用户要求格式化代码、修复 lint 错误、或统一代码风格时使用。触发场景非常明确不会误触发。这个 Skill 的核心价值在于它内置了我团队的代码规范——缩进用 2 空格还是 4 空格、import 排序规则、命名约定等。每次触发时Claude Code 会按照这些规则直接修改代码而不是给我建议让我自己改。省掉的是它说一句我改一句的来回确认时间。3.2 Git 提交信息生成 Skill这个 Skill 我犹豫了很久要不要留。最终留下的原因是它解决了一个我每天都要做但每次都要想一下的问题——写 commit message。它的 description 是当用户要求生成 git commit message 或准备提交代码时使用。触发后它会读取 staged 的 diff按照 Conventional Commits 规范生成提交信息。关键细节是我在 SKILL.md 里明确写了不要生成 body 部分只生成一行 subject因为我的团队不需要详细的 commit body。这种个性化配置是通用工具做不到的。3.3 终端命令安全审查 Skill这个 Skill 的触发条件我设置得比较特殊——它不是靠 description 匹配的而是在settings.json里配置了 hook当 Claude Code 准备执行某些危险命令如rm -rf、git push --force、DROP TABLE时强制触发。它的作用是在命令真正执行前弹出确认提示并解释这条命令的影响范围。我承认这有点过度谨慎但自从有一次它拦住了一条我手滑写错的rm命令之后我就决定永久保留它。3.4 项目上下文加载 Skill这个 Skill 比较特殊它不执行任何具体操作而是在我打开一个新项目时自动读取项目根目录下的CLAUDE.md、README.md和package.json或pyproject.toml把关键信息注入到对话上下文中。它的价值在于省掉了我每次都要手动告诉 Claude Code这个项目用什么框架、用什么包管理器、测试怎么跑的时间。description 写的是当用户打开新项目或切换工作目录时使用触发时机很明确。3.5 测试用例生成 Skill这个 Skill 我设置了一个硬性约束只在用户明确说写测试或生成测试用例时触发。它内置了我常用的测试框架模板pytest、jest、vitest并且会根据被测代码的导入关系自动推断需要 mock 的依赖。删掉的其他测试相关 Skill 有 3 个它们的功能分别是测试覆盖率分析测试重构建议测试数据生成。删掉的原因很简单这三个功能我三个月里一次都没用过而生成测试用例每周至少用两次。3.6 文档字符串生成 Skill这个 Skill 专门用来给函数和类生成 docstring。它的 description 写得很具体当用户要求为函数或类添加文档字符串、或要求生成 API 文档注释时使用。我保留它的原因是写 docstring 是一件我知道该写但懒得写的事情。有了这个 Skill我只需要选中代码说一句加 docstring它就会按照 Google Style 生成完整的参数说明、返回值说明和异常说明。它解决的不是技术问题而是心理阻力问题。3.7 依赖版本检查 Skill这个 Skill 会读取项目中的依赖文件检查是否有已知的安全漏洞或版本冲突。触发条件是当用户要求检查依赖版本、更新依赖、或排查依赖冲突时使用。我保留它是因为它帮我避免了一次生产事故——它在一次例行检查中发现某个间接依赖的版本存在已知问题而这个问题在我手动检查时被忽略了。这种定期体检类的 Skill价值不在于频繁使用而在于关键时刻能兜底。3.8 自定义代码片段插入 Skill这是我自己写的一个 Skill功能非常简单当我输入特定的触发词如snippet:react-component时它会把预定义的代码模板插入到当前文件中。模板包括 React 函数组件、Python 类定义、FastAPI 路由等。它的不可替代性在于完全个性化——这些模板是我根据自己项目的实际结构定制的任何通用工具都无法替代。description 写的是当用户输入 snippet: 开头的指令时使用触发条件精确到不可能误触发。4. 删掉的那 32 个 Skill 都长什么样4.1 功能重复型同一件事有三个 Skill 在做删掉的 Skill 里有 6 个属于功能重复。比如代码审查这个功能我同时装了code-review、code-quality-check和lint-review三个 Skill。它们的 description 都涉及检查代码质量导致每次我让 Claude Code 看代码时三个 Skill 都有可能被触发互相干扰。类似的还有文档生成——我装了doc-generator、api-doc-writer和readme-builder三个。实际上我只需要一个能生成 docstring 的 Skill 就够了README 我都是手写的。判断标准如果你能用一句话描述两个 Skill 的共同功能那它们就是重复的留一个就够了。4.2 触发条件过宽型什么都能触发等于什么都触发不了有一个 Skill 叫general-helperdescription 写的是帮助解决各种编程问题。这个 Skill 几乎在我每次对话时都会被触发因为它太万能了。但它的内容其实只是一些通用的编程建议没有任何特异性。还有一个叫smart-assistant的 Skilldescription 是智能辅助编程。我到现在都不确定它到底做了什么因为它的指令内容非常泛化基本上就是你要仔细思考、认真回答之类的废话。这类 Skill 的唯一作用就是浪费上下文窗口。4.3 场景过于垂直型三个月用不上一次我删掉了一个SolidWorks 插件开发的 Skill因为我在装它的那一周确实在做一个 SolidWorks 相关的项目但项目结束后就再也没碰过。类似的还有像素动画生成打斗动作提示词生成AI 备课等 Skill——它们都是我在特定场景下装的场景过去后就成了死重。这里有一个反直觉的结论垂直 Skill 的价值密度很高但适用频率极低。如果你不是每天都在做同一件垂直的事情那这类 Skill 更适合用的时候再装而不是先装着备用。4.4 质量存疑型从社区 clone 下来但从未验证删掉的 Skill 里有 8 个是从社区 clone 下来的我承认当时只是看了 README 觉得不错就装了从来没有认真读过它们的 SKILL.md 内容。后来清理时打开一看有的 SKILL.md 只有三行字有的指令写得含糊不清还有一个居然引用了不存在的文件路径。从社区获取 Skill 时一定要先读一遍 SKILL.md 的完整内容再决定是否保留。一个写得好的 Skill它的指令应该是具体、可执行、有明确边界的。如果 SKILL.md 里全是你要认真思考你要仔细分析这类空话那这个 Skill 基本没有价值。5. 清理 Skill 的具体操作流程5.1 先做一次触发日志审计Claude Code 本身不提供 Skill 触发日志但你可以通过settings.json里的 hook 机制来记录。我的做法是在settings.json中添加一个PreToolUsehook当 Skill 被触发时把 Skill 名称和时间戳追加写入一个日志文件。配置大概长这样{ hooks: { PreToolUse: [ { matcher: Skill, command: echo \$(date %Y-%m-%dT%H:%M:%S) $CLAUDE_TOOL_INPUT\ ~/.claude/skill-trigger.log } ] } }跑一周之后打开skill-trigger.log看一眼哪些 Skill 从没出现过、哪些 Skill 每天触发十几次一目了然。数据比感觉可靠得多——我原本以为文档生成 Skill 我经常用结果日志显示它一周只触发了两次。5.2 按最近触发时间排序从最久未触发的开始删拿到日志后把所有 Skill 按最后触发时间排序。我的删除策略是超过 30 天未触发直接删不要犹豫7 到 30 天未触发标记为观察期如果接下来两周还没触发就删7 天内触发过保留但检查是否有功能重复这个策略帮我快速砍掉了 20 多个 Skill。剩下十几个进入观察期的两周后又删掉了一半。5.3 合并功能重叠的 Skill对于功能重叠的 Skill不要简单地留一个删一个而是考虑合并。比如我之前有三个和代码质量相关的 Skill我把它们的有用部分提取出来合并成了一个code-qualitySkilldescription 写清楚它覆盖的具体场景格式化、lint 修复、命名规范检查这样既保留了功能又避免了重复触发。合并后的 SKILL.md 结构大概是--- name: code-quality description: 当用户要求格式化代码、修复 lint 错误、检查命名规范、或统一代码风格时使用 --- ## 格式化规则 - 缩进2 空格 - 行宽100 字符 ... ## Lint 修复流程 1. 先运行项目配置的 linter 2. 根据输出逐条修复 ... ## 命名规范 - 变量camelCase - 常量UPPER_SNAKE_CASE ...5.4 删完之后重新审视 settings.jsonSkill 删完后记得检查settings.json里是否还有引用已删除 Skill 的配置。特别是有 hook 配置的情况下如果 hook 指向了一个不存在的 Skill可能会导致 Claude Code 报错或行为异常。我的settings.json在清理后精简了很多主要保留了这几块{ skills: { directory: ~/.claude/skills, autoLoad: true }, hooks: { PreToolUse: [ { matcher: Bash, command: ~/.claude/hooks/command-safety-check.sh } ] } }注意不同版本的 Claude Code 对settings.json的字段支持可能不同建议先查阅官方文档确认当前版本支持的配置项不要直接照搬网上的配置。6. 三个月使用下来总结的 Skill 管理原则6.1 一个 Skill 只做一件事description 要窄到不可能误触发这是最重要的一条原则。好的 Skill 应该像一把手术刀而不是瑞士军刀。description 的写法要具体到当用户说 X 的时候使用而不是当用户需要 X 相关帮助时使用。我现在的做法是写完 description 后自己读一遍然后问自己如果用户只是随便聊到相关话题这个 Skill 会不会被触发如果答案是可能会那就继续收窄。6.2 新 Skill 先试用期两周内没触发就删我现在装新 Skill 的流程是先装然后在日历上设一个两周后的提醒。两周后如果这个 Skill 一次都没触发过直接删不给自己以后可能用到的借口。这个习惯帮我避免了很多收藏即学会的无效积累。Skill 的价值在于被使用而不是被拥有。6.3 定期审计建议每月一次Skill 目录需要像衣柜一样定期整理。我现在的习惯是每个月最后一个周五花半小时做一次 Skill 审计看触发日志、检查功能重复、删除未使用的。这个投入产出比非常高——半小时的整理能换来接下来一个月更流畅的使用体验。6.4 不要从社区盲目 clone先读 SKILL.md 再决定社区里的 Skill 质量参差不齐。我现在 clone 任何 Skill 之前都会先在浏览器里打开它的 SKILL.md 看一遍。重点看三个东西description 写得是否具体、指令内容是否可执行、有没有引用不存在的文件或工具。如果 SKILL.md 读起来像鸡汤那这个 Skill 大概率没有实际价值。7. 关于 Skill 编码和插件生态的一些观察最近社区里出现了很多关于 Skill 编码、Skill 插件的讨论比如skill 编码 247skill 编码 193这类说法。我理解这指的是某些 Skill 在特定编码体系下的分类编号但说实话编号本身并不重要重要的是这个 Skill 解决的具体问题是否匹配你的实际需求。我也看到有人在讨论去 AI 味的 Skill狗头军师 Skillworkbuddy Skill这类偏趣味性的 Skill。这些 Skill 不是没有价值——它们能让 Claude Code 的输出更符合个人风格或者增加一些交互趣味性。但我的建议是先把功能性 Skill 管理好再考虑这类风格化 Skill。否则你的 Skill 目录会变成一个什么都有一点但什么都不精的大杂烩。另外关于npx skills这个命令它确实提供了一种快速安装 Skill 的方式但我的经验是安装越方便越容易装多。我现在已经不用npx skills批量安装了而是手动把需要的 Skill 复制到~/.claude/skills/目录下这样每装一个都会经过一次我真的需要它吗的思考。8. 我个人的一些实操体会删掉 80% 的 Skill 之后最直观的变化是 Claude Code 的响应变快了而且它跑偏的概率明显降低。以前它经常在我没要求的情况下触发某个 Skill然后按照 Skill 的指令做一堆我不需要的事情。现在这种情况基本消失了。另一个体会是Skill 的质量远比数量重要。我保留的 8 个 Skill 里有 3 个是我自己根据实际需求写的它们的价值远高于从社区 clone 下来的那些。如果你发现现有的 Skill 都不能很好地满足你的需求不妨自己写一个——SKILL.md 的格式并不复杂核心就是把什么时候触发和触发后做什么这两件事写清楚。最后分享一个小技巧我会在~/.claude/skills/目录下建一个_archive子目录把暂时删掉但可能以后会用到的 Skill 移进去。这样既清理了活跃目录又不会真的丢失。三个月下来_archive里的 Skill 我一个都没有再移回来过——这反过来验证了当初删掉它们的决定是正确的。
Claude Code Skill 精简指南：从40个删到8个的实战复盘
1. 从装Skill上瘾到删到只剩骨架一个真实的心路历程三个月前我的 Claude Code 配置目录里躺着四十多个 Skill。每次看到社区里有人分享新的 SKILL.md我就忍不住 clone 下来塞进~/.claude/skills/。那段时间我的状态可以用四个字概括——收藏即学会。直到某天我让 Claude Code 帮我改一个正则表达式它居然先调用了一个代码风格检查 Skill又触发了一个文档生成 Skill最后还试图用一个Git 提交规范 Skill来给我写 commit message。一个本该三十秒解决的问题硬是绕了两分钟。那一刻我意识到Skill 不是越多越好而是越精准越好。于是我花了整整一个周末把四十多个 Skill 逐一审查、测试、归类最终只保留了 8 个。删掉的 80% 里有的是功能重复有的是触发条件过于宽泛导致误触发有的纯粹是我当时觉得有用但三个月一次都没真正用上。这篇文章就是那次大清理的完整复盘。我会讲清楚Skill 的触发机制到底是怎么回事、为什么装多了反而会互相干扰、怎么判断一个 Skill 该留还是该删、保留下来的那 8 个分别解决了什么问题以及settings.json和SKILL.md里那些容易被忽略但极其关键的配置细节。如果你也在用 Claude Code 并且 Skill 目录已经开始膨胀这篇内容应该能帮你省下不少试错时间。2. Skill 的触发机制为什么装多了会互相打架2.1 SKILL.md 的 description 字段才是真正的开关很多人以为 Skill 是靠名字来匹配的其实不是。Claude Code 在决定是否调用某个 Skill 时主要依据的是SKILL.md文件头部 YAML frontmatter 里的description字段。这个字段的写法直接决定了 Skill 的触发范围。我举个真实的例子。之前我装了一个叫code-review的 Skill它的 description 写的是帮助审查代码质量。看起来没问题对吧但实际使用中只要我让 Claude Code 看任何一段代码它都会触发这个 Skill。因为看代码和审查代码在语义上太接近了模型无法区分我只是想让它读一下代码还是要做质量审查。后来我把 description 改成了当用户明确要求进行代码审查、检查代码规范、或寻找潜在 bug 时使用触发频率立刻降到了合理水平。description 的写法本质上是在给模型划边界——你划得越模糊误触发就越多。2.2 多个 Skill 同时命中时的优先级混乱当你装了多个 Skill且它们的 description 存在语义重叠时Claude Code 并不会智能地选一个最合适的而是可能同时加载多个 Skill 的上下文。这就导致了一个严重问题上下文窗口被大量 Skill 指令占据真正用于处理你任务的 token 反而变少了。我实测过一组数据。在装 40 个 Skill 的情况下一次简单的帮我写个 Python 脚本读取 CSV请求Claude Code 加载了 3 个 Skill 的完整内容消耗了大约 4000 个 token 在 Skill 指令上。删到 8 个之后同样的请求只加载了 0 到 1 个 Skilltoken 消耗降到 500 以内。这意味着留给实际任务的上下文空间多了 3500 token对于复杂任务来说这个差距非常明显。2.3 那些看起来有用但实际从不触发的 Skill删掉的 32 个 Skill 里有将近一半属于装了但从没被触发过的类型。比如我装过一个生成 API 文档的 Skill但我平时写文档都是用专门的文档工具根本不会在 Claude Code 里做这件事。还有一个数据库迁移脚本生成的 Skill我三个月里只做过一次数据库迁移而且那次用的还是手写 SQL。这类 Skill 的问题在于它们占据了我的认知带宽却没有产生实际价值。每次打开 Skill 目录看到它们我都会想这个以后可能会用到但以后从来没有来过。判断标准很简单如果一个 Skill 在过去一个月里没有被触发过且你也想不出下周会在什么场景下用到它那它就该被删掉。3. 我保留的 8 个 Skill 及各自的不可替代性3.1 代码格式化与 lint 修复 Skill这是使用频率最高的一个。它的 description 我写得很窄当用户要求格式化代码、修复 lint 错误、或统一代码风格时使用。触发场景非常明确不会误触发。这个 Skill 的核心价值在于它内置了我团队的代码规范——缩进用 2 空格还是 4 空格、import 排序规则、命名约定等。每次触发时Claude Code 会按照这些规则直接修改代码而不是给我建议让我自己改。省掉的是它说一句我改一句的来回确认时间。3.2 Git 提交信息生成 Skill这个 Skill 我犹豫了很久要不要留。最终留下的原因是它解决了一个我每天都要做但每次都要想一下的问题——写 commit message。它的 description 是当用户要求生成 git commit message 或准备提交代码时使用。触发后它会读取 staged 的 diff按照 Conventional Commits 规范生成提交信息。关键细节是我在 SKILL.md 里明确写了不要生成 body 部分只生成一行 subject因为我的团队不需要详细的 commit body。这种个性化配置是通用工具做不到的。3.3 终端命令安全审查 Skill这个 Skill 的触发条件我设置得比较特殊——它不是靠 description 匹配的而是在settings.json里配置了 hook当 Claude Code 准备执行某些危险命令如rm -rf、git push --force、DROP TABLE时强制触发。它的作用是在命令真正执行前弹出确认提示并解释这条命令的影响范围。我承认这有点过度谨慎但自从有一次它拦住了一条我手滑写错的rm命令之后我就决定永久保留它。3.4 项目上下文加载 Skill这个 Skill 比较特殊它不执行任何具体操作而是在我打开一个新项目时自动读取项目根目录下的CLAUDE.md、README.md和package.json或pyproject.toml把关键信息注入到对话上下文中。它的价值在于省掉了我每次都要手动告诉 Claude Code这个项目用什么框架、用什么包管理器、测试怎么跑的时间。description 写的是当用户打开新项目或切换工作目录时使用触发时机很明确。3.5 测试用例生成 Skill这个 Skill 我设置了一个硬性约束只在用户明确说写测试或生成测试用例时触发。它内置了我常用的测试框架模板pytest、jest、vitest并且会根据被测代码的导入关系自动推断需要 mock 的依赖。删掉的其他测试相关 Skill 有 3 个它们的功能分别是测试覆盖率分析测试重构建议测试数据生成。删掉的原因很简单这三个功能我三个月里一次都没用过而生成测试用例每周至少用两次。3.6 文档字符串生成 Skill这个 Skill 专门用来给函数和类生成 docstring。它的 description 写得很具体当用户要求为函数或类添加文档字符串、或要求生成 API 文档注释时使用。我保留它的原因是写 docstring 是一件我知道该写但懒得写的事情。有了这个 Skill我只需要选中代码说一句加 docstring它就会按照 Google Style 生成完整的参数说明、返回值说明和异常说明。它解决的不是技术问题而是心理阻力问题。3.7 依赖版本检查 Skill这个 Skill 会读取项目中的依赖文件检查是否有已知的安全漏洞或版本冲突。触发条件是当用户要求检查依赖版本、更新依赖、或排查依赖冲突时使用。我保留它是因为它帮我避免了一次生产事故——它在一次例行检查中发现某个间接依赖的版本存在已知问题而这个问题在我手动检查时被忽略了。这种定期体检类的 Skill价值不在于频繁使用而在于关键时刻能兜底。3.8 自定义代码片段插入 Skill这是我自己写的一个 Skill功能非常简单当我输入特定的触发词如snippet:react-component时它会把预定义的代码模板插入到当前文件中。模板包括 React 函数组件、Python 类定义、FastAPI 路由等。它的不可替代性在于完全个性化——这些模板是我根据自己项目的实际结构定制的任何通用工具都无法替代。description 写的是当用户输入 snippet: 开头的指令时使用触发条件精确到不可能误触发。4. 删掉的那 32 个 Skill 都长什么样4.1 功能重复型同一件事有三个 Skill 在做删掉的 Skill 里有 6 个属于功能重复。比如代码审查这个功能我同时装了code-review、code-quality-check和lint-review三个 Skill。它们的 description 都涉及检查代码质量导致每次我让 Claude Code 看代码时三个 Skill 都有可能被触发互相干扰。类似的还有文档生成——我装了doc-generator、api-doc-writer和readme-builder三个。实际上我只需要一个能生成 docstring 的 Skill 就够了README 我都是手写的。判断标准如果你能用一句话描述两个 Skill 的共同功能那它们就是重复的留一个就够了。4.2 触发条件过宽型什么都能触发等于什么都触发不了有一个 Skill 叫general-helperdescription 写的是帮助解决各种编程问题。这个 Skill 几乎在我每次对话时都会被触发因为它太万能了。但它的内容其实只是一些通用的编程建议没有任何特异性。还有一个叫smart-assistant的 Skilldescription 是智能辅助编程。我到现在都不确定它到底做了什么因为它的指令内容非常泛化基本上就是你要仔细思考、认真回答之类的废话。这类 Skill 的唯一作用就是浪费上下文窗口。4.3 场景过于垂直型三个月用不上一次我删掉了一个SolidWorks 插件开发的 Skill因为我在装它的那一周确实在做一个 SolidWorks 相关的项目但项目结束后就再也没碰过。类似的还有像素动画生成打斗动作提示词生成AI 备课等 Skill——它们都是我在特定场景下装的场景过去后就成了死重。这里有一个反直觉的结论垂直 Skill 的价值密度很高但适用频率极低。如果你不是每天都在做同一件垂直的事情那这类 Skill 更适合用的时候再装而不是先装着备用。4.4 质量存疑型从社区 clone 下来但从未验证删掉的 Skill 里有 8 个是从社区 clone 下来的我承认当时只是看了 README 觉得不错就装了从来没有认真读过它们的 SKILL.md 内容。后来清理时打开一看有的 SKILL.md 只有三行字有的指令写得含糊不清还有一个居然引用了不存在的文件路径。从社区获取 Skill 时一定要先读一遍 SKILL.md 的完整内容再决定是否保留。一个写得好的 Skill它的指令应该是具体、可执行、有明确边界的。如果 SKILL.md 里全是你要认真思考你要仔细分析这类空话那这个 Skill 基本没有价值。5. 清理 Skill 的具体操作流程5.1 先做一次触发日志审计Claude Code 本身不提供 Skill 触发日志但你可以通过settings.json里的 hook 机制来记录。我的做法是在settings.json中添加一个PreToolUsehook当 Skill 被触发时把 Skill 名称和时间戳追加写入一个日志文件。配置大概长这样{ hooks: { PreToolUse: [ { matcher: Skill, command: echo \$(date %Y-%m-%dT%H:%M:%S) $CLAUDE_TOOL_INPUT\ ~/.claude/skill-trigger.log } ] } }跑一周之后打开skill-trigger.log看一眼哪些 Skill 从没出现过、哪些 Skill 每天触发十几次一目了然。数据比感觉可靠得多——我原本以为文档生成 Skill 我经常用结果日志显示它一周只触发了两次。5.2 按最近触发时间排序从最久未触发的开始删拿到日志后把所有 Skill 按最后触发时间排序。我的删除策略是超过 30 天未触发直接删不要犹豫7 到 30 天未触发标记为观察期如果接下来两周还没触发就删7 天内触发过保留但检查是否有功能重复这个策略帮我快速砍掉了 20 多个 Skill。剩下十几个进入观察期的两周后又删掉了一半。5.3 合并功能重叠的 Skill对于功能重叠的 Skill不要简单地留一个删一个而是考虑合并。比如我之前有三个和代码质量相关的 Skill我把它们的有用部分提取出来合并成了一个code-qualitySkilldescription 写清楚它覆盖的具体场景格式化、lint 修复、命名规范检查这样既保留了功能又避免了重复触发。合并后的 SKILL.md 结构大概是--- name: code-quality description: 当用户要求格式化代码、修复 lint 错误、检查命名规范、或统一代码风格时使用 --- ## 格式化规则 - 缩进2 空格 - 行宽100 字符 ... ## Lint 修复流程 1. 先运行项目配置的 linter 2. 根据输出逐条修复 ... ## 命名规范 - 变量camelCase - 常量UPPER_SNAKE_CASE ...5.4 删完之后重新审视 settings.jsonSkill 删完后记得检查settings.json里是否还有引用已删除 Skill 的配置。特别是有 hook 配置的情况下如果 hook 指向了一个不存在的 Skill可能会导致 Claude Code 报错或行为异常。我的settings.json在清理后精简了很多主要保留了这几块{ skills: { directory: ~/.claude/skills, autoLoad: true }, hooks: { PreToolUse: [ { matcher: Bash, command: ~/.claude/hooks/command-safety-check.sh } ] } }注意不同版本的 Claude Code 对settings.json的字段支持可能不同建议先查阅官方文档确认当前版本支持的配置项不要直接照搬网上的配置。6. 三个月使用下来总结的 Skill 管理原则6.1 一个 Skill 只做一件事description 要窄到不可能误触发这是最重要的一条原则。好的 Skill 应该像一把手术刀而不是瑞士军刀。description 的写法要具体到当用户说 X 的时候使用而不是当用户需要 X 相关帮助时使用。我现在的做法是写完 description 后自己读一遍然后问自己如果用户只是随便聊到相关话题这个 Skill 会不会被触发如果答案是可能会那就继续收窄。6.2 新 Skill 先试用期两周内没触发就删我现在装新 Skill 的流程是先装然后在日历上设一个两周后的提醒。两周后如果这个 Skill 一次都没触发过直接删不给自己以后可能用到的借口。这个习惯帮我避免了很多收藏即学会的无效积累。Skill 的价值在于被使用而不是被拥有。6.3 定期审计建议每月一次Skill 目录需要像衣柜一样定期整理。我现在的习惯是每个月最后一个周五花半小时做一次 Skill 审计看触发日志、检查功能重复、删除未使用的。这个投入产出比非常高——半小时的整理能换来接下来一个月更流畅的使用体验。6.4 不要从社区盲目 clone先读 SKILL.md 再决定社区里的 Skill 质量参差不齐。我现在 clone 任何 Skill 之前都会先在浏览器里打开它的 SKILL.md 看一遍。重点看三个东西description 写得是否具体、指令内容是否可执行、有没有引用不存在的文件或工具。如果 SKILL.md 读起来像鸡汤那这个 Skill 大概率没有实际价值。7. 关于 Skill 编码和插件生态的一些观察最近社区里出现了很多关于 Skill 编码、Skill 插件的讨论比如skill 编码 247skill 编码 193这类说法。我理解这指的是某些 Skill 在特定编码体系下的分类编号但说实话编号本身并不重要重要的是这个 Skill 解决的具体问题是否匹配你的实际需求。我也看到有人在讨论去 AI 味的 Skill狗头军师 Skillworkbuddy Skill这类偏趣味性的 Skill。这些 Skill 不是没有价值——它们能让 Claude Code 的输出更符合个人风格或者增加一些交互趣味性。但我的建议是先把功能性 Skill 管理好再考虑这类风格化 Skill。否则你的 Skill 目录会变成一个什么都有一点但什么都不精的大杂烩。另外关于npx skills这个命令它确实提供了一种快速安装 Skill 的方式但我的经验是安装越方便越容易装多。我现在已经不用npx skills批量安装了而是手动把需要的 Skill 复制到~/.claude/skills/目录下这样每装一个都会经过一次我真的需要它吗的思考。8. 我个人的一些实操体会删掉 80% 的 Skill 之后最直观的变化是 Claude Code 的响应变快了而且它跑偏的概率明显降低。以前它经常在我没要求的情况下触发某个 Skill然后按照 Skill 的指令做一堆我不需要的事情。现在这种情况基本消失了。另一个体会是Skill 的质量远比数量重要。我保留的 8 个 Skill 里有 3 个是我自己根据实际需求写的它们的价值远高于从社区 clone 下来的那些。如果你发现现有的 Skill 都不能很好地满足你的需求不妨自己写一个——SKILL.md 的格式并不复杂核心就是把什么时候触发和触发后做什么这两件事写清楚。最后分享一个小技巧我会在~/.claude/skills/目录下建一个_archive子目录把暂时删掉但可能以后会用到的 Skill 移进去。这样既清理了活跃目录又不会真的丢失。三个月下来_archive里的 Skill 我一个都没有再移回来过——这反过来验证了当初删掉它们的决定是正确的。
