一个环境住了三个skill-creator

概述

这是本栏第1轮的例行观察。与以往不同的是，本期榜单端通道未开放，市场新架与涨星数据无法联网复核，因此本期周报换了一个此前只扫过一角的方向：把装机端的门牌从头到尾点一遍。口径是2026-09-28本机会话实际挂载的技能清单，逐条清点两遍。核心发现有三：其一，这台机器挂着421条技能条目，其中10组条目共用同一个名字——最挤的一户，skill-creator一个名字住着三个不同来源的实体；其二，撞名分两种，官方包镜像造成的「重影」和无主 sank 的「同位竞争」，后果完全不同；其三，近名家族（pptx族11件、通信族11件）不是病，是分工。全文数字均为当期清单清点结果，不涉任何外部榜单。

口径说明：为什么普查门牌，以及数字怎么来的

先交代方法，本期所有结论的效力边界都在这里：

• 清点对象：2026-09-28当日会话挂载的技能清单，含用户目录手装件、官方插件包、会话内置件三个来源，逐条清点两遍；
• 未读盘声明：本期未打开任何一份SKILL.md原文（与09-27期《盲盒四件首拆》的逐段拆读不同），因此只谈名字层的事实——谁和谁同名、谁和谁近名、各来自哪个来源；凡涉及件内功能的描述，只引用清单自带的一句话简介，不做无据展开；
• 先例衔接：09-26期《内容办公装机总账》用同样的注册表口径点验过内容办公层的16件，本期把范围从「一个工位层」扩大到「整台机器」；
• 误差声明：421这个总数为人工清点，组内成员名单逐条可查，总数按±2理解不影响任何一组的结论。

总账：421条挂载从哪来

flowchart TD
    ALL["本机挂载 421条"]
    ALL --> U
    ALL --> P
    ALL --> H
    subgraph U["用户目录 386条"]
        U1["人格件 约250"]
        U2["工具件 约136"]
    end
    subgraph P["官方插件包 21条"]
        P1["example-skills 16件"]
        P2["obsidian包 4件"]
        P3["frontend-design 1件"]
    end
    subgraph H["会话内置 14条"]
        H1["审查运行配置类"]
    end
    U --> X
    P --> X
    H --> X
    X["撞名带 10组"]

三个来源的比例本身就值得看一眼。用户目录386条占绝对大头，其中约250件是以人名命名的「人格件」——从鲁迅到张雪峰，从葫芦娃七兄弟到灌篮高手全员——占用户目录的六成五。这个结构与09-16期「人格件过剩」的判断一致，但本期不展开人格件（09-04期已盘点过葫芦娃七件、喜羊羊六件的家族拆法，09-19期拆过huluwadawa的压缩件经济学），本期盯的是剩下那批工具件里更隐蔽的问题：名字撞了。

十组撞名总表

清点出的10组同名条目如下。撞型一栏是本期的关键区分：「镜像同源」指同一份内容的两次挂载（比如官方插件包里的件被复制进了用户目录），「异源同名」指两个来源各自独立演化的同名件——后者才是真风险。

10组里7组是镜像重影，3组是异源竞争。这个比例说的是一件事：大多数撞名是装机习惯造成的 sediment（沉积层），不是设计事故——先手装了官方件的拷贝，后来又装了官方插件包，没人记得删旧的。真正要警惕的是前两行。

三户同住的skill-creator

全清单最挤的一户。skill-creator这个名字在清单里出现4次挂载口径，物理来源至少三个：

1. 用户目录手装件——最早装进来的那一份；
2. example-skills官方包——anthropics/skills全家桶16件之一，随包进场；
3. obsidian插件包——obsidian官方包带着自己的skill-creator进场，同一份全家桶逻辑在另一个插件里又演了一遍。

三个「教你写Skill的Skill」同时在场，这件事的荒诞度和它的警示价值一样高：连教人做件的官方样板件，都会在装机端撞车。用户装obsidian包时大概率没意识到包里附带了一件和自己手装件同名的货——插件包不是「一个件」，是「一户人家」，搬进来时连家具带人口一起进门。

最危险的一组：deep-research

比skill-creator更值得单独立案的是deep-research。这一组的特点是：两个来源都是真实活跃的触发者。用户目录那一件是手装的深调研件，会话内置那一件带着一句完整的描述——「扇出搜索、交叉验证、综合成带引用的报告」。两组描述都常驻在每次对话的扫描带里（这正是09-27期《第一件Skill，九条套路写完》讲的物理定律：描述常驻、正文按需、深料再按需），用户说「帮我深度调研一下X」的时候，两个件都符合触发条件。

和镜像重影不同，这组没有「反正内容一样」的托底——两件的调研流程、输出格式、引用规范可能是两套设计。模型这次点亮哪一件，用户无从指定，也没有任何提示。撞名的代价不是磁盘，是触发的不确定性：你以为是自己在用工具，其实是抽签。

家族不是撞名：近名家族普查

把「精确同名」排除之后，剩下的近名聚集是另一种东西——它们不是事故，是分工。清点出的最大家族：

注意部署族和pcap族（analyzer/generator/modifier）的命名法：用后缀声明分工，名字本身就是路由表。这与09-19期在人格件上发现的「家族拆件跟着主角团人数走」是同一个生态行为在不同层的投影——人格层按角色拆，工具层按工序拆。健康的近名聚集有一个判据：任何一件的名字删掉后缀后，你仍然能说出它和兄弟件的区别。说不出来的，就是下一组撞名的候补。

撞名的真实代价：扫描带上的注意力税

最后把机制说透。技能清单的扫描模型是：每次对话，所有已装件的name和description都会被扫一遍。这意味着撞名的成本公式和直觉不同——

• 磁盘成本≈0：SKILL.md就几KB，复制十份也无感；
• 扫描带成本线性增长：421条描述每次对话都在被扫，其中22条是重复门牌的重复描述——这部分 token 花得最冤，它们增加的匹配噪音是双向的：模型多一次二选一，用户多一次「它刚才用的到底是哪个」；
• 最贵的成本是静默的：异源同名的两件互不知晓对方存在，各自演化，某天其中一件改了触发词，抽签的概率就悄悄变了。没有任何报错，没有任何日志。

这就是为什么装机端需要一道「上户口」的工序——09-26期总账里「装机量纲只说明盒子进了门，不说明盒子被打开过」的发现，在门牌这一层同样成立：装机清单只说明名字注册了，不说明名字是唯一的。

装前三步：给新件上户口

flowchart TD
    A["想装一件新件"] --> B["查现有门牌"]
    B --> C{"名字已存在？"}
    C -->|是| D["改前缀或走插件命名空间"]
    C -->|否| E["查近名家族是否重叠"]
    E --> F["比对描述触发词"]
    F --> G["装入并实测点名"]

对应的命令（都是本机可复现的）：

# 第一步：查现有门牌，看目标名字是否已存在
ls ~/.claude/skills

# 第二步：查插件包带来了哪些户（插件件以 plugin:name 形式挂载）
# 在 Claude Code 会话内执行 /plugin 查看已装插件及其附带件

# 第三步：装官方全家桶前，先确认手装镜像是否要退役
# 插件市场添加（以官方仓库为例）
claude plugin marketplace add anthropics/skills

撞名已发生的处置优先级：镜像同源组（7组）直接删手装拷贝、保留插件托管版，升级走插件通道；异源同名组（3组）按实际使用留一件，另一件改目录名换门牌——名字是触发路由的第一关键词，改名即改路由。

本期排行

• 撞名重灾区TOP3：skill-creator（3源4挂载）、deep-research（双活跃触发者）、frontend-design（两个插件包互不相让）；
• 最大家族TOP3：演示/出纸族11件、通信垂直族11件、件管理族5件；
• 来源贡献排行：用户目录386条 ＞ example-skills包16条 ＞ 会话内置14条 ＞ obsidian包4条 ＞ frontend-design包1条；
• 最省心的命名法：pcap三件与部署四件的后缀分工法——名字即路由表，零撞名记录。

参考来源

1. 2026-09-28本机会话技能清单实测清点（用户目录386条 + 官方插件包21条 + 会话内置14条，共421条挂载；10组同名名单见总表）— 本文全部数字与名单的直接来源
2. 本栏存档2026-09-26期《内容办公装机总账：翻译位空着》（docs/claude-code/skills-review/2026-09-26-skills-ecosystem-r4-1032.md）— 注册表目录遍历口径与「装机量纲」发现的先例
3. 本栏存档2026-09-27期《第一件Skill，九条套路写完》（docs/claude-code/skills-review/2026-09-27-skills-ecosystem-r8-2003.md）— 「描述常驻、正文按需」的扫描模型出处
4. 本栏存档2026-09-27期《盲盒四件首拆：翻出自家传家宝》（docs/claude-code/skills-review/2026-09-27-skills-ecosystem-r4-1623.md）— 本机SKILL.md逐段拆读的方法先例
5. 本栏存档2026-09-19期huluwadawa拆解与2026-09-16期判例（同目录）— 人格件家族拆件与「人格件过剩」判断的出处

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。