--- author: Best Partners TV date: '2026-01-02' guest: '' layout: post.njk source: https://www.youtube.com/watch?v=FqJJehqxY58 speaker: Best Partners TV tags: - ai-coding - developer-tools - human-ai-collaboration - software-architecture - future-of-programming title: \"AI 浪潮下的 IDE 进化论：Nathan Sobo 与 Zed 的未来展望\" summary: \"本文探讨在人工智能（AI）的冲击下，集成开发环境（IDE）是否会消亡。通过对 Atom 创始人 Nathan Sobo 的观点分析，文章指出 IDE 不会消失，而是会进化为人类与 AI 协作的超级界面。重点介绍了其新项目 Zed 编辑器，强调 Rust、GPU 渲染和实时协作特性，以及 Agent Client Protocol (ACP) 如何赋能 AI Agent 直接操作代码。文章认为，人类角色将转向代码审查和架构设计，IDE 将成为记录代码生成历史的元数据骨干，预示着新一代 IDE 的黄金时代。\" insight: '' draft: true series: '' category: ai-ml area: tech-engineering project: [] people: - Nathan Sobo companies_orgs: - OpenAI products_models: - Zed - GPT-4o - Claude - Gemini media_books: [] status: evergreen --- 大家好，这里是最佳拍档。这期节目我们来聊一个话题：在AI的冲击下，**IDE**（**Integrated Development Environment**: 编写、调试和运行代码的软件应用程序），也就是我们熟悉的集成开发环境，是不是快要消亡了呢？ 随着 **ChatGPT**、**Claude** 这些大语言模型的爆发，越来越多的开发者开始尝试在终端里，甚至仅仅是通过自然语言的对话来生成代码。**Vibe Coding**（一种通过自然语言对话生成代码的开发模式）的概念正在像病毒一样传播。有一种观点认为，既然AI都能写代码了，人类何必还要盯着复杂的代码编辑器看呢？我们只需要像产品经理一样发号施令，代码就会像魔法一样自动生成了。如果按照这个逻辑推演，那个陪伴了程序员几十年的代码编辑窗口，似乎真的要成为历史的尘埃了。 ### AI 冲击下的 IDE 危机 但是，今天我要给大家分享一个对此持有不同观点的访谈，它来自一位在IDE领域深耕了近二十年的传奇人物——**内森·索博**（Nathan Sobo）。你可能对这个名字不熟悉，但是你一定用过或者听说过他的作品。他是 **GitHub** 著名的开源编辑器 **Atom** 的创始人，也是那个改变了整个桌面应用开发生态的 **Electron**（一个允许使用 Web 技术构建跨平台桌面应用的框架）框架的缔造者。现在的行业霸主 **VS Code**，在技术路线上，其实很大程度上也算是承袭了Electron的衣钵。 而现在，内森·索博带着他的新作品——**Zed**（一款基于 **Rust**（一种系统编程语言，以安全、并发和性能为设计目标）语言编写的高性能编辑器），重新杀回了战场。在最近红杉资本的一次深度访谈中，内森·索博对IDE已死的论调提出了强有力的反击。他认为，只要我们还没有实现真正的通用人工智能 **AGI**（**Artificial General Intelligence**: 具备与人类相当或超越人类的智能水平的通用人工智能），只要人类还没有完全从生产流程中退出，我们就依然需要通过某种界面，来理解和交互源代码。 ### 源代码：写给人读的语言 为什么会这么说呢？这就要回到一个更本质的问题：源代码究竟是什么？在很多人的潜意识里，代码是写给机器看的指令，是二进制的另一种表现形式。但是内森引用了麻省理工学院计算机科学教授哈罗德·阿伯尔森（Harold Abelson）的一句经典名言：“程序必须是写给人读的，只是顺便让机器去执行。” 这句话听起来可能有点极端，毕竟代码最终是要跑在CPU上的。但是，如果你仔细思考软件工程的本质，你会发现这是一个深刻的真理。代码是我们人类表达抽象逻辑、定义数据结构、描述复杂过程的一种极其精确的语言，这种语言的精确度是目前的自然语言还无法比拟的。 这就引出了一个核心矛盾：目前的AI编程工具大多是基于对话形式的。我们在聊天框里用英语描述需求，AI返回一段代码。这在解决简单问题或者编写样板代码的时候非常有效。但是，当你面对一个庞大的、复杂的、数百万行代码的工程时，当你需要理解每一行代码背后的上下文以及它们之间错综复杂的依赖关系时，仅仅靠聊天是不够的。你需要看，你需要跳转，你需要一个高带宽的视觉通道，来将这些信息加载到你的大脑中。 这就是为什么内森坚信，IDE不仅不会死，反而会进化。它需要成为人类与AI、人类与人类之间协作的一个超级界面。 ### Atom 的性能瓶颈与 Zed 的重生 让我们把时针拨回到2006年，那时候的内森·索博才刚刚大学毕业，他就萌生了一个想法：他想造一个自己的编辑器。那时候最流行的是 **TextMate**，轻量、快速。后来无论是 **Emacs**、**Eclipse** 还是 **JetBrains** 系列，都有各自的拥趸，但是内森觉得它们都不够完美。这就导致了Atom的诞生。 在GitHub时期，内森和团队做了一个大胆的技术决定：用Web技术来构建桌面应用。他们实际上是将一个浏览器引擎和一个 **Node.js**（一个基于 Chrome V8 引擎的 JavaScript 运行时环境，用于服务器端开发）环境打包在了一起，这就诞生了后来的Electron框架。Atom极其成功，它的扩展性极强，任何懂 **JavaScript**（一种高级、解释型或即时编译的编程语言，常用于 Web 前端开发）的人都可以为它编写插件。 但是随着时间的推移，内森发现了一个致命的问题，那就是性能。Web技术虽然开发效率高，但是它并不是为了高性能文本编辑而生的。当你打开Chrome浏览器的开发者工具，看着性能分析图里的火焰图（Flame Graph），你会发现有大量的计算资源被浪费在JavaScript的垃圾回收、DOM树的重绘和复杂的布局计算上。这种架构决定了，无论你如何优化，它都很难达到那种指尖即达的极致流畅感。 这种挫败感促使内森在2017年做出了一个极其艰难的决定：推倒重来。他离开了Web技术的舒适区，选择了一条布满荆棘的道路，采用Rust语言，结合 **GPU**（**Graphics Processing Unit**: 图形处理器，用于并行计算，常用于渲染图像和视频）渲染技术，从零开始构建一个新的编辑器，这就是Zed。 ### GPU 加速：极致响应 为什么要用GPU呢？我们在玩3D游戏的时候，画面可以达到每秒60帧甚至120帧，哪怕场景里有成千上万个多边形。但是，为什么我们的代码编辑器，仅仅是显示几行文字，有时候却会卡顿呢？内森认为，编辑器应该像视频游戏一样，利用显卡的并行计算能力来渲染界面。他的目标是，当你敲击键盘的那一瞬间，屏幕上的像素必须在显示器的下一次刷新周期内完成更新，实现真正意义上的零感知延迟。这不仅仅是快一点的问题，这是一种质的飞跃。对于那些每天要在这个窗口里工作8到10个小时的专业工程师来说，工具的响应速度直接影响着思维的流畅度。 ### 实时协作：代码版 Docs 除了性能，Zed的另一个核心理念是协作。现在的软件开发协作模式，基本上是基于 **Git**（一个分布式版本控制系统，用于跟踪代码变更）的异步模式：我在我的电脑上写代码，你写你的，然后我提交一个快照（Snapshot），推送到GitHub，你再来评论，我再来修改。这一来一回，可能就是好几个小时，甚至好几天。内森觉得这不够高效，他想把Google Docs那种即时协作的体验带入到代码编辑中。 在Zed里，你可以看到队友的光标在移动，你可以直接在他的代码上下文里进行讨论。这背后的技术挑战非常大，因为代码不同于普通的文档，它有严格的语法结构和复杂的依赖关系。 ### AI Agent：操作代码的助手 说到这里，你可能会问：这跟AI有什么关系呢？这正是最精彩的部分。当Zed团队构建好了这个极致性能、支持实时协作的底层架构后，他们发现，这简直就是一个为AI量身定做的身体。现在的AI编程助手，大多还是以插件的形式存在于侧边栏上。但是内森认为，AI不应该只是一个陪聊的机器人，它应该是一个能够实际操作代码的Agent。 为了实现这一点，Zed开发了一个叫做 **Agent Client Protocol**（**ACP**: 用于 IDE 与 AI Agent 之间通信的协议），简称ACP的东西。你可以把IDE想象成瑞士这个国家，一个中立的地带。无论是 **OpenAI** 的模型，还是 **Anthropic** 的 **Claude**，或者是 **Google** 的 **Gemini**，甚至是开源模型，都可以通过这个协议接入IDE。在这个协议下，AI不再只是输出一段文本，让你去复制粘贴。AI Agent可以像人类程序员一样，拥有操作编辑器的权限。它可以看到光标的位置，可以读取当前文件的上下文，可以跳转到定义，甚至可以在你的注视下，直接在代码中进行增删改查。这就改变了人机协作的范式。 内森举了一个他自己的例子，非常生动。有一次，他需要为Zed编写一个模拟 **Cloudflare**（提供内容分发网络、DNS、安全和服务器无服务器计算服务的公司）API的后端模块，这是一个很枯燥但是工作量又很大的任务。如果是在以前，他需要去查阅Cloudflare冗长的API文档，然后一行一行地写Rust代码来进行封装。但是他这次换了一种方式：他把Cloudflare的JavaScript API文档喂给了AI Agent，然后对Agent说：“我需要一个Rust的抽象层，还要一个模拟器，请帮我生成。”结果令他大为震撼：AI迅速地生成了大量的样板代码，不仅覆盖了主要的API接口，甚至连一些边缘情况也都考虑到了。内森形容这种感觉，就像是用这一个知识挤压机，把散落在互联网各个角落的文档知识，瞬间挤压成了他所需要的结构化代码。这就是AI最擅长的地方：处理那些在它的训练数据分布内的、标准化的、但是又繁琐的任务。 ### 人类角色：从编写到审查 但是，这是否意味着内森就可以完全放手不管了呢？绝对不是。虽然AI生成了大量的代码，但是作为一个资深的架构师，内森发现AI在处理宏观架构和复杂的逻辑约束时，依然会犯错。它可能会生成一段看起来很完美，但是在某种极端并发情况下会死锁的代码，或者它会写测试用例，但是那些测试用例本身就是错的，导致测试永远通过不了。 所以，在当前的阶段，人类的角色正在发生转变：我们从单纯的代码编写者，变成了代码审查者和架构设计师。我们需要具备更高的鉴别能力，去判断AI生成的代码是否符合系统的整体设计。这就是为什么内森强调，我们仍然需要IDE，甚至需要一个更强大的IDE。 ### 元数据骨干：代码的历史 在Zed的未来愿景中，IDE将不仅仅是一个写代码的地方，它将变成一个**元数据骨干**（**Metadata Backbone**: 一种将代码与其生成历史、讨论过程等元数据紧密关联的系统）。想象一下，在未来的代码库里，不仅存储着最终的代码文本，还存储着这些代码是如何产生的历史。当你把鼠标悬停在某一个函数上时，你不仅能看到它的定义，还能看到一段对话记录，这段记录显示了当初是你和AI Agent讨论了三个回合才决定采用这个算法的。或者你可以看到，这个复杂的逻辑是大语言模型在阅读了某篇技术论文后生成的，并且附带了那篇论文的链接。这种将对话、思考过程与代码实体紧密绑定的方式，将彻底改变我们维护和理解软件的方式。代码不再是一串串冷冰冰的字符，而是人类思维与AI算力共同编织的历史。 当然，我们必须得承认，这种愿景到现在还处于早期的阶段。目前的AI Agent还不够完美，它们的上下文窗口也很有限，推理能力也经常幻觉。很多时候，看着AI在那一行一行地敲出错误的代码，确实不如自己直接上手写来得快。 但是内森·索博是一个乐观的长期主义者。他从2006年开始就在追求完美的编辑器，经历了Atom的辉煌与遗憾，现在用Rust和Zed再次出发。他赌的不仅仅是一个工具的胜利，而是在赌一种未来的人机关系。在这种关系中，AI变得越来越快、越来越聪明，而人类，依然掌握着方向盘，依然需要通过一个高性能、高带宽的界面，去审视、去引导、去与这些硅基智能体共同创造。 所以，回到最初的问题，IDE会死吗？我的答案是：旧时代的、仅仅作为文本编辑器的IDE，可能会被逐渐的边缘化。但是新一代的、作为人机协作中枢的、拥有无限上下文感知能力的超级IDE，才刚刚开始它的黄金时代。正如内森所说，我们不仅是在编写代码，我们是在通过代码这种精确的语言，将人类的抽象思维具象化。只要这种创造性的活动还在继续，我们就永远需要那个能让我们与数字世界深层连接的窗口。 那大家觉得，未来的编程会变成纯粹的对话形式吗？还是我们会像内森预测的那样，进入一个人机深度融合的视觉化编程时代呢？欢迎在评论区留言。感谢收看本期视频，我们下期再见。