AI 编程 Agent 提交的 PR 被拒率超 90%：OpenClaw 上的 PR 垃圾邮件风暴
昨天刷 Hacker News 的时候看到一个帖子，标题直接把我吸引住了：「PR spam today looks like email spam in the early 2000s」。点进去一看，是 Greptile 团队做的一份统计分析，数据来自 GitHub 上增长最快的仓库之一 —— OpenClaw。
看完之后我沉默了好一会儿。
不是因为数据有多震撼（虽然确实挺震撼的），而是因为这事儿跟我们每个用 AI 编程工具的人都有关系。你用 Claude Code 写代码、用 Cursor 补全、用 Copilot 生成函数 —— 这些工具产出的代码，最终可能以 PR 的形式出现在开源项目里。而当所有人都在用同样的工具、同样的模型、同样的提示词去贡献代码的时候，开源社区会发生什么？
OpenClaw 给了我们一个真实的答案。
从每周 2 个 PR 到每周 3400 个
先说说背景。OpenClaw 是一个开源 AI Agent 项目，增长速度极快，几个月就成了 GitHub 上最火的仓库之一。Greptile 做 OpenClaw 的 PR review 服务，所以他们能看到完整的 PR 数据。
数据是这样的：
- 去年 12 月，OpenClaw 每周收到大约 2 个 PR
- 到了今年 2 月，这个数字暴涨到每周 3400 个
- 在暴涨之前，大约 48% 的 PR 能被合并
- 暴涨之后，合并率跌到了 9.3% 以下
从 2 个到 3400 个，合并率从 48% 跌到 9%。你品品这个数字。
更离谱的是，有一个贡献者一天之内提交了 106 个 PR。106 个。我算了一下，就算他每个 PR 只花 5 分钟写，那也是快 9 个小时不间断地提交。但实际上，这些 PR 之间的中位提交间隔只有 3 秒。
3 秒。
这不是人在写代码，这是 AI Agent 在自动提交。一个人开了个脚本，让 Claude 或者 Codex 不停地生成代码、创建分支、提交 PR，然后就这么循环了一天。至于质量嘛……你猜。
为什么会出现 PR 垃圾邮件
要理解这个现象，得先搞清楚一件事：现在用 AI 编程 Agent 提交 PR 的成本几乎为零。
以前你想给开源项目贡献代码，得先读懂代码库，理解架构，找到可以改进的地方，写代码，测试，然后提 PR。整个流程下来，少说也得几个小时。
现在呢？你跟 Claude Code 说一句「看看这个仓库有什么可以改进的」，它就能自动分析代码、找到问题、生成修复方案、写好代码、创建 PR。整个过程可能不到 5 分钟。
成本降到接近零，数量就会爆炸。这跟 2000 年的电子邮件垃圾邮件一模一样。
Greptile 的 Rahul 在文章里做了个类比，我觉得特别到位：2000 年的 ILOVEYOU 病毒在 24 小时内感染了 4500 万台电脑，原因就是发送邮件的成本趋近于零，而人们信任这个平台。现在 PR 的情况完全一样 —— 提交成本趋近于零，而项目维护者默认信任每一个 PR。
不过我觉得这个类比还可以延伸一步。邮件垃圾邮件最终催生了 Gmail 的 spam filter、发件人信誉系统（SPF/DKIM/DMARC）这些基础设施。PR 垃圾邮件也会催生类似的基础设施 —— 只是目前还在早期阶段。
你可能会问：这些人为什么要提交这么多 PR？动机其实挺多样化的。有些人是真的想贡献代码，但用了错误的方式 —— 他们让 Agent 扫描整个仓库，找到所有「可以改进」的地方，然后批量提交。有些人是想刷 GitHub 贡献图（那个绿色小方格），觉得 PR 数量多就是「活跃贡献者」。还有一些人可能是想通过开源贡献来丰富简历，但又不想花时间真正理解项目。
不管动机是什么，结果都一样：维护者被淹没了。
我之前在一个 Discord 群里看到有人分享「如何用 AI 快速给开源项目贡献代码」的教程，步骤大概是：fork 仓库 -> 用 Claude Code 扫描代码 -> 找到所有 lint warning -> 自动生成修复 -> 批量提交 PR。听起来挺高效的是不是？但问题是，lint warning 之所以是 warning 而不是 error，就是因为它们不一定需要修复。有些是有意为之的设计选择。Agent 不知道这些，它只会机械地修复所有 warning。
更有意思的是，这种批量提交 PR 的行为在 GitHub 上形成了一种新的「内卷」。当有人发现可以用 AI 快速刷 PR 数量的时候，其他人也会跟风 —— 不然自己的贡献就会被淹没在噪声里。这就形成了恶性循环：PR 越来越多，质量越来越低，维护者越来越疲惫，项目越来越难维护。
我在 GitHub 上观察了几个热门项目，发现一个有趣的现象：有些项目的 PR 列表里，前 10 个 PR 的标题格式几乎一模一样 —— 都是 Agent 生成的那种标准格式（「feat(module): add feature X」「fix(component): resolve issue Y」）。如果你把这些 PR 的描述遮住，你根本分不清是谁提交的。这种同质化程度，在一年前是不可想象的。
所有人都在用同一个 AI，所以所有 PR 都长得一样
这个发现让我印象最深。
Linus Torvalds 有句名言：「足够多的眼睛，就能发现所有 bug。」这是开源的核心优势 —— 不同的人用不同的方式思考，能从不同角度发现问题。
但当所有人都用 Claude、Codex、Cursor 这些工具的时候，这个优势就被削弱了。Greptile 在 OpenClaw 数据里发现了一些让人哭笑不得的例子：
- 有 4 个不同的人提交了标题完全一样的 PR：「feat(web-search): add SearXNG as a search provider」。总共 10 多个人独立尝试添加同一个功能。
- 有 6 个人独立修复了同一个 Brave Search 的 locale bug。其中 2 个人提交的 PR 标题一模一样，时间间隔 94 分钟。
- 有 5 个人独立发现了 agent runner 里同一个超时死锁问题。
你想想这画面：10 多个人各自打开 Claude Code，对着同一个仓库说「帮我加个 SearXNG 搜索支持」，然后 Claude 们不约而同地给出了几乎相同的实现方案。
这不叫「足够多的眼睛」，这叫「同一个脑子复制了 10 份」。
开源的多样性优势，在 AI Agent 时代正在被稀释。大家都用同一个模型、同一个提示词模板，产出自然趋同。就像全班同学都抄同一个人的作业，交上去看起来都差不多。
这个问题其实有个专业术语叫「model monoculture」（模型单一文化）。农业领域有个概念叫「单一作物风险」—— 如果一个地区的农民都种同一个品种的水稻，一旦爆发针对这个品种的病虫害，整个地区颗粒无收。软件开发也是一样：如果所有人都用同一个模型的「思维模式」来写代码，那这个模型固有的盲区就会变成整个代码库的盲区。
举个具体的例子。Claude 系列模型在处理并发问题时有个倾向 —— 它喜欢用 mutex（互斥锁），不太擅长用 channel 或者 actor 模式。这不是说 mutex 不好，而是说如果所有贡献者都用 Claude 来写并发代码，整个项目的并发模型就会趋向单一。有些场景用 channel 更合适，但 Agent 不会主动选择 —— 它只会用它最「熟悉」的方式。
不同模型之间其实有差异。Claude 倾向于写防御性代码（大量 try-catch、null check），GPT-4 倾向于写更简洁的代码（信任调用方），Gemini 倾向于使用最新的语言特性。如果一个开源项目的贡献者来自不同模型，代码风格的多样性反而能覆盖更多边界情况。但如果大家都用同一个模型……你懂的。
这个问题其实比表面上看起来更深层。开源项目之所以强大，不只是因为「多人协作」，而是因为「多种思维方式的碰撞」。不同背景的开发者会从不同角度看问题：前端开发者关注用户体验，后端开发者关注性能和可靠性，安全工程师关注攻击面。这种多样性是 bug 被发现的前提。
但 AI Agent 没有「背景」。它不会因为之前踩过某个坑而对类似问题特别敏感，也不会因为某个技术栈的经验而有不同的代码风格。它的输出本质上是训练数据的统计平均 —— 最「安全」、最「常见」的写法。当所有人都用同一个 Agent 的时候，代码库的多样性就在慢慢流失。
有个开源维护者在 Twitter 上说了一句话我觉得很精辟：「以前我担心贡献者不够多，现在我担心贡献者都一样。」
我之前在用 Claude Code 的时候也有类似的体验。有一次我让它帮我重构一个模块的错误处理逻辑，它给出的方案是把所有 error 都 wrap 成自定义类型。我看了觉得挺合理，就照着改了。后来 review 别人的 PR，发现他用 Claude Code 改同一个模块，给出的方案几乎一模一样 —— 连变量命名都差不多。
这说明什么？说明 Claude 对「好的错误处理」有一个固定的理解模式。这个模式不一定错，但它缺乏多样性。如果 10 个人都用 Claude 来改同一段代码，你会得到 10 份几乎一样的改动。这在开源项目里是个问题 —— 你希望看到 10 种不同的思路，而不是 10 份相同的方案。
什么样的 PR 能被合并？
数据里最有价值的一个发现：重构类 PR 的合并率是功能类 PR 的近 4 倍。
- 功能类 PR：合并率约 9%
- 重构类 PR：合并率约 35%
为什么？因为重构需要你真正理解现有代码库的架构、依赖关系和设计意图。你得知道为什么要这么写，才能安全地改。而 AI Agent 目前最不擅长的就是这个 —— 它能写新代码，但不太能理解已有代码的「为什么」。
Greptile 举了个例子：claude-mem 这个项目把 Claude Code 的 hook 工具流映射成可恢复的 Agent SDK observer session，这个架构决策需要同时深入理解两个系统。一个真正理解这个决策的开发者，能把这个理解转化成精确的提示词，让 Agent 的输出质量大幅提升。但如果你只是跟 Agent 说「帮我建个记忆系统」，它做不到这个。
这让我想到一个比喻：200 年前，设计建筑的人和建造建筑的人是同一批人，叫「master builder」。后来随着建筑技术发展，这个角色分裂成了「建筑师」和「施工队」。软件行业可能也在经历类似的过程 —— 真正有价值的不再是「写代码」，而是「理解系统并做出正确决策」。
这个数据对我自己也有启发。我平时用 AI 编程工具，大部分时间花在让它写新功能上。但数据显示，用 Agent 帮你做重构、清理技术债、优化现有代码，可能才是更高效的应用场景。因为重构本身需要对代码库的深度理解，而这份理解来自于你 —— Agent 只是帮你执行。
Mitchell Hashimoto 的 Vouch 系统
面对 AI 生成的 PR 垃圾邮件，开源社区开始想办法了。
Mitchell Hashimoto（HashiCorp 创始人，现在在做 Ghostty 终端模拟器）被 AI 生成的 PR 搞得受不了，先是限制了 AI 生成的贡献，然后开发了一个叫 Vouch 的信任管理系统。
Vouch 的逻辑很简单：没有被 vouch（担保）的用户不能贡献代码，有不良记录的用户会被明确标记。这本质上就是开源世界的「发件人信誉评分」。
Mitchell 的愿景是让信任决策跨项目传播 —— 如果你在一个项目里被标记为 spammer，其他项目也能看到。这跟邮件系统的黑名单机制如出一辙。
不过有意思的是，Vouch 在 Ghostty 上运行得不错，但 Mitchell 后来还是决定把 Ghostty 从 GitHub 搬走了。具体原因比较复杂，但 AI PR 垃圾邮件肯定是其中一个因素。
我觉得 Vouch 这个方向是对的，但也有局限性。它本质上是在「人」的层面做筛选 —— 判断某个贡献者是否可信。但 AI PR 垃圾邮件的问题不只是「人不可信」，还有「代码质量不可控」。一个信誉很好的开发者，如果直接把 Agent 的输出当 PR 提交，照样可能提交低质量代码。
所以可能还需要在「代码」层面做筛选 —— 用 AI 来审查 AI 生成的 PR，识别那些模式化的、缺乏深度思考的改动。Greptile 本身就在做这件事。
我查了一下，目前市面上已经有一些工具在尝试解决这个问题。比如 CodeRabbit 和 PR-Agent 这类 AI PR 审查工具，它们可以自动分析 PR 的质量、检测模式化的改动、甚至判断代码是否「看起来像 AI 写的」。不过说实话，这些工具目前还比较初级 —— 毕竟用 AI 检测 AI 本身就是个难题，就像用魔法打败魔法一样不靠谱。
更靠谱的可能是 GitHub 自己出手。GitHub 作为平台方，有最完整的数据 —— 谁提交了多少 PR、合并率多少、贡献模式是什么样的。如果 GitHub 能基于这些数据建立贡献者信誉系统，效果会比任何第三方工具都好。不过 GitHub 目前还没有这方面的动作，可能他们还在观察这个趋势会发展到什么程度。
不只是 OpenClaw 的问题
你可能觉得这只是 OpenClaw 的问题 —— 谁让它那么火呢？但实际上，几乎所有热门开源项目都在经历类似的事情。
GitHub 上 star 数超过 1 万的项目，几乎都收到过 AI 生成的 PR。区别只在于程度 —— 越火的项目，收到的越多。
我跟几个维护开源项目的朋友聊过，他们的感受很一致：最近半年，PR 数量明显增加，但质量明显下降。很多 PR 的特点是：
- 代码风格高度一致（因为都是同一个模型生成的）
- commit message 写得很规范（AI 擅长这个）
- 但改动逻辑经不起推敲
- 缺乏对项目历史和设计决策的理解
有个朋友说了一句很扎心的话：「以前收到 PR，我先看代码质量。现在收到 PR，我先看是不是 AI 写的。」
这种情况如果持续下去，对开源生态的伤害是很大的。维护者本来就缺时间，现在还要花更多精力去筛选低质量 PR。有些人可能直接放弃维护 —— 这对整个社区都是损失。
对我们普通开发者意味着什么
说了这么多宏观的东西，回到个人层面，这件事对我们有什么影响？
第一，如果你在用 AI 编程工具给开源项目贡献代码，请认真 review。 不要直接把 Agent 的输出当 PR 提交。我知道这很诱人 —— Agent 写好了代码、自动创建了分支、甚至帮你写好了 PR 描述，你只需要点一下「Create PR」。但这样提交的 PR 大概率会被拒，而且会降低你在项目中的信誉。
第二，AI 编程工具最大的价值不在「写新功能」，而在「理解现有代码」。 数据已经证明了，重构类贡献的成功率远高于功能类。用 Agent 帮你理解一个复杂代码库、找到技术债、规划重构路径，比让它直接写新功能更有价值。
第三，开源贡献的门槛在变高，不是变低。 听起来反直觉 —— AI 工具不是应该降低门槛吗？是的，它降低了「提交 PR」的门槛，但提高了「提交有价值的 PR」的门槛。当维护者面对 3400 个 PR 的时候，他们只会关注那些真正有深度的贡献。泛泛的功能添加会被淹没在噪声里。
第四，提示词工程在开源贡献中变得很重要。 同样是用 Claude Code，一个理解代码库架构的人写出的提示词，和一个不了解上下文的人写出的提示词，产出质量天差地别。这又回到了前面说的 —— 思考比打字重要。
怎么用 AI 工具写出高质量的开源 PR
既然问题存在，那有没有好的实践？根据我自己的经验和这次数据的启示，总结几条：
先花时间读懂代码库，再让 Agent 动手。 不要上来就让 Agent 「帮我找可以改进的地方」。先自己花几个小时读代码、看 issue、理解项目的设计哲学。然后带着你的理解去提示 Agent，产出质量会好很多。
让 Agent 帮你做重构，而不是写新功能。 数据已经说了，重构的合并率是功能的 4 倍。用 Agent 帮你清理技术债、改善代码结构、补充测试，这些比让它写新 feature 更容易被接受。
不要批量提交。 一天 106 个 PR 明显是 bot 行为。就算你的 PR 质量不错，维护者看到你短时间内提交一堆 PR，第一反应也是「这人是不是在刷」。控制节奏，每次提交 1-2 个高质量 PR。
在 PR 描述里说明你的思考过程。 不要只写「Added feature X」。写清楚你为什么选择这个方案、考虑过哪些替代方案、有什么局限性。这能让维护者知道你真正理解了这个改动，而不是让 Agent 随便生成了一个方案。
尊重项目的方向。 有些 PR 虽然技术上没问题，但跟项目的发展方向不一致。Agent 不会考虑这个 —— 它只看代码。你得自己判断这个改动是否符合项目的 roadmap。
先在 issue 里讨论。 这是最简单但最容易被忽略的一步。在提交 PR 之前，先开一个 issue 描述你打算做什么、为什么要做、打算怎么做。维护者的回复能帮你判断这个改动是否被需要。如果维护者说「我们已经有计划做这个了」或者「这不是我们想要的方向」，你就不用浪费时间写代码了。
写好 commit message。 Agent 生成的 commit message 通常很规范（「feat: add SearXNG search provider」），但也通常很模板化。如果你能在 commit message 里写清楚「为什么」而不只是「是什么」，维护者会更愿意花时间 review。
测试、测试、测试。 Agent 生成的代码通常能通过它自己写的测试 —— 因为测试和代码是同一个「脑子」写的，盲区也一样。如果可能的话，自己写几个 edge case 的测试，或者用不同的方式验证 Agent 的改动。
保持小而精。 一个 50 行的 focused PR 比一个 500 行的「refactor everything」PR 更容易被接受。Agent 倾向于做大幅度改动（因为它不怕冲突），但维护者更喜欢小步迭代。
我自己的踩坑经历
说到 AI 生成 PR，我自己也踩过坑。
之前用 Claude Code 帮我给一个项目修 bug，Agent 很快就给出了修复方案，代码看着也挺合理。我差点就直接提 PR 了，但多看了一眼 diff，发现它改了一个不该改的默认值。这个默认值看着像 bug，但实际上是设计如此，文档里有说明。
如果我直接提交了，维护者大概率会拒掉，而且会觉得我不靠谱。这种「看起来对但实际上错」的 PR，比明显的垃圾 PR 更烦人 —— 维护者得花时间 review，最后发现是白费功夫。
还有一次更搞笑。我让 Claude Code 帮我给一个 Python 库加个新功能，它很积极地写了一堆代码，包括 tests、docs、甚至 changelog 条目。我一看，挺专业的嘛。结果提交之后，维护者回复说：「这个功能我们已经在 v2.0 里实现了，你用的是 v1.x 的分支。」
Agent 根本没注意到我在错误的分支上开发。它只看当前目录的代码，不会主动去检查项目是否有更新的版本。这种上下文缺失的问题，只有人才能发现。
所以现在我的习惯是：Agent 写完代码之后，我至少要花同样的时间去理解它改了什么、为什么这么改、有没有副作用。这个 review 过程不能省。
企业内部也面临同样的问题
你可能觉得 PR 垃圾邮件只是开源社区的事，跟企业内部开发没关系。但实际上，同样的问题在企业内部也在发生，只是表现形式不同。
在企业里，AI 生成的代码不会以 PR 垃圾邮件的形式出现，但会以「低质量代码审查」的形式出现。当一个团队里 80% 的人都在用 AI 编程工具的时候，代码审查就变成了一个尴尬的局面：审查者用 AI 审查 AI 生成的代码，提交者用 AI 修改 AI 审查提出的问题。整个流程看起来很高效，但实际上可能没有人真正理解这些代码在做什么。
我认识一个技术 leader，他最近在团队里做了一个实验：让两个团队分别完成同一个功能，一个团队完全用 AI 编程工具，另一个团队不用。结果发现，AI 团队的代码量是手动团队的 3 倍 —— 不是因为功能更复杂，而是 AI 生成了大量冗余代码：重复的工具函数、不必要的抽象层、过度工程化的设计模式。
更麻烦的是，这些冗余代码是「正确的」—— 它能跑、能过测试、代码风格也没问题。但它增加了代码库的复杂度，让后续维护变得更难。这就是所谓的「AI 代码膨胀」—— 代码量在增长，但有效信息密度在下降。
所以不管是在开源还是企业环境，核心问题都是一样的：AI 工具降低了写代码的成本，但没有降低理解代码的成本。如果你跳过了理解这一步，代码量再大也没用。
AI 编程工具厂商该怎么做
这个问题不只是开源社区需要解决的，AI 编程工具的厂商也有责任。
目前主流的 AI 编程工具（Claude Code、Cursor、Copilot、Codex）在设计上都鼓励「快速产出」—— 给你代码、帮你 commit、甚至帮你创建 PR。整个流程越顺畅越好。但这种设计哲学在开源贡献场景下是有问题的。
我觉得工具厂商可以做几件事：
加一个「思考提示」。 当 Agent 检测到你在给一个不是你自己的仓库提交代码时，弹一个提示：「你确定你理解了这个项目的架构和设计决策吗？」不是阻止你提交，而是提醒你停下来想想。
限制自动 PR 的频率。 一天 106 个 PR 明显是异常行为。工具可以加个限制，比如每小时最多创建 3 个 PR，或者在创建第 5 个 PR 时要求用户确认。
在 PR 描述里标注 AI 生成。 有些工具已经在做了，但还不够普遍。如果 PR 明显是 AI 生成的，应该在描述里标注，让维护者知道。这不是歧视 —— 而是给维护者更多信息来做判断。
鼓励多样化的提示词。 工具可以检测到用户是否在使用过于通用的提示词（比如「find and fix bugs」），然后建议更具体的引导：「这个项目的错误处理风格是 X，你想用什么方式改进？」
不过说实话，我不太指望工具厂商会主动做这些事。限制用户使用频率、增加使用摩擦，这些都跟他们的商业目标相悖。他们更可能走的路线是：让 Agent 更智能，能更好地理解代码库上下文，从而产出更高质量的代码。这当然也是对的，但可能需要时间。
几个常见误区
写到这里，我觉得有必要澄清几个我看到的常见误解。
误区一：「AI 生成的 PR 都是垃圾」。 不是的。AI 生成的代码可以很好，前提是使用者知道自己在做什么。数据也证明了这一点 —— 重构类 PR 的合并率有 35%，说明 AI 辅助的代码改动完全可以达到高质量。问题不在工具，在使用方式。
误区二：「开源项目应该禁止 AI 生成的 PR」。 这太极端了。有些项目确实这么做了（比如 Ghostty），但这会误伤很多认真使用 AI 工具的贡献者。更好的做法是提高审查标准，而不是一刀切禁止。
误区三：「这只是大项目的问题」。 不是。小项目收到的 AI PR 可能更麻烦 —— 因为小项目通常只有 1-2 个维护者，精力更有限。一个 500 star 的项目收到 20 个 AI 生成的 PR，维护者可能要花一整天来 review，最后只 merge 了 2 个。
误区四：「AI 编程工具会让开源贡献变得更容易」。 它让「写代码」更容易了，但让「贡献有价值的代码」反而更难了。因为维护者的期望值在提高 —— 当他们知道你有 AI 工具辅助的时候，他们会期望你的 PR 质量更高。以前一个简单的 typo fix 可能会被接受，现在维护者会想「你为什么不顺便让 AI 做个全面的 review？」
误区五：「这只是暂时的问题，等模型更强了就好了」。 这个我持保留意见。模型确实会越来越强，但「更强的模型」可能意味着更多人使用 AI 工具，意味着更多的 PR，意味着更严重的噪声问题。技术进步不会自动解决社会问题 —— 垃圾邮件技术在进步，反垃圾邮件技术也在进步，这场博弈已经持续了 25 年了。
开源的未来会怎样
Greptile 的文章最后说了一句话我觉得很到位：开源社区以前解决过比这更难的问题。
确实。从 Linux 内核的代码审查流程，到 GitHub 的 fork/pull 模型，开源社区一直在进化。PR 垃圾邮件是一个新问题，但不是无解的问题。
可能的解决方向：
- 信誉系统：像 Vouch 这样的跨项目信任网络，让贡献者的历史记录可追溯
- AI 辅助 PR 审查：用 AI 来审查 AI 生成的 PR，识别低质量贡献（Greptile 本身就在做这个）
- 贡献者分级：新贡献者的 PR 自动进入更严格的审查流程
- 提示词多样性：项目文档中加入「贡献指南」，引导贡献者用不同的方式思考问题。比如在 CONTRIBUTING.md 里写清楚项目的架构决策、设计哲学、以及「我们不接受的改动类型」。这样即使用 Agent，产出也会更有针对性
- 分支权限收紧：限制新用户的 PR 频率，或者要求先在 issue 里讨论方案再提交代码。有些项目已经在这么做了 —— 你必须先在 issue 里描述你的方案，得到维护者的认可之后才能提交 PR
- PR 模板和检查清单：在 PR 模板里加入必填项，比如「你测试了哪些场景？」「你考虑过哪些替代方案？」「这个改动对现有用户有什么影响？」。这些问题是 Agent 不会主动回答的，必须由人来填写
- 自动化质量检测：用 linter、type checker、test coverage 这些工具做第一道筛选。AI 生成的代码通常能通过这些检查，但至少能过滤掉最粗糙的 PR
不过说到底，工具只是工具。AI 编程 Agent 能帮我们更快地写代码，但不能替我们思考。开源的核心价值 —— 多样性、协作、对代码质量的追求 —— 这些东西不会因为 AI 的出现而改变，只是实现方式需要调整。
就像邮件垃圾邮件没有杀死电子邮件一样，PR 垃圾邮件也不会杀死开源。但它确实改变了游戏规则。以前你提个 PR，维护者会认真看。现在维护者面对 3400 个 PR，只能先筛掉 90% 的噪声，再看剩下的 10%。
你想成为那 10% 吗？那就别让 Agent 替你思考。
说个有意思的事。Greptile 的数据显示，OpenClaw 上那些被合并的 PR，大部分来自贡献过 5 次以上的老用户。他们的合并率是 18.6%，是新用户（8.2%）的两倍多。这说明维护者确实在用「信誉」来筛选 —— 你之前提交过高质量代码，这次我也更愿意信任你。
这对新手来说可能不太公平 —— 他们还没来得及建立信誉，就要面对 90% 的拒绝率。但这就是现实：在 AI 时代，「证明你不是 bot」变成了开源贡献的第一道门槛。
下次你用 Claude Code 写完代码准备提 PR 的时候，多问自己一句：这个 PR 如果是别人提交的，我会 merge 吗？