夜雨聆风2024年底，AI编程工具井喷。Cursor用户破千万，Windsurf横空出世，Zed用Rust重写了编辑器的未来，连GitHub Copilot都开始免费。
所有人都在换IDE。
而我做了一个看起来完全反直觉的决定：把日常开发全部搬回Emacs。
不是尝鲜，不是怀旧，是认真的。到现在用了大半年，配合Claude Code，效率比之前用任何AI IDE都高。
我知道这听起来很像某种技术原教旨主义的宣言。但请耐心看完，我想解释的不是"Emacs比XX好"，而是一个更本质的问题：
AI时代，编辑器到底应该是什么？
02 编辑器的"智能"贬值了
先说一个可能有点扎心的观察：
当Claude、GPT-4这些模型能直接理解整个代码仓库、生成完整功能模块的时候，编辑器自带的"智能"——代码补全、语法检查、重构建议——突然就不那么值钱了。
你品品：
代码补全？AI写的比你补全的还完整 语法检查？AI直接告诉你哪错了、怎么改 重构建议？问一句，方案给你列三个 文档生成？把代码丢过去，README都给你写好
那编辑器还剩下什么？
我的答案是两件事：操控感和可感知性。
操控感是：你能多快、多精准地操作你的代码和工作流。可感知性是：AI能多大程度地理解你的当前状态。
这两件事，恰好是Emacs最擅长的事。
03 Claude Code + Emacs：当AI有了眼睛
这是我选择Emacs最核心的原因，也是别的IDE很难做到的事。
Server-mode：AI能"看见"一切
Emacs有一个叫server-mode的功能，开启后可以通过emacsclient命令从外部访问Emacs内部的任何状态。
这意味着什么？
意味着Claude Code——一个跑在终端里的AI编程助手——可以直接读取Emacs里所有buffer的内容。
*Messages*里的报错信息？直接读。任何打开的文件内容？直接读。Lisp求值的结果？直接读。
你不需要截图、不需要复制粘贴、不需要切换窗口。
举个真实的场景：
我在折腾Emacs配置的时候，eval-after-load报了个错。在传统工作流里，我得：
看到报错信息 复制报错文本 切到AI对话框 粘贴、描述上下文 等回复 切回去改代码
在Emacs + Claude Code的工作流里：
Claude Code自己读到 *Messages*里的报错直接分析原因 直接改好文件
步骤从6步变1步。而且AI获取的信息是完整的、精确的，不存在"我忘了贴哪段"的问题。
你在其他IDE里很难做到这件事
Cursor也好，Copilot也好，AI插件能感知的范围是有限的。它能看到当前文件，能拿到LSP的诊断信息，但它看不到你的终端输出、看不到你的build日志、看不到那些没有API暴露的内部状态。
而Emacs不一样。Emacs本身就是一个Lisp运行时，所有状态都是first-class的。Buffer、Window、Process、Hook——一切都是可以被查询和操纵的对象。
AI + Emacs，本质上是给AI接上了一个完整的操作系统级API。
04 不需要离开编辑器
第二个大优势：Emacs本身就是一个集成环境，不需要在外部工具之间跳来跳去。
我的日常开发：
Magit管Git——commit、rebase、diff，全键盘操作，体验比任何GUI Git工具都好 Dired管文件——浏览、创建、复制、删除， j/k导航，比Finder快vterm跑终端——Claude Code、shell命令，全在Emacs窗口里 Consult搜索——ripgrep + mdfind，项目中任何内容瞬间定位
所有东西都在Emacs里。Cmd+hjkl窗口间丝滑切换，全程不需要鼠标。
这有什么了不起的？
上下文切换是效率最大的杀手。 每次从编辑器切到终端，再切到浏览器，再切回来，你的大脑都在重新加载。当所有工具都在同一个环境里，你的注意力就不会被打断。
AI时代更是如此。你和AI的协作是一个连续的对话过程——改代码、看效果、调参数、再改。如果这个循环中每一步都要切换窗口，那个流畅感就碎了。
05 多工作区：同时和多个AI对话
我的配置里有一个细节：Cmd+1打开主Claude Code，Cmd+2打开"tom"工作区，Cmd+3打开"jerry"工作区。
这不仅仅是个快捷键。它代表了一种工作方式：
我可以同时在不同的git worktree里，让不同的Claude Code实例处理不同的任务。一个在修bug，一个在写新功能，一个在做代码审查。
三个AI同时干活，我只需要在窗口间切换查看进度。mode-line上用🦀🐱的图标显示哪个工作区是活跃的，一眼就知道状态。
这种多实例并行的工作方式，在单体IDE里很难实现。但在Emacs里，不过就是多开几个vterm buffer的事。
06 中文开发者的隐藏福利
这个小功能看起来不起眼，但用过就回不去：
Emacs可以检测当前buffer的类型，自动切换输入法。
进入Claude Code的终端 → 自动切到中文输入法，因为我要用中文和AI对话。
回到代码buffer → 自动切回英文，因为我要写代码。
进入Magit写commit message → 英文。
进入Org Mode写文档 → 中文。
你不需要手动切换。Emacs知道你接下来要干什么，帮你把输入法切好了。
这个小细节每天给我省下的时间可能只有几秒钟，但它消除了一个持续的心理摩擦。你不会意识到它有多好，直到你用回了没有这个功能的编辑器。
07 改完立刻生效：AI的反馈循环
Emacs配置有一个很优雅的特性：保存即重载。
我的init.el里配了一个hook，任何.el文件保存后自动eval。这意味着：
Claude Code帮我改了一段Emacs配置 → 文件保存 → 立刻生效。
不需要重启，不需要手动加载。改完就是好了。
结合Magit的diff视图，我可以立刻看到AI改了什么。结合*Messages*buffer，如果改出错了，Claude Code立刻就能读到报错，马上修复。
这个反馈循环快到什么程度？快到你感觉AI在"实时"帮你调代码。
08 40年的编辑器，为什么在AI时代反而更强了
最后说说更宏观的视角。
Emacs诞生于1976年，快50年了。在这50年里，无数编辑器来了又走——Sublime Text、Atom、VS Code（虽然还活着，但也在不断被挑战）、现在又来了Cursor、Windsurf、Zed。
Emacs为什么没死？
因为它从来不是一个"编辑器"，而是一个平台。
它的核心设计哲学是：不要给我一个成品，给我一个我能改造一切的引擎。
Lisp是它的底层语言，一切皆可定制。Buffer、Window、Process、Keymap、Hook——所有编辑器的概念都是暴露出来的、可以被修改的。
这正好是AI时代最需要的东西。
AI需要的不只是一个能编辑文本的窗口，而是一个它可以深度感知和操控的环境。Emacs给了它这个能力：
通过 emacsclient读取所有buffer状态通过 eval执行任意Emacs Lisp代码通过vterm与终端进程交互 通过文件系统操作任何文件
Emacs不是一个编辑器，它是AI的操作系统。
09 写给还在观望的人
我不是要劝所有人都用Emacs。Emacs的学习曲线确实陡峭，配置确实折腾，生态确实不如VS Code丰富。
但我想提供一个不同的视角：
当所有人都在追逐"下一个AI IDE"的时候，也许值得想一想——你需要的到底是一个内置了AI的编辑器，还是一个AI能深度接入的环境？
前者，每出一个新的AI工具，你就得换一个IDE。后者，AI工具随便换，你的环境始终是那个环境。
工具会过时，但好的架构不会。
这就是我在AI时代选择Emacs的原因。不是因为它最新、最好看、最有AI功能，而是因为它最开放、最灵活、最能让AI成为我工作流的一部分，而不是反过来。
如果你也在用Emacs + AI编程，欢迎交流。如果没用过但感兴趣，可以从Claude Code开始——它是我用过最好的AI编程助手，没有之一。
