一个$900悬赏的Issue被AI Bot刷了253条评论、27个假PR，维护者每周花半天时间清理。这不是科幻，是今天GitHub上的真实场景。371个Hacker News用户用Upvote投出了一个信号：AI Bot正在杀死开源社区。
事件回顾
5月18日，一篇名为《Archestra: How I had to defend my open source project from AI bots》的文章在Hacker News上引爆社区，拿下371分和178条评论。作者是一个开源项目的维护者，他的遭遇让整个开发者社区感同身受。
事情的起因很简单：作者在GitHub上发布了一个$900的悬赏Issue，希望社区协助解决一个技术难题。然而，AI Bot的洪水在短短几天内涌来——253条AI生成的评论，27个完全无效的假Pull Request，每个都需要人工检查、回复、关闭。
维护者说，他每周要花至少半个工作日来处理这些AI Bot制造的「垃圾」。更讽刺的是，这些AI Bot本身用的就是开源代码——它们用开源社区的成果来攻击开源社区。
为什么重要
这不是孤立事件——这是一个系统性的问题，而且正在加速恶化。
AI的能力越强，问题越严重。 Claude Code、Cursor、GPT-5等编程Agent的普及，让「自动提交代码」变得前所未有的容易。一个没有恶意的脚本小子，跑一个开源的AI Agent工具，配置一个GitHub Issue scanner，就能在几分钟内生成并提交几十个PR。这些PR看起来「像模像样」——有代码改动、有commit message、有测试——但实际上一行有用的代码都没有。更可怕的是，这些PR的质量在快速提升：三个月前还能一眼识破，现在已经需要花费维护者几分钟来评估和否定。
开源社区的信任机制正在被AI瓦解。 GitHub的协作模型建立在「提交者是人」的假设上。Reviewers信任提交者的判断，维护者信任贡献者的善意。AI Bot的涌入正在摧毁这个信任基础——每一个PR都需要被怀疑，每一个Issue都需要被验证。一位HN评论者说得好：「这不是反向图灵测试的问题，问题是一个差劲的AI Bot不会惹恼你走开——它会持续制造垃圾，直到你把Issue关闭。」
178条HN评论的共识： 这比垃圾邮件更危险。垃圾邮件你一眼就能认出来，但AI生成的代码看起来「太真实了」——它不像垃圾，倒像一个努力但没理解问题的初级开发者。
从371分里读出的三条信息
1. 每个开源维护者都在面对同样的困境
HN评论区里，大量维护者分享了自己的经历：「我的项目也被AI Bot攻击了」「我已经被迫关闭了所有公开Issue」「我在GitHub Actions里加了AI检测规则」。这不是一两个人的抱怨——这是一个正在发生的行业生态变化。有人甚至说，他的项目在6个月前还好好的，自从GPT-5的Claude Code集成出来后，AI PR的数量暴增了50倍。
2. 「防AI」正在成为新的基础架构需求
GitHub官方的「prior contributor」设置和Git的 --author flag 原本不是为防AI设计的。但现在，它们是开源维护者最依赖的防线。作者提出的实操方案，已经被多家知名开源项目采纳：
- 在仓库设置中开启「Only allow prior contributors to submit PRs」
- 使用
git log --author过滤非人工提交 - 在CONTRIBUTING.md中明确声明AI提交的规则和惩罚
- 在CI pipeline中加入token合法性校验——很多AI Bot不会配置真正的GitHub token
3. 有一家创业公司的机会就在这里
问题越痛，机会越大。当前GitHub生态中没有一个专门的「AI Bot检测与过滤」工具。维护者只能手动应对。一个能自动识别AI生成PR、标记可疑提交、甚至与GitHub API集成的SaaS工具，对开源社区来说是一个刚需。一位HN评论者估算：「如果有一个工具能帮我把每周半天的清理时间减少到10分钟，我愿意每月付$50-$100。」按全球100万活跃开源维护者计算，即使1%的付费率，这也是一个每年$600万-$1200万的市场。
对AI创业者的启示
如果你在运营开源项目，这是你当前最应该关注的问题之一。几个实操建议：
短期（今天就能做）：检查你的GitHub仓库设置，开启「Restrict contributions to prior contributors」。在你的Issue模板中添加AI提交警告。每天花5分钟检查PR队列。如果你用的是Hermes Agent或OpenClaw，确保你的Agent配置中没有启用「自动扫Issue提交PR」的模式。
中期（1-2周内）：建立AI贡献的白名单机制，在CONTRIBUTING.md中明确规则。考虑使用GitHub Actions的workflow来自动标记异常PR（例如：提交时间在凌晨3-6点、commit消息模式太整齐、没有对应的Issue讨论）。对于MCP协议接入的Agent工具，可考虑在tool调用层加一层「人工确认」的阀门。
长期（商业机会）：如果你在找AI创业方向，这是被验证的痛点。一个「AI Bot防火墙」服务——集成GitHub API、使用ML模型识别AI生成代码、自动阻止低质量PR——几乎可以确认会有付费用户。371分的HN热度就是你的市场需求调研。这个市场的独特之处在于：被攻击者（维护者）和防御者（AI Bot防火墙）站在同一边——大家好才是真的好。
底线
AI Bot淹没GitHub不是技术问题——是人类协作模型被AI冲击的第一个前线。如果你只读一条行动建议，那就是：不要让AI Bot的垃圾成为你项目的负担，规则要在被淹没之前建立。
开源不会被AI杀死，但开源社区需要新的规则来适应AI时代。谁能定义这些规则，谁就能定义开源的下一个十年。
这个故事的更深层意义是：我们在用AI Agent构建自动化工具的同时，必须提前思考「谁来清理AI制造的副产品」这个问题。从GitHub的PR到Web3的漏洞报告、从论文的审稿到代码的review——AI生成内容的「真伪甄别」将成为2026年最被低估的基础设施赛道。