发布时间

我的 IDE 之旅：从 JetBrains 到 Claude Code

我们选择的工具，不只是塑造代码，也塑造思维。这就是我穿越三种截然不同 IDE 哲学的旅程故事：它们分别教会了我关于生产力、控制力，以及开发者与机器关系的不同理解。最初它只是一次追求效率的尝试，最后却变成了一个发现：有时候，少真的就是多。⌨️

IDE 的哲学：超越功能清单 🧭

IDE 作为工作哲学

每一种集成开发环境，其实都体现了一种关于人类应该如何与代码交互的哲学：

JetBrains：集成式卓越

  • 哲学：“你需要的一切，都被完美集成在一起”
  • 每项任务都能一键完成
  • 把按语言定制优化做到极致

VSCode：通用适配器

  • 哲学：“一个工具覆盖所有语言”
  • 在所有项目之间保持轻量与可移植
  • 配置即代码，处处同步

Neovim + Claude Code：键盘优先的未来

  • 哲学：“少即是多，AI 是你的结对程序员”
  • 两个窗口：聊天与 diff
  • 完整键盘控制，统一心智模型

第一阶段：JetBrains 时代 - “一体化解决方案” 🏢

第一次接触专业工具

当我第一次开始认真写代码时，从基础编辑器切换过来的冲击非常强烈。JetBrains IDEs 代表的是生产力上的量子跃迁：

集成承诺：

  • PyCharm 用于 Python——智能补全仿佛能读心
  • IntelliJ IDEA 用于 Java——重构功能几乎总是可靠
  • WebStorm 用于 JavaScript——内建整个前端生态所需工具
  • One-Button Everything：运行、调试、测试、部署——都能通过单个快捷键完成

它为什么这么强：

把一切都集成起来所带来的力量，真的很让人上头。函数补全不只是 autocomplete——它能理解上下文、建议更好的模式、在编译前发现错误。语法检查也不只是看语法，它还会建议更符合语言习惯的写法。点一下按钮，就能带着完整调试能力运行你的应用。

对于初学者来说，这种体验是颠覆性的。你不用配置构建系统，不用单独搭调试器，也不用手动把命令行工具串起来。IDE 帮你处理复杂性，让你可以把精力集中在学习语言本身。

裂缝开始出现

但随着项目越来越复杂，一些无法忽视的模式逐渐浮现：

多 IDE 问题：

  • Python 项目？打开 PyCharm
  • Java 服务？切到 IntelliJ
  • 前端工作？启动 WebStorm
  • 每个 IDE：不同的内存占用、独立配置、各自独特的键位

配置噩梦：

跨语言项目——而这在现代开发中越来越常见——开始变得痛苦。一个典型的微服务项目可能同时包含：

  • Python backend（PyCharm）
  • Java services（IntelliJ）
  • React frontend（WebStorm）
  • Shell scripts 和 configs（？）

结果就是：配置碎片化。每个 IDE 都维护着自己的一套：

  • 代码风格设置
  • 键位自定义
  • 插件配置
  • 数据库连接

手动保持这些东西同步既繁琐又容易出错。我发现自己不断在不同语言之间切换，同时还要在完全不同的代码导航心智模型之间切换。

资源成本：

同时运行多个 JetBrains IDE 会消耗大量系统资源。为了打开一个简单配置文件，就要启动一个数百 MB 的应用。高度集成的卓越体验，伴随着沉重的资源代价。

觉悟时刻

那个我们无法再忍受的缺点是：按语言 silo 切割导致的配置碎片化。当混合型项目逐渐从例外变成常态时，JetBrains 模式开始显露出年代感。我们需要一种能够以一致配置和合理资源占用处理所有语言的方案。

第二阶段：VSCode 转向 - “统一环境” 🌐

轻量化革命

Visual Studio Code 成了 JetBrains 配置碎片化问题的答案：

通用解决方案：

  • 一个编辑器处理一切：Python、JavaScript、Rust、Go、Markdown——全都在同一个窗口里
  • 轻量足迹：启动快，内存占用合理
  • Settings Sync：一套配置，通过 GitHub/Microsoft 账号同步到所有机器
  • Remote Development：SSH 到远程机器上，像本地一样编码

工作流转变：

第一次，我可以：

  1. 打开一个同时包含 backend + frontend + infrastructure code 的 monorepo
  2. 在所有文件类型中使用一致的键位绑定
  3. 在工作电脑、个人桌面机和远程服务器之间共享设置
  4. 在不同项目之间瞬间切换，而不必启动笨重 IDE

扩展生态：

VSCode 的插件系统带来了前所未有的灵活性：

  • 任何语言都能通过 language servers 获得智能补全
  • Formatters、linters、debuggers——全部按需安装
  • 无需 IDE 厂商锁定也能更换主题和定制体验
  • 社区驱动的创新速度快得惊人

鼠标问题开始浮现

几年过去后，VSCode 成了我的日常主力。配置同步顺滑，远程开发也几乎无可挑剔。但新的挫败感也在慢慢积累：

不一致的键盘控制：

不同插件有不同的交互模型：

  • 文件浏览器：方向键加回车
  • 搜索面板：自定义快捷键
  • 调试器：一部分是键盘快捷键，一部分仍需要点击
  • Git 集成：有些命令能走键盘，有些只能靠鼠标
  • 设置 UI：大量依赖鼠标

VSCode 的 Command Palette（Ctrl+Shift+P）确实有帮助——很多操作可以通过键盘触发。但并不是全部。有些功能只存在于右键菜单里，有些扩展 UI 里的按钮根本没有键盘等价物。

VIM 插件的失望：

我也尝试过 VSCode 的 vim 插件。它们在文本缓冲区里提供了模态编辑——但也就仅此而已。一旦你需要与侧栏、面板或扩展 UI 交互，就又得回到鼠标。那种我一直渴望的统一心智模型，始终没能真正出现。

AI Agent 革命

然后，Code Agent 时代来了：

  • GitHub Copilot 证明 AI 能写样板代码
  • Cursor IDE 展示了 AI-first 编辑体验
  • Claude Code 则把 LLM agents 带到了命令行

这引入了一种新的范式：对话式编码。你不再需要点来点去地操作 UI，而是可以直接描述你想做什么，再让 AI 去执行这些操作。

觉悟时刻

那个我们无法再忍受的缺点变成了：被迫依赖鼠标，打断键盘工作流。当你高度专注时，每一次手离开键盘去碰鼠标，都会打断动量。对于拥抱 VIM 模态编辑哲学的开发者来说，VSCode 对鼠标的依赖像是持续不断的摩擦。

更重要的是：AI agents 指向了一个更简单的未来。如果 LLM 能读代码、理解意图并直接做修改，也许我们根本不再需要复杂的 IDE UI。

第三阶段：Neovim + Claude Code - “键盘优先的未来” ⌨️

极简主义觉醒

转向 Neovim + Claude Code 不是在增加功能，而是在移除一切非必要之物：

双窗口范式：

我现在的整个开发环境，只由下面两部分组成：

  1. 运行 Claude Code 的终端窗口：AI agent 聊天界面
  2. 显示 diff 的第二个终端：看清楚改了什么、正在改什么

就这么多。没有侧栏。没有文件浏览器 UI。没有扩展面板。只有：

  • 与 AI 的自然语言对话
  • 代码 diff 审查
  • 通过 VIM 键位实现的完整键盘控制

工作流：

# Terminal 1: Claude Code
$ claude-code
> "Add error handling to the API client in src/api.rs"
> "Run the tests and fix any failures"
> "Refactor the database module to use async/await"

# Terminal 2: Watch changes
# Use lazygit or git diff buffer to review changes

这带来了什么：

统一心智模型：

  • 到处都是 VIM 导航——文件跳转、代码编辑、窗口管理
  • 只需要记住一套键位系统
  • 肌肉记忆能在所有操作之间迁移

AI 作为结对程序员：

  • Claude Code 负责搜索文件、修改代码、运行测试
  • 你在 diff 视图中审查改动，决定批准还是继续迭代
  • 关注点从“怎么实现”转移到“实现什么”

上下文保持：

  • 没有 UI chrome 消耗认知带宽
  • 两个窗口 = 两个清晰上下文（对话 + 代码）
  • 没有隐藏侧栏，没有突如其来的弹窗
  • 终端环境 = 可脚本化、可自动化、透明

具体优势

1. 完整键盘控制：

每个操作都能映射到 VIM 逻辑：

  • 文件导航：:e、通过 telescope/fzf 进行模糊查找
  • 代码跳转：gd（跳到定义）、gr（references）
  • 窗口管理：Ctrl+w 组合
  • 终端集成：:terminal 或 tmux panes
  • Git 操作：fugitive 插件或 CLI 命令

2. AI 增强工作流：

Claude Code 负责：

  • 跨多个文件的复杂重构
  • 生成和修复测试
  • 编写文档
  • 代码审查与建议
  • 终端命令执行

你负责：

  • 高层设计决策
  • 代码审查与批准
  • 意图说明
  • 最终验证

3. 资源效率：

  • Neovim：约 10-50MB 内存占用
  • Claude Code：CLI 工具，开销极低
  • 总计：仅为 VSCode 或 JetBrains 占用的一小部分
  • 瞬时启动，没有索引等待

4. Remote Development 更自然：

  • SSH + 终端 = 完美远程开发
  • 没有协议额外开销（不同于 VSCode remote）
  • 到处都是同一套配置（dotfiles）
  • 慢速连接下也能工作

学习曲线的现实

这种方式当然也有成本：

需要投入时间：

  • 学会 VIM motions 需要几周才能自然
  • 配置 Neovim 需要理解 Lua/Vimscript
  • 写出高效的 Claude Code prompts 也需要练习
  • 没有可视化 debugger UI 时，调试需要切换心智模型

并不是所有事情都更容易：

  • 可视化调试（断点、watch windows）更复杂
  • GUI 较重的任务（如数据库浏览）需要额外工具
  • 团队成员可能不理解你的工作流
  • 有些工具默认假设 IDE 集成存在

但关键在这里：

真正推动工具迁移的，是那些我们无法再忍受的缺点。对我来说，鼠标依赖和碎片化心智模型最终变得不可接受。投入时间去学 VIM + Claude Code 是值得的，因为它消除了我无法容忍的摩擦。

对其他人来说，可视化调试或集成数据库工具的优势也许比键盘效率更重要。这完全合理——不同的人，无法忍受的缺点本来就不同。

“少即是多”的哲学

把 IDE 缩减成两个终端窗口，并不是为了审美意义上的极简主义，而是因为：

降低认知负担：

  • 更少 UI 元素 = 更少视觉解析
  • 一套键位系统 = 更少心智上下文切换
  • AI 处理实现细节 = 更多时间思考架构

有意图性：

  • 每个存在的工具都是主动选择的结果
  • 每个键位都是刻意映射的
  • 每条工作流都是有意识设计出来的

优化心流：

  • 双手永远不离开键盘
  • 上下文切换被压到最低
  • 卡住时，AI 结对编程能继续保持节奏

转变：从工具使用者到工作流创造者 🚀

这段旅程与我的Arch Linux 经历如出一辙——从消费预构建方案，转向打造个性化工作流。

第一阶段（JetBrains）： 接受一体化方案，信任厂商的选择

第二阶段（VSCode）： 大量定制，但仍然受限于扩展生态的边界

第三阶段（Neovim + Claude Code）： 从原语构建自己的环境，控制每一个方面

这个模式非常清晰：每一次迁移，都是在用便利交换控制力，用预构建交换个性化。

这段旅程适合谁

如果你符合下面这些条件，这套工作流会很有意义：

  • ✅ 你已经适应命令行环境
  • ✅ 你更重视键盘效率，而不是可视化工具
  • ✅ 你经常处理跨语言/混合型项目
  • ✅ 你对 AI 辅助编程感到兴奋
  • ✅ 你喜欢配置和工作流优化
  • ✅ 你愿意投入时间学习 VIM

如果你是下面这些情况，这套工作流可能不太适合：

  • ❌ 你主要只在单一语言/生态里工作
  • ❌ 你的团队高度依赖 IDE 专属功能
  • ❌ 可视化调试对你的工作流至关重要
  • ❌ 你更喜欢预配置工具，而不是自己定制
  • ❌ 你觉得学习曲线所花的时间没有价值

这也没关系。 目标不是说服所有人都去用 VIM 和 Claude Code。目标是识别出某个工具的哪些缺点已经对你个人变得不可忍受，并且有勇气去探索替代方案。

展望未来：AI-Native 开发时代 🌟

我们正站在软件开发工具的拐点上：

旧模型：

  • IDE 提供各种功能：completion、refactoring、debugging
  • 开发者通过鼠标/键盘驱动所有操作
  • AI（Copilot）提供建议式辅助

正在出现的新模型：

  • 开发者以对话方式描述意图
  • AI agent 执行操作：搜索、编辑、测试、重构
  • 开发者通过自然语言审查和引导
  • 键盘驱动的 review 与批准

Claude Code 代表了这一模型的早期阶段。未来的迭代可能会带来：

  • 更强上下文感知：AI 理解整个代码库架构
  • 主动建议：“我注意到这里有个模式，要不要我帮你重构？”
  • 多文件推理：“这三个模块应该一起重新设计”
  • 测试驱动 AI：“我先写测试，再开始实现”

双窗口范式（对话 + diff）也许就是未来的界面——不是尽管它简单，而是正因为它简单。

结语：拥抱那些你无法忍受的缺点 🎯

这段 IDE 之旅给了我一个结论：

工具迁移并不是因为缺少功能，而是因为你再也无法忍受某些缺点。

  • 当配置碎片化变得无法忍受时，我离开了 JetBrains
  • 当鼠标依赖破坏工作流时，我离开了 VSCode
  • 当AI 辅助、键盘优先的编码成为可能时，我拥抱了 Neovim + Claude Code

你无法忍受的点，也许会不同：

  • 也许可视化调试对你来说不可妥协
  • 也许团队协作功能最重要
  • 也许集成式工具能更有效地减轻你的认知负担

这正是重点。 最好的 IDE，就是那个能消除你的摩擦点的工具，即便它也会引入别人不能接受的取舍。

元层面的启示

这段旅程与Arch Linux 哲学形成了对应：

  • Windows/macOS ↔ JetBrains：集成式、强主张、开箱即用
  • Linux ↔ VSCode：可配置、可扩展、跨平台
  • Arch Linux ↔ Neovim + Claude Code：从原语构建、完全掌控

两边的演进路径其实都是：

  1. 便利优先：接受预构建方案
  2. 灵活性浮现：发现配置空间
  3. 创造者心态：从零构建个性化工作流

每走一步，都需要更多投入，但也会换来更高程度的思维对齐。

最后的想法

如果你正在做小型跨语言项目，并且对AI 辅助编程充满兴趣，我觉得这套工作流会与你产生共鸣。因为下面这些元素组合在一起：

  • 统一的 VIM 键位覆盖所有操作
  • 通过 Claude Code 进行 AI 结对编程
  • 极简 UI 降低认知负担
  • 对环境的完全控制

……会创造出一种更像是与代码库对话，而不是操作 IDE 的开发体验。

但请记住：真正有智慧的人，也能欣赏与自己不同的选择中所蕴含的智慧。无论你最终选择 JetBrains 的集成体验、VSCode 的灵活性，还是 Neovim + Claude Code 的键盘优先 AI 辅助——都请在充分理解自己获得什么、又放弃什么的前提下做出选择。

祝你编码愉快，学习愉快，创造愉快！💻✨🤖

这篇文章记录了我截至 2025 年 10 月的 IDE 旅程。工具会不断变化，但原则不会变：当某些缺点变得无法忍受时，就勇敢拥抱变化。