GitHub 上那些每小时推送上万次代码的僵尸号到底在操纵什么

在分析 GitHub Archive 的公开数据集时，我意外发现一组极为震惊的数据现象。在每个小时约 16 万次的公开事件中，其中 64% 的 Push 操作都被判定为垃圾信息。这意味着短短一个小时内，GitHub 上的代码提交活动就被海量自动化脚本所“污染”。

我特意追踪了一些异常账号，发现这些账号的命名规律惊ly统一，基本都是像 smithhoward5868 这种典型的“英文单词+随机数字”组合。但更诡异的是，这些账号的行为模式完全不符合正常开发者的逻辑。通常我们见到的“刷子号”为了骗取 Star 或者做 SEO，至少会花点心思写个像样的 README，或者通过 Fork 热门项目来伪造贡献度。然而这类所谓的 Push-farm 机器人完全不走这条路，它们推送到仓库里的内容几乎全是乱码或毫无意义的碎片，没有 Issue，没有 Fork，甚至连一个基础的 README 也没有。

单仓库小时级690次极限推送

在监控过程中，我捕捉到一个极其极端的案例：某个僵尸号在单个仓库中，一小时内竟然完成了 690 次 Push，而且这种高频的刷屏操作竟然持续了十几个小时之久。这种强度如果放在一个真实的项目中，绝对会被认为是由于 CI/CD 配置错误导致的死循环，但在这些僵尸号这里，这似乎就是它们的“日常”。

面对这种纯粹为了制造提交记录而提交的行为，我分析了四种潜在的底层逻辑。

最直接的可能性就是薅 GitHub Actions 的羊毛。很多开发者在利用免费的 CI/CD 算力跑一些后台任务（比如简单的爬虫或定时脚本），然后将运行结果通过 Git Push 的形式回写到仓库中。因为 GitHub Actions 提供了相当慷慨的免费额度，这种方式成了很多低成本自动化工具的“默认数据库”。

低质量重复代码污染模型训练

另外，我认为这可能是一种针对大模型训练的数据污染策略。现在几乎所有主流的代码大模型都会抓取 GitHub 的公开数据，如果有人故意制造大量低质量、具有特定模式但逻辑错误的重复代码，可能会在无形中干扰模型的训练集，导致模型在学习特定逻辑时产生偏差。

高频提交养号绕过风控检测

此外，这可能是在通过高频更新来“养号”。在很多平台的权重算法中，活跃度是一个关键指标。通过这种高频提交，账号可以迅速建立起一个看起来非常勤奋的“绿墙”（Contribution Graph），从而在后续分发恶意包或推广垃圾代码时，降低被系统拦截的概率，增加可信度。

最后，尽管这些仓库没有正经的 README，但频繁的提交记录本身可能会触发某些索引算法的权重更新，从而在某种隐秘的 SEO 维度上获得优势。

实时监控脚本验证数据异常

如果你也想验证这种现象，可以通过编写简单的 Python 脚本去监控 GH Archive 的实时流数据。这种现象其实给研究模型安全的人带来了很大的启发：当训练数据中充斥着这种毫无逻辑的重复 Push 时，模型在学习代码逻辑时是否会被带偏？如果一个模型学习到的“活跃开发者”特征就是每小时提交 600 次乱码，那么它对“高质量代码”的定义是否会产生偏差？这在某种程度上预示着未来数据清洗将成为模型训练中最核心的挑战。