上周在电梯里遇到隔壁组的同事，他瞥了一眼我的屏幕，愣了一下：“你咋把 IDEA 换成了这么朴素的编辑器？”我说：“因为现在写代码的主力是 AI，IDE 对我的价值已经没那么大了。”这不是赌气，也不是蹭热度，而是过去一个多月我把工作流彻底换掉之后，得出的真实结论。
说白了，我一直是 JetBrains 系的忠实用户。从 Java 后端写到微服务治理，再到后来带小团队做 Code Review，几乎所有跟代码有关的操作都在 IDEA 里完成。但 AI 写代码的成熟速度比我预想的快得多，当“生成代码”变成主要工作，而不是“手写代码”的时候，重型 IDE 那套完整闭环反而开始拖节奏。这篇文章就记录一下我决定去掉 IDEA 之后怎么干活、用了哪些工具、踩了哪些坑，以及什么情况下我建议你别学我。
1. 为什么曾经离不开 IDEA，现在却想放手
1.1 IDEA 解决的是“人写代码”时代的痛点
先说清楚，我不是否定 IDEA 的价值。它在一线开发里解决的是非常实在的问题：工程结构管理、跨文件重构、智能补全、断点调试、静态检查、版本控制集成，再加上各种框架插件。对于 Java 这种“重装备”语言，IDEA 几乎就是把一台完整的汽车维修车间搬到你电脑上，螺丝该拧多大扭矩它都能提醒你。
我过去十年的常态是：打开 IDEA，建好 Module，写好代码，用它的重构功能安全地改字段名，用 Diff 面板仔细看变更，再通过内置的 Git 面板提交。每一步都在 IDE 里完成，所有操作都有图形界面兜底。这在“人的双手是主要生产线”的年代里，完全合理，也极度高效。IDEA 的很多设计，比如 Local History、Find Usages、Refactor Preview，都是为了降低人写代码时引入错误的风险。
但问题在于，当 AI 成为代码生产线的主力之后，人和代码的关系发生了本质变化。我不再是“逐行敲代码的人”，而是“提需求、审代码的人”。IDEA 里大量以“手动编码”为前提的功能，实际使用频率大幅下降。我打开 IDE 最常做的事，慢慢只剩下看文件树和跑测试，那为什么还要让一个几 GB 内存的庞然大物常驻后台呢？
1.2 AI 改变的不是补全，而是协作模型
很多人对 AI 写代码的理解还停留在“高级自动补全”。其实不是。Copilot 这类工具早期确实是补全，但现在的 AI 编程工具已经能做到：理解整个项目的结构、读取相关文件、自动修改多处代码、生成测试、分析风险。
这才是根本性的变化。以前我写一个订单导出功能，需要自己搭 Controller、Service、Mapper，再写 DTO、异常处理、日志。现在只需要用自然语言说清楚“从订单表查出已付款订单，按店铺分组导出 Excel，超过 50 万行要分片”，AI 能直接把整条链路的代码都给你列出来，连大文件导出的分片建议都能给到。工作模式从“人写、工具查”变成了“人审、AI 写”。
当协作模型变成这样，IDEA 的优势项就失去了用武之地。比如跨文件重构，过去我要依赖 IDE 的 Find Usages 确保安全，现在可以让 AI 先梳理调用链，再自动修改，然后我来 Review Diff。结果是一样的代码质量，但我不用再点开一堆弹窗。
这不是说 IDEA 就不好用，而是它的设计目标和 AI 时代的编码节奏不再匹配。就像你有了自动驾驶之后，对方向盘手感的要求会降低，更在意的是路径规划和避障逻辑。
2. 去掉 IDEA 之后，我的工具链是怎么搭的
2.1 编辑器选择：VS Code 为主，Vim 模式为辅
决定去 IDE 化之后，我第一个面临的问题就是：用什么作为日常代码的主要容器。市面上的选择很多，但我最终选了 VS Code，没有选更激进的纯终端方案。
理由很简单：VS Code 对多语言支持均衡，插件生态成熟，启动速度和内存占用比 IDEA 轻一个量级，而且对 AI 编程插件的支持最全。我日常主力语言是 Java 和 Python，偶尔写点 Go、TypeScript，VS Code 都能覆盖。安装 Vim 插件之后，编辑效率也能满足我这种“键盘流”的习惯。
配好之后我的 VS Code 大概是这个状态：
- 核心 AI 插件：Continue、Cline、GitHub Copilot 作为备选
- 主题和字体：One Dark Pro + JetBrains Mono（是的，我用的是 JetBrains 家的字体，但编辑器已经换了）
- 快捷键习惯：启用 Vim 键位，自己映射了
<leader>开头的常用命令 - 终端集成：VS Code 内置终端运行 Aider、git 命令
有人可能会说，你这不是把 IDEA 换成了 VS Code 嘛，不还是一个编辑器？对，但区别在于核心生产工具换了。IDEA 的核心价值是“管理和检查”，VS Code 在我的工作流里的核心价值是“薄薄的一层界面，主要干活的其实是 AI 和命令行”。
2.2 AI 编码工具的选型和真实参数对比
工具选型是最关键的一步。我试了一圈，市面上常见的 AI 编程工具基本都用过，各自的特点也相对清楚了。这里直接给一个对比表格，方便你按需选择：
| 工具 | 模型接入方式 | 上下文能力 | 交互方式 | 费用 | 我的使用场景 |
|---|---|---|---|---|---|
| GitHub Copilot | 官方模型，黑盒 | 当前文件+相关文件 | 内联补全、对话 | 付费订阅 | 快速补全、备选 |
| Continue | 支持 OpenAI、Anthropic、本地模型 | 可自定义索引 | 对话+内联编辑 | 免费，模型费自理 | 主力，接我自己配的模型 |
| Cline | 支持多种模型，自动操作文件 | 多文件协同 | 自主执行任务 | 免费，模型费自理 | 跨文件重构、批量改 |
| Aider | 支持主流模型 | git diff 为基础，全仓库上下文 | 纯终端交互 | 免费+API 费用 | 复杂任务、偏好终端时 |
| 通义灵码 | 阿里系模型 | 中文本地化强 | IDE 插件、对话 | 免费额度 | 中文注释和需求理解 |
选择的时候有一个关键点容易被人忽略：上下文窗口。我之前用只支持短上下文的模型，AI 经常忘记开头聊的需求，改着改着就开始自我发挥。后来我改用支持长上下文的模型，并配合 Continue 的项目索引功能，让 AI 能读取当前改动影响到的类和方法，生成质量明显提升。
另一个影响很大的参数是“温度”。写代码不是写诗，温度建议调到 0 到 0.2 之间，否则 AI 会用不同的写法实现同样的功能，Review 的时候会很痛苦。我自己基本都是固定 temperature=0，让输出更稳定。
2.3 终端工作流：为什么我又捡起了 Aider
你可能觉得奇怪，既然有了 VS Code 插件，为什么还用终端工具。因为我发现某些场景下，纯终端的 Aider 反而更高效。
Aider 的运作方式非常特别：它直接读写你的 git 仓库，每次修改前自己建一个分支，修改完把 diff 呈现给你，你直接用 Git 命令决定保留还是丢弃。这种“以 Git 为操作单元”的设计，天然适合我这种习惯频繁提交、喜欢精确掌控每次变更的人。
我常用的操作大概是这样的：
# 新建一个分支开始新功能 git checkout -b feature/ai-generate-report # 启动 Aider，指定主要文件 aider --model gpt-4o --temperature 0 src/report_service.py # 在 Aider 对话里输入需求，它会自动改文件并生成 commit 信息对比一下，在图形界面里用 AI 插件改代码，改完之后我还要自己看文件 diff，再手动提交；在 Aider 里，AI 自己会创建分支、改代码、生成 commit 信息，我只需要审查 diff，然后合并。长期用下来，这个流程对版本控制的透明度反而更高。
我还把 Aider 的快捷键映射到了 VS Code 终端里，做到图形界面和命令行无缝切换：日常浏览代码用 VS Code，需要 AI 做大改动时直接在集成终端里跑 Aider，不用切出窗口。
3. AI 写代码的完整实操：从需求到合并
3.1 需求拆解：把自然语言变成伪代码
AI 写代码的第一步，也是最容易被忽略的一步，是你得先把需求说清楚。很多人在这一步就翻车，给 AI 一句“帮我写个报表”，然后抱怨生成的代码不能用。实际上，合格的 AI 编码流程里，需求拆解的重要性占了 60%。
我现在的习惯是：先写一段伪代码或者结构化描述，再交给 AI。伪代码不需要严格语法，它更像是个骨架，告诉 AI 数据从哪来、处理逻辑是什么、输出长什么样。比如做一个销售数据日报功能，我给的描述是这样的：
函数：读取销售订单 CSV，按订单日期聚合日销售额，输出按日期排序的日报。 输入字段：order_id, order_time, channel, amount 逻辑： 1. 过滤掉 order_time 为空的行 2. 按订单时间的年月日分组 3. 每组内金额相加，保留两位小数 4. 输出格式：日期 + 销售额 + 订单数 边界条件：CSV 字段缺失时直接报错并提示哪一行有问题，不要静默跳过这段描述里包含了输入、输出、边界条件和错误处理策略。AI 拿到这个描述之后，生成的代码基本不会偏。
这里特别提一下，网络上经常出现“伪代码怎么写”的搜索，新手总觉得伪代码是种正式技能。其实不是，伪代码就是你把脑子里的逻辑用最简短的文字写出来，让 AI 少猜一点。AI 猜得越少，生成结果越准。
3.2 让 AI 生成主体代码，并人工补一刀
继续上面的例子，我用 Continue 把那段伪代码发给模型，很快得到了完整实现。下面是我略作调整之后的结果：
# 读取销售订单 CSV，按日聚合销售额，输出日报表 import csv from collections import defaultdict from datetime import datetime def load_orders(path): orders = [] with open(path, encoding="utf-8") as f: for row_number, row in enumerate(csv.DictReader(f), start=1): order_time = row.get("order_time", "").strip() if not order_time: raise ValueError(f"第 {row_number} 行缺少 order_time") try: parsed_time = datetime.strptime(order_time, "%Y-%m-%d %H:%M:%S") except ValueError: raise ValueError(f"第 {row_number} 行时间格式无法解析: {order_time}") orders.append({ "date": parsed_time.date(), "amount": float(row.get("amount", 0)), "channel": row.get("channel", ""), }) return orders def daily_report(orders): day_amount = defaultdict(float) day_count = defaultdict(int) for order in orders: day_amount[order["date"]] += order["amount"] day_count[order["date"]] += 1 return dict(sorted(day_amount.items())), dict(sorted(day_count.items())) if __name__ == "__main__": orders = load_orders("orders.csv") amounts, counts = daily_report(orders) for day in amounts: print(f"{day} 销售额: {amounts[day]:.2f}元 订单数: {counts[day]}")生成速度很快，但我不会直接信任，而是快速过了三遍代码：第一遍看整体结构，第二遍看异常处理，第三遍看数据类型有没有坑。果然发现一个问题：float(row.get("amount", 0))在 amount 字段为空字符串时会报错。这个属于典型的 AI 幻觉边界，模型以为 CSV 里一定有合法数字，实际上脏数据到处都是。
我的处理方式是直接改进代码，加上对金额字段的校验和清洗，再让 AI 针对“金额为空字符串”“金额为负数”这两个场景补测试。这就是 AI 协作的精髓：AI 负责生成主干，人类负责注入实践经验。
3.3 AI 自动写测试，并且真的跑起来
写测试是 AI 编码工具最容易出效果、也最容易被忽视的环节。很多团队 Code Review 时苦于没有测试，而 AI 恰恰是测试代码生成的能手。它对框架的熟悉程度远超个人记忆，只要给它明确的输入输出边界，它能飞快生成一版有理有据的单元测试。
还是以日报功能为例，我让 AI 生成的测试大概长这样：
import pytest from sales_report import daily_report, load_orders def test_daily_report_aggregates(): orders = [ {"date": "2024-01-01", "amount": 100.0, "channel": "app"}, {"date": "2024-01-01", "amount": 50.5, "channel": "web"}, {"date": "2024-01-02", "amount": 30.0, "channel": "app"}, ] amounts, counts = daily_report(orders) assert amounts["2024-01-01"] == 150.5 assert counts["2024-01-01"] == 2 def test_load_orders_missing_order_time(): with pytest.raises(ValueError): load_orders("missing_time.csv")注意，这里 AI 生成了测试，但它默认我存在missing_time.csv这个文件，实际测试跑不过。我需要让 AI 生成临时文件，或者自己用 tmp_path fixture 改造一下。这个发现很有价值：AI 生成测试的准确度取决于它对上下文的理解程度，如果它不知道测试环境怎么构造，就会瞎猜。
我的经验是，让 AI 写测试之前，先把项目用的测试框架、构建工具、目录结构告诉它，最好把pytest.ini或pom.xml里的关键配置贴过去。上下文越具体，生成的测试越能用。
3.4 用 AI 做 Code Review，比同事还较真
很多人以为 AI 写代码就是“生成完就结束”，其实 AI 做 Code Review 的能力同样被低估。我自己在代码提交前，会专门让 AI 以“严格的资深工程师”视角审查一遍本次改动。
典型的一句话指令是这样：
请以资深工程师视角审查以下 diff，重点检查： 1. 是否有并发安全问题 2. 是否有资源未释放 3. 是否存在边界条件遗漏 4. SQL 是否存在慢查询风险 5. 命名和复杂度是否需要改进 请按严重程度输出问题列表，不要给改进建议之外的解释。实测下来，AI 对并发问题、异常处理遗漏、资源泄漏这类问题的识别能力相当强。有一次它还发现我事务注解打错了位置，导致异常时数据库连接不会回滚，这种情况靠肉眼 Review 很容易漏掉。
需要说明的是，AI Review 不能替代人工 Review。它的强项是模式识别和规范检查，弱项是对业务上下文的理解。所以我现在的流程是：人工先过一遍逻辑，AI 再过一遍技术细节，最后提交给团队 Review 的时候，往往已经没什么低级问题了，团队的 Review 体验也变好了很多。
4. 去 IDE 化的路上，我踩过的坑与排查技巧
4.1 没有图形化调试器，疑难杂症怎么定位
去掉 IDEA 之后，我第一个不适应的就是调试。以前遇到问题直接在行号旁边打红点，看变量面板，一行行 Step Over。现在用 VS Code 写 Java，调试体验虽然不算差，但没有原来那么顺手。
我的应对策略是分层排查。线上问题一律走日志和链路追踪，本地问题优先写单元测试复现。只有到了确实需要断点调试的复杂场景，我才会临时打开 IDEA 作为“调试器使用”，不参与写代码环节。这相当于把 IDE 降级成工具箱，而不是日常工位。
另外一个技巧是，Python 代码我经常直接在终端里用pdb或者ipdb调试。很多人对命令行调试有心理障碍，其实最基本的几个命令就够用：
# 在代码里插入断点 import pdb; pdb.set_trace() # 常用命令 # n - 执行下一行 # s - 进入函数内部 # c - 继续执行到下一个断点 # p 变量名 - 打印变量值这套东西学起来不到十分钟，但能解决 80% 的本地调试需求。加上 VS Code 也支持 Python 的远程调试，通过 debugpy 连接，体验和图形化调试差距很小。
4.2 AI 幻觉问题：看起来有道理，实际在胡编
去 IDE 化之后，最大的风险不是工具难用，而是 AI 生成的代码“看起来太真了”。有一次我让 AI 写一个读取配置文件的工具类，它直接调用了一个并不存在的第三方库方法，编译的时候报了一堆错。还有一次更隐蔽，AI 在 SQL 里用了某个新版本的函数，生产环境的数据库版本不支持，差点上线出事故。
针对 AI 幻觉，我总结了一套三层防御：
第一层是代码执行前防御：让 AI 给出它用到的方法签名和版本来源，只要来源不明，立刻怀疑。我会追问：“你引用的这个方法在 Spring Framework 哪个版本引入？”AI 答不上来的时候，说明它很可能是编的。
第二层是编译和测试防御：所有 AI 生成的代码，必须本地编译通过、单测通过，绝不允许“看起来没问题”就提交。我没有图形化 IDE 的自动提示后，反而更依赖命令行编译和测试，这会逼着我手动执行构建命令，及时发现低级错误。
第三层是运行时防御：添加足够的日志埋点和监控报警，确保即使有问题也能快速回滚。AI 生成的代码再稳，也免不了业务数据刁钻，生产监控才是最后一道防线。
4.3 团队规范和私有化部署问题
不是所有人都能自由选择工具。如果你的团队强制要求使用统一的 IDE 配置、代码模板、提交插件，去 IDE 化会遇到现实阻力。我自己的做法是：日常写代码不再依赖 IDEA，但提交之前会在 CI 上跑团队规范检查，确保 AI 生成的代码符合项目风格。比如 Java 项目强制 Checkstyle，我直接在本地用 Maven 跑校验，不通过就让 AI 改到通过为止。
这里也想多说一句关于 AI 模型部署的问题。有隐私要求的企业往往不能把代码传给公网 API，所以本地部署大模型成了一个热门的替代方案。我自己也玩过 local model，比如用 Ollama 跑开源模型，接入 Continue 插件。实测下来，普通水平的开源模型胜任简单函数生成和补全没有问题，但复杂任务的能力距离顶级商业模型还是有些差距。如果你的公司有隐私要求，可以考虑直接买企业版或者私有化部署方案，不要强行用老旧的单机模型去指望它完全替代商业 API。
4.4 去 IDE 化常见问题速查表
| 问题 | 现象 | 我的排查思路 |
|---|---|---|
| AI 生成的代码编译报错 | 不存在的函数、缺失的 import | 让它解释函数来源，并贴出编译错误日志继续追问 |
| 测试生成后跑不过 | 路径不存在、数据没清理 | 用 tmp_path 或者在测试里手动创建临时文件 |
| 代码风格不符合项目规范 | 格式不统一、命名不规范 | 先让 AI 读取项目已有的代码风格配置，再重新生成 |
| 上下文太长被截断 | 改到后面 AI 忘了前面的需求 | 手动拆分任务，一次对话只做一件事 |
| 本地模型效果太差 | 生成的代码大量返工 | 换用更大的模型，或者只让本地模型做简单补全 |
这张表其实是在提醒大家：去 IDE 化不是“一步到位”的事，它更像是把工作流拆成很多个小环节，每个环节都用最合适的工具去处理。碰到具体问题，先用最笨的办法复现，再逐步让 AI 接管，这才是比较务实的路径。
5. 什么人适合去掉 IDEA，什么人建议保守
5.1 我建议你可以大胆尝试的人群
如果你符合下面几个特征，爽快地试一试去 IDE 化并不会有太大风险：
- 全栈开发者、独立开发者，或者长期写脚本和微服务的人，对 IDE 的重型能力依赖并不深
- 团队成员已经普遍使用 AI 编码工具，团队规范和 CI 配置完善，不依赖 IDE 内置模板
- 认可用“人审代码、AI 写代码”作为主要工作模式，控制欲望强，能忍受从图形界面到命令行和编辑器的过渡
- 项目本身具备完善的自动化测试和持续集成，即使 AI 代码有瑕疵，也能在早期被发现
我自己目前的状态就是这样。工作流已经从“打开 IDEA 开始写代码”变成了“打开终端和编辑器，让 AI 生成、我审查、测试兜底”，效率提升明显，尤其是需求明确的中小型功能，开发时间能压缩到以前的五成左右。
5.2 我还是建议你谨慎对待的人群
反过来，我也要泼几盆冷水，不要盲目跟风去 IDE 化：
- 大型 Java 企业级项目，涉及海量类库、复杂构建、分布式调试，IDEA 的重构和调试能力仍然碾压轻量编辑器
- 团队有强制性的 IDE 配置规范，或者大量使用 IDE 专属插件和自定义脚手架
- 刚入行不久的新人，还在通过编辑器提示学习语法和框架 API，IDE 的主动提示对建立知识体系帮助很大
- 你手头的 AI 工具只是网页版聊天窗口，没有深度集成到项目里时，去 IDE 化只会增加复制粘贴的时间成本
我在团队里带过不少新人，观察到一个现象：AI 时代对工程师的要求不是会写更多代码，而是更会判断代码好坏。如果一个新人还没有建立起“这段代码是否可靠”的判断力，就过早依赖 AI 生成代码，后面会陷入“代码能跑但不知道为啥能跑”的尴尬。这个阶段，IDE 反而是一个很棒的辅助学习工具，先保留它没有坏处。
至于网上“AI 抢走写代码工作”之类的焦虑，我的看法是：AI 不会抢走写代码的工作，但会用 AI 的人确实在效率上碾压不会用 AI 的人。真正稀缺的从来不是敲键盘的速度，而是把需求拆清楚、把代码审明白、把问题查到底的能力。这恰恰是 IDE 给不了你、而 AI 协作能逼着你去锻炼的那部分能力。
写在最后的个人体会
一个月实践下来，我最大的感受是：去掉 IDEA 这个动作本身并不神奇，神奇的是它逼着我把工作流重新想了一遍。以前我在 IDE 里是被动接受检查的那一个，现在我主动定义需求、主动审查代码、主动设计测试，AI 只是在中间帮我承担了重复劳动。
我现在依然会在某些复杂场景下打开 IDEA，比如大范围重构、排查调用链、调优 Maven 依赖冲突的时候。但日常 80% 的编码工作已经不再需要它了。如果你也在犹豫要不要切换，我的建议是先别急着卸掉 IDE，先从一个小功能开始，用 AI 工具在旁边辅助，体验一下“我说需求、AI 动手、我把关”的节奏，觉得舒服再逐步转移。工具永远是为人服务的，最适合你的工作流，就是最好的工作流。
