用 Codex 生成 Spring Boot 项目，确实能省下大量脚手架时间。但把代码导进 IDE 的那一刻，真正的考验才开始——AI 生成的项目距离可投产，中间隔着一道必须人工跨越的 Gap。最近我专门拿 Codex 生成的 Java 项目做了一次完整检查，把发现的问题整理成一份清单，供同样想把它用在真实工程里的开发者参考。
项目结构：骨架搭起来了，细节藏雷
Codex 生成的目录结构乍一看像模像样，标准的src/main/java与src/test/java分层，包名也按反向域名规则铺开了。但逐层点开就会发现，有些文件夹是空的，有些该拆的模块却揉在了一起。
典型问题集中在两方面。一是包结构扁平化，比如把controller、service、mapper全塞在同一层级，缺少按业务域划分的domain或module分包，后续规模稍涨就会臃肿。二是资源文件位置漂移，我遇到过application.yml被放在src/main/resources/config多级子目录下的情况，Spring Boot 默认加载机制识别不到，启动直接报错。
更隐蔽的是.gitignore的缺失或过时。Codex 有时会生成一份通用模板，但里面没有排除 IDEA 的.idea/和 Maven 的target/，或者沿用旧版规则漏掉了新工具链的文件。导进 IDE 的第一件事，建议先核对目录树与团队规范模板的差异。
依赖版本：冲突比想象中多
打开pom.xml，Codex 通常能正确引入 Spring Boot Parent 和常用 Starter，但版本号管理是重灾区。
最频繁出现的是传递依赖冲突。比如同时引入了spring-boot-starter-data-redis和某个第三方缓存库，两者各拉了一条不同版本的lettuce或netty，Maven 的依赖调解机制未必选到你想要的那条。用mvn dependency:tree扫一遍，经常能看到红色标记的版本碰撞。
另一个是版本号硬编码。Codex 有时会在<dependency>里直接写死版本号，而不是交给 Parent 统一管理。这导致后续升级 Spring Boot 版本时，个别依赖被遗留在旧版本，形成"半吊子"升级。我的做法是直接删掉这些硬编码，让 Parent 的 BOM 接管，除非有明确的版本锁定需求。
还有个小坑是Scope 声明错误。测试依赖如spring-boot-starter-test被标成compile，或者反向地，运行时需要的库被标成test，本地跑没问题，打包上线就炸。
单元测试：能跑通不等于能用
Codex 生成的测试类往往包含基础的@SpringBootTest启动测试，但距离"可直接运行"还差几步。
首先是数据库依赖未隔离。生成的测试经常直接连真实数据源，没有配置 H2 或 Testcontainers 等内存数据库。这意味着在新环境或 CI 流水线里，测试会因为找不到数据库而失败。需要手动加上@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.ANY)或嵌入式容器配置。
其次是测试数据污染。多个测试方法共用同一套数据初始化逻辑，没有@Transactional回滚或@Sql脚本清理，顺序执行时互相干扰，单独跑却都能过。Codex 不会替你考虑这种边界，必须自己补@BeforeEach和@AfterEach的清理逻辑。
更关键的是覆盖率幻觉。生成的测试可能只覆盖了 Controller 层的 happy path，Service 里的分支逻辑、异常处理全未触及。用 JaCoCo 跑一遍报告，经常能看到大片红色区域。
配置文件：硬编码与敏感信息
application.yml或application.properties是 Codex 最容易埋雷的地方之一。
环境相关配置写死是最普遍的。数据库 URL、Redis 地址、日志级别直接硬编码在文件里，没有按dev/test/prod分环境配置。Spring Boot 的 Profile 机制明明很成熟，但 Codex 生成的模板经常只给一份"大杂烩"。
敏感信息明文存储是另一个必须手动修正的点。我见过 Codex 把演示用的数据库密码直接写在配置里，虽然标注了# TODO: replace in production，但谁能保证每个接手的人都记得改？正确的做法是把密码、密钥等抽离到环境变量或配置中心，本地用.env文件配合.gitignore排除。
还有端口与路径冲突。默认的8080端口在微服务环境里几乎必然撞车，server.port和server.servlet.context-path需要根据团队规范重新指定。
安全漏洞：AI 不会替你担责
把 Codex 生成的项目丢进安全扫描工具，结果往往不太乐观。
依赖库已知 CVE是高频问题。Codex 训练数据有截止期，它引入的某些库版本可能已存在公开漏洞。比如某次生成的项目中，logback-core版本带了一个中等严重度的 CVE，而最新 Parent 早已修复。这要求我们在生成后必须执行mvn org.owasp:dependency-check-maven:check或类似扫描，不能盲目信任。
安全配置缺位同样常见。Spring Security 的 starter 引入了，但配置类里全是默认的"放行"规则，没有启用 CSRF 防护、没有配置密码编码器、没有限制会话并发数。对于需要认证鉴权的项目，这些等于裸奔。
输入校验缺失是更深层的隐患。Controller 层接收的参数对象缺少@Valid注解，或者校验规则过于宽松，SQL 注入、XSS 等风险在边界上敞着口。Codex 生成的代码通常只保证"功能通"，不会主动加固安全防线。
从生成到投产：必须手动修正的典型项
综合以上检查，我把 Codex 生成 Spring Boot 项目后必须人工介入的环节列成一份短清单：
| 检查项 | 典型问题 | 修正动作 |
|---|---|---|
| 项目结构 | 包层级扁平、资源文件位置错误 | 按团队规范重构包结构，核对配置文件路径 |
| 依赖管理 | 版本冲突、硬编码版本号 | 统一收归 Parent BOM，清理冗余依赖 |
| 单元测试 | 连真实库、无数据隔离、覆盖率低 | 引入内存数据库，补全边界与异常分支测试 |
| 配置文件 | 硬编码环境配置、敏感信息明文 | 拆分多环境 Profile，敏感信息外置 |
| 安全扫描 | 依赖 CVE、配置缺位、输入无校验 | 执行 OWASP 扫描，补全 Security 配置与参数校验 |
Codex 的价值在于把项目从 0 推到 0.6，剩下的 0.4 需要开发者用工程化思维补完。我的习惯是生成后立即导入 IDE，按上述清单逐项过一遍，把自动化的部分交给工具，把判断和决策留给自己。AI 编程代理再强，目前还替代不了代码审查和安全兜底的责任——这份清单，就是两者之间的缓冲带。
