我先拿设备借还这个小场景举例。它看起来不复杂却特别容易把全栈项目里藏着的问题翻出来设备明明显示已借出借还记录却没有借用人归还按钮提示成功刷新后设备还是不能再借。只看一张列表页看不出这些问题所以我得把页面、接口和数据库一起跑一遍。我之所以选设备借还是因为它虽然小却正好能把状态、记录和数据一致性都串起来。一次借出会新建记录并改变设备状态归还时要结束原记录再把设备改回可借。对我来说它很适合检查从需求描述到工程运行之间哪些部分由工具完成哪些地方还得人工接手。这次我按飞算 JavaAI 的全栈流程先看设计文档再生成前后端代码。我从空目录开始走完五步智能引导随后处理了首版编译错误、日期解析和 MySQL 时区问题也对核心借还链路做了回归。下面我只讲这次本地实测不把结果推广到其他项目或生产环境。为了让你看清每一步到底是谁完成的我把版本分成三条线S0 是原始生成版S1/S2 是我人工修复后的本地启动与局部回归版S3 是后来人工补上的账号能力。一、我先把“设备能借能还”说清楚我一开始没有直接写“做一个资产管理后台”因为这个说法太宽最后很容易做成页面很多、验收却没重点的项目。所以我把范围收在设备登记和借还不做采购、折旧、扫码、维修和消息通知。首轮我只按单管理员、本地运行来设计Prompt 里先不塞复杂权限先把设备借还这条主流程跑通再说。为了让你能一眼看清我想做什么我先把功能拆成四块页面 / 模块核心业务职责重点核对的边界设备列表新增设备、按关键字搜索、按状态筛选设备编号是否唯一状态是否与借还动作实时联动设备详情查看设备资料、当前借用人和历史流水同一设备的基础信息与流水记录能否串联借用登记填写借用人、部门、用途与预计归还时间前端表单与后端接口是否完成双重校验借还记录查询未还与已还记录、办理设备归还归还是否准确结算原记录历史流水是否完整保留这里我先把几条不能含糊的规则定下来设备编号必须唯一借出时设备从“可借”变为“借出”同时新增一条未还记录归还时那条记录标为“已还”设备恢复“可借”。预计归还时间不能早于办理借用的时刻实际借出和归还时间由服务端记录。我当时按下面这套状态转换来判断借出成功新增未还记录归还成功原记录标为已还再次借用拒绝且不新增记录设备可借设备借出我特别盯着“同一设备最多只能有一笔未还记录”这条规则。前端把按钮置灰只能减少误点真正兜底的还是后端要拦住重复请求归还也一样第二次点击不能覆盖第一次写入的归还时间。二、我怎样从需求走到设计2.1 本地测试环境与起点实际操作时我先新建了一个没有业务源码的独立目录再从飞算 JavaAI 的“关联项目”模式开始生成这样后面看到的文件变化才都是这次实践产生的。我这次实际使用的软硬件环境如下项目本轮实测记录操作系统、硬件规格macOS、M1 MacBook32GB 统一内存开发工具 (IDE)IntelliJ IDEA 2026.2.3飞算 JavaAI 插件版本 3.9.15后端技术栈JDK 17.0.18Spring Boot 3.2.5Maven 构建工具前端技术栈Node.js 26.3.0Vue 3.4.21Vite 5.4.21npm 11.13.0数据库环境MySQL 8.4基于 Docker Desktop 本地容器命名数据卷持久化数据库youjie工程起点全新空目录生成前没有任何 Java 业务类与前端代码操作者技术背景主修 Java 后端日常以 Spring Boot、MyBatis 为主对 Vue3 与前端工程化仅了解基础调用极少独立编写前端复杂交互图 1IDEA 插件管理页CalEx-JavaAI 3.9.15 处于启用状态。2.2 实际提交的需求描述这里我没有把所有技术实现细节一股脑塞进输入框而是先把业务边界说清楚。智能引导固定经过“理解需求、设计接口、表结构设计、代码生成计划、生成源码”五步每一步出来后我都会先看结果觉得不对就编辑或重新生成再点“下一步”。首轮提交的需求描述如下我想从零做一个给公司行政和 IT 共用的设备借还后台项目叫“有借”。日常要管理笔记本、显示器、投影仪、摄影机这些办公设备先做一个本地能跑起来的 Java Web 项目前后端都要有。前端目录为 frontend后端目录为 backend。 这个系统先只给一位管理员使用不用做登录、权限、多租户、扫码、采购、报废这些功能把设备借还主流程做好就行。首页可以简单显示设备总数、可借数量和借出数量。设备列表要能新增设备按设备编号或名称搜索按“可借”或“借出”筛选。列表里显示编号、名称、分类、存放地点和状态新增时编号、名称、分类和存放地点必填备注可选编号不能重复。 点进设备详情要看到完整资料、现在是否已借出、当前借给谁以及过去每一笔借还记录。借用时从指定设备进入填写借用人、部门、用途和预计归还时间这些内容不能空着预计归还时间不能早于现在。借出成功后设备必须变成“借出”同时生成一条新的借用记录记录要有借出时间。已经借出的设备不能再借给第二个人。 归还时要按原来的借用记录办理归还成功后填入实际归还时间设备改回“可借”。同一条记录不能重复归还重复借用或重复归还时页面要说清楚为什么不行也不能多生成记录或改坏以前的数据。归还后设备可以重新借出新旧记录都要保留。 数据必须真的保存到数据库里关闭再启动项目后设备和借还记录还在不要只做静态页面、假数据或临时内存数据。先放三台可借的测试设备FEI-TEST-001 测试摄影机、FEI-TEST-002 测试投影仪、FEI-TEST-003 测试平板借还记录先为空。只用虚构人员和测试数据。页面做得简洁、好用要有加载、空数据和操作失败时的提示。最后给我前后端代码、数据库初始化方式、接口说明和 README写清楚怎么配置、启动和测试你实际做过哪些检查也请如实告诉我。图 2在“关联项目/子模块”模式中输入首轮“有借”需求。2.3 生成前我确认了什么进入源码生成前我没有急着点下一步而是先替后面的自己确认了三件事设备列表与详情中分页返回格式是否规范借出操作是以设备 ID 为入口还是单据入口“归还”到底归还什么页面和接口都按一条借还记录处理后端接收借还记录 IDrecordId而不是只改设备的status。这样旧流水才能留住。图 3第 1 步“理解需求”界面拆分出 12 个关键点。图 4第 2 步“设计接口”界面展示基于需求生成的 6 个接口方案。图 5第 3 步“表结构设计”界面展示设备表和借还记录表。图 6第 4 步“代码生成计划”计划列表共 27 项。三、代码出来后我先看第一版这里我想先提醒你代码生成完、项目能启动、借还流程能跑其实是三回事。我先保留生成后的第一版再分别处理构建和运行问题避免把修复后的结果说成“一次生成就完成了”。3.1 一次计划停滞和智能路由等待回头按当时的操作过程整理时我记得智能引导走到第四步“代码生成计划”准备进入源码生成界面大约 3 分钟没有出现新日志。这里的“约 3 分钟”没有录屏和逐秒记录只用来说明这次等待的量级。当时我看不出是后台任务忙、连接超时还是别的原因所以先停止任务再重新生成计划这一次恢复正常后续源码也生成完成。这个处理只说明它在当时有效不能当作所有卡顿的通用解法。我在使用“智能路由”时还遇到过一轮回复很慢。界面没有留下实际分配模型、排队状态和完整耗时所以这只是一次使用感受不能直接归为某个模型慢也不能据此判断问题一定出在智能路由。另有一次异常退出后之前的智能引导记录没有恢复因为没有保留异常堆栈和录屏我只能确认“历史无法继续”不能判断触发原因或恢复边界。图 7第 5 步“生成源码”期间工作区列出了已生成文件界面仍显示“思考中”。3.2 首次构建排查S0 到 S1源码落盘后我保留原始版本 S0在backend目录用 JDK 17 执行mvn -DskipTests package。S0 的构建日志报出 5 个编译错误随后我又检查到一个会影响启动的 Mapper 扫描配置问题。它们可归为下面四类接口与实现类方法命名脱节BorrowService声明的是borrow(Long, BorrowRequest)而BorrowServiceImpl中写成了borrowDevice(Long, BorrowRequest)控制器调用错误BorrowController调用了接口中不存在的borrowDevice视图对象缺失字段DeviceServiceImpl中调用了DeviceDetailVO不存在的setCreateBy和setUpdateBy缺失 MyBatis Mapper 扫描配置主启动类与配置类中未声明MapperScan即使编译通过Mapper 也无法注入 Spring 容器。这些都是多文件之间没有对齐好。按当时操作的回忆我用约 4 分钟做了最小修改统一方法名为borrow删掉多余的 VO 调用并补上 Mapper 扫描配置。这个时间不是逐秒记录再次打包通过后才得到首个可启动版本 S1。图 8修复后在 backend 目录执行 Maven 打包终端显示 BUILD SUCCESS。3.3 首次启动冒烟与时区 Bug后端监听 8080Vite 前端监听 5173页面能打开初始化表也已创建。第一次通过页面给FEI-TEST-004办理借用时出现了两个问题日期反序列化异常前端提交的预计归还时间是yyyy-MM-dd HH:mm:ss字符串Spring Boot 默认未配置该格式的LocalDateTime反序列化器导致直接抛出 500 异常。调整全局 Jackson 配置后接口能正常校验并返回标准错误响应8 小时时区偏差测试借出时间为18:46:07归还后数据库写入的归还时间变成了10:46:32整整相差了 8 小时。经排查是本地 Docker 中的 MySQL 容器会话时区为 UTC而 Java 应用运行在 Asia/Shanghai。我调整了日期参数解析和数据库时区配置再用新设备做局部回归得到 S2。版本阶段定位构建/启动状态实测表现与问题说明S0 原始生成版生成完成后的第一现场编译失败后端构建报 5 处编译错误另发现 Mapper 扫描配置缺失无法进入可启动状态S1 启动冒烟版最小编译修复后版本启动成功接口跑通但在真实交互中暴露了日期反序列化 500 和 MySQL 8 小时时区差S2 局部回归版修复时区与参数解析正常运行对 FEI-TEST-005 完成正常借出、归还、重复归还保护、统计与重启后读取的局部回归S3 账号扩展版后续人工二次开发正常运行人工补充登录、Token、管理员建号与角色越权拦截不属于首轮生成范围四、我怎样把页面截图和本地回归分开看我先把这里的素材边界讲清楚免得把两轮测试看成同一条数据图 9 至图 12 记录的是一次页面操作设备编号是FEI-TETS-006TETS就是我当时在截图里填的原始拼写所以本文照原样保留。另一轮 S2 的本地接口和数据库回归用的是FEI-TEST-005。两轮都在本地测试环境里完成但不是同一条记录后面我会分开说。4.1 我在页面上完成的一次新增、借出和归还先带你看图 9 和图 10图 9 只记录了提交前的表单填写图 10 显示设备列表已经出现FEI-TETS-006浏览器 Network 面板中POST /api/devices的业务响应为code0。我只能据此确认这次页面新增请求正常返回不能仅凭这两张图推断数据库落库、重启后的数据或重复操作。图 9新增设备弹窗提交前填写 FEI-TETS-006 等字段。图 10设备列表出现 FEI-TETS-006Network 中 POST /api/devices 的业务响应为 code0。再看图 11 和图 12FEI-TETS-006借出后详情页显示了借用人“张阿梨”、部门“办公室”和一条未归还记录同一张图里的借用请求响应为code0归还后设备恢复可借并保留了已归还历史和实际归还时间。对我来说这两张图只支持一次正常借出和一次正常归还不能延伸成重复借出、重复归还或并发场景的结论。图 11FEI-TETS-006 借出后详情页显示张阿梨的未归还记录Network borrow 响应为 code0。图 12归还后页面显示可借、已归还历史及实际归还时间Network 中有 return 请求。4.2 我另做的一轮 S2 局部回归到了另一轮本地回归时我换用FEI-TEST-005完成了一次借出和归还。页面显示的借出时间是2026-09-17 18:53:32归还时间是2026-09-17 18:53:46我再查当轮 MySQL看到的对应时间和页面一致没有再出现FEI-TEST-004曾暴露的 8 小时时差。为了确认归还后的保护逻辑我在归还完成后又直接向本地后端重复发送了一次归还请求。请求返回业务码40902既有归还时间仍保持为18:53:46没有被覆盖。这只能算一次局部的重复归还保护回归不等同于重复借出、并发抢借或全部异常路径都已验证。4.3 我重启后端后看到的持久化表现接着我保持本地 MySQL 容器运行停止并重启了 Spring Boot 后端再分别通过本地后端接口和 Vite/api代理查询统计和FEI-TEST-005详情。两处都读到5/5/0设备总数 / 可借 / 借出和已有归还记录。所以我只能据此说明这次本地后端进程重启后数据仍从同一个 MySQL 容器中读出来这不是按固定基线完成的完整持久化验收也不是生产备份恢复测试。4.4 我实际核对过什么下面这张表是我实际看过的问题现场和做过的局部回归方便你快速区分“已经看到”与“还没有覆盖”的范围。它不对应测试指南里的 F01—F12也不能替代完整项目验收。编号本轮核对项版本 / 素材结果证据边界L01原始生成版后端构建S0问题现场5 个编译错误修复前无法启动后端L02首次日期时间参数处理S1问题现场后局部修复首次借用返回 HTTP 500修复后格式错误日期返回 HTTP 400、40001L03本地时区表现S1 / S2局部回归有效FEI-TEST-004曾相差 8 小时FEI-TEST-005的页面与 MySQL 对应时间一致L04FEI-TEST-005正常借出和归还S2局部回归有效页面时间为18:53:32、18:53:46状态随操作变化L05FEI-TEST-005重复归还保护S2局部回归有效重复请求返回40902既有归还时间未被覆盖L06统计接口与本地 MySQL 汇总S2已核对接口和数据库汇总均为5/5/0L07后端进程重启后的读取S2已观察重启后后端接口和 Vite 代理仍能读到统计和既有记录L08FEI-TETS-006页面新增、借出、归还图 9—12已观察截图支持各一次页面操作和对应成功响应不延伸为数据库或重复操作结论L09本地账号与角色隔离接口S3独立接口回归有效后续人工补充管理员建号、401/403 边界已核对未做浏览器真实登录提交重复设备编号、搜索筛选、四项非法借用、重复借出、归还后再次借出、浏览器刷新详情、逐字段三方一致性和并发请求均未按固定基线完成本文不把它们写成已验证结果。五、我怎么回顾这 30 分钟从输入需求到完成 S2 的局部业务回归我事后按当时的操作过程回想了一遍墙钟时间大约是30 分钟。我得先把这个数字的边界讲清楚本轮没有录屏也没有为五步智能引导逐项记录开始和结束时间。下表保留的是我对过程的近似拆分用来解释操作顺序和投入位置不能当作精确实验数据也不能据此计算个人开发效率或与传统开发做倍数对比。阶段大致耗时本轮产出或操作环境准备与进入项目约 3 分钟确认本地 Docker MySQL、JDK 和 Node 环境进入飞算 JavaAI 入口第 1 步理解需求约 2 分钟得到设备借还场景的关键点拆分第 2 步设计接口约 2 分钟得到接口方案并核对借还以记录为中心的设计第 3 步表结构设计约 2 分钟查看设备表和借还记录表设计第 4 步代码生成计划约 3 分钟生成 27 项计划其中包含一次约 3 分钟无新日志后的停止与重试第 5 步生成源码约 9 分钟生成前后端目录和首版源码首次构建排查与修复约 4 分钟处理 S0 的方法名、VO 调用和 Mapper 扫描问题启动冒烟与日期/时区修复约 3 分钟暴露并修复日期解析和时区问题局部业务回归与重启读取约 2 分钟核对一次借还、重复归还保护、统计和重启后读取总历时约 30 分钟按完成后的操作回顾整理未逐项录屏计时顺带说一句表中的“约 3 分钟等待”已经包含在第四步内没有作为额外耗时重复相加。因为没有原始起止时间和传统开发对照这些数字只代表我对这次操作的粗略复盘不是可复现实验的效率结论。顺带把活动 Brief 的参考数据和我的结果分开说其中“中等复杂度 CRUD 约 7 天缩短至 1 天”是活动提供的参考不是我的实测结果。这次我能确认的是工具先给出了前后端目录和初版源码编译、日期解析和时区问题仍需要我自己定位和验证。六、我这轮的收获、问题和下次做法对我有帮助的部分对我来说五步引导最有用的地方是先把需求、接口和表结构摊开再去生成前后端目录和初版源码。这样我不用从空目录开始搭基础工程也能在生成前先确认“按借还记录归还”这条规则有没有写清楚。这次暴露的问题不过我也得把踩到的坑讲清楚S0 不能编译S1 又出现了日期解析和时区问题所以我不会把这次过程说成“一次生成即可运行”。代码生成计划有过约 3 分钟没有新日志我用智能路由时也遇到过一次回复偏慢。一次涉及多文件变更的任务里界面还出现过停顿不过我当时没记录文件数、持续时间或日志。异常退出后智能引导历史也没有恢复。因为我没有留下完整故障日志、模型分配信息或录屏这些只能算本次使用观察不能直接归因到某个模型或功能机制。下次我会怎样做下次我还会把飞算 JavaAI 用在搭工程、整理基础页面和辅助设计上但会在每个引导步骤保存截图和起止时间。源码生成后我会先构建再用固定设备逐项核对页面、接口和数据库借还、时间和重复操作这些地方也不会只看页面提示。任务较大时我会按模块拆分生成并在关键节点保留工程快照减少卡顿或异常退出后难以续接的成本。#飞算JavaAI #AI编程 #Java #全栈开发 #前后端分离 #后端开发 #前端开发 #IDEA插件 #程序员 #IDEA开发 #Java开发 #SpringBoot #程序员必备