4 条巡检，10 条正常，14 条异常，闭环率 64.3%。
这是“尺鉴”巡检后台运行截图上的一组数字。页面有了，数据也已经存进数据库，我接着想确认：64.3% 的分母是什么？处理一条异常后，哪些数字应该变？点进门店，列表里的记录能不能和排行对上？
这次我在 IntelliJ IDEA 中使用飞算 JavaAI 的智能引导，做了一套门店巡检后台，再围绕生成后的工程补上登录、角色权限和测试。下面按实际操作过程、运行截图和代码，复盘这套 Spring Boot + Vue 项目。
整套系统跑在本地 H2 文件库上，截图里的数字都来自接口查询和聚合，不是我手动填进去的。另外要先说清楚：文中的 24 条只是截图那一刻的数据状态，后面我再新增或核销记录，页面数字也会跟着变。
一、给 AI 的需求里，我先写清楚怎么算数
巡检业务不复杂：登记结果，发现问题，整改复核，再看统计。但“异常数量”很容易产生歧义：已经整改的记录，还算不算发生过异常？我在输入需求时先把这些规则说清楚。
在 IDEA 的飞算 JavaAI 面板中选择“创建项目”，使用“Java Web 工程（新版）”入口和智能路由，提交的需求节选如下：
我想做一个门店巡检后台，项目叫“尺鉴”。先做一个本地能跑起来的 Java Web 项目，前后端都要有。前端目录为 frontend，后端目录为 backend。先给一位管理员使用，不做登录、权限、外部平台对接和复杂整改审批，把巡检录入、列表、详情和统计看板做好就行。
……异常记录先处于待整改状态，处理时要填写整改措施和复核人，由后端记录复核时间，然后改为已处理。只有待整改的异常记录才能处理，正常记录不能走整改流程，已经处理过的记录不能重复处理。原来的问题信息和整改记录都要保留，不能为了减少待整改数量直接删掉记录。
看板显示巡检总数、正常数、异常总数、待整改数和已处理数，再用简单图表展示问题分类和各门店的异常数量。每条巡检记录算一次巡检，异常总数包含待整改和已处理，闭环率等于已处理数除以异常总数；没有异常时显示“—”。看板和列表使用同一组门店、巡检日期筛选条件，起止日期都包含在内，已处理记录仍按原巡检日期统计。数字必须由后端根据数据库计算，并能查看对应明细；处理一条异常后，待整改减一、已处理加一，巡检总数和异常总数不变。
这里我把首轮范围定为单管理员使用。登录和权限是在后续完善工程时加入的。这样回看结果时，就能分清原始需求和后来增加的功能。
二、五步智能引导，把需求拆成工程任务
提交需求后，插件按“理解需求 → 设计接口 → 表结构设计 → 代码生成计划 → 生成源码”五步推进，每一步都要人工确认后才继续。
阶段 1：理解需求。插件把需求整理成 16 个关键点，支持逐项调整。明细回查、参数校验、加载与失败提示被拆成独立条目，还列出了统一响应与异常处理。截图中已经明确要求统计与列表共用门店、日期条件，后续验收可以直接拿这些条目逐项检查。
阶段 2：设计接口。页面列出 6 个接口方案，覆盖巡检登记、记录查询、异常整改、基础数据、统计看板和数据初始化。这是按业务能力组织的方案，最终 HTTP 接口清单见下一节。
阶段 3：表结构设计。这一阶段设计了 4 张表：门店表、分类表、风险等级表和巡检记录表t_inspection_record。可以在界面中查看字段，也可以打开完整 SQL 脚本。
阶段 4：代码生成计划。插件列出 17 个任务项，包含后端 Maven 工程、数据库初始化脚本、前端 Vite 工程和各业务接口。我在这一步可以看到接下来要创建哪些文件、实现哪些功能。
阶段 5：生成源码。确认计划后，插件进入执行阶段。下图记录的是生成进行中：它正在检查工作目录，并准备初始化后端工程。图中文字还说明，生成时会优先采用用户规则中的 Spring Boot 3.x + JPA 配置。
这里我要如实交代：五步下来，我只留下了每一步的产出——关键点清单、接口方案、建表草案、任务清单和生成出来的工程，没有做逐秒计时。所以下文不会出现“生成花了 X 分钟”这种数字，所有结论都只针对生成结果本身。
最终工程分为backend和frontend两个目录，我又在这个骨架上补了认证、权限和测试。设计阶段的表名、接口路径和技术选型，与这个运行版本存在差异：例如巡检表最终使用inspection_task，接口集中在/api/inspections。下面按实际运行版本介绍。
三、运行起来之后，这套后台有哪些东西
那么生成出来的工程实际长什么样？先看技术栈：
- 后端：Spring Boot 3.3.4 + Spring Data JPA + Spring Security + Bean Validation + springdoc 2.6.0，Java 编译目标 17；依赖里带 H2、MySQL 驱动和 Flyway 迁移，本地跑的是 H2 文件库。
- 前端：Vue 3 + Vite 6 + TypeScript 5.7 + Tailwind CSS 3.4 + axios，主要页面集中在
App.vue，接口调用封装在api/index.ts，另有类型定义和初始化数据模块。 - 图表：分类占比用进度条实现，门店排行用列表实现，没有引入 ECharts。
我数了一下最终留在仓库里的表：两张，迁移脚本也分别配套：
V1__create_inspection_task.sql→inspection_task：task_no（唯一）、store_name、inspector_name、inspect_date、status、issue_category、severity、issue_detail、fix_measures、resolved_by、resolved_at、created_at、version（乐观锁）V2__create_system_user.sql→sys_user：username（唯一）、password_hash、display_name、department、role、enabled、审计时间戳
门店名称和隐患分类直接保存在巡检表字段中。当前版本没有独立的门店档案管理模块。本地 profile 由 JPA 管理表结构，Flyway 在生产 profile 中启用；本地启动成功并不等于 MySQL 迁移已经验证。
主要接口如下：
| 方法 | 路径 | 说明 |
|---|---|---|
| POST | /api/inspections | 登记巡检记录 |
| GET | /api/inspections | 分页 + 门店 / 状态 / 分类 / 起止日期条件查询 |
| POST | /api/inspections/{id}/resolve | 异常整改闭环核销 |
| GET | /api/inspections/dashboard | 全库统计看板，不接收筛选参数 |
| GET | /api/auth/me | 当前登录身份 |
运行界面是左侧导航 + 右侧内容区：
- 顶部：5 张指标卡——全网巡检总批次、正常合格巡检、累计发现异常、待整改异常工单、整改闭环率；
- 中部：隐患类型分类占比分布 + 高频异常门店排行；
- 底部：巡检流水台账。
登记和核销都通过弹窗完成，点击分类或门店可以联动台账筛选。不过，筛选入口已经接上，不代表排行和列表的统计范围就完全一致，这一点后面单独分析。
四、24 条巡检，为什么闭环率是 64.3%
先看系统跑起来的实际画面，我把截图上的数字逐个抄了下来：
截图时，数据库中的巡检记录对应下面这组数值：
| 指标 | 数值 | 核对方式 |
|---|---|---|
| 巡检总数 | 24 | 正常 10 + 异常 14 |
| 正常巡检 | 10 | 状态为NORMAL |
| 累计异常 | 14 | 待整改 5 + 已处理 9 |
| 待整改 | 5 | 状态为ABNORMAL |
| 已处理 | 9 | 状态为RESOLVED |
| 闭环率 | 64.3% | 9 ÷ 14 × 100%，保留一位小数 |
分类区我也顺手加总了一遍：消防安全 4、卫生合规 4、陈列违规 3、收银防损 3，合计 14 条，正好等于异常总数；占比约 29% / 29% / 21% / 21%。这组分类统计包含已经整改的异常——整改完成并不会抹掉问题曾经发生的事实。
那么这些数字在后端是怎么算出来的？我把InspectionServiceImpl#getDashboardStats的实现原样贴出来：
@Override@Transactional(readOnly=true)publicDashboardStatsVogetDashboardStats(){longtotal=taskRepository.count();longnormal=taskRepository.countByStatus(InspectionStatus.NORMAL);longabnormal=taskRepository.countByStatus(InspectionStatus.ABNORMAL);longresolved=taskRepository.countByStatus(InspectionStatus.RESOLVED);longtotalIssues=abnormal+resolved;DashboardStatsVovo=newDashboardStatsVo();vo.setTotalTasks(total);vo.setNormalTasks(normal);vo.setAbnormalTasks(abnormal);vo.setResolvedTasks(resolved);vo.setResolutionRate(totalIssues==0?null:Math.round((resolved*1000.0/totalIssues))/10.0);vo.setCategoryStats(taskRepository.countByCategory().stream().map(item->newCategoryStatItem(item.getCategory(),item.getCount())).toList());vo.setStoreIssueRanking(taskRepository.countIssuesByStore(List.of(InspectionStatus.ABNORMAL,InspectionStatus.RESOLVED)).stream().map(item->newStoreIssueRankingItem(item.getStore(),item.getCount())).toList());returnvo;}这段代码里有三处值得停下来核对的地方：
- 一次聚合一次查询，没有前端累加。一次看板请求执行 4 次计数查询和 2 次分组查询，数据来自数据库全量记录；前端只把待整改数与已处理数相加展示累计异常、用后端返回的分类计数算占比，没有拿当前分页列表的明细数组去累加全局统计。
- 闭环率的分母是所有异常，包含待整改和已处理。按截图数值推算：如果接下来只核销一条待整改记录，总数仍应为24，异常仍为14，待整改 5 → 4，已处理 9 → 10，这一比例应变为71.4%——这是由当前口径推导出的验收值。换句话说，点核销之前我就知道屏幕上该跳出什么数；对不上，才是真有问题。
- 没有异常时，后端返回
null，前端显示“—”。这条分支在后端测试中有断言；它与“有异常但尚未处理”的 0% 是两种状态。
录入弹窗中，门店、督导巡检人、日期和结果是基础字段。下面这张图保留的是选择“正常合格”时的表单状态：
选择异常后，代码会展开分类、风险等级和现场详情字段，后端也会检查这些信息是否完整。正常记录则不保存异常字段。
核销弹窗会带出原工单、门店和隐患描述，要求填写整改措施。截图中的复核人为当前登录的系统管理员，姓名不可在弹窗中修改。
这个弹窗对应提交前的操作状态。服务端实际处理时，还会检查工单是否处于待整改状态、登录人是否有核销权限，再写入复核人和复核时间；相关测试结果放在第七节。
五、点进明细，才发现还有一处口径没对齐
全库统计可以算清楚了，那么点进明细之后呢？我又把查询条件逐项核对了一遍，当前版本的实现情况如下：
| 检查项 | 当前实现 | 核对结果 |
|---|---|---|
| 总数、异常数和闭环率 | 后端聚合，异常包含待整改与已处理 | 截图为 24 / 14 / 64.3%，计算关系一致 |
| 异常为零时的闭环率 | 后端返回null，前端显示“—” | 后端测试覆盖空分母 |
| 异常证据与状态流转 | 校验分类、等级和详情，仅允许待整改记录核销 | 测试覆盖详情为空及重复核销拒绝 |
| 日期不晚于当天 | DTO 使用@PastOrPresent，接口启用校验 | 已有校验实现 |
| 复核身份与时间 | 后续加入身份绑定，服务端记录时间 | 测试覆盖身份覆盖与越权拒绝 |
| 看板随列表筛选变化 | 看板无参数，始终统计全库 | 尚未联动 |
| 门店、状态、分类与日期筛选 | 前三项有前端入口，日期范围仅后端支持 | 页面尚无日期范围控件 |
| 分页及完整详情 | 接口支持分页，页面固定每页 20 条；信息展示在台账中 | 尚无翻页控件和独立详情页 |
| 分类与门店下钻 | 点击后改变列表筛选条件 | 门店排行与列表的状态范围不同 |
| 数据初始化 | 原需求为 4 条，当前截图和初始化实现为 24 条 | 当前已经有持久化记录 |
门店下钻的问题，我是被一个例子点醒的。第一反应是列表算错了——把两边的统计范围摆在一起才发现，根本不是同一个口径。“上海静安寺概念店”在初始化数据里有 3 条记录：
- 排行口径：只计异常（1 条待整改 + 1 条已处理）→ 显示2 次；
- 列表口径：点击门店只把门店名称传给查询 → 正常记录也会被查出来，列表总数应为3 条。
说白了，这两个数字不是同一个分母，不能直接拿列表总数与异常排行去比。已有的状态、分类条件还会继续保留，叠加后进一步缩小列表范围。那么要实现“点一下就能核对”，门店下钻就需要同时限定待整改和已处理两类记录，并明确其他条件如何保留或重置。
另一个问题就更直接了：看板没有跟随门店、日期筛选变化。需求拆解阶段已经识别了这项要求，最终接口却仍是无参的全局统计。这里能确认的是设计与实现之间存在遗漏，验收时仍需把筛选条件和预期数值落到具体用例上。
六、核销人是谁，这件事不能只靠表单
首轮需求允许人工填写复核人，这就留下了一个口子：页面上填谁，记录里就写谁。所以后来完善工程的时候，我加入了 Spring Security，把核销权限和复核人一起绑到登录身份上。
当前/api/**使用 HTTP Basic 认证，用户信息从sys_user读取，密码以 BCrypt 哈希存储。督导员INSPECTOR可以录入、查询；整改核销要求AUDITOR或ADMIN角色，越权请求返回 403。
核销时的赋值在服务端完成：
task.setStatus(InspectionStatus.RESOLVED);task.setFixMeasures(dto.getFixMeasures().trim());task.setResolvedBy(currentUser.displayName());task.setResolvedAt(LocalDateTime.now());请求体里虽然仍有resolvedBy，最终写入的是当前登录人的姓名。截图里的“不可篡改”，具体对应这一项字段限制——不能据此推导出整套数据库具备防篡改审计能力。
把工程继续用于正式环境前，还有几项具体工作：
- 默认管理员口令：初始化只在用户表为空时执行，首次启动应设置
APP_ADMIN_INITIAL_PASSWORD，避免回落到固定默认口令；已有账号不会因修改变量而改密，当前也没有改密页面或接口。 - 凭据保管：前端把 Basic 认证凭据存在
sessionStorage，Base64 编码不等于加密；正式接入需要配置 HTTPS，并完善凭据管理。 - 演示数据入口：后端初始化器在非
test环境、记录少于 20 条时会追加 24 条数据，前端在空结果时也会自动写入初始化数据——正式环境需要隔离这两个入口，避免既有业务记录混入。 - 容器健康检查：Docker 健康检查目前请求
/swagger-ui.html，而生产 profile 关闭了 Swagger，应改为专用健康端点；Flyway 迁移、MySQL 配置和 Dockerfile 已有代码，本次验证仍限于本地 H2 环境。
七、10 个测试通过，具体覆盖了什么
工程完善后，我在本地执行了后端测试。在项目根目录运行：
cdbackend mvn-Bcleantest结果：
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 -- InspectionServiceIntegrationTests [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 -- AuthAndSecurityIntegrationTests [INFO] Results: [INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0 [INFO] BUILD SUCCESS也就是说：10 个用例、0 失败、0 错误，构建成功。具体组成如下：
InspectionServiceIntegrationTests（4 个）：编号派生与正常记录不含异常字段、异常详情为空时拒绝创建及重复核销拒绝、督导员无权核销、数据库统计及空分母。其中统计用例创建了 1 条正常和 1 条异常记录，核销前断言总数为 2、正常为 1、待整改为 1、已处理为 0；核销后断言待整改为 0、已处理为 1，该比例落到 100%。AuthAndSecurityIntegrationTests（6 个）：未认证 401、错误口令 401、督导员与复核员各自可取到身份、督导员核销 403、复核员核销成功且resolvedBy被绑定为登录人姓名。
测试数据与截图中的 24 条记录是不同的数据集。空库时闭环率为null，新增一条异常后为 0%，核销后为 100%，这是测试覆盖的变化过程。
本次 Maven 报告的运行时为 JDK 25.0.2，pom.xml的 Java 编译目标为 17。打包后得到inspect-pulse-1.0.0.jar。认证与权限用例通过 MockMvc 执行；这 10 个后端测试不覆盖浏览器点击下钻、日期筛选或分页交互。
实体已经配置@Version，异常处理器也将乐观锁冲突映射为 HTTP 409，但目前没有针对并发冲突的自动化用例或压测结果。
八、这次用下来，我会怎么用飞算 JavaAI
这次让我觉得有用的，是智能引导把一段巡检需求拆成了可以逐项检查的需求、接口、表结构和生成任务。后续拿到工程，我能沿着这条路径找到接口、统计逻辑和状态校验，再补上认证与测试。
运行截图中的 24 条巡检已经进入数据库，正常、异常、待整改和已处理之间的数量关系可以按公式核对；后端测试也覆盖了部分关键业务规则。接下来要继续处理的，是门店下钻、筛选联动、翻页和初始化数据隔离。这些问题会直接影响使用者对看板数字的理解。
对我这样的 Java 后端来说，这次跑下来最实在的收获，是一条做内部工具的路径：用飞算 JavaAI 推进前后端工程，再把精力放到统计范围、业务约束和验收上。本次没有做传统开发与 AI 开发的计时对照，生成各阶段也没有逐秒计时，更没有进行 MySQL、容器或生产环境验证，所以评价就落在这套本地工程的实际结果上。
下次再做类似看板，我会给每个数字都配一个验收动作：选中某家门店，预期返回哪些记录；核销其中一条，预期哪些计数改变。页面生成出来之后，这些动作才是我判断能否交付的依据。
#飞算JavaAI #AI编程 #Java #全栈开发 #前后端分离 #后端开发 #前端开发 #IDEA插件 #程序员 #IDEA开发 #Java开发 #SpringBoot #程序员必备
