为什么IDE不会在AI编程时代消亡：Zed创始人Nathan Sobo
摘要
在AI编程工具如雨后春笋般涌现的时代，"IDE已死"的论调不绝于耳。然而，Zed编辑器创始人Nathan Sobo提出了一个反常识的洞见：源代码本质上是一种为人类阅读而设计的语言，只要人类还需要理解代码，就需要优秀的可视化界面。Nathan在IDE领域深耕近二十年，从GitHub的Atom到如今用Rust重写的Zed，他始终在追寻一个终极工具——既拥有Vim的响应速度，又具备JetBrains的功能深度。Zed目前拥有超过17万活跃开发者，并开创性地提出了ACP（Agent Client Protocol）协议，旨在让不同AI代理与不同编码界面无缝连接，类似LSP（Language Server Protocol）对语言支持的标准化。Nathan认为，IDE的未来不是被AI取代，而是演化为人类与AI协同工作的核心枢纽——一个将对话、编辑、上下文全部锚定在代码上的元数据骨干网络。他分享了对LLM（大语言模型）编码能力的深刻观察：模型在"分布内"任务上表现出色，但在需要深度思考的问题上仍力不从心。这篇文章深入探讨了代码协作的范式转变、LLM的真实能力边界，以及IDE在AI时代的演化方向。
正文
一、IDE真的会消亡吗？
Nathan Sobo开门见山地回应了当下最热门的话题：AI编程工具是否会终结IDE？他坦言自己也曾陷入焦虑，毕竟他一生都在打磨终极编辑器。但他经过深思熟虑后认为，那些宣称"IDE已死"的论调并不现实。
核心论据在于：源代码是一种语言，就像自然语言一样。Nathan引用了计算机科学先驱Harold Abelson的经典名言——"程序应该写给人类阅读，而只是顺便给机器执行"。尽管LLM（大语言模型）在自然语言处理上取得了革命性突破，但源代码并非只能喂给处理器的二进制数据，它本质上是面向人类消费的。
Nathan的推理链条很清晰：除非达到AGI（通用人工智能）阶段，人类不再需要参与任何编程活动，否则我们始终需要查看代码。而一旦需要查看代码，问题就变成了"什么是最佳的用户界面"。他观察到，即使重度使用终端AI编码工具的用户，也常常在旁边开着一个编辑器来查看AI到底做了什么。当Claude Code之类的工具只能在终端显示10行代码片段时，想要理解更广阔的上下文就不得不借助编辑器。
二、从Atom到Zed：二十年磨一剑
Nathan回顾了自己的职业生涯。2006年大学毕业后，他就立志打造自己心目中的完美编辑器。当时的TextMate以轻量、简洁、快速著称，Emacs和Eclipse各有特色，JetBrains产品功能强大但启动缓慢。没有任何一个产品能将这些优点融为一体。
在GitHub期间，Nathan主导开发了Atom编辑器。为了追求极致可扩展性，团队选择了Web技术栈，并在此过程中构建了Electron框架——最初只是为了给Atom提供外壳，后来却成为无数桌面应用的基础。然而，Atom的成功也埋下了隐患。Nathan回忆道，过度开放导致扩展代码随意在主线程上运行，严重拖累了性能。当他打开Chrome开发者工具试图优化性能时，面对火焰图中那些无法深入的调用栈，他意识到Web技术已经触及天花板。
2017年，Nathan决定从头再来。他选择Rust重写编辑器，核心追求是零感知延迟——每次按键都应在显示器的下一个同步周期内得到像素级响应。Zed将整个应用架构设计为向GPU着色器输送数据来渲染UI，就像视频游戏渲染帧一样。这种极致的性能关注，让Zed在响应速度上远超任何基于浏览器的编辑器。
三、从人类协作到人机协作
Zed最初的设计目标是改善人类开发者之间的协作体验。Nathan对GitHub式的异步代码审查模式提出了质疑：提交快照、上传、等待他人评论、可能一天后才回复——这种"邮件式"体验对于同处一页的团队来说效率低下。他更推崇类似Figma的实时协作模式：所有人在同一个创作环境中，能看到彼此，能实时对话和打断。
这个设计恰好为AI时代的到来埋下了伏笔。当AI代理开始参与编程时，Nathan发现原有的协作架构自然延伸到了人机交互。他的愿景是将对话永久锚定在代码上——不是每次AI生成一行代码就提交一次，而是建立一种细粒度的追踪机制，类似于"每次按键都有一次提交"，让对话和反馈可以精确地绑定到代码的每一个版本上。
Zed正在构建的Delta DB系统正是为了实现这一目标：在Git之上层叠实时同步和细粒度编辑追踪，将代码转化为元数据骨干，让所有与代码相关的对话、上下文和历史都可以围绕这个骨干展开。
四、ACP协议：IDE的"瑞士"战略
Nathan将Zed定位为人类与各种AI代理之间的"瑞士"——中立但至关重要的连接层。ACP（Agent Client Protocol）的灵感直接来自微软的LSP（Language Server Protocol）。LSP将语言智能从IDE中剥离出来交给社区维护，彻底改变了编辑器生态。Nathan想对AI代理做同样的事。
他的判断是：未来会有多种AI代理在不同领域竞争，每个代理可能各有优势。与其让Zed自建一个可能被超越的代理，不如建立开放协议，让任何代理都可以接入Zed的最佳UI界面。目前JetBrains已经加入ACP生态，多家人工智能代理开发商也在接入。Nathan将这一战略称为"与努力结盟，而非与之竞争"。
五、LLM编码能力的真实边界
Nathan分享了自己使用LLM编程的实际体验。他认为LLM在"分布内"任务上表现出色——那些训练数据中广泛存在的知识。例如，他用GPT-4生成了Zed的整个图形渲染后端，包括GPU着色器配置流程；他还利用LLM编写Rust过程宏（一种他本不熟悉的高级特性），将Tailwind CSS的理念引入系统编程语言。
他将LLM比喻为"知识挤出机"：模型内部蕴含大量通用知识，你只需要将其挤压成你需要的形状。这种"复制粘贴的超级增强版"在处理标准化任务时极为高效。
然而，当面对需要深度思考的问题时——比如Zed正在开发的Delta DB系统——LLM就力不从心了。"代码不是约束，思考才是"，Nathan说。在这种场景下，他仍会使用LLM探索想法或快速生成原型代码来感受效果，但不会依赖它们来写出最终产品。他对LLM的加速能力持乐观态度，认为速度提升将带来质变。
六、IDE的未来：对话即编辑器
Nathan展望了IDE的终极形态。他正在设计一个将对话置于前台的界面——不再是被动查看AI生成的代码片段，而是将对话本身变成一个可编辑的表面。用户可以像操作编辑器一样在对话中导航、在渲染的代码窗口中直接编辑、查看任意两个时间点之间的变更。
这本质上是创造了一种新的编辑器类型：它不只是展示代码库中的一个文件，而是展示一段对话和来自多个文件的代码片段，用户可以像在传统编辑器中那样直接与之交互。这种设计突破了传统IDE的"左侧文件树、中间标签页、右侧面板"的布局，为"代理驱动开发"这一新工作范式量身定制了界面。
Nathan强调，Zed不是要抛弃传统编码模式——那种"一个开发者在一个工作副本中手动解决问题"的方式永远有存在的价值。但他同时认为，随着LLM速度提升，开发者会同时处理多个代理对话和多个项目，IDE需要演化为能够管理这种复杂性的环境。
Nathan Sobo花了近二十年追寻完美编辑器。在AI浪潮中，他非但没有看到IDE的终结，反而看到了这个品类演化的最大机遇：从人类的编码工具，升级为人类与AI协同创作的元数据中枢。正如他所说："我们不是要逆势而为，我们是在驶向未来。"