Archestra 一个 $900 bounty issue 被 AI 机器人灌了 253 条评论,同一功能收到 27 个未经测试的 PR。团队成员每周花半天清理 AI 垃圾。这不是个例——你的开源项目可能就是下一个。
一、当 AI 成为开源社区的"垃圾制造机"
2026 年 4 月,VC 背书的开源平台 Archestra(GitHub 3.7k stars)发布了一个带 $900 赏金的 issue,希望社区贡献者帮忙实现"MCP Apps"支持。
前几个小时一切正常——真实开发者在讨论方案、提交尝试。然后 AI 机器人来了。
数据触目惊心:
- 单个 issue 被灌到 253 条评论,真实讨论被淹没
- 同一个功能(x.ai provider)收到 27 个 PR,绝大多数未经测试
- 团队成员每周花半天手动清理 AI 垃圾
- GitHub 通知变成噪音墙,真实贡献者 @ethanwater、@developerfred 的讨论被深埋
CTO Ildar Iskhakov 在博文中写道:"AI accounts started flooding not just this issue — but the entire repo. Every sloppy comment triggered a notification for every team member."
更让人不安的是,这不是 Archestra 一家的问题。HN 讨论中有人指出:某些开源仓库最近一个月的 commits 中,超过一半是 AI 噪音。
对于 AI 创业者来说,这个问题加倍致命:你的开源项目是你的技术名片、招聘漏斗、社区资产。被 AI slop 淹没 = 真实贡献者流失 = 项目慢性死亡。
二、Archestra 的三次防守升级(附工具链)
2.1 第一道防线:信誉机器人 "London-Cat"
Archestra 最早建立了一个叫 London-Cat 的微型 bot,根据 merged PR 数量等信号计算贡献者信誉分。
# London-Cat 核心逻辑简化版
import requests
import os
GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]
REPO = "archestra-ai/archestra"
def get_contributor_reputation(username: str) -> dict:
"""计算贡献者在目标仓库的信誉分"""
headers = {"Authorization": f"Bearer {GITHUB_TOKEN}"}
# 1. 统计 merged PRs
merged_prs = requests.get(
f"https://api.github.com/search/issues"
f"?q=repo:{REPO}+is:pr+author:{username}+is:merged",
headers=headers
).json().get("total_count", 0)
# 2. 检查是否被标记为 spam
spam_labels = requests.get(
f"https://api.github.com/search/issues"
f"?q=repo:{REPO}+author:{username}+label:spam",
headers=headers
).json().get("total_count", 0)
# 3. 计算综合分数
score = min(100, merged_prs * 20 - spam_labels * 50)
return {
"username": username,
"merged_prs": merged_prs,
"spam_count": spam_labels,
"reputation_score": max(0, score),
"trust_level": "high" if score >= 60 else "low" if score < 20 else "medium"
}
# 在 issue comment webhook 中调用
def on_issue_comment(comment):
rep = get_contributor_reputation(comment["user"]["login"])
if rep["trust_level"] == "low" and rep["merged_prs"] == 0:
# 自动标记为可疑
label_comment_as_spam(comment["id"])
post_warning(comment["issue_url"],
f"⚠️ @{comment['user']['login']} 信誉分 {rep['reputation_score']},"
f"此评论已被标记为待审核。")
效果评估: London-Cat 帮助团队快速识别"谁是谁",但并不能阻止 spam——bot 不在乎被标记,它们只是继续灌。
⚠️ 踩坑1:单纯的信誉系统在 AI spam 面前是纸老虎。AI bot 不会因为被打低分就停止——它们没有羞耻心。信誉系统只对真实人类有效。
2.2 第二道防线:AI Sheriff(用 AI 打 AI)
Archestra 接着构建了"AI Sheriff"——一个用 AI 检测 AI 内容的机器人。
# GitHub Actions workflow: AI Sheriff
name: AI Spam Detector
on:
issues:
types: [opened, edited]
pull_request:
types: [opened, edited]
issue_comment:
types: [created, edited]
jobs:
detect-spam:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Analyze content with AI
id: analyze
uses: archestra-ai/spam-detector-action@v1
with:
openai-key: ${{ secrets.OPENAI_API_KEY }}
content: ${{ github.event.comment.body || github.event.issue.body }}
thresholds: |
spam_probability: 0.85
ai_generated_probability: 0.90
min_account_age_days: 7
- name: Auto-close if spam
if: steps.analyze.outputs.is_spam == 'true'
uses: actions/github-script@v7
with:
script: |
const reason = `${{ steps.analyze.outputs.reason }}`;
const spamLabel = '🤖 AI-generated';
if (context.eventName === 'pull_request') {
await github.rest.issues.createComment({
...context.repo,
issue_number: context.issue.number,
body: `⚠️ 此 PR 被 AI Sheriff 检测为疑似 AI 生成内容。\n原因:${reason}\n\n如果你是真实开发者,请回复 "!human" 触发人工审核。`
});
await github.rest.pulls.update({
...context.repo,
pull_number: context.issue.number,
state: 'closed'
});
}
await github.rest.issues.addLabels({
...context.repo,
issue_number: context.issue.number,
labels: [spamLabel]
});
效果评估: 这个方案更激进,但也更容易误伤——Archestra 承认 AI Sheriff 关闭了一些合法 PR 🤦。
⚠️ 踩坑2:用 AI 检测 AI 内容存在根本性的军备竞赛问题。GPT-4 检测 GPT-4 生成内容的准确率不超过 70%。更糟的是,检测模型有偏见——非英语母语者的内容更容易被误判为 AI 生成。
2.3 第三道防线:贡献者入门白名单(核选项)
前两道防线失败后,Archestra 祭出了"核选项":
核心机制: 利用 GitHub 的"Limit to prior contributors"设置 + 自定义 onboarding CI 脚本。
# onboarding.py — Archestra 贡献者白名单系统的简化实现
import hashlib
import hmac
import json
import os
import time
import requests
from flask import Flask, request, jsonify
app = Flask(__name__)
GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]
WEBHOOK_SECRET = os.environ["WEBHOOK_SECRET"]
REPO = "archestra-ai/archestra"
# 使用 GitHub 的 co-author 机制将用户标记为"prior contributor"
@app.route("/onboard", methods=["POST"])
def onboard_contributor():
"""五步入门流程,完成后自动创建一个 co-authored commit"""
data = request.json
github_username = data.get("github_username")
if not github_username:
return jsonify({"error": "Missing github_username"}), 400
# 步骤1-4:CAPTCHA + 行为准则确认 + 文档阅读 + 小测验
# (此处省略前端流程,假设已通过)
# 步骤5:创建 co-authored commit 将用户标记为 prior contributor
result = create_onboarding_commit(github_username)
return jsonify({
"status": "onboarded",
"commit_sha": result.get("sha"),
"message": "你现在可以创建 issues、PR 和评论了!"
})
def create_onboarding_commit(username: str) -> dict:
"""利用 GitHub co-author 机制创建白名单 commit"""
# 1. 获取当前 CONTRIBUTORS.md 的 SHA
headers = {
"Authorization": f"Bearer {GITHUB_TOKEN}",
"Accept": "application/vnd.github+json"
}
file_resp = requests.get(
f"https://api.github.com/repos/{REPO}/contents/CONTRIBUTORS.md",
headers=headers
).json()
# 2. 在 CONTRIBUTORS.md 末尾追加用户名(实际操作用无害的微小改动)
current_content = requests.get(file_resp["download_url"]).text
new_content = current_content + f"\n- @{username} (onboarded {time.strftime('%Y-%m-%d')})"
# 3. 创建 commit,使用 co-author 将用户标记为 contributor
commit_payload = {
"message": f"docs: onboard @{username} as contributor\n\n"
f"Co-authored-by: {username} <{username}@users.noreply.github.com>",
"content": base64_encode(new_content),
"sha": file_resp["sha"],
"branch": "main",
"committer": {
"name": "Onboarding Bot",
"email": "bot@archestra.ai"
},
"author": {
"name": username,
"email": f"{username}@users.noreply.github.com"
}
}
resp = requests.put(
f"https://api.github.com/repos/{REPO}/contents/CONTRIBUTORS.md",
headers=headers,
json=commit_payload
)
return resp.json()
def base64_encode(content: str) -> str:
import base64
return base64.b64encode(content.encode()).decode()
if __name__ == "__main__":
app.run(port=5000)
关键机制解读:
GitHub 的"Limit to prior contributors"选项的判断依据是:该 GitHub 账户是否有 commit 被合并到默认分支(main/master)的提交历史中。
Archestra 的巧妙之处:让新贡献者通过 CAPTCHA 验证后,自动创建一个以该用户为 co-author 的微小 commit。此后该用户就是"prior contributor"了,可以正常创建 issue/PR/评论。
效果: 上线后成功拦截了 至少 500 个 AI bot 账户——bot 不会过 CAPTCHA,也不会点击行为准则确认。
⚠️ 踩坑3(安全风险):HN 用户 @captn3m0 在讨论中指出——GitHub 文档警告,成为 prior contributor 后,该用户的 fork PR 将绕过审批要求而自动运行 CI。这意味着如果 bot 绕过了白名单(例如用人肉打码平台),就有可能推送恶意代码并获得自动 CI 执行权限。
> 缓解方案: 始终在 CI 中对 fork PR 进行额外审查,不依赖 GitHub 的"prior contributor"状态来做安全决策。
⚠️ 踩坑4(噪音转移):HN 用户 @optionalsquid 发现了一个讽刺的现象——Archestra 仓库最近一个月的 commits 中,超过一半(369/3521)是 onboarding 产生的"噪音 commits"。垃圾从 issues 转移到了 commits 历史。虽然 commits 不会触发通知,但 git blame 被污染了。
三、社区正在涌现的防御工具(2026年5月)
除了 Archestra 的自研方案,社区也在快速响应这个问题:
| 工具 | 原理 | 适用场景 | 状态 |
|---|
Git --author flag | 在 CI 中检查 PR 作者的 commit 历史 | 所有 GitHub 仓库 | 原生支持 |
| GitHub Interaction Limits | 临时限制新账户互动 | 短期 spam 攻击 | 内置但有时效 |
| terminal-guardian-mcp | MCP 服务器,沙箱化终端访问+风险分析 | Claude Code 等 Agent 工具 | 新项目(2 stars) |
| Reputation Bot (London-Cat) | 基于 merged PRs 计算信誉分 | 有 bounty 的活跃仓库 | 原型阶段 |
3.1 利用 Git `--author` flag 做第一轮过滤
HN 讨论中反复出现的一个简单方案——在 CI 中用 git log --author 检查:
#!/bin/bash
# .github/scripts/check-first-timer.sh
# PR 创建时运行,检查作者是否在仓库历史中
AUTHOR_EMAIL="$1"
MIN_COMMITS=2
EXEMPT_LABEL="legitimate-newcomer"
# 例外:手动标记的合法新人
if gh pr view --json labels | grep -q "$EXEMPT_LABEL"; then
echo "✅ 已标记为合法新人,跳过检查"
exit 0
fi
# 检查该 email 在仓库历史中的 commit 数量
COMMIT_COUNT=$(git log --all --author="$AUTHOR_EMAIL" --oneline | wc -l)
if [ "$COMMIT_COUNT" -lt "$MIN_COMMITS" ]; then
echo "⚠️ 警告:$AUTHOR_EMAIL 在仓库中仅有 $COMMIT_COUNT 个 commits"
echo " 此 PR 被自动标记为待审核"
gh pr edit --add-label "needs-review"
gh pr comment --body "🤖 自动检测:你在本仓库的 commit 数量不足 $MIN_COMMITS。\n
维护者将在 24 小时内审核。为加快流程,请在 PR 描述中说明你的实现思路。"
else
echo "✅ $AUTHOR_EMAIL 有 $COMMIT_COUNT 个历史 commits,通过检查"
fi
四、AI 创业者的防守清单
如果你是维护开源项目的 AI 创业者,以下是分阶段的防守策略:
阶段1:基础防御(今天就可以做)
# 1. 开启 GitHub 仓库的互动限制
# Settings → Moderation → Interaction limits →
# "Limit to prior contributors" (临时模式)
# 2. 在 CI 中添加作者历史检查
# 将上面的 check-first-timer.sh 加入 PR workflow
# 3. 设置 issue template 要求贡献者描述实现思路
# .github/ISSUE_TEMPLATE/feature_request.md 中添加:
# "请用至少50字描述你的实现思路(AI生成的泛泛而谈将被关闭)"
阶段2:工具化防御(本周可以部署)
- AI 内容检测 Action:类似 Archestra 的 AI Sheriff,但调低阈值避免误伤
- 信誉系统:基于 merged PRs 的轻量评分
- 速率限制:限制单个账户每天最多创建 3 个 issue / 2 个 PR
阶段3:白名单系统(适合活跃社区)
- 贡献者入门流程(CAPTCHA + 行为准则 + 文档阅读)
- co-author commit 机制自动授予 prior contributor 状态
- 定期审计 onboarding commits,清理长时间无活跃的权限
五、常见踩坑问题
Q1: 用 AI 检测 AI,会不会误伤真实开发者?
会。 Archestra 的 AI Sheriff 就关掉过合法 PR。建议:
- 检测阈值设高(>0.9 概率才自动关闭),低概率只标记
- 提供申诉机制(如回复
!human 或 @maintainer 触发人工审核) - 对已知社区成员加白名单
Q2: GitHub 为什么不直接解决这个问题?
HN 讨论中很多人问了同样的问题。可能的原因:
- GitHub 的贡献者增长指标("每秒钟新增一个开发者")依赖 AI 贡献数据
- 区分 AI 和人类的准确率还不够高
- 误伤真实新人的代价太大
但在微软/OpenAI 和 GitHub 同属一个生态的背景下,社区对此的耐心正在耗尽。
Q3: 这些防御措施对小型仓库也适用吗?
更要防。 小仓库的问题不是 spam 量,而是人力不足——小团队没有半天/周来清理。建议:
- 小型项目直接开启"Limit to prior contributors"
- 设置 Discord/论坛作为讨论入口,GitHub issues 仅限核心开发
- 将 bounty 改为定向邀请而非公开悬赏
Q4: 白名单 onboarding commit 污染 git 历史怎么办?
这是目前方案最大的副作用。Archestra 已经有超过 10% 的 commits 是 onboarding 噪音。缓解方案:
- 使用独立分支存放 onboarding commits,定期 squash
- 或者使用 GitHub App 权限而非 co-author commit——用 App 将用户加入团队(需要组织账号)
- 长期来看,希望 GitHub 提供原生的"verified contributor"机制
六、总结
AI 机器人正在从根本上改变开源协作的信任模型。以前你可以假设来提 PR 的都是善意的开发者,现在你必须假设第一个 PR 可能是无人审查的 AI 生成代码。
Archestra 的三道防线是一个逐步升级的实战路径:
- 信誉系统(了解"谁是谁")
- AI 检测(用 AI 打 AI,但小心误伤)
- 白名单门槛(放弃开放,换取质量)
对于 AI 创业者来说,保护你的开源项目就是保护你的技术品牌。一个被 AI slop 淹没的仓库不会吸引真实贡献者,也不会让潜在客户相信你的技术能力。
立即行动: 花 30 分钟在你最重要的仓库里部署阶段1防御(interaction limits + CI 作者检查)。这是最低成本、最高收益的投资。
*本文参考:Archestra 团队博文《Let's talk about AI slop》(2026.4.17)、HN 讨论(234 points / 101 comments)、GitHub 社区讨论。*
#AI创业 #开源维护 #AI Agent #防spam #GitHub
本文由AI辅助创作,经人工审核编辑发布