vibe coding这个概念火起来之后，我一度以为VS Code扩展市场会迎来一波大爆发。毕竟VS Code是全球装机量最大的代码编辑器，AI又是最近一两年最热的方向，两相叠加，怎么也该催生出一大批“AI助手”、“vibe coding工作流”、“自然语言编程”之类的扩展。可实际情况完全相反：你打开扩展市场搜一圈，能打的AI扩展还是那几张老面孔，新的小工具大多停留在“套一层聊天窗口”的水平，真正能被记住的寥寥无几。这个反差本身就很有意思——一个趋势如此受欢迎，却没有在最大的编辑器生态里留下多少痕迹，说明问题不在需求端，而在更深层的结构上。
这篇文章想把这个现象聊透。我会从vibe coding的真实工作流说起，分析VS Code扩展生态为什么没有跟上，再聊聊我实际使用和开发过程中的观察。如果你正在纠结“要不要在VS Code里装一堆AI扩展”，或者你本身想做扩展开发但不知道该往哪个方向投入，这篇应该能给你一些参考。
1. 先还原vibe coding的现场：用户到底在哪儿写代码
1.1 所谓vibe coding，很多人的理解是偏的
先校准一下概念。vibe coding这个词是Andrej Karpathy在2025年初提出来的，原意是“凭感觉编程”——你有一个模糊的想法，用自然语言描述给AI，AI生成代码，你不太仔细看具体实现，跑起来差不多能用就往下走。它强调的是“传达氛围”而不是“精确控制”，开发者从“逐行写代码”变成“描述意图、验收结果”。
这个定义听起来很玄，但落到实际操作上，大多数人理解的vibe coding其实是另一套东西：在聊天框里让AI写一个函数、修一个bug、补一段测试。这种用法更接近“AI辅助编程”，和Karpathy说的“你自己基本不看代码”还是有距离。真正把vibe coding贯彻到底的人，往往是需求非常明确的场景——比如做个内部工具、写个自动化脚本、搭一个原型Demo——代码质量不是第一优先级，能跑、能改、能在十分钟内看到结果才是。
这个区别很关键，因为它决定了工具形态。你如果只是“让AI帮我写个函数”，那在VS Code里装个Copilot、Codex插件就够了。但如果你真的要“描述一个想法，让AI自己折腾半天，最后给你一个能跑的东西”，那VS Code这种编辑器形态反而不适合——你需要的是一个愿意长时间自主工作的agent，而不是一个被动响应你输入的插件。
1.2 真实工作流：从终端到聊天框，唯独不太在编辑器里
我观察到的vibe coding实践者，工作流大致可以分成三类。
第一类是Claude Code、Codex CLI这种终端工具。你在终端里启动一个会话，告诉AI“我要做一个什么工具”，AI自己去读文件、改代码、跑测试、报错再修。整个过程中，你和编辑器唯一的交互可能就是偶尔打开文件看一眼结果。这类工作流里，VS Code只是个旁观者。
第二类是Cursor、Windsurf这种把AI深度集成进编辑器的独立IDE。它们不是VS Code的扩展，而是基于VS Code内核重新做了一层AI交互界面。你在编辑器里直接和AI对话，AI能看到你的光标位置、选中代码、编译错误，甚至帮你一键执行命令。这种体验比“VS Code + 扩展”更顺滑，因为AI是原生UI的一部分，而不是在一个Webview里模拟聊天。
第三类是聊天框模式，就是你在DeepSeek、ChatGPT、Kimi这类网页或桌面应用里把代码贴来贴去。这个模式最原始，但用的人一点都不少，尤其适合需求描述清楚、代码量不大、一次生成完不反复迭代的活。
你发现没有，这三类主流工作流里，VS Code本身都不是核心承载者。它是终端工具旁边的一块屏幕，是独立IDE的“底子”，是聊天框之外的“对照物”——但唯独没有形成一个围绕VS Code扩展展开的vibe coding生态。这不是偶然，后面我会详细分析原因。
2. 扩展商店的真实状态：不是没人做，是压根没长出来
2.1 翻一遍市场：AI扩展的老面孔和新面孔
我前段时间专门把VS Code扩展市场里的AI相关扩展翻了一遍，结论可以用一句话概括：头部还是那几位，腰部几乎断层，长尾全是玩具。
头部是谁？GitHub Copilot是老大哥，ChatGPT官方插件也算一个，然后是Continue、Cline（原Claude Dev）、通义灵码、CodeGeeX这些。它们的共同点是：出现得早，背靠大厂或成熟开源社区，迭代稳定，功能覆盖“代码补全+对话+Agent”的完整链条。但注意，这些扩展的发布时间大多在2023到2024年，2025年vibe coding概念火热之后，并没有出现一个“专为vibe coding设计”的现象级扩展。
腰部断层的意思是，排名前十以外的AI扩展，数量不少，但同质化极其严重。我打开市场搜“AI Code”，翻了几页，看到的几乎全是“套壳聊天窗口 + 对接某个大模型API”的组合。它们做的事情本质上是同一个：在侧边栏开一个Webview，把OpenAI或Anthropic的API封装一下，附带几个快捷操作，比如“解释选中代码”、“生成测试用例”。这类扩展我称之为“API搬运工”，它们没有回答一个核心问题：vibe coding真正需要的到底是什么交互形态。
长尾就更不用说了，很多个人开发者做的扩展，上传一两个版本就不更新了，能用但不敢在生产环境碰。整体看下来，VS Code的AI扩展生态呈现出一种“早熟而后劲不足”的状态——2023年那波AI热已经把这些该做的都做过了，2025年的vibe coding热反而没给这个市场带来多少增量。
2.2 连基础体验都还在踩坑：装机、权限、禁用
除了数量和质量的断层，VS Code扩展生态本身的基础体验也拖了后腿。你可能觉得这不重要，但恰恰是这些不起眼的坑，劝退了一大批想做AI扩展的开发者。
远的不说，网上随便搜一下就能看到一堆真实吐槽：有人装了某个AI扩展之后被提示“由于恶意软件、可疑行为或违反策略，已禁用此扩展”，插件刚上线还没来得及用就被微软那边扫了；有人从GitHub Releases下载离线安装包，装完发现版本不对，报“扩展无效”；还有人每次打开VS Code都被要求重新登录才能访问扩展市场，登录一次能管一阵子，过几天又掉。
这些问题的根源是VS Code扩展生态的“双重身份”矛盾。一方面，VS Code扩展本质上是“Web应用 + Node.js运行时”的组合，权限模型比较宽松，既能读文件又能调终端，天然容易被滥用；另一方面，微软为了维护自家商店的安全底线，引入了签名校验、策略扫描、登录态校验等机制。这两套逻辑叠加在一起，就给开发者制造了大量隐形成本——你的扩展可能功能没问题，但在分发和安装环节踩坑。
这对vibe coding扩展的发展是实打实的阻碍。AI类扩展往往要申请终端权限、文件系统权限，而这些权限恰恰是微软审核时重点怀疑的对象。我认识一个做AI扩展的开发者，他的工具功能很简单，就是调用大模型API帮用户批量生成项目脚手架，结果上架后几天内被标记为“可疑行为”，申诉了一圈才恢复。这种事情发生一次就够消磨人热情了，更别说连续踩坑。
3. 为什么扩展生态跟不上：四个绕不开的结构性原因
3.1 工具形态错位：CLI才是vibe coding的主场
我前面说vibe coding的主流工作流在终端和独立IDE，这背后有个很实际的原因：agent类AI工具的核心能力是“自主操作”，而自主操作需要的是一个完整的系统环境，不是编辑器里的一个面板。
以Claude Code为例，它的工作方式是在终端里启动一个会话，AI可以调用shell命令、读写项目文件、搜索代码仓库、运行编译器和测试，然后根据结果决定下一步动作。这种“给自己授权、自己干活、自己纠错”的模式，本质上和一个程序员在终端前干活没什么区别。VS Code扩展能做什么呢？它能读文件、能调终端、能操作编辑器选区，但这些都是“被授权”的细粒度API，每做一步都要经过扩展的权限边界，而且扩展运行在渲染进程里，不能长时间占用主线程做重型任务。
所以你会看到一个很有意思的现象：Claude Code、Codex CLI这些工具都有对应的VS Code扩展版本，但它们都是“锦上添花”的存在——给你一个图形界面看AI目前在看哪些文件、断点状态如何而已。真正的逻辑引擎在CLI里，扩展只是个显示器。vibe coding的核心生产力发生在CLI这一层，编辑器扩展只是观察窗口，这决定了它注定不会成为生态的主角。
3.2 扩展API的限制：VS Code能给你什么，不能给你什么
再往深一层说，VS Code的扩展API设计，从根上就不是为“AI Agent”准备的。它的API更像是“键盘快捷键 + 编辑器操作 + 文件读写 + 终端调用”的组合，是为了让人工操作更高效，而不是让一个AI自主决策。
举几个具体例子。VS Code扩展可以调用vscode.window.createTerminal创建一个终端，但如果你想监听终端里每一个命令的输出流，做起来很别扭，你得用onDidWriteTerminalData事件，但这个事件在某些终端类型下不可用，或者输出的数据是分块的，解析起来很麻烦。AI agent需要的是对终端的完整控制——执行命令、读取stdout/stderr、判断退出码、决定下一步——这套东西在VS Code扩展API里是残缺的。
再比如，AI agent要自主遍历项目文件，扩展虽然有workspace.findFiles，但当项目很大的时候，这个API的性能并不理想，而且你无法精准控制搜索范围。更不用说AI常常需要创建临时文件、修改配置、管理多步事务，这些在VS Code扩展上下文里都很难优雅实现。你让一个agent跑一个需要十几分钟的任务，VS Code的扩展宿主是撑不住的——渲染进程崩了、内存爆了、用户切个窗口就断线，这些都是真实发生过的问题。
所以很多做AI工具的人最后都发现，与其在VS Code扩展里硬磕，不如直接用Node.js写一个独立进程，大不了做成一个“VS Code远程扩展”通过HTTP和编辑器通信。但这条路门槛更高，不是普通开发者愿意走的。
3.3 商业模式与平台博弈：厂商更愿意做独立产品
还有一个容易被忽略的原因：商业上的博弈。VS Code的扩展市场是微软控制的，虽然开发者可以自由上架，但分润、数据、用户关系都掌握在微软手里。对于Anthropic、OpenAI、各大模型厂商来说，做一个VS Code扩展意味着把自己的核心用户体验寄人篱下——扩展可能被下架、被限流、被竞品模仿，而且你无法直接从扩展上赚钱（VS Code市场不支持付费扩展订阅，得靠内购或跳转外链）。
这种情况下，大厂更愿意做一个独立IDE或独立应用。Cursor就是典型的例子，它基于VS Code开源内核，自己掌控整个UI和AI交互层，用户可以订阅付费，厂商可以做增长策略、做用户行为分析、做差异化功能。Windsurf、Replit也是同样的逻辑——与其在微软的平台上寄人篱下，不如自己做一个带AI基因的产品。
小开发者则面临另一个问题：迭代速度追不上模型变化。vibe coding工具的核心是模型能力和agent逻辑，模型API天天在变，prompt engineering的实践也在快速演化，而你做一个扩展，既要适配新API，又要处理VS Code本身的版本兼容，双重负担下，个人开发者根本忙不过来。很多2024年还能看到的AI扩展，到2025年已经停更了，作者要么转去做独立应用，要么放弃了。
3.4 迭代速度的错配：扩展追不上工具的更新
最后说一个和开发体验直接相关的原因：VS Code扩展的迭代节奏，和vibe coding工具的迭代节奏，完全不在一个波段上。
vibe coding领域的工具，更新频率是惊人的。Claude Code几乎每周都有新版本，Codex的命令行工具也在频繁加功能，Cursor更是两周一个小版本、一个月一个大版本。这些工具的API体系、配置格式、交互约定经常变化，今天还能用的参数明天可能就废弃了。
而VS Code扩展的发布流程是相对保守的。你得跟着VS Code的发布周期走，兼容不同版本的Electron和Node运行时，还要在审核、签名、发布这些环节上花时间。你如果是做CLI工具的，改一个参数发个包，一分钟的事；你如果是做VS Code扩展的，改一行代码要测试、打包、上架、等待审核，快则几小时，慢则几天。
这种节奏错配导致的直接结果是：很多AI扩展在发布时功能是新的，但过两周就过时了。用户装了一个“vibe coding扩展”，用起来发现还是老一套的聊天窗口，没有agent能力，没有上下文感知，没有自主执行，体验和最新的CLI工具差了不止一个版本。用户失望，开发者疲惫，生态自然就长不起来。
4. 在VS Code里做AI助手，现实比理想骨感
4.1 现有扩展能做到什么程度
说了这么多结构性问题，还是得回到地面上看看，现在VS Code里的AI扩展到底能做到什么程度。
如果你只需要“代码补全”和“行内对话”，那Copilot类的体验已经相当成熟了。补全延迟低、上下文意识强，Edit模式在处理单文件修改时很顺手。这属于“AI辅助编程”的范畴，和vibe coding有交集但不等同。
如果你需要“Agent式操作”——让AI自己读代码、改多个文件、跑测试——那VS Code扩展里唯一表现不错的是Cline（原Claude Dev）。它引入了“Plan / Act”模式，AI可以规划步骤、操作多个文件、调用终端命令，用户只需要在关键节点确认。它的原理是直接调用Claude API，把整个项目上下文塞给模型，让模型决策并执行。这个思路是对的，但受限于VS Code扩展的宿主环境，跑大项目时明显吃力：加载上下文慢、token消耗大、终端交互不如CLI稳定。我拿它跑过一个中等规模的React项目，改完一轮代码大概要七八分钟，期间VS Code的CPU占用一直在高位，风扇呼呼转。
至于其他扩展，体验就更多样化了。有的做“AI代码审查”，能扫描项目给出问题列表，但对上下文的理解停留在静态分析层面；有的做“自然语言转SQL”，挺实用但场景太窄；还有一堆“多模型聚合器”，号称一个插件能切换十几个大模型，实际就是把API轮询封装了一层，没有自己的逻辑。这些工具你说它们是vibe coding扩展吗？勉强算，但都没抓住vibe coding的核心——不是让你“对话写代码”，而是让你“描述需求，让AI自己完成从设计到实现的全过程”。
4.2 实测过的几个扩展：哪些能用，哪些是坑
我这一年多陆续装过十几个AI相关扩展，这里挑几个说下真实体验，给想尝试的人一个参考。
先说GitHub Copilot。它是我留在VS Code里的唯一一个“常驻AI扩展”，原因很简单——它不是vibe coding工具，但它在“代码补全”和“局部修改”这两个维度上做到了无可替代。我日常写代码时，它预测的下一行、下一个函数的准确率很高，能显著减少无意识的键盘输入。但如果你指望它“帮你vibe一个项目”，它做不到。它的设计哲学是“辅助人类写代码”，不是“替代人类写代码”。
再说Cline，前面提过它的agent能力，补充一点：它的核心优势是项目感知，能把当前项目的文件树、代码片段、终端输出都打包给模型，所以它修bug、改逻辑的时候“知道自己在干嘛”。但它有个硬伤——贵。跑一次完整任务，消耗的token相当可观，我用Claude的API跑一个小功能的实现，花了几美分，如果每天都这么用，月账单不低。另外它对大项目的上下文管理还是不够聪明，文件一多就容易“迷失”，甚至会把无关文件也扔给模型，既费钱又容易跑偏。
然后说那些“套壳扩展”。说实话我不推荐装太多，因为你装了五六个聊天类扩展，最后真正高频用的还是那个顺手的一两个。而且它们给不了你agent能力——顶多是帮你把选中代码发给AI、把AI回复粘回来，中间少了很多“让AI自己去查报错、自己去改文件”的可能性。这类扩展的市场逻辑是“绑定自家模型API做增量”，但在vibe coding的语境下，它们几乎可以被原生聊天工具完全替代。
最后提一下扩展安装环节的坑。我遇到过几次“扩展被禁用”，点开详情一看，提示“由于恶意软件、可疑行为或违反策略，已禁用此扩展”。有一次是新装的一个代码注释生成器，没用几天就被禁了，原因不明。这种事儿发生一次你就会对“什么扩展都敢装”这件事产生警惕，间接也降低了整个AI扩展生态的信任度。
5. vibe coding真正落地的形态：编辑器之外的五条路
5.1 独立IDE和独立应用：Cursor模式为什么能跑通
如果说vibe coding有一个“最理想”的载体，那目前来看是Cursor这类独立IDE，而不是VS Code加扩展。
Cursor的逻辑是：基于VS Code的开源代码，重写了AI交互层。它不叫“扩展”，它本身就是“宿主”。AI对话框、代码差异预览、行内编辑建议、自动应用修改，都作为IDE的原生功能实现。这种做法的好处是，AI的每一个动作都可以直接反映在编辑器UI上——AI改了哪个文件、哪几行，用diff高亮显示，你扫一眼就能决定接不接受。这和Claude Code在终端里输出一大串“我改了xxx文件，因为yyy原因”相比，直观程度高了不止一个量级。
更重要的是，独立IDE可以掌控数据流。Cursor团队能知道用户在哪些文件上花了最多时间、AI的建议被接受率是多少、哪些模型在哪个任务上表现好——这些数据可以用来优化AI交互，可以做差异化的产品功能。VS Code扩展拿不到这些数据，或者说，拿到了也无法在产品层面形成壁垒。
Windsurf、Zed、Replit也都是各自从不同角度切入vibe coding的。Zed主打性能，强调低延迟的AI响应；Replit把整个开发环境搬到浏览器里，让“描述需求、看到结果”的链路变得极短。它们的共性是从“环境”层面思考AI编程，而不是从“插件”层面思考。vibe coding需要的不是一个能聊天的编辑器，而是一个“你说需求，它就把环境搭好、代码写好、运行起来给你看结果”的完整闭环——这种闭环只有独立应用能提供。
5.2 CLI工具、Agent协议与浏览器端
除了独立IDE，CLI工具是vibe coding的另一个主场。Claude Code、Codex CLI、Kimi Code这类工具的成功，很大程度上击中了“终端内自主编程”这个真实场景。它们不是编辑器，但它们的输出比任何编辑器都更接近“交付结果”。
它们为什么能做到？因为CLI工具天然拥有“完整系统权限”——能读文件、能写文件、能执行命令、能pip install、能git commit、能启动服务、能curl调API。vibe coding的本质是“AI在真实环境中干活”，而CLI工具是让AI直接接触系统环境的最高效方式。VS Code扩展理论上也能调用这些东西，但受限于宿主架构，实际体验差很远。
还有一个新趋势，就是“Agent to Agent”的协议层工具。比如一些团队在做“AI项目经理”的概念——你在一个聊天界面里描述完需求，AI项目经理帮你拆解任务、排期，然后派发给多个子Agent去执行。这种工具通常以网页应用或CLI形态出现，因为多Agent协作需要的状态管理和消息传递已经超出了编辑器的范畴。想想看，如果这类工具做成了VS Code扩展，它得在渲染进程里维护一堆Agent状态，出了一点问题整个编辑器就卡死，这不现实。
浏览器端也是个被低估的方向。Replit、Google的Project IDX、GitHub Codespaces都在往“云端IDE + AI Agent”的方向走。它们的优势在于沙箱环境——AI可以在这个环境里随便折腾，装依赖、跑实验、试错，不会弄坏你本地的项目。这和本地vibe coding的体验完全不同，但它更接近“让AI放手去做”的理想状态。VS Code也有远程开发能力，IDE内置的Agent能力反而是个空档——微软把Agent能力做进了自家Copilot，但那是云端的、跟GitHub绑定的体系，和开放扩展生态是两条线。
6. 如果还想在VS Code里等一个好扩展，缺的是什么
6.1 几个可能被做出来的方向
说了这么多“为什么做不起来”，也得说说“如果要做，该往哪个方向做”。
我觉得首先值得尝试的方向是“Agent监控面板”。既然真正干活的agent在CLI里，VS Code扩展可以做的不是重复实现agent，而是成为一个“驾驶舱”——展示agent正在读哪些文件、改了什么、终端输出是什么、接下来打算做什么，让用户能在可视化界面里监控和干预。这个方向上目前没有特别成熟的产品，但它完美贴合VS Code扩展的定位：不做重型计算，做信息展示和交互控制。
第二个方向是“项目级上下文管理”。vibe coding经常遇到的问题，就是AI“看不懂”项目结构。一个扩展如果在编辑器中运行，它可以监听当前打开的文件、最近的Git提交、项目的README、依赖清单，然后自动构建一个精炼的上下文摘要，供外部agent或CLI工具调用。这本质上是一个“上下文打包器”，避开VS Code扩展的性能限制，发挥它“在编辑器里能感知用户当前注意力”的优势。
第三个方向是“AI代码审查的本地化”。现在的AI审查工具大多是云端的、事后的，而VS Code扩展特别适合做“提交前审查”——在git commit之前，扩展自动把暂存区的diff发给模型，检查常见问题、生成提交信息、甚至直接给出可复用的测试建议。这个场景对实时性要求不高、输入输出可控、逻辑清晰，是AI扩展最容易做出稳定体验的方向。
第四个方向是“工作流模板”。vibe coding的上手门槛其实不低，很多人问“我应该怎么描述需求AI才听得懂”。一个好的扩展可以做“项目向导”——根据用户选择的项目类型，自动生成一个包含明确步骤、验收标准、示例描述的需求模板，让AI明白这个项目该怎么做。这类想法不一定需要多强的模型能力，但对用户体验的提升很直接。
6.2 我的个人判断：扩展生态大概率不会爆发，但也不会消失
最后说说我的判断。我倾向于认为，VS Code的AI扩展生态在未来一年内不会出现像Copilot当年那样的爆发式增长，原因是结构性的——CLI工具和独立IDE已经抢占了vibe coding的核心场景，扩展能做的增量空间不大。
但这不意味着扩展生态会消失。VS Code依然有它不可替代的价值：它是全球开发者最熟悉的编辑器，它的扩展模型对轻量级工具依然友好。AI扩展会逐渐分化成两个阵营：一类是“深度集成型”，像Copilot一样成为编辑器体验的一部分，做补全、做修改、做审查；另一类是“场景工具型”，做某个特定痛点的解决方案，比如上下文打包、agent监控、工作流管理。
vibe coding这个趋势本身还在演化。它从最初“让AI写代码”变成今天“让AI自主完成项目全流程”，未来还可能走向多Agent协作、走向云端沙箱、走向更抽象的意图驱动开发。在这个过程中，VS Code的角色会越来越像一个“观察窗口”和“人工干预节点”，而不是主角。这不一定是坏事——一个好的工具生态从来不是所有功能都堆在一个壳里，而是各得其所。
如果让我给想入局的开发者一个建议：别去做“又一个聊天窗口”，去做那些和编辑器强相关的、CLI和IDE做不好的事。方向对了，扩展生态还是有机会长出几个好产品来的。
