Claude Code 的 Skill 机制出来之后，我用了大半年。这篇记一下自己怎么用的，以及踩过的坑。

先说清楚：Skill 的安装方式、上游渠道这些，Arguo 那篇《Claude Code Skill 怎么装、从哪找、装哪些》讲得比我全，三种安装方式和全局装、项目装的区别都在里面。我这里只写自己实际用的部分。

它解决的问题

用 AI 工具最烦的一件事是”每次都要重新交代”。

我有一类固定的活：把一份 PDF 转成结构化的笔记、按固定格式整理一份周报、给一批文件改名并归档。这些活每次都得重新描述一遍要求，稍微说漏一点，出来的结果就不能用。

Skill 干的就是这件事：把一个流程写成文件放在那儿，模型在合适的时机自己发现并使用它。不用每次贴提示词，不用维护一堆模板。

我的组织方式

目录分层。 我分两层：全局层放跟具体项目无关的（文档处理、格式转换、我自己习惯的输出风格）；项目层放跟这个仓库绑定的（测试怎么跑、发布流程、哪些目录别动）。

项目层的东西跟着代码一起进版本控制，换机器就能用；全局层我自己做了备份。

一个 Skill 一件事。 我试过写一个”综合助手”式的 Skill，里面塞了四五种能力，结果它经常用错。拆成一件事一个之后，触发准确率明显变好。

description 是触发器，不是说明。 这是我踩的最大的坑。

一开始我把 description 当成”功能介绍”写：”用于处理文档相关任务。”结果它基本不触发——因为模型判断要不要用这个 Skill，靠的就是这句描述。后来改成写清楚什么时候该用：”当用户要求把 PDF 或 Word 文档转成 Markdown 笔记、或需要处理批量文件格式转换时使用。”触发率立刻上去了。

一句话总结：description 应该回答”我什么时候该用你”，而不是”我是什么”。

名字要能一眼看懂。 Skill 的名字会出现在清单里，模型和我都靠它判断用途。我一开始用了几个缩写，后来全改成描述性的短语——记不住的名字等于不存在。

写完先自己试几遍。 我有个习惯：新写的 Skill 先在两三个真实任务上跑，看它该触发的时候有没有触发、不该触发的时候有没有乱用。这一步能发现大部分”description 写得太泛”的问题。

装了但基本不用的那类

我装过一批”看起来很厉害”的 Skill：某种特定框架的最佳实践、某种语言的高级模式、一堆通用规范检查。结果它们几乎不触发。

原因是这些知识本来就在模型的训练数据里，而且比我的 Skill 更新。只有当 Skill 里包含模型不可能知道的信息——比如我自己的目录约定、我的输出格式偏好、我们内部系统的接口——它才有价值。

这个判断标准挺实用：Skill 里应该装”私有知识”，而不是”公共知识”。

几个实际问题

更新。 Skill 是文本，改动无成本，但也意味着它会慢慢和实际做法脱节。我现在的做法是每次发现它给的结果不对，就顺手改一次，而不是攒着一起改。

版本冲突。 全局层和项目层如果有一个同名或功能重叠的 Skill，行为会变得不可预测。我踩过一次：全局有个旧的格式转换 Skill，项目里有个新的，它在两个之间来回跳。后来把全局那个删了。

权限。 Skill 可以带上脚本，也就是说它能执行代码。来源不明的 Skill 我基本不装，装之前至少看一眼里面有没有执行外部命令的部分。

上下文占用。 Skill 的清单和描述是要占上下文的。装到几十个之后，还没开始干活，上下文里已经铺了一层它的目录，跟 MCP 工具描述占上下文是同一类问题。

我的判断

Skill 这个机制的价值在于它把”经验”变成了可复用的资产——以前这些东西散在我的脑子里和一些零碎的笔记里，现在有一个明确的落点。

但它的收益有个前提：你确实有重复的流程。偶尔做一次的事情，写 Skill 的时间比省下的时间还多。

判断标准很简单：这件事我半年内做过五次以上吗？做过，值得写；没做过，先别写。写 Skill 的成本不在写，在维护——它会一直躺在那里，等着被模型误用。