GitHub上的AI技能悄悄在互相抄作业，没人知道源头在哪

2026年的某一天，如果你打开GitHub搜索框架，输入SKILL.md，你会看到一个数字：超过二十五万个仓库里，藏着一百六十多万份内容各异的技能文件。这些文件短短十个月前还不存在。

更让人意外的是，其中一半是一字不差的复制品。

这件事听起来可能没那么惊人，开源世界本来就是互相借鉴的文化。但问题在于，这些文件不是普通代码。

Skill*：一种给AI编程助手（比如Claude Code、Codex）使用的指令包，通常是一个文件夹，里面有一份叫SKILL.md的说明书和一些脚本。AI助手会按照这份说明书的指示去执行操作，包括运行命令、访问网络、修改文件，而且是用你的权限去做这些事。

你可以把它理解成给AI助手装的一个插件，但这个插件没有应用商店，没有版本号，也没有任何审核机制。你不知道它最早是谁写的，不知道它经过了几手转抄，也不知道如果原作者发现了一个安全漏洞，这个消息能不能传到你手里的那份拷贝。

这就是这篇论文要回答的问题：这群散落在GitHub上、靠复制粘贴传播的AI技能，到底是怎么流动的？谁在抄谁？抄来的东西会不会跟着原作者更新？如果想守住这条供应链的大门，应该盯着谁？

**为什么“看一眼谁有这份技能”远远不够**

在这篇论文之前，研究者们想弄清楚技能传播情况，用的办法基本都是拍快照。

也就是说，在某个时间点扫描一遍GitHub，看看哪些仓库里有哪些技能文件，然后统计一下、做做分类、标注一下风险。这种方法能告诉你“现在谁手里有什么”，但回答不了“这东西是从哪儿传过来的”。

这就好比你走进一个小镇，发现家家户户门口都摆着同一种盆栽。快照式的研究相当于你挨家挨户数了一遍盆栽的数量和种类，写了一份报告说“这镇上有六百盆绿萝”。但你答不出谁是第一个把绿萝带进镇子的人，也答不出邻居A的绿萝是从邻居B那儿分的枝，还是自己从花市买的。如果镇上突然流行一种绿萝枯萎病，你完全不知道该先去警告谁家，因为你压根不知道这些盆栽之间的传染关系。

研究团队决定不再满足于拍快照，而是去挖每一份SKILL.md文件的git提交历史，重建出一张带时间戳、带方向的网络图。谁先有的，谁后加的，谁抄了谁，什么时候抄的，全部还原出来。这张图里，每一份技能文件的所有复制品构成的网络，论文给它起了个名字，叫“星座”（constellation）。

**技能传播靠的不是一个个零散的决定，而是整批整批地“打包搬家”**

论文发现的第一个核心事实，打破了很多人对软件传播的直觉想象：技能很少是一个一个被单独采用的。

数据显示，33.3%的技能获取是通过“复制”行为发生的，也就是一个仓库一口气抄进了别人已经攒好的一批技能，而真正意义上“我自己一个一个挑着加”的个体采用，只占8.1%。剩下58.6%则是最早的原创来源。

这背后的机制叫“优先连接”（preferential attachment），论文的说法更精确：当一次复制行为涉及的是大批量（一次性超过一百个文件）的“打包搬家”时，它明显更倾向于挑选那些已经被别人复制过很多次的源头。用数学语言说，复制次数的对数每增加一点，被选中作为新源头的概率就显著上升。但如果只是单个技能被人东挑西选地采纳，这种“越红越火”的效应就弱很多，几乎是平的。

引用块：优先连接*：一种网络增长规律，指新节点倾向于连接那些已经拥有很多连接的旧节点，结果是少数节点变得越来越中心化，俗称“马太效应”。

这就像是图书馆里的畅销书效应。你去借书，如果你只是零星地凭兴趣挑一两本，可能真的是看了简介才决定的，跟这本书被借过多少次关系不大。但如果你是整个班级的读书角要集体采购一批书，你大概率会直接搬一个“畅销书单”过来，而这份书单本身就是被反复转抄、反复引用形成的。如果不存在这种打包搬运的行为，技能的传播速度会慢得多，也会分散得多，不会出现后面要讲的那种极度集中的局面。

传播的另一个特征是极度不均衡，专业说法叫“过度离散”，离散系数k只有0.086，这是一个非常极端的数字。翻译成人话就是，绝大多数技能被某个仓库采纳之后，根本不会再被任何其他仓库转抄，是传播链条的终点；但极少数技能一旦被某几个仓库收录，就会像野火一样蔓延出去。排名前1%的仓库，贡献了全网94.7%的传播量。

图1b展示的“web-design-guidelines”这份技能的传播轨迹，就是这种极端现象的缩影：它最终传到了972个采纳者手里，其中490个能明确追溯到传播链条，最深的复制链条达到了12代。想象一下，一份说明文档像基因一样一代一代往下传，传到第十二代的时候，可能已经没人记得它最初长什么样子了。

**GitHub星标是个假信号，真正的大佬藏在没人关注的角落**

论文第二个让人印象深刻的发现，是关于“谁才是技能传播的真正源头”。

正常直觉是，GitHub星标高的仓库肯定更有影响力，毕竟那是大家用脚投票的结果。但论文算出来的肯德尔相关系数只有负0.10，这意味着星标数和一个仓库在复制网络里的“出度”（也就是有多少仓库是从它这儿抄走技能的）几乎没什么关系，甚至是微弱的负相关。

更扎心的是一个对照实验。论文拿这些仓库在截止日期之前积累的“出度排名”去预测未来的传播，发现当前的复制出度能捕捉到27.8%的未来传播，而星标数只能捕捉到7.0%，差了将近四倍。PageRank算法和“持有技能数量”这两个指标的表现跟出度差不多，星标是四个指标里垫底的那个。

引用块：出度*：在网络图里，一个节点指向其他节点的连接数量，这里指一个仓库被多少其他仓库复制过技能。

PageRank*：谷歌搜索引擎最初用来给网页排名的算法，核心思想是被重要节点连接的节点也更重要，这里被用来衡量仓库在复制网络中的中心地位。

这就像评价一家餐厂厨师的真实影响力，不能看他大众点评上的星级评分，得看有多少其他餐厅的菜单是抄他的配方做出来的。星级评分反映的是消费者的直接喜好，可能因为营销、位置、网红效应虚高或虚低；但“被同行抄袭的次数”反映的是这家店在整个行业供应链里的实际地位。如果安全审计团队只盯着星标高的仓库去做风险排查，等于是在错误的地图上找宝藏，大概率扑空。

更有意思的是，论文还挖出了这些“真正的传播源头”到底长什么样。他们找Claude Opus和Claude Sonnet这两个大模型对一百五十个源头仓库做分类标注，发现没有星标的那些高影响力仓库里，66.4%居然是普普通通的项目，不是什么专门的技能聚合目录，也不是刻意经营的内容农场。换句话说，真正带动技能扩散的，很多时候是某个开发者随手写了个还不错的东西，被别人默默抄走了，这个开发者自己可能都不知道自己的仓库成了传播枢纽。

**抄来的技能几乎从不跟着原作者“打补丁”**

这是整篇论文里最让人后背发凉的发现。

论文定义了一个叫“克隆组”的概念：在某一周内，持有同一份技能完全相同版本的所有仓库，构成一个克隆组；如果这个克隆组随着时间推移被追踪下来，就叫“家族谱系”（genealogy）。所谓“一致性变更”，指的是当原始版本更新之后，这个组里的所有成员是不是都跟着更新到了同一个新版本。

结果是，无论观察窗口设成一周还是十周，一致性变更的比例都稳定在11.1%左右，几乎不随时间推移而改善。更残酷的是，一旦这个克隆组里出现了多个不同的拥有者（也就是技能已经分散到不同人手里），一致性几乎直接归零。论文算出来，如果克隆组只属于同一个拥有者，变更保持一致的几率要高出3.32倍。而从所有被追踪的家族谱系来看，真正会出现一致性更新的，只有4.0%。剩下的要么从头到尾一次没变过（72.6%），要么变得乱七八糟毫无规律（23.4%）。

作为对照，论文引用了另一项关于普通代码文件复制的研究：一般代码文件在原作者修补安全漏洞之后，有47%到84%的复制品会跟进更新。而AI技能文件的这个数字只有20.9%。

引用块：家族谱系*：一个技能的某个克隆版本随时间推移在不同仓库间的传播轨迹，用来追踪它是否跟随源头更新。

这意味着什么？意味着如果某个热门技能文件被发现藏有安全漏洞，原作者修好了，发了新版本，但现实中接近八成的复制品根本不会同步这个修复。它们会像被遗弃在角落的旧手机一样，永远停留在带漏洞的那个版本上，继续被AI助手执行。

这个场景让人想起老小区里的消防通道。物业发现某栋楼的消防通道堵塞，贴了整改通知，自己那栋楼立刻清理干净了。但隔壁几栋楼因为产权不同、管理方不同，根本没人去传达这个通知，堵塞依旧，直到真的出事才会被人想起来。如果技能传播体系从一开始就带着版本号和引用机制，而不是靠复制粘贴，原作者的修复理论上能自动推送到每一个使用者手里，但现实是没人设计这套机制，于是修复信息就卡在了半路。

论文还发现一个更微妙的现象：那些确实被修改过的技能拷贝，往往不是自己拥有者动手改出来的新能力，而是直接换了一个“别人改好的版本”拼接过去的。图3f显示，命令执行权限这种高危能力的净增长，主要来自“采纳了别的版本”而不是“自己动手编辑”。也就是说，大部分开发者根本没有真正审查过自己手里这份技能文件的内容，只是在不同的现成版本之间来回切换而已。

论文还顺手揪出一个有点滑稽的细节：有些技能文件被放进了Codex、Cursor这些别的AI助手的专属文件夹里，但内容里却直接点名要求调用只有Claude Code才具备的工具。研究者手动核查了56个这样的案例，全部确认无误。这说明开发者在跨平台搬运技能文件时，压根没有核对过内容是否适配当前这个AI助手，纯粹是“抄过来能跑就行”的心态。

**审计该查谁：100个精准目标 vs 100个点赞最多的仓库**

把前面的发现拼起来，论文提出了一个实际可操作的问题：如果你是安全团队，预算有限，只能挑一百个仓库去重点审查，该挑谁？

他们训练了一个叫“条件逻辑回归模型”的工具，让它学习每一次复制事件里，新仓库到底是依据什么规律去挑选它的“抄袭对象”的，考量的因素包括这个潜在源头已经持有的技能数量、过去被复制的次数、星标数和账号年龄等等（取对数之后输入模型）。

引用块：条件逻辑回归*：一种统计模型，这里用来预测在一次复制事件中，众多候选源头里哪一个最可能被选中，通过对比各个特征的权重来打分排序。

把这个模型训练好之后，论文做了一个很干净的验证实验：用2026年4月1日之前的数据训练模型，然后看它对这个日期之后新发生的传播事件预测得准不准。结果是，按模型打分审查前100个仓库，能提前拦截14.9%的高风险技能未来传播；而审查星标最高的前100个仓库，只能拦住0.5%；随机挑100个仓库的效果几乎是噪声水平。这个结论在把分割日期换成3月1日或5月1日时依然成立，证明不是偶然碰上的巧合。

图4a还给出了一个参照值，叫“事后诸葛亮上限”，就是假设你开了天眼，提前知道未来会发生什么传播，能达到的理论最高拦截率也只有26.6%。这说明即便是理想情况，也拦不住所有风险，因为大约一半的高风险传播其实来自全新出现的技能，而不是对已有技能的二次传播，天眼也没用，因为这些新技能压根还不存在。

这就好比机场安检要在有限的人力下挑出真正值得重点盘查的旅客。如果只按“这人穿得体面不体面、随身行李看起来高不高级”这种表面特征去筛选（相当于按星标筛选），抓到问题的概率极低；真正有效的做法是看这个人过去的出行记录和行为模式（相当于复制出度和PageRank），这才是和实际风险真正挂钩的信号。如果不采用这种基于历史行为的建模方式，安全审查资源会被大量浪费在“看起来重要但实际不重要”的目标上。

论文还提醒了一件容易被忽略的事：新技能从出现到被大多数未来采纳者发现，中位数需要56天，第一周只能触达7.7%的最终采纳者。这意味着安全审查团队有一个相对宽裕的窗口期去拦截，不需要争分夺秒到以小时计算，但也绝不能拖到几个月之后才动手，因为那时候传播早已失控。另外，三分之一左右的技能复制行为已经开始跨越不同AI助手平台发生，这意味着审查工作不能只盯着某一个AI工具的生态圈，必须全平台覆盖。

**风险到底藏在哪：命令执行权限是重灾区**

论文给技能文件打了风险标签，标准包括是否捆绑了可执行文件、是否预先批准了某些工具权限、是否指示执行危险操作。标注过程同样用了两个大模型做独立交叉验证，Cohen's κ系数（衡量两个标注者意见一致程度的指标）在不同问题上介于0.66到1.00之间，整体算是相当可靠，严格标准下的精确率达到98.3%，召回率80.9%。

有意思的是，被标记为高风险的技能，实际传播到的仓库数量反而比随机模型预测的要低（28.6%对41.1%），说明高风险技能确实传播得没那么远，这算是个不幸中的万幸。但一旦某个技能被修改过，它更倾向于获得命令执行权限而不是失去它（图3e），这种净增长几乎全部来自“切换到别人改过的版本”而非自己编辑，前面已经提到过这一点。

**这篇论文之后，这条路还会怎么走**

这项研究最终给出的建议很直接：平台方应该让技能以“带版本号的引用”方式分发，而不是任由用户复制粘贴整个文件夹。这样原作者一旦修复了漏洞，所有引用这个版本的人都能自动感知到更新，而不是像现在这样，复制出去的那一刻起就和原作者彻底失联。

论文发表之前，已经有一批相关工作在尝试从不同角度切入这个新兴问题。比如前文提到的GitSkills数据集本身，就是这篇论文据以展开分析的原始数据来源，它最早统计出“一半的技能文件是逐字复制”这个基础事实。另外还有几篇聚焦“检测恶意技能”的工作，比如专门做神经符号推理检测恶意技能的MalSkills，以及在USENIX安全顶会上发表的、专门研究“如何检测并理解那些故意写着不要告诉用户这一点”的恶意指令技能的论文。这些工作解决的是“这份技能本身危不危险”的问题，而这篇论文解决的是完全不同的问题，它关心的是“这份技能是怎么传开的、该审查谁”，两者互补而非重叠。

论文还提到一个有趣的时间线细节：就在这篇论文完成后不久，另一篇题为《从注册中心到仓库：AI智能体技能是如何被编写、适配与维护的》的工作也在关注注册中心里的技能有多少从未被修改过（他们的数字是53%），这个数字和本文“20.9%技能跟随源头更新”的发现方向是一致的，互相印证了技能复制生态里“复制后基本不再维护”这个普遍现象。

---

写在后面

读完这篇论文，最让我在意的其实不是那些漂亮的拦截率数字，而是一个更底层的现实：这整套AI技能分发体系，是在没有人刻意设计的情况下自然长出来的。

没有人坐下来开会说“我们要建一个没有版本管理、没有审核、靠复制粘贴传播的软件分发系统”，但这个系统就这样在十个月里自己长出来了，长到一百六十多万份文件的规模。这让我想起很多互联网早期的基础设施，都是先野蛮生长，等出了大问题之后才回头补规则。技能生态现在显然正处在“还没出大问题，但所有迹象都指向迟早会出问题”的阶段。

另一个让我反复琢磨的细节，是“GitHub星标是个假信号”这个发现。我们这个时代太习惯用点赞数、粉丝数、星标数来快速判断一个东西值不值得信任，但这篇论文用扎实的数据证明，至少在这个具体场景里，这种直觉彻底失灵了。真正危险或者真正有影响力的节点，可能就藏在那个你从来没点开过、star数是个位数的普通仓库里。这多少提醒我们，流行度和影响力这两件事，在很多场景下根本不是一回事。

如果有一天某个藏在无名仓库里的技能文件，正在悄悄教几千个AI助手做一件你完全没预料到的事，而没有一个人去更新它、审查它，这个画面想想还挺让人毛骨悚然的。

Q&A

Q1：Skill（AI技能）文件到底是什么东西，为什么会有安全风险？

A：它是AI编程助手使用的指令包，包含SKILL.md说明文件和脚本，助手会用用户本人的权限去执行这些指令，可以运行命令、访问网络、修改文件，所以一旦技能文件被植入恶意内容，风险和用户本人操作是一样大的。

Q2：为什么GitHub星标高的仓库不能用来判断谁是技能传播的真正源头？

A：论文计算发现星标数和仓库在复制网络中的出度几乎不相关，肯德尔相关系数只有负0.10，用当前复制出度预测未来传播能捕捉27.8%，而星标只能捕捉7.0%，差了近四倍，而且星标还存在被刷的风险。

Q3：论文说的“审计100个仓库能拦截14.9%高风险传播”具体是怎么算出来的？

A：研究者用2026年4月1日前的数据训练一个预测复制来源的模型，用它给仓库打分排序，审查打分最高的100个仓库并移除其高风险技能，看这能拦下多少4月1日之后才发生的高风险传播，结果是14.9%，远高于按星标排序的0.5%，这一结论在换成3月或5月的分割点后依然成立。