为什么我开始使用 Zed 编辑器

Zed 团队的上一个作品是 Atom。

Atom 当年是 Chromium 的 fork,而开发它的过程顺手生出了 Electron——也就是后来 VS Code 的地基。讲难听一点,VS Code 站的那块地是这群人自己挖的,而他们现在在旁边盖了一栋不用那块地基的房子。

Zed 的 1.0 是 2026 年 4 月 29 日才发布的,五年、一百多万行 Rust。

我从 微软大战代码 Microsoft VS Code 搬过去的理由没那么浪漫,是我某次把伺服器搞到 96°C 之后,顺手量了一下这东西在我机器上到底放了什么。

先看帐单#

本机这一侧,同样开着一个专案:

伺服器那一侧差距更大。远端开发会在伺服器上留一份自己的 runtime,而 VS Code 那份长这样:

7.9 GB 对 107 MB,七十倍。

拆开来看 VS Code 那 7.9 GB:cli 3.2 GB、bin 2.9 GB、extensions 945 MB、data 412 MB。而且我在里面翻到两个版本的 rust-analyzer 扩充同时躺着,旧的那份没被清掉。

老实说光这组数字就足以说服我试试看,而实际用起来的顺畅度也对得上——滑动、开档、搜寻、切分页都是即时的,没有那种「等它想一下」的顿挫感。

官方有一条正式的搬家路径#

这是我原本不知道、后来才发现的:Zed 有一整页官方的 How to Migrate from VS Code to Zed,而且第一次启动的设定精灵就会问你要不要汇入 VS Code 设定、以及要整合哪家 AI。

错过精灵也没关系,命令面板里叫得出来:

它搬什么、不搬什么#

官方文件列了完整的对照表,节录几条:

涵盖分页、档案总管、Git、终端、字型和大部分编辑器偏好。

但它不搬扩充,也不搬键位绑定。 这两件事得自己来。

键位:预设就已经是 VS Code#

base_keymap 的预设值本来就是 VS Code,所以什么都不用做。想确认或改成别的:

{ "base_keymap": "VSCode" }

可选的有 VS Code、Atom、Emacs(Beta)、JetBrains、Sublime Text、TextMate、Cursor,以及 None。也可以在设定视窗里选,或用命令面板的 zed: toggle base keymap selector。

日常最常按的那几个完全一样,Ctrl + Shift + E 开档案列表、Ctrl + Shift + G 开 Git,手指不用重练。

官方文件有列「即使选了 VS Code 键位还是不一样」的几个,但那张表是用 macOS 的写法写的,而且两栏的平台还不一致,直接照抄会很困惑:

Windows 和 Linux 上 Cmd 要换成 Ctrl。Zed 的键位定义里有个 secondary- 就是在处理这件事。真的要查,直接看官方 repo 里各平台的预设键位档比较准。

更方便的做法是用内建的 Keymap Editor(Ctrl + K 再 Ctrl + S),里面列出所有动作和目前绑定的键,可以直接改,改完会同步写回 keymap.json。

23 个扩充,搬完剩 8 个#

这是整趟里最有感的一段。我在 VS Code 上装了 23 个扩充,而搬到 Zed 之后真正需要「安装」的只剩 8 个。

不是因为功能变少,是分类方式不一样。

basedpyright   bash-language-server   eslint   json-language-server
package-version-server   ruff   rust-analyzer   tailwindcss-language-server
vscode-css-language-server   vtsls   yaml-language-server

官方自己对这件事讲得很坦白,而且正好命中我少掉的那几个:

Zed does not offer as many extensions as VS Code. You won't find one-to-one replacements for every VS Code extension, especially if you rely on tools for DevOps, containers, or test runners.

反过来,官方也列了「在 VS Code 要装扩充、在 Zed 是内建」的:即时协作(不用 Live Share)、AI 辅助、终端面板、全专案模糊搜寻、task runner、LSP 诊断。

设定:有 GUI,而且比我想的完整#

我原本以为 Zed 只能改 JSON,写到一半才发现不是。Ctrl + , 开出来是一个完整的设定视窗,有搜寻框、有分类、有开关和下拉选单:

十五个分类,而且每一项旁边都有「Edit in settings.json」可以直接跳去改原始档。GUI 和 JSON 是同一份设定的两个入口,不是二选一。

想直接编档案的话,命令面板的 zed: open settings file,或是 Ctrl + Alt + ,。

专案层级的设定少很多#

这是实际用起来会撞到的一个限制。设定视窗上方可以切换范围,而切到专案那一格之后,分类从十五个掉到五个:

专案设定放在专案里的 .zed/settings.json,而能放进去的只有编辑器行为和语言工具那类(tab_size、formatter、format_on_save 之类)。

所以像「只有这个专案要关掉 auto_fold_dirs」或「只有这个专案关掉 Auto Reveal」这种需求,目前只能改全域。我一个 VS Code 重度使用者的同事第一个撞到的就是这个。

面板位置#

顺带记一下,面板要换边不用去翻设定——在面板图示上按右键就有:

也可以在 settings.json 里把每个面板的 dock 写死,我就是这样固定的。

我的设定,可以直接抄#

排版和配色如果你喜欢,整份拿去改就好。远端连线那段我拔掉了,留注解范本:

{
  // base_keymap 预设就是 VSCode,这行只是写明
  "base_keymap": "VSCode",

  // CLI 开档案时进现有视窗,不要每次都开新的
  "cli_default_open_behavior": "existing_window",

  // 远端连线(把 host 换成你 ~/.ssh/config 里的别名)
  // "ssh_connections": [
  //   {
  //     "host": "my-server",
  //     "args": [],
  //     "projects": [
  //       { "paths": ["/home/you/projectA"] },
  //       { "paths": ["/home/you/projectB"] }
  //     ]
  //   }
  // ],

  // 面板位置
  "project_panel": { "dock": "left" },
  "git_panel": { "tree_view": true, "dock": "left" },
  "collaboration_panel": { "dock": "left" },
  "outline_panel": { "dock": "right" },
  "agent": { "sidebar_side": "right", "dock": "right" },

  // 外挂 agent(下一节会讲这是什么)
  "agent_servers": {
    "claude-acp": {
      "type": "registry",
      "default_config_options": { "fast": false }
    }
  },

  // 外观
  "theme": {
    "mode": "dark",
    "light": "Gruvbox Light",
    "dark": "Catppuccin Macchiato - No Italics"
  },
  "icon_theme": {
    "mode": "dark",
    "light": "Zed (Default)",
    "dark": "Material Icon Theme"
  },
  "ui_font_size": 16,
  "buffer_font_size": 15,
  "minimap": { "show": "always" },

  "telemetry": {
    "diagnostics": true,
    "metrics": false,
    "anthropic_retention": false
  },

  // 远端专案每次开都要按信任很烦,但这等于全部 worktree 都信任,自己斟酌
  "session": { "trust_all_worktrees": true }
}

两个地方值得多说一句:telemetry.metrics 我关掉了,session.trust_all_worktrees 开了之后很方便但等于放弃那道确认,要自己权衡。

介面上的差别#

VS Code 到处都是按钮,例如档案总管标题列那排新增档案、新增资料夹、重新整理、全部收合:

Zed 的方向相反,大部分操作都走命令面板和右键。刚开始会觉得少了什么,习惯之后手不用离开键盘。

老实说整趟搬家最大的成本就是这个——不是功能,是习惯。真正的功能落差只有少数几个(后面会列),而前两天的不顺几乎都是肌肉记忆还没改过来。

远端开发#

这是我换编辑器的起点,所以讲细一点。

远端专案直接写在设定档的 ssh_connections 里,host 填你 ~/.ssh/config 的别名就好,金钥、跳板、Port 那些都交给 SSH 自己处理,Zed 不另外管一套。

冷启动到能开始写程式:

第一次连线它会把 remote server 丢上去(就是前面那 107 MB),之后那支是常驻的,所以再连就很快。我这台的 remote server 行程已经连续跑了七天。

断线比 VS Code 稳很多#

这是我没预期到的收获。VS Code Remote-SSH 在网路品质不好的时候常常要重连、重载视窗,有时候还会卡在「Reconnecting...」不动;Zed 这边同样的网路环境下重连失败的次数明显少很多,大多数时候是无感接回去。

同一个视窗切换远端专案#

这个功能 VS Code 没有。 VS Code 开第二个远端专案就是开第二个视窗,分页和视窗会愈叠愈多;Zed 可以在同一个视窗里直接换,视觉上干净很多。我自己满喜欢这点。

内建的 Git 比我预期的完整#

我原本以为要找 GitLens 的替代品,结果不用。Git 面板可以切成树状,commit 历史和 diff 都在编辑器里:

行内 blame 也是内建的,滑过去就有卡片:

Markdown 预览有渲染 mermaid#

这个我一开始担心过,因为我写文章大量用 mermaid,而在 VS Code 那边是靠扩充撑的。结果 Zed 的内建预览直接就会画:

ACP:把 agent 从编辑器里拆出来#

这一段是我换过来之后才碰到的东西,也是这篇最想写的部分。

ACP 的定位讲得很直接:

LSP 把「语言智慧」从 IDE 里拆了出来,ACP 要对「agent」做同一件事。

在 LSP 之前,每个编辑器都要自己实作每种语言的补全和跳转;LSP 出现之后,语言方写一次 server,所有编辑器都能用。ACP 想解决的是同一个形状的问题:现在每个 AI agent 都要为每个编辑器各写一套外挂,而 ACP 让 agent 写一次就好。

目前 JetBrains、Google、GitHub 都加入了,注册表上有二十五个以上的 agent。第一次启动 Zed 的设定精灵就会问你要整合哪一家。

它长这样#

设定里加上 agent server 之后,agent 就出现在侧边栏:

注意右下角那排:Opus (1M context)、High、Fast mode。

这排是重点,因为它解释了 ACP 的分工。 官方文件是这样写的:

Zed hosts the thread in the Agent Panel, while the External Agent usually owns its own runtime, auth, model selection, tools, and native configuration.

所以模型选择、认证、工具、设定全部是 agent 自己的,Zed 只出借介面——thread 显示、多档编辑、专案上下文、diff review 这些。

我一开始的疑问是「走 agent panel 跟直接用 CLI,模型会不会不一样」。查了半天查不到答案,后来才想通:这个问题本身问错了。ACP 根本不碰模型,两边跑的是同一个东西。

旧对话可以汇进来#

这个功能藏得有点深,但很实用。按 Ctrl + Alt + J 开 Threads Sidebar,再按 Ctrl + G(或点左下角那个时钟图示)开 Thread History:

里面有一个 Import Threads 按钮。

选好要汇入的 agent 之后,Zed 会透过 ACP 去抓那个 agent 在本机留下的旧 session,补进你的历史纪录里。汇进来的是封存状态,打开就能接着聊。重复汇入是安全的,已经在历史里的会自动跳过。

Terminal Threads:两边其实可以不用选#

我原本以为「用原生 agent panel」和「在终端里跑 CLI」是二选一,后来发现 Zed 已经把这个问题解掉了。

Terminal Threads 让你在 Agent Panel 的 + 选单里选 Terminal,开出来的终端机会变成 Threads Sidebar 里的一个 thread。在里面跑 claude、amp、codex 或任何东西都可以,侧边栏的标题还会跟着跑的程式自动更新。

它可以跟 Zed 自己的 agent thread、ACP thread 混着开,键盘导览和通知都一样。等于保留 CLI 原本的环境和额度,同时拿到 Zed 的介面。

但我还是把 CLI 放在一般终端机里#

理由只有一个:

/rc(remote control)只有 CLI 有。

差别不在功能多寡,在谁拥有 session:

我的用法是让 CLI 每次开 session 就自动 /rc。这样不管人在哪,用 Claude Desktop 开一个分页就能接管同一个 session,不需要那台电脑开着 Zed。

影片里那个 Resume session (2 of 27) 的挑选画面就是这个机制:session 是独立于编辑器存在的东西,编辑器只是其中一个入口。

换句话说,我放弃的是比较整合的 UI,换到的是不被任何一台机器绑住。如果你没有跨机器的需求,agent panel 或 Terminal Threads 都更顺手,我不会劝退。

缺什么#

这节是给正在考虑要不要换的人看的。我自己撞到的加上查到的,大致是这些:

反过来,Dev Container 在 2026 年 1 月已经支援了。网路上比较早期的 Zed 评测常常把它列在缺点里,那条现在可以划掉了——这也是下一节要讲的事。

繁体中文的社群方案#

官方看起来还没有要动工,但社群有 zed-i18n 这个专案。

它不是完全无痛:会少掉一些功能,而且要额外设定。我同事写过一篇处理 Windows 11 右键选单的踩坑纪录,要装的话建议先看过:

但这份清单的保鲜期很短#

上面那些缺失我不太担心,理由是时间轴。

Zed 开源到现在没几年,而 1.0 是 2026 年 4 月 29 日才发布的——五年开发、一百多万行 Rust。它现在几乎每周都在出新版,我写这篇的过程中就遇到两次「查资料时说没有,实际打开发现已经有了」:设定 GUI 是一次,Terminal Threads 是另一次。Dev Container 也是今年一月才补上的。

而它敢这样快,跟底层有关。Zed 团队在 1.0 那篇文章里把来龙去脉讲得很清楚:

Atom 是 Chromium 的 fork,并在过程中催生了 Electron,而 Electron 后来成了 VS Code 的地基。网页技术让出货变简单,但也设下了一道天花板——不管我们多努力,都没办法让 Atom 超越它所依附的平台。

所以他们重来一次,把整个编辑器当成一款游戏来写:资料喂给 GPU 上的 shader,UI 框架 GPUI 从零自己刻。前面那个「4 GB 对 200 MB」不是最佳化调出来的,是一开始就没有背那个包袱。

对 Rust 开发者特别友善#

这点我私心加的,因为我自己写 Rust。

Zed 本身就是 Rust 写的,团队等于是自己的重度使用者。不过讲清楚:下面这些不是为 Rust 特制的,是整条 LSP 路径的工程,只是 rust-analyzer 出了名的重,所以刚好最吃这些。

所以结论要说得准一点:rust-analyzer 没有变快,吃记忆体照样吃。变的是它旁边那个编辑器不再是额外的一份负担——而这在远端开发上,就是全部的差别。

万物皆可 Rust,这次我没有意见。

我没有把 VS Code 删掉#

写到这里看起来像在推销,那我就直说:这篇确实偏向推荐 Zed,因为那组资源数字太有说服力,而且实际用起来真的顺很多。

但我两个都留着,分场合:

• 在家走内网 — VS Code Remote-SSH。同网段延迟低,扩充和熟悉的介面都在,而且人就在机器旁边,真的烧起来我看得到也关得掉。
• 在外面长时间连 — Zed 加 Claude CLI。远端延迟会让 VS Code 那套变得很难用,而且上一篇那三个把机器烧到 96°C 的凶手全都是「连着连着它自己烧起来」的类型,人不在现场正是最糟的状况。

会这样分,是因为我发现这两个工具的成本结构不一样,而我刚好有两种很不一样的使用情境。

至于要不要换,我的看法是:如果你被 VS Code 绑得不深,那障碍主要是习惯而不是功能。 我不是重度使用者,没有一堆非某个扩充不可的工作流,所以搬起来几乎没有痛。但如果你每天要用 File Nesting、要开资料库、要按专案调一堆设定,那现在的 Zed 还接不住你。

真要说搬家最大的收获,反而不是省下来的那几 GB,是被迫把 23 个扩充重看一遍。其中五个是 Python 生态的重复叠加,两个是同一个扩充的不同版本没清掉,还有几个我根本想不起来当初为什么装。这种盘点平常不会做,只有换工具的时候会被强迫做一次。