2026年4月29日，编程工具圈炸了。一个人——Nathan Sobo——曾经创造了Atom编辑器，间接催生了Electron框架，而Electron后来成为VS Code的基石。现在，他用超过100万行Rust代码、5年时间，亲手推翻了自己建立的一切。Zed 1.0正式发布，宣告Electron时代的终结。
这不是一次普通的编辑器更新。这是一个人对自己职业生涯最深的技术反思——"我用Web技术构建了Atom，但它从第一天起就让我不满意。"这个视频值得每一个写代码的人花时间看，因为它回答了一个我们都在面对的问题：当AI编辑器每周冒出一个新变体时，我们到底需要什么样的编程工具？
| 项目 | 内容 |
|---|---|
| 视频标题 | Zed is 1.0 |
| 频道 | Zed Industries |
| 发布日期 | 2026年4月29日 |
| 时长 | 约3分钟（官方发布视频） |
| GitHub Stars | 81,542+ |
| 核心主题 | 用Rust从零构建的高性能代码编辑器正式达到1.0里程碑 |
Nathan Sobo在GitHub工作了9年（2011年12月至2020年）。在这段时间里，他创造了Atom编辑器——一个基于Chromium分叉的编辑器，这个分叉最终演变成了Electron框架。Electron的成功超出了所有人的预期：它不仅支撑了VS Code（目前全球使用最广泛的代码编辑器），还被Slack、Discord等数以千计的桌面应用采用。
但Sobo从未满意过。在他的1.0发布博文中，他直言不讳地写道："Web技术提供了一条便捷的路径来发布灵活的软件，但它同时施加了一个根本性的性能天花板。"
这就是Zed 1.0的故事核心：一个工程师花了5年时间，用100万行Rust代码，亲手推翻了自己创建的技术范式。这不是简单的"再做一个编辑器"，而是对整个桌面软件开发方式的根本性反思。
【延伸分析】 这种"自我革命"在技术史上并不常见。大多数人在创建了一个成功的框架后会继续优化它，但Sobo选择从头再来。这背后是对"足够好"的不妥协——Electron让开发变容易了，但代价是每一个基于Electron的应用都背负着Chromium的庞大开销。VS Code虽然功能强大，但启动慢、吃内存、占用CPU的问题一直被开发者诟病。
Zed的技术选型可以用三个关键词概括：Rust原生、GPU渲染、零依赖Web技术栈。
Rust原生意味着什么？ 不需要运行一个Chromium实例来渲染UI。Zed直接调用GPU进行界面渲染，实现了120fps的流畅度和2ms的输入延迟。作为对比，VS Code需要先启动Electron（本质是一个Chrome浏览器），再加载JavaScript/TypeScript运行时，最后才能开始渲染界面。这个链条上的每一步都是性能损耗。
GPU渲染的细节： Zed不使用HTML/CSS来布局界面，而是自研了一套基于GPU的渲染管线。这意味着文本渲染、光标闪烁、语法高亮、甚至分屏操作都直接在GPU上完成。DevToolReviews在评测中给出了速度评分9.8/10，这是他们评测过的所有编辑器中的最高分。
实测数据说话： - 启动速度：Zed约0.4秒 vs VS Code约2-3秒（2x差距） - 内存占用：Zed约50-100MB vs VS Code约800MB-1.6GB（最高16x差距） - 输入延迟：Zed约2ms vs VS Code约30-50ms
【延伸分析】 这里有一个容易被忽视的技术细节：Zed的GPU渲染不是简单的"把文字画在GPU上"。它需要自研一套完整的文本布局引擎——处理字体渲染、Unicode双向文本、连字（ligatures）、等宽对齐等数十个细节问题。这正是为什么Zed花了5年才做到1.0的原因之一。这些工作在Web世界里由浏览器免费提供，但当你决定不用浏览器时，你就必须自己解决所有这些问题。
Zed 1.0最引人注目的AI特性是并行Agent——你可以在同一个编辑器中同时运行多个AI编码代理。这个功能在4月22日（1.0发布前一周）作为最后的关键特性合并进主分支。
与Cursor、GitHub Copilot等"AI先行"的编辑器不同，Zed采取了一种更务实的AI策略： - 开放协议： Zed提供了一个开放协议，让不同的AI模型（Claude、GPT、Gemini等）可以在编辑器中并行工作 - AI可选： 你可以选择完全关闭AI功能。The Register特别赞赏了这个设计，称"为那些只想让代码编辑器做代码编辑器的开发者提供了选择" - Agent协作： 多个Agent可以同时操作不同的文件，完成不同的任务
【延伸分析】 这种"AI作为工具而非核心"的理念在2026年显得格外珍贵。当几乎所有编辑器都在强调AI能力时，Zed反其道而行，把AI做成可选的插件式体验。这反映了一个深层洞察：开发者对AI工具的态度是矛盾的——我们需要AI提高效率，但又不希望AI接管一切。Nathan Sobo在Sequoia Capital的播客中明确表示，IDE不会因为AI而消亡，因为"编码不仅是文本生成，更是理解和操控复杂系统的过程"。
Zed的协作功能不是附加的，而是从架构层面内置的。多个开发者可以同时编辑同一个文件，看到彼此的光标、选区和编辑操作，延迟极低。这得益于Rust的并发模型——Zed从一开始就为多用户协作设计了数据同步机制。
这与VS Code的Live Share功能形成了有趣的对比。VS Code的Live Share是一个附加功能，基于独立的信号服务器；而Zed的协作是编辑器核心架构的一部分，不需要额外配置。DevToolReviews给出了协作评分9.5/10，这是Zed在所有评测维度中的最高分。
Zed 1.0的一个重要里程碑是三大操作系统首次达到功能对等。这意味着无论你用macOS、Linux还是Windows，Zed提供的功能和体验完全一致。
回顾Zed的跨平台历程： - 2023年：仅macOS，邀请制测试 - 2024年1月：开源（AGPL协议） - 2025年：Linux支持上线 - 2026年初：Windows支持上线 - 2026年4月29日：三端功能对等，发布1.0
【延伸分析】 跨平台一致性在编辑器领域是一个被低估的难题。VS Code因为基于Electron，天然具备跨平台一致性。但Zed用Rust写原生应用，每个操作系统的窗口管理、GPU接口、文件系统API都不同，要做到三端一致需要大量的平台适配工作。这也是为什么Zed花了5年才做到1.0的另一个原因。
Zed在2024年1月以AGPL协议开源。这个选择值得玩味。
AGPL（GNU Affero General Public License）要求任何基于Zed的修改版本必须同样开源，即使是通过网络提供服务也必须公开源码。这意味着任何公司如果想fork Zed做成自己的编辑器产品，都必须开源他们的修改。这是一个精心设计的"护城河"——既能享受开源社区的贡献和信任，又能防止竞争对手直接窃取成果。
GitHub仓库目前已经积累了81,542颗Star，这在新一代编辑器中是非常亮眼的成绩。
公平地说，Zed 1.0也有明显的短板。最大的问题在于插件生态系统。DevToolReviews给出的生态系统评分仅为7.5/10，远低于速度（9.8）和协作（9.5）。
VS Code拥有超过50,000个扩展，覆盖几乎所有语言和框架。Zed虽然支持语言服务器协议（LSP），这意味着基础的语言支持不成问题，但那些让VS Code强大的领域专用插件（如Docker管理、数据库客户端、REST客户端等）在Zed上还很匮乏。
不过Zed有一个潜在优势：它的扩展API基于Rust编写，理论上可以比VS Code的JavaScript扩展提供更好的性能。但这也意味着扩展开发者需要学习Rust，提高了开发门槛。
mindmap
root((Zed 1.0))
技术架构
Rust原生（100万+行）
GPU渲染（120fps）
2ms输入延迟
无Electron/Chromium依赖
性能对比VS Code
2x启动速度
16x内存效率
原生渲染vs Web渲染
AI策略
并行Agent
开放协议
可完全关闭AI
核心特性
实时协作（内置）
三平台功能对等
LSP支持
Tree-sitter语法高亮
历史
Nathan Sobo创造Atom
Atom催生Electron
Electron成就VS Code
Sobo用Rust推翻Electron范式
挑战
插件生态尚薄
Rust扩展开发门槛
迁移成本
Zed 1.0目前在几个场景下已经非常值得尝试：
场景一：大型项目开发者。 如果你在处理大型代码库（10万行以上），VS Code的内存占用和启动速度会成为明显瓶颈。Zed在打开大型项目时的表现明显优于VS Code——0.4秒启动、50-100MB内存占用，这对于在多个项目间频繁切换的开发者是巨大的体验提升。
场景二：远程协作团队。 如果你经常做pair programming或需要多人实时编辑代码，Zed的内置协作功能比VS Code Live Share更丝滑，因为协作能力是从底层架构设计的，而不是附加的。
场景三：性能敏感型开发者。 如果你对输入延迟极度敏感（比如使用vim/emacs的开发者），Zed的2ms输入延迟会让你感觉"跟手"程度完全不同。
但不建议的场景： 如果你的工作流深度依赖VS Code的特定扩展（如特定的调试器、Docker管理、Kubernetes集成等），目前切换还为时过早。建议先在副项目中使用Zed，等插件生态成熟后再考虑主力切换。
Zed 1.0给我们最大的启示不是"又多了一个编辑器"，而是一个技术决策的反思框架：当你创造了一个被全世界采用的技术方案时，你是否有勇气承认它的根本缺陷，并从零开始寻找更好的答案？
Nathan Sobo没有选择优化Electron，没有选择在VS Code基础上做微创新，而是选择了最艰难的路——用5年时间、100万行新代码，证明"原生开发"在2026年仍然是桌面应用的最佳选择。这种工程判断力，比任何具体的技术实现都更值得学习。
Nathan Sobo用5年和100万行Rust证明：当你有勇气推翻自己创造的成功范式时，才能做出真正下一代的产品——Zed 1.0不只是快，它是桌面软件开发方式的范式转移。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。