26软工实践 啊对对队 团队展示与选题报告

一、团队展示

1. 项目名称与选题

• 团队名称：啊对对队
• 项目名称：LabMate 智能实验室管家
• 项目领域：实验器材规范使用与新手误操作预防，首期聚焦创客中心拓竹 H2D 3D 打印机。
• 项目一句话：把型号匹配的操作指导、使用前检查和软硬件确认串起来，帮助刚进入实验室的同学减少误操作和设备损坏风险。

标志以仪器面板对应实验器材，检查清单对应操作前的条件核对，盾牌中的确认符号对应权限与人工确认。我们希望把规范使用落实到具体步骤，尽可能减少新手误操作。

2. 项目介绍

我们希望先解决新同学刚接触实验器材时的一件事：不熟悉设备和操作要求，可能漏做检查、误解步骤，或在条件没有确认时就继续操作。首期对象已明确为创客中心的拓竹 H2D 3D 打印机。团队确认该设备有可读取运行状态的接口，具体字段、调用方式、授权范围及适用规程将在接入前核对；当前尚未进行软件接入与联调。

首期最想向使用者介绍的价值是：在开始操作之前，让同学知道还缺哪项检查、为什么需要检查，以及下一步应该做什么。系统结合型号资料、人工确认和可获取的硬件状态，把说明书里的要求落实到当前这一次使用。通过本软件发起的请求，在必要条件未满足时暂停；需要管理员帮助的情况则明确引导。我们希望先把这一两个具体环节做好，再考虑更多设备和功能。

答辩后，团队决定暂缓灯光、日历、多实验室和通用旧设备接入，集中设计一条使用前流程：选定设备与任务，按审核过的清单逐项检查，结合能获得的硬件状态核对条件，再由使用者确认。遇到条件缺失、资料不匹配或权限不足时，软件指出缺项并暂停本软件内的开始请求，需要时联系管理员。

大语言模型主要承担理解自然语言问题、解释操作要求和追问缺失条件的工作。后端用明确规则检查身份、清单、确认和允许的动作，网关负责实际设备通信。模型给出建议，不能自行认定设备安全或绕过检查。

软硬件联动是首期核心设计。计划优先利用 H2D 已有的运行状态接口，将实际读数、使用前检查和软件提醒对应起来。读取状态与控制设备分别核验：已有状态接口不等于所有动作都允许远程执行。对于尚未获准的控制动作，采用低压训练装置验证“输入条件变化、软件提示、确认、受控输出”的流程。训练数据始终标为演示，不冒充 H2D 实际读数或真实防损效果。

真实设备接入与训练演示分别检查：前者需要说明具体型号、获准接口及能获得的实际条件，后者只说明输入、规则、确认和输出是否对应。如果最终只能完成训练演示，就如实保留真实设备接入的缺口，不把演示结果写成真实打印机的防损效果。

另保留一项小范围增强：用户主动上传操作前照片，视觉模型结合型号和清单提示可见疑点，并说明需要现场确认什么。它不承担连续监控、故障定责或安全合格判定。我们的目标是降低可识别的误操作风险，实际效果需后续实现和使用反馈支持。

3. 已开展调研与需求依据

已查到的公开资料

我们查阅了福州大学公开的《实验室安全管理办法》，其中涉及实验室操作规程、设备使用维护、检修记录和实验结束检查。福州大学实验室安全管理办法

同时查到学校公开有仪器设备管理办法、仪器设备管理系统个人业务操作手册和维保申请表。仪器设备管理办法 · 个人业务操作手册 · 仪器设备维保申请表

这些材料说明校级已有相关制度和入口，可作为领域知识来源和产品边界。它们不能证明具体实验室是否使用这些流程、学生是否能访问，也不能证明用户存在资料查找困难。因此，我们先关注型号匹配的使用指导、操作前条件检查和受控确认是否能帮助新同学规范操作，保留现有设备管理与维修流程。

用户调研状态

团队在 2026 年 10 月中下旬、答辩准备期间，与协会管理人员和初学使用者开展了围绕创客中心设备使用的需求交流。时间为成员回忆的大致范围，具体日期与人数未作完整记录。以下按成员提供的反馈摘要整理，不是录音逐字稿。团队进一步明确首期设备为拓竹 H2D，并确认存在运行状态读取接口；这项接入条件不代表项目已经完成联调。

“不规范使用”暂按操作准备、维护权限、收尾和记录问题细分，具体发生经过与原因仍需核实。这些分类是需求分析结果，不是新增调查事实。视觉辅助提醒是团队提出的增强设想，也不是已经验证有效的用户需求。

从“不会用”继续追问原因

已有说明书、培训或他人指导，为什么仍可能出现误操作？这是本轮需求分析需要继续核实的问题。我们先列出可能原因及对应设计，再通过现场观察判断哪些最值得优先解决。

这些都是方案假设，尚不能当成已经查明的事故原因。后续优先观察一名新同学完成一次使用前准备，再与管理员核对其中一两个关键环节；不根据假设宣称所有误操作都能被阻止。

4. 答辩反馈与选题调整

10 月 24 日的答辩中，老师追问了项目与一般实验室管理软件的区别，以及主要解决的是管理问题还是新手操作指导。结合讨论，我们理解老师更关心：能否找到一个现实、具体的问题，说明最受影响的人是谁，并把处理过程做完整。

老师还提醒我们，范围过广容易让每项功能都停留在表面。仅把资料交给模型阅读，并不能自然解决设备出现问题后没人知道怎样处理的情况。打印中断、设备报警等是在讨论中提出的细化方向，不能直接写成已经调查确认的案例。

以上结合现场转录与团队拍摄的课堂评价记录整理，不是逐字引语。记录中针对第二组的意见集中在：创客中心打印机的真实痛点、产品最值得介绍的价值，以及深入解决一两个问题、考虑一两台打印机的接入。课堂共性要求还包括明确项目经理，回答为何不直接使用通用大模型，并继续分析问题发生的原因。这些材料作为方案修订的依据，不替代对真实使用流程的观察。

老师提出的是聚焦具体问题、控制范围；“围绕新手操作前检查开展软硬件联动”是团队据此进一步确定的方向，不写成老师指定的方案。接入一两台设备是范围建议，首期仍以一台目标设备为起点。

下一步拟观察新同学从准备到开始使用设备的过程，核对哪些步骤容易遗漏、哪些条件能由接口或传感器获得、哪些必须本人或管理员确认，以及软件外是否仍可直接启动设备。照片辅助是否有价值也需确认。目前没有事故次数、损坏率或降低误操作的实测数据。

5. 目标用户与拟定场景

拟定场景：新同学准备使用拓竹打印机，系统确认型号、角色和任务，按本地规程列出使用前检查。可由接口读取的状态标明来源和时间，需本人确认的条件逐项填写。条件不满足或未知时，提示缺项并暂停本软件内的开始请求；通过审核规则后，用户确认，后端授权允许的下一步，网关执行并回传结果。真实设备动作与低压训练演示分别标明。

照片辅助作为 P1：用户上传获准拍摄的设备或操作区域照片，模型只描述可见情况和可能疑点，映射到检查项后交由现场人员确认；不把不可见条件推断为正常。异常求助只保留补充入口。

6. Agent 定制思路

本地资料按实验室、型号和有效版本优先检索。提示词示例说明怎样追问、引用和表达未知；清单是否完成由后端记录和判断，不能仅凭模型说“已检查”就通过。

为什么还需要 LabMate

通用大模型和厂家助手可以提供设备知识。LabMate 拟补充的是创客中心本地的操作资格、现场规程、当前检查状态和硬件条件，并把这些信息接入一次具体使用流程。不是所有既有工具都缺少这些能力，后续仍需核实它们已覆盖什么，优先复用能满足需求的部分。

模型负责理解和解释，后端负责规则、权限及确认，网关负责获准的设备交互。软件工程工作的重点是让界面、业务状态、设备来源和异常处理保持一致，便于后续验证。权限控制和执行条件不能只依赖聊天回答；如果现有系统已经完整满足这些需要，也应据实调整项目范围。

联网补查、历史文献/数据库和厂商 Agent 协作放入未来发展。文档、图片和工具返回中的指令只当作数据，不授予操作权限；视觉描述不直接触发设备动作。

7. 首期功能范围

P0 拟开发：一台目标设备的使用前检查与软硬件确认流程。当前尚未实现。

• 设备、角色与任务选择，按型号展示审核过的使用指导。
• 使用前清单：区分人工确认、硬件可读取和未知项，显示依据与缺项。
• 一条硬件联动链路：读取获准设备状态，或用低压训练装置的按钮/开关表示一项检查条件；变化时更新软件提示。
• 后端校验身份、规则和确认。未通过或取消时，不发出本软件内的开始请求；通过后只执行已批准的下一步。
• 受控输出与回执：先在低压装置演示确认后的状态变化；真实设备动作另核接口与批准，不默认接管打印机供电或加热。
• 保存检查、确认、失败和结果记录，不确定或异常时提供管理员入口。

P1 小范围增强：主动上传一张操作前照片，借助视觉理解指出可见疑点与待确认位置，结果供现场人员复核。暂不做视频监控、自动事故识别或自动控制。

未来发展：更多实验室和设备、历史文献/数据库、联网补查、灯光/空调、门禁、比赛日历、厂商 Agent 转接及通用 USB 共享。均不列为本期验收项。

能力边界：本软件可以拦截通过它发起的未满足条件的请求。如果真实设备仍可由面板等渠道直接启动，软件提示不能保证阻止所有误操作；设备侧互锁需独立核实。低压演示只证明联动流程，不等同于已降低真实设备损坏率。

8. 软件结构与设备接口设想

新同学/管理员 → Web（任务、指导、清单、确认、结果）↓后端（权限、规则校验、Agent、操作记录）├─ 本地审核资料与 Skill├─ MCP：检索、状态、检查、确认与有限动作└─ Adapter/本地网关├─ 获准的目标设备接口└─ 低压训练装置：实体输入与受控输出
增强：用户主动上传照片 → 视觉辅助描述 → 现场人员复核

前端显示缺项、依据和真实/演示来源，后端维护清单状态、规则、权限与本次确认，网关连接硬件。拟采用 Vue、FastAPI 和 PostgreSQL，模型经可替换 API 接入。

实体输入或设备状态变化后，网关返回带时间的读数，软件按规则更新提示。用户补齐检查并确认后，后端复核目标、参数和状态，才允许网关执行指定动作。回执缺失显示未确认完成，Agent 不能补写成功。

H2D 运行状态读取接口已由团队确认存在，具体采集字段与授权方式仍需核对；额外训练器件和受控动作方案尚待确定。硬件必须对应清单中的具体条件，不能仅与任务无关地亮灯；不预设任意拓竹控制指令可用，也不直接改造市电线路。

9. 后续验收要求与定制效果检查设想

下表均为未来交付条件，当前没有运行结果、硬件联动或视觉效果数据。

未来关注用户能否理解要求、发现清单中的遗漏，以及未通过条件的请求能否被软件拦截、软硬件状态是否一致。是否降低真实损坏率，需要更长时间的使用依据，不能根据演示直接推断。

10. 团队成员风采

我们是啊对对队，由六名成员组成。下面结合本次答辩分工，介绍大家在项目中准备承担的工作。

李嘉星｜102401128｜需求与项目管理、Agent 与知识

李嘉星担任项目经理，负责把用户反馈整理成具体需求，协调项目范围、任务分配与开发安排，并跟进沟通和进度。同时承担 Agent 和知识库相关设计，关注模型怎样检索资料、选择工具，以及什么时候应该转交人工。接下来将重点整理拓竹设备资料和使用前检查流程，让团队围绕同一个具体问题推进。

林诗航｜102401129｜后端与数据、答辩主讲

林诗航担任本次选题答辩主讲，并与张炜鑫共同承担后端与数据工作。后续重点是账号权限、检查规则、用户确认和操作记录，让前端的检查与实际执行对应起来。讲清楚方案，也把检查和确认落实到接口和数据中，是这一角色的主要任务。

张炜鑫｜102401127｜前端交互、后端协作

张炜鑫负责前端交互，并参与后端与数据设计。前端需要让新同学看清当前步骤、未完成条件和下一步。后续重点是指导、清单、动作确认与结果页面，同时对齐后端字段与硬件状态，减少页面显示与实际情况不一致的问题。

谢玲洁｜102401101｜质量与部署

谢玲洁与李莹莹共同负责质量与部署。当前重点是梳理需求是否完整、每项功能将来怎样验收；进入开发阶段后，再跟进问题记录、版本交付与部署说明。资料查不到、提交被取消、用户没有权限时，软件还能不能给出清楚的下一步，也是这一岗位需要关注的细节。

李莹莹｜102401104｜质量与部署

李莹莹与谢玲洁共同承担质量与部署工作。后续会从学生和管理员两种身份检查使用流程，关注检查是否容易完成、提醒是否清楚、取消操作与硬件结果是否一致，并整理使用反馈和交付材料。两人协作完成质量与部署任务，具体检查项随开发进度继续细分。

王清源｜102401134｜设备与网关

王清源负责设备与网关方向，围绕已确定的拓竹 H2D 核对官方资料、状态接口的字段、授权和调用方式。设备显示在线，是否就能说明它正在正常工作；接口返回的信息能否对应具体检查项，都需要逐项核实。后续负责真实状态读取、低压训练输入与受控输出的核对，让清单、软件提示和硬件行为对应起来。

11. 团队首次合照

12. 团队愿景

我们希望刚进入实验室的同学，能看懂设备要求，少漏一次检查，少做一次不确定的操作。团队从创客中心的一台设备做起，把有依据的指导、软硬件确认和必要的人工帮助连起来，让器材更好用，也更经用。

13. 团队初步分工

二、需求分析说明书

1. 文档目的与适用范围

本说明参照 GB/T 9385-2008《计算机软件需求规格说明规范》的组织思路，描述用户、业务范围、功能、接口、数据及验收条件。介绍、调研依据、目标用户和项目标志见上文；本节补充需求细节。

本版依据课堂反馈及团队后续讨论，将首期确定为“拓竹设备的新手规范操作与软硬件确认”。P0 为首期拟开发流程，P1 只保留单张照片视觉辅助；其余功能放入未来发展。历史版本中较大范围和事后交接方案不作为本版首期承诺。本文已内嵌当前需求说明。

2. 需求沟通与形成过程

我们先从创客中心的交流中收集问题，再整理可能的用户任务，形成课堂汇报方案。答辩时，老师对“管理还是指导”“范围是否过大”“资料问答能否解决具体问题”提出追问。本版据此调整范围，并把仍需回访的内容列出。

后续沟通拟围绕新同学准备和使用设备的过程：哪些要求不易理解、会漏哪些检查、谁确认资格、接口能读取什么、现场有哪些绕过软件的操作渠道。记录中分开保存对方描述、可回查材料与团队解释。照片辅助另核实能观察什么、哪些内容不能拍摄或上传。

3. 思维导图

4. 功能需求与前后端职责

操作状态：待检查 → 存在缺项或待确认 → 已通过规则、等待确认 → 执行中 → 已获回执/执行未确认。条件变化、状态过期或确认超时后需重新检查；取消不执行。状态仅表示软件流程，不代表设备满足全部安全条件。

管理员入口：首期查看缺项和操作记录、维护审核配置、提供人工帮助；复杂报修工单与完整维修流转暂缓。

5. 接口草案与核心数据

核心数据包括用户、设备、资料片段、检查模板、检查会话、硬件快照、确认操作和事件记录。检查项标明人工/硬件来源；快照包括真实/演示、时间与有效性。视觉结果独立保存为“辅助疑点与待确认项”，不直接改写硬件条件或产生通过结论。

核心类图

6. 代表性任务及未来验收标准

以下为拟定任务，不是已发生事故或已完成产品测试。具体规则需由适用手册、现场规程和管理员确认。

定制效果检查设想：同一底座模型与任务背景下，对比纯 LLM 和完整 Agent 对操作要求的解释、缺失条件追问、引用及下一步建议。执行约束另用记录和实体回执核对，不能把有无工具的差异全部归因于模型理解能力。

照片辅助若实现，单独检查可见疑点描述、无法判断时的表达与人工复核结果，保留误报和漏报。用户是否少漏步骤、是否理解提醒、能否绕开软件，都需真实反馈；不以训练演示推算损坏率下降。

7. 非功能要求与异常处理

• 权限与执行：用户、设备、工具和参数分别校验，模型不能修改授权；确认绑定目标与参数，变化后重新确认。
• 规则与资料：规程、清单和白名单经管理员审核，后端判定是否通过；模型只负责解释与任务组织。
• 硬件异常：真实/演示、人工/采集、历史/实时分开标明，离线、过期或回执缺失时暂停本软件放行流程。
• 视觉边界：只处理主动上传的获准照片；模糊、遮挡和内部状态不猜测，不替代传感器、资格审批或现场检查。
• 提示词注入：文档、图片和工具返回中的指令无权改变权限，后端执行固定工具与参数约束；内部数据不自动外传。
• 最少记录：保存必要检查版本、输入来源、确认和回执，不保存无关照片或凭据；上传前说明用途与保留方式，具体期限待中心确认。
• 使用与交付：移动端可完成检查和确认，提示说明缺什么、为什么、找谁。最终提供线上入口和实体检查方式，当前尚未上线。

8. 实施顺序与主要依赖

主要依赖是审核过的规则、可获得的硬件状态和获准动作。没有设备侧约束时只能控制本软件请求，不能以页面通过承诺设备不会损坏。视觉能力也应以能否帮助完成某一具体检查为取舍标准。

需求迭代记录

参考资料

• 课程作业要求
• 福州大学实验室安全管理办法
• 福州大学仪器设备管理办法
• 福州大学仪器设备管理系统个人业务手册
• 福州大学仪器设备维保申请表
• GB/T 9385-2008 需求规格说明规范
• Agent Skills 规范
• Model Context Protocol Tools

---