几年前，我认真想过一次“叛逃”。
从 JetBrains 全家桶，转向更轻量的工具，比如 VS Code，甚至 Zed。那时候的我，理性上已经开始动摇，情感上却还在依赖。工作节奏快、项目复杂、deadline 像钟摆一样无情摆动——切换工具意味着学习成本、环境重建、快捷键肌肉记忆崩塌。于是每次都只是装一下 VS Code，配几个插件，惊叹两天，然后默默切回 IntelliJ。
浅尝则止，是成年人对“改变”的常见态度。
但最近一两年，我明显感受到 JetBrains 系列在走一条让我不太舒服的路。臃肿、启动慢、内存占用高，偶发卡顿，某些存在已久的 BUG 长期得不到修复。你能在 Reddit 上看到不少类似的抱怨：性能退化、升级后变慢、索引失控、插件冲突……当然，每个大型软件都会有这些问题，但当“重”成为一种常态，开发体验就开始被侵蚀。
更关键的是——时代变了。
AI 不是一个“插件功能”，而是一种开发范式的改变。
JetBrains 当然也在接入 AI，但它的架构天生更像传统 IDE 的延伸：强类型、深度索引、工程级抽象、静态分析驱动一切。这套体系在没有 AI 的时代是王者——自动补全精准、重构安全、代码导航强大。但在 AI 时代，很多“深度理解”已经可以由大模型完成，而且是跨语言、跨框架、跨上下文的。
当 AI 可以理解整段逻辑甚至整个仓库时，传统 IDE 的优势正在被稀释。
与此同时，JetBrains 的商业模式也让我开始犹豫。订阅制、价格不低。我已经连续续费了 5 年，说实话是一种惯性。熟悉的快捷键、熟悉的界面、熟悉的工作流——人类的大脑天然抗拒迁移。但今年，我决定不再续费。
不是因为它完全不好，而是因为它不再是“最优解”。
不过必须承认，JetBrains 也有一些让我至今念念不忘的设计。其中一个，就是那个几乎成了“肌肉记忆信仰”的功能——double shift。
连续按两下 Shift，Search Everywhere。
这个设计优雅到近乎哲学。它不是简单的文件搜索，而是一种“全局认知入口”。类、文件、Symbol、Action、配置项、Git 操作……你不需要记得它在哪个菜单，不需要记得快捷键，只要 double shift，然后输入几个模糊字符，世界就会自己收敛到你面前。
那一刻，你和工程之间没有层级结构，只有意图。
这种体验，其实是一种高度抽象后的统一接口。它把复杂 IDE 的所有能力压缩成一个搜索框。这种“极致统一入口”的设计思路，是 JetBrains 工程文化里非常闪光的一点。
VS Code 当然也有 Command Palette，也有全局搜索，但在整体一致性和细腻程度上，仍然差那么一点“浑然一体”的感觉。JetBrains 的 double shift 像是一种认知捷径，而不仅仅是功能入口。
这也是迁移过程中最让我不舍的部分。
但工具的演化，从来不是单点功能的比较，而是整体范式的迁移。
我开始逐步迁移到 VS Code。
VS Code 是一个很有意思的存在。它既不是传统意义上的文本编辑器，也不完全是重型 IDE。它更像一个“可编程外壳”——一个可以被插件不断重塑的开发平台。默认状态下它是轻量的，但通过插件你可以让它变成几乎任何形态。
最关键的是，它的 AI 插件生态极其活跃。
Copilot、各类对话式编程助手、上下文感知补全、基于大模型的重构建议……AI 插件的迭代速度远超传统 IDE 的更新节奏。某种意义上，VS Code 成为了 AI 开发工具创新的试验场。
当然，迁移不是没有代价。
JetBrains 的 Git Client 是我最怀念的部分之一。分支管理、rebase 可视化、冲突解决体验，都非常成熟。而 VS Code 原生 Git 功能，只能说“够用”，但不优雅。
于是我做了一个有点“分体式”的选择：VS Code + GitKraken Pro。
GitKraken 在 Git 交互体验上确实优秀，图形化操作直观、rebase 流程清晰、冲突处理友好。开通 Pro 版本后，一些团队协作能力也更完善。某种程度上，我把 JetBrains 的“全能 IDE”模式拆解成了“可组合工具链”。
这其实反映了一个更大的趋势：单体式 IDE 正在被模块化工具链取代。
过去我们追求“一体化”，因为整合意味着效率。现在我们追求“可组合”，因为 AI 让工具之间的边界变得柔软。编辑器负责交互，AI 负责理解，专用工具负责专业能力。每个组件只做好一件事。
更重要的是，VS Code 的性能模型更轻。内存占用更可控，启动更快，插件加载可管理。它不像一个庞大的工程机器，而更像一个不断进化的生态系统。
这不是情绪化的“JetBrains 已死”宣言。JetBrains 依然强大，尤其在大型 Java/Kotlin 项目、复杂重构场景下仍有不可替代的优势。它的 double shift、强类型重构、结构化导航，仍然是工业级打磨的代表。但在 AI 驱动开发的今天，灵活性、插件生态、开放性正在成为新的核心竞争力。
工具选择本质上是一种“认知结构”的选择。
你是希望工具替你构建完整的工程抽象？还是希望工具成为 AI 的接口，让你更自由地组合能力？我选择了后者。
也许几年后我会再次迁移。开发工具的历史，本质上就是抽象层不断上移的历史。从 Vim 到 IDE，从 IDE 到 AI 协作环境。我们并不是在选择编辑器，而是在选择与代码互动的方式。
当 AI 能够理解上下文、生成重构建议、解释陌生代码、甚至协助架构设计时，工具的核心不再是“功能多强”，而是“与智能协作的摩擦有多小”。
对我来说，26年将会是一个分水岭。