如何选择一个好的 Skill：准则

Feb 15, 2026

舍温 5 min read AI Coding Claude Code , LLM

AI 时代的产能过剩，一天新增一万多个 Skills。
人生就是不停的做选择题，如何”考察，甄别，落地”这些变成了一个难题。

数据来源： https://skillsmp.com/timeline

我选择 Skill 有几条准则：

这个 Skill 必须是”我实际会使用的”，下载 10000 个 Skills 的我不会用的预设包，并不会给我带来什么实际好处。
这个 Skill 必须是”原子化的”，不要给我打包推销太多功能。
新的 Skill 应该和已经存在的已有的 Skill 正交，不要 Overlapping，更不需要冲突对抗。
一个优质的 Skill 应该足够轻量，用简单的语句就可以描述清楚他的目的，他的能力边界。

Skills 和编程语言的 <函数> 很像，它们有一些相同点。

	一个函数…	一个 Skill…
✅ 相同点
单一职责	一个好的函数只做一件事。	一个好的 Skill，应该是原子化的，职责边界清晰。
正交性	函数之间不应有副作用交叉。	Skill 之间也不应有 overlapping 或冲突对抗。
可组合性	小函数组合成大流程。	Skill 也可以在一次会话中被 Agent 串联调度。
命名即契约	函数名表达意图。	Skill 的名称和触发描述是它与调用者之间的契约。
轻量优于臃肿	好函数短小精悍。	好 Skill 用简单语句就能描述清楚目的和能力边界。
按需引入	只 import 用到的函数。	只安装实际会使用的 Skill。
可替换性	接口稳定时，函数实现可以替换。	同理，同一职责的 Skill 也可以被更好的版本替代。

同时，他们也有不同点。

	一个函数…	一个 Skill…
🚫 不同点
调用方式	显式调用 fn(args)。	Agent 根据上下文自动匹配触发。
签名精确度	严格的类型签名，入参出参明确。	自然语言描述的模糊边界，靠触发词和语义匹配。
执行确定性	相同输入 → 相同输出。	涉及 LLM 推理，输出有不确定性。
错误边界	编译期/运行时类型检查。	没有硬约束，依赖描述的准确性来避免误触发。
安装成本	import 几乎零成本。	每个 Skill 占用 context 空间，有认知和上下文的隐性成本。