承渊政道个人主页❄️个人专栏:《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.前三个都冲突,最后一个刚好首尾相接,应该允许.目录常见问题一、先放一段已占用时间,再谈生成速度二、把规则交代成一条需求三、把四个时间段摆上日历四、一次双击,才看到并发窗口核心源码对比:时间区间冲突判断与并发创建飞算JavaAI3.9.1:应用层遍历飞算JavaAI3.9.9:数据库区间查询五、账要拆开算,别只报总耗时六、日历能打开,不等于预约规则过关七、本次评价常见问题Q会议室预约的时间冲突检测难点是什么?A难点在于只判断开始时间是否相等会放过一大批重叠预约.需要检测前包后、后包前和完全包含三种重叠模式,同时允许首尾相接的边界情况.Q飞算JavaAI 3.9.1和3.9.9在时间冲突处理上有何差异?A两版本从同一份空工程开始,使用相同的需求说明和初始数据.3.9.9在预约队列处理效率上有所提升,具体差异以实测计时为准.Q测试用了哪些冲突场景?AA101已占用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.1IntelliJ IDEA2026.2.1飞算 JavaAI3.9.1 与 3.9.9两轮均使用智能路由模式后端Java 17 Spring Boot 4.5Maven 3.9.14前端Vue 3 ViteNode.js 26.3.0构建与缓存Maven 3.9.14两组使用相同缓存状态数据库MySQL 8.4 LTS两轮保持相同服务端时区固定测试数据A1018 人、A10220 人A101 已占用 10:00—11:00对照起点相同的空项目、需求说明、初始数据和冲突用例计时终点正常预约、三种重叠、边界相接及超员用例全部通过3.9.1与3.9.9都从同一份空骨架开始,数据库使用同一批会议室与预约数据.允许使用 IDE 自动补全,但不能复用上一轮生成的冲突检测代码.两轮都必须通过同一套接口测试,不能一轮停在页面可用,另一轮跑到并发校验.预约的状态线不复杂,真正的边界在时间区间 PENDING → CONFIRMED → COMPLETED └─ 开始前取消 → CANCELLED 区间冲突newStartoldEndnewEndoldStart两轮都使用智能路由模式,不切换专家模型.时间判断只挡住一部分重叠时,失败用例与人工修正分别计时,不能算作首轮成功.图 1测试环境二、把规则交代成一条需求这轮只做预约这条线后端保存会议室、预约和签到记录,并在写入时做冲突校验;前端负责查空闲、提交预约和呈现结果.日历上的状态来自同一条后端记录.开发一套独立的会议室预约前后端项目。后端使用 Java Spring Boot 提供 REST API、业务校验和数据持久化前端使用 Vue Vite所有列表、日历和操作都调用后端接口不能使用本地模拟数据代替业务结果。 请先给出实体关系、状态流转、接口清单和实现顺序确认后再生成完整代码。 需要包含会议室管理、空闲时段查询、创建预约、修改预约、取消预约、签到和我的预约。 预约状态为 PENDING → CONFIRMED → COMPLETED开始前取消进入 CANCELLED。每一次状态变化要记录操作时间和操作人。 创建或修改预约时后端必须在写入前校验会议室是否可用、参会人数是否超过容量、结束时间是否晚于开始时间前端查询空闲结果不能代替后端校验。 时间冲突按区间处理newStartoldEndnewEndoldStart。要覆盖前包后、后包前、完全包含和首尾相接四种情况其中首尾相接允许预约。 处理并说明重复提交、两个请求同时抢同一时段、会议开始后取消、超员预约和非法状态流转。失败时返回可读错误不写入无效预约。 前端提供预约日历、会议室列表、我的预约和冲突提示日历状态必须来自接口。补充关键接口测试或单元测试并给出项目启动与联调说明。补充条件统一时间口径数据库保存带时区的时间,页面按本地时区显示;结束时间必须晚于开始时间,单次预约最长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:应用层遍历// 3.9.1 生成实现在应用层内存比对时间区间且未加锁publicbooleancheckConflict(LongroomId,LocalDateTimestart,LocalDateTimeend){// 缺陷1将该房间所有预约全量拉入内存遍历数据量大时性能极差ListMeetingBookingallBookingsbookingMapper.selectByRoomId(roomId);for(MeetingBookingb: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()))){returntrue;// 冲突}}returnfalse;}说明这段代码遗漏了新预约完全包住旧预约的情况,例如 09:00—12:00 覆盖 10:00—11:00;两个请求同时查询时,也可能都得到空闲结果.飞算JavaAI3.9.9:数据库区间查询// 3.9.9 生成实现底层标准区间交叉判定 乐观锁 / 行级排他锁校验Transactional(rollbackForException.class)publicBookingResponseVOcreateBooking(BookingRequestDTOdto){// 1. 基础时间合法性前置拦截结束时间必须大于开始时间if(!dto.getEndTime().isAfter(dto.getStartTime())){thrownewBusinessException(ErrorCode.INVALID_TIME_RANGE,会议结束时间必须晚于开始时间);}// 2. 数据库层面标准区间交叉判定start existing_end AND end existing_start// 自动过滤 CANCELLED 状态且支持“首尾相接”10:00-11:00 与 11:00-12:00 互不冲突intconflictCountbookingMapper.countOverlappingBookings(dto.getRoomId(),dto.getStartTime(),dto.getEndTime(),List.of(BookingStatusEnum.CONFIRMED.getCode(),BookingStatusEnum.PENDING.getCode()));if(conflictCount0){thrownewBusinessException(ErrorCode.TIME_SLOT_CONFLICT,所选时间段已被预约请选择其他时段或会议室);}// 3. 写入前再次校验相同开始时间可用唯一约束防重重叠区间仍需锁或重试策略兜底MeetingBookingbookingMeetingBooking.builder().roomId(dto.getRoomId()).userId(dto.getUserId()).startTime(dto.getStartTime()).endTime(dto.getEndTime()).status(BookingStatusEnum.CONFIRMED.getCode()).createdAt(LocalDateTime.now()).build();bookingMapper.insert(booking);returnBookingResponseVO.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 秒构建成功和冲突检测通过会分开记录.一张绿色构建图不能替代预约用例.验收项首次结果修改后结果正常流程通过创建预约、空间分配、日历状态变更正常通过状态流转完整重复请求需加固并发快速双击产生同时间重复预约通过补齐 roomIdstartTime 防重约束非法状态或边界输入通过结束早于开始、跨夜超长预约均被拦截通过返回明确业务错误提示录屏时让计时器和 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秒.不足首尾相接的边界需要把 调整为严格小于;高并发抢同一时段时,仍需补充锁、数据库约束或重试方案.建议智能路由适合先完成预约流程和界面;上线前必须保留重叠、首尾相接、容量和并发创建的接口用例.真正的勇者不是流泪的人,而是含泪奔跑的人!敬请期待下一篇文章内容每日心灵鸡汤: 靠自己,才是最大的底气!不是你摔倒了就会有人扶,不是你困难了就会有人帮,不是你委屈了就会有人关心;路要自己走,苦要自己吃,事要自己扛,不要总把希望寄托在别人身上,你要努力让自己变得足够强大.