实验样品一多就容易找错，我用飞算JavaAI做了个追踪面板

一、样品在实验室里流转，最怕的不是量大，而是"不知道到哪了"

我在第三方检测机构负责实验室信息管理。外人看实验室，觉得最头疼的是检测精度——但真正在一线待过的人都知道，样品流转过程的失控才是管理成本的隐形杀手。

一个样品从送检登记到最终归档，中间要经历至少 5 个阶段：登记、待检测、检测中、待复核、归档。以前我们靠纸质流转单配合 Excel 表格来管，样品少的时候还能应付，一旦碰上批量送检（比如食品厂每月的例行抽检），问题就暴露了：

• 登记完的样品没人分配检测任务，在角落放了一周也没人发现；
• 检测结果超标了没有自动标记，审核员要在几十个样品里挨个翻；
• 想查某个样品现在在哪个人手里、卡在哪个环节，至少要问三个人。
  简单说就是：信息有，但散在各个环节里，没人能一眼看全。

所以我想做的，其实不是一个"大而全"的 LIMS（实验室信息管理系统），而是一个聚焦于样品流转可视化追踪的轻量面板——谁登记、谁检测、谁复核、异常在哪里，一张页面说清楚。

---

二、成品首秀：从工作台一张图看清所有样品状态

 

 

 

最终做出来的系统叫 LabTrack，首页工作台长这样：顶部四张统计卡片分别展示样品总数、待检测数、待复核数和异常样品数；中间是一条横向样品生命线，五个阶段一目了然，每个节点旁边标有当前存量；下方左侧是今日待办清单，右侧是最新登记的样品列表。

登录进去第一眼看到的就是这张图，不用翻任何菜单就能知道"今天要做什么、哪些卡住了、哪些有异常"。

 

 

侧边栏包含了 9 个核心功能入口：工作台总览、样品登记、样品列表、检测看板、检测记录、复核管理、异常追踪、报告管理、统计分析。每个页面都承担了样品流转中的一个关键角色视角。

三、把检测流程拆成五段，每一段都是一个状态机

动手写代码之前，我先在纸上画了一下业务流转路径。实验室样品追踪的核心其实不复杂，就是一条直线型状态机：

 

 

但这条线背后，每个节点都有明确的职责分工和触发条件：

样品列表页实现了按状态、分类、关键字的多维筛选。每一行样品的状态用不同颜色的徽章标识——灰色待登记、蓝色待检测、橙色检测中、红色待复核、绿色已归档——看颜色就知道当前卡在哪。

---

四、飞算 JavaAI 的智能引导，帮我从想法到工程

4.1 Prompt 输入：说清楚业务就行

我打开 IDEA 右侧的飞算 JavaAI 插件面板，选择"智能引导"。

 

输入的需求是：

没有刻意堆专业术语，就是把我上面画的流程用自然语言描述了一遍。

4.2 AI 确认需求：提取角色和功能模块

 

 

AI 读了我的需求之后，很快梳理出了三个核心角色和对应的功能域：

• 样品管理员：样品登记、检测任务分配、样品信息管理
• 检测工程师：检测任务看板、检测结果录入、仪器数据关联
• 质量审核员：复核管理、异常处理、报告签发
  这个阶段最让我惊喜的是，AI 主动问了一句"样品是否需要区分加急和常规"，这个细节我第一次没写进去，但确实在真实场景中很关键。

4.3 接口与模型设计：实体关系和 API 契约

AI 生成了样品（Sample）、检测项目（TestItem）、检测结果（TestResult）、用户（User）等核心实体，以及它们之间的关联关系。最关键的是，它自动设计了一套状态枚举和状态转换约束，保证了流转不能跳阶段（比如不能从"待登记"直接到"待复核"）。

API 接口也一并生成了：样品 CRUD、状态更新接口、检测结果录入、复核审核、统计查询等，RESTful 风格，路径命名干净。

 

4.4 表结构设计：DDL 和关联关系

生成的表结构包含了外键约束、索引设计和状态字段的枚举定义。样品表用 status 字段 + status_label 来兼顾机器判断和前端展示，检测结果表用 ref_range 和 is_out_of_range 字段来支持自动比对——这些都是我在 Prompt 里没有明写，但 AI 根据"自动比对标准范围"这个意图推断出来的。

 

 

4.5 生成计划和源码生成

AI 把整个工程分成了前端 Vue 3 项目和后端 Spring Boot 项目，并列出了完整的目录结构：页面组件、路由配置、数据层、API 层。

生成完成之后，我直接导出了前后端两个工程。前端是 Vue 3 + Pinia + Vue Router，后端是 Spring Boot + MyBatis-Plus + MySQL。骨架部分基本没修改，直接跑起来了。

---

五、核心页面设计意图：不只是"把数据列出来"

5.1 检测看板 — 拖拽流转的核心交互

 

这是我最满意的一个页面。五个竖列对应五个样品状态，每张卡片是一份样品，卡片左上角显示编号、右上角显示紧急程度、底部显示负责人员和异常标记。卡片可以直接在同列拖拽调整顺序，也可以跨列拖拽改变状态——比如检测员做完检测后直接把卡片从"检测中"拖到"待复核"。

异常样品在卡片左侧有一条红色边框标记，进入看板第一眼就能看到。

5.2 复核管理 — 异常处理的工作流入口

 

审核员在这里看到所有"待复核"的样品。点击复核按钮后弹出操作弹窗，弹窗里逐项列出该样品的所有检测结果，超出标准范围的项目用红色高亮。审核员可以选择"复核通过并归档"，对于异常样品还可以选择"退回重检"——退回后样品状态回到"待检测"，检测员会重新收到任务。

5.3 异常追踪 — 专项管理超标样品

这张表专门列出所有包含超标检测项的样品，每条记录左侧用红色边框标记，超标的具体项目和数值直接展示在列表中。点击"处理"按钮直接跳转到复核页面，不需要记住编号再翻回去找。

 

5.4 统计分析 — 数据可视化辅助决策

 

统计页面用纯 CSS 实现了状态分布条形图、分类分布图、近 7 日检测趋势柱状图和一个 SVG 环形图。不用额外引入 ECharts 等图表库，数据全部来自 Mock 层，但布局和数据口径已经对齐真实业务——比如"异常率"的定义是有超标项的样品占总样品的比例。

六、技术栈与职责对照

这个项目虽然是一个 Demo 级的前端原型，但整体的技术选型已经对齐了企业级的前后端分离架构：

我的原则是：骨架由 AI 生成，灵魂由开发者注入。AI 帮我把 80% 的工程化脚手架和样板代码写好了——路由配置、Store 定义、组件模板、Mock 数据格式——但我自己动手调整了状态流转的边界条件（比如退回重检后不能直接归档）、异常标记的触发逻辑、以及每个页面的排版布局和信息优先级。

---

七、总结：AI 加速了"从想法到原型"，但业务判断还是得人来做

这次做 LabTrack，最大的感受是飞算 JavaAI 的智能引导在需求结构化上确实帮了大忙。以前做类似的项目，我得先花半天搭工程脚手架、写路由、配 Store，然后才敢开始想业务页面。现在 Prompt 写完、对话确认完需求，工程骨架和接口定义已经自动生成好了，我可以直接进入"修改+微调"环节。

但有几个地方 AI 做不到，或者说做得不够好：

1. 状态机的边界规则：AI 知道样品有 5 个状态，但"退回重检后样品应该回到待检测还是检测中"这种业务决策，它不会替我做。
2. 页面信息优先级：AI 生成的列表页把所有字段都展示出来了，但实际使用中"当前负责人"和"进入当前阶段的时间"比"送检方"重要得多——这需要人对操作场景的理解来调整。
3. 异常处理的分支逻辑：检测结果超标后，是直接标记"不合格"还是要走一个"异常评估流程"？不同实验室规则不同，AI 只能给出通用方案。
   AI 负责把工程冷启动的成本降到最低，但产品细节和业务逻辑的打磨，还是得真正懂业务的人来把控。

这话听起来像套话，但做完了这个项目之后，我是真的这么觉得的。

---

本文参与「飞算 JavaAI 炫技赛」分享。由 JavaAI 免费版（9.9 元/月）提供代码生成支持。如果你对 AI 辅助开发或者 Java 项目提效感兴趣，也可以试试飞算 JavaAI 的专家 Agent 工具，支持多 Agent 面板和智能引导——你的下一个项目可能就从一次对话开始。