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.0Java 编译目标 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_tasktask_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_userusername唯一、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的实现原样贴出来OverrideTransactional(readOnlytrue)publicDashboardStatsVogetDashboardStats(){longtotaltaskRepository.count();longnormaltaskRepository.countByStatus(InspectionStatus.NORMAL);longabnormaltaskRepository.countByStatus(InspectionStatus.ABNORMAL);longresolvedtaskRepository.countByStatus(InspectionStatus.RESOLVED);longtotalIssuesabnormalresolved;DashboardStatsVovonewDashboardStatsVo();vo.setTotalTasks(total);vo.setNormalTasks(normal);vo.setAbnormalTasks(abnormal);vo.setResolvedTasks(resolved);vo.setResolutionRate(totalIssues0?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 认证凭据存在sessionStorageBase64 编码不等于加密正式接入需要配置 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 错误构建成功。具体组成如下InspectionServiceIntegrationTests4 个编号派生与正常记录不含异常字段、异常详情为空时拒绝创建及重复核销拒绝、督导员无权核销、数据库统计及空分母。其中统计用例创建了 1 条正常和 1 条异常记录核销前断言总数为 2、正常为 1、待整改为 1、已处理为 0核销后断言待整改为 0、已处理为 1该比例落到 100%。AuthAndSecurityIntegrationTests6 个未认证 401、错误口令 401、督导员与复核员各自可取到身份、督导员核销 403、复核员核销成功且resolvedBy被绑定为登录人姓名。测试数据与截图中的 24 条记录是不同的数据集。空库时闭环率为null新增一条异常后为 0%核销后为 100%这是测试覆盖的变化过程。本次 Maven 报告的运行时为 JDK 25.0.2pom.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 #程序员必备
# AI 写完后台就能交付？我用飞算 JavaAI 核对了 24 条巡检记录 24 条巡检，10 条正常，14 条异常，闭环率 64.3%。 这是“尺鉴”巡检后台运行截图上的一组数字。页面有了，数
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.0Java 编译目标 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_tasktask_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_userusername唯一、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的实现原样贴出来OverrideTransactional(readOnlytrue)publicDashboardStatsVogetDashboardStats(){longtotaltaskRepository.count();longnormaltaskRepository.countByStatus(InspectionStatus.NORMAL);longabnormaltaskRepository.countByStatus(InspectionStatus.ABNORMAL);longresolvedtaskRepository.countByStatus(InspectionStatus.RESOLVED);longtotalIssuesabnormalresolved;DashboardStatsVovonewDashboardStatsVo();vo.setTotalTasks(total);vo.setNormalTasks(normal);vo.setAbnormalTasks(abnormal);vo.setResolvedTasks(resolved);vo.setResolutionRate(totalIssues0?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 认证凭据存在sessionStorageBase64 编码不等于加密正式接入需要配置 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 错误构建成功。具体组成如下InspectionServiceIntegrationTests4 个编号派生与正常记录不含异常字段、异常详情为空时拒绝创建及重复核销拒绝、督导员无权核销、数据库统计及空分母。其中统计用例创建了 1 条正常和 1 条异常记录核销前断言总数为 2、正常为 1、待整改为 1、已处理为 0核销后断言待整改为 0、已处理为 1该比例落到 100%。AuthAndSecurityIntegrationTests6 个未认证 401、错误口令 401、督导员与复核员各自可取到身份、督导员核销 403、复核员核销成功且resolvedBy被绑定为登录人姓名。测试数据与截图中的 24 条记录是不同的数据集。空库时闭环率为null新增一条异常后为 0%核销后为 100%这是测试覆盖的变化过程。本次 Maven 报告的运行时为 JDK 25.0.2pom.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 #程序员必备
