Skill 多了就会撞名：教你把 AI Skill/插件命名做成“唯一且好搜”的一套方案
你有没有遇到过这种场面：
- 你刚写完一个 Skill，准备提交
- 结果发现同事也写了一个一模一样的名字
- 更离谱的是，GitHub 上已经有人占了这个仓库名 😅
这事真不稀奇。
比如 seo-audit 这种名字，直观、好记、也确实“太通用了”。现在就有两位开发者都用过这个命名：
- @wonfull888：
github.com/wonfull888/seo-audit - @CoderJeffLee：
github.com/JeffLi1993/seo-audit
撞名的代价很实在：仓库难搜、文档难写、调用方也容易配错。
下面给你一套命名方案，目标就两个：
- 永远不撞（至少在你团队和你的发布渠道里）
- 人类好读（别搞成 UUID 那种“看了想辞职”的名字）
1）先把“名字”拆成两层：短名给人看，唯一 ID 给系统用
很多人一上来就把 Skill 名字当成唯一标识。
问题是：短名越好记，越容易撞。
推荐你把命名拆成两层：
- display_name（展示名）：给人看的，允许通用、好理解
- skill_id（唯一标识）：给系统用的，保证全局唯一
一个参考长这样：
- 展示名：
SEO Audit - 唯一标识：
com.yourteam.seo.audit
你会发现，展示名可以继续叫 seo-audit，但系统层已经不会撞了。
如果你的 Skill 框架/平台只允许一个字段，那就把这两层揉进去：
yourteam-seo-auditjefflee-seo-auditwonfull-seo-audit
短名别太“公共”。公共就意味着迟早撞。
2）最稳的命名空间：反向域名（真的好用）
想要“永不撞”，命名空间是核心。
最常见也最稳的套路：反向域名。
示例：
- 你的域名：
example.com - Skill：
seo-audit - 最终 ID：
com.example.seo-audit
没有域名怎么办？也行：
- 用 GitHub 用户名：
io.github.yourname.seo-audit - 用组织名：
io.github.yourorg.seo-audit
这套命名的优点：
- 看一眼就知道是谁家的
- 多人协作也不容易打架
- 发到任何平台都能复用
3）仓库名别只图省事：把“通用词”变成“可定位的品牌词”
seo-audit 这种仓库名的问题不在于它不好。
问题在于它太“像默认值”。
你可以用一个小技巧：通用能力 + 你家的标记。
比如：
seo-audit-skillseo-audit-agent-skillseo-audit-by-yourteamyourteam-seo-audit
如果你未来会做一堆 SEO 相关能力，更建议上一个“合集仓库”结构：
- 仓库：
yourteam-seo-skills - Skill 目录：
skills/seo-auditskills/seo-keyword-researchskills/seo-competitor-scan
这样做的好处是：不会出现“10 个仓库 10 个类似名字”，后期维护也轻松。
4）包管理（npm/pypi）也要同步命名，否则你会被自己坑到
很多 Skill 会打包发布。
你仓库叫一套、包名叫一套、Skill 名又叫一套。
过两个月回来看，你自己都不记得哪个是哪个。
建议你用“一致性表格”强行统一：
| 维度 | 建议格式 | 示例 |
|------|----------|------|
| 仓库名 | org-skillname 或 org-topic-skills | yourteam-seo-audit |
| 包名（npm） | @org/skillname | @yourteam/seo-audit |
| 包名（pypi） | org-skillname | yourteam-seo-audit |
| Skill ID | 反向域名 | io.github.yourteam.seo.audit |
| 展示名 | 友好短名 | SEO Audit |
npm 还有个神器：scope。
@yourteam/seo-audit
scope 天生就是命名空间。
这一步做对了，你几乎不会在包管理上撞名。
5）给 Skill 写“名片”：一句话描述 + 关键词，让别人一搜就找到你
撞名的另一层痛苦是：搜不到你。
所以别只写 seo-audit，你还得让搜索引擎知道“你到底有什么不一样”。
建议 README 顶部固定三件套：
- 一句话：它解决什么问题
- 适用场景：谁会用、什么时候用
- 输入输出：一眼看懂怎么调用
示例（可直接套用）：
# SEO Audit Skill（技术 SEO 快速体检）
给运营/开发用的 SEO 体检工具：抓取 robots、sitemap、canonical、meta、状态码与重定向链路。
适合场景：
- 新站上线前，想避免“上线就翻车”
- 网站改版后，想快速检查 404/重定向
输入：网站 URL
输出：结构化报告（JSON/Markdown）
再补一刀：在 GitHub Topics 里加上标签。
seoauditskillagentllm
这些标签对“被搜到”很关键。
6）团队协作的硬规则：建一个“Skill 注册表”，别靠口头约定
只要团队里 Skill 一多，靠喊话一定出事。
你需要一个最朴素但最有效的东西：注册表。
形式随意：
- 一个
skills/registry.json - 一页 Notion
- 一个 Google Sheet
关键字段建议包含：
skill_iddisplay_namerepoownerstatus（draft/active/deprecated）created_at
大家每加一个 Skill，就登记一下。
这一步会让你少掉大量“我以为没人用这个名字”的扯皮。
示例：把“seo-audit”命名成不撞名版本
假设你是 yourteam，你想保留 seo-audit 的直观感。
一套比较舒服的命名可以是：
- 展示名：
SEO Audit - Skill ID：
io.github.yourteam.seo.audit - 仓库：
yourteam-seo-audit - npm：
@yourteam/seo-audit - 文档标题：
SEO Audit Skill（yourteam）
你会发现，大家仍然会口头叫它 “seo-audit”。
系统层已经完全不怕撞。
避坑清单（踩一次就够你烦半天）
- 只用通用词做唯一名：
seo-audit、summarizer、translator这种，撞名概率极高。 - 大小写/下划线乱用：不同平台规则不一样，最后会出现“同一个东西三种写法”。建议统一用
kebab-case。 - 仓库改名不做重定向说明：README 不写迁移公告，别人继续用旧链接。
- 没有弃用策略：旧 Skill 不标
deprecated，新旧并存，调用方直接迷路。 - 不同语言包名不一致：npm 叫 A，pypi 叫 B，你的用户要对照表才能安装，体验很劝退。
你可以直接照抄的命名规则（适合大多数团队）
- 展示名：
人类好懂 - 唯一 ID：
io.github.<org>.<topic>.<skill>（反向域名风格） - 仓库：
<org>-<topic>-<skill> - 包名（npm）：
@<org>/<topic>-<skill> - 包名（pypi）：
<org>-<topic>-<skill>
把这套定下来，写进团队规范里。
以后谁再提交一个 seo-audit，你就把这篇甩过去：别撞了，兄弟，咱们有规矩 😄
