最近有朋友问我你现在写 Java 还用 IDEA 吗我说不装了已经卸了一个月。他一脸震惊好像程序员离开了 IDEA 就活不了。其实在 AI 写代码能力突飞猛进之后我越来越清楚地意识到IDEA 带给我的核心价值正在被一点一点替代补全、模板、查找、重构甚至代码解释AI 都能做。我所需要的渐渐只剩下一个能让 AI 跑起来、能让我快速看结果的入口。于是我做了一个有点冲动的实验去掉 IDEA 工具用一套以 AI 为核心、以终端为主场的轻量工作流写项目。这篇文章就是实验本身包括工具怎么选、迁移怎么干、有哪些坑以及什么情况下千万不要学我。1. 从“IDEA 重度用户”到“AI 副驾驶”的转变1.1 我原本依赖 IDEA 的哪些能力先说背景。我过去是标准的 JetBrains 系用户从早年间的 Eclipse 叛逃到 IntelliJ IDEA后来写 Python 用 PyCharm写前端也硬要把 WebStorm 装上。最疯狂的时候我电脑里同时开着三个 IDE16G 内存被吃得干干净净。IDEA 的索引一跑就是十几分钟风扇呜呜响但我从来没想过离开它因为它的确解决了几个非常刚的痛点。第一是智能补全。写 Java 的时候IDEA 能根据类型推断、泛型约束、已有依赖给出非常准确的补全。第二是全局查找CtrlShiftF 搜字符串AltF7 找方法调用点这是所有老码农的肌肉记忆。第三是重构重命名一个方法它会把注释、XML 配置、测试代码里的引用全部联动改掉。第四是调试器断点、表达式求值、Step Into/Out定位问题几乎是唯一路径。第五是框架集成Spring 的 Bean 注入、MyBatis 的 Mapper 映射它都能在 IDE 里画出可视关系图。这些东西在过去是不可替代的。但请注意一个关键事实IDEA 提供的不是能力本身而是“让人快速操作这些能力”的界面。当 AI 开始承担生成和理解工作之后界面本身的权重就下降了。打个比方过去你要去图书馆查资料必须熟悉索引柜、卡片的排列方式现在你直接问管理员管理员跑一圈把书抱给你你只需要会“提问”就行。IDEA 就是那个索引柜AI 是那个管理员。1.2 AI 补全和生成把场景切走了真正让我开始动摇的不是某一次 AI 写对了什么大项目而是一些很普通的日常。过去写一个 REST 接口我要先建 DTO、再写 Service、再写 Mapper再记得加注解每一步都需要 IDEA 的提示来减少返工。现在我用 AI 描述一句“给我生成一个用户注册接口包含参数校验、异常处理和测试类”它能在几秒内把一整套文件骨架写出来。我做的不是从零写代码而是 review、改一改边界条件、补点防御逻辑。这种工作方式的转变意味着什么意味着代码生成从“逐字逐句的 token 补全”变成了“文件级、模块级的生成”。IDEA 的补全再强本质还是在一个已有的句子中帮你想下一个词而 AI 直接帮你把整段文章写出来你再做编辑。虽然 IDEA 也有 AI Assistant 插件但我感觉到它更多是想把 AI 塞进原来的交互范式里而不是重新思考一个项目到底需要什么。另一个变化是我对“代码导航”的需求也在减少。以前我要看一个方法的实现得 CommandF12 在文件里跳来跳去。现在 AI 可以直接告诉我“这个方法在哪个文件、涉及哪些状态、有没有副作用”。它像一个读过整个仓库的同事我只需要用自然语言提问。慢慢地打开 IDEA、等待索引、点开 Project 面板这个启动动作变成了一种负担。1.3 真正让我动摇的几次对比我做过几次不太严谨但很有说服力的对比。用一个普通的后端需求“调整订单状态并发送通知”为例任务用 IDEA 的典型路径用 AI 终端的路径找到订单状态相关的全部代码关闭无关窗口用 AltF7 搜调用点逐个阅读rg orderStatus配合 AI 总结调用关系生成一个状态机流转逻辑手写 StateMachine 或者查旧代码复制描述状态和事件AI 给出实现我再补测试排查线上日志里一个堆栈报错复制异常栈在 IDEA 里关联源码用 Debug 模拟把异常栈丢给 AI它直接指出可能的原因和修复方向全局重命名一个 DTO 字段CtrlF6等索引检查改动用rg和 AI 脚本批量替换再编译验证你发现没有IDEA 依然很好用但它的好用集中在“手动操作”上。而我手动的欲望在 AI 时代急剧下降。这个对比里最致命的是“启动时间”我不需要为了看两行代码去加载一个 2GB 的 JVM 进程。很多次我只是在终端里想确认一个方法签名结果等 IDEA 起来之后我忘了要干什么。这种割裂感积累到一定程度实验的冲动就压不住了。2. 去掉 IDEA 之前我做的五项准备直接删除 IDEA 是不可能的至少对我这种手里压着几个老项目的人来说盲目卸载等于自杀。所以我用了大概一个星期做铺垫把准备过程拆成五件事。2.1 盘点存量项目和技术栈我先把本机和服务器上所有项目理了一遍。哪些是正在维护的 Java Spring Boot 服务哪些是 Python 脚本哪些是纯前端。每个项目的构建工具是 Maven、Gradle 还是 npm测试框架是什么有没有 Dockerfile部署流程依赖哪些 IDEA 的 Run Configuration。这一步的目的是划出“试点范围”。我给自己定了一个原则第一批迁移只选一个可以独立部署、依赖不能太复杂、测试相对完整的服务。千万不要从遗留单体项目开始那是给自己找不痛快。我选的是一个用户认证服务Spring Boot 3 MyBatis Plus PostgreSQL代码量不大但覆盖了 CRUD、缓存、定时任务和对外接口足够检验工作流。2.2 核心诉求清单不可让渡的能力我不玩极端“不要 IDEA”不代表“放弃一切工具”。在动手之前我列了一个清单写清楚哪些能力是绝对不可让渡的能快速查看项目目录结构和文件内容。能对代码进行精确的全局搜索与替换。能执行构建、测试、单文件运行。能有基本的断点调试能力哪怕是命令行调试器或日志调试。能舒服地处理 Git 操作。能方便地查看数据库、Redis 和其他中间件的状态。你注意这份清单里没有“基于 UI 的可视化重构”没有“自动导入依赖”也没有“Spring 的 Bean 关系图”。因为我评估下来这些都是可以被 AI 和命令行工具替代的只是替代方式需要适应。如果一个能力连替代思路都没有那它就必须留在 IDA 里不要强行搬走。2.3 替代工具链选型从 Cursor 到 CLI Agent工具选型是这场实验里最重要的一环。我试了三类工具最终确定了“轻量编辑器 终端 AI Agent 命令行工具”的组合。轻量编辑器我选了 VS Code 的 Remote Server 版本而不是继续用桌面版。因为我不想回到“本地 IDE”的老路更希望把代码放在一台配置统一的开发机上本地只保留一个终端窗口。VS Code Server 的好处是有 Web 界面临时用手机或者平板也能看代码改文件。对于纯文本编辑Neovim 也是不错的选择不过团队里大家习惯程度不同先用 VS Code Server 过渡更容易。AI 工具我拆成两层。一层是编辑器内的 Continue 插件做补全和选区问答另一层是终端里的 CLI Agent类似 OpenAI Codex CLI 或 Google Gemini CLI 这种直接读仓库、跑命令、提交代码。我最终用的是 Codex CLI因为它的沙箱机制让我觉得可控每次执行命令前都会展示影响范围。你可以根据自己已经开通的账号来选择关键点是编辑器内补全负责“小步快跑”CLI Agent 负责“跨文件的改动”。命令行工具方面ripgrep替代全局搜索fzf做交互式文件切换tmux管理多个会话jq解析 JSONgrc看日志颜色。数据库用psql和一个 Web 端管理工具Redis 用redis-cli。这套组合看起来很朴素但足够应付大多数日常开发。2.4 提前模拟一周无 IDEA 开发选型完成后我没有直接卸载而是先模拟了一周“只准用新工具不准打开 IDEA”。这周我还在原项目上做功能开发但所有操作都强迫自己走终端。头两天非常痛苦经常会下意识按 CtrlF12然后发现没反应再改用fzf。到第三天肌肉记忆开始松动效率基本恢复正常。第五天的时候我已经能比较自然地在终端里完成“改代码-跑测试-看日志”的循环。模拟周是整场实验最值得做的一步。它把大部分风险暴露在“还能回到 IDEA ”的时候。比如我发现没有 IDEA 的 Run Configuration 之后Spring Boot 多环境启动变得很麻烦于是提前把application-dev.yml和启动脚本的参数写好。又比如我发现 MyBatis XML 里的 resultMap 和 Java 属性对应关系没法用 UI 自动跳转就总结出一套 grep 配合 AI 的检查方法。这些问题如果在卸载后再遇到心态会崩。2.5 和团队约法三章这一点很多技术文不会提但我认为很重要。如果你的代码要提交到团队仓库不能因为自己搞“新工作流”就影响协作。我在实验前和团队打了招呼代码规范照旧提交信息格式照旧唯一的区别是“我可能用命令行为主”。另外我给自己定了一条纪律所有 AI 生成的关键逻辑必须在提交前由我逐行 review并且补上对业务含义的解释。这是对自己的底线也是防止“AI 写上瘾”导致代码不可维护。3. 卸载 IDEA 后的轻量工作流搭建步骤准备工作做完我选了一个周五晚上把 IDEA 和相关的 JetBrains 工具链全部卸载然后开始从零搭环境。整个过程分成五步每一步都有可以照抄的细节。3.1 基础环境终端 VS Code Server tmux我选择在一台 Ubuntu 22.04 的开发机上操作。安装 VS Code Server 很简单使用code-server二进制包或者官方 Remote-SSH 插件连上去都行。我更推荐 Remote-SSH因为这样可以用本地 VS Code 客户端的习惯又不需要在本地保存代码文件。顺手把终端环境调成对自己友好的状态Zsh oh-my-zsh加上zsh-autosuggestions和zsh-syntax-highlighting两个插件。接着安装 tmux创建一个多窗口布局窗口一放编辑器服务窗口二跑构建和日志窗口三专门跑 AI CLI。# 在开发机上启动 VS Code Server示例使用 code-server curl -fsSL https://code-server.dev/install.sh | sh code-server --port 8080 --auth none --bind-addr 0.0.0.0 # tmux 布局三个窗口 tmux new -s dev Ctrl-b c # 新开窗口 Ctrl-b c # 再开一个这套环境看起来没什么技术含量但它解决了两个被 IDEA 时代忽略了的问题会话不因为本地电脑重启而断开代码和 AI 工具在同一台机器上协同。以前本地 IDEA 连接远程服务器时经常遇到索引不同步的问题现在本地只有一个终端远程就是全部环境。3.2 AI 编码工具的三层配置我的 AI 工具不是单一入口而是分三层。第一层是代码补全我使用 Continue 插件配置成混合模型补全走本地小模型聊天走云端大模型。这样基础补全不依赖网络聊天质量又足够高。第二层是终端里的大模型 CLI。这类工具一般需要 API Key我把它写到环境变量里并且限定它只能访问指定工作目录。使用上我会直接问它“当前分支相比 main 改了什么有没有潜在 bug”或者“帮我给这个接口补一个失败场景的单元测试”。它给我的不光是答案还能直接生成 diff。第三层是写脚本和自动化流程。这时候不需要和 AI 长篇对话而是让它生成一个 Python 或 Shell 脚本然后我自己跑。比如批量修改模块导入路径、生成 MyBatis Mapper 的 XML 片段、把 JSON 响应转换成 TypeScript 类型定义。这种脚本越积累越多最后变成了一个scripts/目录相当于我自己的“个人脚手架”。# AI CLI 的一个典型会话 $ ai 找出 UserService 里所有用 Autowired 的字段统计它们注入的 Bean # - 返回字段列表和可能的使用风险3.3 构建与运行从 Run 按钮到 Makefile 和脚本IDEA 里最常见的操作其实是点击右上角的绿色运行按钮。这一步背后是 Maven 或 Gradle 的坐标以及 IDEA 自动生成的一份 Run Configuration。脱离 IDEA 后我统一用 Makefile 把这些命令固化下来。一个 Spring Boot 项目的 Makefile 大概长这样dev: mvn spring-boot:run -Dspring-boot.run.profilesdev test: mvn test -DskipITs build: mvn clean package -DskipTests deploy: scp target/app.jar userserver:/opt/app/ ssh userserver systemctl restart app写完之后我所有的运行动作变成两条命令make dev启动make test跑测试。不要小看这个转变它把“环境配置”从 IDE 的私有配置里解放出来变成仓库内的显式文件。新同事拿到代码后不再需要导入 IDEA 工程直接 make 就能跑。这个收益即使你以后继续用 IDEA也值得做。3.4 调试与测试没有断点 UI 怎么办最大的恐惧通常来自“没有可视化断点”。一开始我也担心但实战下来发现在 Java 这种语言里命令行调试器的效率并没有想象中那么不堪。Spring Boot 应用可以用远程调试方式启动然后本地用jdb连接。只是现代代码问题更多地出现在数据流转和复杂业务状态上纯断点不一定能解决问题反而需要日志和测试来定位。我现在的组合是“AI 分析异常栈 精准日志 单测验证”。举个例子接口报 NullPointerException我先让 AI 看看异常发生位置的代码它往往会指出哪个引用可能为空。我再根据提示在可疑的返回点加一行日志重新跑一次基本就能确认。如果问题非常复杂还可以用 JUnit 写一个最小复现测试而不是打开 Debug 慢慢看。另外没有 IDEA 之后assertEquals和覆盖率报告反而成了我的第一读者。写完代码跑一遍测试用openjdk生成的 JaCoCo 报告看覆盖情况比用断点看得更系统。这算是“被逼出来”的好习惯。3.5 Git、重构和每日流程怎么落地Git 操作没什么悬念命令行本来就是 Git 的根。我配置了几个别名比如git st、git lg、git co配合fzf分支切换日常操作不比 IDEA 慢。前半个星期的适应成本主要在“改文件名后有没有把引用改干净”后来我用git mv并让 AI 检查一遍引用就顺了。每日流程固定为开工前先git pull --rebase然后打开 tmux 里昨天的日志窗口看有没有告警写代码阶段用 Continue 做补全复杂改动交给 AI CLI 生成 diff我 review 后应用跑完测试后生成提交信息git commit前再用git diff最后扫一遍。整套流程里IDEA 曾经承担的“上下文记忆”角色由 AI CLI 和我的操作记录替代了。4. 实战中踩过的坑与对应解法说点实话这一周不是处处丝滑。以下坑我都真实踩过解法也经过验证你如果也想去掉 IDEA提前知道能省至少一天时间。4.1 大文件、长路径和编码问题第一个坑来自我的 Windows 本机代码放在 D 盘很深的目录里项目里有几个前端依赖把文件名搞得很长。IDEA 对长路径有内部处理终端工具往往直接报“文件不存在”。我最初用rg搜关键字怎么都搜不到结果后来才发现其中一个中间目录名被截断了。解法是统一把项目克隆到开发机的/data/work/平铺目录下不要在本地 Windows 上跑。另外把.gitattributes统一配置成* textauto避免换行符和编码在不同平台之间产生 diff。开发机统一用 UTF-8文件 IO 不乱码。4.2 Spring/MyBatis 这类框架的代码导航IDEA 对 Spring 和 MyBatis 的加持确实存在。MyBatis 里Mapper 接口和 XML 的 resultMap 是通过“魔法字符串”对应的IDEA 能识别并跳转命令行环境下就没有这种便利了。我一开始用rg找出 Mapper 接口里的方法名再去 XML 里搜同名id手动比对参数类型非常费劲。后来我让 AI 帮我写了一个小脚本扫描Mapper.xml和接口自动检查方法名和返回类型是否一致并把不一致的列出来。这个脚本只有几十行但解决了我最大的痛点。这件事给我一个启发传统 IDE 的“静态分析能力”不是消失了而是可以转化为轻量脚本和 AI 的组合只不过需要你亲自去定制。4.3 AI 生成代码的质量问题AI 生成的代码看似能跑但藏着很多“漂亮的坑”。我在某个服务里让 AI 生成一个批量导入功能它用了 Java 17 的新Stream.toList()代码很简洁。可项目基础环境是 Java 11编译直接失败。这是模型训练数据过新导致的。还有一个更隐蔽的问题AI 会默认使用一些不存在的库版本。比如它给出的 Maven 依赖坐标里httpclient版本号看起来合理但实际仓库里不存在。解决办法是启用 Maven 仓库的镜像并让mvn dependency:tree在 CI 里作为必跑步骤一旦依赖解析失败就立刻暴露。AI 代码必须配合编译和测试一起看不能只看逻辑。4.4 重构和全局改名的坑我早期依赖 IDEA 的 Refactor 特别重。这次实验里我把一个 DTO 的字段userName改成nickname用 AI 写的 sed 命令全局替换结果把 XML 里的 SQL 别名、Redis 键名、前端传参全部一起改了有的不该改有的该改没改到因为user_name是下划线风格没被匹配。此后我定了规矩跨文件改名必须用ripgrep先看所有匹配点然后分批次替换每批替换后跑一次编译和测试更保险的做法是让 AI 生成一个“变更影响清单”而不是直接让 AI 动手改。虽然多了几步但不会半夜被线上问题叫醒。4.5 依赖冲突和 Maven/Gradle 调试IDEA 的 Maven 工具窗格可以图形化看依赖树冲突时标红。换成命令行后我依赖mvn dependency:tree和mvn dependency:analyze。刚开始觉得输出太长后来配合grep过滤出冲突项再用 AI 解释冲突来源。其实 IDEA 后端也是分析的同一份 POM 模型命令行和高频搜索完全可以把问题定位清楚。如果遇到需要排除某个传递依赖的情况我会先在dependency:tree里确认坐标然后手工在 pom.xml 加入exclusions。这个操作高频但简单熟练后一分钟内解决不需要 UI。5. 什么场景适合去掉 IDE什么场景必须保留一个月的实验结束后我没有成为一个“极端命令行主义战士”。相反我更清楚哪些场景下 IDEA 依然不可战胜。5.1 适合轻量化 AI 工作流的四种项目类型基于 Spring Boot 的标准微服务结构清晰依赖稳定AI 生成效率高命令行构建测试链路顺畅。个人工具类项目没有复杂的多模块依赖作者自己清楚全局不需要 IDE 的可视化导航。以 Python、Go、TypeScript 为主的中小型服务这些语言本身比 Java 更适合命令行工具链。已经具备良好测试覆盖、CI 管线成熟的项目每次改动都有自动化闸门把关出错的成本低。5.2 还需要保留 IDEA 的三类情况第一类是大型遗留单体项目代码量几十万个类模块之间靠 IDE 索引和全局查找才能理清关系。AI 在这种规模下容易迷失上下文光靠rg会找漏。第二类是需要深度调试的并发问题比如锁竞争、死锁、线程状态切换命令行jdb实在太不直观IDEA 的调试 UI 在这里依然是效率神器。第三类是团队标准环境已经是 JetBrains 全家桶的情况如果你一个人用命令行同事打开你的项目时还是基于 IDEA 的.idea文件这会产生协作摩擦。5.3 我目前的最终配置和建议分级我现在没有彻底安装回 IDEA但保留了 JetBrains 的评估版本不主动打开。日常 80% 时间用终端 AI 组合遇到特别复杂的重构或线上疑难杂症时我可能会打开 IDEA 花十分钟解决然后继续回到轻量工作流。这听起来“不够纯粹”但很务实。使用人群建议刚入行的开发者不建议去掉 IDEA先通过 IDE 建立代码前后端关系和调试手感有三年以上经验的开发者可以尝试一周实验先从一个小项目开始不要直接删主项目团队负责人别强制统一工具允许个人工作流差异但统一提交和构建规范极客玩家、工具控放心大胆折腾终端方案注意给 AI 工具配好权限和沙箱我的最终结论是去掉 IDEA 不是目的重组自己的工作流才是。IDEA 曾经是“帮你管理复杂度的工具”AI 出现后管理复杂度的方式变了IDE 自然也失去了一部分存在价值。但这也意味着如果哪天 AI 变得不可用我还能熟练切回 IDEA这份能力没有丢。最后分享一个我在实验里养成的小习惯特别适合想尝试的人先不要卸载 IDEA而是在 IDEA 设置里关掉“打开项目时自动索引”强制自己通过终端操作一周。这一周你的肌肉记忆会告诉你哪些能力是虚假依赖哪些是真正离不开的。等你想清楚了再决定去留不仅不痛苦还会发现那个笨重的 IDE 突然变得轻盈了许多。
