说实话我花了不少时间才做这个决定。以前每天早上打开电脑第一件事就是启动 IntelliJ IDEA等它把项目索引完再开始一天的工作。可在 AI 编程工具用了半年多之后我突然意识到一个问题我打开 IDEA大部分时间竟然不是写代码而是在等它启动、等它索引、等它转圈圈。真正动手敲代码的时长越来越少反而是跟 AI 对话、审查它生成的代码、再让 build 脚本跑测试占掉了绝大多数时间。于是我开始认真思考一个以前根本不会考虑的问题当 AI 已经把写代码这件事从“人敲键盘”变成“人提需求、AI 产出、人审查”之后像 IDEA 这样以“深度索引 精准补全 重型重构”为核心卖点的 IDE对我来说到底还是不是必需品这篇博文就聊聊我最后为什么卸掉 IDEA换成了什么样的工具链以及在迁移过程中踩过的坑和总结出来的经验。不劝你盲目照做但如果你也有类似的体感我的这套方案值得抄一抄。1. 离开 IDEA 的真实原因它解决的不再是我的问题了1.1 我还在用 IDEA但使用它的方式已经变了先说结论我并不是因为 IDEA 不好才离开它。相反我一直觉得 IntelliJ IDEA 是同类产品里做得最扎实的尤其是 Java 领域它的补全、重构、索引能力到今天依然是第一梯队。但问题恰恰出在这里。IDEA 的强项是假设你是一个“以手写代码为中心”的开发者你打开一个几十万行代码的工程需要快速理解结构、跳转定义、搜索引用、重构方法IDE 帮你把项目变成一个巨大的、可导航的信息网络。这套逻辑在过去十年里非常成立我也靠它吃饭吃了很多年。可是 AI 编程助手普及之后我最常做的事情变成了向 AI 描述需求让它产出代码片段我负责把片段放进工程里跑起来、看结果、改问题。IDE 里那些“跳转到定义”“查找所有引用”的操作频率断崖式下降。代码不是我想出来再敲出来的而是 AI 根据上下文“猜”出来的我的核心工作从“写代码”变成了“写清楚需求 审查 AI 的产出 验证结果”。当工作模式发生这种变化之后IDEA 再强大它帮的忙也有限了。我需要的不是更强的索引而是一个能让我把需求表达得足够清楚、能快速和 AI 来回迭代、能轻易跑起测试和构建的工作台。IDEA 当然也能装 AI 插件可它最贵的那些能力在我这里已经闲置了。1.2 重型 IDE 的隐形成本越用越心疼除了价值错位之外IDEA 的隐形成本也一直在上升。最直观的是资源占用。一个中大型 Spring Boot 工程IDEA 光索引就要吃 3 到 4GB 内存如果再开几个微服务模块内存分分钟破 6GB。我平时还要跑 Docker、本地数据库、AI 大模型本地部署这些全都需要内存。当机器资源紧张的时候我发现自己很难接受把一个可能一整天都用不上几次“索引跳转”的 IDE 放在后台白白占着资源。其次是启动和索引的时间成本。IDEA 很少完全关闭但每次升级版本、切换分支、或者隔了几天回来它都会重新索引那个进度条一等就是几分钟。这种等待不是一次性的而是每天都会重复的累积成本。想想看等一次索引的时间足够我和 AI agent 来回两轮改代码了。还有一个容易被忽略的点IDEA 的插件体系过于庞大很多插件装完后彼此打架导致卡顿或者 CPU 飙高。我过去有段时间装了十几个插件最后为了排查一个内存泄漏问题不得不挨个禁用浪费了两个小时。后来我意识到很多插件的功能在 AI 时代已经被替代了——我不需要一个插件告诉我“这段代码有坏味道”我直接把它丢给 AI 看它给出的解释更详细、更明白。1.3 AI 到底替代了 IDEA 的哪些功能把话说得更直白一点。我做了一张对比表列出 IDEA 最核心的几个能力以及 AI 工具链在哪些维度已经能打过它IDEA 核心能力传统价值AI 时代的替代方案替代后的感受智能补全Tab 补全、模板补全AI 补全生成整行、整块甚至整个方法AI 补全更接近“意图”而不只是“语法”精准重构方法重命名、提取接口、全项目引用修改AI 批量改代码 单元测试兜底验证需要更严谨的测试覆盖但结果同样可靠深度索引立刻跳转定义、查找使用位置语义模糊搜索 rgripgrep AI 解释小工程效率差不多大工程略降但可接受静态分析编译期报错、代码检查编译器输出 AI 审查错误日志编译器仍然是硬底线AI 帮我解读调试器断点、步进、观察变量日志输出 AI 分析堆栈 远程调式复杂并发问题还是需要调试器这条保留微服务开发内置 HTTP Client、数据库工具命令行 curl Docker AI 辅助写请求上手有成本熟悉后并不差这张表不是说 IDEA 一无是处而是说它最核心的那些深度功能在 AI 工作流里已经不是日常刚需了。当工具的价值排序和我的真实工作模式错位之后继续供着它本质上是在为“过去的习惯”付费而不是为“当下的效率”付费。2. 去掉 IDEA 之后我用什么写代码2.1 主力编辑器最后我留的是轻量编辑器加 AI 插件决定去掉 IDEA 之后我并没有马上换成一个“AI 全家桶”方案而是先老老实实评估了下一个问题日常打开代码的总入口到底应该是什么我的答案是一个足够轻量的编辑器 一套好用的 AI 插件。我最后选的是 VS Code团队统一生态成熟配合 Continue 和 Cline 这类开源 AI 编程扩展。如果你对数据主权有要求可以用 VSCodium体验基本一致。为什么不是 IDEA 社区版很简单IDEA 社区版依然是个 IDE它依然会为很多我用不到的能力做索引和后台计算而 VS Code 打开就是打开没有漫长的“工程加载”概念编辑器本体很安静资源占用和启动速度都轻松得多。在轻量编辑器里我几乎不再手动写那些样板代码了。Controller 方法、Mapper 接口、DTO 字段全部交给 AI 补全生成然后我审查一遍、把不一致的地方改掉。遇到模块级的问题比如“把这段逻辑抽成策略模式”我直接把相关代码块选中丢给 AI 对话窗口它给出的改造方案通常非常接近团队原本会采用的做法。有一点需要注意轻量编辑器的默认补全、跳转能力确实不如 IDEA 那么“开箱即用”但通过几个核心扩展可以补齐 90%语言服务器比如 Java 的 Language Support for Java、GitLens 做代码历史、Prettier 统一格式。就够了真不要装一屏插件。2.2 终端里的 AI agent真正让我敢放手的主力如果说 VS Code 是“写码的桌面”那真正让我下定决心删掉 IDEA 的其实是终端里这些 AI agent 工具——Claude Code、Aider、OpenAI Codex CLI。它们是“长在命令行里的 AI 程序员”不是你问一句它答一句而是你给它一个任务它会自己读工程文件、自己改代码、自己跑测试然后把结果汇报给你。以 Aider 为例我最常用它的场景是这样的丢给它一个 bug 描述比如“登录接口偶尔返回 500日志里看到了空指针位置在 AuthService 第 88 行附近”它会自己去读 AuthService.java分析依赖关系然后给出修改方案。如果我同意它就动手改代码改完自动跑我配置的测试命令。整个过程我基本不碰编辑器。Claude Code 则更适合做多文件改造。比如我之前把一个老旧的同步调用改成异步消息队列涉及 Controller、Service、消息生产者、消费者、配置文件五个文件我用大白话描述完需求之后它一路读文件、一路改中间自己写了两次单元测试来验证逻辑最后只有两处接口设计问题是我手动调整的。用这类工具的关键认知是agent 是用来“写代码”的不是用来“替你做决定”的。它不能判断业务上是不是应该异步、消息要不要顺序消费。这些架构层面的决策必须你自己做。所以我的习惯是先自己想清楚方案再用 agent 去执行agent 给结果我做审查和验收。2.3 本地大模型兜底数据敏感项目也能用 AI还有一个绕不开的场景很多公司的代码是不能往外发的。这种情况下在线 AI 编程助手就不能随便用了但完全放弃 AI 又太可惜。我的做法是本地部署一套大模型用 Ollama 跑起来配合 Continue 这类插件的本地模型模式让它做代码补全和简单的问答。实测下来本地模型的效果上限和在线大模型差距还是明显的。单文件的小任务、模板生成、注释补全它做得不错但上下文一大、需要跨文件推理的时候就经常答非所问。所以我的策略是数据敏感的项目本地模型只是兜底主要用于补全和单文件改写跨文件的重活交给人来梳理然后用离线的方式在隔离环境里处理。关于本地部署配置其实不复杂。Ollama 装好之后拉一个 Qwen 系列或者 DeepSeek 系列的中小尺寸模型给 VS Code 的 Continue 插件配上本地接口就能用了。模型文件大概几个 GB主要瓶颈在内存和显存16GB 内存的机器跑 7B 到 14B 参数量的模型速度还算能用。我不建议在家用电脑上追求最大尺寸的模型够用就好因为本地模型的核心价值是“数据不出本机”不是“性能秒杀云端”。3. 迁移实操从 IDEA 平滑过渡到 AI 工作流3.1 迁移前的准备清单真正动手“卸”IDEA 之前我先做了一轮准备工作。核心思路很简单既然我不再依赖 IDE 的静态检查能力和内建工具链那就必须把“质量底线”交给自动化而不是交给某个 IDE。这轮准备我建议你也照着做一遍第一统一代码格式。无论团队用的是 Google Java Format、Checkstyle 还是 Spotless都必须保证命令行下可以直接跑。以后 AI 生成的代码和人类写的代码格式不一致会导致 diff 里全是换行和空格审查的时候想死。我直接配了 .editorconfig 和 spotless 插件提交前自动执行。第二构建脚本一键可跑。Maven 就用 Maven WrapperGradle 就用 Gradle Wrapper确保新机器上 clone 下来之后不需要手动配环境直接 ./mvnw test 或者 ./gradlew build 就能完成编译和测试。以前依赖 IDEA 的“一键运行”其实本质上是 IDEA 帮你调好了环境变量和构建参数这个动作必须还原子命令行。第三测试必须能自动跑通。IDEA 里有“Run Tests with Coverage”之类的功能但到了命令行你需要的是一个稳定的、不依赖 GUI 的测试入口。单测跑通是底线集成测试如果太重至少核心模块要有。因为 AI 改代码之后测试是唯一能快速证明“改坏了没有”的手段。第四把静态检查从 IDE 里挪到 CI。以前我是靠 IDEA 的 Inspections 在写码过程中发现问题现在这个角色交给了 CI 里的 SonarQube 或同类的静态扫描工具每次 push 自动跑。虽然反馈没有 IDEA 实时但胜在统一、不占本地资源。3.2 给 AI agent 立规矩一份配置文件解决 80% 问题很多人在用 AI 写代码的时候会有一种失控感它生成的代码风格五花八门、动不动就引入复杂的依赖、改文件的时候把无关的地方也改了。这些问题在用了 agent 类工具之后会放大因为 agent 比对话式 AI 更喜欢“顺手改两行”。我的解决方案是在项目根目录放一个 AGENTS.md 文件Claude Code 支持的是 CLAUDE.mdAider 也有类似约定。这个文件相当于给 AI agent 的“入职培训”把所有工程规范写清楚。下面是我的一份精简示例# AGENTS.md - 项目 AI 协作规范 ## 项目背景 - Spring Boot 3.x MyBatis PlusJava 17 - 面向电商后端核心链路订单、库存、支付 ## 编码规范 - 所有新建类必须有 Javadoc 说明用途 - 禁止引入新依赖除非在回复中明确说明理由 - 日志使用 slf4j 的占位符风格不使用字符串拼接 - 禁止修改 pom.xml 中的版本号除非明确要求 ## 测试要求 - 修改核心 Service 时必须同步更新或新增单元测试 - 测试禁止访问真实数据库使用 H2 或 Mock - 跑测试命令./gradlew test --tests 目标类 ## 禁止事项 - 不要重构无关代码只处理任务涉及的类 - 不要删除配置文件中的注释 - 不要修改接口的既有签名除非明确要求 - 不要为了“干净”而大规模重排 import 顺序 ## 协作方式 - 每次修改完成后列出所有改动文件清单 - 明确标注哪些文件是逻辑变更、哪些是格式调整 - 如果任务无法完成说明原因和尝试过的方案放上这份文件之后AI agent 的行为明显收敛了。它不是万能的但确实能让产出更接近团队风格减少了我在 review 阶段的大量重复修改。3.3 一个完整的 AI agent 实操案例空谈没用直接看一个我实际跑过的任务。某次线上反馈订单取消后没有回滚库存。这明显是个 bug我把它整理成任务丢给 Aider订单取消接口 cancelOrder 在事务中调用了库存服务的 releaseStock 方法 但订单状态更新成功后库存回滚经常会失败且不影响主流程。 请定位 inventory-service 中 releaseStock 的实现 找出可能导致失败的点并建议修复方案。 先不要改代码先给我分析结果。Aider 花了大概 20 秒读了 5 个相关文件答案是库存回滚接口在调用远程服务前先扣减了本地预占记录远程失败后没有补偿逻辑而且异常被吞了。它建议在本地记录里增加状态标记用定时任务做补偿同时把异常改为抛出并回滚主事务。这个建议基本靠谱。我让它继续先给方案再实现并要求补充单元测试。它随后改了三个类、加了一个补偿状态枚举、新增两个测试命令行里 /run 自动执行了测试全部通过。我又手动做了一轮 code review重点看了事务边界和异常处理没有发现问题才 push。这次体验给我最大的感触是以前同样的问题我需要自己在 IDE 里挨个文件翻点开调用链一路追至少半小时起步。现在通过 agent我能把时间花在“判断方案对不对”上而不是“找到错误在哪”上。这完全改变了我的工作节奏。3.4 构建、调试与部署的替代方案IDEA 里那些“挥手即用”的按钮在命令行下怎么做我列几个最常用的场景给的方案都是我实际验证过的。构建Java 工程用 Maven/Gradle Wrapper前端工程用 npm/pnpm 脚本。关键是别在本地依赖 IDE 的 JRE 或内置环境统一用命令行版本。调试JVM 应用可以开远程调试端口然后用 jdb 或者直接让 AI 分析日志。说实话AI 时代之后我调试用得最多的是“日志 堆栈 AI 分析”这套组合断点调试只留给那些极度复杂的并发问题。容器构建IDEA 里有“Docker 镜像打包”的可视化面板命令行的等价物是 docker build 配合 Dockerfile如果你用 Spring Boot直接 gradle bootBuildImage 就能出镜像IDEA 里的那个按钮底层也是调它。数据库操作以前我喜欢 IDEA Database 面板现在用 DBeaver 命令行迁移成本很低。这里有一个值得补充的点一旦你把构建、测试、调试、部署全部脚本化你会发现这些步骤不仅能脱离 IDE 运行还能原封不动地用在 CI/CD 流水线里。也就是说你从“个人工具链”里去掉的每一个 IDE 依赖都相当于给自动化流程添了一块砖。这比省下内存更有长期价值。4. 迁移过程中踩过的坑与排查技巧4.1 常见问题速查表迁移过程不是一帆风顺的。我把自己遇到的典型问题整理成一个速查表方便你有类似情况时直接翻阅。问题现象常见原因解决方案AI 生成的代码里用了不存在的库或 API大模型训练数据滞后或者幻觉让 agent 先查本地依赖版本再生成代码测试是唯一的裁判agent 改了不该改的文件上下文理解偏差把“相关”当成了“必须改”在 AGENTS.md 中明确禁止事项要求输出改动清单重构后测试大面积失败只改逻辑没同步更新 Mock 数据和测试预期让 agent 修改测试跑完测试再收手本地模型补全明显变慢模型尺寸和机器内存不匹配换更小的量化版本或者扩大 swap 但不建议命令行构建和 CI 结果不一致本地环境变量与 CI 不同统一使用 Maven Wrapper / Gradle Wrapper固定 JDK 版本agent 中途“失忆”丢前忘后上下文窗口被长文件撑爆拆细任务多轮对话避免单次塞入超大文件4.2 跳过大坑AI 幻觉与过期 API 的实战教训我要单独把“AI 幻觉”拎出来说因为这是我踩过最痛的坑。有一次我让 agent 修复一个 JSON 解析问题它引用了一个 Jackson 的处理类代码看起来天衣无缝编译也过了但运行时报 ClassNotFoundException。检查之后发现AI 引用的类在 Jackson 2.15 里根本不存在它在训练数据里见过这个东西但项目用的版本已经把它移到了另一个包路径。这个坑在 IDEA 时代不会出现——IDE 会在编译期直接给你标红。但在 AI 工作流里编译能过不代表库存在尤其是 agent 自动加依赖的情况下。我的对策首先是硬性要求agent 修改 pom 或引入新依赖时必须明确说明理由不许“顺手加”。其次是用测试兜底好在这个问题在单测阶段就会暴露不至于上到生产。另一个高频问题是过期 API 误用。AI 训练数据如果偏旧会写出一堆 Spring Boot 2.x 的写法比如 WebSecurityConfigurerAdapter 这种在 Spring Security 5.7 之后就废弃的类。每次遇到这种情况我都会让 agent 先明确项目里用的框架版本再让它按版本对应的写法产出代码。有时候多问一句“这个 API 在当前版本是否可用”比事后排查一小时有效得多。4.3 不再依赖 IDE 静态分析靠什么守住代码质量以前 IDEA 的黄色波浪线、红色波浪线是无时无刻不在提醒我“这有问题”。去掉 IDEA 之后这个实时反馈没了我得靠另一套机制补上。第一道关是本地测试。不管 AI 生成的代码看起来多完美我坚持要求它必须补充、更新单元测试并且本地跑通。第二道关是 CI。每次 push 之后流水线会自动跑全量测试、静态扫描和构建不通过就进不了主分支。第三道关是 code review。现在 AI 写的第一版我会拿它当“初稿”来审看边界条件、异常处理、事务边界、并发安全这几个点。最后一道关是 AI review——我自己审完之后把改动丢给 AI 再审一遍经常能发现一些我习惯性忽略的问题。这套流程跑熟之后我发现在某些方面质量甚至比以前更稳了。原因是以前靠 IDE 的静态检查很多规范是“写的时候顺手改掉”而现在靠强制流程每个环节都有明确的责任人反而没有漏网之鱼。4.4 坚持命令行和轻量编辑器会影响团队协作吗这是我被问得最多的问题。担心也无道理的部分在于如果一个团队只有你一个人不用 IDEA那代码格式化、编码规范很容易出偏差。我的经验是只要做好下面三件事协作不会出问题。第一用 EditorConfig 统一基础格式。这个文件放在仓库里不管队友用 IDEA、VS Code 还是 vim格式化结果都是一样的。第二把构建和测试命令固定为脚本团队所有人统一跑 gradlew test而不是打开 IDE 点按钮。第三commit 信息规范提交用固定的前缀风格让 code review 的时候容易追溯。剩下的其实都是个人偏好问题。代码最终是存在 Git 仓库里的IDE 只是打开它的工具之一。只要你的提交经过充分测试、格式规范、diff 干净没有人会关心你是在 IDEA 里提交的还是终端里提交的。相反如果你用了很多“顺手格式化整个文件”的操作导致 diff 里全是风格变更那不管用哪个 IDE 都会被队友嫌弃。还有一点想单独提醒不要为了省事去网上下载那些所谓的“激活工具”或者“破解码”。这是另一条线的问题但既然聊到 IDEA 了我必须说一句——IDEA 官方有免费的社区版付费版本建议走正规订阅。那些破解工具里大概率藏着挖矿程序和窃密木马代码还没跑起来机器先成了肉鸡得不偿失。写在最后去掉 IDEA 对我而言不是一次工具替换而是一次工作方式的重构。我重新理解了“写代码”这件事在 AI 时代到底意味着什么它不再是纯粹的生产动作而更多是需求定义、方案决策和质量判断。工具的选择应该服务于这套新逻辑而不是继续为过去十年的肌肉记忆买单。如果你还在犹豫要不要做类似迁移我的建议是先别急着卸载 IDEA。你可以花两周时间刻意把自己的一部分工作切到轻量编辑器加 AI agent 上看看感觉。如果两周后你发现自己已经完全适应了那再考虑彻底切换如果发现有些场景离不了 IDEA 的索引和调试器那就留下来继续用。工具不是信仰怎么高效怎么来。最后再分享一个小技巧无论你最终离不开 IDEA 还是彻底离开它都值得把“AI 帮你写代码、你帮 AI 提需求、测试帮你兜底”这套流程建立起来。这才是这个时代真正的竞争力——不是你会用哪个 IDE而是你能用 AI 把想做的事情以更低的成本、更高的质量做出来。