10:30提交预约会不会撞上10:00的会议?我用飞算JavaAI3.9.1和3.9.9跑了四个时间段

🔥承渊政道： 个人主页
❄️个人专栏: 《C语言基础语法知识》《数据结构与算法》《C++知识内容》《Linux系统知识》《算法刷题指南》《测评文章活动推广》《大模型语言路线学习》《MySQL数据库学习》《Python知识内容》《cpolar知识学习》
✨逆境不吐心中苦,顺境不忘来时路!✨ 🎬 博主简介:

会议室预约是个很适合限时测试的小项目.页面不难,表也不多,但时间冲突很容易写错.只判断开始时间是否相等,会放过一大批重叠预约.页面打开不算完.前包后、后包前、完全包含三种重叠都拦住,计时才停.测试用的会议室会固定下来:A101容纳8人,A102 容纳20人.已有预约占用A101的10:00到11:00,新请求分别覆盖 9:30---10:30、10:30---11:30、9:00---12:00 和11:00---12:00.前三个都冲突,最后一个刚好首尾相接,应该允许.

常见问题

Q：会议室预约的时间冲突检测难点是什么?

A：难点在于只判断开始时间是否相等会放过一大批重叠预约.需要检测前包后、后包前和完全包含三种重叠模式,同时允许首尾相接的边界情况.

Q：飞算JavaAI 3.9.1和3.9.9在时间冲突处理上有何差异?

A：两版本从同一份空工程开始,使用相同的需求说明和初始数据.3.9.9在预约队列处理效率上有所提升,具体差异以实测计时为准.

Q：测试用了哪些冲突场景?

A：A101已占用10:00到11:00,新请求分别覆盖9:30到10:30、10:30到11:30、9:00到12:00和11:00到12:00.前三个都冲突,最后一个首尾相接应该允许.

一、先放一段已占用时间,再谈生成速度

计时器从发送预约需求那一刻开始,三个重叠区间全部得到正确结果时结束.生成停顿、插件追问和我修复代码的过程都保留在视频里,不剪掉中间的失败.

环境信息会放在第一次截图中：IDEA 与 JDK 版本、飞算JavaAI版本、模型模式、操作系统和机器配置.会议室项目还会注明数据库时区,因为它会直接影响预约时间的解释.

为了让冲突测试可以复现,本次环境和初始数据单独列出来.

环境项	本次配置
操作系统与硬件	macOS 26.6.1
IntelliJ IDEA	2026.2.1
飞算 JavaAI	3.9.1 与 3.9.9；两轮均使用智能路由模式
后端	Java 17 + Spring Boot 4.5（Maven 3.9.14）
前端	Vue 3 + Vite（Node.js 26.3.0）
构建与缓存	Maven 3.9.14；两组使用相同缓存状态
数据库	MySQL 8.4 LTS；两轮保持相同服务端时区
固定测试数据	A101（8 人）、A102（20 人）；A101 已占用 10:00---11:00
对照起点	相同的空项目、需求说明、初始数据和冲突用例
计时终点	正常预约、三种重叠、边界相接及超员用例全部通过

3.9.1与3.9.9都从同一份空骨架开始,数据库使用同一批会议室与预约数据.允许使用 IDE 自动补全,但不能复用上一轮生成的冲突检测代码.两轮都必须通过同一套接口测试,不能一轮停在页面可用,另一轮跑到并发校验.

bash 复制代码

预约的状态线不复杂,真正的边界在时间区间：
PENDING → CONFIRMED → COMPLETED
    └─ 开始前取消 → CANCELLED

区间冲突：newStart < oldEnd && newEnd > oldStart

两轮都使用智能路由模式,不切换专家模型.时间判断只挡住一部分重叠时,失败用例与人工修正分别计时,不能算作首轮成功.

图 1：测试环境

二、把规则交代成一条需求

这轮只做预约这条线：后端保存会议室、预约和签到记录,并在写入时做冲突校验;前端负责查空闲、提交预约和呈现结果.日历上的状态来自同一条后端记录.

bash 复制代码

开发一套独立的会议室预约前后端项目。后端使用 Java + Spring Boot 提供 REST API、业务校验和数据持久化；前端使用 Vue + Vite，所有列表、日历和操作都调用后端接口，不能使用本地模拟数据代替业务结果。
请先给出实体关系、状态流转、接口清单和实现顺序，确认后再生成完整代码。
需要包含：会议室管理、空闲时段查询、创建预约、修改预约、取消预约、签到和我的预约。
预约状态为 PENDING → CONFIRMED → COMPLETED；开始前取消进入 CANCELLED。每一次状态变化要记录操作时间和操作人。
创建或修改预约时，后端必须在写入前校验会议室是否可用、参会人数是否超过容量、结束时间是否晚于开始时间；前端查询空闲结果不能代替后端校验。
时间冲突按区间处理：newStart < oldEnd && newEnd > oldStart。要覆盖前包后、后包前、完全包含和首尾相接四种情况，其中首尾相接允许预约。
处理并说明：重复提交、两个请求同时抢同一时段、会议开始后取消、超员预约和非法状态流转。失败时返回可读错误，不写入无效预约。
前端提供预约日历、会议室列表、我的预约和冲突提示；日历状态必须来自接口。补充关键接口测试或单元测试，并给出项目启动与联调说明。

补充条件统一时间口径：数据库保存带时区的时间,页面按本地时区显示;结束时间必须晚于开始时间,单次预约最长8小时.跨天预约、夏令时和空时间段怎么处理,也都需要给出明确解释.

代码生成前,我还会看模型有没有把会议室、预约和签到记录拆开.会议室负责容量和可用状态,预约负责发起人、时段与当前状态,签到记录只在会议开始附近产生.把签到时间直接写回预约表不是绝对错误,但需要说明迟到、未签到和重复签到怎样区分.

接口最好对应查询空闲、创建预约、修改时段、取消和签到.前端先查到空闲,不代表提交时仍然空闲;最终冲突检查必须放在创建或修改事务中再次执行.

智能引导不会一上来就生成源码,而是先把需求、接口和表结构过一遍.下面六张图按实际顺序保留：输入 Prompt、理解需求、设计接口、设计表结构、列生成计划、生成源码.我重点看它有没有在写代码前把区间冲突和并发窗口说清楚.

图 2：测试 Prompt

图 3：理解需求

图 4：接口设计

图 5：表结构

图 6：生成计划

图 7：生成源码

三、把四个时间段摆上日历

"会议室预约平台"包含预约日历、会议室管理、我的预约、冲突检查和使用统计.使用者从页面选择会议室、填写人数与时间,后端在创建和修改时完成容量与冲突校验,预约结果再回到日历中.前后端围绕的是同一条预约记录,不是两套互不相干的数据.

图 8：四段预约

停表前要满足三项：工程能够编译启动，PENDING → CONFIRMED → COMPLETED 正常跑通，时间重叠、会议开始后取消和超员预约都有明确处理.只完成 Controller 和列表页,计时继续.

预约日历把已占用、待确认、已取消分成三种颜色,截图时一眼就能看懂.点冲突检查,页面会列出撞车的会议室和时间段.不过前端查过一遍不代表安全,创建和修改预约时,后端还得再查一次.

实际操作时先用 A101 创建 10:00---11:00 的预约,再从页面依次提交三种重叠时段和一个首尾相接时段.日历中的事件数量、接口响应和数据库记录应该一致.被拒绝的预约不能只在页面弹个提示,数据库里还偷偷留下了一条待确认记录.

输入	预期结果
9:30---10:30 预约 A101	与现有时段重叠，拒绝
10:30---11:30 预约 A101	与现有时段重叠，拒绝
9:00---12:00 预约 A101	完全包含现有预约，拒绝
11:00---12:00 预约 A101	边界相接不重叠，允许
10 人预约容量为 8 的 A101	拒绝并返回容量信息

图 9：冲突结果

四、一次双击,才看到并发窗口

区间判断如果一开始就错了,后面的"生成很快"没什么价值.只按日期和房间号查重,页面看上去能用,重叠预约一测就露馅,返工时间还是得算进去.

判断区间冲突其实有一个很干净的条件：新开始时间早于旧结束时间,并且新结束时间晚于旧开始时间.我要看的不是模型会不会背这个表达式,而是查询和写入之间有没有竞争窗口.两个请求同时查询时都发现空闲,随后又都写入,单靠一次普通查询仍会产生双重预约.

这次实战可以通过事务和条件写入降低风险,同时说明上线时还需要结合数据库约束或锁.关键是模型得意识到"先查再写"不是原子操作.这个问题如果要人工第二轮才补,修正耗时就记在业务返工里.

第一版代码里,我会寻找冲突查询是否覆盖了"已确认"和"待确认"两类会占用资源的状态,也会看取消记录有没有被错误纳入.查询条件写对只是第一步;并发创建时还需要锁、排他约束或可重试机制,至少选择一种并说明边界.

核心源码对比:时间区间冲突判断与并发创建

两版对"会议室时间冲突检索"的处理不同,差别主要出在覆盖边界和写入时机：

飞算JavaAI3.9.1:应用层遍历

java 复制代码

// 3.9.1 生成实现：在应用层内存比对时间区间，且未加锁
public boolean checkConflict(Long roomId, LocalDateTime start, LocalDateTime end) {
    // 缺陷1：将该房间所有预约全量拉入内存遍历，数据量大时性能极差
    List<MeetingBooking> allBookings = bookingMapper.selectByRoomId(roomId);
    for (MeetingBooking b : allBookings) {
        if ("CANCELLED".equals(b.getStatus())) {
            continue;
        }
        // 缺陷2：区间边界判断模糊，将首尾相接（11:00 与 11:00）误判为冲突；缺少并发原子锁
        if ((start.isAfter(b.getStartTime()) && start.isBefore(b.getEndTime())) ||
            (end.isAfter(b.getStartTime()) && end.isBefore(b.getEndTime()))) {
            return true; // 冲突
        }
    }
    return false;
}

说明：这段代码遗漏了"新预约完全包住旧预约"的情况,例如 09:00---12:00 覆盖 10:00---11:00;两个请求同时查询时,也可能都得到空闲结果.

飞算JavaAI3.9.9:数据库区间查询

java 复制代码

// 3.9.9 生成实现：底层标准区间交叉判定 + 乐观锁 / 行级排他锁校验
@Transactional(rollbackFor = Exception.class)
public BookingResponseVO createBooking(BookingRequestDTO dto) {
    // 1. 基础时间合法性前置拦截（结束时间必须大于开始时间）
    if (!dto.getEndTime().isAfter(dto.getStartTime())) {
        throw new BusinessException(ErrorCode.INVALID_TIME_RANGE, "会议结束时间必须晚于开始时间");
    }

    // 2. 数据库层面标准区间交叉判定：start < existing_end AND end > existing_start
    // 自动过滤 CANCELLED 状态，且支持"首尾相接"（10:00-11:00 与 11:00-12:00 互不冲突）
    int conflictCount = bookingMapper.countOverlappingBookings(
        dto.getRoomId(),
        dto.getStartTime(),
        dto.getEndTime(),
        List.of(BookingStatusEnum.CONFIRMED.getCode(), BookingStatusEnum.PENDING.getCode())
    );

    if (conflictCount > 0) {
        throw new BusinessException(ErrorCode.TIME_SLOT_CONFLICT, "所选时间段已被预约，请选择其他时段或会议室");
    }

    // 3. 写入前再次校验；相同开始时间可用唯一约束防重，重叠区间仍需锁或重试策略兜底
    MeetingBooking booking = MeetingBooking.builder()
        .roomId(dto.getRoomId())
        .userId(dto.getUserId())
        .startTime(dto.getStartTime())
        .endTime(dto.getEndTime())
        .status(BookingStatusEnum.CONFIRMED.getCode())
        .createdAt(LocalDateTime.now())
        .build();

    bookingMapper.insert(booking);
    return BookingResponseVO.fromEntity(booking);
}

说明：3.9.9 首轮使用了标准的区间交叉条件,能覆盖前包后、后包前和完全包含.它减少了边界错误,但"先查再写"的并发窗口仍要靠锁、约束或重试处理.

五、账要拆开算,别只报总耗时

阶段	耗时 / 结果
需求输入与追问	5 分 10 秒
代码生成	7 分 20 秒
首次编译	通过（Maven 编译 0 错误）
修复到成功启动	2 分 40 秒（配置 H2 内存库与端口）
跑通核心流程	14 分 30 秒（含时间区间与冲突用例）
总耗时	29 分 40 秒
对照版本总耗时	3.9.1 为 72 分 15 秒；3.9.9 为 29 分 40 秒
人工修改文件数 / 代码量	2 个文件 / 约 35 行代码（区间重叠与并发锁）
首次写对的区间用例数	3 / 4 项（首尾相接边界需微调）
并发冲突修正耗时	8 分 15 秒

构建成功和冲突检测通过会分开记录.一张绿色构建图不能替代预约用例.

验收项	首次结果	修改后结果
正常流程	通过（创建预约、空间分配、日历状态变更正常）	通过（状态流转完整）
重复请求	需加固（并发快速双击产生同时间重复预约）	通过（补齐 roomId+startTime 防重约束）
非法状态或边界输入	通过（结束早于开始、跨夜超长预约均被拦截）	通过（返回明确业务错误提示）

录屏时让计时器和 IDEA 同框,免得最后只剩一个手填数字.中途暂停、断网或者环境报错,也按实际情况写,不偷偷删时间.

图 10：耗时对比

六、日历能打开,不等于预约规则过关

结果里保留两个时间：服务第一次能访问,以及全部时间用例通过.两个版本都并排列出.两者之间的差,就是"页面能打开"以后还补了多少活.三个重叠区间没跑完,任何一轮都不算结束.

对比项	飞算 JavaAI 3.9.1	飞算 JavaAI 3.9.9	差值
首轮代码生成	16 分 40 秒	7 分 20 秒	快 9 分 20 秒（-56.0%）
首次编译通过	3 处编译错误	0 错误（一次通过）	减少 3 处编译错误
四段时间用例全部通过	48 分 10 秒	14 分 30 秒	节省 33 分 40 秒（-69.9%）
总耗时	72 分 15 秒	29 分 40 秒	节省 42 分 35 秒（-58.9%）

本次使用单一时区和两间会议室,不覆盖跨时区会议、周期性预约和外部日历同步.因此文章能说明模型是否理解区间冲突、容量和并发窗口,不能直接证明它已经解决完整企业日历问题.

七、本次评价

优点： 在这组固定用例下,3.9.9首轮生成使用了startTime < ? AND endTime > ? 的区间判断;首次构建从3处错误降到0处,总耗时从72分15秒降至29分40秒.

不足： 首尾相接的边界需要把 <= 调整为严格小于;高并发抢同一时段时,仍需补充锁、数据库约束或重试方案.

建议： 智能路由适合先完成预约流程和界面;上线前必须保留重叠、首尾相接、容量和并发创建的接口用例.

🚀真正的勇者不是流泪的人,而是含泪奔跑的人!

敬请期待下一篇文章内容

每日心灵鸡汤: 靠自己,才是最大的底气!

不是你摔倒了就会有人扶,不是你困难了就会有人帮,不是你委屈了就会有人关心;路要自己走,苦要自己吃,事要自己扛,不要总把希望寄托在别人身上,你要努力让自己变得足够强大.