AI 辅助开发实战：基于 Java Web 的毕业设计选题系统设计与实现-洪萨配资

背景痛点：传统选题系统为什么总“踩坑”

每年毕业季，教务老师最头疼的不是答辩，而是“抢选题”。
旧系统要么 Excel 满天飞，要么 JSP+Servlet 老项目，改一行代码得全量重启；需求临时加“学生可退选”，前端要改、SQL 要改、逻辑要改，动辄通宵。
更惨的是，并发一上来就超卖：A、B 两个学生同时刷到最后一题，数据库只减一次库存，老师只能手工调。
总结下来，低效环节集中在：

需求变更→手写 SQL 重复劳动
无统一 DTO → 字段名写错到上线才发现
无并发控制 → 超选、重复选
无权限模型 → 谁都能看成绩，数据泄露风险高

这次我们用 AI 当“外挂”，把重复劳动交给 Copilot/通义灵码，人只聚焦业务与架构。

技术选型：Spring Boot + MyBatis 为什么最配 AI

生态成熟：Spring Boot 自动装配让“项目骨架”一句话生成，AI 补全业务代码时不会踩版本坑。
注解友好：MyBatis 的@SelectProvider等注解式 SQL 方便 AI 一次性整块生成，再让人 Review，比 JPA 隐式 SQL 更可控。
可插拔：MyBatis-Plus 提供LambdaQueryWrapper，AI 生成链式写法几乎零调试。

AI 辅助效果实测（同一业务模块）：

环节	纯手工	AI 先生成+人工 Review	节省
实体类+DTO	25 min	5 min	80%
CRUD XML	40 min	8 min	80%
单元测试	30 min	7 min	77%

注意：AI 生成后必须静态扫描 + 人工走查，平均仍有 8% 的 NPE 隐患需手动加固。

核心实现细节

1. 选题互选状态机

题目状态只有三种：可选 / 已锁定 / 已确认。
学生点击“申请”→系统先写topic_lock行锁记录，状态=锁定，同时启动定时器（30 min 未支付自动释放）。
老师点击“确认”→事务内把状态改已确认，并写student_topic最终表。
AI 提示词模板：

// 语言：Java // 框架：Spring Boot + MyBatis // 需求：将指定 topicId 锁定给指定 studentId，锁定超时 30 min，返回是否成功 // 要求：使用数据库行锁，防超卖

Copilot 会给出SELECT ... FOR UPDATE骨架，人只需加唯一索引校验。

2. 并发冲突处理

超卖根源是“查库存→业务判断→减库存”三步非原子。
方案：MySQL 乐观锁 + 唯一索引。

在topic表加version字段
更新时WHERE version=#{oldVersion}，返回行数=0 抛OptimisticLockingException
同时给(teacher_id, title)建唯一索引，防止 AI 生成代码漏判重名

AI 会忘记加version，所以提示词一定写“带乐观锁”，否则它默认“先查后改”。

3. 用户角色模型

采用 Spring Security + RBAC，五张表足矣：

user（id, username, password, enabled）
role（id, role_name）
user_role（user_id, role_id）
permission（id, uri, method）
role_permission（role_id, permission_id）

AI 生成UserDetailsService实现类时，一定追加“密码采用 BCrypt 加密”，否则它会明文返回。

关键代码：自动分配服务

场景：老师确认后，若选题人数 > 名额，系统按绩点自动分配。
以下代码保持 Clean Code 原则，AI 先生成，再人工精简。

/** * 自动分配服务：老师确认后，若超额，则按绩点排序截取。 */ @Service @RequiredArgsConstructor public class TopicAllocateService { private final TopicMapper topicMapper; private final StudentTopicMapper stMapper; /** * 老师点击确认时触发，事务内完成。 * @param topicId 题目主键 * @param applyStudentIds 已申请的学生 ID 列表 * @param quota 老师设定的录取名额 */ @Transactional(rollbackFor = Exception.class) public void allocate(Long topicId, List<Long> applyStudentIds, int quota) { if (applyStudentIds.size() <= quota) { // 名额充足，全部录取 insertBatch(topicId, applyStudentIds); return; } // 1. 按绩点倒序取前 quota 名 List<Student> sorted = stMapper.selectByIdsOrderByGpa(applyStudentIds, quota); List<Long> winner = sorted.stream().map(Student::getId).collect(Collectors.toList()); // 2. 写最终表 insertBatch(topicId, winner); // 3. 其余学生释放锁定 applyStudentIds.removeAll(winner); releaseLock(applyStudentIds, topicId); } private void insertBatch(Long topicId, List<Long> studentIds) { if (studentIds.isEmpty()) return; List<StudentTopic> list = studentIds.stream() .map(sid -> StudentTopic.builder().studentId(sid).topicId(topicId).build()) .collect(Collectors.toList()); stMapper.insertBatch(list); } private void releaseLock(List<Long> studentIds, Long topicId) { if (studentIds.isEmpty()) return; topicMapper.batchUnlock(studentIds, topicId); } }

AI 会漏写rollbackFor，提示词一定强调“事务失败必须回滚”。

安全性 & 性能

防刷选题
- 前端限流：同一 studentId 5 秒内只能点一次，用 RedisSETNX EX 5
- 后端兜底：Guava RateLimiter 每秒 10 次，超阈值直接 429
幂等性
- 学生重复提交相同申请 → 唯一索引 (student_id,topic_id,status='锁定') 直接抛DuplicateKeyException，前端提示“已申请”
冷启动优化
- 项目启动时把热点题目列表刷到 Redis，减轻首次查询穿透
- AI 生成的CommandLineRunner代码注意关闭lazy-init，否则缓存加载会晚于第一次请求

生产环境避坑指南

边界校验缺失
AI 常忘判quota<=0，上线后老师手抖填 0，全体学生白屏。务必在 Service 首行Assert.isTrue(quota>0, "名额必须大于 0")
事务传播误配
Copilot 默认@Transactional是REQUIRED，但“释放锁定”方法若内部新事务，会提前解锁。提示词写“释放锁与主事务同生命周期”，或把释放锁逻辑挪到同一方法内
字符集踩坑
MySQL 表 AI 脚本默认utf8，emoji 保存失败。手动改为utf8mb4
分页 SQL 性能
AI 喜欢LIMIT off,size大偏移，深翻页慢。给提示词“用游标分页/延迟游标”，让它生成WHERE id<#{lastId} ORDER BY id DESC LIMIT #{size}

结语：把 AI 模式搬到更多教务场景

整个系统从 0 到上线只花了两个迭代，共 18 人日，比纯手写预估的 45 人日节省一半。
AI 不是替代程序员，而是把“体力活”压缩到分钟级，让人专注状态机、并发与业务规则。
下次面对“实验室预约”“竞赛报名”等相似教务子系统，只要把 RBAC、乐观锁、防刷三板斧模板化，再配合结构化提示词，就能快速复制。
如果你也在做毕业设计，不妨先动手实现“学生锁题→老师确认→自动分配”最小闭环，把 AI 当搭档，你会惊喜地发现，写 Java Web 也能像搭积木一样轻松。