怎么,你也曾对编辑器着迷吗?

你没有？哦，那没事了，可能是我这人有点工具癖（手动狗头）。

但如果你也有过——那我们大概能聊到一块儿。

这篇文章是一份个人笔记。顺着这些年我用过的编辑器，回头看一件事：我们到底是怎么和代码打交道的，又是怎么从亲手编辑文本，一步步走到今天要调度一群 Agent 的。写着写着我越来越确信，”编辑器”这个词，可能已经不够用了；而它正在消失的边界里，也藏着一点兴奋之外的阴影。

第一部分：CLI 时代

一、Vim：一扇新世界的大门

几乎每个第一次打开 Vim 的人，都会经历同一场小型灾难。

先是打不了字。好不容易发现要按 Esc，又不知道接下来该干什么。等到终于把该改的改完，却发现自己被困在里面——连退出都不会。最后只能灰头土脸地打开浏览器，搜索那句后来成了程序员世界头号梗的问题：

How to exit Vim?

我也是这样狼狈进门的。大学才真正开始碰 Linux 和 GNU，也是在那台塞满命令行工具的电脑上，第一次遇见 Vim。

可真正跨过那道门之后，我才发现门后根本不是”另一个编辑器”，而是另一种思考文本的方式。

有一阵子，我在电脑上”玩”得最多的不是游戏，是 Vim。我常常新建一个临时文件，随便贴一段文字或代码进去，就在那儿练光标跳跃，练 ciw、da(、.，不是为了写出什么功能，只是反复感受那种手感和节奏。就像小时候重玩一款早就通关的游戏——不为赢，单纯因为操作本身让人开心。

后来我才慢慢想明白，自己那时到底在练什么。

Vim 最迷人的地方，是它把”编辑”变成了一套语法。你不是在移动光标，而是在表达意图：ciw 是”改掉当前这个词”，da( 是”删掉这对括号里的东西”，. 是”把刚才那个动作再来一遍”。动词、对象、修饰词，像造句一样不断组合。编辑不再是一连串零散的按键，而成了一门可以说、可以写的语言。

那个临时文件，其实就是我在背这门语言的单词。

就像有人第一次看完一部特别好的电影，旁边总有人说——”真羡慕你还能第一次看它”。后来每次想起这段经历，我都会想：真羡慕那些还没接触过 Vim 的人。那种推开新世界大门的兴奋，一辈子大概只有一次。

直到今天，我还在用 Vim。不是因为它一定最好，而是因为它早就长在了我的手指上。终端里随手 vim ~/.zshrc 改个配置，VSCode、Cursor 里也总要装上 Vim 插件。它早已不只是一个编辑器，而是我和文本打交道的默认方式。

当然，也得说句公道话：Vim 的门槛确实不算低。光是让新人”能打字、能退出”，就足够劝退一批人；它的现代化也慢过半拍。那种被人津津乐道的”手感”里，或许也掺着一点路径依赖：你为它交了太多肌肉记忆的学费，早就舍不得走了。

二、Emacs：如果编辑器就是操作系统呢？

差不多同一时期，还有另一扇门：Emacs。

如果说 Vim 想回答的是”如何把编辑文本做到极致”，那 Emacs 想回答的是一个更大的问题——如果整个操作系统都建立在文本交互之上，会怎样？

它本质上是一个披着编辑器外壳的 Lisp 环境。编辑文件只是入口，邮件、文件管理、日程、Shell 都能塞进去；更要紧的是，这些能力全都能被你重新定义。你不只是在使用 Emacs，你是在给自己搭一个文本世界里的工作环境。

所以才有那句流传已久的调侃：

Emacs 是一个不错的操作系统，只可惜缺了一个像样的编辑器。

Emacs 我认真折腾过，也动过把工作全搬进去、从此长住其中的念头，最终还是没能留下来。表面原因是受不了 Lisp 满屏的括号，真正劝退我的，是它那份”什么都能做”背后的无底洞。可它仍留给我一件一直记着的事：编辑器不一定只是编辑器。它可以是人与计算机交互的整个环境，也可以是某种工作方式的容器。这个念头，当时只是一个好玩的旁枝，后来却一路长到了 Agent 时代。

第二部分：GUI 时代

三、Sublime Text

后来，我遇见了 Sublime Text。倒不是离开了终端——Vim 和命令行一直都在——只是我的世界里，第一次多了一个像样的图形界面编辑器。

第一次打开它的时候，我有点震惊：原来编辑器可以这么漂亮。启动几乎是瞬间完成，Goto Anything 里敲几个字符就能跳到任何文件，多光标编辑第一次让我意识到，原来十几个地方可以同时改。那种顺滑和利落，是我在终端里从没体会过的。

但真正吸引我的不是某一个功能，而是它证明了一件事：编辑器可以既强大又优雅，既轻快又容易上手。这两组词过去像是互斥的，Sublime 把它们放到了一起，也让编辑器第一次真正走出了极客圈。直到今天，依然有很多人守着 Sublime，不是因为它最新，而是因为它足够轻、足够顺、足够不打扰人。

这也让我第一次明白，编辑器从来不是一条谁替代谁的直线。每一种工具都有自己的生态位，而低延迟和少打扰，本身就是一种理由。

四、Atom 为什么输了，VSCode 为什么赢了

Sublime 之后，两个基于 Electron 的编辑器几乎同时进入视野：Atom 和 VSCode。它们都来自那个”用 JavaScript 写一切”的年代，也都相信编辑器不该只是一个本地文本框，而应该是一套可以扩展的平台。

Atom 的理想很吸引人：hackable editor，一个你可以随意改造的编辑器。编辑器应该像网页一样开放，任何开发者都能用 HTML、CSS、JavaScript 去定制它。只是它始终没解决几个现实问题：启动慢，打开大文件慢，插件一多更慢；它把赌注押在了”愿意折腾的人”身上，而现实里，更多人只想打开就干活。哲学没有错，只是这一注押在了少数人那边。

VSCode 的方向正好相反：开箱即用，需要时再扩展。它同样跑在 Electron 上，却通过进程隔离、延迟加载、增量渲染，把体验做得足够像原生应用。真正奠定胜局的，是 Language Server Protocol（LSP）和远程开发。前者让每种语言都能用统一方式接入补全、跳转、诊断，后者把本地、服务器、容器、云端开发慢慢收进同一个界面。

所以 VSCode 赢得的不只是一场编辑器之争，而是一个生态位。今天一个新语言出来，第一件事是出 VSCode 插件；一个新框架出来，第一件事是出 VSCode 调试适配器；一家云服务商想吸引开发者，第一件事还是出 VSCode 扩展。

生态效应一旦形成，就很难被颠覆。不是技术上打不过，而是迁移成本太高：你的工作流、快捷键、插件、团队配置，全都绑在一起。就算来一个快一倍、漂亮一倍的新编辑器，你也很难说服自己从头再搭一遍。

所以 VSCode 早已不是一个能被”更好的编辑器”击败的编辑器。

它是一个开发操作系统的内核。

这其实又把 Emacs 当年那个问题带了回来：编辑器到底只是编辑文件的地方，还是开发者工作的整个环境？只不过到了 VSCode 这里，这个环境不再靠一个人改 .emacs 长出来，而是靠插件、协议和生态慢慢堆成了默认入口。

当然，赢家也有赢家的代价。VSCode 是个吃内存的大胖子，Electron 的原罪它一样背着；微软那套”拥抱扩展”的开放，本质是一种更高级的绑定——你用得越顺手，离开的成本就越高。舒适区待久了，也会变成一堵你自己都没察觉的墙。

第三部分：AI 时代

五、GitHub Copilot

然后，AI 来了。

最早大规模把 AI 带进日常编码的是 GitHub Copilot。2021 年，GitHub 和 OpenAI 一起推出了它，定位是”AI 结对程序员”。它长在 VSCode 里，并不显眼：你在写代码，它就根据上下文，用灰色的字提前把接下来可能要写的一整行、甚至一整个函数补出来。觉得对，按一下 Tab 就接受了。

就是这么一个小小的灰色提示，让几百万开发者第一次同时感受到——AI 真的可以帮你写代码了。

现在回头看 AI 时代刚开始的时候，我已经有点无法重新感受当时那种兴奋了。今天再看自动补全，好像已经成了理所当然的背景噪音。但我清楚记得，第一次在代码里写下一段 comment，然后看它顺着我的意图自动生成测试时，那种震撼非常具体：原来除了手写、搜索、复制、粘贴、改一改别人的答案之外，编辑器里也可以有东西主动接着你往下写。

它没有改变编辑器的样子，却改变了一件更根本的事：写代码，从”手写加复制粘贴”，开始变成”你和一个模型一起写”。

当然，这一步的”融合”还很浅。Copilot 更像是把 AI 轻轻嫁接到老编辑器的表面——你还是在原来的编辑器里写代码、查资料、拼上下文，它只在光标附近搭把手，看不见整个项目在干什么。但正是这层浅浅的嫁接，第一次让 AI 和编辑器长在了一起。而”只懂光标附近、读不懂整个项目”这个短板，恰恰指向了下一步该往哪走。

六、Cursor

Copilot 让”AI 帮我补全”成了习惯。但真正让我觉得整个编辑方式都变了的，是 Cursor。

它从 VSCode fork 出来，界面几乎一模一样，只多了几样东西：Tab 补全、Cmd+K、Cmd+L。Tab 补全是 AI 根据上下文预测你接下来要写什么，按一下就整行整段地生成；Cmd+K 是选中一段代码，用自然语言告诉它想怎么改，它直接帮你重写；Cmd+L 则是在编辑器里开一个 AI 对话窗口。

看起来只是三个快捷键，底下却是一次视角的翻转。

以前的编辑器是”你输入，它帮你补完”；现在变成了”你表达意图，它替你写出来”。第一次，我发现自己在编辑器里做得最多的事，不再是敲字，而是想清楚要它做什么。

如果说 Copilot 是把 AI 嫁接到编辑器表面，Cursor 则把融合往下压了一层：它 fork 了整个 VSCode，把成熟编辑器的插件、LSP、快捷键原封不动接过来，再在上面重构”意图→生成”的交互。这也决定了它这一阶段的形态——它同时要一具被验证过的编辑器躯体，和一颗 AI 的大脑。剥掉 AI 外壳，底下仍是个编辑器。

而这道尚未弥合的缝，正是它接下来要撑开的方向：与其把 AI 塞进编辑器，不如让 Agent 直接走到台前。

七、Agent 优先：Cursor 3.0 与 VSCode Agents

差不多前后脚，Cursor 和 VSCode 做了同一个方向的选择：把编辑器整个围着 Agent 重新组织一遍。

2026 年 4 月，Cursor 发布 3.0，代号”Glass”，打开的第一眼界面就变了。以前是一个文件列表加一个编辑窗口，现在主界面成了 Agents Window——一个 Agent 调度面板。你可以同时启动多个 Agent，每个在自己的 Git worktree 里独立干活：一个修前端 bug，一个重构后端 API，还有一个在浏览器里验证 UI；你坐在中间，看进度、审产出、决定合并还是重来。

VSCode 也很快跟上。Agent mode 和 Agent Sessions 早就在 Insiders 版本里跑了一段时间，微软一直在把本地、后台、云端的 Agent 会话收拢到同一个工作台里。到了 2026 年 7 月 1 日发布的 1.127，这套界面进一步长成一个能拖拽、分组管理的 Agents 窗口，还配上了专给 Agent 用的浏览器工具——Agent 能打开页面、截图、点击、填表单，写完一个 API 自己去调一遍，看返回对不对，再回来修正。

不只是 Cursor 和 VSCode，Trae、Kiro、Antigravity 这类新 IDE 也在往这个方向挤。它们形态不完全相同，但都在说明一件事：VSCode 那套成熟编辑器底座，正在被一遍遍改造成 Agent 的工作台。

但抛开谁先谁后，它们骨子里是同一个转向：Agent 优先。IDE 的主界面不再是编辑窗口，而是 Agent 调度面板；打开编辑器要做的第一件事，也不再是”打开一个文件开始写代码”，而是”派一个 Agent 去完成任务”。

而这场翻转真正重新定义的，不只是编辑器，还有人。你从亲手写代码的人，变成给一群分身派活、验收产出的那个人。这一步走得很快，快到人的角色还没完全跟上——同时盯着好几个 Agent，认知负担未必比自己写代码轻。但也正是在这里，冒出了下一个真正的问题：当 Agent 成了主角，缺的已经不是一个更好的编辑器，而是一整套能让人从容调度、审阅、接管它们的环境。

八、Claude Code

Cursor 和 VSCode 都还在”编辑器里加 Agent”的框架里。而 2025 年出现的 Claude Code，提出了一个更激进的问题：

如果 Agent 足够强，编辑器本身还必要吗？

Claude Code 是 Anthropic 的 AI 编程工具，核心定位是”终端原生”的编程 Agent。打开终端，输入 claude，用自然语言告诉它你想做什么，它就自己读代码、改文件、跑测试、看输出，一路做到任务完成。你可以在 VSCode 里用它的插件，在 JetBrains 里用，甚至在 Slack 里发条消息让它干活；也可以用 Claude Code on the web，在浏览器或 Claude 手机 app 里把任务交给云端环境，等你回头审。

如果”编辑器”指的是”用来写代码的图形界面软件”，那 Claude Code 不是编辑器——它根本没有自己的编辑窗口。但如果你把”编辑器”理解成”开发者与代码交互的入口”，那它正在成为一种新的入口。

你不必打开任何界面，在终端里敲一行命令，它自己去改代码；你回来的时候，代码已经变了。它正在把”编辑”从”界面”里抽出来，变成一件”Agent 替你完成的任务”。

Claude Code 把这条融合线推到了尽头，也把它翻了个面：AI 不再住进编辑器，而是编辑器成了 AI 众多入口之一——终端、VSCode 插件、JetBrains、Slack、手机网页，都只是它探出头的一个界面。可当界面这样退到幕后，也带出了新的课题：过程跟着隐身，你回来面对的是一堆 diff，信任几乎整个交给一个看不见其思路的黑箱。这不是它的终点，而是它接下来要补的功课——怎么把黑箱重新变得可看、可信、可接管。

而且说到底，界面之变还只是表层。Claude Code 真正的分野，也许在更底下：它把一个足够强的大模型，用一整套工程手段发挥了出来——工具调用把读代码、改文件、跑测试、看报错这些动作包成模型能反复调用的能力；agent loop 让它在”尝试—观察—修正”之间自己转起来；沙盒则给了它一个能放手施展、又不至于闯祸的空间。让”编辑”能被整个交出去的，不是”没有界面”，而是这套让大模型能力被真正释放出来的机制。

第四部分：编辑器之后

九、重新理解”编辑”

Claude Code 出来以后，我开始反复想一个问题：我们还需要编辑器吗？

我越来越觉得，编辑器并不会消失，只是重要性在下降。过去，编辑是开发工作的主体；今天，它越来越像最后的收尾。开发者练习的重点，也从”如何更快写代码”，慢慢变成了”如何更好地表达意图，判断 AI 有没有理解，并审阅它交付的结果”。

写到这里我才意识到，这些年我其实一直在追着同一个东西跑：Vim 在重新定义文本，VSCode 在重新定义 IDE，Cursor 在重新定义人与 AI 的协作，Claude Code 则开始重新定义”编辑”本身。

那再往后呢？我越来越觉得，未来真正需要设计的，也许已经不是编辑器，而是 Agent 工作的环境（Environment）。因为 Agent 要的从来不只是一个文本框，它需要终端、浏览器、Git、任务、上下文、通知、协作、记忆、恢复现场，也需要很多 Agent 一起工作。而人，越来越不像那个亲手写代码的人，更像这些 Agent 的负责人。

这也是我做 jaade（一个面向 Agent 的开发环境）时反复想的问题。它不想重新发明一个编辑器，而是想试着搭一个 Agent 工作的环境，并回答另一个问题：

如果未来 Agent 才是一等公民，那它们应该工作在怎样的环境里？而人又该怎样看见、审阅、接管它们的工作？

这个问题，我现在也没有答案。Cursor 在试，VSCode 在试，Claude Code 在试。我也想试试看。我也清楚，这大概率只是又一次试错——说不定哪天回头看，jaade 连个名字都没能留下，就悄悄消失在这条长长的试验名单里了。但我还是想亲手做一个工具，把自己这些年攒下的一点理解放进去，试一试。

十、往回看

回头看这些年的编辑器，大概可以分成几次转向。

Vim 和 Emacs 让文本编辑变得更快、更可编程，也第一次把”编辑器作为环境”这个念头种下来；Sublime 证明了编辑器可以轻快、漂亮、不打扰人；Atom 和 VSCode 则把编辑器推成了平台，只是前者更理想主义，后者更懂默认体验和生态。

到了 GitHub Copilot，AI 第一次坐进编辑器，帮你补全；到了 Cursor，AI 开始深度参与编辑；到了 Cursor 3.0 和 VSCode Agents，编辑器开始变成 Agent 的工作台；到了 Claude Code，编辑本身开始退出舞台。

也得提醒一句：别把这条线读成”谁赢了谁就对”。每一个编辑器背后，都有作者一套认真的产品哲学；很多时候决定结局的，不是哲学谁高谁低，而是时机、资源和一点运气。今天的赢家，换个年代未必赢；今天被淘汰的，也未必是想错了。

今天回头看，Vim 没有消失，VSCode 也没有消失。它们只是所解决的问题，不再是今天最重要的那个问题了。

我后来才慢慢意识到，自己真正着迷的，好像从来都不是编辑器。

而是人与计算机的交互方式，每隔几年，就会彻底变一次。

很幸运。这一次，我们正好站在变化发生的地方。

十一、一点阴影

当然，变化发生的地方，也不全是亮的。

如果 Agent 真的成了主要的执行者，问题就不只是在”还需不需要编辑器”这一层了。再往下问一点：编辑器里的那些插件呢？各种框架呢？我们还需要这么多种编程语言吗？

过去，插件、语言和框架都是人直接面对机器的界面。我们要记住语法、API、生命周期、最佳实践，也会因为熟悉某个编辑器插件、某个框架、某门语言而形成自己的手感和身份。但如果大量代码都由 Agent 生成和修改，很多差异就会退到幕后。对人来说，更重要的可能不再是”我熟不熟这个框架”，而是”我能不能说清楚系统要什么，能不能看懂它给出的 diff，能不能判断这个改动会不会在生产里出事”。

这未必是坏事。少一点样板代码，少一点工具崇拜，少一点为了适配框架而适配框架，本来也是好事。只是某些今天还很值钱的技术，未来会不会慢慢变成”屠龙之技”？不是完全没用，而是很少再由人亲手施展。

这些影响到底会走到哪里，我们现在其实还很难了解，也很难预测。但这层阴影值得先放在这里。因为编辑器从来不只是效率工具，它也承载了开发者的手感、偏好、审美和身份感。假如有一天这些东西都退到后台，被 Agent 的执行层抹平，那我们得到的也许不只是更高的效率，也会失去一些原本让编程世界显得丰富和有趣的东西。