同步至个人站点：我把默认的 code . 换成了 zed .
本期唠嗑。
我已经把默认的 code . 换成了 zed .。
说来话长。
从我接触编程开始，除了最早学 C 语言的时候用过 Dev-C++，后面无论是前端、Node、Python，还是 Go、Rust，我基本一直都在用 VS Code。
中间当然也试过别的 IDE，比如 GoLand、PyCharm。客观来说，它们确实强，尤其是在对应语言生态里，很多功能做得很完整。但我总是用了几天就切回 VS Code。
原因也简单：笨重，且不习惯。
VS Code 对我来说一直是一个很舒服的平衡点：轻量、快捷、生态好。它不像传统 IDE 那样一上来就给你一整套巨大的工程体系，更像是一个文本编辑器，再加上一套成熟到离谱的插件系统。
你写前端，它可以。 你写 Node，它可以。 你写 Python，它可以。 你写 Go、Rust，它也可以。
所以在相当长的一段时间里，我其实都是 VS Code 粉。不是信仰粉，而是很实用主义地觉得：它确实好用。
AI IDE 用着用着，感觉有点不对了
最近这一年多，我陆续接触了不少 AI IDE。Cursor、Windsurf、Trae 之类。
它们的方向当然是对的。现在我也很难回到完全没有 AI 辅助的开发状态了。无论是 Copilot、Claude Code、Codex，还是别的 agent，本质上都已经改变了我写代码的方式。
但问题在于，用着用着我总觉得有点拧巴。。
懂的都懂。
很多产品本质上还是 VS Code 的形态，界面像 VS Code，插件生态像 VS Code，操作习惯像 VS Code，然后再在上面叠自己的 agent window、chat panel、sidebar、任务系统。
这个东西可不是放一个聊天框那么简单。
一个真正可用的 coding agent，需要代码库索引、语义搜索、上下文管理、文件读写、diff apply、终端执行、checkpoint、任务队列、工具调用状态、MCP 或外部工具接入，还要有一整套持续流式更新的 UI。
这些东西一旦都塞进编辑器里，原来那个"轻"字，就很容易守不住了。
以 Cursor 的 agent window 为例，我自己的体感是，它和 VS Code 原生窗口的流畅度压根不在一个层级。VS Code 本体的编辑器、侧边栏、命令面板这些核心 UI，是长期打磨出来的。你可以说它是 Electron，但它确实已经优化得非常成熟了。
（吐槽：Cursor 的 agent window 打开是真的满啊，和 Codex 桌面版一样，不过人家有个 Loading 效果，Cursor 的 Agent Window 直接白屏。。。）
但 agent window 是另一个东西。
它要渲染长对话、工具调用日志、文件 diff、终端输出、checkpoint、任务状态，还要不断接收流式输出。稍微实现得不够克制，就很容易出现卡顿、延迟、发热，甚至整个编辑器都跟着变沉。
所以我现在越来越觉得，问题不只是"Electron 慢"。
VS Code 自己也是 Electron，但它能做到相当流畅。真正的问题可能是：很多 AI IDE 在 VS Code 之上叠了一个越来越重的 agent 工作台，而这个系统的性能、状态管理和 UI 打磨程度，并没有达到 VS Code 本体那种成熟度。
不是 VS Code 不行。是它太成功之后，被当成底座，上面叠的东西太多、太沉了。
强大本身，慢慢也会变成包袱。
然后我试了 Zed，有点回不来了
Zed 1.0 是上个月 29 号发的，到现在也一个月了。我是认认真真在体验，不是装完截个图就关掉那种。
结果试完之后，有点回不来了。
我 Mac 底部栏里已经把 VS Code 去掉了，换成了 Zed。终端里打开项目的方式，也从 code . 换成了 zed .。
为什么？
因为它真的快。
VS Code 已经算快了，这点我必须承认。冷启动两三秒，打开项目再稍微等一下，这在一众传统 IDE 面前已经很优秀了。
但 Zed 给我的感觉是另一种状态。它是那种"点开就开了"的感觉。冷启动快，开项目快，切 workspace 快，文件切换也快。我没有做严格 benchmark，也没有拿秒表计时，这些都是体感。
但编辑器这种东西，体感其实很重要。
因为你每天都在用。每天都在打开、切换、搜索、写代码。只要一个工具在这些动作上持续给你一种"没有阻力"的感觉，你很快就会被它惯坏。
Zed 就是这样。它让我重新感受到了一种很久没见过的轻盈感。
AI 集成这块，Zed 更对我的胃口
除了快，Zed 另一个让我喜欢的地方，是它对 AI agent 的处理方式。
很多 AI IDE 的选择是：魔改一个 VS Code，然后把 agent 深度集成进去。当然可以做得强，但代价往往是编辑器越来越重。
Zed 的思路看起来更像是：编辑器保持轻，agent 通过协议接进来。
它借助 ACP，可以把外部 agent 接进侧边栏里。比如 Claude Code CLI、Codex CLI、Open Code 这些，只要支持对应协议，就可以作为外部 agent 接进来。
这个方向我真的很喜欢。
编辑器就是编辑器，agent 就是 agent，二者通过协议解耦。AI 当然重要，但编辑器本身也很重要。一个编辑器如果为了 AI，把自己搞得越来越卡、越来越重、越来越不稳定，那我觉得有点本末倒置了。
Zed 这种做法，让我既能享受 agent 的能力，又能保持编辑器本身的干净和流畅。
插件少，反而成了让我安心的点
再说插件。
VS Code 的插件生态强到没话说，这点没人能否认。但强到一定程度，也会让人有点害怕。
VS Code 插件市场太大了，背后又是 Node 和 npm 生态。npm 作为全球最大、最活跃的包管理器之一，依赖链复杂，投毒、恶意包、供应链攻击这些事情并不少见。
再加上 VS Code 扩展本身权限很大，能读文件、能发网络请求、能跑外部进程。对于开发者来说，这些能力当然很有用；但从安全角度看，一旦插件出问题，影响面也会非常大。
相信大家最近也刷到了：GitHub 员工安装了一个被投毒的插件，直接导致泄露了近 4000 个私有代码仓库。这种事听起来离谱，但在一个过于庞大的生态里，它就是可能发生。
所以我现在对插件市场越来越谨慎。
Zed 的插件生态目前还很小，截止到现在也就一千零几个。这当然是缺点，很多 VS Code 里已经成熟的插件，在 Zed 里可能没有；很多细碎的工作流，也不一定能立刻迁移过去。
但另一方面，这种小和克制，也解决了我前面的困扰。
它的边界更清楚。Zed 的扩展通常以 Git 仓库形式存在，通过 extension.toml 声明能力。有逻辑的部分一般用 Rust 写，再编译成 WebAssembly。运行时还有 capability system 约束权限。
这不代表天然安全，但至少更收口、更透明。不是那种无限开放的"什么插件都可以进来改一切"的感觉。
对我来说，目前这一千多个插件就已经满足绝大的多开发情况了（实际我安装的插件也不过二十多个），已经够日常开发用了。
我不是说 VS Code 不行了
写到这里，可能有人会觉得我是在唱衰 VS Code。其实真不是。
我到现在依然觉得 VS Code 是非常优秀的编辑器。它轻量、稳定、生态成熟，插件体系强到离谱。对于绝大多数开发者来说，它仍然是最稳妥、最成熟的选择。
Zed 也远没到可以无脑替换的程度。
所以我的建议是：别盲目迁移。如果你高度依赖的某些插件在 Zed 里还没有，或者团队工作流已经围绕 VS Code 搭起来了，继续用 VS Code 完全合理。
工具这种东西，本质上还是看自己的工作流。
但如果你在写代码的时候，在意更快、更轻、更干净的体感，又想通过一个统一的入口接入各种 AI agent，那 Zed 1.0 确实值得你认真试一下。
我一直觉得，真正决定你会不会长期使用一个工具的，往往不是参数表上的毫秒数和内存占用。而是那些很细微的体感------打开项目时有没有阻力，切换文件时有没有停顿，写代码时编辑器会不会抢你的注意力。
这些感受堆在一起，最后就会变成一个很简单的判断：我愿不愿意每天打开它。
以前我的答案是 VS Code。现在，它开始变成 Zed。
所以你现在的主力编辑器，还是 VS Code 吗？
（完）