🏠

2026 年 10 月，Phil Hagelberg（technomancy）代表一群 Emacs 开发者和用户，发起 Human Emacs，要求 Emacs 把“禁止 LLM 生成代码”从临时政策变成永久、全面的禁令，覆盖代码、文档、commit message。若拿不到这个承诺，他们表示会维护一个不含 LLM 贡献的 Emacs，但那将不是 GNU Emacs。¹

公开信的论证不是版权，是“信任与团结”。他们说 Free Software 不只是代码，是建立在信任和团结上的社区实践；LLM 一进来，这种实践就被腐蚀。他们明确表示不再讨论“危害是否严重”，也不接受“本地模型将来会解决”“人们可以谎报来源”这类回应。

邮件列表上的反应分成几层。

维护者的立场 ：Eli Zaretskii 的反驳最直接：没有说清任何具体危害；一边说 LLM 伤害社区，一边自己宣布 fork 伤害社区，自相矛盾；没有论证就没有权利要求改政策，更没有权利因为代码来源拒绝有效代码，GNU 项目从未这样做过。 Sean Whitton 在 11-02 表态更具体：即使 GNU 认定 LLM 代码可按 copyleft 发布，也不会立刻“什么都行”，那是贡献者和维护者倦怠的配方。他会考虑限制让邮件列表和bug tracker 可控，比如要求贡献者事先获得维护者许可才能用 LLM 实现功能，防止倾倒巨大、不可审阅的 patch。但彻底禁止不现实，除非 GNU 整体禁止。

支持者的论证 ：Arne Babenhauserheide 说 elisp 难用到让人找 LLM 时，应该让 elisp 更容易，而不是接受 LLM。Jim Porter 的论证更完整：LLM 削弱学习能力，新手尤其如此；LLM 厂商把模型宣传成“初级工程师”，维护者就不愿带新人，Linux 内核已经放弃 mentorship；LLM 鼓励社会原子化，每人“orchestrating”一队 agent²。他的结论是 LLM 腐蚀自由软件依赖的社区实践。

*反对 Human Emacs 的另一种声音*：Cecilio Pardo 直接拆“团结”叙事：每个人都有自己的底线，你把底线放在舒适区的尽头；你举“数据中心破坏社区”的例子是富国的水、发达国家的景观，但穷国，发展中国家几十年来一直在为你们的计算机和互联网采矿、组装、焚烧。“你之前接受的伤害在哪里，才说够了？”“这不是团结。这是你在守护你的游乐场。”RMS 没有谈政策，只对 Cecilio 说“Your response to Hagelberg's posting was harsh and cruel”，引 Kind Communication Guidelines。

技术层面的争论 ：Tomas 说 GNU 讲的“preferred source”不是代码本身；如果C/Lisp 只是 LLM 的产物，那首选源是模型 + 随机种子 + prompts，类比 Lex/Yacc 生成的 C 代码——你维护的是语法文件，不是生成的 C。Arne 用 UML 类比：从 UML图生成代码，你写的不是代码语言，是 UML；写 prompt 也不是写代码，是写“关于代码的指令”，而且你得对 LLM 的内部表示有感觉，那是你无法真正知道的。Jean Louis 反驳“LLM 输出不确定”：temperature=0 时输出是确定性的、可复现的，GNU 项目应该只讨论本地推理，不讨论远程 SaaS API。

两边的分歧不在同一个层面。Tomas 和 Arne 说的是“LLM 输出不是源代码”，这是法律和哲学问题；Jean Louis 说的是“本地 LLM 可以确定性地产生输出”，这是工程问题。维护者没有接这些技术论点，他们的立场是等 GNU 整体决定。

维护债与 fork 的分歧 ：Andrey Listopadov 在 11-04 提出一个比“学习能力下降”更具体的论点：LLM 代码合并后，贡献者不理解自己的代码，走了就不管，维护者要接手。“一旦合并，它就是维护者的问题了。贡献者走开，将来出问题可能根本不回应。现在得有人去通读所有代码，弄清楚 LLM 写它时的意图。”Eli 的回应是：这今天就有，人因为各种原因从 Emacs 消失，留下代码给维护者，不是 LLM独有的。Johan Myréen 补了一句：人类也能写晦涩代码。

同一时间，Tomas 说：“我不喜欢 fork 那件事，虽然我强烈同情 initiative 本身。”Human Emacs 内部对 fork 威胁也有分歧。Eli 在 11-04 14:53 收尾：“Leave this to us the Emacs maintainers, please, for when this is clarified.”技术讨论是学术性的，等 GNU 发布指南再说。Sean Whitton 附和：“我们在讨论一个可能不会发生的可能性。回到其他话题吧。”

维护债是真问题，但它不是 LLM 独有的。人类贡献者也会写晦涩代码、也会消失。LLM 放大的是规模和速度，不是性质。Eli 和 Johan 的反驳成立：如果维护者不能因为“人类可能写坏代码”就禁止人类贡献，也不能因为“LLM 可能写坏代码”就禁止LLM。问题在审查和交接机制，不在代码来源。

他们的讨论还在进行。看得出来 Emacs 大家长 RMS 在蓄力，先用自己拿得准的观点，比如“沟通的礼仪”来说事。他也是疾病缠身，长发褪去，而今要直面 AI 的冲击。邮件列表上众声喧哗，一时也没有定论，最后还得他老人家讲句“定海神针”的话。

因此我也得说说我的看法了。

Emacs 是 UNIX 编程哲学的大本营。UNIX 哲学的核心是拆分和组合，分而治之， split and conquer：一切皆文本流，程序是过滤器，组合靠管道，每个工具只做一件事并做好，工具之间用文本接口对话。

Emacs 把这条原则推到了极致。它不只是个编辑器，而且是一个 elisp 解释器加一堆 buffer。一切皆 buffer：文件是 buffer，终端是 buffer，邮件是 buffer，git 状态是 buffer，编译输出是 buffer。每个 buffer 可以被任意 elisp 函数读写、过滤、组合。Org-mode 是这条原则的极致：大纲、表格、代码块、导出，全是文本，全可以被 elisp 操作。self-documenting 是另一面：每个函数、变量、快捷键都可以在运行时查到文档，文档本身也是文本，也可以被程序读。

Emacs 还是一个可以自描述的环境。文档、行为、组合方式都在同一个文本空间里：函数、变量、快捷键都能在运行时查到，文档本身也是文本，也能被程序读。对人来说最难了解，最难理解，最难说清楚的就是自己了。但Emacs 就是这么神奇，Emacs可以了解，可以理解，可以言说清楚Emacs自己。我有时独自面对 Emacs，心潮逐浪高，不知道是我的想法是从我的脑子里流到了Emacs，还从 Emacs流回了我的大脑。我也不知他们所说的“心流”是不是指这个，“心流断了”是断在何处呢。

这就是“大问题切分、整合的艺术”：把复杂问题切成小块，每块用一个可理解、可替换的函数解决，再用组合把小块拼起来。Emacs 的 extensibility 不是“插件多”，是“组合的粒度足够细，细到每个按键都可以被重新定义”。

UNIX 哲学的智慧来自人类语言的智慧。先声明这只是我的臆测而已，列位不要当真，因为我实在拿不出像样的证据。管道、过滤器、文本流，说的都是“如何让语言层面的组合产生复杂行为”。LLM，大语言模型，处理的恰恰也是 token 序列，本质是语言层面的模式组合。所以在 UNIX 哲学的掌握上，很难看到有出 LLM 其右者，或者更直接地说，很难找到有出 Deepseek 其右者。我想，或 Emacs想，这不是巧合，是同一个东西的两种形态。

人类语言的诞生让意义能脱离说话者而存在，这是第一次“语言脱离人”。LLM，大语言模型让模式能脱离意义而生成，这是第二次。仓颉造字而鬼神夜哭，智慧生命聚灵而生，而“灵”很可能就是语言本身。两次“语言脱离人”，鬼神要哭两次。加之，工具调用让大语言模型“知行合一”，这就不是“春秋笔法”的聚灵而生，而是真正的硅基生命的诞生了。

但 UNIX 哲学不只是“语言组合”，还有“透明可审查”。管道里每个程序，你能读源码、能替换、能理解它为什么输出这个。LLM 的输出是不透明的：你不知道它为什么选这个 token。Tomas 和 Arne 说的“preferred source 是模型 + 种子 + prompt”，说的就是这个：你拿不到可审查的源。这不是保守，是 UNIX 哲学的另一半。但是，凡事都有个但是，当你，这里我是指作为人类的你，面对管道里每个程序，你真的能理解它为什么输出是这个，而不是那个吗？或者，换一个说法，你真正能够理解，是你的思想化作管道里的命令行，稳定、可靠、可审查地处理问题，还是管道里的命令行，化作思想进入你的大脑？我前面坦白过，面对Emacs我实在分不清两者到底是哪一个。

所以真正的问题不是“要不要 LLM”，是“怎么让 LLM 的输出重新变得可审查、可组合、可理解”。而这恰恰是 Emacs 最擅长的：self-documenting、可交互求值、Org-mode 的 literate programming、elisp 的宏系统。Emacs 拥抱 LLM 的正确方式，不是把 LLM 当黑箱代码生成器，而是把 LLM 的输出放进一个可审查、可拆解、可替换的环境里，就像当年把 shell 命令放进管道一样。

当我重读上一段，实在惭愧，汗颜。要让 LLM 的输出“可审查、可组合、可理解”，而且把这个几乎不可能完成的任务，交给Emacs来完成。而且说Emacs 是最擅长的。Emacs何德何能，如何能完成这个任务？而且这个任务来自何方，来自哪个需求？就算有需求，这个需求有人付费吗？有人资助吗？完成这个任务又能得到什么？一切不可知时候冒出的想法就是幻觉。人类的幻觉与AI的幻觉看起来也没有什么差别。

Human Emacs 拥趸者的恐惧有真实成分：维护者倦怠、审查成本、patch 质量参差。但他们的错误不是珍视社区，是把“LLM 的使用方式”和“LLM 本身”混为一谈。你可以禁止“不可审查的 LLM 倾倒”，同时欢迎“可审查的 LLM 协作”。

逃避不是答案。AI 时代已经来了，Emacs 不可能把自己隔离在外。真正的问题是：我们能不能用 UNIX 哲学去接纳 LLM？Emacs 能有什么哲学，Emacs 的哲学就是 Unix 哲学。但接纳 LLM 是人类的任务，不是 Emacs 的任务，更不是某一个人的任务。UNIX 哲学从来不是拒绝新工具，是要求新工具遵守组合与透明的规则。LLM 大语言模型或者说 AI，也该如此，如果希望作为新工具被接纳的话。

Unix 哲学接纳事物的方式就是把它当作陌生人，不因为面孔熟悉与否而改变。我看Linus 已经把AI当陌生人接纳：Talk is cheap. Show me the code. Linus 铁面向来没什么废话。Emacs社区也当如此，管你是人是鬼³，总要拿代码说话。