AI 辅助开发实战：基于 Java 的招聘网站毕设项目架构与实现

AI 辅助开发实战：基于 Java 的招聘网站毕设项目架构与实现

摘要：高校学生在完成“Java 招聘网站毕设”时，常面临需求模糊、技术选型混乱、代码结构松散等问题。本文结合 AI 辅助开发工具（如 GitHub Copilot、通义灵码），从领域建模、模块解耦到 RESTful API 设计，系统性构建一个可扩展、易维护的招聘平台原型。读者将掌握如何利用 AI 提升开发效率，同时规避常见架构陷阱，产出符合企业级规范的毕设代码。

1. 毕设常见痛点：为什么“能跑”≠“能毕业”

过去两年帮师弟师妹看代码，发现最集中的问题不是“跑不通”，而是“跑得太随意”：

• 功能清单拍脑袋：想到啥写啥，结果“职位搜索”与“简历上传”耦合在一个 800 行的Controller里。
• 分层设计缺失：Service直接调用Mapper，事务注解随手一扔，回滚逻辑全靠运气。
• 重复代码爆炸：同样的字段校验、异常处理、分页封装，每个模块复制一遍，AI 生成也救不了。
• 测试=main 方法：没有单元测试，上线前手动点一遍，教授提问“事务边界在哪”直接沉默。

这些问题导致两个后果：一是答辩时被怼“你的架构图和代码对不上”；二是 Github 仓库没人敢提 PR。下面记录我如何用 AI 工具把“跑通”升级为“可演进”。

2. AI 辅助开发落地三件套：建模、CRUD、测试

2.1 领域建模：让 AI 先画“草图”

我先用自然语言在 Copilot Chat 里输入：

招聘网站核心域模型包含用户、职位、公司、简历、投递记录，请给出 UML 类图描述和关键字段。

30 秒后拿到初版，再让 AI 补充枚举（职位状态、简历审核状态）。把生成的 YAML 粘到 plantuml 在线渲染，得到下图：

人工复核时，我发现 AI 把“用户”与“公司”放同一表，果断拆为User与Company，并补充UserType枚举。AI 负责“快”，人负责“准”，两者互补。

2.2 CRUD 代码生成：别让 AI 一次性写 500 行

经验：让 AI 按“聚合根”粒度生成，而不是整库一键生成。示范指令：

基于 Spring Data JPA，写 User 聚合根的实体、Repository、Service、Controller，要求 DTO 转换使用 MapStruct，字段校验用 BeanValidation。

AI 给出 4 个文件，我逐行 Review：

• 实体字段类型是否正确？private Integer age被 AI 写成String，手动改回。
• 关联关系是否懒加载？AI 默认EAGER，改LAZY并加fetch = FetchType.LAZY。
• 是否暴露敏感字段？AI 把password也输出到 DTO，立刻建UserDto排除。

这样 15 分钟就完成了用户模块骨架，比纯手工快 3 倍，且错误率可控。

2.3 单元测试：AI 写正向，人写逆向

让 AI 生成“用户注册成功”的 Mockito 测试只用 10 秒：

@Test void should_save_user_when_email_not_exists() { when(userRepo.existsByEmail("tom@qq.com")).thenReturn(false); userService.register(dto); verify(userRepo).save(any(User.class)); }

但边界异常（邮箱已存在、数据库唯一约束冲突）必须自己补，否则答辩演示时教授一扔curl请求就 500。结论：AI 负责“快乐路径”，人负责“痛苦路径”。

3. 核心模块 Clean Code 实战

下面给出三个聚合根的“关键代码片段”，均经过 AI 初稿 + 人工重构，可直接粘贴到毕设里当模板。

3.1 用户管理

@Entity @Table(name = "users") public class User { @Id @GeneratedValue(strategy = IDENTITY) private Long id; @Column(unique = true, nullable = false) private String email; @Convert(converter =PasswordEncryptor.class) // 自定义 JPA 加密转换器 private String password; @Enumerated(STRING) private UserType type; // CANDIDATE, HR } @Service @Transactional public class UserService { public User register(UserDto dto){ if(userRepo.existsByEmail(dto.getEmail())){ throw new BizException("邮箱已存在"); } User user = User.create(dto); return userRepo.save(user); } }

• 事务范围只在 Service，Controller 不碰数据库。
• 密码加密用AESPasswordEncryptor实现AttributeConverter，保证数据库落盘即密文。

3.2 职位发布

@Entity public class Job { private Long id; private String title; private String description; @ManyToOne(fetch = LAZY) private Company company; @Enumerated(STRING) private JobStatus status; // OPEN, CLOSED } @Repository public interface JobRepository extends JpaRepository<Job, Long>, QuerydslPredicateExecutor<Job> { }

借助 Querydsl，一行代码搞定动态条件搜索：

BooleanBuilder b = new BooleanBuilder(); keyword.ifPresent(k -> b.and(job.title.containsIgnoreCase(k))); return jobRepo.findAll(b, pageable);

AI 先生成if/else拼接 SQL，我直接重构为 Querydsl，既类型安全又易读。

3.3 简历投递（重点：幂等性）

@Entity public class Application { @Id @GeneratedValue(strategy = IDENTITY) private Long id; @NaturalId // 使用 Hibernate @NaturalId 保证复合业务键唯一 @Column(name = "uk_job_user", unique = true) private String jobUserKey; // jobId + "_" + userId @ManyToOne private Job job; @ManyToOne private User candidate; @Enumerated(STRING) private ApplicationStatus status; // PENDING, ACCEPTED, REJECTED }

Service 层：

public void apply(Long jobId, Long userId){ String key = jobId + "_" + userId; if(applicationRepo.existsByJobUserKey(key)){ throw new BizException("已投递，请勿重复提交"); } Application app = new Application(); app.setJobUserKey(key); ... applicationRepo.save(app); }

并发场景下，数据库唯一索引兜底，幂等性双保险。性能压测 200 线程重复提交，仅 1 条成功，其余抛异常，符合预期。

4. 并发投递场景：事务与锁的边界

上面apply()方法标记@Transactional，但高并发仍可能产生“幻读”——两个线程同时通过exists检测。解决方案：

1. 事务隔离级别可提到REPEATABLE_READ，但性能下降。
2. 更轻量：利用唯一索引冲突，catchDataIntegrityViolationException后转业务提示，数据库当分布式锁。

我选方案 2，实测 QPS 从 1200 降到 1150，几乎无损耗，且代码更简洁。

5. 性能与安全：教授最爱问的“加分项”

• 密码加密：不用 MD5，AI 提示BCrypt即可，给出BCryptPasswordEncoder配置类。
• XSS 防护：AI 会写Jsoup.clean，但忘记给 JSON 入站统一做过滤。我加Jackson xss模块，全局生效。
• SQL 注入：JPA 已占位符，但 AI 生成的动态 SQL 若用拼接，立即改 Querydsl。
• 分页性能：职位表 50 万数据，AI 写的SELECT *+limit在 Explain 里全表扫描。加联合索引(status, create_time)后，type=index，扫描行降到 20。

6. 生产环境避坑指南：AI 不是免死金牌

1. 拒绝硬编码：AI 喜欢if(role == 1)，含义不明。统一枚举，魔法值零容忍。
2. 自动补全陷阱：AI 看你写过sendEmail()，下次直接写sendEmail(to, title)，把title当参数，编译通过逻辑错。必须 Review。
3. 日志与监控：AI 不会主动写log.info()，自己补，关键业务留痕，方便答辩演示“日志溯源”。
4. 配置外置：AI 生成的application.yml里数据库密码明文，用ENV变量替换，否则 Git 仓库成社工库。
5. 版权与开源协议：AI 可能复制 GPL 代码，毕设若闭源上架校内云，有合规风险。用mvn license:check扫描。

7. 可落地的重构路线（送给读者）

如果你已经把“能跑”的代码交初稿，不妨按下面节奏二次迭代：

1. 拉分支refactor/clean-arch，先让 AI 生成领域模型图，对照现有代码，标出“跨层引用”点。
2. 把Controller里的业务逻辑抽到Service，再抽Domain实体行为，过程让 AI 按方法粒度生成，人做整合。
3. 每抽一层，补单元测试，用 Copilot 生成正向用例，人补充异常用例，保证测试覆盖率 > 80%。
4. 引入 MapStruct、Querydsl、Validator 等“样板杀手”，让 AI 写转换接口，人写配置。
5. 上线前跑一遍 SpotBugs、CheckStyle，把 AI 留下的“小黄条”清零。

8. 写在最后：AI 与人工 Review 的协同

经过两个月实战，我最大的感受是——AI 把“写”代码的耗时从 60% 降到 20%，但“读”代码的重要性反而上升。机器擅长套路，人负责判断边界、异常与伦理。毕设不是炫技场，而是把“可维护”证明给教授看。下次当你一键 Accept AI 提示时，别忘了问自己三句话：

• 这段代码如果换师弟来改，他 5 分钟能看懂吗？
• 如果 1 万并发过来，这段逻辑还成立吗？
• 如果数据泄露，这段代码会不会背锅？

把这三关过了，再合并到 main 分支，你的毕设自然就有了“企业级”味道。接下来，打开你的旧仓库，挑一个最臃肿的Controller，试着用 AI 重构成领域模型，然后跑一遍单元测试。你会发现，AI 不是来替你写作业的，而是逼你更早面对“代码责任”——这大概也是毕业前最重要的一课。