企业官网建设流程全解析

如果你最近持续刷技术社区或 X，大概率已经被 Zed 刷过屏了。这个由 Atom 原班核心团队打造、使用 Rust 语言实现的编辑器，从开源第一天就以“启动速度极快、GPU 渲染、原生协作”三个标签吸引了大批开发者关注。我自己从第一次听说到真正把它用作日常主力编辑器，前后大约两个月。中间踩过不少坑，也研究过不少配置细节。这篇教程不追求堆砌术语，而是把从下载安装、基本配置到高频功能、AI 接入和问题排查的完整过程整理出来，给想从 VS Code 或其他编辑器切换过来、但不知道从哪下手的读者一份可以照做的参考。

Zed 适合什么样的人？如果你对编辑器启动速度敏感、喜欢 Vim 操作方式、希望一个工具里同时解决编辑、终端、协作和 AI 辅助，Zed 大概率会让你舒服。如果你重度依赖某个 VS Code 专属插件或者常年远程开发，那最好先看完第 6 章的踩坑清单再做决定。总之，这篇文章不负责劝你卸载任何东西，只负责把你需要知道的 Zed 点点滴滴讲清楚。

1. 为什么是 Zed：性能之外的四个理由

1.1 从 Atom 团队到 Zed：一脉相承的编辑器哲学

要理解 Zed，得先聊一段历史。Atom 是 GitHub 当年推出的编辑器，曾经有一批忠实用户，但后来被 VS Code 逐渐超越，最终在 2022 年退役。Atom 的核心成员在项目结束后并没有放弃“做一个更好编辑器”的想法，而是成立了公司，从零开始打造 Zed。这件事的背景很有意思：Atom 本身就是基于 Electron 的，本质上是套了一个浏览器内核，性能和内存占用始终被用户诟病。Zed 的诞生，某种意义上就是这群人对自己以前技术路线的“清算”——他们决定不再依赖网页技术，而是用 Rust 写一个真正的原生编辑器。

这段历史决定了 Zed 的很多设计选择。它不是一个“改了个皮肤的 VS Code”，而是从底层开始重新设计的作品。UI 层基于自研的 GPUI 框架，纯 native 渲染，不套浏览器，不背一整个 Electron 的体积。了解这一点，你就明白为什么 Zed 这么敢在性能上喊口号——那不是营销话术，而是技术路线决定的必然结果。

1.2 性能数字背后的底气：Rust 和 GPU 渲染

Zed 的启动速度有多快？以我自己的实测，在 macOS 上冷启动通常在 1 秒以内，热启动基本是“点一下图标就出现窗口”的级别。相比 VS Code 平均 3~5 秒的启动时间，这个差距在日常使用中非常明显。真正让 Zed 拉开差距的不只是启动速度，还有滚动和编辑的顺滑度。它把整个编辑器界面理解为 GPU 可以绘制的图形，光标移动、代码滚动、语法高亮都交给 GPU 管线处理，而不是像传统编辑器那样在 CPU 上逐行计算布局。

这一点在打开大文件、长代码行很多的项目时体验尤其明显。我用它打开过一个几万行的 Rust 工程，光标在代码里上下移动依然流畅，不会出现普通 Electron 编辑器那种“卡一下然后跳过去”的迟滞感。同时，Zed 把很多操作设计成多线程并发执行，比如文件索引和 LSP 语言服务器分析，不会堵住 UI 线程。用聊天的方式解释：VS Code 像是在浏览器里开了一个大型网页应用，页面元素越多越容易卡；Zed 则像是一个精心优化的游戏客户端，界面上每帧元素都是 GPU 直接绘制，性能自然不在一个量级。

1.3 协作、AI 与编辑深度整合的产品观

Zed 不只是把编辑器本身做快了，它还在产品理念上赌了一条“未来开发环境”的路。Zed 内置了名为 Channel 的协作功能，你可以创建频道、邀请队友加入，大家在同一份代码上实时看到彼此的光标，甚至可以语音沟通。这比“远程共享屏幕”或者“开一个会议然后各自改代码”的体验好得多。这个功能不是插件商店里的某个扩展，而是编辑器主体的一部分，所以协作的延迟控制和稳定性都更有保障。

AI 也是同样的思路。Zed 没有走“插件市场里装一个 AI 助手”的路线，而是把 AI 面板、内联补全和代码重构指令直接做进编辑器核心。实际使用下来，这种“原生集成”的好处是 AI 可以更自然地读取当前文件、当前选中内容甚至整个工作区上下文，不需要像 VS Code 扩展那样做一堆剪贴板交互。Zed 的产品观很清晰：编辑器是开发环境的中枢，协作和 AI 不是外挂，而是这个中枢的原生能力。

1.4 和 VS Code、Cursor 相比的真实差距

当然，Zed 也不是没有短板。最直观的一点是插件生态和 VS Code 还不在一个量级。VS Code 的扩展市场里有几万个插件，几乎什么冷门语言、工具链都有对应的支持；Zed 的扩展中心目前还是以主题和语言包为主，深度定制类的扩展正在发展但尚未完全成熟。Cursor 是另一条路线，它基于 VS Code 的生态，把 AI 能力深度封装进编辑器，比如 Chat、Composer、代码库索引等。Zed 的 AI 是原生自研的，但目前的丰富度对比 Cursor 还有距离，两者解决的问题侧重点不同。

我的建议是：判断自己该不该用 Zed，核心就看两点——第一，你是否依赖“非 VS Code 不可”的插件；第二，你是否需要成熟的远程开发方案。如果这两个问题的答案都是“否”，Zed 能给你带来的速度和集成体验非常值得一试。

2. 从下载到跑起来：三个平台的安装实操

2.1 macOS：命令行一行搞定

macOS 上安装 Zed 最方便的方式是使用 Homebrew：

brew install --cask zed

如果你没有安装 Homebrew，去官网下载 dmg 文件直接拖进 Applications 目录也是一样的效果。第一次启动时会弹提示问是否安装zed命令行工具，建议选“是”，这样后续在终端里就能随时用zed .打开当前目录，或者zed README.md打开指定文件。

安装完成后，建议先把命令行别名确认一下。在终端执行which zed，如果输出/Applications/Zed.app/Contents/MacOS/zed或类似路径，说明安装成功。接下来直接zed .打开一个已有项目即可。首次打开项目时，Zed 会做索引，后台会自动下载当前语言需要的 LSP 语言服务器。这个步骤需要联网，如果你的网络环境受限，之后打开文件可能没有代码提示，后面我会专门讲这个的排查。

2.2 Windows：安装包和 winget 两种方式

Zed 对 Windows 的支持最近已经比较成熟，官方提供了安装包，也支持 winget 命令行安装：

winget install Zed.Zed

不想用命令行的话，去 GitHub 的 Releases 页面下载 exe 安装程序，双击安装就行。安装过程中没太多需要自定义的选项，一路下一步即可。装完第一次启动后，同样建议在命令面板里确认是否安装命令行工具，Windows 上一般会自动处理好 PATH。

有一点需要提醒 Windows 用户：Zed 的 daily 版本更新非常频繁，功能迭代快但偶尔也会引入一些小的不稳定问题。如果不是为了体验最新特性，建议用稳定版（Stable）而不是 daily 版。我自己在 Windows 上主要做 TypeScript 开发，日常使用的是稳定版，体验已经足够顺滑。

2.3 Linux：脚本安装与 AppImage

Linux 上的官方安装方式是一行脚本：

curl -f https://zed.dev/install.sh | sh

这个脚本默认会把 Zed 安装到~/.local/bin，并自动添加 PATH。如果你的发行版没有把~/.local/bin加入 PATH，需要手动在~/.bashrc或~/.zshrc中加一行：

export PATH="$HOME/.local/bin:$PATH"

如果脚本下载失败或者网络太慢，可以去 GitHub Releases 下载 AppImage 文件，但使用 AppImage 需要系统装有 FUSE 运行库。Ubuntu 等常见桌面发行版一般自带，但精简版的 WSL 或者某些无桌面环境服务器可能没有装。如果运行时报fuse: device not found之类的错误，先通过发行版包管理器安装 FUSE 再试。

2.4 安装后的第一件事：确认 LSP 是否正常拉取

刚装完 Zed 后，我希望你先别急着配置主题，先花两分钟做一次“健康检查”。任选一个项目目录，用zed .打开，然后打开一个 Python、TypeScript 或 Rust 文件，观察编辑器的状态。如果代码有语法高亮、有智能提示、有错误提示，说明 LSP 已经正常工作。这是判断 Zed 是否完全可用的关键一步，因为 Zed 的很多智能功能都依赖 LSP。

如果打开文件后发现没有任何提示，大概率是 LSP 下载失败或网络拦截。Zed 会在后台下载对应语言的 Language Server，比如 Python 的 Pyright、TypeScript 的 typescript-language-server、Rust 的 rust-analyzer。你可以打开命令面板输入language server之类的关键词，查看当前文件对应的语言服务器状态。如果确实没起来，先检查网络，再考虑手动安装对应的独立 LSP 工具。很多语言服务器本身就是独立的可执行程序，Zed 也会尝试优先使用系统已有的。

3. 第一份 settings.json：把编辑器调成自己的形状

3.1 配置文件在哪里，为什么用 JSON

Zed 的配置方式非常“程序员化”：不是一堆图形化勾选框，而是一个 JSON 文件。这样做的好处有两个：一是配置即代码，你可以把配置放进自己的 dotfiles 仓库，换电脑或者重装系统后一键恢复；二是 Zed 的配置项非常多且细，JSON 格式表达起来更简洁直接。

配置文件的位置：

• macOS 和 Linux：~/.config/zed/settings.json
• Windows：%APPDATA%\Zed\settings.json

如果你找不到这个文件，不用慌——首次安装后它不一定存在。按Cmd+Shift+P（Windows 是Ctrl+Shift+P）打开命令面板，输入zed: open settings，Zed 会帮你创建好目录和文件并打开编辑器。配置文件保存后立即生效，不需要重启编辑器，这一点比改完配置还要重启大半天的某些 IDE 舒服太多。

3.2 主题、字体、行号和自动保存：先合眼缘

以下是一份我目前在所有机器上都会使用的基础配置，不算花哨但非常实用：

{ "theme": "One Dark", "ui_font_size": 14, "buffer_font_family": "JetBrains Mono", "buffer_font_size": 13, "tab_size": 2, "relative_line_numbers": true, "autosave": "on_focus_change" }

逐个说明一下我为什么这么配：

• theme：Zed 默认内置了多款主题，One Dark、Gruvbox Dark、Solarized 等都有。如果你喜欢更现代的风格，可以去扩展中心搜更多主题。主题可以在命令面板里输入theme selector快速切换，试了一圈之后再把最终喜欢的写进 JSON。
• buffer_font_family：代码字体。我用 JetBrains Mono 很久了，宽窄均匀、区别度高。如果你的系统装了 Fira Code，Zed 支持连字（Ligature）显示，可以在配置里开启相关字体特性。
• relative_line_numbers：相对行号。配合 Vim 模式和命令跳转很实用，让我能不依赖行号插件，更快定位上下文。
• autosave：我选的是on_focus_change，意思是当编辑器窗口失去焦点时自动保存。这样我切换到浏览器或终端的时候，代码已经保存好了，不担心忘记保存。

3.3 开启 Vim 模式，一个决定性的配置

如果你习惯 Vim 的键位，这一项绝对是 Zed 最酥服的体验之一。在 settings.json 里加一行：

"vim_mode": true

保存后，Zed 立刻变成 Vim 风格：h/j/k/l移动、dd删除、ciw改词、u撤销、Ctrl+[回到普通模式，这些操作全都原生支持。关键和 VS Code 里装 Vim 插件不一样的是，Zed 的模式逻辑是在编辑核心层面实现的，不是模拟按键，所以在普通模式、插入模式、可视模式之间切换没有任何延迟感，也不会出现插件被某些弹窗吃键位之类的烦人问题。

开启 Vim 模式后，Zed 原有的快捷键仍然可用，比如Cmd+Shift+P打开命令面板，Cmd+P切换文件。你可以在普通模式下顺手执行编辑器功能，不用像某些编辑器那样还得先把 Vim 插件禁用才能用原生快捷键。如果你是从 Neovim 切过来的，建议再加一条：

"vim_use_system_clipboard": true

这样删除、复制的内容直接进系统剪贴板，和终端里复制粘贴互不冲突。

3.4 针对不同语言配置 LSP 和格式化工具

Zed 对每种语言都会给出默认的 LSP 和格式化方案，但如果你想自定义，可以在配置里加一个languages字段。举个例子：

{ "languages": { "Python": { "language_servers": ["pyright", "ruff"], "formatter": "ruff format" }, "TypeScript": { "language_servers": ["typescript-language-server"], "formatter": "prettier" } } }

这个配置的含义是：编辑 Python 文件时，Zed 会同时用 Pyright 做类型检查和补全、用 Ruff 做 lint 检查，并用 Ruff 来格式化代码；编辑 TypeScript 时则使用 typescript-language-server 和 Prettier。这些工具如果系统已经装好了，Zed 会直接调用；如果没有，Zed 会尝试自动安装。这个自定义能力解决了很多开发者的核心痛点：不同团队、不同项目往往有自己固定的 lint 和 format 工具，Zed 能够尊重项目内的约定。

4. 高频功能实测：从模糊搜索到多光标编辑

4.1 命令面板与文件切换器：键盘驱动的核心

Zed 的日常工作流高度依赖键盘。我每天最常按的几个组合键如下：

文件切换器是我个人感知最强的一个功能。VS Code 的 Ctrl+P 已经很好了，但 Zed 给我的感觉是结果出现得更快，而且搜索排序更贴合我的使用习惯。你还可以在文件切换器里输入:行号直接跳转，比如输入app.ts:120会直接打开 app.ts 并定位到第 120 行。全局搜索同样很快，几万行代码的项目搜索关键词，结果几乎是秒出的。日常开发中“切换文件 + 全局搜索 + 命令面板”三件套占了我 80% 的导航操作，Zed 这三件套的响应速度确实让人心情愉悦。

4.2 多光标和批量修改：高频编辑场景不拖后腿

批量修改代码是编辑器使用频率最高的操作之一。Zed 的多光标功能非常顺滑：

• 按住Alt再点击鼠标，可以在多个位置放置光标，随后同时输入。
• 选中一个词后按Cmd+D，会选中下一个相同词，继续按直到覆盖你要修改的所有位置。
• 使用Cmd+Shift+L可以一次性选中当前文件中所有和选中内容一致的片段。

这几种操作结合起来，重构一个重复出现的函数名、批量给一组变量加上前缀、同时修改多处类似的错误，效率提升非常明显。再加上第 3 章提到的 Vim 模式，你可以用.命令重复上次修改，这让很多重复性操作几乎可以盲操作。在我个人的体验里，Zed 的多光标和批量修改响应速度比 VS Code 要快一档，尤其是在大文件里快速选中多处相同内容时，没有明显的卡顿或延迟。

4.3 内置终端与任务系统：少切换窗口就是少打断

开发过程中最打断思路的事情，就是在编辑器和终端之间来回切换。Zed 内置的终端面板虽然不算惊艳，但胜在跟编辑器“同一个进程”：你可以在终端里敲命令、看构建日志、跑测试，不用离开编辑器窗口。终端支持多开，每个终端有独立的标签；终端的字体和背景默认跟随 UI 主题，不会显得突兀。

任务系统（Tasks）是比终端更进一步的集成。你可以在项目根目录创建.zed/tasks.json文件，定义一组常用任务：

[ { "label": "run dev server", "command": "npm run dev" }, { "label": "run tests", "command": "cargo test", "tags": ["cargo"] } ]

然后在命令面板里输入task关键词，就能看到并运行这些任务。任务的输出会显示在单独的 Task 面板中，和交互式终端分开。这样构建日志和手动敲的命令各自有各自的面板，不用在一个终端窗口里翻来翻去找上一次的报错在哪。对 Rust 项目尤其舒服，cargo test和cargo run分别配成一个任务，平时切换运行目标只需要调命令面板。

4.4 扩展中心目前的真实情况：能装什么、什么还不能装

在下载任何编辑器之前，你最担心的往往是“我需要的插件有没有”。Zed 的扩展中心用命令面板输入zed: extensions或zed: install extension打开。目前质量较高的扩展主要围绕两类：主题和语言包。比如更丰富的代码高亮、额外的 LSP 配置、各种配色主题等。

至于更复杂的扩展，比如 GitKraken 风格的图形化 Git 工具、自定义侧边栏组件、特定的代码片段库插件等，目前还比较有限。好消息是 Zed 内置了很多功能，比如 Git 面板、文件树、终端的 diff 视图，这些在 VS Code 里往往需要组合多个插件才比较好用，Zed 直接给做进了主体。如果你用的语言和工具链足够主流，Zed 开箱即用的体验其实已经很好；但如果你是那种“没有 XX 插件就不会写代码”的选手，建议先查一下你要的插件有没有对应的 Zed 扩展或者替代方案，再考虑迁移。

5. AI 功能接入指南：从云模型到本地模型

5.1 内置 AI 面板：聊代码、改代码、解释代码

Zed 的 AI 功能天然内置，没有插件安装的步骤。在命令面板输入assistant: new thread可以打开一个 AI 对话面板，之后你可以选中一段代码，直接问“这段代码有什么问题”“帮我把这段函数改成异步风格”“解释一下这个循环的作用”之类的自然语言指令。AI 会结合当前文件甚至工作区的上下文来回答，这是它比在浏览器里开 ChatGPT 粘代码更顺手的地方。

AI 能力大致分三层：

• 内联补全：编辑时给出灰色建议，按 Tab 接受。
• 聊天式问答：AI 面板中和代码上下文对话。
• 内联编辑指令：在代码区域直接用自然语言发出修改指令，AI 会自动生成 diff。

这些功能需要用 Zed 账号登录或者配置自己的模型服务才能用。Zed 官方提供的托管 AI 服务很方便，但它更偏向“开箱即用订阅制”；如果你是国内网络环境，或者想省钱、重视数据隐私，更推荐自己配置一个 OpenAI 兼容接口。

5.2 配置 OpenAI 兼容模型的思路

Zed 的 AI 功能支持 OpenAI 兼容协议，因此“任何提供 OpenAI 风格 API 的服务”理论上都可以接。常见的开源模型网关（One API、New API）、云厂商提供的兼容端点、本地推理框架（Ollama、LM Studio、vLLM）都可以通过这个思路接入。

在 settings.json 里大致这样配置：

{ "assistant": { "enabled": true, "provider": "openai", "openai": { "base_url": "https://your-endpoint.example.com/v1", "api_url": "https://your-endpoint.example.com/v1", "model": "your-model-name", "api_key": "your-api-key" } } }

这里的base_url和api_url指向 OpenAI 兼容接口的地址，model换成你实际要用的模型名，api_key填对应的密钥。有的版本只需要填base_url和api_key就能工作，多余字段写上也无妨。需要注意的一点是：Zed 的 AI 配置字段在不同版本迭代较快，如果你在编辑 settings.json 时看到字段名被划横线或者提示不存在，以当前版本编辑器内提示为准。

5.3 把本地 Ollama 模型接进 Zed：免费方案的实操路径

对于大多数人来说，“免费使用 AI”是最关心的需求。你的机器上跑一个 Ollama，然后让 Zed 指向本地服务的 OpenAI 兼容端口，整个过程不需要花一分钱。

第一步，确认 Ollama 已经装好并且拉取了对应模型。以我用的qwen2.5-coder:7b为例：

ollama serve ollama pull qwen2.5-coder:7b

第二步，确认 Ollama 的 OpenAI 兼容接口可用。默认情况下，Ollama 会在http://127.0.0.1:11434/v1地址提供 OpenAI 风格的 API。设置好环境变量或者直接写进 Zed 配置：

{ "assistant": { "enabled": true, "provider": "openai", "openai": { "base_url": "http://127.0.0.1:11434/v1", "api_url": "http://127.0.0.1:11434/v1", "model": "qwen2.5-coder:7b", "api_key": "ollama" } } }

第三步，重启 Zed 或重新打开 AI 面板，测试对话是否响应。如果配置正确，AI 面板会走本地模型，速度取决于你 CPU/GPU 的性能。我实测下来，7B 级别的量化模型在 M1 Pro 上用 GPU 加速跑，内联补全的速度基本跟得上打字节奏。

如果你希望内联补全也能生效，可能还需要查看当前版本是否有额外的开关，比如：

"show_inline_completions": true

总而言之，把任何本地推理框架当作 OpenAI 兼容服务暴露出来，再指给 Zed，是一种通用的有效方案。如果你想换更大模型，比如 13B 或 32B，只要你的显存管够，把model名字换掉就行。

5.4 关于 AI 配置的实操提醒

免费方案和云方案在使用体验上有明显差异。本地 7B 模型做简单的解释、补全绰绰有余，但回答复杂架构问题时会显得“不太聪明”。我的建议是：把本地模型用于内联补全和简单问答，遇到复杂问题再切到云端的强模型。双模型并行不一定需要 AI 功能本身支持，你完全可以多配一个 provider 或在不同对话中切换不同模型。

另外，一个实际的使用经验：在 AI 面板提问时，尽量选中相关代码块再问。不要让它基于一大坨不相关的文件内容生成回答，否则噪音会很大，回答质量明显下降。代码补全也一样，如果你的工作区非常庞大且复杂，Zed 会在后台读取大量上下文，本地小模型的处理时间会变长，这时候缩小工作区范围或者把模型 context 长度调小，响应速度会明显改善。

6. 踩坑清单：安装和使用中我遇到的真问题

6.1 Linux 下启动失败，多半是 GPU 驱动和 Vulkan 的事

Zed 在 Linux 上最让人头疼的一点是依赖 GPU 渲染，而 Linux 的图形栈恰恰是最容易出幺蛾子的。常见的报错包括启动后窗口空白、闪退，或者终端提示找不到 Vulkan 相关的动态库。我的排查顺序是：

1. 确认显卡驱动是否安装完整。NVIDIA 用户检查nvidia-smi是否正常输出；Intel/AMD 核显或入门显卡确认 mesa 和 vulkan 相关包是否已安装。
2. 如果启动即闪退或黑屏，先尝试软件渲染方式启动：

LIBGL_ALWAYS_SOFTWARE=1 zed

或者根据报错提示设置其他环境变量。软件渲染能启动，说明问题大概率在 GPU 驱动上，而不是 Zed 本身。 3. 如果用的是精简版桌面环境，缺少一些图形库也会导致类似问题。这时候用发行版的包管理器补装基础图形库，比如mesa-utils、libvulkan1等，是最稳妥的。

Zed 官方对 Linux 的支持还在不断打磨中，但最近几个版本已经明显稳定了。如果不想折腾驱动，推荐优先考虑 Ubuntu 系的发行版，图形栈问题相对少。

6.2 中文输入法失效：Wayland 下的一条典型处理路径

这是 Linux 用户高频踩坑点：在 Zed 里按英文键没问题，切到中文输入法后啥都打不出来。根源在于 Zed 的 GPUI 自绘界面和输入法框架（尤其 fcitx5）之间的适配在 Wayland 下还不够完美。我实测比较有效的方案：

1. 确认 fcitx5 的 Wayland 支持是好的。重新加载输入法：

fcitx5 -r

2. 检查环境变量GTK_IM_MODULE、QT_IM_MODULE、XMODIFIERS是否指向 fcitx，必要时在启动 Zed 前手动设置。
3. 如果仍然不行，尝试让 Zed 以 X11 模式运行，比如在 Wayland 会话里借助 XWayland 运行 Zed。虽然这绕了一圈，但很多情况下输入法立刻恢复正常。

macOS 上我用原生中文输入法没有任何问题；Windows 上 Win10/11 自带的微软拼音在 Zed 里也一切正常。中文输入法的问题主要还是集中在 Linux，特别是新版本刚发布时偶尔出现回归，建议关注 Zed 的 Release Notes。

6.3 远程开发：Zed 目前最明显的一块短板

VS Code 用户最习以为常的 Remote-SSH、Dev Containers 这类远程开发工作流，Zed 目前的官方支持比较弱。我在服务器上做 Go 开发时，曾经想全程用 Zed，但最后还是回到 VS Code 处理远程场景。社区有一些第三方方案，比如类似 remote Zed 的实现，但整体成熟度、稳定性和 VS Code 的 Remote-SSH 差距不小。

如果你和我一样平时 80% 时间在本机开发，只是偶尔去远程服务器看一个文件、跑一个脚本，那完全可以用 Zed 应付。但如果是常年远程开发，最好还是别强求，甚至不用急着切换。Zed 官方已经把这个列为重点发展方向，我相信以后会越来越好，但目前不要因此影响生产力和心情。

6.4 一组零碎的日常使用心得

最后分享一些零碎但很实用的经验：

• 大项目首开时 Zed 会做文件索引，大多数时候很快；但如果你用的是互联网磁盘或老式机械硬盘，索引期间可能会有一点资源占用，耐心等一下就好。
• 不要在同一台机器上同时装 Stable 和 Daily 版并反复切换配置，两个版本的配置格式偶尔不兼容，容易出现“上次能用这次不能”的怪问题。
• 自动保存建议开着，用on_focus_change是既不打扰、又能兜底的好选择。
• Zed 的 Git 面板内置的 diff 视图很好用，支持暂存、丢弃和逐行操作，不再需要单独打开一个 Git GUI。
• 遇到配置项拿不准的时候，直接打开zed: open settings，编辑器内会有字段提示和默认值参考，比去翻文档更快。

按我个人现在的使用习惯，日常本机开发主力已经变成了 Zed，特别是 Rust、TypeScript、Python 这些语言的项目，启动快、Vim 模式顺手、AI 辅助也不拖后腿。遇到需要远程调试或者重度依赖 VS Code 插件的地方，我很自然地切回 VS Code。工具是服务于工作的，给自己设一个“只用一把锤子”的执念没有必要。希望这篇保姆级教程能帮你顺利把 Zed 跑起来，少踩一些我已经替你踩过的坑。