我们使用Git的--author标志阻止了GitHub仓库中的AI机器人垃圾信息
TL;DR · AI Summary
GitHub开源项目面临AI机器人垃圾信息泛滥问题，Archestra团队通过Git的--author标志和贡献者白名单机制成功过滤AI垃圾内容，保护了社区贡献质量。
Key Takeaways
- AI机器人导致单个issue产生253条垃圾评论，27个未测试PR污染代码库
- 团队开发London-Cat声誉系统和AI sheriff工具但效果有限
- 最终采用GitHub的'Limit to prior contributors'设置和Git --author标志验证机制
结构提纲
按章节快速跳转。
AI机器人导致GitHub仓库被253条垃圾评论和27个未测试PR淹没，严重破坏贡献质量。
团队开发London-Cat声誉系统和AI sheriff工具，但误伤合法PR效果有限。
实施贡献者白名单机制，要求通过5步 onboarding 流程才能获得评论和PR权限。
利用GitHub的'Limit to prior contributors'设置限制非贡献者权限。
通过Git的--author标志验证commit作者身份，确保只有真实贡献者能参与。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- GitHub AI垃圾问题解决方案
- 问题表现
- 253条垃圾评论
- 27个未测试PR
- 每周半天的清理成本
- 解决方案
- London-Cat声誉系统
- AI sheriff工具
- 贡献者白名单机制
- Git --author验证
- 实施效果
- 保护合法贡献者
- 质量优于数量
- 社区环境净化
金句 / Highlights
值得收藏与分享的关键句。
AI账户不仅淹没了这个issue，还淹没了整个代码库。每个草率的评论都会触发所有关注仓库的团队成员的通知。
我们的一名团队成员每周不得不花费半天时间清理代码库中的AI垃圾，删除未测试的PR和关闭幻觉问题。
我们决定反击，坚持让我们的代码库成为合法贡献者舒适安全的空间。
GitHub将'先前贡献者'定义为在main分支上有提交记录的GitHub账户作者。
标题：谈谈AI垃圾内容
来源网址：https://archestra.ai/blog/only-responsible-ai
发布时间：2026年4月17日
Markdown内容：
Hacker News上的讨论：
我们所熟知的开源时代的终结
几个月前，GitHub分享统计数据时，庆祝AI在其产品指标中的巨大贡献，却完全忽视了贡献质量下降的问题，那时我们就已经感觉到情况不妙。
第一个令人担忧的时刻是我们发布了一个悬赏900美元的问题。我们希望能激励有人贡献代码，为我们的平台带来闪亮的新“MCP Apps”支持。我们很快吸引了合法的贡献者提出计划、询问问题、提交尝试——但不久之后……
AI机器人来了，把这个问题炸开了，总评论数达到253条，用毫无意义的“实施计划”甚至对维护者的纯粹攻击毒化了对话！
AI账户开始泛滥，不仅在这个问题上——而是整个代码库。每一个草率的评论都会触发每个关注代码库的团队成员的通知。我们的GitHub通知变成了一堵噪音墙。像@ethanwater、@developerfred和@Geetk172这样积极处理悬赏任务的贡献者的真实对话被淹没了。
后来，这个问题演变成了流行病。例如，仅仅是为Archestra添加x.ai提供商支持的问题，我们就收到了[27个拉取请求](https://github.com/archestra-ai/archestra/pulls?page=1&q=is%3Apr+is%3Aclosed+is%3Aunmerged+x.ai)，其中大多数贡献者甚至没有尝试测试。
我们的一位团队成员不得不每周花费半天时间清理代码库中的AI垃圾，删除未经测试的PR并关闭幻觉产生的问题。当我们忘记这样做时，我们的代码库很快就变成了一个对合法贡献者完全不友好的地方。
反击
起初，我们尝试计算贡献者的“声誉”，并构建了一个名为"London-Cat"的小机器人，根据合并的PR和其他一些信号计算贡献者的声誉（示例）。它显然没有阻止垃圾信息，但帮助我们分辨“谁是谁”。
作为下一步，我们构建了一个“AI警长”（示例），但它显然关闭了一些合法的PR🤦。
无用的AI评论和建议不断涌来，情况只会越来越糟，赶走了合法的贡献者，让我们重新考虑：是否应该停止用悬赏激励贡献？是否应该停止给求职者提供有趣的测试任务？
我们决定需要反击，坚持让我们的代码库成为合法贡献者、负责任的AI用户、新手和经验丰富的工程师舒适安全的空间。
今天，我们禁止那些没有完成入职流程的人创建问题、开启PR和留言。
贡献者入职流程，五个步骤获得白名单权限
是的，这是一个核选项。对于一个被VC投资、通过GitHub活动严格衡量的初创公司来说，这尤其敏感，但我们必须扣动扳机：我们重视质量胜过数量。我们不看重由AI垃圾内容堆砌的指标。
我们希望Archestra成为一个优秀的软件，每个人都可以贡献，而不被AI机器人吞噬。
在GitHub上实现
在开源代码库上，没有直接的方法来白名单那些可以评论或创建PR的人，所以我们不得不采取一些变通方法。
有一个设置叫做“限制为先前贡献者”。简单规则：如果你之前没有向main分支提交过代码，你就不能评论问题或PR。
先前贡献者设置
这个设置无法区分AI机器人和注册来处理悬赏的真实开发者。两者都是“非先前贡献者”。两者都会被锁定。
GitHub将“先前贡献者”定义为GitHub账户是main分支上某个提交的作者的人。Git提交有两个身份字段——作者和提交者——他们可以是不同的人。
你可以使用Git的--author标志创建一个归属于他人的提交。如果电子邮件匹配他们的GitHub账户，GitHub会将提交链接到他们的个人资料，并授予他们贡献者状态。
每个GitHub账户都有一个noreply电子邮件：<id>+<username>@users.noreply.github.com。通过API查找ID并提交：
gh api users/their-username --jq '.id'
git commit \
--author="their-username <ID+their-username@users.noreply.github.com>" \
-m "chore: add their-username to external contributors"推送到main，他们就可以立即评论。
归属于外部用户的提交
外部用户显示为作者，我们的账户显示为提交者。这就是GitHub认为他们是先前贡献者所需的全部。
完整流程：
- 在我们的官网上进行注册，需遵守合乎道德的 AI 规则并通过 CAPTCHA 验证：https://archestra.ai/contributor-onboard
- 提交时会触发 GitHub Action，查找用户的 GitHub ID，将其用户名添加到
EXTERNAL_CONTRIBUTORS.md文件中，并以该用户账户身份向main分支推送一次提交。 - 用户随后被加入白名单并获得仓库访问权限。
结语
虽然 GitHub 报告了指标的大幅增长——其中很大一部分是由 AI 生成的——但我们作为一个开源项目团队，却不得不承担繁重的工作：清理仓库中的 AI 垃圾，并想出各种复杂的变通方案，以维持我们开源受众的合法性水平。
垃圾内容不仅挫伤了那些希望花时间做有意义事情的贡献者的积极性（他们不得不先穿越噪音之墙），还带来了巨大的安全风险，正如 LiteLLM 仓库中发生的情况——攻击者试图利用 AI 机器人操纵对话。
亲爱的社区，是时候认真讨论一下 AI 对开源的影响了。