Skill 文档的命名规范应该怎么做?-夜雨聆风

Skill 文档的命名规范应该怎么做?

今日快速学习一个技能！

Skill 文档的命名规范应该怎么做？

首先，为什么要做给 Skill 文档规范命名这件事情？

因为：给 Skill 文档规范命名，核心原因是为了帮 AI 精准“认路”和“干活”，同时也方便人类管理，命名规范直接影响后续的 Skill 路由、版本管理和“人+机”、“机+机”团队协作效率。

Skill 文档命名，主要有这几个关键作用：

提高 AI 的触发准确率

AI 在启动时，只会先扫描所有 Skill 的名称（name）和简介（description）来决定加载哪一个。名字起得规范（比如用动名词 processing-pdfs），AI 就能快速理解这是“正在处理 PDF”的能力，从而准确匹配你的指令，避免调用错误。

节省昂贵的上下文窗口

AI 的上下文窗口（能处理的信息量）很有限。规范的命名让 AI 在初期只需“看一眼”名字就能判断相关性，不需要一上来就加载所有 Skill 的完整文档，从而把带宽留给真正需要执行的复杂任务。

明确功能，防止混淆

像 utils（工具箱）或 helper（助手）这种模糊的名字，人看了都懵，更别提 AI 了。规范的命名（如 code-review代码审查）能让功能的边界一目了然，防止 AI 在多个相似 Skill 之间“猜”该用哪个。

工程化维护与协作

当你的 Skill 越积越多时，统一的命名模式（如 kebab-case 的小写连字符格式）就像给代码定规范一样，方便你在目录中快速查找、引用，也利于团队协作时的统一管理。

案例如下：

文件命名：{domain}-{action}-{object}.md

三段式，全小写 kebab-case：

domain — 业务域，如 hr、sales、financeaction — 动作，如 query、analyze、generate、alertobject — 操作对象，如 performance、report、employee

比如我之前已有的两个绩效分析 skill 套进去就是：

hr-query-low-performance.md       ← Skill Ahr-analyze-employee-performance.md ← Skill Bskill-design-framework.md         ← 框架本身（工具类不加 domain）

frontmatter 里的 name 字段与文件名保持一致，去掉 .md 后缀：

yamlname: hr-query-low-performance

这样路由器可以直接用文件名做 skill ID，不需要额外维护映射表。

版本目录结构：

skills/├── hr/│   ├── hr-query-low-performance.md│   └── hr-analyze-employee-performance.md├── tools/│   └── skill-design-framework.md└── _archive/    └── hr-query-low-performance_v0.9.md   ← 旧版归档加下划线+版本号

几条硬规则：

禁止用中文、空格、大写字母
禁止用 v1、final、new 这类词放在文件名里（版本信息只放 frontmatter）
同一 skill 的不同语言版本加语言后缀：hr-query-low-performance.zh.md

大家可以做笔记，评论区交作业、交流！