我不是 Reverse Centaur：当 AI 生成的 PR 涌入开源项目

原文来源：I Am Not a Reverse Centaur — 一位开源维护者对 AI 生成的 Pull Request 浪潮的回应

如果你是一个流行的开源项目的维护者，最近你的 GitHub 收件箱大概也不好过。

上周，Miguel Grinberg——Flask 的核心贡献者、多本 Python Web 开发技术书的作者——发表了一篇题为 I Am Not a Reverse Centaur 的博文，迅速在 Hacker News 上获得了超过 250 个点赞。

他要说的主题很简单，但切中了无数开源维护者的痛点：越来越多的 Pull Request 来自 AI，而非人类。

什么是 Reverse Centaur

Grinberg 引用了 Cory Doctorow 提出的概念：Reverse Centaur（反向半人马）。在希腊神话中，半人马是上半身人、下半身马的生物。而"反向半人马"指的是人类变成了 AI 的提线木偶——AI 写代码，人类只是把它提交上去。

"Cory Doctorow 称那些执行这种功能的人为'reverse centaur'。他说这是'脆弱而脆弱的人类被冷漠无情的机器操控着'。"

这不是一个漂亮的比喻。它恰恰描述了当下很多人使用 AI 编程的方式：让 AI 生成代码，自己不做审查就直接提交 PR。

发生了什么

Grinberg 说他最近遇到了一个明显的变化：他维护的开源项目收到的 Pull Request 数量激增，而几乎所有这些 PR 都是 LLM 生成的。

这些 PR 有一些共同特征：

• 没有先前的讨论记录（不是在 issue 中先讨论过再来的）
• PR 描述用的是 AI 那种过于正式、结构化的语气
• 提交者没有和项目有任何历史互动
• 改动范围往往过大，或者解决了一个并不存在的问题

Grinberg 说他能做到一眼识别出 AI 生成的 PR。"如果我看不到人类参与的痕迹，那我就不感兴趣，PR 会直接关闭，不附带任何后续讨论。"

新政策：先讨论，再动手

为了应对这个趋势，Grinberg 在他的项目贡献指南中更新了一条政策：

如果你想为这个项目贡献代码，请先在 issue 中介绍你希望做的改动。没有经过 issue 讨论就直接提交的 Pull Request，维护者有权直接关闭。

一旦他在 issue 中同意你动手，你再提交 PR 也没问题。但前提是：你得证明你自己（而非 AI）完成了这个工作。

对于依赖 LLM 的用户，他的建议更直接：

"在 issue 中描述问题，让我来处理。我不想要 AI 生成的章节、要点列表和 emoji，只需要你用自己的话简要描述问题。"

如果你希望问题被优先处理，可以考虑捐赠。但不要浪费 token 来生成 PR，这些 PR 会被直接忽略。

维护者的两难

Grinberg 的做法在评论区引发了激烈的讨论。

有人质疑："你这样会不会错过一些好的贡献？毕竟 AI 生成的代码里也可能有高质量的改动。"

Grinberg 坦率地承认了这一点。但他强调，自己的时间是有限的，而且比"不错过任何可能的好 PR"更重要。 当 AI 生成的 PR 像潮水一样涌来时，他没有义务去充当那个甄别者。

也有评论者建议在贡献指南中加入 AI 可读的指令（比如 .cursorrules 或 ai-context.md），告诉 LLM 不要生成 PR。Grinberg 的回应很干脆：LLM 在他的仓库中是全面禁止的——只有真人的工作才被接受。 他不会去适配那些未经同意就在他的代码上训练的模型。

更深层的隐忧

这篇博文的最后一部分，Grinberg 表达了对开源生态更广泛的担忧。

"我的感觉是，人们对开源、乃至编程本身的兴趣都在下降。我热爱编程的主要原因是它有挑战性，而我认为这恰恰也是很多人宁愿花钱给 AI 实验室，让机器吐出代码的原因——即使冒着代码质量低下的风险。"

他承认自己仍然在为了工作和乐趣而编程，但已经不太愿意公开发布新的项目了。他害怕一个未来：只有机器在写代码，而人类变成了 reverse centaur——机器驱动的提线木偶。

他打算抵制这种趋势。继续手动写代码。

我的看法

Grinberg 的这篇博文之所以引起共鸣，是因为它触及了一个很多开发者隐隐感到不安但没说出口的问题。

AI 编程工具带来了效率提升，但也正在改变开源社区的基本社交契约。开源的本质是人与人之间的协作——你帮我 review 代码，我帮你在 issue 里讨论方案，我们共同改进这个项目。当一方变成了 AI 的中转站，这种协作就变成了单向的垃圾倾倒。

更值得思考的是：AI 生成的贡献是否在稀释开源项目的价值？

一个 PR 的价值不仅仅在于改了几行代码。它包含了贡献者对项目方向的理解、对代码库的熟悉程度、以及后续维护的承诺。AI 生成的代码改得很漂亮，但如果原作者不打算长期维护，这些改动最终会成为其他人的包袱。

我理解 Grinberg 的疲惫。维护开源项目本来就不是一份轻松的工作，而现在维护者们又多了一项新的工作：从 AI 生成的代码中甄别出真正有价值的贡献。

对开发者的建议

如果你正在使用 AI 编程工具，并且想为开源项目做贡献，这里有几点建议：

1. 保持人类参与。 不要直接提交 AI 生成的 PR。自己先理解代码、手动修改、添加测试。
2. 先讨论，后动手。 在 issue 中和维护者沟通你的想法，获得认可后再行动。
3. 诚实标注。 如果你使用了 AI 辅助，可以在 PR 描述中说明，并强调你已经审查过代码。
4. 考虑长期参与。 一个好的贡献者比一个好的 PR 更有价值。建立与项目的长期关系。

Grinberg 并非反对 AI 本身。他也提到，有些人 fork 了他的项目并用 LLM 修改后另起炉灶——这完全没问题。问题在于，当你要求别人花时间 review 你的代码时，请确保你付出了与之对等的努力。

这让我想起 Tom Bedor 的那篇文章《如果你在寻求人类的关注，请先展示人类的努力》。两篇文章发表时间仅隔一天，却形成了完美的呼应：AI 时代的协作礼仪，正在成为每个开发者需要重新学习的课题。