為什麼我開始使用 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 生態的重複疊加,兩個是同一個擴充的不同版本沒清掉,還有幾個我根本想不起來當初為什麼裝。這種盤點平常不會做,只有換工具的時候會被強迫做一次。