Zed 编辑器 2026 评测：速度优先，AI 为辅

我们在过去几个月里，一直在实际项目中日常使用 Zed——包括一个大型 TypeScript monorepo 和几个较小的个人项目——最初是因为好奇它宣称的"最快编辑器"，后来则是因为它已经赢得了一个永久的位置，与我们的其他工具并列。

这里呈现的是真实体验：Zed 并不打算在 AI 方面超越 Cursor。它想要做的是成为最快、最轻量的工作环境，无论有没有 AI 驱动都是如此。这是一个不同的赌注，而且大多数时候它赌赢了。

速度不是营销话术

在我们的机器上，冷启动时间约在 0.4–0.6 秒之间，而基于 VS Code 的编辑器冷启动需要 1.2–1.3 秒。空闲时内存占用在 150–250MB 范围。在我们的大型 monorepo 上，Zed 稳定在 200–400MB 左右，而 Cursor 在索引激活后稳定在 500–800MB。

这不是跑分页上的数字——而是"从不让你等待的编辑器"和"偶尔会让你感受到它在思考的编辑器"之间的差别。

更有意思的赌注：不自己做 AI，而是托管它

Zed 自带的编辑器内 Agent 面板功能相当——多文件编辑、MCP 工具支持、编辑预测能力不错（虽然没有 Cursor Composer 那么深入）。但真正让 Zed 与众不同的功能是 Agent Client Protocol（ACP）：一个开放标准，让你可以用 Claude Code、Codex CLI 或 Gemini CLI 作为实际驱动编辑器的 Agent，diff 会以内联方式渲染，而不是在终端面板中滚动过去。

如果你已经习惯在终端里用 Claude Code 或 Codex CLI，这正是你不知道自己想要的那种升级——同样的 Agent、同样的模型，但文件编辑会作为真正的内联 diff 出现在编辑器 UI 中，而不是一整面终端文本。ACP 从设计上就是与 Agent 无关的，所以 Zed 并没有把整个产品押注在某一个厂商的模型会永远保持领先上。

原生的人类协作，不只是 AI 对话

Zed 将实时多人协作编辑——共享光标、语音聊天、同一文件中的真正协同编辑——作为核心功能交付，而不是后期加上的扩展。我们在两台机器上结对修复了一个 bug，感觉更接近 Google Docs 而不是屏幕共享。这是一个 Cursor 完全不竞争的领域；它的协作故事完全是面向 AI 的。

在哪些方面它仍然输给 Cursor

Composer 将多文件 Agent 编辑作为一个成熟、自包含的系统来处理，而且 Cursor 的标签补全能预测多行代码块，并具备项目特定模式感知——两者都依赖持续更新的代码库索引。Zed 自带的 Agent 面板并不打算达到那样的深度，实际上也确实没达到。如果你想要最深度的内置 AI、零外部配置，Cursor 仍然领先。

扩展生态市场也比 VS Code 小——主流语言（TypeScript、Rust、Python、Go）用起来很扎实，但某个小众的 VS Code 扩展可能还没有 Zed 等效实现。

个人（免费）：完整编辑器，每月 2,000 次编辑预测接受额度，如果自带 Agent 或 API key 则无限制。

Pro（$10/月）：无限编辑预测，包含 $5 的托管 AI 额度，超出后按 API 列表价格 + 10% 计费。

商业（$30/席位/月）：全组织模型策略、数据治理、RBAC、统一消费可见性。

因为编辑器本身从不强制要求订阅，如果你提供自己的 Agent 或 API key，免费版实际上可以用于日常工作中——不是被阉割的试用版。

它真正适合谁

Zed 适合以下场景：你所在的代码库中编辑器延迟真的拖慢了你的速度、你已经在运行外部 Agent 且想要一个更快的原生归宿、你需要真实的人与人协作，或者你想要一个可以审查的完全开源的编辑器。如果你想要最深度的内置 AI 且零配置——那仍然是 Cursor——或者你依赖某个 Zed 市场还没有等效实现的小众 VS Code 扩展，它可能不适合你。

评分：4.0/5。完整评测、优缺点分析以及与 Cursor 的对比：devtoolsreview.com/reviews/zed-review