Loading... # Emacs 与 Vim 在 AI 时代的未来 # 一、新闻概述 ## 1. 标题 Emacs and Vim in the Age of AI（Emacs 与 Vim 在 AI 时代） ## 2. 发布时间 2026 年 3 月 9 日 ## 3. 来源 (think) 个人博客 # 二、核心内容 ## 1. 事件摘要 ### A. 主要内容 文章作者 Bozhidar Batsov 作为拥有 20 年以上 Emacs 使用经验的核心贡献者，深入分析了在 AI 工具快速发展的背景下，Emacs 和 Vim 这两款传统编辑器面临的挑战与机遇。 ### B. 核心亮点 - VS Code 和专用 AI 编辑器（Cursor、Windsurf 等）正在形成强大的吸引引力 - AI 改变了编程的核心技能：从编辑速度转向意图表达和代码审查 - AI 可能降低 Emacs Lisp 和 VimScript 的学习门槛 - 终端原生 AI 工具与 Emacs/Vim 的工作流天然契合 ## 2. 关键信息 ### A. 作者背景 - Emacs 狂热使用者超过 20 年 - 维护了多个热门 Emacs 包，包括 copilot.el - 近期重新学习 Vim 和 Neovim ### B. 涉及技术 - Emacs、Vim、Neovim - Claude Code、Copilot、Cursor、Windsurf 等 AI 工具 - gptel、ellama、aider.el、avante.nvim 等集成插件 ### C. 文章定位 这是一篇技术观点文章，而非纯粹的新闻报道，基于作者多年开源社区经验对未来趋势的思考。 ## 3. 背景介绍 ### A. 前置背景 VS Code 已经在编辑器市场占据绝对主导地位，并且正在获得所有主要 AI 工具的一流集成支持。微软有充分的资源和动力让 VS Code 成为 AI 辅助开发的最佳宿主。 ### B. 相关上下文 编程领域正在经历根本性转变，AI 越来越多地承担代码生成工作，人类的角色从编写代码转向审查、引导和精炼代码。 # 三、详细报道 ## 1. 风险分析 ### A. IDE 的引力井 VS Code 的市场份额已经远超其他编辑器，正在获得 Copilot、Codex、Claude、Gemini 等 AI 工具的深度集成。Cursor、Windsurf 等专用 AI 编辑器也吸引了大量投资和人才。这些工具围绕 AI 工作流构建完整的体验，提供集成的上下文管理、内联差异、多文件编辑和代理循环。 每个转向这些工具的开发者都是一个不再学习 Emacs 或 Vim 快捷键、不再编写 Elisp、不再为生态系统做出贡献的人。这种引力井效应是真实的。 ### B. "强力工具"的必要性存疑 Emacs 和 Vim 一直以来的卖点在于让用户更快地编写和编辑代码。快捷键、宏、可扩展性——所有这些都在于让人类更高效地完成编码的机械动作。 但如果 AI 正在编写你的大部分代码，机械编辑速度还重要吗？当你正在审查和引导 AI 生成的差异而不是逐个字符地输入代码时，瓶颈从"我能编辑多快"转移到"我能多清楚地表达意图并评估输出"。这是一种完全不同的技能，而且不清楚 Emacs 或 Vim 在这方面有内在优势。 学习曲线的论证也变得更难成立。当使用 Cursor 的初级开发者可以在一个下午搭建整个应用程序时，要求某人花费六个月学习 Emacs 以获得 10 倍速度是一个艰难的推销。 ### C. 企业支持的不对称 VS Code 有微软。Cursor 有风险投资。Emacs 有一小群志愿者和自由软件基金会。Vim 有 Bram 和现在的维护者社区。Neovim 有一个小型但专注的核心团队。 这种情况一直存在，但 AI 放大了差距。构建深度 AI 集成需要跟上快速发展的 API、模型和范式。资金充足的团队可以专门投入工程师全职从事这项工作。志愿者驱动的项目以人们业余时间和热情的节奏前进。 ### D. 末日场景 让我们走向极端：如果我们熟悉的编程在下一个十年内完全自动化会怎样？如果 AI 代理可以接收规范并生成工作、经过测试、已部署的软件而无需人工干预，我们就根本不需要编码编辑器了。没有 Emacs，没有 Vim，没有 VS Code，没有 Cursor。整个类别变得无关紧要。 作者认为这在短期内不太可能，但值得承认这是一种可能性。AI 能力的轨迹甚至让乐观主义者感到惊讶。 ## 2. 机遇分析 ### A. AI 使配置和扩展变得微不足道 几乎没有人谈论这一点：Emacs 和 Vim 一直受困于其扩展语言的晦涩。Emacs Lisp 是大多数程序员从未见过的 20 世纪 80 年代的 Lisp 方言。VimScript 就是 VimScript。即使是 Neovim 专门采用因为它更易接近的 Lua，也足够小众以至于大多数开发者没有写过一行。 这几十年来一直是两个生态系统的最大瓶颈。不是编辑器本身——它们极其强大——而是自定义它们需要学习一种不熟悉的语言，而且大多数人从未超越从博客文章和 README 文件复制片段。 作者在第一次学习 Emacs 和 Vim 时对 Elisp 和 VimScript 感到不知所措，他认为自己不是唯一一个。只有投入大量时间真正学会 Elisp 后，他才开始在 Emacs 中感到非常富有成效。（从未费心对 VimScript 做同样的事情，而且坦率地说，他也不太渴望掌握 Lua。） AI 一夜之间改变了这一点。你现在可以用简单的英语描述你想要什么，并获得工作的 Elisp、VimScript 或 Lua。"写一个 Emacs 函数，将当前段落重新格式化为 72 列并添加前缀"——完成。"配置 lazy.nvim 使用这些快捷键设置 LSP"——完成。扩展语言障碍，几十年来一直是采用的最大障碍，突然之间变得低得多。 ### B. 插件开发同样受益 在 Emacs 社区 20 多年后，作者经常感觉到一个相对较小的群体——也许 50 到 100 人——正在推动最有意义的进展。同样的名字出现在 MELPA、邮件列表和错误报告中。这不是对那些人的批评（他自豪地是其中之一），但这是一个结构性弱点。一个依赖如此少贡献者的社区是脆弱的。 不仅仅是 Elisp 和 VimScript。Emacs 和 Vim 的 C 内部（以及 Neovim 的 C 核心）由更小的群体维护。找到既愿意又能够入侵数十年旧的 C 代码库的人确实很难，而且随着越来越少的人学习 C，这变得更难。 AI 工具可以在这里以两种方式提供帮助。首先，它们降低了新贡献者的门槛——理解想要构建东西的"概念"的人现在可以获得 AI 对不熟悉语言"实现"的帮助。其次，它们帮助现有维护者更快地移动。作者个人发现 AI 非常擅长生成测试脚手架、编写文档和处理减慢包维护速度的繁琐部分。 ### C. AI 集成已经在发生 Emacs 和 Neovim 社区并没有坐以待毙。已经存在令人印象深刻的 AI 集成： Emacs： - gptel——多功能 LLM 客户端，支持多个后端（Claude、GPT、Gemini、本地模型） - ellama——通过 llama.cpp 和 Ollama 与 LLM 交互的 Emacs 接口 - aider.el——Aider 的 Emacs 集成，Aider 是流行的 AI 结对编程工具 - copilot.el——GitHub Copilot 集成（作者恰好是项目的当前维护者） - elysium——具有内联差异应用的 AI 驱动编码助手 - agent-shell——通过代理客户端协议与 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 帮助下，创建新的集成变得更加容易。作者不会惊讶插件开发速度显著加速。 ### D. 终端原生 AI 工具是天然契合 这里有一个值得更多注意的讽刺：许多最强大的 AI 编码工具是终端原生的。Claude Code、Aider 和各种 Copilot CLI 工具都在终端中运行。而终端里有什么？Emacs 和 Vim。 在 Emacs vterm 缓冲区或 Neovim 终端分割中运行 Claude Code 是完全自然的工作流。你在一个窗格中获得 AI 代理，在另一个窗格中获得你的编辑器，所有快捷键和工具都保持完整。没有切换到不同的应用程序——都在同一个环境中。 这实际上是优于基于 GUI 的 AI 编辑器的优势，其中 AI 集成与编辑器自己的界面紧密耦合。使用终端原生工具，你可以选择自己的编辑器和自己的 AI 工具，它们自然地组合在一起。 ### E. Emacs 作为 AI 集成平台 Emacs 的"编辑器即操作系统"哲学非常适合 AI 集成。它不仅仅是代码编辑器——它是邮件客户端（Gnus、mu4e）、笔记系统（Org mode）、Git 接口（Magit）、终端模拟器、文件管理器、RSS 阅读器等等。 AI 可以在每一层集成。想象一个 AI 助手，可以读取你的 org-mode 议程、在 mu4e 中起草邮件回复、在 Magit 中帮助你编写提交消息以及在源缓冲区中重构代码——都在同一个环境中，共享上下文。没有其他编辑器架构使这种深度的跨域集成像 Emacs 一样自然。 ### F. AI 帮助你自助 对于 Emacs 和 Vim 用户来说，AI 最被低估的好处之一是平凡的：故障排除。两个编辑器都有臭名昭著的陡峭学习曲线和不透明的错误消息。"Wrong type argument: stringp, nil" 比任何竞争对手都让更多人远离 Emacs。 AI 工具在解释神秘错误消息、诊断配置问题和建议修复方面非常出色。它们可以读取你的 init 文件并发现问题。它们可以解释一段 Elisp 做什么。它们可以帮助你理解为什么你的快捷键不起作用。这显着拉平了学习曲线——不是通过使编辑器更简单，而是通过给每个用户提供耐心、知识渊博的指南。 作者在 Emacs 设置中确实不需要任何 AI 帮助来排除故障，但在 Neovim 世界中偶尔很方便，相比之下他的知识相对有限。 至少有一个记录在案的案例表明，有人离开多年后回到 Emacs，特别是因为 Claude Code 使修复配置问题无痛无苦。他们因为配置负担太烦人而离开 Emacs 去 IntelliJ——一旦 AI 消除那个障碍就回来了。"快乐该死的日子我又回家了"，正如他们所说的那样。如果 AI 能带回离开的 Emacs 用户，在我看来这是一件好事。 ### G. 即使在编程后的世界，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。 因此即使在最极端的情况下，两个编辑器都有超越代码的生命。一个可能 diminished 的生活，但仍然是生活。 ## 3. 技术细节 ### A. 编辑器角色转变 几十年来，编辑器是你"编写"代码的地方。越来越地，它正在成为你"审查、引导和精炼"AI 编写的代码的地方。重要的技能从打字速度和编辑体操转移到规范清晰度、代码阅读和架构判断。 在这个世界中，获胜的编辑器不是具有最佳代码补全的编辑器——而是给你对工作流最大控制的编辑器。而这一直是 Emacs 和 Vim 的核心价值主张。 ### B. 社区适应的挑战 问题是社区能否足够快地适应。工具在那里。架构在那里。哲学是正确的。需要的是人——更多的贡献者、更多的插件作者、更多的文档作者、对话中更多的声音。AI 可以帮助弥合差距，但它不能取代真正的社区参与。 ### C. 伦理关注 Emacs 和 Vim 社区中并非每个人都对 AI 热情，反对意见超越了单纯的技术恐惧症。存在将在很长一段时间内辩论的真正伦理关注： - 能源消耗。训练和运行大型语言模型需要大量的计算能力和电力。对于一直重视效率极简主义的社区——以在 40 年前的编辑器上运行为荣的 Emacs 用户、以亚秒启动时间为豪的 Vim 用户——AI 的环境成本难以忽视。 - 版权和训练数据。LLM 在大量代码和文本语料库上训练，该训练的合法性和伦理仍然有争议。一些开发者对使用可能未经明确同意从受版权保护的代码中学习的工具感到不舒服。这种担忧深深地触动了对许可深切关心的开源社区。 - 工作置换。如果 AI 使开发人员显着更高效，可能需要更少的开发人员。对于任何编程社区来说这是一个不舒服的想法，而对于围绕赋予人类程序员力量的身份而建立的编辑器来说，这尤其尖锐。 这些担忧已经产生了具体的行动。Vim 社区最近看到了 EVi 的创建，这是 Vim 的一个分支，其整个存在理由是提供没有 AI 辅助（生成的？）代码贡献的文本编辑器。无论你是否同意前提，人们因此分叉既定编辑器这一事实告诉你一些社区成员感觉有多强烈。 # 四、影响分析 ## 1. 行业影响 ### A. 编辑器竞争格局 VS Code 和专用 AI 编辑器在资金和市场份额上拥有巨大优势，但 Emacs 和 Vim 的核心价值——工作流控制和可定制性——在新的编程范式中仍然相关。 ### B. 技术趋势 编程的角色从"编写"转向"审查和引导"，这有利于那些在上下文管理和工具集成方面提供最大灵活性的编辑器。 ## 2. 用户影响 ### A. 现有用户 对于现有 Emacs 和 Vim 用户，AI 工具可以降低配置障碍、加速插件开发，并在需要时提供故障排除帮助。 ### B. 新用户 学习曲线曾经是 Emacs 和 Vim 的主要障碍。AI 可以显着降低这一障碍，使新用户更容易进入生态系统。 ### C. 离开用户的回归 已记录的案例表明，一些用户因配置复杂而离开 Emacs，在 AI 工具让故障排除变得容易后回归。 ## 3. 社区影响 ### A. 贡献者门槛降低 AI 可以帮助不熟悉 Elisp 或 VimScript 等语言的新贡献者更快地实现他们的想法，扩大贡献者基础。 ### B. 伦理分歧 关于 AI 的伦理担忧可能导致社区分裂，例如 EVi 分支展示了部分社区对 AI 代码的强烈反对。 # 五、各方反应 ## 1. 作者观点 作者承认担忧，但保持谨慎乐观。他一直在听人说 Emacs 即将死亡 20 年了，但它仍然存在。社区很小但充满激情，编辑器比以往任何时候都更有能力，架构确实适合 AI 时代。 ## 2. 社区行动 ### A. AI 集成插件蓬勃发展 Emacs 和 Neovim 社区已经开发了丰富的 AI 集成插件生态系统，包括 gptel、copilot.el、avante.nvim 等。 ### B. 伦理反对 Vim 社区出现了 EVi 分支，明确反对 AI 代码，显示了社区内对 AI 的分歧。 ## 3. 作者建议 如果你是 Emacs 或 Vim 用户：不要恐慌，但也不要自满。学习新的 AI 工具（如果你不是从根本上反对它们）。美化你的设置并使其令人敬畏。写你的工作流。帮助新来者。确保你的编辑器在 AI 时代生存的最佳方式是让它在其中繁荣。 也许未来不是它曾经的样子——但不一定是一件坏事。 *** ## 参考资料 1. [Emacs and Vim in the Age of AI](https://batsov.com/articles/2026/03/09/emacs-and-vim-in-the-age-of-ai/) 最后修改：2026 年 03 月 16 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏