我为什么从 VS Code 切换到 Zed

如果你已经受够了编辑器随着扩展增多而逐渐变慢的体验，那么你很可能已经在寻找一个更轻量、更现代的选择。过去5年，我一直在用 VS Code，但坦白说，我算不上它的“粉丝”。Electron 框架带来的资源消耗和响应延迟，始终是个让人无法忽视的问题。直到我遇到了 Zed——一个完全用 Rust 构建、拥有自己 GPU 加速 UI 框架的编辑器，它彻底改变了我的看法。

VS Code 的“原生”问题：当扩展成为负担

VS Code 本身并不慢。如果你只用一个空白的编辑器，它的启动速度和响应都算得上优秀。但现实是，没有一个开发者会这么做。我们需要 AI 补全、代码检查、格式化、远程开发、Docker 集成……每个扩展都在消耗 CPU 和内存。两三个 VS Code 窗口加上一堆扩展，轻松吃掉 3-4GB 内存。

VS Code 依赖的 Electron 框架本质上是 Chromium 套壳，渲染延迟和内存占用是它天生的短板。这不是微软的问题，这是技术选型的代价。

Zed 走了一条完全不同的路。它从零开始，用 Rust 编写，使用自己的 GPUI 框架，直接将 UI 渲染工作交给 GPU。结果是：滚动体验能达到 120 FPS，打开大型项目的速度比 VS Code 快数倍。当然，公司自测的数据不一定完全反映真实场景，但在我自己的低配 MacBook 上，差异确实显而易见。

真正让我留下来的：AI Agent 的“主场”体验

如果说速度是 Zed 的门票，那它对于 AI Agent 的原生支持，才是我决定留下来的原因。

2026 年，AI 编程助手已经成为开发工作流的一部分。Zed 没有像IDEA把 AI 当作一个“聊天窗口插件”，而是作为编辑器的核心能力来设计。

通过 Agent Client Protocol (ACP)，Zed 可以原生集成 Claude、Codex、Gemini 等多个外部 Agent。每个 Agent 都有独立的线程，在侧边栏里并行工作，彼此互不干扰——这些 Agent 可以分别运行在不同的项目、不同的 Git 工作树中，各自使用自己的模型配置和权限管理。

在并行 Agent 更新的基础上，Zed 还增加了对终端 Agent 的原生支持。Codex、Claude 等命令行 Agent 可以直接在 Agent 面板中运行，并与其他线程并列显示。

这意味着我可以同时让 Claude 处理一个模块的重构，Codex 测试另一个功能，而 Zed 自己的 Agent 则负责代码审查——所有的 Agent 活动都在同一个界面中清晰可见。这种“多 Agent 协作”的工作流，在 VS Code 中需要通过多个窗口或复杂的配置才能勉强实现。

切换的代价

当然，切换到 Zed 不是没有代价的。VS Code 最大的护城河是它的扩展生态。有些功能，比如 Live Share、高级 Git 集成、远程开发、更成熟的调试工具，VS Code 的体验确实更成熟。而且由于 VS Code 足够普及，它很可能是你团队正在使用的默认编辑器。

Zed 的扩展生态还在发展中。不过 Zed 把很多 VS Code 中需要扩展实现的功能（比如 Git 集成、AI 面板、多光标编辑）都做进了内核。大多数日常开发需要的功能已经原生可用。对我而言，还没遇到在 VS Code 里离不开、在 Zed 里找不到替代的扩展。当然，如果你依赖某些特定场景的扩展（如特定语言的调试器或数据库客户端），迁移前需要确认 Zed 是否已经支持。

谁适合尝试 Zed？

• 如果你的电脑性能有限，或者你受够了内存占用过高的烦恼，Zed 的轻量设计能给你直观的体验改善
• 如果你日常工作中频繁用到 AI 编程助手，Zed 的 Agent 原生集成可能会显著提升你的工作流效率
• 如果你愿意接受一个仍在成长的扩展生态，并乐于尝试新的工具和流程

而如果你需要稳定、庞大的社区支持和成熟的扩展体系，VS Code 在今天依然是最好的选择。

Zed 并不是要“杀死”VS Code，而是给开发者提供了一个新的选择——一个在性能和 AI 工作流上方向明确的选择。对于像我这样已经厌倦了 Electron“重量感”的开发者来说，它正在成为一个越来越有吸引力的答案。