企业官网建设流程全解析

前阵子接了个内部管理系统的需求，工期压得紧，还得从零搭建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.store
• Java版本和Spring Boot版本：例如 Java 17 + Spring Boot 3.2.5
• 构建工具：Maven 还是 Gradle
• 模块划分：是否要分用户、商品、订单，还是单模块先跑通
• 数据库和ORM：MySQL + Spring Data JPA，还是 MyBatis-Plus
• 需要集成的组件：Redis、Swagger、Spring Security、JWT、消息队列等
• 接口风格：RESTful，统一返回 Result
• 部署方式：打成 jar 包运行，还是需要 Dockerfile

举个例子，我这次生成的是一个简单的商品服务，需求描述是这么写的：

生成一个 Spring Boot 3.2.5 项目，使用 Java 17，Maven 构建，包名 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 一件都不能少

很多人生成完工程之后卡在编译阶段，不是因为代码有问题，而是本地环境版本不对。这里我列一个相对稳妥的搭配，供你参考。

环境检查命令也不用我说了吧：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-auto=update；提供一个 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> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>org.springdoc</groupId> <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId> <version>2.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?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: ${DB_PASSWORD:root} jpa: hibernate: ddl-auto: update show-sql: true springdoc: swagger-ui: path: /swagger-ui.html

你看，它连时区参数、编码、密码占位符都处理了，这些小细节是我手写时经常忘的。当然，DDL_AUTO=update只适合开发环境，生产环境我会改成validate，这个后面细说。

ProductController 也生成了一个简单的CRUD雏形，包含新增和分页查询，统一返回Result<T>，这部分我直接沿用了，只改了几个字段名。整体来说，第一个版本就达到“能编译、能启动、能调接口”的程度。

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。所以生成完工程后，我会对照下面这张表逐项检查：

除了这些，还要检查有没有把生产密钥写死在application.yml里。比如Redis密码、短信密钥、OSS accessKey，AI不会知道你的真实值，所以它会写占位符，但如果它猜了一个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后面不带serverTimezone=Asia/Shanghai，偶尔会报时间差错误。飞算JavaAI生成的url默认带了，但如果你自己改配置时不小心去掉，就会踩这个坑。

第四个坑：Swagger UI 404。访问不了接口文档时，先看pom里有没有引入springdoc-openapi-starter-webmvc-ui，再看路径是否是/swagger-ui.html。另外Spring Boot 3里，如果配置了spring.mvc.servlet.path，Swagger路径也要加前缀。

第五个坑：生成的接口没做参数校验。给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”这件事到底能有多快。