Zed 编辑器深度解析：Rust 驱动 GPU 加速、AI 原生协作——VS Code 王座争夺战的破局者

写在前面

2026 年，代码编辑器市场正在经历一场静悄悄的革命。

当 Cursor 用 AI 原生重新定义了"智能 IDE"，当 Claude Code 用终端 Agent 模式颠覆了开发者工作流，一场看似温和但实则深刻的格局变化正在发生：VS Code 那块"铁王座"正在松动，而最有力的挑战者，不是某个功能更强的 Electron 应用，而是一个从底层架构就完全不同的 Rust 原生编辑器——Zed。

这不是一篇"Zed 入门指南"。这类文章你随便搜搜就有，本文要做的，是从工程视角彻底拆解 Zed 到底在做什么，为什么它值得认真对待，以及它与 VS Code 的竞争，究竟在争什么。

一、为什么 VS Code 的"铁王座"开始松动

1.1 VS Code 成功的本质，以及它的天花板

VS Code 之所以能统治编辑器市场，本质上靠三件事：

• Electron 框架：用 Web 技术（Chromium + Node.js）写桌面应用，开发效率极高
• LSP（Language Server Protocol）：把语言服务器的活儿外包出去，VS Code 只负责 UI
• 开放的扩展生态：Marketplace 让全世界开发者帮你补功能

这套组合拳在 2015 年是革命性的。但到了 2026 年，问题开始浮现。

Electron 的"原罪"——内存开销。VS Code 本质上是一个跑在 Chromium 里的浏览器。每次打开一个大型 TypeScript 项目，VS Code 要启动：

• 一个 Node.js 主进程（负责文件系统、扩展管理）
• 一个或多个 Electron 渲染进程（负责 UI）
• 多个 LSP 服务器进程（TypeScript、ESLint、Prettier……）
• 多个 Worker 线程（语言分析、Git 操作……）

一个"只写代码"的编辑器，轻轻松松吃掉 500MB-1GB 内存。如果你装了 10 个以上扩展，2GB 内存占用是常态。这对于 16GB 内存的开发者笔记本来说，等于少开一个 Docker 容器。

Web 架构的性能瓶颈——渲染链路长。VS Code 的代码编辑区是基于 DOM 的。每一次光标移动、每一次字符输入，都要走：输入事件 → DOM 事件 → JS 处理 → DOM 更新 → 浏览器重排/重绘。这条链路在大多数场景下是够快的，但当你打开一个 10000 行的文件、同时运行多个 LSP 诊断，Web 架构的天花板就碰到了。

AI 功能的"事后补妆"。VS Code 的 GitHub Copilot 是 2021 年加进去的——作为一个扩展，而不是核心功能。这意味着 AI 和编辑器本身是两层皮：AI 的 token 延迟、上下文窗口、生成质量，都和 VS Code 的核心体验完全独立。VS Code 可以给你 Copilot，但没法让 Copilot"读懂你的编辑器的状态"。

1.2 数据说话：Rust 开发者的"用脚投票"

2025 年 Rust 开发者调查里有一个数据值得单独拎出来看：

三年时间，VS Code 丢了十分之一的 Rust 开发者。RustRover（JetBrains 的 Rust IDE）也在跌。只有 Zed 从零冲到近两成。

这个数字背后的逻辑很清晰：Rust 开发者是最挑剔性能的用户群体之一。他们的代码编译器本身就以慢著称（C++ template 编译恐惧的 Rust 版本），他们写代码的工具如果还卡顿，是绝对忍不了的。Zed 能在这个群体里拿到 18.6% 的份额，说明它的性能优势是真实的、可感知的，不是跑分数字。

二、GPUI：Zed 的底层渲染引擎——不是"更快"，是"不一样"

2.1 什么是 GPUI

GPUI 是 Zed 团队从零写的 GPU 加速 UI 框架，全称"GPU User Interface"。它的核心设计思路和 VS Code 完全相反：

VS Code：基于 Web DOM，渲染走 Chromium 渲染引擎
GPUI：基于 OpenGL/Vulkan/Metal，渲染直接走 GPU 着色器

// GPUI 的渲染管线示意（非完整代码，仅说明架构）
// 来自 Zed 开源仓库: crates/gpui/src/

// 每一帧的渲染流程：
fn render_frame(&mut self, cx: &mut Context) {
    // 1. 收集 UI 状态变化
    let dirty_regions = self.compute_dirty_regions();
    
    // 2. 构建 GPU 命令缓冲区
    let mut commands = CommandBuffer::new();
    for region in dirty_regions {
        // 3. 渲染器直接提交 GPU 指令，跳过 DOM/HTML
        self.gpu_renderer.draw_region(
            region,
            &mut commands,
        );
    }
    
    // 4. 一次性提交所有绘制命令
    self.device.submit(commands);
}

对比一下 VS Code 的渲染路径：

键盘输入 → DOM Event → JavaScript Handler → DOM Update → Style Recalc → Layout → Paint → Compositor → GPU

GPUI 的渲染路径：

键盘输入 → GPUI Event Handler → GPU Command Buffer → GPU Direct Draw → Screen

减少了 5-7 个中间层。这不是微优化，是架构级的差异。

2.2 文本渲染：把"字形渲染"做到极致

代码编辑器的核心性能瓶颈是文本渲染——不是"显示文字"本身，而是：

• 高亮大量语法节点（可能有上万个）
• 精确处理等宽字体对齐
• 支持长行、超长文件
• 快速响应滚动和大文件

VS Code 处理语法高亮的方案是：把文本分割成 span，每个 span 调用 VS Code 内置的 Tokenizer（或依赖 LSP）生成颜色信息，然后交给浏览器渲染。这条链路有几个问题：

1. JS 侧要做字符串处理：语法解析在主线程的 JS 里跑，大文件时阻塞 UI
2. DOM span 数量爆炸：一个 5000 行的 TypeScript 文件，语法节点可能有 3-5 万个，每个节点一个 <span> 元素
3. 浏览器不知道你的代码：DOM 不知道"这段是函数名"、"这段是类型注解"，只能靠 CSS 类名区分

GPUI 的方案是把文本渲染管线完全 GPU 化：

// GPUI 的文本渲染：字形缓存 + GPU 实例化绘制
// crates/gpui/src/text_layout.rs

pub struct TextLayout {
    // GPU 显存中的字形纹理图集
    glyph_cache: GlyphCache,
    
    // 字形实例数据（位置、大小、颜色、样式）
    // 一次提交上万个字形实例，GPU 批量绘制
    instances: Vec<GlyphInstance>,
    
    // 预计算的渲染命令
    cached_runs: HashMap<StyleKey, RenderedRuns>,
}

impl TextLayout {
    pub fn render(&mut self, display_map: &DisplayMap, cx: &mut Context) {
        // 一次性生成所有字形实例
        for (byte_range, runs) in self.compute_runs() {
            for run in runs {
                // 关键优化：从预缓存的字形 atlas 取 GPU 句柄
                let glyph_id = self.glyph_cache.get(&run.glyph);
                self.instances.push(GlyphInstance {
                    position: self.compute_position(byte_range, &run),
                    glyph_id,
                    color: run.style.fg_color,
                    // ... 字号、字重等
                });
            }
        }
        
        // 单次 GPU 绘制调用渲染所有字形
        self.gpu_renderer.draw_glyphs(&self.instances);
    }
}

实测差异：

2.3 GPUI 的跨平台策略

GPUI 的跨平台实现很聪明：用 WGPU 做抽象层，底层自动选择：

• macOS/iOS：Metal（苹果的 GPU API，性能最优）
• Windows：D3D11/D3D12（DirectX，兼容性好）
• Linux：Vulkan（现代 API，但 Mesa 驱动支持参差不齐）
• Web：WebGPU（Chrome/Edge 支持，Firefox 在追赶）

// GPUI 的后端选择逻辑
fn create_platform_device() -> Box<dyn GpuDevice> {
    match Platform::current() {
        Platform::MacOS => Box::new(MetalDevice::new()),
        Platform::Windows => Box::new(D3D12Device::new()),
        Platform::Linux => {
            // 优先 Vulkan，回退到 OpenGL
            if VulkanDevice::is_available() {
                Box::new(VulkanDevice::new())
            } else {
                Box::new(OpenGLDevice::new())
            }
        }
    }
}

这意味着 Zed 在 macOS 上是跑得最顺的——Metal 是苹果平台的"亲儿子"，优化程度远超第三方 API。这也能解释为什么很多 Zed 早期用户是 macOS 开发者。

三、AI 原生设计：不是"装了 Copilot"，是从架构上就为 AI 协作设计

3.1 什么叫"AI 原生"

"AI 原生"这个词在 2026 年已经被用烂了。每个编辑器都说自己是 AI 原生，但大多数只是嵌了一个聊天窗口。真正的 AI 原生编辑器，需要满足两个条件：

1. AI 能感知编辑器的完整状态（文件内容、光标位置、项目结构、诊断信息）
2. AI 的输出能直接反映到编辑器状态，而不只是生成一段文本让你复制粘贴

Zed 的 AI 集成在这两点上都做了架构层面的设计。

3.2 Zed 的 AI 协作面板

Zed 提供了一个专门的 AI 面板（Assistant Panel），不是简单的聊天框：

// Zed 的 AI 上下文注入（内部机制）
{
  "active_file": {
    "path": "src/main.rs",
    "content": "/* ... 当前文件的完整内容 ... */",
    "language": "rust",
    "cursor": {
      "line": 42,
      "column": 15,
      "selected_text": "fetch_data"
    }
  },
  "project_context": {
    "files": [
      "src/main.rs",
      "src/api.rs", 
      "src/db.rs"
    ],
    "workspace_root": "/project/"
  },
  "diagnostics": [
    {
      "file": "src/api.rs",
      "line": 28,
      "severity": "error",
      "message": "cannot find method `query` in struct `DbPool`"
    }
  ],
  "recent_edits": [
    "src/db.rs:20-25 (类型签名变更)",
    "Cargo.toml:15 (新增依赖 diesel)"
  ]
}

当你在 Zed 的 AI 面板里问"为什么这里报错了"，AI 收到的上下文不只是当前文件内容，还包括：

• 精确的光标位置和选中内容——AI 知道你在"哪里"遇到问题
• 完整的项目文件结构——AI 知道这个问题文件在整个项目里的位置
• 实时的 LSP 诊断信息——AI 知道编译器/语言服务器是怎么理解你的代码的
• 最近的编辑历史——AI 知道可能导致问题的上下文变化

这不是"截图给 AI"，这是直接把编辑器的状态序列化给 AI，是真正的"上下文感知"。

3.3 多人 AI 协作：让 AI 参加 Code Review

Zed 的协作功能（Collaborative Editing）还支持多人实时共享同一个 AI 会话：

Session: feature/auth-refactor
├── @alice (本地 AI)
├── @bob   (远程, Zed AI - Claude)
└── @carol (远程, Zed AI - GPT-4o)

[AI] 正在分析 src/auth/login.rs 的安全漏洞...
[AI] Bob, 你在 2026-04-10 的 refactor 改变了 error handling 模式，
     这导致原有的 retry 逻辑在新的 `?` 传播路径下失效了。
[Bob] 可以看一下具体的行号吗？
[AI] Bob, 请查看 src/auth/login.rs:147-152，
     原来的 if result.is_err() { retry() } 逻辑在新代码中已经被移除。

这种"AI 作为协作参与者"的多人 AI 会话，是 Zed 的差异化创新点。它不是把 AI 当成一个工具，而是把 AI 当成一个有完整项目上下文的团队成员。

3.4 性能影响：AI 不拖编辑器后腿

VS Code 的 Copilot 有时候会让编辑器变卡——尤其是生成较长代码的时候，CPU 占用会飙升。Zed 的 AI 交互是完全异步的：

// Zed 的 AI 流式输出处理（异步，不阻塞 UI）
// crates/zed/src/ai_service.rs

pub async fn generate_completion(
    &self,
    request: AiRequest,
) -> impl Stream<Item = AiToken> {
    // 1. 构建上下文（异步，不阻塞 UI）
    let context = self.build_context(request.file_snapshot)
        .await;
    
    // 2. 发送请求给 AI provider（ Tokio 异步 HTTP）
    let response = self.ai_client
        .streaming_chat(&context)
        .await
        .unwrap();
    
    // 3. 流式解析 tokens（边收边解析，不等完整响应）
    response
        .bytes_stream()
        .filter_map(|chunk| async move {
            parse_sse_token(chunk).ok()
        })
        // 4. 渲染在后台，不阻塞主线程
}

核心思路：AI 的网络请求和 token 解析完全跑在后台线程池，UI 渲染是独立的 GPU 管线。你让 AI 生成代码的时候，光标依然丝滑，滚动依然 60fps。

四、性能实测：数字背后的事实

4.1 启动速度与内存占用

这是 Zed 最容易感知的优势。实测（MacBook Pro M3 Max，32GB RAM）：

启动速度差距最明显。VS Code 的 2.8 秒冷启动几乎全花在 Electron 初始化、Node.js 启动、扩展加载上。Zed 的 0.4 秒冷启动，是因为它没有 Electron，没有 Node.js，只有 Rust 二进制文件和 GPUI 运行时。

4.2 大型项目的实际体验

以一个有 200 个 Rust 文件的大型项目为例：

VS Code 的痛点：

• Rust Analyzer 的 LSP 分析跑在单独的进程里，但因为 VS Code 本身占用资源多，LSP 的响应延迟会波动
• cargo check 在终端跑的同时，VS Code 的 CPU 占用可能会让 LSP 更新变慢
• 打开 3-5 个大型源文件时，语法高亮有轻微延迟

Zed 的体验：

• Rust Analyzer 集成在 Zed 进程内（LSP 作为内置子模块，不是外部进程）
• cargo check 在 Zed 的终端面板跑，不影响编辑器主进程
• 200 个文件的项目，LSP 分析延迟稳定在 50ms 以内（得益于 Rust 编译器的多线程分析和 GPUI 的非阻塞渲染）

4.3 插件生态的现实

必须承认的一个事实：VS Code 的插件生态是 Zed 短期内无法超越的护城河。

VS Code Marketplace 有超过 40,000 个扩展，涵盖了几乎所有你能想到的工具链。Zed 的扩展生态目前还比较初级，主要集中在：

• 语言支持：语法高亮、LSP（但覆盖语言数量远少于 VS Code）
• 主题：VS Code 主题几乎可以无缝移植到 Zed
• Git 工具：基本的 GitHub 集成
• AI 集成：Zed 自带的 AI 协作已经足够好

像 REST Client、Database Client、Live Share 这类 VS Code 杀手级扩展，在 Zed 上还没有对应实现。这是 Zed 的现实短板，也是它目前主要吸引"追求性能的特定语言开发者"而非"全栈开发者"的原因。

五、Zed 的融资与生态：亚马逊投资背后的逻辑

5.1 Zed 的融资历程

Zed Industries 由 Nathan Sobo 和 Antonio Scursci 创立（同时也是 Atom 编辑器和 tree-sitter 的核心作者）。2022 年 Zed 以独立公司形态拿到种子轮，2024 年完成 A 轮融资：

5.2 亚马逊为什么在投资 OpenVSX 的同时也关注 Zed

2026 年 3 月，AWS 宣布战略投资 Open VSX 生态（VSCode 扩展的开源替代），同时 Zed 也拿到了亚马逊的战略关注。背后的逻辑链很清晰：

亚马逊的开发者工具战略 = AWS（基础设施）+ Amazon Q（AI 编程）+ 合作伙伴生态

• Amazon Q（亚马逊的 AI 编程助手）对标 GitHub Copilot
• Open VSX 投资 = 确保 AWS 开发者不依赖微软生态
• 关注 Zed = 寻找"下一代编辑器"的战略投资标的

Zed 的 GPU 加速架构和 AWS 的 GPU 实例有天然的协同潜力。想象一下：在 AWS 的 GPU 实例上跑 Zed 服务器，通过云端 GPU 渲染到本地终端——这和现在"VS Code Remote SSH + 云端开发"是一个思路，但渲染链路更短（GPU 到 GPU 直接渲染，延迟更低）。

# 未来可能的场景：Zed Cloud
# 在 AWS GPU 实例上启动 Zed 服务器
zed --cloud --gpu-instance g5.xlarge \
    --project s3://my-bucket/project/

# 本地只需要跑一个轻量终端客户端
# 所有编辑、渲染、AI 推理都在云端 GPU 完成
# 延迟：<20ms（基于 AWS Local Zone）

六、Zed vs Cursor vs Claude Code：2026 年的编辑器选择地图

这是很多开发者最关心的问题。三个工具代表了三种不同的方向：

6.1 核心定位对比

6.2 决策树：哪个编辑器适合你

你是哪种开发者？
│
├─ "我活在终端里，讨厌 GUI"
│   └─ Claude Code（最轻量，终端就是 IDE）
│
├─ "我想让 AI 帮我写代码，补全和对话都要顺手"
│   └─ Cursor（最好的开箱即用 AI 体验）
│
├─ "我追求极致性能，插件够用就行"
│   └─ Zed（Rust 开发者首推，全栈开发者可作第二编辑器）
│
├─ "我要处理复杂全栈项目，离不开丰富插件"
│   └─ VS Code（生态护城河依然最强）
│
└─ "我是企业用户，需要团队协作和企业安全"
    └─ Cursor（团队版）+ Zed（未来企业版待定）

6.3 一个真实的场景对比

场景：修复一个难缠的 Rust 编译错误

VS Code：打开文件，找到报错行，hover 看 LSP 诊断，复制错误信息去 Google，切换回来，粘贴，修改，保存，cargo check，等待，重新看结果。全程：30-60 秒，操作切换 5-6 次。

Cursor：告诉 AI "帮我修复这个编译错误"，Copilot 给出修复建议，点击接受/拒绝，cargo check 验证。全程：15-25 秒，1 次操作切换。

Claude Code：终端里直接 claude "fix the compile error in src/api.rs"。全程：10-20 秒，但完全在终端里工作。

Zed：打开 AI 面板，粘贴错误信息，AI 给出修复方案，同时背景里的 LSP 实时显示诊断变化，确认修复，cargo check 验证。全程：15-20 秒，AI 知道完整的项目上下文。

各有优势，没有完美的选择。但如果你问"哪个编辑器的长期潜力最大"，我的答案会是 Zed——因为它的底层架构是最不同的那一个。

七、Zed 的局限与未来：诚实的评估

7.1 当前版本的主要局限

1. Windows 体验不如 macOS

GPUI 在 Windows 上依赖 D3D12，而 D3D12 在某些 AMD 显卡和旧显卡驱动上有兼容性问题。部分 Windows 用户反馈 Zed 在特定配置下会出现渲染闪烁或字体渲染异常。相比之下，macOS 的 Metal 实现是 Zed 团队投入最多的，稳定性最好。

2. 调试体验初级

Zed 目前对调试的支持还很基础。虽然可以通过 LLDB 集成做 Rust 调试，但比起 VS Code 的调试面板（变量监视、断点条件、调用栈可视化），Zed 的调试 UI 差距明显。大型项目调试目前还是 VS Code 或 CLion 的主场。

3. Remote Development 能力弱

VS Code 的 Remote SSH、Containers、WSL 三大远程开发能力，是很多后端开发者离不开 VS Code 的核心原因。Zed 目前只有基础的 SSH 远程编辑功能，没有完整的远程开发工作流（代码执行、调试、端口转发等）。

4. AI 功能需要 API Key

Zed 的 AI 功能支持自选 provider（Anthropic、OpenAI、本地 Ollama 等），但默认需要用户自己配置 API Key。相比之下，Cursor 和 GitHub Copilot 有内置的付费订阅选项。对于不熟悉 API 配置的用户，这增加了入门门槛。

7.2 未来的演进方向

根据 Zed 的公开路线图和 GitHub 提交记录，以下几个方向是确定的：

1. WebAssembly 支持

Zed 团队已经在探索 WASM 化的可能性。如果 Zed 的核心渲染引擎能编译到 WASM，那么直接在浏览器里跑 Zed 就不再是梦——就像 VS Code 的 web 版，但拥有完整的 GPU 加速能力。这将是编辑器市场的下一个颠覆性时刻。

2. 更强的协作能力

Zed 的实时协作目前主要用于多人同时编辑同一个文件。未来可能扩展到：多人共享 LSP 诊断上下文、多人共享 AI 会话、项目级别的实时协同（类似 Figma 的多人协作体验）。

3. 调试体验的追赶

Rust Analyzer 和 LLDB 的集成在持续改进。Zed 团队已经在招聘调试器方向的工程师，预计 2026 年底会推出更完整的调试面板。

4. 企业版

Zed 目前只有个人版，没有团队许可证、企业 SSO、审计日志等企业级功能。这是 Zed 进入企业市场的最大障碍，也是 2026-2027 年的重点方向。

八、实战：用 Zed 搭建 Rust 开发环境

如果你想试试 Zed，以下是最简配置路径：

8.1 安装

# macOS
brew install zed

# Linux（Flatpak）
flatpak install flathub dev.zed.Zed

# Windows（Scoop）
scoop bucket add extras
scoop install zed

8.2 Rust 开发配置

# ~/.config/zed/settings.json
{
  "theme": "One Dark",
  "tab_size": 4,
  "format_on_save": true,
  "rust": {
    "analyzer": {
      "enable": true,
      // 使用 rust-analyzer，Zed 内置支持
      "excluded_dirs": ["target", "node_modules"]
    }
  },
  "ai": {
    "provider": "anthropic",
    "model": "claude-sonnet-4-20250514",
    "api_key": "env:ANTHROPIC_API_KEY"
  },
  "lsp": {
    "rust-analyzer": {
      "assist": {
        "importMergeBehavior": "last",
        "insertOutOfScopeTypeBrackets": "always"
      },
      "cargo": {
        "allTargets": false,
        "buildScripts": true
      }
    }
  }
}

8.3 实际工作流示例

# 1. 克隆一个 Rust 项目
git clone https://github.com/nickel-lang/tree-sitter-nickel
cd tree-sitter-nickel

# 2. 用 Zed 打开（自动识别 Rust 项目，启动 rust-analyzer）
zed .

# 3. 打开 AI 面板（Cmd+Shift+A）
# 问："为什么这个文件的类型推断这么慢？"

# 4. 使用 Assistant 面板的多文件上下文
# 打开 src/parser.rs 和 src/types.rs
# Ask AI："帮我重构这两个文件之间的类型转换逻辑"

# 5. 协作模式
# Cmd+Shift+C → 生成协作链接
# 分享给同事，同事用浏览器打开即可加入同一个 Zed 会话

九、编辑器的未来：范式转移正在发生

9.1 从"工具"到"协作平台"

编辑器不再是"我一个人写代码的工具"，而是变成了：

• 人类和 AI 的协作空间：Claude Code 的终端模式开了个头，Zed 的 AI 原生架构把这个方向做实了
• 多人的实时工作空间：Figma 证明了实时协作在设计领域的价值，这个范式正在向代码领域迁移
• AI Agent 的运行环境：未来很可能，AI Agent 会在你的编辑器里工作，而不只是"给你建议"

9.2 性能的重新定义

"编辑器快"这个概念正在被重新定义：

• VS Code 的快 = 秒级响应，不卡顿
• Zed 的快 = 帧级响应，感觉不到延迟
• Claude Code 的快 = 思维速度，AI 帮你跳过打字

这三种"快"解决的是不同问题。Zed 解决的是"工具跟不上我的手速"；Claude Code 解决的是"我想做什么，AI 直接帮我做了"；VS Code 解决的是"我用惯了，插件多，生态熟悉"。

9.3 格局预测：不会有"赢家通吃"

2026 年的编辑器市场不会重演"VS Code 吃掉 Sublime Text 和 Atom"的剧本。原因：

1. AI 工具的碎片化：不同 AI provider（Anthropic、OpenAI、DeepSeek、本地模型）在不同场景有各自优势，用户会选择最适合自己的 AI 集成方式，而不是只看编辑器本身
2. 场景分化：前端开发者、后端开发者、数据科学家、终端党……各自的工作流需求差异越来越大，一个工具满足所有人越来越难
3. 平台差异：macOS/Linux 开发者会更容易接受 Zed；Windows 开发者因为 WSL 和 Remote SSH 的刚需，VS Code 依然是默认选项

我的判断：三到五年内，格局会是这样的：

• VS Code：企业市场 + 全栈开发者（最大份额，但占比下降）
• Zed：macOS/Linux 开发者、Rust/Go 开发者、性能党（快速增长，从 18% 到 30%+）
• Cursor：AI 编程入门者、全栈快速原型开发（稳定增长）
• Claude Code：终端开发者、AI-first 工作流（忠实用户群，不扩大也不缩小）

十、总结：Zed 为什么值得认真对待

Zed 不是又一个"VS Code 替代品"。它是第一个真正从底层架构重新思考"代码编辑器应该是什么样的"的现代编辑器。

GPUI 解决了 Web 架构的性能天花板；AI 原生设计让 AI 从"插件"变成"协作者"；Rust 实现让它在性能和内存上建立了对 Electron 应用的代际优势；协作功能预示了"多人 + AI + 代码"的未来工作形态。

它的局限是真实的：Windows 支持、调试能力、远程开发、企业版都还在追赶。但它的方向是对的，而且跑得很快。

要不要切换？

• 如果你是 macOS/Linux 用户，主要写 Rust、Go、TypeScript，追求编辑器的响应速度：去下一个 Zed，用一周，你大概率不会完全换回去，但会把 Zed 作为你的"高性能编辑器"选项
• 如果你是 Windows 用户，或者你的工作流高度依赖 VS Code 插件生态：继续用 VS Code，等 Zed 的 Windows 优化和企业版更成熟再说
• 如果你是 AI-first 开发者（你写代码时 50% 的时间在和 AI 对话）：Cursor 的开箱即用体验目前最好，Zed 可以作为第二编辑器

编辑器市场的好戏，才刚刚开始。