本文翻译自 Emacs and Vim in the Age of AI，原载于 Hacker News。作者 Bozhidar Batsov 是 Emacs 社区的资深贡献者，也是多个流行 Emacs 包的维护者。

预言未来是一件极其困难的事情，尤其是关于未来的预言。

—— Yogi Berra

我是一名拥有 20 多年经验的 Emacs 狂热用户。我构建和维护了一些最受欢迎的 Emacs 包，为 Emacs 本身贡献过代码，并花费了无数时间调整我的配置。Emacs 不仅仅是我的编辑器——它是我的激情所在，是我的精神家园。

在过去的一年里，我也花了很多时间使用 Vim 和 Neovim，从零开始重新学习它们，并乐在其中地对比两个社区如何解决相似的问题。这是一次有趣而新鲜的体验。

最近，像行业里的其他人一样，我也在尝试各种 AI 工具——特别是 Claude Code——观察 AI 对整个编程领域的影响，并思考这一切对编程的未来意味着什么。自然而然地，我不断回到同一个问题：在这个崭新的 AI 世界里，我心爱的 Emacs 和它的”宿敌” Vim 会面临什么？

我认为答案比”它们注定消亡”或”一切照旧”要微妙得多。预测未来显然是困难的，但推测未来是如此有趣。

我的逻辑是，每一次重大的行业转变都会给参与者带来大量的风险和机遇，所以我想花点时间思考一下 Emacs 和 Vim 面临的风险与机遇。

风险

IDE 的引力陷阱

VS Code 已经以绝对优势成为主导编辑器，而且它将获得所有主流 AI 工具的一流集成——Copilot（显而易见）、Codex、Claude、Gemini，应有尽有。微软有充分的动机让 VS Code 成为 AI 辅助开发的最佳宿主，而且他们拥有实现这一目标的资源。

此外，专门构建的 AI 编辑器如 Cursor、Windsurf 等正在吸引大量投资和人才。它们不是将 AI 作为事后补充添加到现有编辑器中——而是围绕 AI 工作流构建整个体验。它们提供集成的上下文管理、内联 diff、多文件编辑和智能体循环（agent loops），这些功能感觉是原生的，而非生硬附加的。

每一个转向这些工具的开发者，都是一个不学习 Emacs 或 Vim 键位绑定、不编写 Elisp、不为我们的生态系统做贡献的开发者。这种引力陷阱是真实存在的。

我从未尝试过 Cursor 和 Windsurf，因为它们本质上是 VS Code 的分支，而我无法忍受 VS Code。这些年来我尝试过几次，但由于各种原因，我在其中从未感到高效。

你还需要”专业工具”吗？

Emacs 和 Vim 的一部分价值主张一直是它们能让你更快地编写和编辑代码。键位绑定、宏、可扩展性——所有这些都是为了让人类在编码的机械行为中更加高效。

但如果 AI 正在编写你的大部分代码，机械编辑速度还有多重要？当你审查和引导 AI 生成的 diff，而不是逐字符输入代码时，瓶颈从”我能多快编辑”转移到了”我能多好地表达意图和评估输出”。这是一项根本不同的技能，而 Emacs 或 Vim 在这方面是否具有内在优势并不清楚。

学习曲线的论点也变得更难自圆其说。”花六个月学习 Emacs，你会快 10 倍”这种说法，在一个初级开发者用 Cursor 就能在一下午搭建整个应用的时代，很难有说服力。

企业支持的不对称

VS Code 背后有微软。Cursor 背后有风险投资。Emacs 背后有……一小群志愿者和 FSF。Vim 曾有 Bram，现在有一群维护者。Neovim 有一个小而专注的核心团队。

这种情况一直存在，但 AI 放大了这种差距。构建深度 AI 集成需要跟上快速发展的 API、模型和范式。资金充足的团队可以全职投入工程师做这件事。志愿者驱动的项目以人们业余时间和热情的节奏推进。

世界末日场景

让我们走到极端：如果在下一个十年内，我们所知的编程被完全自动化会怎样？如果 AI 智能体可以接受规范并生成经过测试、已部署的工作软件，无需人工干预，我们根本不需要编码编辑器。不是 Emacs，不是 Vim，不是 VS Code，不是 Cursor。整个类别都变得无关紧要。

我认为这在短期内不太可能，但值得承认这种可能性。AI 能力的轨迹甚至让乐观主义者都感到惊讶（我最初是一个 AI 怀疑论者，但去年的快速进步最终改变了我的想法）。

机遇

AI 让配置和扩展变得轻而易举

几乎没有人讨论的一点是：Emacs 和 Vim 一直受困于其扩展语言的晦涩难懂。Emacs Lisp 是一种 1980 年代的 Lisp 方言，大多数程序员从未见过。VimScript 嘛……就是 VimScript。即使是 Neovim 专门采用的 Lua（因为它更易接近），也足够小众，大多数开发者从未写过一行。

这一直是两个生态系统最大的瓶颈。不是编辑器本身——它们非常强大——而是定制它们需要学习一门陌生的语言，大多数人从未超越从博客文章和 README 复制代码片段的阶段。

当我第一次学习 Emacs 和 Vim 时，我对 Elisp 和 VimScript 感到非常不知所措，我想我不是唯一一个。只有在我投入了大量时间真正学好 Elisp 之后，我才开始在 Emacs 中感到高效。（但我从未对 VimScript 做同样的事，坦白说，我也不太渴望掌握 Lua。）

AI 一夜之间改变了这一切。你现在可以用简单的中文描述你想要的，然后获得可工作的 Elisp、VimScript 或 Lua。”给我写一个 Emacs 函数，将当前段落重新格式化为 72 列并添加前缀”——完成。”配置 lazy.nvim 用这些键位绑定设置 LSP”——完成。几十年来一直是采用最大障碍的扩展语言壁垒，突然降低了。

插件开发也是如此

在 Emacs 社区待了 20 多年后，我经常感觉一个相对较小的群体——大约 50 到 100 人——在推动大部分有意义的进展。同样的名字出现在 MELPA、邮件列表和 bug 报告中。这不是对那些人的批评（我很自豪自己是其中一员），但这是一个结构性的弱点。一个依赖如此少贡献者的社区是脆弱的。

而且不仅仅是 Elisp 和 VimScript。Emacs 和 Vim（以及 Neovim 的 C 核心）的 C 内部由更小的群体维护。找到既有意愿又有能力修改几十年历史的 C 代码库的人真的很困难，而且随着越来越少开发者学习 C，这只会变得更难。

AI 工具可以在两个方面提供帮助。首先，它们降低了新贡献者的门槛——理解他们想要构建的概念的人现在可以获得 AI 对用陌生语言实现的帮助。其次，它们帮助现有维护者更快地工作。我个人发现 AI 非常擅长生成测试脚手架、编写文档和处理拖慢一切的包维护中繁琐的部分。

AI 集成已经在发生

Emacs 和 Neovim 社区并没有坐以待毙。已经有令人印象深刻的 AI 集成：

Emacs:

• gptel – 一个多功能 LLM 客户端，支持多种后端（Claude、GPT、Gemini、本地模型）
• ellama – 通过 llama.cpp 和 Ollama 与 LLM 交互的 Emacs 接口
• aider.el – 流行的 AI 配对编程工具 Aider 的 Emacs 集成
• copilot.el – GitHub Copilot 集成（我恰好是当前的项目维护者）
• elysium – 带有内联 diff 应用的 AI 编程助手
• agent-shell – 通过 Agent Client Protocol 与 LLM 智能体（Claude Code、Gemini CLI 等）交互的原生 Emacs 缓冲区

Neovim:

• avante.nvim – Neovim 内部的 Cursor 风格 AI 编码体验
• codecompanion.nvim – 支持多个 LLM 提供商的 Copilot Chat 替代品
• copilot.lua – Neovim 的原生 Copilot 集成
• gp.nvim – Neovim 中的 ChatGPT 风格会话，支持多个提供商

这只是一个样本。构建这些集成并不像看起来那么难——API 很简单，两个编辑器的可扩展性意味着你可以用感觉原生的方式连接 AI 工具。有了 AI 辅助，创建新集成变得更加容易。我不会惊讶于插件开发的步伐显著加快。

终端原生 AI 工具是天然契合

有一个值得更多关注的讽刺：许多最强大的 AI 编码工具都是终端原生的。Claude Code、Aider 和各种 Copilot CLI 工具都在终端中运行。而什么在终端中？Emacs 和 Vim。

在 Emacs vterm 缓冲区或 Neovim 终端分割中运行 Claude Code 是完全自然的工作流。你在一个窗格中获得 AI 智能体，在另一个窗格中获得编辑器，保留所有键位绑定和工具。不需要切换到不同的应用程序——一切都在同一个环境中。

这实际上是一个相对于基于 GUI 的 AI 编辑器的优势，后者的 AI 集成与编辑器自己的界面紧密耦合。使用终端原生工具，你可以选择自己的编辑器和自己的 AI 工具，它们自然地组合在一起。

Emacs 作为 AI 集成平台

Emacs 的”编辑器即操作系统”哲学独特地适合 AI 集成。它不仅仅是一个代码编辑器——它是一个邮件客户端（Gnus、mu4e）、一个笔记系统（Org mode）、一个 Git 接口（Magit）、一个终端模拟器、一个文件管理器、一个 RSS 阅读器，以及更多。

AI 可以在所有这些层面进行集成。想象一个 AI 助手，它可以阅读你的 org-mode 议程，在 mu4e 中起草邮件回复，帮助你在 Magit 中编写提交消息，并在源代码缓冲区中重构代码——所有这些都在同一个环境中，共享上下文。没有其他编辑器架构能像 Emacs 那样使这种深度的跨领域集成如此自然。

诚然，我很早就停止将 Emacs 用作我的操作系统了，现在主要用它来编程和写博客。（我正在 Emacs 中写这篇文章，借助于 markdown-mode。）不过，我只是一个个例，许多用户可能以更全面的方式使用它。

AI 帮助你自助

AI 对 Emacs 和 Vim 用户最被低估的好处之一是平凡的：故障排除。两个编辑器都有以陡峭的学习曲线和晦涩的错误消息而闻名。”Wrong type argument: stringp, nil”驱使更多人放弃 Emacs，比任何竞争对手都要多。

AI 工具在解释晦涩的错误消息、诊断配置问题和建议修复方面非常出色。它们可以读取你的 init 文件并发现问题。它们可以解释一段 Elisp 的作用。它们可以帮助你理解为什么你的键位绑定不工作。这极大地降低了学习曲线——不是通过让编辑器更简单，而是通过给每个用户一个耐心的、知识渊博的向导。

我真的不需要任何 AI 辅助来解决我的 Emacs 设置中的问题，但在 Neovim 领域偶尔很有用，因为相比之下我的知识相对有限。

至少有一个记录在案的案例，有人在离开多年后专门因为 Claude Code 让修复配置问题变得无痛而回归 Emacs。他们因为配置负担太烦人而转向 IntelliJ——一旦 AI 消除了这个障碍就回来了。”真 tm 开心我又回家了，”他们是这么说的。如果 AI 能带回流失的 Emacs 用户，在我看来这是一件好事。

即使在编码末日之后，Emacs 和 Vim 也能存活

让我们重新审视末日场景。假设编程被完全自动化，没人再写代码了。Emacs 会消亡吗？

不一定。Emacs 已经被用于远超编程的领域。人们使用 Org mode 管理他们的整个生活——任务、笔记、日历、日志、时间追踪，甚至学术论文。Emacs 是一个能力强大的写作环境，对 LaTeX、Markdown、AsciiDoc 和纯文本有出色的支持。你可以阅读邮件、浏览网页、管理文件，当然，还可以玩俄罗斯方块。

Vim 类似地，既是一个文本编辑范式，也是一个程序。Vim 键位绑定已经占领了计算世界中每个文本输入——VS Code、IntelliJ、浏览器、shell，甚至 Emacs（通过 Evil mode）。即使 Vim 程序消退，Vim 的理念是不朽的。

谁知道呢——也许有一天会有人工手工艺软件的市场。”本地采购、自由放养的代码，由人类在 Emacs 中编写。”我会买那件 T 恤。而且我相当确定那些工匠程序员不会使用 VS Code。

所以即使在最极端的情况下，两个编辑器都有代码之外的生命。也许是缩减的生命，但仍然是生命。

更大的图景

我认为实际发生的事情比”编辑器消亡”或”编辑器没事”更有趣。编辑器的角色正在转变。

几十年来，编辑器是你编写代码的地方。越来越多地，它正在变成你审查、引导和细化 AI 编写的代码的地方。重要的技能正在从打字速度和编辑体操转移到规范清晰度、代码阅读和架构判断。

在这个世界里，获胜的编辑器不是代码补全最好的——而是给你最多工作流控制权的。而这一直是 Emacs 和 Vim 的核心价值主张。

问题是社区能否足够快地适应。工具在那里。架构在那里。理念是正确的。需要的是人——更多的贡献者、更多的插件作者、更多的文档编写者、更多对话中的声音。AI 可以帮助弥合差距，但它不能取代真正的社区参与。

伦理上的棘手问题

并非 Emacs 和 Vim 社区中的每个人都对 AI 充满热情，反对意见不仅仅是技术恐惧症。有一些正当的伦理关切将被长期讨论：

• 能源消耗。 训练和运行大型语言模型需要大量的计算和电力。对于长期以来重视效率和极简主义的社区——以运行 40 年历史编辑器为荣的 Emacs 用户，以亚秒级启动时间为傲的 Vim 用户——AI 的环境成本难以忽视。
• 版权和训练数据。 LLM 是在大量代码和文本语料库上训练的，这种训练的合法性和伦理仍有争议。一些开发者对使用可能从受版权保护代码中学习而未经明确同意的工具感到不安。这种关切对于深切关心许可的开源社区来说触及痛处。
• 工作取代。 如果 AI 让开发者效率显著提高，可能需要更少的开发者。这对任何编程社区来说都是一个不舒服的想法，对于以赋能人类程序员为核心身份的编辑器来说尤其尖锐。

这些关切已经产生了具体行动。Vim 社区最近出现了 EVi 的创建，这是 Vim 的一个分支，其存在的全部理由是提供一个不受 AI 辅助（生成的？）代码贡献影响的文本编辑器。无论你是否同意这个前提，人们因此分叉成熟编辑器这一事实告诉你一些社区成员对此感受有多强烈。

我不认为这些担忧应该阻止任何人探索 AI 工具，但它们是真实且值得认真对待的。我预计在未来几年里会在 emacs-devel 和 Neovim issue 追踪器上看到大量关于此的激烈辩论。

结语

未来不再是过去的那个样子了。

—— Yogi Berra

我不会假装我不担心。AI 浪潮移动得很快，现有者拥有巨大的资金和心智份额优势，编程的本质正在我们脚下转变。完全有可能 Emacs 和 Vim 会逐渐淡入小众的默默无闻，只被少数拒绝前进的顽固派使用。

但我 20 年来一直听说 Emacs 快要死了，它仍然在这里。社区虽小但充满激情，编辑器比以往任何时候都更强大，架构真正适合 AI 时代。Vim 的情况类似——核心理念如此强大，它不断找到新的表达方式（Neovim 是最新和最有力的化身）。

能够生存的编辑器不会是那些拥有最华丽 AI 功能的。它们将是那些用户在乎到继续构建、适应和分享的编辑器。这一直是开源软件的真正引擎，再多的 AI 也改变不了这一点。

所以如果你是 Emacs 或 Vim 用户：不要恐慌，但也不要自满。学习新的 AI 工具（如果你不是根本反对它们的话）。完善你的配置，让它变得棒极了。写关于你的工作流。帮助新人。确保你的编辑器在 AI 时代存活的最好方法是让它在其中蓬勃发展。

也许未来不再是过去的那个样子——但这不一定是坏事。

译者总结

这篇文章提供了一个难得的平衡视角，既不盲目乐观也不悲观绝望。几个关键要点：

1. AI 是双刃剑：它可能削弱传统编辑器的优势（编辑速度不再那么重要），但同时降低了学习曲线（配置门槛大幅降低）

2. 终端工具的优势：Claude Code、Aider 等 AI 工具天然适合终端环境，这给了 Emacs/Vim 用户一个独特优势

3. 社区活力是关键：技术不是决定性因素，真正决定这些编辑器命运的是社区能否持续吸引新贡献者

4. Emacs 的独特优势：作为”操作系统”的编辑器，Emacs 可以在邮件、笔记、Git 等多个维度集成 AI，这是其他编辑器难以复制的

作为一个长期使用 Vim/Neovim 的开发者，我认同作者的观点——与其焦虑，不如积极拥抱变化，让这些经典工具在 AI 时代焕发新生。