Skills 虽好，但真别啥都装：我踩过的 Claude Code 技能管理的坑

发表于 更新于 分类于 阅读次数： 本文字数： 4.6k 阅读时长 ≈ 4 分钟

cover

哈喽，我是飞飞。

前两天整理 Claude Code 的配置，打开全局 skills 文件夹一看，73 个。七十三个。

我自己都愣了。什么时候攒了这么多？

仔细回想了一下，大概是这么来的：先装了 superpowers 插件，一下子多了十几个 skill。觉得不错，又装了 gstack。然后飞书相关的 lark 系列，企业微信的 wecomcli 系列，Obsidian 系列……每个插件包里少则三四个，多则十几个 skill，像滚雪球一样越滚越大。

直到上周，我让 Claude 帮我写一个部署脚本，它居然先去调了 design-review 的 skill——一个检查 UI 设计质量的工具。我当时的表情大概是这样的：？？？

这件事让我意识到：Skills 装太多，Claude 会懵。

先说清楚：Skill 多了为什么会出问题

Claude Code 的 skill 机制是这样工作的：每个 skill 都有一个 SKILL.md 文件，里面的 description 字段会被加载到系统提示词里。Claude 根据这些描述来判断”当前任务该不该用这个 skill”。

问题来了。如果你装了 73 个 skill，系统提示词里就有 73 条 skill 描述。Claude 每次收到你的指令，都要扫一遍这 73 条，判断哪些相关、哪些不相关。

最直接的影响是上下文窗口被白白浪费了。73 条 skill 描述，每条少说几十个 token，加起来可能吃掉好几千 token。这些 token 本来可以用来理解你的代码、分析你的需求，现在全浪费在”扫描菜单”上了。

然后还有个更烦的事——选择多了，选错的概率也高。这不是 Claude 笨，是信息论的基本原理。73 个选项里挑一个正确的，比 8 个选项里挑一个正确的，出错概率就是高。MindStudio 有篇实测文章的结论很直接：一个项目里，活跃的 skill 控制在 5-8 个最好。超过这个数，模型表现反而下降。

最头疼的是skill 之间会打架。比如 superpowers 里有一个 requesting-code-review 的 skill，gstack 插件里也有类似的代码审查能力。Claude 不知道该听谁的，有时候两个都调一遍，有时候挑了个不太对的。我在社区里看到好几个人吐槽同样的问题。

我自己的翻车现场

说几个我实际遇到的情况。

场景一：写博客触发了安全审计。

我用 /writing-agent 写文章，写到一半，Claude 突然开始跑 cso（Chief Security Officer）skill 的流程——检查 OWASP Top 10 漏洞。一篇 Markdown 博客文章，查什么安全漏洞？

后来我想明白了，cso 的 description 里写的是”performs security review on code”，而我的 writing-agent 里有一步是生成代码块示例。Claude 看到了代码，就觉得应该审计一下。

场景二：部署脚本变成了设计评审。

前面提到的那次。我说”帮我写个 Docker 部署脚本”，Claude 先触发了 design-review。因为 design-review 的描述里包含”review”这个关键词，而我的提示词里可能也有类似的表述，Claude 就匹配上了。

场景三：飞书消息发到了企业微信。

我装了 lark-im（飞书即时通讯）和 wecomcli-get-msg（企业微信消息），两个都是”消息”相关的 skill。有一次我说”帮我查一下最近的消息”，Claude 用了企业微信的接口——但我当时想查的是飞书。

这些问题的根源都一样：skill 太多，描述有交叉，Claude 分不清该用哪个。

全局 Skill vs 项目 Skill：到底怎么分

Claude Code 的 skill 分两个层级：

  • 全局 skill：放在 ~/.claude/skills/ 下，所有项目共享
  • 项目 skill：放在项目目录的 .claude/skills/ 下，只对当前项目生效

我之前的做法是把所有 skill 都装在全局。想法很简单——装一次到处用，多省事。

现在回头看，这是个错误。

什么该放全局

全局 skill 适合那些跟具体项目无关、你每天都会用到的通用能力。

我现在全局只保留这几类：

1
2
3
4
5
6
7
~/.claude/skills/
├── git-commit/          # 每个项目都要提交代码
├── investigate/         # 通用调试流程
├── find-skills/         # 查找和安装新 skill
├── skill-creator/       # 创建新 skill
├── careful/             # 防止危险命令
└── browse/              # 浏览器自动化

判断标准很简单：如果这个 skill 换一个项目还能用，放全局。

什么该放项目级

项目 skill 适合那些跟特定项目深度绑定的工作流。

拿我这个博客项目举例：

1
2
3
.claude/skills/
├── writing-agent/       # 写博客的完整流程
└── ai-tone-detector/    # 检查文章 AI 味

这两个 skill 只在写博客的时候有用。放到全局的话，我去写 Python 后端的时候，Claude 的系统提示词里多了两条完全无关的 skill 描述，白白浪费 token。

再举个例子：如果你有一个 React 项目，frontend-design 放项目级合适。如果你同时还在做一个纯后端的 Go 项目，那个项目完全不需要前端设计能力。

一个简单的决策框架

我现在用这个标准来判断一个 skill 该放哪里：

问题 是 → 全局 否 → 项目级
这个 skill 跟编程语言/框架无关吗？ git-commit, investigate frontend-design, layout-creator
换一个完全不同的项目，还用得上吗？ browse, careful writing-agent, lark-base
团队成员需要共享这个 skill 吗？ — 放项目级，提交到 Git

关于团队共享，有一点很容易忽略：你的全局 skill，队友看不到。 全局配置是你个人的，不会跟着 Git 仓库走。说白了，你在全局装再多花活也只有你自己受益。想让团队统一用的东西，就得放项目里提交到 Git。

插件包的问题：一装就是一打

我踩的最大的坑，就是插件包。

superpowers 一装，多了十几个 skill：brainstorming、writing-plans、executing-plans、test-driven-development、systematic-debugging、code-reviewer、dispatching-parallel-agents……每个听起来都很有用，但你真的每个都用得上吗？

lark 系列更夸张。lark-base、lark-calendar、lark-contact、lark-doc、lark-drive、lark-event、lark-im、lark-mail、lark-minutes、lark-sheets、lark-task、lark-vc、lark-whiteboard、lark-wiki，加上两个 workflow——一共 16 个。但我日常只用 lark-doc 和 lark-im。

插件包的问题在于：它是按”全家桶”逻辑打包的，不是按”你需要什么”来打包的。

这就像你只想装个 VS Code 的 Python 插件，结果它把 Java、Go、Rust 的语言支持全给你装上了。

我的处理办法

目前 Claude Code 还没有”只启用插件包里某几个 skill”的细粒度开关（虽然有 enabledPlugins，但颗粒度是整个插件，不是单个 skill）。

我的折中方案是：

  1. 插件包只装在全局，但心里有本账——知道哪些 skill 是我真的在用的
  2. 项目级只放真正需要的 skill——这样项目里的 skill 数量可控
  3. 定期审计——每隔两三周问自己：过去两周用过哪些 skill？没用过的，考虑要不要卸载整个插件

说实话，这不是最优解。社区里有人在 GitHub 上提了 issue，要求支持插件级别的 skill 开关。等这个功能出来，管理会方便很多。

踩完坑之后，我总结了几个教训

最大的一个教训是——CLAUDE.md 都没写好就急着装 skill，这是本末倒置。

我早期就是这样。CLAUDE.md 空着，先跑去装了一堆花里胡哨的插件。结果 Claude 连我项目用什么框架都不知道，装再多 skill 也白搭。后来我花 20 分钟把 CLAUDE.md 写好了——技术栈、代码规范、哪些文件不能动——Claude 的表现立刻就不一样了。Skill 是锦上添花，CLAUDE.md 才是地基。

第二个教训是自己写的 skill 比装的好用。

Reddit 上有个帖子说得特别实在：”I used to use GSD and SuperPowers. Now I just use my own skills I have built. Those plugins were slowing me down too much.” 我深有同感。自己写的 skill，针对性强，描述精准，Claude 不会误触发。别人写的插件包为了通用性，描述往往比较宽泛，误触发的概率就高。

其实写一个 skill 没多复杂——就是一个 SKILL.md 文件，写清楚什么时候触发、该执行什么步骤。我的 writing-agent 从无到有大概花了一个小时，但之后每次写文章都能省两三个小时。

第三个教训跟 skill 的 description 有关。这个字段决定了 Claude 什么时候触发它，写得越模糊，误触发越多。

举个对比：

1
2
3
4
5
# 这么写，Claude 看到任何跟"代码"和"反馈"相关的对话都可能触发
description: Review code and provide feedback

# 这么写，只有在明确的 PR 审查场景才会触发
description: Run after completing a PR. Analyzes git diff against the implementation plan, checks for OWASP vulnerabilities and coding standard violations. Only invoke when user explicitly requests a review or says "review this".

差距一目了然。

最后一个习惯是定期做减法。我现在每隔两三周会跑一次 ls ~/.claude/skills/ | wc -l，看看全局 skill 数量。如果超过 15 个就该精简了。判断标准很粗暴：删了这个 skill，我的工作会受到什么影响？ 答案是”没什么影响”的，直接删。

最后说几句掏心窝的

我知道看到一个新插件、新 skill，手痒想装是什么感觉。毕竟 Claude Code 的扩展生态确实越来越丰富了——GitHub 上 awesome-claude-code 有 5 万多 star，社区每天都有人在分享新的 skill 和插件。

但我现在的心态变了。装 skill 不是集邮，多不等于好。

我从 73 个全局 skill 的教训里学到的最核心的一点是：Claude 不是人类，它没有”先看看有什么工具、需要的时候再拿”的能力。它是把所有工具描述一次性加载到上下文里，每次决策都要过一遍。你给它的选项越多，它做对的概率反而越低。

少即是多。这话在 skill 管理上，是字面意思。

你的 Claude Code 装了多少个 skill？有没有遇到过 skill 冲突或者误触发的情况？评论区聊聊，我想看看大家都是怎么管理的。