今天的PR垃圾邮件就像2000年代初的电子邮件垃圾邮件
摘要
对OpenClaw仓库中拉取请求的统计分析显示,AI生成的PR垃圾邮件激增,合并率从48%下降到9.3%,贡献者每天提交数百个自动PR。文章将这一现象与早期的电子邮件垃圾邮件进行比较,并讨论了基于信誉的过滤器和信任管理系统(如Vouch)等新兴解决方案。
暂无内容
查看缓存全文
缓存时间: 2026/06/24 16:52
# openclaw/openclaw 上 PR 的统计研究
来源:https://www.greptile.com/blog/prs-on-openclaw
我是 Rahul,在 Greptile 工作,我们构建了用于审查拉取请求的 AI 代理。Greptile 为 OpenClaw 审查 PR,而 OpenClaw 几乎在一夜之间成为 GitHub 历史上增长最快的仓库。这让我们得以近距离观察一些奇怪的现象。
去年 12 月,OpenClaw 每周收到两个拉取请求。到 2 月,这个数字跃升至每周 3400 个。在激增之前,大约 48% 的 PR 被合并;之后,只有不到 9.3% 的 PR 被合并。
其中许多 PR 是低质量的垃圾,通常是由人们的 AI 编码助手生成的。例如,一位贡献者在一天内提交了 106 个 PR,提交之间的中位时间仅为*三秒*。
从很多方面来看,openclaw/openclaw 向我们展示了开源贡献未来可能的样子。以下是三个观察结果:
### PR 将需要发送方信誉
今天的 PR 垃圾就像 2000 年代初的电子邮件垃圾。
当我第一次查看 OpenClaw 数据时,这种模式让我想起了电子邮件。2000 年,ILOVEYOU 蠕虫病毒在 24 小时内感染了 4500 万台计算机,因为发送邮件的成本接近于零,而且人们信任该平台。结果,人们收到了大量邮件,其中一些是恶意的。同样的参数也适用于今天的 PR。
最初的修复方案类似:使用黑名单来管理数量,使用基于置信度的过滤器和信誉基础设施来捕捉不良行为者。今天,你的邮件是否能到达收件人的收件箱取决于两件事:你是谁,以及你的发送历史。
OpenClaw 上的贡献者已经根据他们的信誉被过滤:首次贡献者的合并率为 8.2%,有 2-5 个 PR 的贡献者为 10.3%,5 个以上的为 18.6%。
Mitchell Hashimoto 创建并维护了 Ghostty,这是最流行的开源终端模拟器之一。随着项目获得动力,人们提交了大量 AI 生成的 PR 垃圾,以至于他需要限制 AI 生成的贡献。
一周后,他发布了一个解决方案:Vouch (https://github.com/mitchellh/vouch),这是一个针对开源贡献者的信任管理系统。未经认证的用户无法贡献,不良行为者会被明确标记。虽然 Vouch 目前是针对特定项目的,但 Mitchell 的愿景是信任决策最终能在共享相似价值观的项目之间扩散。Vouch 相当于开源世界的发送方信誉评分。(值得一提的是:虽然 Vouch 在 Ghostty 上运行良好 (https://x.com/mitchellh/status/2048085375139422366),但 Mitchell 决定将 Ghostty 从 GitHub 上移除 (https://mitchellh.com/writing/ghostty-leaving-github)。)
### 如果所有贡献者都以同样的方式思考,更多贡献者也无济于事
Linus Torvalds 有句名言:“只要有足够多的眼球,所有的 bug 都是浅显的。”
让更多人关注同一个问题会带来多样化的视角。不同的人以不同方式使用软件,遇到不同的 bug,并以新颖的方式解决问题。
当每个人都汇聚到 Claude / Codex / Cursor / Devin 等工具上时,这条规则可能不再适用。在 OpenClaw 中:
- 4 位贡献者提交了标题完全相同的 PR:“feat(web-search): add SearXNG as a search provider”。他们是 10 多位独立尝试添加同一功能的人中的 4 位。
- 6 个人独立修复了同一个 Brave Search 区域设置 bug。其中 2 个人在 94 分钟内提交了标题完全相同的 PR。
- 5 个人独立发现了代理运行器中相同的超时死锁。
OpenClaw 上的眼睛比以往任何时候都多,但他们的视角也同样被 AI 编码助手过滤。如果大多数贡献者使用相同的 AI 编码助手和相同的提示,那么他们的贡献也将彼此相似。
开源的优势和承诺在于思想的多样性。只有底层的思维保持多样性,Linus 定律才能成立。真正研究过代码库的贡献者与没有研究过的贡献者,他们的提示方式会不同。
### 实际被合并的是什么
在 OpenClaw 的 PR 数据中,功能的合并率为 9%,而重构的合并率为 35%。
需要深入理解现有代码库的贡献,其表现比新功能贡献高出近 4 倍。这就是如今常说的道理:思考远比打字重要。数据证明了这一点。
例如,claude-mem (https://github.com/thedotmack/claude-mem) 将 Claude Code 的钩子捕获工具流映射到其自身的可恢复 Agent SDK 观察会话的方式,是一个非显而易见的架构选择,需要对两个系统都有深入理解。理解这一决策的软件开发人员能够将其提炼为一个检查清单,这将成为提示词,使得代理的输出显著更好。而一个只被提示“构建一个记忆系统”的代理,自己无法做到这一点。
直到 200 年前,设计建筑的人同时也建造它们。他们被称为总建筑师。随着建筑技术的进步,这一角色分裂为两个行业:建筑设计和建筑施工。软件领域的类比并不完全成立。建筑师仍然需要知道建筑如何立起来。但这指向了一个真实的现象:能够通过审查的贡献,越来越多的是那些代理无法独自完成的任务,是需要对现有系统有深入理解的决策,而不是全新的构建。
### 那么,接下来呢?
OpenClaw 在短短几个月内从无到有,变成了一个真实世界的 Jarvis。一个人,加上一个强大的社区,能够以一年前不可能的速度进行构建。这非常特别。
开源社区现在可以比以往任何时候都更快地构建。这种速度带来的问题,需要在身份、信誉以及我们如何验证贡献方面有更好的原语,而这些都将被构建出来。开源以前解决过更困难的问题。
相似文章
AI 代理提交的 PR 数量创下新高,但有人关心过这是否真的推动了业务发展吗?
一篇评论文章,质疑 AI 代理生成的拉取请求和 token 消耗指标激增是否真的能转化为有意义的业务价值,并警告不要优化虚荣指标而忽视实际影响。
别再给我发超大PR了;一篇吐槽
这篇吐槽批评了软件开发中流行的大型AI生成的拉取请求趋势,提倡使用更小、易于审查的改动来提升代码质量和审查者的体验。
@GergelyOrosz: 引人入胜:查看Bun仓库中的PR,大部分都是AI评审员在与AI机器人对话...!CodeRabbit和Claude...
观察到Bun仓库中的许多PR都涉及AI评审员(CodeRabbit和Claude)与AI机器人(Robobun)的交互,突显了AI在代码审查中日益增长的作用。
在 PR 审核的前 60 秒,你实际会关注什么?(针对 AI 生成的 PR)
一位开发者正在寻求反馈,关于构建一个系统来审核 AI 生成的拉取请求,通过降低认知负担并突出关键变更,询问前 60 秒的审核实践和信任证据。
构建了一个AI PR审核工作流,可生成实际修复PR而不仅仅是评论
作者构建了一个AI驱动的PR审核工作流,可生成实际修复PR而不仅仅是评论,声称比CodeRabbit便宜6倍,且在处理大型PR时更准确。