JetBrains绝地反击：Junie登顶，IDE之王把AI编程抢回来了

2026年7月2日，一条消息在开发者社区炸开了锅。

JetBrains Junie正式版发布，在SWE-Rebench基准测试中以61.6%任务解决率登顶编码智能体榜首。不是OpenAI，不是Anthropic，不是那家被SpaceX花600亿美元买下的Cursor。是一家做IDE做了25年的捷克公司。

这个排名的冲击力，相当于诺基亚突然发布了一款干掉iPhone的手机。

过去两年，AI编程的叙事一直被一条主线牢牢把控：新贵颠覆老钱。Cursor从0做到年收入140亿，Claude Code从一个内部小工具长成Anthropic半条命，Copilot从代码补全演进到自主Agent。传统IDE厂商在这条叙事里扮演的角色很统一——被颠覆的对象。JetBrains的IntelliJ IDEA被嘲"太重"，VS Code被夸"够轻"。仿佛IDE越强大，反而越像个累赘。

Junie用一次登顶，把这个叙事打翻了。

不是换皮插件，是让Agent住进IDE的骨子里

大多数AI编程工具和IDE的关系，本质上是一层皮。Cursor基于VS Code Fork，Copilot是插件，Claude Code是终端。它们和IDE共享一个界面，但不共享一个灵魂。它们读你的代码，但不理解你的项目结构。它们能补全你的函数，但不知道你的断点打在哪。

Junie走了另一条路。

它不是插件，是IDE原生的编码智能体。它可以直接接管IDE的调试器——不是生成调试建议让你手动执行，是自己打断点、自己运行、自己看变量、自己找到bug根因。它可以在你写代码之前先出一个执行计划，不是那种"我建议你这样写"的废话，是结构化的任务分解：先确认需求边界，再检索相关代码，再设计方案，最后动手。

JetBrains管这叫"先计划后编码"模式。实测下来，无效执行和Token浪费大幅下降。因为Agent不再盲目自信地在错误方向上狂奔，而是先停下来想一想。

这才是AI编程工具一直没有解决的问题：不是能力不够，是冲动不够克制。

无厂商锁定：一个被行业假装看不见的痛点

Junie还有一个让行业沉默的特征：不绑定任何模型。

你可以用OpenAI的GPT-5.6，可以用Anthropic的Claude Fable 5，可以用Google的Gemini，甚至可以在本地跑一个开源的DeepSeek。Junie不关心模型来自哪家，它只管调度。

这件事的潜台词很锋利。

Cursor虽然支持切换模型，但它的默认体验深度绑定自己的模型。Copilot深度绑定OpenAI。Claude Code就更不用说了。每一个AI编程工具都在用"最好的模型"作为护城河，实际上是在用模型锁定用户。你今天习惯了一个工具的工作流、快捷键、上下文管理方式，明天它涨价了，你换还是不换？

Junie把这个锁拆了。你可以在任何模型之间自由切换，工具不变。这意味着AI编程工具的价值锚点，第一次从"接入什么模型"转向了"提供什么开发体验"。对开发者来说，这是一次权力的归还。

为什么是JetBrains？答案藏在15M开发者身上

很多人会问：JetBrains凭什么？

答案在数据里。JetBrains IDE拥有超过1500万开发者用户。这1500万人不是在用AI编程工具做Side Project，他们是在写企业级Java、C++、Python项目。他们面对的不是一个单文件脚本，是几百个模块、几十万行代码、复杂的依赖图和遗留系统。

Junie能登顶SWE-Rebench，不是因为模型更强，是因为它对"真实的项目"理解更深。SWE-Rebench的测试任务来自GitHub上真实的Issue和PR，涉及多文件修改、跨模块依赖、复杂上下文。这正是JetBrains IDE积累了25年的领域知识。它知道你项目里的每个类定义在哪，知道你的依赖图长什么样，知道你的测试覆盖率缺口在哪里。

Cursor的优势是轻。Junie的优势是深。

轻让她跑得快，深让她走得远。一场AI编程的军备竞赛，战场正在从"谁生成代码更快"变成"谁理解项目更深"。

JetBrains Air：一张正在翻转的底牌

Junie发布的同时，JetBrains还放出了Air——一个全新的Agentic IDE，目前处于公开预览阶段。

Air的出身很微妙。它基于被放弃的Fleet IDE代码库重建。Fleet当年被定位为"轻量级多语言IDE"，对标VS Code，但一直不温不火，最终被搁置。现在JetBrains把它从坟里挖出来，装上多Agent并行引擎，支持OpenAI Codex、Anthropic Claude Agent、Google Gemini CLI和自家的Junie同时在一个工作区协同工作。

"多个AI Agent并行跑任务"，这个概念Cursor和Copilot都在讲。但Air的做法不一样：它不是让一个Agent做所有事，而是让多个Agent各自负责不同的子任务——一个改前端，一个修后端，一个跑测试——全在同一个工作区里并行推进。状态同步通过ACP（Agent Client Protocol）协议完成。

这听起来像一个开发团队的微缩版。过去你招人组团队，现在你调度Agent组团队。

坏消息是：IDE的战争没有赢家，只有幸存者

Junie登顶SWE-Rebench同一天，JetBrains宣布2026.1版本全线支持ACP Registry——不只是自家的Junie，Cursor、Copilot都可以通过ACP协议接入JetBrains IDE。

这件事最耐人寻味的地方在于：JetBrains在用一个开放协议，把竞争对手变成自己的插件。你在IntelliJ IDEA里写Java，AI能力可以来自Cursor、可以来自Copilot、可以来自Junie。JetBrains不阻止你选谁，它只是让你选择的范围落在它的IDE里。

这比"我的Agent比你的强"高了一个维度。这是用平台思维打工具战争。

但反过来看，JetBrains走到这一步，本身就是被逼的。如果Cursor没有用两年时间从0做到140亿，如果Copilot没有逼到GitHub把整个平台All-in AI，JetBrains大概还在慢慢打磨下一个版本的代码补全。绝地反击的前提，是你已经在绝地了。

最后一句

AI编程工具花了两年证明自己能写代码。接下来两年，它们要证明自己值得信任。

而Junie的登顶，只是这场信任战争的第一枪。