前阵子接了个内部管理系统的需求工期压得紧还得从零搭建Spring Boot工程。放在以前我的路径是先去 start.spring.io 拉一个基础工程再手工往 pom.xml 里补依赖、改 application.yml、写统一返回结构、配日志、接数据库……这一套流程就算很熟练也至少要小半天。那次正好想试一下飞算JavaAI就用它一键生成完整工程从描述需求到拿到一个能启动的Spring Boot项目整个过程比我想象的顺。这篇就把我实际走的流程、生成之后的检查步骤、以及几处必须人工干预的地方都记下来想用AI脚手架加速Spring Boot开发的朋友可以参考。1. 为什么我会把“飞算JavaAI”放进Spring Boot工程的生产链路1.1 传统从0到1搭建Spring Boot工程的隐性成本很多人觉得Spring Boot项目初始化是件“小事”一次两次确实不算啥但如果你是经常要接新项目、做企业内部系统、带新人就会发现这件事的隐性成本其实很高。首先是依赖版本兼容问题。Spring Boot本身有BOM帮你管理大部分依赖版本但引入第三方组件时照样容易踩坑比如Spring Boot 2.x升级到3.x之后javax命名空间变成了jakarta很多老依赖直接编译不过再比如MySQL驱动坐标从mysql-connector-java变成了mysql-connector-j如果照着老文章复制粘贴Maven只会默默报红。这些都是新手最容易卡住的地方也是最没有技术含量、却又最浪费时间的地方。其次是配置分散。一个“完整工程”绝不只是pom.xml和启动类它还包括application.yml、日志配置、全局异常处理、统一返回结构、跨域配置、接口文档配置。这些东西单看都不难但每个项目都要重新写一遍而且不同人的写法还不一样。我带过的团队里有人用Lombok、有人不用有人喜欢Result 、有人直接返回Map最后代码风格五花八门维护成本全在后头。飞算JavaAI能解决的是这个“工程骨架重复建设”的问题。它可以按你的需求生成一个可编译、可启动的Spring Boot工程pom依赖、启动类、配置文件、示例接口都给你写好。省下来的时间我会花在业务整理和代码审查上这两件事才是真正有产出价值的。1.2 它能帮你省哪部分时间不能帮你省哪部分我用了几次之后对飞算JavaAI的定位是它像一个“熟手实习生”能快速搭出工程骨架但你不能指望它一步到位交付生产级代码。它能帮你省的是这些时间选择依赖版本你告诉它要Spring Boot 3.2 Java 17它会自动匹配合适的starter坐标不会出现javax/jakarta这种低级错误。编写基础代码启动类、通用返回Result、全局异常处理器、示例Controller这些模板代码生成得很快。初期配置数据源占位符、Redis、Swagger、日志级别它会按常规方式写进application.yml你只需要改成真实环境参数。它不能帮你省的是这些时间业务建模你到底要管商品还是订单表结构怎么设计状态机怎么流转这些只能你自己想清楚。代码审查生成代码里可能有示例方法和你真实的表结构对不上还有可能没做参数校验、没加鉴权这些必须人工过一遍。性能与安全加固AI默认生成的是“能跑”的代码不是“抗造”的代码。接口是否需要限流、敏感数据是否需要脱敏、数据量上来之后是否需要分页优化它不会替你考虑。所以我的建议是把它当作“加速器”而不是“自动驾驶”。你仍然需要懂Spring Boot的基本原理否则生成完代码后连怎么改都不知道。1.3 什么样的人最适合用这个方案用飞算JavaAI生成Spring Boot完整工程我非常推荐下面三类人尝试第一类是刚学Spring Boot的新手。你不需要一上来就折腾复杂的环境和依赖直接看它是怎么组织controller、service、repository的能更快理解分层结构。当然前提是别只看代码还得自己动手敲一遍。第二类是经常要做原型验证的开发者。领导让你三天出个演示系统与其翻历史工程复制粘贴不如直接按需求生成一个干净工程把业务代码补上省下整理依赖的时间。第三类是需要在团队内统一工程规范的负责人。你可以把生成结果作为初始模板要求大家都从这个骨架出发开发避免“一人一套写法”的混乱。但要注意团队规范最终还是要沉淀成自己的脚手架文档AI工具只是帮你起步。2. 生成工程前的需求梳理与环境准备这一步决定了生成结果能不能用2.1 先想清楚要生成什么样的工程我见过很多翻车案例都是因为“需求描述太简略”。你只写一句“帮我生成一个Spring Boot管理后台”那工具大概率只会给你一个Hello World级别的空壳。AI不是算命的它只能根据你提供的信息去猜。所以在生成之前我会先在文档里把工程需求写清楚。你可以参考我的模板项目名称例如store-admin包名例如com.example.storeJava版本和Spring Boot版本例如 Java 17 Spring Boot 3.2.5构建工具Maven 还是 Gradle模块划分是否要分用户、商品、订单还是单模块先跑通数据库和ORMMySQL Spring Data JPA还是 MyBatis-Plus需要集成的组件Redis、Swagger、Spring Security、JWT、消息队列等接口风格RESTful统一返回 Result部署方式打成 jar 包运行还是需要 Dockerfile举个例子我这次生成的是一个简单的商品服务需求描述是这么写的生成一个 Spring Boot 3.2.5 项目使用 Java 17Maven 构建包名 com.example.store。集成 Spring Web、Spring Data JPA、MySQL、Lombok、springdoc-openapi。提供商品查询分页和新增商品的接口所有接口返回统一的 Result 结果包含全局异常处理。日志使用 logback配置文件使用 application.yml。这样写完之后生成出来的工程基本就八九不离十了。如果你只想先验证一个技术点比如“Spring Boot 集成 WebSocket 的 yml 配置”那也可以单独把需求缩小让它只生成一个带WebSocket的独立模块不用一上来就把所有东西都塞进去。2.2 本地环境准备JDK、Maven、IDE 一件都不能少很多人生成完工程之后卡在编译阶段不是因为代码有问题而是本地环境版本不对。这里我列一个相对稳妥的搭配供你参考。工具推荐版本说明JDK17 或 21Spring Boot 3.x 要求 Java 17 以上别再用 Java 8 硬跑Maven3.6.3 以上3.8 以上更好下载依赖更稳定IDEIntelliJ IDEA 社区版社区版免费Maven、Git、Spring 插件都够用MySQL5.7 或 8.08.0 记得配置连接时区参数Redis任意稳定版如果没有 Redis 环境建议先用默认配置生成后续再集成环境检查命令也不用我说了吧java -version和mvn -v都打印出正常版本就行。还有一个容易被忽略的点如果你在国内Maven 从中央仓库拉依赖会非常慢。我建议在 Maven 的settings.xml里配置阿里云镜像尤其是刚开始下载 Spring Boot 依赖的时候能省下大量时间。这个不是飞算JavaAI能替你做好的属于本地环境标配。2.3 给飞算JavaAI的“提示词”要怎么写才能生成得更靠谱不少工具都支持自然语言输入但同一个工具不同人用效果差别很大核心差距在于提示词质量。想要生成一个结构清晰、能直接启动的Spring Boot工程建议你在描述里包含这些信息明确版本Java 版本、Spring Boot 版本、构建工具。这个最关键它决定了代码里是用javax还是jakarta。明确包名和类名工具猜包名经常猜不准比如 “com.example” 被猜成 “com.examle”后面改起来很麻烦。明确需要的 starter比如spring-boot-starter-web、spring-boot-starter-data-jpa、lombok、springdoc-openapi。明确数据库和连接信息如果只是生成工程可以写 placeholder比如jdbc:mysql://localhost:3306/demo让工具先按这个结构生成。明确附加功能要不要接口文档、要不要鉴权、要不要统一异常处理。我一直用的是下面这个模板效果很稳定请生成一个 Maven 管理的 Spring Boot 3.2.5 工程Java 17包名 com.example.store包含 spring-boot-starter-web、spring-boot-starter-data-jpa、com.mysql:mysql-connector-j、lombok、springdoc-openapi-starter-webmvc-ui。启动类命名为 StoreApplication。要求application.yml 中配置 MySQL 连接和 JPA ddl-autoupdate提供一个 ProductController包含分页查询和新增接口所有接口返回 Result 配置全局异常处理使用 logback-spring.xml最后给出完整的文件目录结构说明。你可能会问描述这么长是不是太啰嗦真不是。AI工具最怕的是模糊信息你把关键约束写清楚它生成出来的工程几乎不需要大改顶多调几个参数。这一点在之后的Review阶段会节省大量时间。3. 实测完整流程从输入描述到跑出一个能启动的Spring Boot项目3.1 从输入需求到拿到工程文件的操作路径飞算JavaAI的界面本身不复杂核心流程我拆成四步。第一步打开工具创建一个新项目任务。输入我上面准备好的需求描述如果工具提供了Java版本、Spring Boot版本、构建工具的下拉选项直接选好如果只支持纯文本那就在描述里写明。第二步选择附加功能。这一步很重要我建议第一次生成时不要太贪心先把 Web、数据库、Swagger 这几个最常见的选上就行。像消息队列、分布式事务这类重组件等业务真正需要了再通过后续生成或者手动添加否则生成出来的代码会有一堆用不上的依赖。第三步点击生成。等待时间通常在一分钟左右如果需求复杂、依赖多可能需要两三分钟。生成完之后一般会提供两个结果在线预览文件树、下载压缩包。第四步下载zip包解压到本地工作目录。之后用IDEA或者VS Code打开第一次加载Maven依赖会慢一点属于正常现象。这里可以说说我的体验我最初其实只抱着“试试看”的心理想看它生成的代码能不能达到“能启动”这个及格线。结果它生成的工程目录结构非常规整甚至比我自己手搭的还要干净。当时最直观的感受是至少省掉了改pom和配置文件的十几分钟。3.2 我拿到手的工程长什么样目录与核心文件拆解生成完毕后我看到的目录结构大致是下面这个样子store/ ├── pom.xml ├── src/main/java/com/example/store/ │ ├── StoreApplication.java │ ├── common/ │ │ ├── Result.java │ │ └── GlobalExceptionHandler.java │ ├── config/ │ │ └── OpenApiConfig.java │ ├── controller/ │ │ └── ProductController.java │ ├── dto/ │ │ └── ProductCreateRequest.java │ ├── entity/ │ │ └── Product.java │ ├── repository/ │ │ └── ProductRepository.java │ └── service/ │ └── ProductService.java └── src/main/resources/ ├── application.yml └── logback-spring.xml这个结构是典型的单模块分层很多中小型项目都是这么组织的。common里放统一返回和全局异常config放Swagger配置controller、service、repository各司其职看着就很舒服。pom.xml 的关键依赖大概长这样dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdorg.springdoc/groupId artifactIdspringdoc-openapi-starter-webmvc-ui/artifactId version2.5.0/version /dependency /dependencies这里两个细节值得注意一是MySQL驱动用的是com.mysql:mysql-connector-j不是老坐标二是Swagger用的是springdoc-openapi-starter-webmvc-ui不是springfox。也就是说AI默认按Spring Boot 3.x的最佳实践生成了依赖不用我再手动调整。application.yml 生成的内容类似于server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/store?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: ${DB_PASSWORD:root} jpa: hibernate: ddl-auto: update show-sql: true springdoc: swagger-ui: path: /swagger-ui.html你看它连时区参数、编码、密码占位符都处理了这些小细节是我手写时经常忘的。当然DDL_AUTOupdate只适合开发环境生产环境我会改成validate这个后面细说。ProductController 也生成了一个简单的CRUD雏形包含新增和分页查询统一返回ResultT这部分我直接沿用了只改了几个字段名。整体来说第一个版本就达到“能编译、能启动、能调接口”的程度。3.3 第一次启动从导入到看到 Tomcat started导入工程这一步没什么好说的IDEA直接用Open选择解压后的pom.xml即可。Maven会自动开始下载依赖等右下角进度条跑完即可。启动之前要做一件事把application.yml里的数据源改成你自己本地的用户名和密码。如果你机器上没有装MySQL可以用H2数据库临时顶一下把spring.datasource.url改成jdbc:h2:mem:testdb再加上com.h2database:h2依赖这样等Redis和MySQL都齐了再换回来也行。启动类右键执行 Run我第一次跑的时候控制台正常输出Tomcat started on port 8080 (http) with context path Started StoreApplication in 3.42 seconds看到这行就说明工程本身没问题了。如果出现端口占用就在application.yml里把server.port改成8081如果出现Driver加载失败检查pom里有没有引入MySQL驱动再检查JDK版本是否匹配。跑起来之后访问http://localhost:8080/swagger-ui.html就能看到接口文档点开product-controller就能直接调试新增和分页接口。到这一步“从0到1”已经完成了但离“真正可用”还有一段距离下面这是重头戏。4. 生成不是终点落地前必须完成的代码Review与配置校正4.1 版本与命名空间Spring Boot 3.x最容易翻车的三个点先说一个很多人问过的问题“为什么我网上抄的代码在Spring Boot 3里编译不过”十有八九是命名空间问题。Spring Boot 3.x完全基于Jakarta EE 9原来的javax.servlet、javax.persistence全部改成jakarta.servlet、jakarta.persistence。如果你在生成代码里看到import javax.*那基本可以断定依赖版本是2.x的需要升级Spring Boot或者手动改import。第二个容易翻车的是数据库驱动坐标。Spring Boot 1.x和2.x时代MySQL驱动是mysql:mysql-connector-java到了Spring Boot 3.x官方把这个坐标改成了com.mysql:mysql-connector-j。如果你的pom还是老坐标虽然也能拉下来但不推荐因为新版本驱动对MySQL 8的兼容性更好建议直接用新坐标。第三个是Swagger集成。很多老教程用springfox-boot-starter但springfox已经停止维护很久了和Spring Boot 3.x完全不兼容。我实测下来最稳的是org.springdoc:springdoc-openapi-starter-webmvc-ui:2.5.0这个和Spring Boot 3.x配合得非常好生成的Swagger UI页面也现代很多。这三个点飞算JavaAI生成的时候都已经帮我处理好了。但如果你拿着AI生成的代码又往里手动加了一些老依赖就很容易被重新带进坑里。所以Review阶段要重点看pom里新增的那部分。4.2 必须人工校准的配置项清单AI能生成一个“合理默认值”但不可能知道你生产库的密码、测试环境的端口、对象存储的endpoint。所以生成完工程后我会对照下面这张表逐项检查配置项生成默认值你需要改成什么server.port8080按实际部署环境调整开发、测试、生产不同端口spring.datasource.urllocalhost:3306/store改成真实数据库地址和库名spring.datasource.username/passwordroot / ${DB_PASSWORD:root}改成环境变量引用别硬编码真实密码spring.jpa.hibernate.ddl-autoupdate开发用update可以生产强烈建议validate或nonespring.jpa.show-sqltrue生产环境关掉否则日志量太大springdoc.swagger-ui.path/swagger-ui.html如果要做接口文档隔离可以加一个访问前缀除了这些还要检查有没有把生产密钥写死在application.yml里。比如Redis密码、短信密钥、OSS accessKeyAI不会知道你的真实值所以它会写占位符但如果它猜了一个accessKey: your-access-key你就要记得用环境变量替换掉。我有一次就是因为没改ddl-auto上线前跑测试环境Hibernate直接把一张核心表的字段类型改了差点酿成大事故。从那以后我对生成文件里的ddl-auto一律强制改成validate。4.3 代码审查建议哪些生成代码可以直接留着哪些建议删掉很多人拿到生成的代码看都不看就开始写业务这是很危险的。我把生成代码分成了三类。第一类是“可以直接留的”启动类、common目录下的Result和全局异常处理、config目录下的OpenApiConfig、application.yml骨架、logback-spring.xml。这些属于通用脚手架本身没什么业务含义风格也规范留着很稳。第二类是“需要修改的”Controller、Service、Entity、Repository。生成出来的ProductController可能只写了新增和分页但你的真实业务可能有删除、更新、导入导出字段也可能和数据库表对不上。这时候就得按实际需求改核心是别让Controller里残留演示逻辑。第三类是“建议删掉的”某些AI生成的示例方法比如demo()、hello()、用Mock数据返回的接口。这些在开发阶段可以留着验证链路但提交代码前要清干净否则同事看到会很迷。我的审查习惯是先全局搜一下TODO、demo、hello、mock把明显是示例的代码挑出来确认再逐个看Controller的每个接口确认有没有方法到Service层、Service层有没有真实调Repository、参数有没有校验注解。整个过程比手写工程多花不了几分钟但能避免很多部署后才发现的问题。4.4 启动时遇到问题建议的排查顺序如果你照着上面的流程启动失败了不要慌按下面顺序排查最快。第一确认依赖是否下载完整。IDEA的Maven面板如果出现红色波浪线先执行mvn clean compile看具体的报错信息。很多时候是网络导致依赖jar包不完整多更新几次或者换镜像就能解决。第二看配置文件有没有解析问题。Spring Boot启动时如果配置文件有语法错误比如YAML缩进不对会直接报Failed to bind properties。这时候用IDEA的YAML插件检查格式比肉眼快很多。第三检查数据库连接。最常见的是连接超时换成本地MySQL或者H2先跑通。另外Spring Boot 3.x对MySQL 8推荐使用com.mysql.cj.jdbc.Driver旧驱动会提示加载失败。第四检查端口和上下文路径。如果端口被占用改成8081如果Git仓库里设置过server.servlet.context-path访问路径也要加前缀。最后看日志关键字Caused by。不要傻乎乎去搜整段报错从最底部的Caused by开始看原因通常只有一句话。这些经验不针对飞算JavaAI而是所有Spring Boot工程通用。工具能帮你生成代码但不能替你完成环境适配。5. 跑通之后的业务扩展从示例工程到真正可用的系统5.1 加一个真正的业务模块时要动哪些地方一个完整的业务模块绝不是一个Controller就能搞定的。我习惯按“表结构 - Entity - Repository - Service - Controller - DTO”的顺序来加这个顺序也适合在AI生成的骨架上填充业务。假设要新增“分类管理”模块第一先在建表SQL里加category表确定字段和索引。第二写一个CategoryEntity用注解映射到表结构。第三写CategoryRepository继承JpaRepository声明需要的查询方法。第四写CategoryService做事务、参数校验、业务判断。第五写CategoryController只负责参数接收和结果返回。第六定义CategoryCreateRequest和CategoryUpdateRequest加NotBlank、Size等校验注解。这个流程是AI最擅长帮你生成初稿的。你可以继续让飞算JavaAI生成这部分代码也可以自己写。核心是保持目录结构和命名规范这样才能让它生成的下一段代码与你已有的工程风格一致。5.2 常用组件接入要点WebSocket、Caffeine、MinIO、虚拟线程搜索热词里出现了很多Spring Boot集成场景我挑几个日常开发中最常碰到的说说在生成工程基础上怎么扩展。先说WebSocket。生成工程里默认不会有WebSocket依赖你需要手动在pom里加spring-boot-starter-websocket。它的核心不是yml配置而是一个配置类实现WebSocketConfigurer注册WebSocketHandler并指定暴露的路径。yml里通常只需要配置Tomcat的缓冲大小等参数很多人以为WebSocket配在yml里就够其实连接还是靠Java配置类驱动。再说Caffeine缓存。这是一个本地缓存库性能很好。生成工程时如果没选缓存可以手动添加依赖com.github.ben-manes.caffeine:caffeine然后写一个CacheConfig声明Caffeine.newBuilder().expireAfterWrite(10, TimeUnit.MINUTES).maximumSize(10_000).build()最后在启动类上加上EnableCaching方法上使用Cacheable(cacheNames product, key #id)就能生效。这里要注意序列化问题默认JDK序列化性能一般建议配一个Jackson序列化器。然后是MinIO对象存储。之前我在生成工程里集成过核心就三步加依赖io.minio:minio在yml里写endpoint、accessKey、secretKey、bucket再写一个MinioConfig用Value读取并创建MinioClient。上传文件时调用minioClient.putObject(...)返回文件URL即可。这个组件生成工具通常不会自动包含因为需要具体地址和密钥但它本身集成难度不高。最后是Java 21虚拟线程。如果你用的JDK 21加Spring Boot 3.2以上可以在application.yml里加spring: threads: virtual: enabled: true加上之后Spring MVC处理请求会使用虚拟线程在高并发场景下能有效降低内存压力。不过要注意如果你的代码里有synchronized阻塞或者使用ThreadLocal虚拟线程场景下会有一些额外坑需要先做充分测试。5.3 如何持续地让AI帮你写代码而不失控我见过有人把AI生成代码当成“一次性工程脚手架”生成完就再也不用了其实挺浪费。合理的思路是在后续迭代中继续把AI当“结对程序员”但每次喂给它的需求必须是独立的、清晰的。比如你要加一个“导出Excel”功能你就单独给它描述“在ProductController中增加一个导出Excel的接口要求使用EasyExcel查询条件下的所有商品数据返回二进制文件。”然后把现有实体类和pom片段贴进去让它生成具体代码。这样生成的代码通常八九不离十。但有两个底线不能碰第一所有AI生成代码必须经过编译和测试第二核心业务逻辑、金额计算、权限校验这类高风险代码我建议还是自己亲手写AI可以给初稿但最终审查和测试要牢牢握在手里。再强调一点用Git管理AI生成工程。每次让AI生成完新功能都先git diff看一下变更再提交。这样万一某次生成把工程改坏了还可以轻松回退。这是一条非常实用的建议别等到代码坏了再后悔。6. 我用下来的真实体会三个好用场景、七个踩坑点6.1 我最认可的三个使用场景第一个场景是“快速验证技术方案”。之前我需要验证Spring Boot集成WebSocket时的线程模型如果用传统方式新建工程再配依赖至少需要半小时。用飞算JavaAI生成一个带WebSocket模块的独立工程十分钟不到就跑通了测试完直接删掉心理负担很小。第二个场景是“带新人上手的起步工程”。让新同事拿AI生成的工程做基础改造比让他从零开始翻文档更平滑。先把目录结构、常用注解、配置项跑熟之后再逐步深入学习Spring Boot的自动装配原理这是效率比较高的路径。第三个场景是“项目初始阶段统一工程结构”。团队新开了个项目与其把自己的历史工程拷来拷去不如统一用一次生成结果作为模板再定制化补上团队自己的安全配置、日志规范、错误码约定。这样后续协作会顺畅很多。6.2 踩过的坑与解决办法用了一段时间我也总结了一些容易踩的坑列在这里给你提个醒。第一个坑需求描述不清生成一个空壳。我有一次只写了“生成订单管理系统”结果它给我一套通用的目录没有具体的订单字段和接口。后来我在描述里把字段、状态枚举、接口名称都写清楚生成质量立刻上了台阶。第二个坑Java版本和Spring Boot版本不匹配。生成时选了Spring Boot 3.x但本地JDK还是8直接编译失败。这个不能怪工具只能怪自己环境没对齐。先java -version确认再开工。第三个坑数据库连接串没有带时区参数。用MySQL 8连接时如果url后面不带serverTimezoneAsia/Shanghai偶尔会报时间差错误。飞算JavaAI生成的url默认带了但如果你自己改配置时不小心去掉就会踩这个坑。第四个坑Swagger UI 404。访问不了接口文档时先看pom里有没有引入springdoc-openapi-starter-webmvc-ui再看路径是否是/swagger-ui.html。另外Spring Boot 3里如果配置了spring.mvc.servlet.pathSwagger路径也要加前缀。第五个坑生成的接口没做参数校验。给Controller里的新增接口传空对象也能入库是我比较介意的。所以生成完代码后一定要给DTO补上NotBlank、NotNull、Min这类校验注解Controller里加Valid。第六个坑示例代码残留。比如生成的Controller里还有一个hello()测试接口忘了删部署后暴露在公网虽然无害但容易被人当成漏洞扫描目标。提交前搜一遍demo和hello很有必要。第七个坑过度信任生成的日志配置。默认logback可能只输出到控制台没有按天滚动。上线前最好加上RollingFileAppender不然日志文件只增不减几天就能占满磁盘。6.3 我的建议以“验收”心态对待AI生成工程而不是“交付”心态最后说点掏心窝的话。AI工具生成Spring Boot工程越来越成熟确实能把我们从“搭架子”里解放出来但这并不代表依赖管理、工程规范、代码审查这些基本功不重要了。恰恰相反正因为生成速度变快了人工Review这个环节才显得更关键。我现在的做法是无论多信赖工具生成完工程后都会先写一个最小冒烟测试比如启动应用访问/api/ping确认链路通然后把关键配置改成环境变量引用再补上关键接口的单测最后才写业务。这套流程下来AI生成工程帮我省了大概60%的启动时间剩下的40%依然靠人工把关。如果你也是经常折腾Spring Boot工程的人不妨找个项目试试这个流程想清楚需求写清描述一键生成认真验收。等你跑通第一个完整工程就会体会到“从0到1”这件事到底能有多快。
