AI时代Java开发工作流重构：VS Code+Maven+Arthas替代IDEA实践-平芜编程栈

1. 这不是卸载IDEA，而是重构开发工作流

“AI写代码之后，我决定去掉IDEA工具”——这句话刚在技术群刷屏时，我第一反应是：又一个标题党？可翻完作者贴出的完整操作录屏、本地日志和三个月迭代数据后，我默默关掉了自己IDEA里开着的17个Spring Boot模块窗口。这不是反工具主义，也不是技术浪漫主义，而是一次被大模型倒逼出来的、真实可行的开发范式迁移。

核心关键词其实就三个：AI生成能力、Java工程复杂度、IDEA功能冗余。我们每天在IntelliJ IDEA里高频使用的功能，真正不可替代的只有不到30%：智能补全（Ctrl+Space）、Maven依赖解析、Spring Boot自动配置感知、断点调试器、以及项目结构索引。其余70%——比如可视化Maven依赖图、图形化Git操作面板、嵌入式Tomcat启动控制台、甚至大部分代码模板——在AI辅助下，正快速变成“可选配件”，而非“运行必需”。

我试过用纯VS Code + Java Extension Pack + Spring Boot Tools + 自研AI插件跑通一个含5个微服务、3个数据库、2套OAuth2流程的Spring Boot企业级项目。从初始化到部署上线，全程没打开过一次IDEA。不是为了炫技，而是发现：当AI能实时生成Controller层校验逻辑、自动补全MyBatis XML映射字段、根据Swagger注解反向生成DTO、甚至基于单元测试失败堆栈精准定位空指针位置时，传统IDE里那些需要鼠标点五次才能触发的“智能提示”，反而成了操作延迟源。

适合谁参考？不是刚学Java的小白——他们还需要IDEA的红色波浪线手把手教语法；而是有3年以上Spring Boot实战经验、熟悉Maven生命周期、能看懂pom.xml依赖冲突树、习惯用命令行管理Git分支的中高级开发者。如果你还在为“idea启动spring boot项目不显示端口号”这种问题查两小时文档，那请先稳住IDEA基本功；但如果你已经能徒手写完一套RBAC权限拦截器，却还在等IDEA加载完200MB的索引缓存，这篇文章就是为你写的。

它解决的不是“能不能不用IDEA”，而是“在什么条件下、用什么替代方案、以什么代价、换取什么收益”的实操决策链。下面我会拆解整个迁移过程的真实路径，不回避坑，不美化结果，只讲清楚每一步为什么这么选、参数怎么调、哪些地方AI真能扛、哪些地方还得靠人盯。

2. 工作流重构的核心逻辑与取舍权衡

2.1 为什么不是“替换IDEA”，而是“解耦开发环节”

很多人误以为这是“用VS Code替代IDEA”，其实本质是把原本被IDEA强绑定的开发环节，按职责重新切分：

代码生成环节→ 交给AI Agent（本地部署的CodeLlama-70B或云端API）
构建与依赖管理环节→ 交给Maven CLI（配合阿里云镜像加速）
运行时环境控制环节→ 交给Docker Compose（统一管理MySQL/Redis/RabbitMQ）
调试与诊断环节→ 交给JDK自带的jdb + Arthas（轻量级热修复）
版本协作环节→ 交给Git CLI + GitHub CLI（跳过IDE图形化界面）

IDEA之所以成为“默认选择”，是因为它把这五个环节打包进一个进程，用内存索引实现毫秒级响应。但代价是：每次升级都要重载整个索引、开多个模块必然吃光32GB内存、Spring Boot DevTools热重启在大型项目里越来越慢。而AI介入后，最耗时的“写代码”环节被前置到编辑器外完成——你输入自然语言需求，AI直接输出.java文件，再由Maven验证编译通过性。此时，IDEA的“智能感知”优势大幅衰减。

我做过对比测试：在一个含87个Maven子模块的Spring Cloud项目中，IDEA加载完整索引需4分23秒；而用VS Code打开同一项目（禁用所有Java插件），仅加载基础语法高亮，耗时1.8秒。AI生成代码后，执行mvn compile -Dmaven.test.skip=true验证，平均耗时28秒。这意味着：等待AI生成的时间（约15秒）+ Maven编译时间（28秒） < IDEA索引加载时间（263秒）。当单次开发循环从“等IDEA”转向“等AI+Maven”，效率拐点就出现了。

2.2 关键取舍：放弃什么，保留什么

迁移不是全盘否定，而是精准裁剪。以下是我在实际项目中明确放弃和坚决保留的功能清单：

功能类别	放弃项	保留项	决策依据
代码编辑	IDEA的Structural Search（结构化搜索）、Postfix Completion（后缀补全）	VS Code的Emmet语法、多光标编辑、正则替换	AI生成代码后，手动编辑频次下降60%，结构化搜索使用率趋近于0；而多光标批量改包名、正则清理日志语句仍高频
构建系统	IDEA内置Maven控制台、可视化依赖树	`mvn clean compile`CLI、`mvn dependency:tree -Dincludes=org.springframework.boot`	CLI命令可精确控制跳过测试、指定profile、排除特定模块，比图形界面更可控；可视化树在排查冲突时仍有价值，但仅需偶尔调用
运行调试	IDEA的图形化断点管理、变量视图、Threads面板	JDK`jdb`命令行调试器 + Arthas`watch`命令	大型分布式项目中，90%的Bug定位靠日志+链路追踪，而非单步调试；Arthas的`watch com.xxx.service.UserService login`能实时监控方法入参，比设断点更高效
版本控制	IDEA的Git图形化提交、分支合并界面	`git status`+`git add -p`+`git commit -m`	CLI交互更清晰，避免IDE误操作（如未暂存文件直接提交）；`-p`参数可逐块选择变更，精准控制提交内容
Spring Boot特化	IDEA的Spring Boot Dashboard、Actuator端点可视化	`curl http://localhost:8080/actuator/health`+`jq`解析	Actuator端点本就是HTTP接口，CLI调用更符合DevOps习惯；Dashboard对单体应用有用，但在K8s集群中已无存在意义

特别说明一个常见误区：很多人认为“去掉IDEA=放弃智能补全”。实际上，VS Code的Java Extension Pack（由Red Hat维护）已支持LSP协议，其语义补全质量与IDEA持平，且响应更快——因为不依赖本地索引，而是调用Language Server实时分析。我实测在10万行代码的模块中，VS Code补全延迟稳定在80ms内，而IDEA在索引未完全加载时可达1.2秒。

2.3 技术栈选型背后的硬逻辑

所有工具选型都围绕一个核心原则：每个组件必须能被脚本自动化、被CI/CD流水线复用、被团队成员零成本上手。这意味着拒绝任何“仅GUI可用”的工具。

VS Code：选择1.85版本（LTS），禁用所有非必要插件，仅启用：
- redhat.vscode-java（Java语言支持）
- vscjava.vscode-spring-boot（Spring Boot特化支持）
- ms-vscode.vscode-typescript-next（TypeScript预编译支持，用于前端联调）
- esbenp.prettier-vscode（代码格式化，统一团队风格）

提示：禁用EditorConfig for VS Code插件。它会与Maven的formatter-maven-plugin冲突，导致mvn formatter:format执行后VS Code自动重格式化，产生无意义的diff。

AI代码生成器：本地部署CodeLlama-70B（量化版），而非调用云端API。原因有三：
1. 企业代码敏感，不能上传至第三方服务器；
2. 网络延迟导致生成响应超2秒，破坏开发节奏；
3. 可定制System Prompt，例如强制要求：“生成代码必须包含@Valid注解、@NotNull字段校验、ResponseEntity封装，禁止使用new HashMap()”。
  部署方案采用Ollama+LM Studio组合，显存占用从原始70B的140GB压缩至32GB（A100），推理速度达18 tokens/s。

Maven配置：全局settings.xml强制启用阿里云镜像，并配置<mirrorOf>*</mirrorOf>确保所有仓库走代理。关键参数调整：

<profiles> <profile> <id>default</id> <activation><activeByDefault>true</activeByDefault></activation> <properties> <!-- 跳过测试编译，加速验证 --> <maven.test.skip>true</maven.test.skip> <!-- 启用增量编译，避免全量重编 --> <maven.compiler.incremental>true</maven.compiler.incremental> <!-- 指定JDK17，避免IDEA自动降级 --> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> </properties> </profile> </profiles>

这些参数让mvn compile在模块间依赖变化时，仅重编译受影响类，而非整个模块。

3. 核心环节实现：从需求到可运行服务的全流程

3.1 需求输入与AI生成：如何让大模型理解Spring Boot语境

AI生成代码的质量，70%取决于Prompt设计，30%取决于上下文注入。我绝不接受“写一个用户登录接口”这种模糊指令，而是构造结构化Prompt：

你是一名资深Spring Boot架构师，请严格按以下要求生成Java代码： 1. 使用Spring Boot 3.2.0 + Java 17； 2. Controller层必须用@RestController，返回ResponseEntity； 3. Service层必须用@Transactional，包含完整的异常处理（UsernameNotFoundException, BadCredentialsException）； 4. DTO必须包含@NotBlank校验，密码字段用@Size(min=8)； 5. 返回JSON结构必须包含code、message、data三字段； 6. 依赖注入必须用构造函数注入，禁止@Autowired字段注入； 7. 包名格式：com.example.project.module.controller/service/dto； 8. 生成后提供对应单元测试（JUnit 5 + Mockito）。

这个Prompt经过23次迭代优化，关键在于：把Spring Boot最佳实践转化为AI可执行的硬约束。例如“构造函数注入”这条，能避免AI生成@Autowired private UserService userService;这种反模式代码。

上下文注入同样重要。我开发了一个VS Code插件，当光标停在UserService.java文件时，自动提取该类的全部方法签名、注解、继承关系，并作为Context传给AI。这样生成的Controller就能精准调用userService.login(username, password)，而非瞎猜方法名。

实测效果：在“基于spring boot的企业项目进度跟踪与工时管理系统”中，AI生成的TaskController首次通过率从32%提升至89%。剩余11%的失败集中在事务边界问题（如Service方法未加@Transactional），这恰好暴露了AI对Spring AOP机制的理解盲区——需要人工Review，但已大幅减少编码量。

3.2 Maven构建验证：用CLI替代IDEA的“一键运行”

去掉IDEA后，“运行项目”不再是点击绿色三角形，而是一套标准化CLI流程：

环境检查：执行./check-env.sh（自研脚本），验证：
- JDK17是否在PATH中（java -version | grep "17."）
- Maven是否配置阿里云镜像（mvn help:effective-settings | grep aliyun）
- Docker daemon是否运行（docker info >/dev/null 2>&1）

依赖解析：mvn dependency:resolve -DincludeGroupIds=org.springframework.boot
此命令仅解析Spring Boot相关依赖，跳过其他模块，耗时从常规mvn compile的45秒降至8秒。若失败，直接输出冲突坐标，如：

[ERROR] Failed to execute goal on project task-service: Could not resolve dependencies for project com.example:task-service:jar:1.0.0: Failed to collect dependencies at org.springframework.boot:spring-boot-starter-web:jar:3.2.0 -> org.springframework.boot:spring-boot-starter-json:jar:3.2.0 -> com.fasterxml.jackson.core:jackson-databind:jar:2.15.2

编译与测试：mvn clean compile test-compile -Pdev
-Pdev激活开发Profile，加载application-dev.yml，其中配置H2内存数据库，避免连接真实MySQL。测试阶段仅编译Test类，不执行，因后续用mvn surefire:test单独运行。
打包与启动：mvn package -DskipTests && java -jar target/task-service-1.0.0.jar --spring.profiles.active=dev
关键技巧：--spring.profiles.active=dev参数必须写在-jar之后，否则Spring Boot无法识别。这个细节在IDEA里被图形界面隐藏，CLI中必须显式声明。

注意：不要用java -jar target/*.jar这种通配符。当Maven生成original-task-service-1.0.0.jar（未重命名的原始包）和task-service-1.0.0.jar（重命名后的可执行包）时，通配符会随机选取一个，导致启动失败。务必指定完整文件名。

3.3 调试与诊断：用Arthas替代IDEA图形化调试器

当线上服务出现NullPointerException时，IDEA的图形化调试器需要重启应用并复现问题，而Arthas可在生产环境热诊断：

# 1. 附着到Java进程（PID从jps获取） arthas-boot.jar 12345 # 2. 监控UserService.login方法的入参和返回值 watch com.example.task.service.UserService login '{params,returnObj}' -x 3 # 3. 当发现username为null时，追溯调用链 trace com.example.task.service.UserService login # 4. 热修复：临时修改方法返回值（绕过DB查询） jad --source-only com.example.task.service.UserService mc /tmp/UserService.java redefine /tmp/UserService.class

这套操作全程无需重启JVM，且watch命令支持条件过滤（如-n 5只监控前5次调用），比IDEA断点更灵活。我曾用此法在客户现场3分钟定位到OAuth2 Token解析失败问题——IDEA远程调试需配置防火墙、证书、端口映射，而Arthas一条命令搞定。

对于Spring Boot特有的Actuator端点，我编写了actuator-cli.sh脚本：

#!/bin/bash # 快速调用Actuator端点并格式化JSON curl -s http://localhost:8080/actuator/health | jq '.status' curl -s http://localhost:8080/actuator/metrics/jvm.memory.max | jq '.measurements[0].value'

配合watch -n 2 ./actuator-cli.sh，可实时监控内存使用趋势，效果不输IDEA Dashboard。

3.4 版本协作：Git CLI的精准控制艺术

去掉IDEA的Git图形界面后，协作反而更透明。关键操作全部用CLI完成：

分支创建与切换：
git checkout -b feat/task-assign origin/dev
强制从远程dev分支创建，避免本地分支偏离。
部分提交：
git add -p逐块选择变更。当一个文件同时修改了业务逻辑和日志级别时，可只提交业务逻辑部分，日志调整留待下次提交。
冲突解决：
git merge --no-commit --no-ff feature/login先合并不提交，用git diff --ours HEAD查看当前分支修改，git diff --theirs HEAD查看对方分支修改，再手动编辑冲突文件。比IDEA的三栏对比更清晰，避免误删关键代码。
提交信息规范：
采用Conventional Commits标准，预置.husky/pre-commit钩子：
```
#!/bin/sh echo "Checking commit message format..." if ! grep -q "^(feat|fix|docs|style|refactor|test|chore):" "$1"; then echo "ERROR: Commit message must start with 'feat:', 'fix:', etc." exit 1 fi
```
这样git commit -m "feat: add task assignment logic"才能通过，确保Git log可读性强，为后续CI自动生成Changelog打基础。

4. 实操避坑指南：踩过的12个坑与解决方案

4.1 Maven依赖冲突：不是AI的问题，是你的配置问题

现象：AI生成的代码引入spring-boot-starter-data-jpa，但项目已存在spring-boot-starter-web，Maven报错NoSuchBeanDefinitionException。

根因：spring-boot-starter-data-jpa默认启用Hibernate，而spring-boot-starter-web不包含JPA依赖，导致Spring容器找不到JpaRepositoryBean。

解决方案：

在pom.xml中显式声明依赖版本，打破传递依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> <version>3.2.0</version> </dependency>

或用mvn dependency:tree定位冲突源：
mvn dependency:tree -Dincludes=org.hibernate:hibernate-core
发现某第三方库引入了旧版Hibernate，此时在<exclusions>中排除：
```
<exclusion> <groupId>org.hibernate</groupId> <artifactId>hibernate-core</artifactId> </exclusion>
```

实操心得：AI生成代码时，永远假设它不知道你的项目全局依赖树。每次生成后，必须执行mvn dependency:analyze检查未使用的依赖，用mvn dependency:purge-local-repository清理本地缓存，避免旧版本干扰。

4.2 Spring Boot Banner乱码：字符集陷阱

现象：启动时Banner显示方框乱码，而非ASCII艺术字。

根因：VS Code终端默认UTF-8，但Spring Boot Banner字体使用ANSI转义序列，某些Linux发行版终端（如CentOS 7）默认LANG=en_US.UTF-8，但缺少相应字体。

解决方案：

在application.yml中关闭Banner：
```
spring: main: banner-mode: off
```
或强制指定字符集：
java -Dfile.encoding=UTF-8 -jar target/app.jar
终极方案：用spring-boot-banner-generator在线生成PNG Banner，配置spring.banner.image.location=classpath:banner.png。

4.3 AI生成代码的事务失效：Spring AOP的隐形门槛

现象：AI生成的Service方法标注@Transactional，但数据库操作未回滚。

根因：Spring AOP代理机制限制。当Service内部方法调用（如methodA()调用methodB()），若methodB()也标注@Transactional，则不会创建新事务，因调用发生在同一对象实例内。

解决方案：

重构代码，确保事务方法被外部Bean调用；

或启用AspectJ编译时织入（CTW），在pom.xml中添加：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency> <dependency> <groupId>org.aspectj</groupId> <artifactId>aspectjweaver</artifactId> </dependency>

并在启动类添加@EnableAspectJAutoProxy(exposeProxy = true)。

实操心得：AI目前无法理解Spring AOP的代理原理。所有涉及事务、缓存、安全的方法，必须人工Review调用链。我建立了一个Checklist：
✅ 方法是否被Controller直接调用？
✅ 是否存在Service内部自调用？
✅@Transactional是否标注在public方法上？（private方法无效）
✅ 是否配置了@EnableTransactionManagement？

4.4 Docker Compose网络隔离：服务间调用失败

现象：Task Service启动后，无法调用User Service的/api/user/profile接口，报Connection refused。

根因：Docker Compose默认为每个服务创建独立网络，但服务名解析需在docker-compose.yml中显式声明。

解决方案：

version: '3.8' services: task-service: build: ./task-service depends_on: - user-service environment: - USER_SERVICE_URL=http://user-service:8080 # 关键：用服务名，非localhost user-service: build: ./user-service ports: - "8081:8080"

并在Task Service代码中，用@Value("${user.service.url}")注入URL，而非硬编码http://localhost:8081。

4.5 VS Code Java插件卡死：LSP服务器内存溢出

现象：打开大型Spring Boot项目，VS Code CPU飙升100%，Java语言服务无响应。

根因：Red Hat Java插件的Language Server（jdt.ls）默认内存为1GB，面对10万行代码时不足。

解决方案：

在VS Code设置中搜索java.configuration.runtimes，添加JDK17路径；

创建~/.vscode/settings.json，增加：

{ "java.configuration.updateBuildConfiguration": "interactive", "java.configuration.runtimes": [ { "name": "JavaSE-17", "path": "/usr/lib/jvm/java-17-openjdk-amd64" } ], "java.home": "/usr/lib/jvm/java-17-openjdk-amd64" }

修改jdt.ls启动参数，在~/.vscode/extensions/redhat.java-*/server/bin/start.sh中，将-Xmx1G改为-Xmx4G。

4.6 单元测试覆盖率暴跌：AI不生成测试代码

现象：AI生成Controller后，mvn test覆盖率从75%降至32%。

根因：AI生成的代码默认不含测试，而Maven Surefire插件只运行src/test/java下的测试类。

解决方案：

在Prompt中强制要求生成JUnit 5测试：
“为上述Controller生成对应单元测试，使用MockMvc模拟HTTP请求，验证状态码、JSON结构、字段值”；

配置pom.xml启用JaCoCo：

<plugin> <groupId>org.jacoco</groupId> <artifactId>jacoco-maven-plugin</artifactId> <version>0.8.11</version> <executions> <execution> <goals> <goal>prepare-agent</goal> </goals> </execution> <execution> <id>report</id> <phase>test</phase> <goals> <goal>report</goal> </goals> </execution> </executions> </plugin>

执行mvn clean test jacoco:report生成HTML报告，定位未覆盖代码。

4.7 Maven阿里云镜像失效：网络策略变更

现象：mvn compile卡在Downloading from aliyun: https://maven.aliyun.com/repository/public/...。

根因：阿里云Maven仓库2023年10月起要求HTTPS，部分旧版settings.xml仍用HTTP地址。

解决方案：

更新settings.xml中的mirror URL：

<mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>Aliyun Maven</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

清理本地仓库：rm -rf ~/.m2/repository/org/springframework/boot/
执行mvn -U dependency:resolve强制更新快照版本。

4.8 Spring Boot DevTools热重启失效：类加载器隔离

现象：修改Controller代码后，curl请求仍返回旧响应。

根因：DevTools将应用类与第三方库类分离加载，但AI生成的代码若放在src/main/resources而非src/main/java，会被视为资源文件不触发重启。

解决方案：

确保AI生成的.java文件保存在src/main/java/com/example/...路径；

在pom.xml中确认DevTools依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> <optional>true</optional> </dependency>

启动时添加JVM参数：-Dspring.devtools.restart.enabled=true。

4.9 VS Code Git提交失败：行尾符不一致

现象：git commit报错LF will be replaced by CRLF，导致代码格式混乱。

根因：Windows系统默认CRLF，Linux/macOS用LF，VS Code未统一设置。

解决方案：

在VS Code设置中搜索files.eol，设为\n；
全局配置Git：git config --global core.autocrlf input（Linux/macOS）或git config --global core.autocrlf true（Windows）；
重置仓库行尾符：git rm --cached -r . && git reset --hard。

4.10 AI生成代码的Lombok失效：注解处理器缺失

现象：AI生成的DTO类使用@Data，但编译时报cannot find symbol。

根因：VS Code Java插件默认不启用Lombok注解处理器，需手动配置。

解决方案：

在pom.xml中添加Lombok依赖：

<dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

在VS Code设置中启用：
"java.configuration.updateBuildConfiguration": "interactive"
重启Java语言服务器（Ctrl+Shift+P → “Java: Restart Java Language Server”）。

4.11 Docker容器端口冲突：多项目并行启动

现象：启动Task Service时，报错Bind for 0.0.0.0:8080 failed: port is already allocated。

根因：多个Spring Boot项目默认用8080端口，Docker映射冲突。

解决方案：

在application.yml中动态端口：
```
server: port: ${PORT:8080}
```
启动容器时指定环境变量：
docker run -p 8081:8080 -e PORT=8080 task-service
或用docker-compose.override.yml为开发环境分配端口。

4.12 Arthas命令失效：JDK版本不匹配

现象：arthas-boot.jar附着失败，报Unsupported Java version。

根因：Arthas 4.0+要求JDK17+，但项目用JDK11编译。

解决方案：

下载匹配版本：Arthas 3.7.0支持JDK11；
或统一JDK版本：在pom.xml中指定<java.version>17</java.version>，并确保JAVA_HOME指向JDK17；
验证：java -version与$JAVA_HOME/bin/java -version输出一致。

5. 效率与质量的再平衡：去掉IDEA后的真实收益

去掉IDEA不是追求极简主义，而是用AI和CLI的确定性，置换IDEA的不确定性。三个月真实项目数据如下（基于“企业项目进度跟踪与工时管理系统”）：

指标	使用IDEA时期	去掉IDEA后	变化率	说明
单次需求开发耗时	4.2小时	2.8小时	↓33.3%	AI生成占1.1小时，Maven验证占0.6小时，人工Review占1.1小时；IDEA时期含索引加载、依赖解析、调试等隐性耗时
构建失败率	12.7%	4.3%	↓66.1%	CLI命令明确报错位置，IDEA常静默失败或错误提示模糊
代码重复率	18.5%	8.2%	↓55.7%	AI生成时强制引用公共DTO/Enum，避免各模块重复定义
Git提交粒度	平均每次提交12.3个文件	平均每次提交3.7个文件	↑精准度	CLI`git add -p`促使开发者思考变更边界，避免“一锅端”提交
新人上手时间	3.5天	1.2天	↓65.7%	新人只需掌握VS Code基础操作+5个Maven命令+Git核心流程，无需学习IDEA复杂界面

最关键的收益不是时间节省，而是认知负荷降低。IDEA把所有开发环节塞进一个UI，新手要同时理解Maven生命周期、Spring Boot自动配置、Git分支模型、调试器变量作用域……而解耦后，每个环节目标单一：VS Code专注代码呈现，Maven专注构建，Git专注版本，AI专注生成。就像把一辆多功能越野车，换成自行车+地铁+步行的组合——看似麻烦，但每段路都更可控、更省力。

当然，这不是银弹。当遇到Spring Cloud Gateway路由规则调试、Feign Client超时配置、或K8s YAML文件编写时，我依然会临时打开IDEA——它的YAML Schema校验和Spring Cloud插件确实无可替代。但日常CRUD开发，AI+CLI已足够坚实。

最后分享一个小技巧：我把所有常用CLI命令做成VS Code任务（tasks.json），按Ctrl+Shift+P调出“Tasks: Run Task”，选择“Compile”、“Test”、“Start Docker”等，键盘操作全程无需碰鼠标。真正的效率，从来不是工具多强大，而是你能否让它完全服从你的节奏。