开源项目正在被 AI Bot 淹没
如果你最近在 GitHub 上维护过中等规模的开源项目，你可能已经注意到了这个现象：
每天冒出一堆 PR——有些是依赖更新的，有些是文档改进的，有些是"看起来像代码"但实际毫无价值的提交。它们大多来自 AI Agent：自动 fork、自动修改、自动提 PR，整套流程不需要人类介入。
更糟糕的是，这些 Bot 不仅提 PR，还会刷 Star——用批量注册的账号给项目点星，制造虚假的热度。GitHub Trending 上越来越多的项目，其 Star 增长速度与实际社区活跃度严重不匹配。
Archestra AI 团队在一篇 Hacker News 热帖（435 分，195 条评论）中分享了他们的应对方案，核心只有一句话：用 Git 的 --author flag 来标记和过滤自动化提交。
方案原理
这个方案的逻辑很简单：
# 正常的人类提交
git commit -m "fix: update README"
# author 是你的 GitHub 账号
# AI Bot 的提交（通常）
git commit -m "feat: auto-update dependencies"
# author 可能是 bot 的默认身份，或者随机伪造的
Archestra 的做法是：在 CI/CD 中检查每个提交的 author 信息，对来自非人类身份的提交施加不同的审核规则。 具体来说：
- 标记自动化提交：通过 author name/email 模式识别 Bot 提交
- 强制人工审核：标记后的提交必须经过维护者手动 review 才能 merge
- 限制批量操作：对同一 author 在短时间内的大量提交实施速率限制
这本质上是一个工作流层面的防御，而不是技术层面的 AI 检测。它不需要训练分类器、不需要分析代码质量、不需要判断"这像不像 AI 写的"。它只做一件事：让自动化提交走不同的流程通道。
为什么这招有效
因为 AI Bot 刷 PR/Star 的核心优势是规模和速度——它们能在几分钟内对几百个项目提交修改。一旦你增加了人工审核这个环节，规模优势就被中和了：
- 人类审核一条 PR 需要几分钟
- Bot 不可能等几分钟——它的经济模型建立在"提交一千条，中一条就行"的假设上
- 当每条提交都需要等人工审核时，Bot 的 ROI 就崩了
这是一个经济学意义上的防御，不是技术意义上的。它让攻击者的成本高于收益。
更深层的问题
但这个方案也暴露了一个更大的问题：Git 的 author 机制太容易被伪造了。
git commit --author="Real Human <human@example.com>" -m "totally not a bot"
任何有基本 Git 知识的人都可以伪装成任意 author。所以这个方案的有效性取决于一个前提：大部分 AI Bot 是懒惰的，不会花精力去伪造 author 信息。
对于低成本的 spam bot，这招够用。但对于真正有针对性的攻击，可能需要更复杂的方案：
- GitHub 的 Verified 提交签名：要求提交用 GPG 或 SSH 签名
- 贡献者白名单：只接受来自组织成员的自动 PR
- 行为分析：检测异常提交模式（时间分布、修改内容一致性等）
对开源社区的启示
HN 帖子下的讨论指向了一个共识：2026 年的开源维护正在变成一场"反 Bot 军备竞赛"。
AI Agent 让自动化贡献的门槛降到了零——任何人（或任何公司）都可以部署一个 Bot，让它自动扫描 GitHub 上的项目，找到可以"改进"的地方，然后批量提交 PR。这对开源生态的噪音水平是指数级的提升。
而维护者的时间和精力是有限的。如果一个项目的维护者每天要花两小时从几十个 Bot PR 中筛选出真正有价值的那个，这个项目的可持续性就受到了威胁。
--author flag 方案的价值不在于它是一个终极解决方案，而在于它代表了一种思路：与其在 AI 层面和 Bot 对抗，不如在工作流层面改变规则。 当 AI 让某些行为变得太容易时，你需要改变的不是检测能力，而是整个流程的经济学。
行动建议
如果你的开源项目正在被 Bot PR 淹没：
- 启用 branch protection rules：要求所有 PR 必须通过 review 才能 merge
- 检查 author 模式：看看是否能识别出 Bot 提交的特征
- 利用 GitHub 的 spam 报告：批量举报明显的 Bot 账号
- 考虑贡献者准入机制：对于高度自动化的项目，可以要求新贡献者先提交一个 non-trivial 的 PR 来证明是真人
这不会完全解决问题，但至少能把噪音降低到一个可管理的水平。