我不是“反向半人马”：一位开源维护者对 LLM 贡献的抵制

背景

大约一年前，作者在个人博客上曾撰文阐述，即便不考虑伦理或环境方面的担忧，使用大型语言模型（LLM）进行编程对他而言也并不可行。当时他的观点是，LLM 生成的代码缺乏人类开发者那种对上下文、架构和长期维护性的深层理解。

然而，随着时间推移，虽然作者个人的立场未变，但他所维护的开源项目收到的贡献（Contributions）数量却显著上升。令人沮丧的是，这些新增的贡献几乎全部是由 LLM 生成的。这种变化迫使作者重新审视自己作为资深软件工程师和开源维护者的角色，并引发了他对“反向半人马”（Reverse Centaur）这一概念的深刻反思。

核心内容

“反向半人马”的困境

作者引用了作家 Cory Doctorow 提出的概念——“反向半人马”。Doctorow 将那些被无情、冷漠的机器操控，从事低价值重复劳动的人称为“脆弱且易受伤害的反向半人马”。

作者感到一种深深的压抑：随着大量由机器生成的代码涌入他的项目，他发现自己正被迫花费越来越多的时间进行代码审查和合并。这让他质疑：自己是否正在沦为一名“反向半人马”？即，尽管他自己拒绝使用 LLM 技术，却不得不日复一日地审查由 LLM 生成的代码，成为机器意志的执行者。作者明确表示，他绝不会成为这样的人，并分享了他抵抗这种趋势的具体策略。

拒绝未经请求的 Pull Request (PR)

在 LLM 普及之前，收到来自陌生开发者的未经请求的 Pull Request (PR) 曾是一件令人兴奋和自豪的事。这代表有人愿意投入时间和精力来改进项目，并与所有用户分享成果。

但在今天，未经请求的 PR 被视为一个红色警报。许多用户懒惰地提示 LLM 代码生成工具，要求修改开源项目的行为以满足其特定需求，却完全不关心这些更改的内容及其对其他用户的影响。虽然偶尔会有合理的改进，但大多数情况下，这些提交者只是贴上一段由 LLM 生成的冗长描述，便将 PR 发送过来，留下维护者去判断这些代码是真正的改进还是纯粹的垃圾（Slop）。

作者认为，自己的生活有更多重要的事情要做，而不是整天审查 LLM 生成的代码。因此，他确立了新的贡献准则：他期望贡献者是直接的、有真实兴趣改进项目的个人。

新的贡献指南与执行策略

为了筛选掉机器生成的垃圾，作者在所有开源项目的贡献指南中加入了严格的指令：

1. 先讨论，后提交：在提交 PR 之前，必须先通过 Issue 向维护者介绍拟议的更改。未经 Issue 讨论直接提交的 PR，维护者有权直接关闭。
2. 获批后工作：只有在维护者接受提议并允许工作后，才提交 PR。

这一流程确保了双方在投入大量时间之前，先建立联系并确认意向，实现双赢。

尽管有此规定，作者仍会收到未经请求的 PR。他开发了一套快速识别机制：在几秒内判断 PR 背后是否有真人参与。如果没有人类参与的证据（如缺乏具体的上下文讨论、格式僵化等），他会毫不犹豫地直接关闭 PR，不问原因。

作者承认，这种态度可能会让他错过一些有用的改进或 Bug 修复。但在充满“机器垃圾”的世界里，审查这些 PR 的工作性质已转变为“反向半人马”的工作，这并非他所愿。他只关注那些积极参与、有真人投入的贡献。

对于只能依靠 LLM 编码的用户，作者的建议是：不要浪费 Token 去提交 PR，因为会被忽略。相反，请用你自己的语言在 Issue 中描述问题。作者明确表示，他不想看到由 LLM 生成的包含章节、要点和表情符号的“小说”，只需要简单、真实的问题描述。为了节省 Token，用户甚至可以考虑捐赠，这可能会激励作者优先处理他们的问题。

开源的未来与代码的本质

作者不断自问：开源还重要吗？

他坦言，近年来他对分享自己创造的事物兴趣减退。虽然仍保持现有项目的更新，但许多新项目他不愿公开。他认为，人们对开源乃至编程本身的兴趣正在下降。

作者热爱编程的核心原因在于其挑战性。他推测，许多人愿意花钱给 AI 实验室，让机器吐出代码，即便代码质量参差不齐，也是因为他们渴望逃避这种挑战。

面对“是否有一天所有人都不再编码，仅由机器完成”的趋势，作者表示希望并非如此，但他必须抵制那种由机器及其亿万富翁所有者掌控一切的“反向半人马”未来。

社区互动解读

文章底部的评论进一步印证了作者立场的坚定与争议性：

• Magesajr 询问 LLM 是否能产生创造性思维，并询问关于 Flask Web 应用转移动应用及 PWA 离线数据库的技术细节。作者（Miguel Grinberg）回应称，自己不是讨论 LLM 能力边界的人，暗示这些技术问题与文章主旨无关或超出了当前讨论范围。
• Dan 赞赏作者的做法，认为它在允许人们使用 LLM 加速编码的同时，重新引入了人性和社会互动，实现了双赢。Dan 建议是否在贡献指南中加入能被 LLM 读取的指令，以阻止 LLM 在未经批准的情况下操作仓库。
• Miguel Grinberg（作者本人） 回复 Dan，指出对方可能没读懂文章：在他的开源仓库中，LLM 被完全禁止。他只接受真实人类的工作。

关键要点

• 拒绝机器垃圾：作者认为由 LLM 生成的未经深思熟虑的 PR 大多是低质量的“Slop”，审查它们是一种浪费时间的“反向半人马”劳动。
• 强制人工介入：通过强制要求“先 Issue 讨论，后提交 PR”的流程，确保每个贡献背后都有真实的人类意图和沟通。
• 快速过滤机制：作者利用几秒钟的时间判断 PR 背后是否有真人参与，若无证据则直接关闭，不浪费后续审查时间。
• 鼓励真实表达：作者要求用户用“自己的声音”描述问题，拒绝 LLM 生成的格式化、冗长的文本，并暗示捐赠可作为优先处理的激励。
• 维护者主权：作者强调作为维护者有权决定接受何种贡献，即使这意味着可能错过一些自动化的改进，也要保持代码库的人类主导性。
• 对开源未来的忧虑：作者观察到人们对编程挑战的兴趣减弱，担忧开源社区逐渐被自动化和资本驱动的 AI 生产模式所侵蚀。

意义与影响

这篇文章不仅是个人偏好的表达，更触及了 AI 时代开源社区的核心矛盾：效率与质量的博弈，以及人类主体性的丧失。

1. 重新定义“贡献”的价值：在 LLM 能够瞬间生成代码的背景下，作者强调“意图”和“沟通”比代码本身更重要。这提醒社区，开源不仅仅是代码的交换，更是社区互动、知识共享和协作精神的体现。
2. 维护者的防御策略：对于维护者而言，面对海量的自动化 PR，建立严格的过滤机制（如强制 Issue 前置）是保护自身精力和项目质量的必要手段。这也可能成为未来开源项目维护的新常态。
3. 人机协作的边界：文章揭示了当前 LLM 辅助编程的局限性——它擅长生成语法正确的代码，但缺乏对业务逻辑、用户影响和长期维护性的深刻理解。作者的观点促使开发者反思：何时该用 AI 加速，何时必须保留人类判断。
4. 伦理与劳动异化：通过引用“反向半人马”，作者将代码审查工作异化为一种被机器操控的奴役状态，引发了关于技术如何改变人类劳动性质、以及谁在从 AI 中获益（是开发者还是 AI 公司所有者）的深层伦理讨论。

总之，这是一篇关于在 AI 洪流中坚守人类开发者尊严与质量的宣言，也为开源维护者提供了一套实用的防御性实践指南。