凌晨刷到一篇论文，arXiv 2610.11169，10 月 8 号挂上去的，《Skill Constellations》，作者 Fahd Seddik。主分类 cs.SE，捎带 cs.CR 和 cs.SI。
看完第一反应不是震惊，是"哦，又是这个剧本"。
先把话讲清楚，作者扒的是 GitHub 上 skill 的复制关系，拼成一张带日期的复制网络，覆盖 2,193,119 次采用。
两百多万次。
skill 是什么不用我讲，Claude Code、Codex 那类 agent 按你的权限跑的指令和脚本。重点在后半句——按你的权限跑。它能读你的环境变量，能推你的仓库，能 curl 一个东西下来直接 bash。这不是装个插件换个配色，这是把你手上一半的钥匙交出去。
这么个东西怎么传播的？复制。仓库到仓库，人肉拷。
没有注册表，没有版本号，没有来源追踪。论文的说法是：一个被拷走的 skill，原始出处不知道，安全修复能覆盖到哪不知道，哪些仓库要回头审也不知道。
我看着屏幕，脑子里浮出来的是十年前接手的那套东西。一个没人管的脚本，从甲手里传到乙手里，中间改过几版谁都不记得，跑起来还都能跑。这个剧本我看过。
补一刀：当年传的至少还是 shell 脚本，这次传的是拿着你权限的 agent 指令。
说实话我一开始对这论文有偏见——两百万这个数，听着就像拿来抓眼球的，差点划走。改主意是在看到 star 那一段之后。
两条结论，一条比一条难看。
第一条：副本不跟着源仓库更新。源那边修了洞，副本收不到。你在某处修的那个问题，永远修不完——它已经在几百个你听都没听过的仓库里躺着，躺得理直气壮。
现场大概是这样：
name: deploy-helper
version: (无)
source: (无)
copied_from: 某个人的仓库
这叫依赖管理？依赖管理好歹有 lock 文件、有版本号、有 CVE 能对上号。这叫口口相传。
第二条是我最想骂的：GitHub 的 star 数识别不出关键来源。
作者拟合了个模型给仓库排审计优先级，审排名前 100 的，能挡掉 14.9% 的高风险后续采用。换成 star 最高的 100 个去审——0.5%。
三十倍。
我们这个行业对 star 迷到什么程度了？选型看 star，招人看 star，现在连安全审计都往 star 高的仓库凑。人家数出来的是另一回事：贡献了几乎全部复制来源的，是极少数仓库，而这些仓库 star 并不高。
star 高的是谁？会写文档的、会做展示的、把 README 排版弄得很好看的那批。
说句实话，这条我一点都不意外。生产环境里打过仗的人，跟能把项目页做成爆款的人，从来不是同一批。
然后是我想算的那笔账。
一个 skill，写的人一小时写完，拷的人一分钟拷完，下班。审计落到谁头上？落到被半夜叫起来的那个冤种头上。那个画面你自己想——凌晨两点，告警指向某个仓库里一段你没见过的脚本，翻变更记录，三个月前从别处拷过来的，来源无，版本无，改它的人已经转岗了。
那帮天天念"skill 生态成型了"的人，算过这笔账吗？二百多万次采用里，有几个 skill 真进过任何一个人的 review？我猜答案不太好听。
那怎么办。论文有条建议我觉得对：平台该分发带版本的引用，而不是分发副本。
翻成运维的话——别 copy-paste，要 pin version。你依赖一个东西，就得知道它是谁、哪一版、什么时候能升、谁来升。
短期能自己动手的，三条，不新鲜，全是从 lock 文件那套抄的，抄了十几年照样管用：
其一，进仓库的 skill 当生产依赖审，别当"配置"审。配置改坏了大不了重启，skill 改坏了，它拿你的权限干什么都有可能。
其二，来源和版本写死，谁拷的、从哪拷的写清楚。写不清楚的，别进主干。
其三，评估一个 skill 值不值得信，看复制来源，别看 star。
扯远了，回到论文。作者还放了个交互式查看器，能自己翻那张复制网络，我没细看。这事真正的意义不在模型，在于他证明了它能被测——以前我们只能靠经验说"这玩意儿就是一坨复制粘贴攒出来的"，现在有人把它数出来了，数得还挺细。
哦对，分类里还有 cs.SI，社会与信息网络。挺配。传播学的问题，被包装成了工程问题。
本期教训一句话：任何进生产的指令，不管人写的还是 AI 生成的、你手打的还是从 GitHub 拷的，来源、版本、审过没有——三样里有一条说不清，就别上。它出事的时候不会挑时间，专挑你刚睡着那会儿。