从使用者到创造者：用 AI 构建你的专属 VS Code 工具链

如今大家几乎都在类 Visual Studio Code 的编辑器里进行 AI 编程。插件生态已经极其丰富，功能琳琅满目。但真正长期写代码的人都会知道，再多插件，也无法完全贴合每个人独特的工作习惯。

总有一些“差一点”的地方：
某个功能只满足 80%；
某个交互不够顺手；
某个数据格式根本没人支持。

过去，插件开发是一道明显的门槛。要理解扩展机制、打包流程、前后端通信、UI 渲染方式，还要熟悉构建工具链。为了一个“微调需求”去补齐这些能力，成本很高。

但 AI 改变了这件事。

当下的 AI 编程能力，已经足以帮我们完成绝大多数插件逻辑开发工作。我们完全可以在现有插件基础上改造，也可以从零开始构建专属于自己的工具。让 AI 负责结构、逻辑、样板代码，我们负责判断与取舍。

工具不再是别人给什么我们用什么，而是我们需要什么就做什么。

# 一

前阵子，我基于开源的 avro explorer 做了一版改进的 Avro 数据浏览插件 （https://open-vsx.org/extension/winse/avro-explorer） 。

随后又在此基础上实现了一个 parquet explorer（https://open-vsx.org/extension/winse/parquet-explr）。

整体逻辑几乎都是 AI 完成的。我主要做两件事：明确需求，以及对部分 UI 细节进行手动微调——因为有些视觉效果，与其花时间精准描述，不如直接改样式来得高效。

拆开来看，VS Code 插件本质上可以分成两个部分。

第一部分是逻辑层。
负责文件读取、数据解析、结构转换。这部分偏后端能力，核心是数据处理与消息通信。

第二部分是展示层。
插件在展示 UI 时会创建一个 WebView，也就是一个内嵌浏览器环境。后端通过 vscode.WebviewPanel 的 postMessage 把数据发送给前端；前端用户操作回传给后端 onDidReceiveMessage。

完整链路非常清晰：

后端读取文件 → 解析数据 → postMessage 发送给 WebView → 前端渲染 → 用户交互 → 消息回传后端 → 执行逻辑。

这套模式一旦掌握，你会发现很多插件的结构高度相似。文件型工具、数据浏览器、代码生成器，本质上都是这个通信闭环。

当第一个插件完成后，后续开发会越来越顺手。 真正难的不是技术，而是迈出第一步。

# 二

插件写完之后，就是发布。

目前主流有两个平台：
一个是 Visual Studio Marketplace，
另一个是 Open VSX Registry。

Visual Studio Marketplace 属于官方生态，覆盖面广；Open VSX 更偏开放社区，很多基于 VS Code 内核的编辑器默认使用它作为插件源。

如果只是自己使用，可以直接打包成 .vsix 本地安装。但如果希望团队共享，或对外发布，上传到平台会更方便。

发布流程并不复杂：

完善 package.json 元信息 和 README；
打包生成 .vsix；
申请发布账号与 token；
执行发布命令；
记得递增版本号。

真正值得思考的不是发布流程，而是发布这件事本身的意义。

当你把一个“为自己效率服务”的工具发布到平台上时，你会发现一个认知变化——

你不再只是生态的消费者，你开始成为生态的一部分。

业务代码服务的是项目； 插件代码服务的是生产力。

前者是交付任务，后者是塑造工作方式。

# 三

AI 时代给程序员带来的，并不只是写代码更快，而是让“构建工具”这件事变得日常化。曾经需要专门投入学习的能力，如今可以边做边学，边学边用。插件开发不再是高门槛技能，而是一种可以持续迭代的个人能力资产。

这时，你已经从“使用编辑器的人”，变成了“塑造编辑器的人”。

在 AI 编程时代，一个实实在在的优势，不是会不会用工具，而是能不能把工具变成自己的。