绪论
1.1 选题背景、目的和意义
随着城市化进程加快，园林绿化作为城市生态建设的重要组成部分，其管理养护水平直接影响城市环境品质与居民生活体验。当前国内园林管理行业普遍面临人力成本居高不下、养护决策粗放、异常响应滞后等现实问题。据中国城市绿化发展报告显示，2023年全国城市绿地面积已突破320万公顷，但园林养护自动化覆盖率不足15%，超过七成园林企业仍以人工巡查为主要管理手段。这种高度依赖经验的作业模式导致水资源浪费严重、病虫害发现不及时、养护质量参差不齐，难以适应现代城市对精细化管理的要求。
在学术研究方面，国内外学者围绕智慧园林建设已展开积极探索。早期研究多聚焦于单一传感器数据的采集与展示，近年逐步向物联网平台集成方向发展。部分研究人员尝试将专家系统引入灌溉决策，取得了一定成效。然而现有成果仍存在明显不足：一是多数系统仅解决数据监测问题，缺乏面向养护决策的智能分析能力；二是对游客端的互动服务关注较少，园林公共服务功能拓展不足；三是系统架构多采用传统单体设计，功能模块耦合度高，不利于后续扩展与维护。基于上述分析，本研究选择以"管、控、营、服"一体化为主线，在传统环境监测基础上引入人工智能大模型进行决策支持，同时将管理端业务与游客端服务纳入统一架构，探索一种兼顾养护效率与用户体验的智能园林解决方案。
从实践意义看，本选题契合智慧城市建设的整体趋势。住房和城乡建设部明确提出推进城市园林绿化数字化管理，各地也在积极探索园林信息化落地方案。将人工智能技术与园林管理深度融合，一方面能够降低人工依赖，通过数据驱动实现精准灌溉、科学施肥和病虫害早期预警，直接压缩养护成本；另一方面可为游客提供智能导览、植物识别等增值服务，提升园林公共服务水平。从学科角度而言，本研究以风景园林学为业务主体，综合运用计算机科学与人工智能技术，为传统园林养护向数字化、智能化转型提供了可参考的技术路径，对推动行业发展具有现实价值。
1.2 国内外研究概况
1.2.1国外研究概况
国外在智慧园林及相关领域的研究起步较早，围绕物联网环境监测、智能灌溉控制和人工智能视觉识别三大方向形成了较为系统的技术体系。在物联网与智能温室集成方面，有学者对2021年以来超过100项相关研究进行了系统综述，指出IoT、机器学习及深度学习技术正加速推动数据驱动的智能温室应用发展。在智能灌溉领域，Saravanan等将卷积神经网络等机器学习模型嵌入物联网框架，构建了自动灌溉系统，其中卷积神经网络模型准确率达到了98.55%。Amir等提出了基于深度学习的番茄茎流预测框架，利用LSTM、GRU等循环神经网络模型分析蒸气压力差和CO₂数据，实现了非侵入式的精准水分管理。在植物病虫害检测方面，多项综述研究指出，卷积神经网络已成为应用最广泛的植物病害识别方法，视觉Transformer模型在准确率方面表现更优但计算资源消耗较高，此外联邦学习和边缘计算等分布式智能方法正成为新的研究热点。在景观智能管理方面，Xie基于改进GoogLeNet算法构建了科创园区植被智能识别系统，平均识别准确率达92.95%。
1.2.2国内研究概况
国内研究方面，随着智慧城市建设的深入推进，智慧园林管理系统的设计与实现逐渐成为学术界关注的重点方向。在系统架构与集成方面，已有研究结合实景三维技术、GIS、物联网及Android移动端等信息化手段，设计实现了园林植物的精确定位与数据可视化管理系统。也有学者基于WebGIS技术，利用SOA面向服务架构整合GPS、云计算等技术，构建了城市园林绿化综合管理数据库与业务平台。在物联网监测方面，有研究采用NB-IoT技术设计植物景观墙监测系统，以STM32为主控芯片，结合K210处理器与摄像头模块实现植物病害实时检测-23；另有研究基于ZigBee无线传感网络构建园林景观监测系统，实现对温度、湿度及烟雾浓度的实时采集与预警-。在智能灌溉领域，有学者以STM32F103C8T6为主控芯片设计光伏智能灌溉装置，支持自动、手动和定时三种工作模式；还有研究基于LoRa无线传感器网络构建智能节水灌溉系统，替代传统人工干预方式，有效减少了约30%的水资源浪费。在人工智能应用方面，已有学者将深度学习算法嵌入手机APP，利用MobileNet卷积神经网络实现园林植物图像自动识别，应用于辅助植物学教学。在北京城市副中心的智慧园林实践中，研究人员设计并实现了公众服务、生态监测和预警通知三个子系统，初步搭建了面向管理者和游客的双向服务平台。
综合来看，国内外研究在物联网感知、智能灌溉和图像识别等单项技术方面已取得显著进展，但将管理与服务深度融合、将人工智能大模型同时应用于养护决策与游客互动的研究仍较为薄弱，这也为本文的研究工作提供了切入点。
1.3 主要研究内容
本研究围绕智能园林管理系统的设计与实现展开，主要研究内容包括以下四个层面。第一，系统需求分析与总体架构设计。在对园林管理业务进行实地调研的基础上，梳理管理员、养护经理和游客三类用户的核心需求，提出"前---中---后"三层系统架构，明确各层的功能边界与数据交互关系，完成数据库表结构设计与技术选型。第二，物联网环境感知模块的构建。设计传感器数据模拟器，按照花园区、草坪区、树木区等不同场景生成温度、湿度、土壤湿度、光照强度等多维环境参数；基于定时任务机制实现数据自动采集与存储，并对异常数据进行告警规则匹配，支撑后续的智能决策分析。第三，人工智能驱动的智能决策模块开发。在文本分析方面，通过调用大语言模型应用程序接口，实现灌溉策略生成、植物营养分析与能耗优化建议等功能，将环境数据转化为可执行的养护方案；在图像识别方面，接入视觉大模型完成植物种类识别与病虫害诊断，模型接收用户上传的植物或叶片图片后返回分类结果、病害类型及防治措施。第四，可视化运维与游客互动模块的实现。面向管理端，搭建基于ECharts的数据监控面板与大屏展示页面，以图表方式呈现区域环境动态、告警分布和历史趋势；面向游客端，开发植物识别、游览路线智能推荐和环保知识问答等互动服务，将人工智能能力从后台管理延伸至前端用户体验。整个系统采用Flask框架统一整合上述模块，通过应用程序接口进行数据交换，最终形成从数据采集、智能分析到业务应用和公共服务的闭环流程。
2 系统分析
2.1 相关开发技术
2.1.1 Flask Web框架
Flask是由Armin Ronacher于2010年用Python语言编写的轻量级Web应用框架，其设计定位是微内核加扩展机制。与Django等全栈框架不同，Flask只提供路由分发、请求上下文管理和模板渲染等基础能力，数据库访问、表单验证、用户认证等功能均通过官方或第三方扩展模块按需集成。这种设计使开发者在项目初期可以快速搭建原型，在功能迭代阶段又能灵活增补组件，不会因为框架本身的强约束而被迫调整业务逻辑。
本系统选用Flask作为后端框架，主要基于三点考虑。一是园林管理系统的业务模块边界清晰，传感器数据处理、AI服务调用和用户权限控制各自独立，Flask的蓝图机制恰好支持按功能拆分为多个子模块，彼此之间通过应用程序接口进行松耦合通信。二是Flask对SQLAlchemy和Flask-Login等扩展的兼容性好，能够用较少的配置完成数据库映射和会话管理。三是Python语言在数据处理和人工智能调用方面具有天然的生态优势，与Flask结合可以复用大量成熟的科学计算库，降低系统开发的技术门槛。
2.1.2 SQLAlchemy对象关系映射
SQLAlchemy是Python社区使用最广泛的对象关系映射框架之一，由Michael Bayer于2006年发布。它提供两层抽象接口：底层Core层允许开发者直接编写SQL表达式并管理数据库连接池；上层ORM层则将数据库表映射为Python类，将表中记录映射为类的实例对象。两层之间可以自由切换，开发者既能用ORM的高层语义简化增删改查操作，也能在需要精细控制SQL语句时回退到Core层。
在本系统中，SQLAlchemy承担所有数据库交互任务。GardenZone、PlantInfo、SensorData、Alert等业务实体均定义为Python模型类，类属性与数据库列一一对应，关联关系通过外键约束和relationship函数声明。当需要查询某个区域最新传感器数据时，代码层面只需调用对象的查询链式方法，SQLAlchemy会自动生成对应SQL语句并执行。这种抽象方式使数据访问代码与业务逻辑代码解耦，后续若从SQLite迁移到PostgreSQL或MySQL，只需修改数据库连接字符串，模型定义和业务代码基本无需改动。此外，SQLAlchemy的事务管理机制保障了数据写入的原子性，在传感器数据批量入库和告警记录同步创建等场景中能够有效避免数据不一致问题。
2.1.3 Bootstrap与ECharts可视化
Bootstrap是由Twitter公司于2011年开源的前端UI框架，其核心由栅格系统、CSS组件和JavaScript插件三部分构成。栅格系统将页面横向分为12列，通过预设的响应式断点自动适配不同屏幕尺寸；CSS组件封装了导航栏、卡片、表单、模态框等常用界面元素；JavaScript插件提供下拉菜单、轮播图、折叠面板等交互功能。开发者只需在HTML标签上添加预设类名即可获得风格统一的界面，无需从零编写样式代码。
ECharts是由百度公司开源的JavaScript数据可视化库，底层依赖ZRender轻量级Canvas库进行图形渲染。它提供折线图、柱状图、饼图、散点图、仪表盘等二十余种图表类型，支持数据区域缩放、图例筛选、提示框联动等交互操作。图表配置采用声明式的option对象结构，X轴和Y轴的刻度范围、颜色映射、标签位置等细节均可通过参数精确控制。
本系统的前端采用Bootstrap与ECharts并用的方案。页面整体框架、导航栏、标签页切换和表单控件由Bootstrap统一构建，确保在PC端和大屏端的显示效果一致。数据监控面板和告警统计区域嵌入ECharts图表，温度、湿度和土壤湿度等时序数据以折线图形式展示，区域分类占比以饼图呈现，告警级别分布以仪表盘突出标识。这种组合既保证了管理界面操作的规范性，又满足了环境数据可视化表达的灵活性需求。
2.1.4 传感器数据模拟与时序处理
在真实生产环境中，物联网传感器通过LoRa、NB-IoT、ZigBee等无线通信协议将采集数据上传至服务器。但在系统开发和功能验证阶段，直接接入硬件设备存在部署成本高、调试周期长的问题。传感器数据模拟器的作用是在不依赖物理设备的前提下，按照各区域的实际环境特征生成符合物理规律的数据序列。
本系统的SensorSimulator类采用基于场景模板的随机生成策略。针对花园区、草坪区、树木区和水景区等不同区域类型，分别设置温度基准值、湿度基准值、光照强度基准值及各自的波动幅度。在生成每条数据时，引入当日时刻因子模拟昼夜温差变化，叠加高斯随机扰动增加数据真实性，同时对降雨量、风速等偶发事件设定触发概率。生成的传感器数据按分钟级时间间隔写入数据库，形成连续的时间序列，为后续的趋势分析和告警判别提供数据基础。
2.1.5 大语言模型与提示工程
大语言模型是一类基于Transformer架构、参数量达到百亿乃至千亿级别的深度学习模型，其核心能力是通过对海量文本语料的预训练学习语言的统计规律和知识关联，进而具备文本生成、逻辑推理、多轮对话等涌现能力。OpenAI于2023年发布的GPT-4、DeepSeek公司于2024年推出的DeepSeek-V2等模型均在多个自然语言处理基准测试上取得了显著进步。
提示工程是指通过设计和优化输入文本的表述方式，引导大语言模型生成符合预期的输出结果。在系统开发中，并非直接扩写模型参数，而是针对具体任务定制系统提示词和用户提示词模板。系统提示词定义模型的角色身份和输出格式，如"你是一位专业的园林灌溉专家，请根据以下环境数据生成灌溉策略"；用户提示词则填入实际的温度、湿度和土壤湿度数值。二者组合后通过API接口发送至模型服务端，返回文本形式的分析结论。这种调用方式虽然计算发生在远端，但在本地应用层表现为普通的HTTP请求和响应交互，与系统其他模块的集成成本较低。
2.1.6 视觉大模型与图像识别
视觉大模型是指能够同时处理图像和文本两种模态信息的多模态大模型，其结构通常包含图像编码器、文本编码器以及跨模态对齐模块三个核心组件。图像编码器将输入图片转换为特征向量序列，文本编码器将自然语言指令编码为对应的语义向量，对齐模块则通过注意力机制将两种表示映射到同一语义空间，使模型能够理解"图中有什么"并生成相应的文字描述。
豆包视觉模型属于此类多模态架构，支持图像分类、目标检测、视觉问答等任务。在本系统中，该模型承担两个具体的图像识别任务。植物识别任务中，游客通过APP或Web端上传植物照片，系统将图片转为Base64编码后与识别指令一并发送至模型接口，模型返回植物名称、科属分类及形态特征描述。病虫害诊断任务中，养护人员拍摄可疑叶片上传，模型分析叶面斑点分布、变色形态等视觉特征，给出病害类型判断、严重程度评级和防治措施建议。两个任务共享同一套模型调用流程，区别仅在于系统提示词中对模型角色的设定不同。
2.2 可行性分析
2.2.1技术可行性的分析
本系统在技术选型上充分考虑成熟度与可维护性。后端采用Flask 3.0框架，该框架发展至今已有十四年历史，社区生态完善，文档齐全，能够稳定支撑中小规模Web应用的开发。数据持久化选用SQLite数据库，其零配置、嵌入式特性适合园林管理系统初期部署和功能验证，后续如需承载更大并发量可平滑迁移至PostgreSQL或MySQL。人工智能服务通过调用DeepSeek和豆包视觉模型的公开API接口实现，这两款大模型均已商业化运行，接口规范明确，响应延迟可控，开发者无需自行训练模型，降低了人工智能能力集成的技术难度。前端可视化使用ECharts 5.4版本，图表类型丰富，对大屏展示场景适配良好，与Bootstrap 5.3的组合方案在多个行业管理系统中已得到实际验证。综上所述，系统从技术上是可行的。
2.2.3经济可行性的分析
本系统的开发成本主要包括软件工具采购、服务器租赁和人力投入三个方面。在软件工具方面，系统采用Python、Flask、SQLAlchemy等开源技术栈，前端借助Bootstrap和ECharts等免费组件，无需支付商业授权费用；开发工具使用PyCharm社区版和Visual Studio Code等免费编辑器，不产生额外软件成本。在服务器租赁方面，系统支持轻量级部署，SQLite数据库对硬件资源要求低，初期使用单台云服务器即可满足小型园林管理场景的正常运行需求，月租费用在可控范围内。在人力投入方面，系统架构采用模块化设计，各功能模块边界清晰，一名开发人员在三个月内即可完成核心功能的编码与联调。
2.2.4操作可行性的分析
本系统面向园林管理员、养护经理和游客三类用户群体，在设计上充分考虑了不同角色的操作习惯和技能水平。管理后台的操作界面采用与主流信息系统一致的左侧导航加右侧内容区的布局，增删改查交互沿用表格列表加表单弹窗的标准模式，管理人员无需专门培训即可上手。数据监控面板以卡片和图表为主，关键指标一目了然，大屏页面自动适配分辨率，投放至会议室显示屏时无需额外调整。游客端的植物识别功能操作路径清晰：进入页面、点击上传、查看结果，三步即可完成，与日常手机拍照后识别的使用习惯一致。游览路线推荐采用勾选框和下拉列表等常见表单控件，操作门槛低。综上所述，系统从操作上是可行的。
2.2.5法律可行性的分析
在整个开发过程中，智能远程视频会议系统严格遵循相关法律法规。在数据安全与隐私保护方面，严格遵守《中华人民共和国网络安全法》《数据安全法》《个人信息保护法》等国家法律规定，对用户的数据进行加密存储和传输，保证数据的保密性、完整性与可用性。在获取DeepSeek等技术的使用授权时，通过合法渠道与授权方签订协议，明确双方权利义务，确保技术使用合规。
2.3 需求分析
2.3.1用户需求分析
本系统的用户分为三类，各类需求侧重点不同。
园林管理员关注系统整体运行态势，需要查看各区域传感器实时数据、告警分布、植物健康统计等信息，并要求具备用户账户管理和系统参数配置权限。养护经理侧重于日常业务操作，需要接收告警通知并及时处理，使用人工智能策略生成功能辅助灌溉和施肥决策，上传异常植物图片进行病虫害诊断。游客需求集中在公共服务层面，希望在入园游览时能通过拍照了解植物信息，获取个性化的游览路线推荐，参与环保知识问答以增强游园体验。
2.3.2功能需求分析
按角色权限划分，系统功能需求如下。
管理员功能：包括区域管理（园林区域的增删改查）、告警管理（告警列表查看与手动解决）、传感器数据管理（历史数据查询与分页浏览）、用户管理（账户启用禁用与角色分配）、系统设置（告警阈值配置、人工智能参数调整、通知方式设置、数据清理与导出）。
图2.1 管理员用例图
养护经理功能：包括数据监控面板（区域环境卡片与趋势图表）、告警中心（告警筛选与一键解决）、智能灌溉策略生成、病虫害图像识别、植物营养分析、能耗优化建议。
图2.2 养护经理用例图
游客功能：包括植物信息浏览与搜索、植物拍照识别、游览路线推荐、环保知识问答与环保小贴士获取。
图2.3 游客用例图
2.3.3业务流程分析
本系统核心业务围绕环境数据采集、智能决策支持和游客互动服务三条主线展开。
环境数据采集流程：系统定时触发传感器模拟器为每个活跃区域生成温度、湿度、土壤湿度、光照强度等环境参数，数据写入数据库后由告警规则引擎逐条检查，如温度超过高温阈值或土壤湿度低于缺水阈值则自动创建告警记录，未触发阈值的数据直接存档以供历史查询。该流程无需人工干预，全程自动运行。
图2.4 环境数据采集与告警流程图
智能决策支持流程：养护经理在区域详情页选择灌溉策略或营养分析功能，系统提取对应区域的最新传感器数据，打包为提示词发送至大语言模型接口，模型返回分析结果后渲染至前端页面展示。病虫害检测流程与之相似，区别在于输入为图像文件而非传感器数值，系统将图片转为Base64编码后调用视觉模型接口进行识别，根据返回的严重程度判断是否生成告警。
图2.5 智能决策支持流程图
游客互动服务流程：游客在植物识别页面提交照片，系统调用视觉模型完成识别后返回植物信息与数据库匹配结果。游览路线推荐由游客设置时长、兴趣标签等参数，系统结合区域信息和植物分布调用大语言模型生成个性化路线方案。
图2.6 游客互动服务流程图
3 系统总体设计
3.1 系统架构设计
本系统采用分层架构设计，自底向上划分为数据持久层、业务逻辑层、接口服务层和展示交互层四个层次，数据按照"采集→存储→分析→展示"的主线在各层之间有序流动。
数据持久层位于架构最底层，承担所有结构化数据的存储和访问任务。传感器采集的环境参数、用户账户信息、区域配置、告警记录、植物信息等数据统一存入SQLite数据库，由SQLAlchemy ORM框架封装底层SQL语句，向上层提供面向对象的增删改查接口。这一层的核心职责是保障数据写入的完整性和查询的高效性，不涉及任何业务判断逻辑。
业务逻辑层是系统的处理中枢，集中实现三类核心业务。一是传感器模拟器，按区域类型配置的温度基准和湿度基准等模板参数定时生成模拟环境数据，经阈值匹配后触发告警自动创建。二是人工智能服务模块，封装对DeepSeek文本模型和豆包视觉模型的API调用流程，将环境数据或图像输入打包为提示词发送至远端模型，接收返回的分析结果并进行结构化解析。三是告警规则引擎，对传感器数据逐条执行阈值判别，生成分级告警信息并写入数据库。
接口服务层基于Flask框架构建，以蓝图机制组织路由分组。auth蓝图负责用户登录和资料管理，main蓝图提供区域查看、植物浏览、数据面板等通用页面路由，admin蓝图承载区域编辑、用户管理、系统设置等后台接口，api蓝图暴露传感器查询、人工智能策略生成和历史趋势数据等RESTful接口，visitor蓝图处理植物识别上传、路线推荐和环保问答等前端请求。接口层接收展示层发来的HTTP请求，调用业务逻辑层的对应服务完成处理，将结果封装为JSON数据或渲染后的HTML页面返回。
展示交互层负责面向不同用户端的界面呈现。管理端基于Bootstrap的栅格布局和组件体系构建数据面板、告警列表和设置表单等页面，ECharts图表库嵌入各监控视图实现时序数据的可视化表达。大屏端独立设计css与JavaScript脚本，实现监测指挥舱和综合监控平台两套展示界面，图片与gif素材统一存放于静态资源目录。游客端适配手机浏览器尺寸，植物识别页支持图片预览和拖拽上传，导览推荐页以卡片布局呈现区域信息和服务入口。
图3.1 系统架构图
3.2 功能模块设计
本系统面向园林环境监测、智能决策支持和游客公共服务三大业务主线，整合为环境感知、智能决策、可视化运维、游客互动和系统管理五个功能模块。
环境感知模块负责模拟物联网传感器数据生成与存储。SensorSimulator类内置花园区、草坪区、树木区和水景区四套环境参数模板，每次生成数据时叠加时刻因子和随机扰动，输出温度、湿度、土壤湿度、光照强度、降雨量和风速等字段。生成的记录写入SensorData表，同时推送给告警规则引擎进行阈值匹配，触发条件时自动写入Alert表。
图3.2 环境感知模块功能图
智能决策模块提供四项人工智能分析能力。灌溉策略生成从指定区域取出最新传感器数据，调用大语言模型分析当前环境是否需灌溉并给出建议浇灌量。植物营养分析将植物品种、健康状态与当前环境数据一并提交给模型，获取营养评估和施肥建议。病虫害识别接受用户上传的植物叶片图片，经视觉模型分析后返回病害类型和严重程度。能耗优化建议根据区域类型和历史温湿度数据生成节能方案。四项能力均通过AIService类统一封装调用流程，前端通过api蓝图下对应的POST接口发起请求。
图3.3 智能决策功能图
可视化运维模块面向管理端和大屏端提供数据监控展示。数据监控面板以卡片形式排列各区域最新温度、湿度、土壤湿度和光照读数，24小时趋势图由ECharts折线图渲染小时级聚合数据。告警中心支持按级别筛选未解决告警、单条标记解决和一键全部解决。大屏监测指挥舱集成病虫害预警区、土壤数据面板、气象信息面板和滚动数据日志表等视觉组件，综合监控平台增加用户角色分布图和植物健康状态清单。
图3.4 可视化运维模块功能图
游客互动模块包含植物识别、游览导览和环保教育三项服务。植物识别让游客上传植株照片，系统调用视觉模型识别品种并匹配数据库中的养护信息。游览导览根据游客选择的游览时长和兴趣标签，结合区域分布和植物资源生成个性化路线方案。环保教育提供按水资源、植物保护、节能减排等主题生成的环保知识选择题和小贴士。
图3.5 游客互动模块功能图
系统管理模块提供区域维护、告警处理、传感器数据查询、用户状态管理和系统参数配置等后台管理功能，其中系统设置允许调整告警阈值、人工智能调用参数和数据清理策略。
图3.6 系统管理模块功能图
3.3 数据库设计
3.2.1概念结构设计
本系统采用SQLite关系型数据库存储数据，各数据表之间通过外键约束建立关联关系。GardenZone表为区域主表，SensorData、Alert、IrrigationRecord和PlantInfo均通过zone_id外键关联到具体区域。User表为账户主表，Alert的resolved_by字段外键引用User的id，IrrigationRecord的created_by字段同样外键引用User的id。PlantInfo与GardenZone通过location字段存储区域名称实现弱关联，PestDetection外键指向PlantInfo，EnergyConsumption外键指向GardenZone。SystemSettings表独立存储系统级配置参数，不与其他业务表产生外键依赖。，GardenZone与SensorData、Alert、IrrigationRecord为一对多关联线，User与Alert、IrrigationRecord为一对多关联线，PlantInfo与PestDetection为一对多关联线，如图3.7所示。
图3.7 E-R图
3.2.2物理结构设计
本系统数据库由八张核心表组成，分别存储用户账户、园林区域、环境传感器读数、告警记录、植物信息、灌溉作业记录、病虫害检测记录和系统配置参数。以下列出各表的核心字段设计。
user_garden表记录系统所有用户的账户信息，包含用户名、加密密码哈希值、邮箱、角色类型、真实姓名、联系电话、账户启用状态及注册时间，详情如下表3.1所示。
表3.1 user_garden表
|---------------|--------------|------------|------------|-------------|-----------------------|
| 字段名 | 数据类型 | 主键 | 外键 | 允许空 | 说明 |
| id | INTEGER | 是 | 否 | 否 | 用户唯一标识 |
| username | VARCHAR(80) | 否 | 否 | 否 | 登录用户名 |
| password_hash | VARCHAR(256) | 否 | 否 | 否 | 加密后的密码 |
| email | VARCHAR(120) | 否 | 否 | 否 | 电子邮箱 |
| role | VARCHAR(20) | 否 | 否 | 否 | admin/manager/visitor |
| real_name | VARCHAR(80) | 否 | 否 | 是 | 真实姓名 |
| phone | VARCHAR(20) | 否 | 否 | 是 | 联系电话 |
| is_active | BOOLEAN | 否 | 否 | 否 | 账户启用标识 |
| created_at | DATETIME | 否 | 否 | 否 | 注册时间 |
| last_login | DATETIME | 否 | 否 | 是 | 最近登录时间 |
（2）garden_zone表记录园林区域的配置信息，包含区域名称、类型分类、面积数值、位置描述和启用状态，详情如下表3.2所示。
表3.2 garden_zone表
|-------------|--------------|------------|------------|-------------|-----------------|
| 字段名 | 数据类型 | 主键 | 外键 | 允许空 | 说明 |
| id | INTEGER | 是 | 否 | 否 | 区域唯一标识 |
| name | VARCHAR(100) | 否 | 否 | 否 | 区域名称 |
| zone_type | VARCHAR(50) | 否 | 否 | 是 | 花园区/草坪区/树木区/水景区 |
| area_size | FLOAT | 否 | 否 | 是 | 面积（平方米） |
| location | VARCHAR(100) | 否 | 否 | 是 | 位置描述 |
| description | TEXT | 否 | 否 | 是 | 区域详细描述 |
| is_active | BOOLEAN | 否 | 否 | 否 | 区域启用标识 |
| created_at | DATETIME | 否 | 否 | 否 | 创建时间 |
（3）sensor_data_garden表记录各区域环境传感器采集的实时数据，通过zone_id关联所属区域，包含温度、湿度、土壤湿度、光照强度、降雨量、风速和空气质量指数等字段，详情如下表3.3所示。
表3.3 sensor_data_garden表
|-----------------|--------------|------------|-------------------|-------------|------------|
| 字段名 | 数据类型 | 主键 | 外键 | 允许空 | 说明 |
| id | INTEGER | 是 | 否 | 否 | 数据记录标识 |
| zone_id | INTEGER | 否 | 是(garden_zone.id) | 否 | 所属区域标识 |
| temperature | FLOAT | 否 | 否 | 是 | 温度（℃） |
| humidity | FLOAT | 否 | 否 | 是 | 空气湿度（%） |
| soil_moisture | FLOAT | 否 | 否 | 是 | 土壤湿度（%） |
| light_intensity | FLOAT | 否 | 否 | 是 | 光照强度（lux） |
| rainfall | FLOAT | 否 | 否 | 是 | 降雨量（mm） |
| wind_speed | FLOAT | 否 | 否 | 是 | 风速（m/s） |
| air_quality | FLOAT | 否 | 否 | 是 | 空气质量指数 |
| timestamp | DATETIME | 否 | 否 | 否 | 采集时间戳 |
（4）alert_garden表记录系统自动检测或手动触发的告警信息，通过zone_id关联区域，resolved_by关联操作用户，包含告警类型、严重等级、标题描述、解决状态和处理时间，详情如下表3.4所示。
表3.4 lert_garden表
|-------------|--------------|------------|-------------------|-------------|--------------------|
| 字段名 | 数据类型 | 主键 | 外键 | 允许空 | 说明 |
| id | INTEGER | 是 | 否 | 否 | 告警记录标识 |
| zone_id | INTEGER | 否 | 是(garden_zone.id) | 否 | 关联区域标识 |
| alert_type | VARCHAR(50) | 否 | 否 | 否 | 告警类型 |
| alert_level | VARCHAR(20) | 否 | 否 | 否 | warning/error/info |
| title | VARCHAR(200) | 否 | 否 | 否 | 告警标题 |
| message | TEXT | 否 | 否 | 是 | 告警详细描述 |
| is_resolved | BOOLEAN | 否 | 否 | 否 | 解决状态标识 |
| resolved_by | INTEGER | 否 | 是(user_garden.id) | 是 | 解决人标识 |
| resolved_at | DATETIME | 否 | 否 | 是 | 解决时间 |
| created_at | DATETIME | 否 | 否 | 否 | 创建时间 |
（5）plant_info_garden表记录园区植物的详细档案信息，包含植物名称、拉丁学名、分类类别、健康状态、养护指南、图片路径和种植日期等字段，详情如下表3.5所示。
表3.5 plant_info_garden表
|-----------------|--------------|------------|------------|-------------|----------------------------|
| 字段名 | 数据类型 | 主键 | 外键 | 允许空 | 说明 |
| id | INTEGER | 是 | 否 | 否 | 植物记录标识 |
| name | VARCHAR(100) | 否 | 否 | 否 | 植物名称 |
| scientific_name | VARCHAR(200) | 否 | 否 | 是 | 拉丁学名 |
| category | VARCHAR(50) | 否 | 否 | 是 | 分类类别 |
| description | TEXT | 否 | 否 | 是 | 植物详细描述 |
| care_guide | TEXT | 否 | 否 | 是 | 养护指南 |
| health_status | VARCHAR(20) | 否 | 否 | 是 | healthy/attention/critical |
| image_url | VARCHAR(500) | 否 | 否 | 是 | 植物图片路径 |
| location | VARCHAR(100) | 否 | 否 | 是 | 种植位置 |
| planted_date | DATE | 否 | 否 | 是 | 种植日期 |
| created_at | DATETIME | 否 | 否 | 否 | 记录创建时间 |
（6）irrigation_record_garden表记录灌溉操作的执行情况，通过zone_id关联区域，created_by关联操作人员，包含灌溉方式、用水量和起止时间，详情如下表3.6所示。
表3.6 irrigation_record_garden表
|--------------|--------------|------------|-------------------|-------------|-----------------------------|
| 字段名 | 数据类型 | 主键 | 外键 | 允许空 | 说明 |
| id | INTEGER | 是 | 否 | 否 | 灌溉记录标识 |
| zone_id | INTEGER | 否 | 是(garden_zone.id) | 否 | 灌溉区域标识 |
| created_by | INTEGER | 否 | 是(user_garden.id) | 是 | 操作人员标识 |
| method | VARCHAR(20) | 否 | 否 | 否 | 自动/手动 |
| water_amount | FLOAT | 否 | 否 | 是 | 用水量（升） |
| start_time | DATETIME | 否 | 否 | 否 | 灌溉开始时间 |
| end_time | DATETIME | 否 | 否 | 是 | 灌溉结束时间 |
| status | VARCHAR(20) | 否 | 否 | 否 | completed/ongoing/cancelled |
| created_at | DATETIME | 否 | 否 | 否 | 记录创建时间 |
（7）pest_detection_garden表记录病虫害图像检测的历史信息，通过plant_id关联被检测植物，存储图片路径和模型返回的检测结果，详情如下表3.7所示。
表3.7 pest_detection_garden表
|----------------------|--------------|----|-------------------------|-----|----------|
| 字段名 | 数据类型 | 主键 | 外键 | 允许空 | 说明 |
| id | INTEGER | 是 | 否 | 否 | 检测记录标识 |
| plant_id | INTEGER | 否 | 是(plant_info_garden.id) | 是 | 关联植物标识 |
| image_url | VARCHAR(500) | 否 | 否 | 否 | 上传图片路径 |
| detection_result | TEXT | 否 | 否 | 是 | 模型返回原始结果 |
| pest_type | VARCHAR(100) | 否 | 否 | 是 | 识别出的病害类型 |
| severity | VARCHAR(20) | 否 | 否 | 是 | 严重程度评级 |
| treatment_suggestion | TEXT | 否 | 否 | 是 | 防治措施建议 |
| created_at | DATETIME | 否 | 否 | 否 | 检测时间 |
（8）system_settings_garden表存储系统级运行参数，以键值对形式记录各配置项的当前取值和描述信息，详情如下表3.8所示。
表3.8 system_settings_garden表
|---------------|--------------|------------|------------|-------------|------------|
| 字段名 | 数据类型 | 主键 | 外键 | 允许空 | 说明 |
| id | INTEGER | 是 | 否 | 否 | 配置记录标识 |
| setting_key | VARCHAR(100) | 否 | 否 | 否 | 配置项名称 |
| setting_value | VARCHAR(500) | 否 | 否 | 是 | 配置项取值 |
| description | VARCHAR(200) | 否 | 否 | 是 | 配置项说明 |
4 系统实现
4.1 开发环境
本系统基于B/S架构体系，采用前后端分离的开发模式。后端以Python语言为核心，借助Flask框架搭建Web服务，数据库选用SQLite轻量级关系型数据库。前端以Bootstrap框架构建页面基础样式，搭配ECharts可视化库完成图表渲染，人工智能服务通过HTTP协议调用DeepSeek和豆包视觉模型的公开API实现。系统开发环境的详情如下表5.1所示。
表5.1 系统开发环境
|---------------------------------------------|----------------------------------|
| 硬件环境 | 软件环境 |
| CPU：Intel Core i5-12400F | 操作系统：Windows 11 专业版 |
| 内存：16GB DDR4 | 数据库：SQLite 3.39.0 |
| 硬盘：512GB SSD | Web服务器：Flask内置开发服务器（Flask 3.0.0） |
| 浏览器：Google Chrome 120.0 | |
| 开发工具：Visual Studio Code 1.85 | |
| Python版本：3.11.5 | |
| 前端框架：Bootstrap 5.3.0 / ECharts 5.4.3 | |
| AI模型：DeepSeek-chat / doubao-seed-1-6-vision | |
4.2 环境感知与数据监控模块
该模块包含数据监控面板和区域详情两个核心页面。数据监控面板（dashboard.html）在页面加载时通过AJAX分别请求/api/sensor/latest和/api/sensor/history接口。latest接口查询SensorData表中各活跃区域的最新记录，封装为区域数据列表返回；前端收到数据后遍历生成Bootstrap卡片，在每个卡片中填入温度、湿度、土壤湿度、光照强度四项数值。history接口按24小时间隔筛选数据，按小时分组聚合平均值，返回小时标签和温度、湿度、土壤湿度均值数组；前端调用ECharts的init方法初始化折线图实例并设置option对象完成渲染。区域详情页（zone_detail.html）同样在页面加载时向/api/sensor/history传递zone_id参数，后端返回该区域过去7天的逐小时聚合数据，前端渲染多系列折线图；页面顶部从模板变量latest_data中直接读取最新读数，以彩色卡片展示。如下图4.1、图4.2所示。
图4.1 数据监控面板
图4.2 区域详情界面
4.2 智能决策模块
智能决策功能以模态框形式嵌入数据监控面板、区域详情和植物详情页中，核心接口为/api/ai/irrigation、/api/ai/plant-analysis和/api/ai/pest-detection。灌溉策略生成时，前端收集当前浏览区域的zone_id，以JSON格式POST至对应接口，后端路由函数从garden_zone表和sensor_data_garden表中获取区域对象和最新传感器记录，将环境数据填入预设的系统提示词与用户提示词模板，调用DeepSeek API的chat/completions端点，返回的文本经解析后再次封装为JSON对象回传。前端在模态框中展示策略文本和环境数据快照。植物营养分析流程与灌溉策略类似，区别在于输入参数取自plant_info_garden表的字段和全局最新传感器数据，提示词模板调整为植物营养专家角色。病虫害检测在植物详情页触发，前端表单以multipart/form-data格式提交植物图片，后端安全地保存临时文件后读取为Base64编码，调用豆包视觉模型API，将模型输出的病虫害类型、严重程度和防治建议存入pest_detection_garden表，严重的自动创建告警记录，前端渲染检测结果卡片。如下图4.3、图4.4所示。
图4.3 灌溉策略界面
图4.4 智能决策界面
4.3 可视化运维与大屏模块
告警中心页面（alerts.html）在main蓝图下渲染，模板接收Alert查询结果列表，按表格形式输出每条告警的标题、级别、时间等信息。每条记录附"解决"按钮，绑定的JavaScript函数resolveAlert发送POST至/admin/alert/<alert_id>/resolve，由于该路由标记了csrf.exempt，请求无需携带CSRF令牌。后端将被选告警的is_resolved置为真、记录操作人和时间后提交数据库，前端收到成功响应后刷新页面。一键解决功能遍历所有未解决告警，依次调用同一接口，全部完成后再刷新。
经理端监测指挥舱（manager/dashboard.html）是一个独立的大屏页面，核心数据源为/api/dashboard/manager接口。后端该路由执行综合性数据聚合：统计活跃区域数、植物总数和未解决告警数；循环各区域获取最新传感器值，估算植株数量并组装土壤质量评级；按小时分组查询过去24小时温度、湿度、土壤湿度的平均值作为趋势数据；同时返回最近10条未解决告警和植物分类统计。前端页面加载后通过jQuery的get方法请求该接口，收到数据后更新页面DOM，将趋势数组传给ECharts图表，将告警列表填充至滚动表格，并利用定时器每6秒刷新灌溉阀门数量等动态数字。管理端综合监控平台（admin/dashboard_bigscreen.html）的数据来源为/api/dashboard/admin，后端统计用户角色分布、植物类别分布、各区域气象数据和模拟的经纬度坐标，前端左侧渲染角色饼图，中间地图区域基于百度地图API标注区域位置，右侧列表展示植物健康状态，还集成了摄像头实时视频流。主界面如下图4.5所示。
图4.5 可视化运维与大屏界面
4.4 游客互动模块
植物识别页（identify.html）支持点击或拖拽上传图片，前端使用FileReader读取文件生成预览，提交时将文件放入FormData发送至/visitor/identify。后端先校验文件类型，存储临时文件后调用AIService的identify_plant方法，方法内部读取图片base64编码并组装多模态消息调用豆包视觉模型；返回的文本经正则提取植物名称，再在PlantInfo表中模糊匹配。前端将识别名称、详细描述和匹配的养护信息渲染在结果区。游览导推荐页（guide.html）提供兴趣标签和时间选项的表单，提交时以JSON格式发送至/visitor/guide/recommend，后端获取所有活跃区域和部分植物列表，打包为提示词调用DeepSeek API生成路线文本，前端在卡片中展示。环保教育页（education.html）通过/visitor/education/tips和/visitor/education/quiz接口获取内容，后端均调用AI服务的对应方法，前者返回预生成或AI生成的环保小贴士，后者根据选定的主题生成JSON格式选择题数组，前端解析后渲染为表单控件。意见反馈页（feedback.html）纯前端收集输入信息，POST至/visitor/feedback，后端简单返回成功。如下图4.6所示。
图4.6 游客互动界面
4.5 系统管理模块
管理后台仪表盘（admin/dashboard.html）在页面渲染时通过视图函数直接查询User、GardenZone、Alert、SensorData等表，统计各维度数量，连同最近告警和最近用户列表一并传入模板。用户管理页（admin/users.html）展示所有用户记录，每行的"禁用/启用"按钮通过/admin/user/<id>/toggle发送POST，后端切换is_active字段后返回新状态，前端刷新页面。区域管理采用前后端表单交互：添加和编辑页共享同一模板（admin/zone_form.html），提交时分别向/admin/zone/add和/admin/zone/<id>/edit发送POST，后端解析表单字段构建或更新GardenZone对象，成功后重定向到区域列表页。告警管理（admin/alerts.html）与前台告警中心共用了main蓝图下的告警页面，仅权限装饰器不同。灌溉管理页（admin/irrigation.html）在模态框中提供区域和方式选择，提交后向/api/irrigation/create发送POST，后端创建IrrigationRecord记录。传感器数据管理（admin/sensor_data.html）以分页表格列出所有传感器读数，支持点击"生成模拟数据"按钮调用/api/sensor/generate触发SensorSimulator执行。系统设置页（admin/settings.html）包含四个分区的表单，分别通过/admin/settings/basic、/ai、/thresholds、/notifications路由保存配置，后端更新SystemSettings表的对应键值，前端通过JavaScript的fetch发送FormData并根据响应弹出提示。数据清理与导出功能由/admin/data/cleanup和/admin/data/export接口提供，前者按天数删除过期数据，后者按类型导出JSON并提供下载。如下图4.7、图4.8、图4.9所示。
图4.7 管理员系统管理界面