为什么我把VS Code换成了Zed？编辑器不该跟工作抢内存

换编辑器，不是因为想要新主题、新侧边栏，或者换个地方装同一批扩展。换的原因是：编辑器已经开始跟我手头的工作抢资源了。

现代开发对电脑的要求本来就不低。浏览器开着一堆标签页，本地服务器、数据库、容器、语言服务器、终端，外加一个甚至多个AI编程代理同时在跑。这时候，用来编辑文本的那个应用，不该再占掉剩余内存的一大块，也不该让每次交互都显得更沉。

这就是我开始用Zed的原因。它快，在日常工作流里相对轻，跟终端相处得舒服，而且是照着AI辅助开发如今的实际形态设计的。VS Code和JetBrains的IDE依然值得尊重，它们是成熟工具，生态庞大，有些项目我可能还是得用。但Zed成了我第一个想打开的编辑器。

最先注意到的是性能

Zed的感觉是即时。打开快，文件出现快，切标签、搜项目、打字、滚动都直接。听起来像个小改进，可编辑器是一天要碰几百上千次的应用，微小的延迟会累积成整个工作流的心情。

这种手感不是把网页应用套进桌面壳里做出来的。它的界面由GPUI构建，这是Zed自研的GPU加速UI框架。团队写过设计思路：像渲染电子游戏那样渲染界面，目标是流畅、响应迅速，包括高刷新率显示器。

我在意的不是Rust和GPU渲染听起来多厉害，而是我能感觉到结果。编辑器待在一边，不抢戏。代码编辑器不该把自己变成主角，它应该快到让我忘记它的存在。

它给工作留出更多空间

内存是另一个原因。在我的工作流里，Zed通常比之前用的重型编辑器组合更省。这很重要，因为编辑器只是开发环境的一部分，浏览器、开发服务器、构建工具、Docker、WSL、数据库、AI代理都要内存。

编辑器省下的内存、少掉的扩展进程，可能决定整个系统是否还流畅。我更愿意把这份内存让给正在构建的应用，或者跑测试的代理。

这个说法要谨慎：Zed不保证在每个项目里都更省内存。语言服务器、调试器、终端、扩展、AI代理都算在总占用里。很长的AI对话会变大，超大仓库需要认真建索引。

Zed为补全、诊断、导航、重构等功能使用独立的语言服务器。设置里可以选择、排优先级，或者在项目不需要时关掉它们。所以我把低内存占用当作我这套配置下观察到的收益，而不是每个开发者都会复现的通用基准。理由很个人也很实际：在我跑的项目和工具下，Zed给了我更多喘息空间。电脑重新像是属于我的工作，而不是属于编辑器。

它把AI当成开发的一部分

很多编辑器是事后加上AI的。Zed越来越像是编辑器、终端、代码库、代理本来就该共享同一个工作区。

Zed的原生代理能读取和搜索项目、编辑文件、运行终端命令、使用MCP工具、遵循可复用的技能和指令，并在审查界面里展示改动。这更接近我现在的用法：不只是要自动补全，而是让代理调查一个bug、追踪相关代码、做出修改、跑测试，然后告诉我它到底动了哪里。

Zed也不只支持自家代理。文档描述了三条路径：原生Zed Agent、通过Agent Client Protocol接入的外部代理、基于终端的代理线程。外部集成可以包括Claude、Codex、OpenCode、Copilot、Cursor等支持Zed代理工作流的工具。

这种灵活性对我很重要。我不想被编辑器锁死在一家模型公司、一份订阅、一个界面上。有时我想让代理待在面板里，有时想在真实终端里用原始命令行，有时想让多个代理并行干活、我来审查改动。Zed给了AI一个有用的位置，但没有假装聊天框应该取代代码、终端、diff和开发者的判断。

终端是一等公民

我大量时间花在终端里。Git、测试、包管理器、构建脚本、部署命令、数据库工具、AI编程命令行、项目自动化都在那儿。我不想因为打开编辑器就放弃这个环境。

Zed的终端可以放在底部面板，也可以作为中央标签页开在普通文件旁边。它支持多个终端实例、自定义shell、任务集成，以及让AI帮忙解释错误或建议命令。

中央终端这个选项，用之前觉得微不足道。终端不总是只配占四分之一屏幕的小工具面板，有时候终端就是工作本身。日志、测试失败、交互工具、编程代理都需要空间，Zed让我能这样对待它们。

任务系统让这层关系更顺。我可以为构建、测试、lint或脚本定义可重复的命令，带着编辑器上下文运行，比如当前文件或选中的文本。我依然拥有shell的能力，又不用把每个工作流重做成编辑器扩展。这才是我说的终端友好：不只是内置一个终端，而是尊重终端驱动的开发方式。

它适配我的Windows和WSL工作流

如果编辑器跟我代码所在的环境打架，再快也没用。

Zed的Windows版本支持把WSL发行版作为远程目标打开。界面在本地跑，源代码、语言服务器、任务和终端可以在远程环境里跑。这个模型符合我的工作方式：在Windows上保留响应迅速的原生界面，同时在WSL里使用Linux工具和项目环境。不用假装Windows和Linux是同一台机器，也不用放弃任何一边的便利。

Zed也支持普通的SSH远程开发。文档说本地界面保持响应，语言服务器、任务和终端在服务器上运行，AI功能在远程会话中继续可用。对跨Windows、WSL、云服务器或远程Linux机器开发的人来说，这是实打实的功能，不是一个勾选项。

极简，但不空

Zed看起来干净，但不只是一个文本框。

它支持Tree-sitter解析和语言服务器，用于补全、诊断、导航、代码操作和重构。语言文档现在通过内置支持和扩展覆盖数百种编程语言和文本格式。它有基于Debug Adapter Protocol的集成调试器，支持断点、单步、变量检查、启动和附加工作流，以及多语言。它能跑任务和测试，用Jupyter内核做交互式代码，配合Git，安装社区扩展。

Zed还有实时多人编辑。多个开发者可以在同一个项目里工作，看到彼此的光标和编辑，协作时有频道和语音聊天。我未必每小时都用多人功能，但它反映了产品的一个取向：Zed是围绕共享工作设计的，不只是孤独地编辑文本。界面保持克制，底下的能力继续生长，这个平衡很难。很多工具能力变强就变乱，Zed仍然像一个编辑器。

扩展生态在变强

留在VS Code最常见的理由是扩展生态，这很公平。多年社区开发，几乎每种语言、服务、古怪工作流都有答案。

Zed更年轻，我不会告诉别人每个VS Code扩展都有对应替代，它没有。它有的是一个成长的扩展系统，覆盖语言、语言服务器、主题、图标主题、MCP服务器、代理服务器、调试适配器和代码片段。Zed的公开扩展目录列出了超过一千个扩展，包括对流行语言和框架的支持。

我也慢慢发现，自己需要的扩展比想象中少。旧配置里有些重量，来自提前解决每一个可能的未来问题。Zed把我推向更小的配置：项目需要什么就装什么，终端放在手边，让LSP、DAP、Tree-sitter、MCP这些标准工具承担更多集成工作。

这种做法不会适合所有人。如果你的工作依赖某个VS Code独有扩展，立刻切换可能带来的摩擦比省下的还多。先检查你的必需品。

它的取舍我喜欢

Zed对键盘友好，给终端真正的空间，假定语言服务器和命令行工具有价值，把AI代理当成该读文件、用工具、跑命令、产出可审查改动的工人，把原生性能当作产品特性，而不是把迟钝当成可扩展性的代价。

这些选择跟我工作流的方向一致。我不再想要一个试图把整个软件行业装进一个应用里的编辑器。我想要一个快速的重心，连接我的代码、终端、工具、远程环境和AI代理。Zed是我找到的最接近这个想法的编辑器。

什么时候值得试

如果你现在的编辑器比工作本身还沉，可以试试Zed。如果你经常开着浏览器、容器、本地服务和AI工具，想找回一些响应速度，可以试试。如果终端本来就是你构建软件的中心，可以试试。如果你想在编辑器里用AI，但不想被锁死在一个代理或模型供应商上，可以试试。

别因为网上有人发了启动时间对比图就切换。打开一个真实项目，只装你需要的语言支持，跑平常的服务器和测试，打开常用的终端和AI代理。看系统内存，也注意那个不太可测量的部分：编辑器让你等待或打断你专注的频率。

你可能会发现VS Code、Neovim或JetBrains IDE仍然更适合你的工作，这没问题。编辑器是私人的，生态很重要。但如果你已经把启动慢、界面拥挤、扩展过载、资源占用高当成现代开发不可避免的一部分，Zed值得一试。它提醒我，强大的编辑器依然可以很轻。