基于SpringCloud微信小程序AI的智能农业微服务农产品质检系统这个题目在计算机毕业设计里确实很火。它把微服务架构、小程序前端和AI大模型三条线串到了一起既能展示后端架构能力也能体现AI应用思路。很多人最开始担心的问题不是功能怎么做而是这个题到底难不难、答辩能不能讲清楚。我的判断是系统本身不算特别难难的是把微服务为什么拆分、AI接入什么环节、小程序如何和后端服务联动这三个问题讲明白。这篇文章按实际开发顺序从架构拆分、组件选型、小程序设计、AI接入、数据库设计、启动排错到论文答辩完整拆一遍。1. 这个毕设题目到底在做什么适合哪些人做1.1 系统解决的现实问题农产品从种植、采摘到流通质检是不可少的环节。传统方式是纸质表单、Excel登记、电话通知数据分散在多个部门查询麻烦。这个系统的核心目标是把质检流程线上化农户或企业在小程序上提交质检申请检测人员录入样品和检测指标系统自动汇总检测数据并生成质检报告管理者可以查看批次状态和统计报表用户端可以直接查看报告。AI大模型在中间承担辅助分析工作比如把报告翻译成普通人能看懂的结论、自动生成不合格预警提示、回答常见的质检咨询。这个定位很关键。很多同学拿到题目后会把注意力放在“微服务多拆几个服务”上结果业务功能反而不完整。我的建议是先想清楚质检流程再套技术。1.2 哪些学生适合选这个题不是只有技术大牛才能做。适合三类人有意向后端方向发展接触过Spring Boot想再进一步学习SpringCloud微服务。想体现“全栈”能力愿意自己搭小程序页面。想蹭AI热点但暂时没有能力训练自己的模型希望接入大模型API完成AI功能。如果你完全没写过Spring Boot接口直接上手这个题目会有点吃力。建议先花三天做一个单体的Spring Boot增删改查小项目把Controller、Service、Mapper、MyBatis-Plus跑通再进入这个毕设。1.3 开发前需要具备的技术基础需要具备以下基础Java基础扎实会写Spring Boot接口知道依赖注入和MVC分层。了解MySQL、MyBatis-Plus能设计简单的业务表。了解Nacos的基本概念知道注册中心和配置中心是干什么用的。小程序端至少会写页面、调用wx.request。不需要会训练模型。现在国内大模型API已经很成熟只需要会用HTTP请求、处理JSON返回就能把AI功能接进去。1.4 真正需要想清楚的三个难点这个题目真正难的地方不是赶潮流而是三个点服务拆分的粒度。拆得太多开发和演示都容易乱拆太少又体现不了微服务架构。AI功能必须落在真实环节不能为了AI而AI。质检系统最需要的是报告解读、异常提示、咨询问答不是“用AI生成整个报告”。微服务项目在本机启动时资源占用和维护复杂度需要提前规划。低配电脑跑六七个服务边开发边卡体验很差。2. SpringCloud微服务架构怎么拆组件选型和启动顺序2.1 服务拆分边界必须按业务域来很多第一次做微服务的同学习惯按页面拆比如“登录服务”“报告服务”“首页服务”这个思路不建议。微服务一定要按业务域拆尽量减少跨服务的数据库操作。以农产品质检系统为例建议拆成这几个服务服务名称职责关键接口gateway所有请求的统一入口路由、鉴权、日志无业务接口system用户、角色、权限微信登录、用户信息product农产品档案、种植/产地信息添加产品、产品列表quality质检批次、检测指标、质检报告提交检测、录入指标、生成报告ai-service大模型调用、报告摘要、智能问答报告分析、问答file图片、报告文件上传下载上传、下载如果机器配置一般可以把 file 归到 quality 里ai-service 也可以在 quality 内部做成独立模块不一定非要单独部署。服务数量控制在 4 到 5 个对毕设项目来说已经能充分展示微服务能力。为什么按业务域拆因为质检流程里的用户、产品、批次、指标、报告各自的数据边界相对清晰。拆开放到不同服务才能体现Nacos注册、OpenFeign调用、Gateway网关这些技术在真实场景里的作用。2.2 组件选型建议别把所有组件都装上SpringCloud生态组件很多不需要全用上。毕设项目最合适的组合是Nacos既做注册中心也做配置中心。Spring Cloud Gateway统一网关负责路由转发和跨域处理。OpenFeign微服务之间远程调用。MySQL业务数据存储。Redis缓存登录token和热点数据。MinIO或本地磁盘存储存质检报告图片、上传的样品照片。关于分布式事务毕设里尽量不用Seata。因为质检流程大部分是前后端交互不是跨库强一致。如果必须跨服务更新数据可以在代码里用“先保存主表再调用子服务失败时做补偿”的最终一致性思路答辩的时候能把方案讲清楚更重要。2.3 版本组合怎么定为什么不要追新版本建议用稳定组合。经典方案是JDK 8 或 JDK 11Spring Boot 2.7.xSpring Cloud 2021.0.xSpring Cloud Alibaba 2021.0.x如果想用新版本JDK 17Spring Boot 3.2.xSpring Cloud 2023.0.xSpring Cloud Alibaba 2023.0.x注意Spring Boot 3 要求JDK 17以上不要选错。网上很多教程里的版本对不上往往是这个原因。注意不要直接照抄网上最新版本号。找一个你本地能跑通的组合然后锁死依赖。2.4 本地启动顺序和验证方法微服务项目不是所有服务一起打包、一起启动。稳妥的启动顺序是启动MySQL和Redis。启动Nacos。确认Nacos控制台能打开默认账号nacos默认密码也是nacos。启动system服务。观察日志里出现“registered to nacos”且没有报错。启动quality服务。同样观察注册状态。启动ai-service。启动gateway。打开Nacos控制台确认服务列表里有预期服务。最后启动小程序开发者工具把请求地址指到gateway。每启动一个服务就刷新一次Nacos服务列表确认服务真正注册成功再启动下一个。不要一次性全部启动否则日志混在一起出了问题很难定位。3. 微信小程序端怎么设计如何和微服务后端衔接3.1 角色功能划分别让质检员在小程序里录数据农产品质检系统有几种角色农户/企业用户、质检人员、管理人员。最合理的方式是小程序端给普通用户和农户用。核心功能包括微信登录、提交质检申报、查看检测进度、查看报告、AI质检问答。管理后台用Web页面更适合因为质检人员需要录入大量指标表格操作在小程序里非常别扭。如果只想做一个端那就做成“小程序管理端Web”的组合而不是让质检员在小程序里录数据。小程序端页面可以控制在6个以内首页、产品列表、提交申报、申报记录、报告详情、我的问答。页面太多开发和演示压力都会变大。3.2 微信登录与统一鉴权小程序登录不能用传统的用户名密码而是通过wx.login获取临时code再由后端调用微信接口换取openid。这个流程可以简化小程序调用wx.login获取code。小程序把code发送给gateway路由到system服务。system服务调用微信接口用code换openid。system服务查找或创建用户生成JWT token返回给小程序。小程序后续请求在请求头里带token。Gateway可以写一个全局过滤器对于需要鉴权的路径统一解析token解析失败直接返回401。这样各个业务服务就不需要重复写鉴权逻辑。3.3 请求地址必须走网关小程序不能直接访问Nacos也不能绕过网关直接打后端服务。所有请求都走gateway统一地址# 开发环境 http://localhost:8080/api/quality/report/list小程序端对应请求wx.request({ url: http://localhost:8080/api/quality/report/list, method: GET, header: { Authorization: Bearer token }, success(res) { console.log(res.data) } })Gateway需要配置路由规则和前缀裁剪。比如把/api/quality/**转发到quality服务并去掉/api前缀。3.4 小程序开发阶段最常见的三个问题开发阶段最常见的问题有三个域名校验。开发时可以在小程序开发者工具的“详情—本地设置”里勾选“不校验合法域名”否则无法请求localhost。HTTPS要求。正式发布必须使用HTTPS且需要在小程序后台配置request合法域名。Bearer token传递。小程序请求头写法大小写要一致服务端解析时要兼容否则会出现“登录成功但接口全部401”的情况。4. AI大模型在农产品质检里怎么用才不会变成摆设4.1 可以落地的四个AI功能AI大模型不是必须挂在所有环节。在质检场景里真正有意义的AI应用有这几类质检报告摘要。系统生成完整检测数据后让大模型把一堆数值转成一段普通人能看懂的结论。异常提示与原因建议。当检测值接近或超过标准值时大模型结合上下文给出解释和合规建议。智能问答助手。用户在小程序里提问“哪些水果容易有农残”“检测报告怎么看”大模型基于提示词给出回答。OCR识别。如果有纸质检测单可以调用带视觉能力的模型把文字提取出来再自动填充。不要做的是把大模型接入到质检结果判定主流程里。质检结果应该始终以检测数据和标准值计算为准AI只做辅助解读。这样既稳定也能避免答辩时被问“AI准确率不高怎么办”。4.2 大模型接入方式和关键参数目前国内主流大模型API大多兼容OpenAI接口Java服务里可以直接用RestTemplate或WebClient请求。一个比较通用的调用思路// 伪代码只演示调用思路 HttpHeaders headers new HttpHeaders(); headers.setBearerAuth(apiKey); headers.setContentType(MediaType.APPLICATION_JSON); JSONObject req new JSONObject(); req.put(model, modelName); req.put(messages, messages); ResponseEntityString resp restTemplate.postForEntity( apiUrl, new HttpEntity(req.toString(), headers), String.class);注意几个工程化细节API Key放在配置文件或环境变量不要硬编码在代码里。设置合理的超时时间默认10秒左右超时就降级。对相同数据的问答设置缓存避免重复调用消耗配额。调用日志要记录model名、请求长度、返回状态和耗时方便排查。4.3 提示词怎么设计输出才稳定如果你要做报告解读用结构化提示词更稳定你是农产品质检助手。 请根据以下数据给出简要质检解读 检测批次号BJ2025001 产品名称苹果 检测项毒死蜱 标准值≤0.05mg/kg 实测值0.02mg/kg 结论合格 请用20字内解释依据。提示词要写清楚三个要素角色、输入数据、输出格式。不要给大模型太多自由发挥空间否则演示时输出不稳定。4.4 降级策略演示不翻车AI服务可能因为网络、配额、超时等原因挂掉。建议在ai-service层做降级当大模型调用失败时返回系统根据规则生成的固定结论模板消费者端看到的效果是一致的。注意演示时一定要准备降级方案。答辩现场网络不稳定AI接口超时是常见的翻车点。5. 数据库设计和核心数据流5.1 核心表结构和关系这个系统的表不用设计得特别多围绕质检流程来。核心表包括表名说明关键字段sys_user用户表id, openid, username, phone, role_typeproduct_info农产品档案表id, user_id, product_name, origin, categoryinspection_batch质检批次表id, user_id, product_id, batch_no, status, create_timeinspection_item检测指标表id, batch_id, item_name, standard_value, actual_value, unit, is_qualifiedinspection_report质检报告表id, batch_id, report_no, conclusion, ai_summary, create_timeai_analysis_logAI调用日志表id, batch_id, model_name, prompt, response, status, cost_ms最核心的一条关系链是用户 - 农产品 - 质检批次 - 检测指标 - 质检报告。质检报告由批次和指标聚合生成。5.2 一条完整的质检业务链路一条完整的业务链路用户在小程序端添加农产品提交质检申报创建inspection_batch状态为待检测。质检人员登录后端看到待检测批次录入多个检测指标。录入完成后保存到inspection_item。系统判断所有指标都录入且都有判定结果自动生成inspection_report状态为已出报告。报告生成后调用ai-service生成AI摘要写入ai_summary字段。用户在小程序端查看报告也可以提问ai-service返回基于大模型的解答。这条链路里只有AI摘要和问答是异步或可降级的其他环节必须保证数据一致性。5.3 Redis在微服务里的使用边界Redis在微服务里主要负责三类登录token会话。热点数据比如常用检测项的标准值列表。AI问答结果缓存相同问题不重复请求大模型。不需要把质检报告缓存太久因为报告一旦生成基本不变数据库查询效率足够。6. 后端微服务模块从零开发流程6.1 推荐的开发顺序不要一次搭六个服务第一次做SpringCloud毕设不要一开始就搭六个服务。我建议按这个顺序开发创建Maven聚合工程父pom里统一定义依赖。先写system服务完成登录和用户表。写gateway把请求转发到system验证整个链路。写quality服务实现质检申报、指标录入、报告生成。写ai-service调用大模型。最后接小程序端。这样每一个阶段都有可运行结果调试压力会小很多。6.2 最简接口示例和工程规范假设quality服务里查询报告列表RestController RequestMapping(/api/quality/report) public class ReportController { Resource private ReportService reportService; GetMapping(/list) public ResultListReportVO list(RequestParam Long userId) { return Result.ok(reportService.listByUser(userId)); } }接口本身并不复杂。关键是要在前面加一层gateway鉴权让小程序携带的token能统一校验。工程规范上我建议在两个地方统一风格返回值统一用ResultT包含code、message、data三个字段。所有跨服务传输对象放在common模块里避免A服务里定义一份、B服务里又复制一份。6.3 微服务调用最常见的坑微服务之间调用最常踩的坑包括Feign路径和Controller类上路径拼接错误。比如Controller写了一个/api/qualityFeign client里也写了一遍gateway又做前缀裁剪最后请求路径重复。服务名大小写。Nacos注册的服务名默认是大写Feign调用时要保持一致。序列化问题。两个服务之间传DTO的时候时间格式、字段名为null的情况容易不一致。我习惯在common模块里放统一的Result对象和BaseDTO避免各服务各自为政。7. 论文、演示和答辩怎么准备7.1 论文结构建议论文不要按流水账写要按“提出问题-分析问题-解决问题-验证结果”的思路。常见结构绪论背景、意义、国内外现状。关键技术SpringCloud、Nacos、微信小程序、大模型API。需求分析角色划分、功能性需求、非功能性需求。系统设计架构设计、服务拆分、数据库设计、AI模块设计。系统实现每个核心功能怎么实现配界面截图、核心代码、运行效果。系统测试功能测试、接口测试、性能测试、AI测试。总结与展望创新点、不足、改进方向。重点章节是系统设计和系统实现比例至少要占全文一半。7.2 答辩必问的五个问题答辩时老师最可能问的问题为什么用微服务规模不大为什么不用单体 回答思路项目想体现分布式架构设计能力质检流程包含用户端、管理端、文件、AI分析多个独立业务域方便独立扩展将来接入更多农业服务时可以按服务扩容。不要回避“单体也能做”但要强调选择微服务的目的是展示架构功底。微服务之间如何通信 回答思路同步用OpenFeign异步用消息队列本项目核心链路用OpenFeign没有引入消息队列因为当前业务没有强异步需求。分布式事务怎么处理 回答思路本项目尽量保持单服务本地事务跨服务时用最终一致思路如果老师追问可以说“实际生产会引入Seata或消息队列但当前业务没有那么强的强一致要求”。AI准确率如何保证 回答思路AI只做辅助解读质检结论还是以规则计算为准提示词做了结构化约束AI结果有缓存和降级策略。六个服务一起部署内存够吗 回答思路本地演示时按需启动不需要同时开所有服务每个服务JVM可以设置-Xmx256m实际占用在1.5G左右。这个回答很现实。7.3 演示流程怎么设计演示环节不要一上来就展示代码。建议按故事线小程序端登录。用户创建一个农产品并提交质检申报。切换管理端质检人员录入检测指标。生成报告展示AI摘要。回到小程序展示报告和AI问答。每一步停留时间不超过一分钟重点展示状态变化和结果输出。提前准备一组固定的测试数据和账号不要在现场临时填表。8. 部署排错和资源控制经验8.1 启动排错顺序遇到起不来的情况按照下面顺序排查看Nacos控制台服务是否注册成功。看服务日志有没有“register”或“error”关键字。看数据库连接数据库账号、密码、url时区配置。看Redis连接密码是否配对。看端口Gateway 8080是否被占用。不要一加微服务就怀疑微服务本身很多问题出在基础环境。比如时区配置不对数据库连接就会一直报错Redis没设置密码但客户端带了密码也会导致登录失败。8.2 小程序连接后端报错怎么查如果小程序请求后端不成功优先检查是不是开发者工具没勾选“不校验合法域名”。是不是请求地址写到了具体服务端口而不是gateway。是不是token过期或者格式不对。是不是接口返回了JSON但前端解析时少处理了一个字段。小程序端的报错往往会直接显示在控制台。先看控制台里的具体报错信息再决定是改前端还是改后端。8.3 大模型调用报错怎么查先看日志里的状态码。常见情况401/403API Key错误或权限不足。429触发了调用频率限制。500/超时模型服务暂时不可用或网络波动。如果频率不够可以在ai-service里做简单的本地缓存或者在提示词里减少输入长度降低调用成本。8.4 低配机器怎么跑微服务低配电脑跑微服务确实容易卡。两条路子控制JVM内存。在启动脚本里给每个服务限制内存java -Xmx256m -jar quality-service.jar。本地调试时只启动需要的服务不要为了演示把六个服务同时跑起来。如果演示机器只有8G内存建议展示前把非必须服务关闭保证 gateway、system、quality、ai-service 四个服务能稳定运行就够了。整体来看这个毕设项目的本质不是追求服务数量多而是把农产品质检这条业务链路做完整同时体现微服务、小程序、AI三个技术关键词。能跑通是第一步能在答辩时把理由讲明白才是拿高分的关键。我个人更建议先跑通最小闭环再逐步加模块和AI功能不要一开始就把结构做得太重。 
长河君 · 2026/9/7 15:24:55 · 阅读 1.2k SpringCloud+小程序+AI：智能农业农产品质检系统全解析
基于SpringCloud微信小程序AI的智能农业微服务农产品质检系统这个题目在计算机毕业设计里确实很火。它把微服务架构、小程序前端和AI大模型三条线串到了一起既能展示后端架构能力也能体现AI应用思路。很多人最开始担心的问题不是功能怎么做而是这个题到底难不难、答辩能不能讲清楚。我的判断是系统本身不算特别难难的是把微服务为什么拆分、AI接入什么环节、小程序如何和后端服务联动这三个问题讲明白。这篇文章按实际开发顺序从架构拆分、组件选型、小程序设计、AI接入、数据库设计、启动排错到论文答辩完整拆一遍。1. 这个毕设题目到底在做什么适合哪些人做1.1 系统解决的现实问题农产品从种植、采摘到流通质检是不可少的环节。传统方式是纸质表单、Excel登记、电话通知数据分散在多个部门查询麻烦。这个系统的核心目标是把质检流程线上化农户或企业在小程序上提交质检申请检测人员录入样品和检测指标系统自动汇总检测数据并生成质检报告管理者可以查看批次状态和统计报表用户端可以直接查看报告。AI大模型在中间承担辅助分析工作比如把报告翻译成普通人能看懂的结论、自动生成不合格预警提示、回答常见的质检咨询。这个定位很关键。很多同学拿到题目后会把注意力放在“微服务多拆几个服务”上结果业务功能反而不完整。我的建议是先想清楚质检流程再套技术。1.2 哪些学生适合选这个题不是只有技术大牛才能做。适合三类人有意向后端方向发展接触过Spring Boot想再进一步学习SpringCloud微服务。想体现“全栈”能力愿意自己搭小程序页面。想蹭AI热点但暂时没有能力训练自己的模型希望接入大模型API完成AI功能。如果你完全没写过Spring Boot接口直接上手这个题目会有点吃力。建议先花三天做一个单体的Spring Boot增删改查小项目把Controller、Service、Mapper、MyBatis-Plus跑通再进入这个毕设。1.3 开发前需要具备的技术基础需要具备以下基础Java基础扎实会写Spring Boot接口知道依赖注入和MVC分层。了解MySQL、MyBatis-Plus能设计简单的业务表。了解Nacos的基本概念知道注册中心和配置中心是干什么用的。小程序端至少会写页面、调用wx.request。不需要会训练模型。现在国内大模型API已经很成熟只需要会用HTTP请求、处理JSON返回就能把AI功能接进去。1.4 真正需要想清楚的三个难点这个题目真正难的地方不是赶潮流而是三个点服务拆分的粒度。拆得太多开发和演示都容易乱拆太少又体现不了微服务架构。AI功能必须落在真实环节不能为了AI而AI。质检系统最需要的是报告解读、异常提示、咨询问答不是“用AI生成整个报告”。微服务项目在本机启动时资源占用和维护复杂度需要提前规划。低配电脑跑六七个服务边开发边卡体验很差。2. SpringCloud微服务架构怎么拆组件选型和启动顺序2.1 服务拆分边界必须按业务域来很多第一次做微服务的同学习惯按页面拆比如“登录服务”“报告服务”“首页服务”这个思路不建议。微服务一定要按业务域拆尽量减少跨服务的数据库操作。以农产品质检系统为例建议拆成这几个服务服务名称职责关键接口gateway所有请求的统一入口路由、鉴权、日志无业务接口system用户、角色、权限微信登录、用户信息product农产品档案、种植/产地信息添加产品、产品列表quality质检批次、检测指标、质检报告提交检测、录入指标、生成报告ai-service大模型调用、报告摘要、智能问答报告分析、问答file图片、报告文件上传下载上传、下载如果机器配置一般可以把 file 归到 quality 里ai-service 也可以在 quality 内部做成独立模块不一定非要单独部署。服务数量控制在 4 到 5 个对毕设项目来说已经能充分展示微服务能力。为什么按业务域拆因为质检流程里的用户、产品、批次、指标、报告各自的数据边界相对清晰。拆开放到不同服务才能体现Nacos注册、OpenFeign调用、Gateway网关这些技术在真实场景里的作用。2.2 组件选型建议别把所有组件都装上SpringCloud生态组件很多不需要全用上。毕设项目最合适的组合是Nacos既做注册中心也做配置中心。Spring Cloud Gateway统一网关负责路由转发和跨域处理。OpenFeign微服务之间远程调用。MySQL业务数据存储。Redis缓存登录token和热点数据。MinIO或本地磁盘存储存质检报告图片、上传的样品照片。关于分布式事务毕设里尽量不用Seata。因为质检流程大部分是前后端交互不是跨库强一致。如果必须跨服务更新数据可以在代码里用“先保存主表再调用子服务失败时做补偿”的最终一致性思路答辩的时候能把方案讲清楚更重要。2.3 版本组合怎么定为什么不要追新版本建议用稳定组合。经典方案是JDK 8 或 JDK 11Spring Boot 2.7.xSpring Cloud 2021.0.xSpring Cloud Alibaba 2021.0.x如果想用新版本JDK 17Spring Boot 3.2.xSpring Cloud 2023.0.xSpring Cloud Alibaba 2023.0.x注意Spring Boot 3 要求JDK 17以上不要选错。网上很多教程里的版本对不上往往是这个原因。注意不要直接照抄网上最新版本号。找一个你本地能跑通的组合然后锁死依赖。2.4 本地启动顺序和验证方法微服务项目不是所有服务一起打包、一起启动。稳妥的启动顺序是启动MySQL和Redis。启动Nacos。确认Nacos控制台能打开默认账号nacos默认密码也是nacos。启动system服务。观察日志里出现“registered to nacos”且没有报错。启动quality服务。同样观察注册状态。启动ai-service。启动gateway。打开Nacos控制台确认服务列表里有预期服务。最后启动小程序开发者工具把请求地址指到gateway。每启动一个服务就刷新一次Nacos服务列表确认服务真正注册成功再启动下一个。不要一次性全部启动否则日志混在一起出了问题很难定位。3. 微信小程序端怎么设计如何和微服务后端衔接3.1 角色功能划分别让质检员在小程序里录数据农产品质检系统有几种角色农户/企业用户、质检人员、管理人员。最合理的方式是小程序端给普通用户和农户用。核心功能包括微信登录、提交质检申报、查看检测进度、查看报告、AI质检问答。管理后台用Web页面更适合因为质检人员需要录入大量指标表格操作在小程序里非常别扭。如果只想做一个端那就做成“小程序管理端Web”的组合而不是让质检员在小程序里录数据。小程序端页面可以控制在6个以内首页、产品列表、提交申报、申报记录、报告详情、我的问答。页面太多开发和演示压力都会变大。3.2 微信登录与统一鉴权小程序登录不能用传统的用户名密码而是通过wx.login获取临时code再由后端调用微信接口换取openid。这个流程可以简化小程序调用wx.login获取code。小程序把code发送给gateway路由到system服务。system服务调用微信接口用code换openid。system服务查找或创建用户生成JWT token返回给小程序。小程序后续请求在请求头里带token。Gateway可以写一个全局过滤器对于需要鉴权的路径统一解析token解析失败直接返回401。这样各个业务服务就不需要重复写鉴权逻辑。3.3 请求地址必须走网关小程序不能直接访问Nacos也不能绕过网关直接打后端服务。所有请求都走gateway统一地址# 开发环境 http://localhost:8080/api/quality/report/list小程序端对应请求wx.request({ url: http://localhost:8080/api/quality/report/list, method: GET, header: { Authorization: Bearer token }, success(res) { console.log(res.data) } })Gateway需要配置路由规则和前缀裁剪。比如把/api/quality/**转发到quality服务并去掉/api前缀。3.4 小程序开发阶段最常见的三个问题开发阶段最常见的问题有三个域名校验。开发时可以在小程序开发者工具的“详情—本地设置”里勾选“不校验合法域名”否则无法请求localhost。HTTPS要求。正式发布必须使用HTTPS且需要在小程序后台配置request合法域名。Bearer token传递。小程序请求头写法大小写要一致服务端解析时要兼容否则会出现“登录成功但接口全部401”的情况。4. AI大模型在农产品质检里怎么用才不会变成摆设4.1 可以落地的四个AI功能AI大模型不是必须挂在所有环节。在质检场景里真正有意义的AI应用有这几类质检报告摘要。系统生成完整检测数据后让大模型把一堆数值转成一段普通人能看懂的结论。异常提示与原因建议。当检测值接近或超过标准值时大模型结合上下文给出解释和合规建议。智能问答助手。用户在小程序里提问“哪些水果容易有农残”“检测报告怎么看”大模型基于提示词给出回答。OCR识别。如果有纸质检测单可以调用带视觉能力的模型把文字提取出来再自动填充。不要做的是把大模型接入到质检结果判定主流程里。质检结果应该始终以检测数据和标准值计算为准AI只做辅助解读。这样既稳定也能避免答辩时被问“AI准确率不高怎么办”。4.2 大模型接入方式和关键参数目前国内主流大模型API大多兼容OpenAI接口Java服务里可以直接用RestTemplate或WebClient请求。一个比较通用的调用思路// 伪代码只演示调用思路 HttpHeaders headers new HttpHeaders(); headers.setBearerAuth(apiKey); headers.setContentType(MediaType.APPLICATION_JSON); JSONObject req new JSONObject(); req.put(model, modelName); req.put(messages, messages); ResponseEntityString resp restTemplate.postForEntity( apiUrl, new HttpEntity(req.toString(), headers), String.class);注意几个工程化细节API Key放在配置文件或环境变量不要硬编码在代码里。设置合理的超时时间默认10秒左右超时就降级。对相同数据的问答设置缓存避免重复调用消耗配额。调用日志要记录model名、请求长度、返回状态和耗时方便排查。4.3 提示词怎么设计输出才稳定如果你要做报告解读用结构化提示词更稳定你是农产品质检助手。 请根据以下数据给出简要质检解读 检测批次号BJ2025001 产品名称苹果 检测项毒死蜱 标准值≤0.05mg/kg 实测值0.02mg/kg 结论合格 请用20字内解释依据。提示词要写清楚三个要素角色、输入数据、输出格式。不要给大模型太多自由发挥空间否则演示时输出不稳定。4.4 降级策略演示不翻车AI服务可能因为网络、配额、超时等原因挂掉。建议在ai-service层做降级当大模型调用失败时返回系统根据规则生成的固定结论模板消费者端看到的效果是一致的。注意演示时一定要准备降级方案。答辩现场网络不稳定AI接口超时是常见的翻车点。5. 数据库设计和核心数据流5.1 核心表结构和关系这个系统的表不用设计得特别多围绕质检流程来。核心表包括表名说明关键字段sys_user用户表id, openid, username, phone, role_typeproduct_info农产品档案表id, user_id, product_name, origin, categoryinspection_batch质检批次表id, user_id, product_id, batch_no, status, create_timeinspection_item检测指标表id, batch_id, item_name, standard_value, actual_value, unit, is_qualifiedinspection_report质检报告表id, batch_id, report_no, conclusion, ai_summary, create_timeai_analysis_logAI调用日志表id, batch_id, model_name, prompt, response, status, cost_ms最核心的一条关系链是用户 - 农产品 - 质检批次 - 检测指标 - 质检报告。质检报告由批次和指标聚合生成。5.2 一条完整的质检业务链路一条完整的业务链路用户在小程序端添加农产品提交质检申报创建inspection_batch状态为待检测。质检人员登录后端看到待检测批次录入多个检测指标。录入完成后保存到inspection_item。系统判断所有指标都录入且都有判定结果自动生成inspection_report状态为已出报告。报告生成后调用ai-service生成AI摘要写入ai_summary字段。用户在小程序端查看报告也可以提问ai-service返回基于大模型的解答。这条链路里只有AI摘要和问答是异步或可降级的其他环节必须保证数据一致性。5.3 Redis在微服务里的使用边界Redis在微服务里主要负责三类登录token会话。热点数据比如常用检测项的标准值列表。AI问答结果缓存相同问题不重复请求大模型。不需要把质检报告缓存太久因为报告一旦生成基本不变数据库查询效率足够。6. 后端微服务模块从零开发流程6.1 推荐的开发顺序不要一次搭六个服务第一次做SpringCloud毕设不要一开始就搭六个服务。我建议按这个顺序开发创建Maven聚合工程父pom里统一定义依赖。先写system服务完成登录和用户表。写gateway把请求转发到system验证整个链路。写quality服务实现质检申报、指标录入、报告生成。写ai-service调用大模型。最后接小程序端。这样每一个阶段都有可运行结果调试压力会小很多。6.2 最简接口示例和工程规范假设quality服务里查询报告列表RestController RequestMapping(/api/quality/report) public class ReportController { Resource private ReportService reportService; GetMapping(/list) public ResultListReportVO list(RequestParam Long userId) { return Result.ok(reportService.listByUser(userId)); } }接口本身并不复杂。关键是要在前面加一层gateway鉴权让小程序携带的token能统一校验。工程规范上我建议在两个地方统一风格返回值统一用ResultT包含code、message、data三个字段。所有跨服务传输对象放在common模块里避免A服务里定义一份、B服务里又复制一份。6.3 微服务调用最常见的坑微服务之间调用最常踩的坑包括Feign路径和Controller类上路径拼接错误。比如Controller写了一个/api/qualityFeign client里也写了一遍gateway又做前缀裁剪最后请求路径重复。服务名大小写。Nacos注册的服务名默认是大写Feign调用时要保持一致。序列化问题。两个服务之间传DTO的时候时间格式、字段名为null的情况容易不一致。我习惯在common模块里放统一的Result对象和BaseDTO避免各服务各自为政。7. 论文、演示和答辩怎么准备7.1 论文结构建议论文不要按流水账写要按“提出问题-分析问题-解决问题-验证结果”的思路。常见结构绪论背景、意义、国内外现状。关键技术SpringCloud、Nacos、微信小程序、大模型API。需求分析角色划分、功能性需求、非功能性需求。系统设计架构设计、服务拆分、数据库设计、AI模块设计。系统实现每个核心功能怎么实现配界面截图、核心代码、运行效果。系统测试功能测试、接口测试、性能测试、AI测试。总结与展望创新点、不足、改进方向。重点章节是系统设计和系统实现比例至少要占全文一半。7.2 答辩必问的五个问题答辩时老师最可能问的问题为什么用微服务规模不大为什么不用单体 回答思路项目想体现分布式架构设计能力质检流程包含用户端、管理端、文件、AI分析多个独立业务域方便独立扩展将来接入更多农业服务时可以按服务扩容。不要回避“单体也能做”但要强调选择微服务的目的是展示架构功底。微服务之间如何通信 回答思路同步用OpenFeign异步用消息队列本项目核心链路用OpenFeign没有引入消息队列因为当前业务没有强异步需求。分布式事务怎么处理 回答思路本项目尽量保持单服务本地事务跨服务时用最终一致思路如果老师追问可以说“实际生产会引入Seata或消息队列但当前业务没有那么强的强一致要求”。AI准确率如何保证 回答思路AI只做辅助解读质检结论还是以规则计算为准提示词做了结构化约束AI结果有缓存和降级策略。六个服务一起部署内存够吗 回答思路本地演示时按需启动不需要同时开所有服务每个服务JVM可以设置-Xmx256m实际占用在1.5G左右。这个回答很现实。7.3 演示流程怎么设计演示环节不要一上来就展示代码。建议按故事线小程序端登录。用户创建一个农产品并提交质检申报。切换管理端质检人员录入检测指标。生成报告展示AI摘要。回到小程序展示报告和AI问答。每一步停留时间不超过一分钟重点展示状态变化和结果输出。提前准备一组固定的测试数据和账号不要在现场临时填表。8. 部署排错和资源控制经验8.1 启动排错顺序遇到起不来的情况按照下面顺序排查看Nacos控制台服务是否注册成功。看服务日志有没有“register”或“error”关键字。看数据库连接数据库账号、密码、url时区配置。看Redis连接密码是否配对。看端口Gateway 8080是否被占用。不要一加微服务就怀疑微服务本身很多问题出在基础环境。比如时区配置不对数据库连接就会一直报错Redis没设置密码但客户端带了密码也会导致登录失败。8.2 小程序连接后端报错怎么查如果小程序请求后端不成功优先检查是不是开发者工具没勾选“不校验合法域名”。是不是请求地址写到了具体服务端口而不是gateway。是不是token过期或者格式不对。是不是接口返回了JSON但前端解析时少处理了一个字段。小程序端的报错往往会直接显示在控制台。先看控制台里的具体报错信息再决定是改前端还是改后端。8.3 大模型调用报错怎么查先看日志里的状态码。常见情况401/403API Key错误或权限不足。429触发了调用频率限制。500/超时模型服务暂时不可用或网络波动。如果频率不够可以在ai-service里做简单的本地缓存或者在提示词里减少输入长度降低调用成本。8.4 低配机器怎么跑微服务低配电脑跑微服务确实容易卡。两条路子控制JVM内存。在启动脚本里给每个服务限制内存java -Xmx256m -jar quality-service.jar。本地调试时只启动需要的服务不要为了演示把六个服务同时跑起来。如果演示机器只有8G内存建议展示前把非必须服务关闭保证 gateway、system、quality、ai-service 四个服务能稳定运行就够了。整体来看这个毕设项目的本质不是追求服务数量多而是把农产品质检这条业务链路做完整同时体现微服务、小程序、AI三个技术关键词。能跑通是第一步能在答辩时把理由讲明白才是拿高分的关键。我个人更建议先跑通最小闭环再逐步加模块和AI功能不要一开始就把结构做得太重。