诚实为何导致 Emacs 补丁被拒？

背景

Emacs 作为开源社区中最古老且最具影响力的文本编辑器之一，其核心维护者 GNU 项目近期对人工智能（AI）辅助代码提交的立场引发了争议。一位名为 Przemysław Alexander Kamiński 的开发者在 Hacker News 上发布了一篇长文，详细记录了他如何利用开源大语言模型（LLM）优化 macOS 上的 Emacs 性能，并因主动披露这一事实而导致补丁被拒的经历。

该事件不仅触及了开源社区对于 AI 工具使用的伦理边界，更引发了关于“透明度”、“版权法律风险”以及“开源精神”的深层讨论。作者通过这一具体案例，批评了 GNU 项目内部缺乏透明度的决策机制，并表达了对当前反 AI 辅助政策的不满，最终决定停止为 Emacs 贡献代码。

核心内容

作者首先回顾了过去几个月在 macOS 平台上优化 Emacs 性能的工作历程。在此期间，他不仅进行了性能分析和基准测试，还尝试让多个 LLM 分析代码库以寻找性能瓶颈。虽然大多数 LLM 生成的补丁效果不佳或误解了问题，但作者形成了一些关于 macOS 平台性能问题的核心观点：主要瓶颈在于渲染问题和内存抖动（memory thrashing），后者由 macOS malloc 实现方式导致的内存碎片化和缺乏内存压缩引起，进而造成虚拟内存膨胀和缓存局部性丢失。此外，正则表达式（regexp）处理也是核心性能痛点之一。

为了验证这些观点并寻找切实可行的修复方案，作者利用朋友提供的 z.ai Max 计划额度，运行了开源权重的 GLM 5.2 模型。他发现 GLM 5.2 在代码优化方面表现出色，于是让该模型针对 Emacs 代码库进行深度搜索和分析。经过约 3 小时的运行，GLM 5.2 生成了几份报告。作者对这些报告进行了严格的人工审查、修改、手动测试和基准测试，最终挑选出一个最有希望的补丁，并在撰写文章前两天提交到了 emacs-devel 邮件列表。

在提交补丁时，作者明确声明了以下几点：

1. 问题发现及补丁草稿由 GLM 5.2（一款具有开源权重的中国模型）生成。
2. 作者已对问题报告的准确性和影响进行了分析。
3. 作者已审查补丁并进行了修改。
4. 作者已手动测试了补丁。
5. 出于法律目的，作者声明自己是提交的作者，并准备好论证其贡献大于 LLM。
6. 作者声明对提交承担全部个人责任。

该补丁仅包含 92 行代码，且注释中包含了修改的理由（raison d'être），作者认为这并非低质量的“垃圾代码”（slop）。然而，第二天作者得知该补丁被拒绝，原因是 GNU 有一条政策禁止接受 LLM 辅助的工作成果。

作者对此表示尊重但不同意，并指出了该政策的逻辑矛盾：

• 惩罚诚实：如果承认使用 LLM 会导致被拒，那么鼓励开发者隐瞒这一事实。这惩罚的是诚信，而非 LLM 的使用本身。作者认为，正因为不信任 LLM 的自动输出，才更需要更多的人工审查，而不是更少。
• 关于“开放性”的荒谬论点：GNU 内部讨论认为，使用本地运行的开源权重模型（如 Qwen 3.6 或 GLM 5.2）是可以接受的，但通过 API（如 OpenRouter）调用则不行。作者反驳称，GLM 5.2 本身就是开源权重模型，如果硬件允许，完全可以在本地运行以规避“SaaS 封闭”的论点。这种区分标准在逻辑上是站不住脚的。
• 关于“合法性”的傲慢：作者认为 GNU 对版权法律的担忧是过度自信。尽管 GNU 自诩为自由软件捍卫者，但在法律意识上并不比其他大型组织更严谨。例如，游戏公司对 IP 保护极度敏感，但 LLM 的使用依然普遍；ChatGPT 拥有十亿活跃用户，无数商业和非商业组织每日使用 LLM 输出。作者引用美国版权局的观点指出，版权局不注册由自然、动物或植物创作的作品，也不注册由超自然存在创作的作品，但这并不意味着人类不能从这些“灵感”中创作受版权保护的作品。问题的关键在于是否将版权标记强加于作品，而非创作工具。
• 缺乏透明度：作者指出，该政策是在 GNU 内部邮件列表中讨论的，对外部用户缺乏透明度。这种不透明的决策过程与 Meta 内部决定 Facebook 方向的运作方式无异，不符合“开源”组织应有的开放精神。

最终，作者宣布将不再为 Emacs 贡献代码。他在本地硬盘上存有约 40 个性能改进补丁，其中部分已验证有效，但他因不满这种“拿着棍子却被告知拿法错误”的态度而选择退出，并计划转向更“开放”的项目。

关键要点

• 事件起因：开发者利用开源 LLM（GLM 5.2）辅助生成 Emacs 性能优化补丁，并在提交时主动、透明地披露了 AI 辅助事实。
• 拒绝理由：GNU 项目依据内部政策，拒绝接受任何 LLM 辅助的工作成果，无论其质量如何或是否经过人工严格审查。
• 作者的反驳逻辑：
  • 诚信悖论：政策惩罚了主动披露的行为，变相鼓励隐瞒，这与开源社区的诚信价值观相悖。
  • 标准不一：区分本地运行开源模型与通过 API 调用同一模型缺乏技术合理性，属于双重标准。
  • 法律误读：GNU 对版权风险的担忧被作者视为过度谨慎甚至傲慢，引用美国版权局观点指出 AI 辅助创作在法律上并非绝对禁区。
  • 程序正义缺失：关键政策在内部闭门讨论，缺乏对社区用户的透明度和问责机制。
• 最终结果：作者因不满 GNU 的决策机制和态度，宣布停止为 Emacs 贡献代码，并公开了其验证过的其他性能优化补丁。

意义与影响

这一事件是开源社区面对 AI 技术浪潮时的一个标志性冲突点。它揭示了传统开源维护者与新兴 AI 工具之间的张力，以及这种张力如何演变为对开源核心价值观（如透明度、自由、协作）的重新定义。

首先，它挑战了“开源”定义的边界。GNU 项目长期以来强调软件的自由和开放，但其对 AI 辅助的排斥似乎建立在一种封闭的内部决策之上。作者将这种不透明的内部讨论比作 Meta 的封闭决策，尖锐地指出了“伪开源”或“排他性开源”的风险。如果开源组织不能在其治理结构上保持开放，其对外倡导的开放价值观将失去说服力。

其次，它引发了关于 AI 辅助开发伦理的深入探讨。目前，开源社区对于 AI 的使用尚无统一标准。有的项目完全禁止，有的要求披露，有的则持开放态度。GNU 的“一刀切”政策虽然旨在规避潜在的法律和道德风险，但也可能阻碍技术创新和效率提升。作者提出的“诚实应被奖励而非惩罚”的观点，为建立更合理的 AI 使用规范提供了思路：即重点应放在代码质量、人工审查力度和贡献者的责任承担上，而非单纯禁止工具的使用。

最后，对开发者生态的影响。知名开发者的退出可能会引起其他贡献者的共鸣或反思。如果开源项目无法适应新的技术现实，或者其治理方式过于僵化，可能会导致人才流失。这一事件提醒所有开源维护者，在制定技术政策时，需要更加透明、包容，并与社区进行充分的沟通，以平衡创新、法律风险与社区价值观之间的关系。