Archestra 的 CTO Ildar Iskhakov 在博客中讲述了一个令人不安的故事：他们的开源仓库被 AI 生成的垃圾 PR 淹没，团队每周要花半天清理。而解决方案出人意料地简单——git 的 --author 参数。
AI 垃圾的冲击波
一切始于一个带 $900 赏金的 Issue。起初，真实贡献者提交方案、提出问题。但很快，AI bot 涌入，将这个 Issue 刷到 253 条评论——充斥着空洞的”实现计划”和对维护者的攻击。后来情况恶化：单个 Issue 收到 27 个 PR，大部分甚至未经测试。团队的 GitHub 通知变成了噪音墙。
“这不是合约工作——这是我们向社区表达感谢的可选方式，”Iskhakov 写道。但 AI 让这个善意机制变成了噩梦。
反击：从声誉系统到 –author
团队首先尝试了”London-Cat”——一个基于合并 PR 数量计算贡献者声誉的小型 bot。它失败了：AI bot 开始故意提交简单修复以积累声誉。团队还尝试了更严格的 PR 模板、Contributor License Agreement (CLA)。但这些都增加了真实贡献者的门槛。
最终方案：利用 Git 原生的 --author 标志。GitHub Actions 工作流检查 PR 作者的 commit 历史——如果账户在仓库中没有过往合并记录，PR 自动标记为需要人工审核。这不能阻止垃圾提交，但将审查负担从”被动应对”转变为”主动筛选”。
安全隐忧
HN 用户 captn3m0 指出了一个被忽视的安全问题：GitHub 的”首次贡献者需审批”机制存在漏洞——恶意用户可以通过提交无害的 typo 修复获得”已贡献者”身份，从而绕过后续 PR 审批。这为供应链攻击打开了窗口。
halapro 直言：”GitHub 应该为此负责。如果他们实施了最基本的评论和 PR 门槛，我们不会落到这步。” silverwind 则建议 GitHub 应临时封禁 PR 拒绝率超过 95% 的账户。
这是开源的警钟
krupan 的评论切中要害：”这就是我们到处宣扬 AI 编程有多厉害的后果。从 AI 厂商开始，到受人尊敬的独立开发者推波助澜，再到 Meta 裁员的新闻火上浇油——现在每个人都深信他们的 AI 朋友在产出惊人代码。”
Archestra 团队的做法提供了一个务实模板：不追求完美的 AI 检测，而是用简单的 Git 原生机制建立防线。正如 Iskhakov 总结：”我们不是反对 AI——我们反对不负责任的 AI。”