Zed 1.0来了,我又开始想换编辑器了

我最近又开始动那个很危险的念头了。

换编辑器。

这事听起来很小，但对写代码的人来说，多少有点像搬家。不是把一个软件卸了再装一个软件那么简单。你要搬快捷键，搬插件，搬终端习惯，搬 Git 面板，搬自己那些已经长进手指里的肌肉记忆。

所以我看到 Zed 1.0 发布的时候，第一反应不是兴奋。

是烦。

不是哥们，怎么又来一个。

VS Code 我用了这么多年， Cursor 也已经变成很多 AI 编程任务的默认入口， Windsurf 的 Cascade 也能跑， JetBrains 那套 IDE 又稳得像一台老机器。你现在跟我说 Zed 1.0 正式发布了，速度很快， AI 很强，协作很丝滑。

我当然会心动。

但我也会警惕。

因为编辑器这个东西，演示视频里永远很美，真到自己项目里就开始露馅。某个插件没有，某个语言服务不稳，远程开发不顺，调试器一抽风，你立刻就会被现实按回 VS Code 。

折腾一圈，到头来还是回老房子。

不过这次我把 Zed 1.0 的发布文章、 Zed AI 、 ACP 、并行 agent ，以及 VS Code Copilot 、 Cursor 、 Windsurf 、 JetBrains Junie 的资料重新看了一遍之后，我有点改观。

Zed 1.0 不是又一个快编辑器。

它真正想抢的，是 AI agent 时代的工作台。

这个判断我觉得挺关键。

过去我们评价一个编辑器，基本看四件事。

快不快。

插件多不多。

语言支持稳不稳。

顺不顺手。

但 AI 编程开始之后，问题变了。你不只是一个人在写代码，你可能同时开着 Claude Code 、 Codex 、 Gemini CLI 、 OpenCode ，或者编辑器内置的 agent 。它们会读代码，会改文件，会跑命令，会解释报错，有时候还会很自信地把事情搞复杂。

这时候编辑器最重要的能力就不是补全那一行代码。

是管理现场。

哪个 agent 在改哪个文件？它刚才跑了什么命令？它有没有覆盖别人改动？我现在应该接手，还是让它继续？这个任务要不要单独切一个 worktree ？这几个问题单独看都不起眼，但连续干三个小时之后，你会发现它们才是最消耗人的地方。

AI 编程的问题，正在从模型能力问题，变成协作秩序问题。

Zed 1.0 很有意思的地方就在这里。

它当然补了很多基础能力。 2026 年 4 月 29 日， Zed 官方发布 1.0 ，强调 Mac 、 Linux 、 Windows 三个平台都进入正式叙事，也把 Git 、 SSH 远程开发、调试器、 Vim 模式、语言服务、编辑预测这些现代编辑器基本功放到台面上。

这一步很重要。

因为没有这些， Zed 再快也只是一个很漂亮的玩具。

但如果只看这些，你会低估它。

Zed 这次真正有野心的地方，是它把并行 agent 、 Threads 、每个线程的独立工作目录、以及 Agent Client Protocol 放在一个叙事里。 ACP 这个东西你可以先粗暴理解成，编辑器和不同 AI agent 之间的一套共同语言。 Zed 不想只服务自己的 agent ，它希望 Claude Code 、 Codex 、 Gemini CLI 、 OpenCode 这些不同 agent 都能接进来。

这有点像当年 LSP 对语言服务做过的事。

以前每个编辑器都要自己适配各种语言能力，累得要死。 LSP 出来之后，语言服务和编辑器之间有了一套共同协议，生态效率就起来了。

ACP 想做的，是 agent 时代的类似事情。

能不能成，另说。

但这个方向很对味。

说到这里，就必须把 Zed 和几个竞品放在一起看。单独看一个产品，容易被发布文章带着跑。放在一张桌子上，你才知道它到底在赌什么。

我先给一个很粗暴的结论。

Cursor 是最像现在答案的工具。

VS Code 是最难绕开的入口。

Windsurf 是最像完整 AI 工作流产品的编辑器。

JetBrains 是最稳的专业 IDE 阵地。

Zed 是最像下一代工作台的赌注。

这几个不是一个维度的强。

编辑器	最强的地方	最大的问题	最适合谁
Zed 1.0	快、协作底座、并行 agent 、 ACP 协议野心	插件生态和成熟度还要继续追	想把多个 agent 当工作现场管理的人
Cursor	AI 编程体验成熟，迁移成本低， VS Code 习惯能继承	越像 VS Code ，越背着 VS Code 的历史包袱	想立刻提高 AI 编程效率的人
VS Code	插件生态事实标准， Copilot agent mode 入口巨大	历史包袱重，体验越来越像一个超级平台	项目复杂、生态依赖重的人
Windsurf	Cascade 工作流感强，规则、工具调用、检查点比较完整	品牌和生态心智还在追赶	想要 AI 带着任务往前推的人
JetBrains	项目理解、重构、调试、语言深度很强	重， AI 体验不像轻编辑器那么灵	Java 、 Kotlin 、后端大工程用户

这张表不是为了让你直接选一个。

恰好相反。

它想说明，编辑器之争现在已经不是谁有一个更强的聊天框。

聊天框太多了。

今天每个产品都说自己能读代码库、能跑命令、能修 bug 、能生成测试、能接 MCP 。你看多了会麻。真正的问题是，当这些能力都开始普及之后，谁能把工作现场组织得更好。

这张图其实对应上面的判断。 Zed 不是在和 Cursor 抢同一块肉。 Cursor 更像是把 VS Code 的老房子重新装修，加了一个特别能干的 AI 同事。这个策略太聪明了，因为开发者最怕搬家。你打开 Cursor ，不需要重新学习世界，很多插件和操作习惯还能延续。

它降低的是尝试成本。

这就是 Cursor 爆得快的原因。

但 Cursor 的代价也在这里。它越像 VS Code ，就越要背着 VS Code 的结构往前跑。它可以把 AI 体验打磨得很顺，但底层工作台到底能不能彻底换一种形状，会被老生态牵住一部分。

Zed 正好反过来。

它没有 VS Code 插件生态这张船票，所以它不能只说我也有 AI 。它必须赌一个更长的东西。

赌未来的编辑器不只是插件市场，不只是 Copilot 面板，不只是一个聊天窗口。

赌未来的编辑器，是多人协作和多 agent 协作的同一个现场。

这个赌法很冒险。

也挺迷人。

因为你仔细想想，如果 agent 真的变成日常开发的一部分，那编辑器里最重要的界面可能不再是文件树，而是任务线程。最重要的单位可能不再是单个文件，而是一个可被隔离、可被追踪、可被回滚、可被人类接管的工作现场。

这就是 Zed 现在想讲的故事。

Zed 的 Threads 不是一个普通聊天记录。它更像任务现场。你可以让不同 agent 线程处理不同任务，必要时隔离到不同工作目录或仓库里。这个设计背后隐含着一个判断， AI 编程会越来越并行。

一个 agent 修测试。

一个 agent 做重构。

一个 agent 读陌生模块。

你在旁边盯着关键决策。

听起来很爽。

但也很容易乱。

所以我反而觉得，未来 AI 编程工具最重要的竞争点可能不是谁更会写代码，而是谁更少让你心慌。

这句话土，但很准。

你让 agent 改 README ，无所谓。你让它改认证模块，心跳就开始变快。你让三个 agent 同时改一个仓库，哪怕它们都很聪明，你也会有一种想伸手拔网线的冲动。

这真的挺烦的。

而且不是那种产品经理嘴里的挑战。

是你眼睁睁看着一个很聪明的东西在你项目里动刀，但你不知道它下一刀会落在哪里。

Zed 如果能把这件事做得清楚、快、可控，它就有机会。

如果做不到，那它可能就是一个很快、很漂亮、偶尔打开玩玩的编辑器。

中间没有太多温柔地带。

不过我不想把 Zed 吹成答案。

这也是我觉得很多 Zed 讨论容易失真的地方。有人会说它性能太强， Rust 写的， GPUI ， 120fps 。也有人会说生态不够，插件少， VS Code 能做的它还不能全做。

两边都对。

但都没说到最实际的那个问题。

你到底要拿它替代谁？

如果你现在重度依赖 VS Code 插件生态，尤其是小众语言、小众框架、小众工具链， Zed 1.0 可能还不是主力答案。因为你的生活已经被插件织成了一张网，搬家不是意愿问题，是成本问题。

如果你已经每天用 Cursor 写代码，而且 Cursor Agent 已经能稳定推进你的任务，那你也没必要为了新鲜感马上搬。 Cursor 现在还是非常强，尤其是它几乎不给你制造迁移阻力。

如果你是 JetBrains 老用户，写 Java 、 Kotlin 、后端大工程，靠重构、调试、项目索引吃饭，那 Zed 也很难一下替代那套 IDE 深水区能力。 JetBrains 的重是真的，稳也是真的。

如果你喜欢 Windsurf 的 Cascade ，喜欢它那种从理解任务到改代码再到检查点的推进感， Zed 也不一定立刻更顺。 Windsurf 更像把 AI 工作流包装成一个产品， Zed 更像在重做底层工作台。

所以我的建议不是换。

是分工。

这事可能更符合真实世界。

Cursor 继续当 AI 编程效率工具。

VS Code 留给生态复杂、插件依赖重的项目。

JetBrains 留给大型后端和重 IDE 场景。

Windsurf 用来跑那种连续任务流。

Zed 则可以先被放在一个更具体的位置。

轻快的代码阅读。

多 agent 并行试验。

不想被 VS Code 生态拖住的小项目。

以及你想观察下一代编辑器到底会怎么长出来的时候。

我画了一张很朴素的选择矩阵。它不是装饰图，是真的可以拿来判断你要不要试 Zed 。

这张图背后的逻辑很简单。

先别问哪个编辑器最好。

先问你的问题是什么。

如果你的最大痛点是插件生态，那别折腾， VS Code 大概率还是最稳。如果你的最大痛点是 AI 写代码效率， Cursor 依然是很现实的选择。如果你的任务更像一条连续工作流， Windsurf 值得留在候选里。如果你的项目是重型后端， JetBrains 不会因为 Zed 1.0 就突然失去价值。

只有当你的痛点开始变成另一个东西，你才应该认真看 Zed 。

那个东西叫现场管理。

你要同时调度多个 agent ，你要隔离任务，你要清楚每条线程在干什么，你想要一个快得没有存在感的编辑器，你不想把所有事情都塞进 VS Code 那个越来越厚的平台里。

这时候 Zed 才真正有意思。

我自己现在越来越觉得，未来开发者的工具栈不会只剩一个编辑器。

以前大家喜欢问， VS Code 和 JetBrains 选哪个。

后来问， Cursor 能不能替代 VS Code 。

现在这个问题可能要换一下。

不是选哪个。

是哪个任务交给谁。

刚才这句话我说得也有点绝对了。

更准确一点，是哪个任务先交给谁，出问题以后又退回哪里。

这很像现在的 AI 模型选择。你不会因为 Claude 会写长文，就再也不用 GPT 。你也不会因为 Codex 会改代码，就让它回答所有问题。你会慢慢形成一种手感，某类问题找某个工具，某类任务开某个环境。

编辑器也会这样。

Zed 1.0 的价值，不是让你今天宣布退坑 VS Code 。

它更像在提醒我们，编辑器这个老东西还没有结束。 AI 进来之后，战场被重新摊开了一次。

旧地图还在。

但边界开始潮湿。

我很喜欢这个状态。因为它说明我们还没被一个事实标准彻底锁死。 VS Code 当然强， Cursor 当然猛， JetBrains 当然稳， Windsurf 当然有自己的产品感。

但 Zed 1.0 这种东西出来之后，你会突然意识到，原来编辑器还能重新长一次。

这就挺让人兴奋的。

当然，兴奋归兴奋。

我不会建议任何人今晚就全量迁移。

工具迁移不是结婚。

更像借住。

先拿一个非核心项目住两晚。看看文件搜索、 Git diff 、终端、远程开发、调试器、语言服务是不是顺。再开两个 agent 线程试试，一个修测试，一个读模块。重点不是它一次写对多少，而是你能不能看清楚现场。

如果你越用越放松，说明它有戏。

如果你越用越想回家，也很正常。

身体会投票。

很多工具不是赢在第一次惊艳，而是赢在第三十次打开的时候，你的身体没有骂人。

Zed 1.0 现在终于走到了可以被认真投票的那一步。

这就已经不容易了。

所以我大概率会试。

但我不会把它当成替代品来试。

我会把它当成一个新工作台。

一个用来观察 AI agent 时代，代码编辑器到底会怎么变化的工作台。

如果它只是快，那还不够。

如果它让我在多个 agent 同时工作的时候少一点慌，多一点掌控感。

那就很有意思了。