#开源替代# VS Code:开源编辑器如何成为 AI 时代的默认界面

 极客日记 · 2026.07.03  ·  桌面生产力 #33 

      VS Code 从 2015 年发布之日起，就注定了要改变编程世界的格局。但让它在 2026 年变得真正不可替代的，不是它比 Sublime 快、比 Atom 稳定——而是它的扩展架构刚好成了 AI 编程工具的最佳宿主。    今天几乎所有主流的 AI 编程助手——GitHub Copilot、Cursor、Continue、Cline——都选择 VS Code 作为第一平台。这篇文章不是在评测一个编辑器，是在分析一个架构决策如何重塑了整个开发者工具市场。 

一、VS Code 的扩展：从语法高亮到接管编辑器的每一步

      2015 年 4 月，微软在 Build 大会上发布了 Visual Studio Code。2016 年 4 月，VS Code 1.0 正式发布。它基于 Electron 框架，本质上是一个 用 Web 技术构建的桌面应用——HTML/CSS/JavaScript 写 UI，Node.js 处理文件系统和进程管理。 

     这个技术选型在当时争议很大：Electron 应用的内存占用高、启动慢。但 Electron 带来了一个传统桌面 IDE 没有的优势：扩展 API 可以用 JavaScript 写，而全世界的 Web 开发者都会 JavaScript。 

      VS Code 的扩展 API 设计有三个关键决策： 

     1. Language Server Protocol（LSP）——编辑器和语言智能（补全、跳转、重构）之间的标准通信协议。任何语言只要实现一个 LSP Server，就能在 VS Code 里获得完整的智能提示。这个协议现在已经成为行业标准，Eclipse、Vim、Emacs 都在用。 

      2. 编辑器的每个行为都是可拦截的事件——光标的每一次移动、文件的每一次保存、缓冲区的每一次修改，都可以被扩展监听和响应。这意味着扩展不仅能”添加功能”，它可以在编辑器核心行为中插入自己的逻辑。 

      3. Webview 作为 UI 容器——扩展可以在编辑器内嵌一个完整的 HTML 页面，拥有自己的 DOM、JavaScript 引擎和 CSS。这使得扩展的 UI 自由度极高——你可以在编辑器侧边栏里运行一个完整的 D3.js 可视化仪表盘。 

二、基本信息

三、为什么 AI 编程工具都长在 VS Code 上

      这是一个架构层面的问题，答案不在 AI 模型的优劣，而在编辑器扩展 API 的开放程度。 

      一个 AI 编程助手需要做这些事情：读取当前文件内容、获取光标位置上下文、访问整个工作区的文件列表、获取语言服务器提供的符号信息、在编辑器中插入/替换代码、在侧边栏显示聊天界面、获取终端输出作为上下文。这八个操作对应着 VS Code 的八个 API。它们全部是公开、稳定、文档完整的。 

       比 API 设计更重要的是：VS Code 允许扩展修改编辑器的每个层面。Copilot 的内联补全（幽灵文本）是通过 `InlineCompletionItemProvider` 接口实现的——这不是微软给自己的 Copilot 团队开后门，这是一个公开 API，Cursor 和 Continue 同样在使用。这意味着 AI 工具在 VS Code 上的竞争是功能层面的，不是平台准入层面的。      另一件关键的事：VS Code 的开源性质允许完全分叉。Cursor 本质上就是一个深度定制的 VS Code 分叉——它保留了对所有标准扩展的兼容性，然后在编辑器的核心交互层（光标行为、Tab 键逻辑、上下文收集）做了自己的实现。如果 VS Code 不是开源的，Cursor 根本不存在。 

四、JetBrains 为什么没有同样的生态

      JetBrains 的 IntelliJ 平台在”传统 IDE”层面仍然是最强的——深度代码分析、重构能力、框架集成。但它在 AI 时代的进展明显落后于 VS Code。这不是技术能力的差距，是平台架构的差异。 

      IntelliJ 的插件 API 是 Java 生态的产物——功能强大但门槛高。写一个 IntelliJ 插件需要了解 PSI（Program Structure Interface）、需要处理复杂的类加载器隔离、需要兼容不同 JetBrains IDE 之间的 API 差异。而写一个 VS Code 扩展只需要 `npm install` 相关依赖，然后写几个 TypeScript 事件处理器。 

      更关键的是：JetBrains 的代码不是开源的。你不能像 Cursor 分叉 VS Code 那样做一个”AI-First IntelliJ”。你只能在 IntelliJ 的插件体系内做事。这意味着你的 AI 工具始终是”一个插件”，而不是”一个新的编辑器”——产品形态的上限被锁死了。 

五、VS Code 在我的工作流中的位置

      VS Code 在我的日常工作中扮演的角色已经不是”编辑器”，而是一个开发环境的操作系统。终端在 VS Code 里，Git 操作在 VS Code 里，数据库查询在 VS Code 里（通过 DBeaver 的 VS Code 扩展），Docker 管理在 VS Code 里（通过 Docker 扩展），甚至写这篇文章的初稿也是在 VS Code 的 Markdown 编辑器里完成的。

      而当 AI 助手介入工作时，VS Code 的优势完全展现出来：AI 可以通过工作区 API 读取整个项目的文件结构作为上下文；可以通过终端 API 获取命令执行结果并据此给出建议；可以通过编辑器 API 不仅生成代码，还能生成完整的文件路径和项目配置。这种”AI 不仅理解你的代码，还理解你整个项目的文件组织”的能力，是 VS Code 扩展架构的直接产物。 

六、局限性与争论

       VS Code 不是完美的，批评主要集中在这几点： 

      内存占用——Electron 应用的先天问题。打开一个大项目 + 20 个扩展，内存轻松超过 2GB。 

     “扩展疲劳”——50,000 个扩展中质量参差不齐。同一个功能有十几个实现，选择成本高。扩展之间的冲突调试让人头疼。 

      微软控制的生态——虽然 VS Code 本身是 MIT 开源，但 Marketplace（扩展商店）和 C# 调试器等组件是闭源的。VSCodium 是社区维护的去微软版本，但无法使用官方 Marketplace 上的一些闭源扩展。 

      跨平台情况——三大桌面平台体验一致，另有 vscode.dev 浏览器版（功能受限）。 

BI9ABS 点评

      BI9ABS点评：VS Code 刚出来的时候我是抗拒的——一个 Electron 应用凭什么替代 Sublime Text 和 Vim？但 2018 年前后，Language Server Protocol 的生态爆发式增长，突然之间 Rust、Go、Python、TypeScript 的所有现代化工具链都把 VS Code 作为第一支持平台。这不是微软的营销胜利，是一个开放协议让整个语言工具链社区自发选择了它。到了 AI 时代，VS Code 的架构优势变成了一种”幸运的必然”——它的扩展 API 设计时并没有考虑 AI，但恰好 API 的粒度（文件级、光标级、缓冲区级）刚好是 AI 编程助手需要的上下文语义粒度。我在 VS Code 里不只是写代码，是整个开发工作的指挥中心——终端、数据库、Git、AI 对话，全部在一个窗口里。 

极客日记 · 桌面生产力系列

■ 本文工具：VS Code —— 开源代码编辑器，AI 编程工具的默认宿主平台

■ 逃离对象：JetBrains 全家桶及各类付费 IDE

■ 跨平台：Windows / macOS / Linux / Web

 ■ 2026 极客日记系列 ■ BI9ABS ■ 转载请注明出处