用完Zed之后，我发现了VS Code 和Zed的一个重大区别

我一直在尝试摆脱 VS Code 及其衍生品（如 Cursor 和 Antigravity），理由和许多开发者尝试新编辑器一样。我转向了 Zed 这类更精简的编辑器，因为它感觉更轻量、更干净，并且在花几个小时熟悉后，速度明显更快。与我多年来构建的、扩展繁多且 AI 深度集成的 VS Code 环境相比，Zed 的界面要清爽得多。

几个月来，我几乎没想念过 VS Code，但是偶尔也会打开vscode——直到我第一次在项目中途关闭 Zed，稍后重新打开它。我立刻注意到，日常流程中少了些什么。没有上下文，没有历史，只有空白的 shell。我不得不从头重建整个环境，而这是 VS Code 从未让我做过的事。结构还在，但工作流丢了。这时候我发现vscode的不可或缺性。

VS Code 如何将终端变成工作区的一部分

和大多数开发者一样，VS Code 是我第一个真正的代码编辑器。它始于一个代码编辑器，随着时间的推移，它演变成一个我无需离开窗口就能完成任何任务的环境：编译代码、执行、调试。集成的终端起初是一种便利，后来逐渐成为我组织工作的核心方式。现代项目同时依赖于多个进程，VS Code 的内置终端完美地支撑了这一点。而这也是vscode变得臃肿的一个原因。

以我正在进行的项目 xx-web为例，它依赖2个进程运行：React 前端、Go 后端，即使在本地测试时，我也需要前端和后端进程同时在两个终端标签页中运行，还需要第三个标签页用于 Git 命令等工具型 shell。每个终端都有其角色，而 VS Code 通过分屏和命名终端让这一切变得更加容易。

一个工作区包含了项目的整个操作状态。保留命令历史（能看到之前跑了什么），保留工作目录（CWD），保留输出内容，甚至还可以 保留分屏布局，VS Code 一直在做一件我直到使用其他编辑器才意识到的事：当我因其他紧急工作而关闭 VS Code 窗口时，重新打开后，它会自动恢复那些正在运行的终端，甚至保留历史记录。这意味着我不会迷失于离开前正在做的事和运行过的命令。虽然会话并非像 tmux 那样真正持久（进程会死亡），但至少我了解上下文——命令和日志依然存在，供我回顾。我无需打开编辑器并从头重建整个环境。VS Code 记住了足够多的工作流环境，让我的大脑无需去记。

Zed 让我意识到了 VS Code 的真正价值

当 VS Code 运行完美时，我为什么还会想切换到其他编辑器呢？在过去两三年里，AI 开始嵌入编码工作流。我测试了几乎所有基于 VS Code 的 AI 代码编辑器（如 Cursor 和 Antigravity），也曾用大量当时觉得合适的扩展来武装 VS Code。但随着时间的推移，这些东西开始给我的工作流带来摩擦：界面感觉臃肿，体验也变得缓慢。

就在这时，我决定从 AI 增强型编辑器退回到纯粹的代码编辑器。我尝试了 Zed、Sublime Text ，最终选择了 Zed。使用几个小时后，我发现它界面更干净、感觉更快、没有 Electron 的沉重感，整体编辑体验更流畅。它甚至有一个支持多标签页和分屏的内置终端。所以我最初的感觉是：“好吧，这个工作流在这里也存在。”

我开始想念 VS Code 是在我第一次关闭 Zed 时——当时有两个进程正在运行。当我稍后重新打开项目时，Zed 只恢复了两个终端，但仅仅是作为占位符。它们保持着相同的分屏结构，但 shell 是空白的。而 VS Code 会恢复带有历史记录的终端，其中包含可见的命令上下文、当前工作目录状态和工作流线索。在 VS Code 中，我能瞬间记起正在发生的事情，重建环境只需几秒钟；而在 Zed 中，我不得不手动从头重建一切。这带来的时间成本不言而喻。

在经历了 Zed 以及 Sublime Text 等同类纯代码编辑器后，我出于好奇检查了 Cursor 和 Google Antigravity，还有国内的trae，codebuddy。由于它们都以 VS Code 为基础，我想看看它们是否也保留了相同的 VS Code 行为。令人惊讶的是，两者都保留了。这时我才意识到，这不是 VS Code 的一个“特性”，而是 VS Code 基础框架的特性。终端被视为工作区状态，而非一次性的工具。这是 VS Code 生态系统模型本身的一部分。

vscode让你一眼就能想起 "刚才在干嘛"，几秒钟就能继续工作。这是很多人从 Zed 切回 VS Code 的重要原因之一—— 对于需要长期保持多个终端工作流的开发者，状态恢复太重要了。

而在非 VS Code 编辑器（如 Zed）中，终端管理是外部发生的，shell 是临时的。这就像打开一个外部终端应用（如 Windows PowerShell）并在 Zed 内部运行它一样，两者与代码编辑器都没有直接关系。如今，开发现代项目本质上是多进程的，这就是为什么终端、日志和工具型 shell 不是可选的附加项，而是工作流本身的一部分。目前只发现zed可以恢复终端的布局和数量。

这次经历让我深刻认识到，VS Code 真正的护城河并非某个单一功能，而是它所提供的工作流连续性。VS Code 将这种工作流规范化地集成到了主流的 GUI 编辑器中，而无需依赖单独的多路复用器（如 tmux）或以终端为中心的环境。真正的特性不是分屏终端或当前工作目录状态，而是工作流连续性和操作上下文。

对于开发者而言，这意味着我们选择的工具，其价值往往隐藏在一些不被注意的细节中——那些在“紧急切换任务”和“事后回归”时体现出的流畅度。Zed 等编辑器在“编辑体验”上可能更胜一筹，但 VS Code 及其衍生品在“环境记忆”上建立了深厚的根基。

这也引申出一个更广泛的选择权衡：你是愿意拥有一个更轻盈、启动更快、编辑更流畅的“编辑器”，还是愿意拥有一个虽然略显沉重、但能完整保存你工作状态和上下文的“开发环境”？

对我来说，答案逐渐清晰：在需要快速切换任务、同时管理多个项目时，工作流连续性带来的心智负担减轻，其价值远超编辑器启动速度快几百毫秒的好处。这可能也是为什么，即使面对众多新兴编辑器的挑战，VS Code 及其生态依然能保持如此强大生命力的核心原因之一。

当然如果目光放得长远一些的话，我相信zed未来也是会以更好的方式去支持这个人性化的新特性的，而且在AI时代这些可能也不是那么重要了，因为AI会话都可以把这些全都覆盖了。