最近在帮一个学弟看毕业设计他的选题是“基于SpringBoot微信小程序AI的智能外卖点餐推荐系统”。看到初版时他挺有信心说后端接口写完了小程序页面也调通了数据库建了十几张表。结果我打开首页所谓的“智能推荐”就是按销量排了个序。我问他如果只是这样题目里“AI”两个字是不是可以去掉他沉默了。这不是个例。很多类似项目的通病不是代码跑不起来而是“智能”根本没有落地。这类项目的真正难点也不在某一个框架的用法而在能不能把传统后端工程、端侧交互、模型决策这三层真正打通。本文会从题目拆解、系统架构、实际开发中的坑点、论文组织到答辩思路完整讲一遍重点不是给你一份“能跑”的代码而是告诉你怎样把一个听起来很唬人的题目做成一个真正经得起追问的系统。1. 这不是一个普通外卖系统而是一条完整的AI落地链路1.1 从“点餐工具”到“推荐助手”题目到底变了什么传统外卖点餐系统的核心是交易闭环用户注册登录、浏览商家、挑选菜品、加入购物车、下单支付、查看订单。这套流程做了很多年技术上已经很成熟数据库表就那么几张接口就那么几个本质上是一个“管理信息系统”。如果毕业设计只做到这个程度无论页面多精致都很难说出增量在哪里。加入AI大模型之后题目重心发生了变化。系统从“帮用户完成一次交易”变成了“帮用户更快做出一次正确决策”。这听起来只是一句话的差别但落到系统设计上完全不一样。推荐能力要介入的不只是首页。用户在搜索框输入“今天想吃点辣的”、在店铺页面犹豫该选哪个套餐、购物车里加了东西又不知道要不要结算——这些场景里推荐系统都可以参与。在传统方案里这些都是靠用户自己翻菜单、看评价、凭记忆完成的。而大模型带来的增量在于它能把自然语言需求转成可执行的筛选条件再结合用户历史行为生成推荐结果并且给出推荐理由。所以这个题目真正值得做的方向不是“外卖下单”而是“外卖决策辅助”。传统外卖是交易工具加上大模型之后系统更像一个知道你今天想吃什么、能替你缩小选择范围的推荐助手。1.2 为什么选SpringBoot、微信小程序、大模型这个组合先说SpringBoot。Java生态里SpringBoot几乎是最适合快速搭建RESTful API的框架。自动装配、Starter机制、内嵌Tomcat配合Maven或Gradle一个基础后端项目几分钟就能跑起来。对于毕设场景最大的好处是遇到问题容易找到资料答辩时也容易解释面试官对这套技术栈的接受度非常高。再说微信小程序。外卖餐饮是高频、低决策成本的场景用户不希望为了点一份饭去下载安装一个App。小程序扫码即用微信平台还提供登录、支付、订阅消息等能力业务闭环很自然。从毕设角度看小程序端还能展示界面设计能力、交互逻辑和移动端适配能力这些都是加分项。最后是大模型。它在系统里承担的是“理解和决策”的角色。为什么需要一个独立的大模型层因为传统推荐靠标签匹配和统计排序比如“用户之前点过辣的食物所以多推荐辣的”。但用户真实需求常常是非结构化的比如“最近在健身想吃高蛋白的”“天气热不想吃太油腻的”。这些需求用标签体系很难完整表达而大模型可以直接理解自然语言并转化为推荐系统的输入条件。这个组合不是三个技术堆在一起而是每一层都有明确分工SpringBoot管业务和接口小程序管交互大模型管理解与决策。它们之间通过标准HTTP接口通信边界清楚这也是它适合做毕设的原因之一。1.3 这个项目真正考察的能力层级这个题目看起来“什么都有”容易给人一个错觉只要把技术名词堆上去项目就完整了。实际上它考察的是三层能力。第一层是工程串联能力。你能不能把小程序、后端、数据库、大模型API、微信登录服务真正串起来。绝大多数人卡在这一层因为中间任何一环出错整条链路都会断。第二层是抽象设计能力。推荐需求不能只是“调用一个大模型接口返回几个菜名”。你要设计出用户画像数据结构、行为事件表、推荐请求参数、候选集、排序结果、推荐理由这些工程化概念。这一层决定了系统是不是一个“作品”而不是一段脚本。第三层是系统化思考能力。推荐结果怎么评估大模型超时了怎么办返回内容格式不对怎么校验用户对推荐结果无反馈时如何做冷启动这些问题如果答不上来答辩时很被动。很多学生卡在第二层和第三层之间系统能跑但不知道怎么证明它是“智能”的。接下来要讲的架构和流程重点就是解决这个问题。2. 从架构到功能先理解系统是怎么转起来的2.1 整体技术架构与数据流为了让后续开发不迷路先建立一个整体架构认知。常见的分层方式是这样的展示层微信小程序负责用户交互、推荐卡片展示、下单流程。应用层SpringBoot后端负责业务逻辑、权限校验、接口路由、数据持久化。数据层MySQL存储业务数据Redis缓存热门菜品和用户会话。智能服务层大模型API或本地部署模型负责自然语言理解、推荐重排、推荐理由生成。第三方服务微信登录接口、微信支付毕设可模拟、对象存储菜品图片。完整的推荐数据流可以这样描述用户打开小程序wx.login获取临时code交给后端。后端用code换用户openid生成自己的登录态token返回小程序。用户浏览、搜索、点击、加购、下单行为数据由前端异步上报到后端。用户触发推荐请求时后端汇总用户画像、历史行为、当前请求上下文调用推荐服务。推荐服务先做候选集召回再做排序过滤最后调用大模型生成个性化推荐理由。小程序渲染推荐结果用户点击或下单后行为结果回流更新画像。这条链路中有一个容易被忽略的点大模型不是直接接受前端请求的。小程序端不能持有模型API的密钥所有与模型相关的调用必须由SpringBoot后端代理。这不只是为了安全也是为了让后端能在模型异常时做降级处理。2.2 核心功能模块拆解以功能划分系统至少应该包含以下模块用户模块微信登录、用户信息维护、收货地址管理。商家与菜品模块商家列表、菜品分类、菜品详情、关键词搜索。购物车与订单模块购物车增删改、下单、支付模拟、订单状态流转。推荐模块首页个性化推荐、搜索联想推荐、推荐理由生成、热门兜底。管理后台商家管理、菜品管理、订单管理、推荐日志查看。其中推荐模块是这个题目的灵魂不能只是“查一下数据库里的菜品再排个序”。一个能拿得出手的设计至少应该包含四个环节召回从全部菜品中选出一个候选集比如按用户偏好的品类召回、按相似用户行为召回、按搜索关键词召回。排序对候选集做过滤和打分比如排除用户不吃的食材、根据价格区间和评分做基础排序。重排结合用户当前需求通过大模型对排序结果做个性化调整。解释生成一句“为什么推荐这个菜”的理由提升用户信任感。很多毕设项目把推荐简化成“查表排序”就是少做了召回和重排这两个环节。答辩时老师问“你的推荐和普通排序有什么区别”如果回答不上来就说明智能部分没有真正落地。2.3 推荐系统在业务中的位置不是炫技是省时间外卖场景有一个独特之处用户的决策时间很短耐心很低。一个人中午打开小程序心里可能只有一个模糊想法“不想吃昨天那家”“今天有点热”“预算二十以内”。他需要的不是越多越好的选择而是“直接告诉我该点哪家”。这决定了外卖推荐系统的目标和短视频推荐完全不同。短视频推荐希望用户停留时间越长越好外卖推荐恰恰相反它希望用户在最短时间内完成决策、下完单、离开。这个差异非常关键它会影响推荐算法的设计目标、评价指标和交互方式。大模型在这里的独特价值是理解用户的模糊表达。传统推荐系统会把“不想吃油腻的”抽象成口味标签但标签之间是割裂的很难组合。大模型可以直接把这句话理解成“过滤油炸类、减少高油高盐选项、推荐轻食或清淡菜系”然后带着这些约束条件去做召回和排序。因此推荐模块在业务中的位置不是做一个“花哨功能”而是整个系统的效率引擎。它可以被定义为在合适的时机用合适的理由把合适的菜品放到用户面前。这也是论文里用来立题的核心论据。3. 动手实现前先把这几个坑点填平3.1 SpringBoot版本不是越高越好开发前第一个决策就是SpringBoot版本。很多人习惯直接用最新版但热搜里有一条“springboot版本太高”就说明这个问题确实在大量发生。SpringBoot 3.x 默认要求JDK 17以上同时一部分老依赖、旧版数据库驱动、特定配置方式可能不兼容。如果你的基础还停留在JDK 8、习惯了传统Spring配置直接上3.x会让开发过程充满意外。最常见的情况是代码照着教程写结果启动时报错查半天发现是版本兼容问题。更稳妥的做法是选择SpringBoot 2.7.x搭配JDK 8或11。这个组合非常成熟网上资料多遇到问题容易找到解决方案。不要为了“用最新版”而给自己增加额外排查成本。版本选择还会影响后续打包和部署比如热词里有人提到“springboot jdk1.8打包到docker desktop”踩坑。JDK版本和Docker基础镜像版本不匹配时最常见的报错是UnsupportedClassVersionError或ClassNotFoundException本质都是编译环境和运行环境不一致。这里的原则很清楚先跑通再谈新版本。项目能完整运行、能稳定演示比“用了最新技术”重要得多。3.2 微信小程序登录态最常见也最容易翻车热词中有一条“小程序获取登录后的微信用户失败:wx1cb4398e1413dce7”这类问题几乎每个做过小程序的人都遇到过。它的麻烦在于报错信息往往不够直观而且问题可能出现在好几个不同环节。先理解正确的登录流程小程序端调用wx.login()获取一个临时code。小程序把code发给SpringBoot后端。后端使用appid secret code请求微信的code2Session接口。后端拿到openid和session_key生成自己的登录态token返回给小程序。小程序后续所有请求都携带这个token后端不再直接依赖微信接口。这个链路中最容易出问题的环节是第3步。常见原因包括AppID和AppSecret不匹配。code已经过期或使用过code是一次性的。后端请求微信接口时网络异常或参数名写错。小程序的AppID和后端配置的AppID不是同一个。排查顺序建议先看小程序开发者工具里项目使用的AppID是不是当前项目所属的再检查后端配置里的AppID和AppSecret接着看一下后端日志里微信接口返回的具体状态码最后再怀疑代码逻辑。热词里还有一条“为什么运行到微信小程序模拟器中小程序id还是原来的”这也是典型的配置不一致问题。在HBuilderX或微信开发者工具中项目AppID可能来自manifest.json、project.config.json或开发者工具本地设置多个地方的配置互相覆盖最后运行的就是旧ID。解决方法是把项目配置文件里的AppID统一修改并在微信开发者工具中重新打开项目必要时清缓存重新编译。注意微信登录相关的坑八成不是代码逻辑有多复杂而是AppID、code有效期、后端请求参数这三者的组合出了问题。排查时先看配置再查日志最后才动代码。3.3 AI大模型接入本地部署还是调用API先分清场景“AI大模型”四个字看起来简单落地时第一个问题就是模型从哪来如果条件允许在服务器本地部署开源大模型当然有吸引力但前提是你要有足够的GPU显存和对应的环境维护能力。很多开源模型的部署不是“拉个镜像就能跑”还要考虑显存、量化、推理加速、并发能力。对大多数毕设项目来说这个前置成本太高而且会让项目重心从“业务系统”偏到“模型部署”上。更务实的方案是调用大模型API。这样做的优势很明显集成成本低通过HTTP请求就能拿到模型能力不需要维护GPU环境推荐效果通常比本地小模型好按token计费毕设阶段的调用量一般可控。但调用API也有几个必须注意的点API Key不能写在小程序前端必须由后端保存并代理调用。大模型返回的是文本不是结构化数据。后端要对模型输出做解析和校验不能直接把原始文本塞给前端渲染。必须设置超时时间。大模型API可能慢可能暂时不可用不能让推荐接口因为模型超时整个崩溃。一个常见的做法是后端请求模型时设置3秒超时如果超时或返回内容不满足格式要求系统自动降级为规则推荐——比如按历史订单频次和评分排序。这个过程记录下来写入日志作为答辩时的兜底说明。从工程经验看大模型更像是系统里的一个“决策顾问”而不是一个“唯一真相来源”。它提供建议但系统要负责校验、兜底、记录这才是一个工程正确的接入方式。3.4 开发工具链HBuilderX、小程序ID与运行环境的坑热词里同时出现了“HBuilderX开发微信小程序”和“小程序id还是原来的”这说明很多人使用跨端开发工具来写小程序。这里有一条容易踩的链路如果你用HBuilderX创建项目运行到微信开发者工具时AppID的读取来源是项目的manifest.json。而微信开发者工具本身也会读取本地项目配置。如果两边的AppID不一致就会出现“我在HBuilderX里改了但模拟器里还是原来的AppID”的情况。处理方法是在HBuilderX的manifest.json中找到“微信小程序配置”填入正确的AppID然后在微信开发者工具里删掉旧项目重新导入如果还不行手动修改project.config.json中的appid字段。修改完成后清缓存、重新编译。另一个容易忽略的点是微信公众平台的域名白名单。开发阶段可以在微信开发者工具里勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”但手机预览和正式版会强制校验。如果你的后端地址是本地IP或未备案域名会出现“开发者工具正常手机上看不到数据”的现象。毕设阶段可以使用测试号或内网穿透方案但要清楚这离正式上线还有距离。4. 单点跑通之后怎么补齐工程化能力4.1 数据存储与用户行为埋点推荐系统最怕的一件事是功能实现了但没有任何数据来支撑“推荐”的判断。如果数据库里只有用户表、菜品表、订单表推荐逻辑就很难展开。无论用规则还是大模型都需要行为数据回流。建议在核心业务表之外增加几张和推荐相关的表用户行为日志表记录浏览、搜索、点击、收藏、加购、下单、评价等行为。用户偏好表保存从历史行为或对话中提取出的口味标签、价格偏好、常点品类。推荐日志表记录每次推荐请求的输入、召回候选、排序结果、模型输出、用户是否点击/下单。这三张表不需要一开始设计得很复杂但它们的价值在答辩时非常明显。你可以直接说推荐效果不是靠感觉判断的而是通过推荐日志与行为日志的关联来观察点击率、下单转化率的。前端埋点也简单小程序每个页面的onLoad、onShow、点击事件里把行为类型和业务ID上报给后端。后端提供统一的/api/log/behavior接口异步写入日志表即可。4.2 推荐策略从规则过滤到向量召回再到重排推荐模块不要一上来就想着训练模型。从工程落地角度推荐策略可以做成三个层次。第一层是规则过滤。先根据用户画像做基础过滤比如排除不吃的食材、限制价格区间、保留用户常点品类再按评分、销量、距离等字段排序。这一层简单可靠也是冷启动阶段最重要的兜底方案。第二层是召回。如果数据量足够可以尝试基于用户行为做协同过滤找出相似用户喜欢的菜品也可以把菜品的名称、描述、口味标签做向量化存入向量数据库用用户的历史偏好向量做近似检索。这一层的目的是从全量菜品里快速得到一个候选集。第三层是大模型重排与解释。把候选菜品信息、用户需求、历史行为摘要组合成提示词让大模型做最终排序并生成推荐理由。模型输出不直接作为最终结果后端要解析并校验。对毕设来说建议先完成第一层再按时间精力决定是否做第二层。第三层是亮点但要在前两层跑通的基础上再接否则问题会被放大。4.3 异常处理与日志答辩时最容易被追问的地方答辩老师最常问的一句话是“某个环节挂了你的系统会怎样”没有做过异常处理的方案这一问很容易露馅。至少要为下面四种情况准备兜底方案大模型API超时设置超时时间超时后自动返回规则推荐结果。大模型返回内容无法解析后端做格式校验不满足要求时丢弃本次结果回退到默认推荐。数据库连接失败记录错误日志向前端返回友好提示不要返回500堆栈。推荐结果为空返回热门菜品列表作为默认兜底。日志方面建议使用SLF4J Logback记录每次推荐请求的入参、候选集大小、模型调用耗时、返回内容、是否降级。这些日志既是排查问题的依据也是答辩时展示工程能力的证据。可以顺便做几个基础单元测试覆盖登录接口、推荐接口和降级逻辑。不用追求覆盖率但要让老师看到你有测试意识。注意系统的可靠性不在于每个功能都完美而在于每个关键环节“万一出问题”时行为是可预期的。5. 毕业设计视角从“能运行”到“能答辩”5.1 论文LW的组织逻辑论文不一定要算法多深但一定要体现出“你真的想把问题讲清楚”。比较好的章节组织方式如下绪论为什么选这个题目餐饮外卖决策痛点大模型带来的新可能。相关技术介绍SpringBoot、微信小程序、大模型API、推荐算法概述。系统分析用户角色、功能需求、非功能需求性能、安全、易用性。系统设计总体架构、模块设计、数据库设计、推荐服务流程设计。系统实现按模块描述关键实现配合关键代码和界面截图。系统测试功能测试、接口测试、推荐效果评估、异常场景测试。总结与展望项目完成情况、不足、后续改进方向。一个重要的写作原则不要用论文来贴代码。论文里解释“为什么用这个方案”比粘贴大段代码有价值。比如“这里选择在SpringBoot后端统一代理大模型API是为了避免密钥暴露同时方便做超时降级”这句话就是论文级别的表达。5.2 PPT演示时要展示什么演示PPT的核心不是把每一行源码放上去而是讲清楚三件事你解决的是什么问题、系统是怎么设计的、你做了什么来验证它。演示顺序可以参考先花一分钟讲清楚外卖点餐的决策痛点。再展示整体架构图说明SpringBoot、小程序、大模型各层之间的关系。现场演示一条完整路径用户打开小程序、触发推荐、看到推荐理由、下单。再展示后端日志或数据库中的推荐记录证明推荐逻辑确实发生在后端。切到管理后台展示数据变化。最后讲一下异常处理如果大模型超时系统怎么降级。这里有一个很实用的技巧演示前准备两条不同用户路径一条是“吃辣用户”一条是“清淡健康用户”。两条路径展示出的推荐结果有明显差异才能让人直观感受到“个性化推荐”这个点。5.3 答辩时常被问到的问题和应对思路常见问题大概有这么几类为什么用大模型做推荐和传统协同过滤比有什么优势大模型答错了怎么办推荐结果由谁负责推荐效果怎么评估数据库表之间是什么关系为什么这样设计多用户并发时系统会怎样应对这些问题的核心思路不是背理论而是“先讲业务逻辑再讲技术实现最后讲边界和兜底”。比如“大模型答错了怎么办”可以这样回答系统不会把大模型输出作为唯一结果。后端会先做格式校验如果返回内容不合规就丢弃并降级到规则推荐。每次推荐都会写日志便于回溯问题。也就是说大模型在系统里的角色是增强推荐的可解释性和个性化程度而不是接管整个决策链路。这样的回答既展示了技术理解也展示了工程思维比单纯背一个算法公式更让老师认可。6. 适用边界与长期价值这个项目值得投入多少6.1 适合谁不适合谁这个项目并不适合所有人。做之前先看看自己属于哪一类。适合选这个题目的情况有Java基础和数据库基础希望在一个项目里同时接触后端、小程序和大模型。想通过毕业设计积累一个完整的全栈项目经历方便后续求职或比赛。对推荐系统或AI应用开发感兴趣愿意花时间做数据设计和接口调试。有耐心处理外部依赖问题比如微信小程序配置、大模型API调用。不适合的情况完全不会Java还没跑通过SpringBoot项目。这类同学建议先选一个更简单的管理系统不要一上来就挑战三端集成。没有足够的预留时间项目最后几天才开始做。这个项目外部依赖多任何一个环节都可能卡住。希望算法深度很深想研究推荐模型本身的创新。这个项目的重心在工程集成不是算法创新。6.2 如果放进生产环境还缺什么一定要在论文或答辩中明确这是一个毕业设计级别的原型系统而不是一个可直接商用的产品。如果真要放进真实运营环境还缺很多东西微信支付需要企业主体、商户号、支付证书等资质。订阅消息订单状态变化需要通过微信订阅消息通知用户。权限与角色用户、商家、管理员的权限要单独设计。缓存与限流热门菜品数据建议用Redis缓存接口要做限流防止刷单或异常流量。模型服务独立部署大模型服务要和业务服务解耦最好独立部署、独立扩容。监控与告警接口耗时、错误率、推荐成功率都要有监控。数据合规用户授权、隐私政策、个人信息保护。这些内容不用全部在论文里展开但在“总结与展望”里提一两段会让论文层次更高。答辩时如果老师问“你这个系统能直接商用吗”你的回答是“原型已经验证了核心流程但商用还需要支付、权限、监控、合规等工程能力补齐”这个回答是加分的。6.3 从毕设项目到AI应用开发者的路径这个项目做完之后你收获的不仅是一份毕设论文还有一条非常典型的AI应用开发路径。你至少能回答这些问题微信小程序怎么拿到用户身份登录态如何维持SpringBoot怎么发布一个RESTful接口参数校验和异常处理怎么做在Java代码里怎么调用外部HTTP服务超时怎么控制大模型返回的文本怎么变成结构化数据不可用时怎么兜底为什么不能让前端直接调用大模型API后端代理的价值在哪里推荐结果如何评估行为日志和推荐日志之间是什么关系这些能力比单纯会写一个SpringBoot增删改查要值钱得多。它们本质上是一个AI应用开发者在真实项目中反复要做的决策怎么接模型、怎么控制风险、怎么让结果可解释、怎么让系统在边界情况下仍然可控。回到开头那位学弟。后来他把系统结构调整成了“规则召回兜底 大模型重排解释”只花了两天时间整个系统的逻辑却顺了很多。答辩时老师问他“大模型挂了怎么办”他直接说“系统会自动降级到规则推荐并记录错误日志。我们的推荐结果从来不是模型的中转站而是有边界的工程决策。”那天之后他给我发消息说老师难得点了点头。技术方案本身不难难的是把系统当成一个整体来思考。如果你正在做类似的毕业设计建议先从最小闭环开始一个后端接口、一个小程序页面、一个推荐请求先跑通再加数据、加日志、加兜底。每次增加一个环节就多问自己一句如果它挂了会发生什么把这个过程走完你的项目才算真正“智能”了。 基于SpringBoot+微信小程序+AI的智能外卖推荐系统设计与实现
最近在帮一个学弟看毕业设计他的选题是“基于SpringBoot微信小程序AI的智能外卖点餐推荐系统”。看到初版时他挺有信心说后端接口写完了小程序页面也调通了数据库建了十几张表。结果我打开首页所谓的“智能推荐”就是按销量排了个序。我问他如果只是这样题目里“AI”两个字是不是可以去掉他沉默了。这不是个例。很多类似项目的通病不是代码跑不起来而是“智能”根本没有落地。这类项目的真正难点也不在某一个框架的用法而在能不能把传统后端工程、端侧交互、模型决策这三层真正打通。本文会从题目拆解、系统架构、实际开发中的坑点、论文组织到答辩思路完整讲一遍重点不是给你一份“能跑”的代码而是告诉你怎样把一个听起来很唬人的题目做成一个真正经得起追问的系统。1. 这不是一个普通外卖系统而是一条完整的AI落地链路1.1 从“点餐工具”到“推荐助手”题目到底变了什么传统外卖点餐系统的核心是交易闭环用户注册登录、浏览商家、挑选菜品、加入购物车、下单支付、查看订单。这套流程做了很多年技术上已经很成熟数据库表就那么几张接口就那么几个本质上是一个“管理信息系统”。如果毕业设计只做到这个程度无论页面多精致都很难说出增量在哪里。加入AI大模型之后题目重心发生了变化。系统从“帮用户完成一次交易”变成了“帮用户更快做出一次正确决策”。这听起来只是一句话的差别但落到系统设计上完全不一样。推荐能力要介入的不只是首页。用户在搜索框输入“今天想吃点辣的”、在店铺页面犹豫该选哪个套餐、购物车里加了东西又不知道要不要结算——这些场景里推荐系统都可以参与。在传统方案里这些都是靠用户自己翻菜单、看评价、凭记忆完成的。而大模型带来的增量在于它能把自然语言需求转成可执行的筛选条件再结合用户历史行为生成推荐结果并且给出推荐理由。所以这个题目真正值得做的方向不是“外卖下单”而是“外卖决策辅助”。传统外卖是交易工具加上大模型之后系统更像一个知道你今天想吃什么、能替你缩小选择范围的推荐助手。1.2 为什么选SpringBoot、微信小程序、大模型这个组合先说SpringBoot。Java生态里SpringBoot几乎是最适合快速搭建RESTful API的框架。自动装配、Starter机制、内嵌Tomcat配合Maven或Gradle一个基础后端项目几分钟就能跑起来。对于毕设场景最大的好处是遇到问题容易找到资料答辩时也容易解释面试官对这套技术栈的接受度非常高。再说微信小程序。外卖餐饮是高频、低决策成本的场景用户不希望为了点一份饭去下载安装一个App。小程序扫码即用微信平台还提供登录、支付、订阅消息等能力业务闭环很自然。从毕设角度看小程序端还能展示界面设计能力、交互逻辑和移动端适配能力这些都是加分项。最后是大模型。它在系统里承担的是“理解和决策”的角色。为什么需要一个独立的大模型层因为传统推荐靠标签匹配和统计排序比如“用户之前点过辣的食物所以多推荐辣的”。但用户真实需求常常是非结构化的比如“最近在健身想吃高蛋白的”“天气热不想吃太油腻的”。这些需求用标签体系很难完整表达而大模型可以直接理解自然语言并转化为推荐系统的输入条件。这个组合不是三个技术堆在一起而是每一层都有明确分工SpringBoot管业务和接口小程序管交互大模型管理解与决策。它们之间通过标准HTTP接口通信边界清楚这也是它适合做毕设的原因之一。1.3 这个项目真正考察的能力层级这个题目看起来“什么都有”容易给人一个错觉只要把技术名词堆上去项目就完整了。实际上它考察的是三层能力。第一层是工程串联能力。你能不能把小程序、后端、数据库、大模型API、微信登录服务真正串起来。绝大多数人卡在这一层因为中间任何一环出错整条链路都会断。第二层是抽象设计能力。推荐需求不能只是“调用一个大模型接口返回几个菜名”。你要设计出用户画像数据结构、行为事件表、推荐请求参数、候选集、排序结果、推荐理由这些工程化概念。这一层决定了系统是不是一个“作品”而不是一段脚本。第三层是系统化思考能力。推荐结果怎么评估大模型超时了怎么办返回内容格式不对怎么校验用户对推荐结果无反馈时如何做冷启动这些问题如果答不上来答辩时很被动。很多学生卡在第二层和第三层之间系统能跑但不知道怎么证明它是“智能”的。接下来要讲的架构和流程重点就是解决这个问题。2. 从架构到功能先理解系统是怎么转起来的2.1 整体技术架构与数据流为了让后续开发不迷路先建立一个整体架构认知。常见的分层方式是这样的展示层微信小程序负责用户交互、推荐卡片展示、下单流程。应用层SpringBoot后端负责业务逻辑、权限校验、接口路由、数据持久化。数据层MySQL存储业务数据Redis缓存热门菜品和用户会话。智能服务层大模型API或本地部署模型负责自然语言理解、推荐重排、推荐理由生成。第三方服务微信登录接口、微信支付毕设可模拟、对象存储菜品图片。完整的推荐数据流可以这样描述用户打开小程序wx.login获取临时code交给后端。后端用code换用户openid生成自己的登录态token返回小程序。用户浏览、搜索、点击、加购、下单行为数据由前端异步上报到后端。用户触发推荐请求时后端汇总用户画像、历史行为、当前请求上下文调用推荐服务。推荐服务先做候选集召回再做排序过滤最后调用大模型生成个性化推荐理由。小程序渲染推荐结果用户点击或下单后行为结果回流更新画像。这条链路中有一个容易被忽略的点大模型不是直接接受前端请求的。小程序端不能持有模型API的密钥所有与模型相关的调用必须由SpringBoot后端代理。这不只是为了安全也是为了让后端能在模型异常时做降级处理。2.2 核心功能模块拆解以功能划分系统至少应该包含以下模块用户模块微信登录、用户信息维护、收货地址管理。商家与菜品模块商家列表、菜品分类、菜品详情、关键词搜索。购物车与订单模块购物车增删改、下单、支付模拟、订单状态流转。推荐模块首页个性化推荐、搜索联想推荐、推荐理由生成、热门兜底。管理后台商家管理、菜品管理、订单管理、推荐日志查看。其中推荐模块是这个题目的灵魂不能只是“查一下数据库里的菜品再排个序”。一个能拿得出手的设计至少应该包含四个环节召回从全部菜品中选出一个候选集比如按用户偏好的品类召回、按相似用户行为召回、按搜索关键词召回。排序对候选集做过滤和打分比如排除用户不吃的食材、根据价格区间和评分做基础排序。重排结合用户当前需求通过大模型对排序结果做个性化调整。解释生成一句“为什么推荐这个菜”的理由提升用户信任感。很多毕设项目把推荐简化成“查表排序”就是少做了召回和重排这两个环节。答辩时老师问“你的推荐和普通排序有什么区别”如果回答不上来就说明智能部分没有真正落地。2.3 推荐系统在业务中的位置不是炫技是省时间外卖场景有一个独特之处用户的决策时间很短耐心很低。一个人中午打开小程序心里可能只有一个模糊想法“不想吃昨天那家”“今天有点热”“预算二十以内”。他需要的不是越多越好的选择而是“直接告诉我该点哪家”。这决定了外卖推荐系统的目标和短视频推荐完全不同。短视频推荐希望用户停留时间越长越好外卖推荐恰恰相反它希望用户在最短时间内完成决策、下完单、离开。这个差异非常关键它会影响推荐算法的设计目标、评价指标和交互方式。大模型在这里的独特价值是理解用户的模糊表达。传统推荐系统会把“不想吃油腻的”抽象成口味标签但标签之间是割裂的很难组合。大模型可以直接把这句话理解成“过滤油炸类、减少高油高盐选项、推荐轻食或清淡菜系”然后带着这些约束条件去做召回和排序。因此推荐模块在业务中的位置不是做一个“花哨功能”而是整个系统的效率引擎。它可以被定义为在合适的时机用合适的理由把合适的菜品放到用户面前。这也是论文里用来立题的核心论据。3. 动手实现前先把这几个坑点填平3.1 SpringBoot版本不是越高越好开发前第一个决策就是SpringBoot版本。很多人习惯直接用最新版但热搜里有一条“springboot版本太高”就说明这个问题确实在大量发生。SpringBoot 3.x 默认要求JDK 17以上同时一部分老依赖、旧版数据库驱动、特定配置方式可能不兼容。如果你的基础还停留在JDK 8、习惯了传统Spring配置直接上3.x会让开发过程充满意外。最常见的情况是代码照着教程写结果启动时报错查半天发现是版本兼容问题。更稳妥的做法是选择SpringBoot 2.7.x搭配JDK 8或11。这个组合非常成熟网上资料多遇到问题容易找到解决方案。不要为了“用最新版”而给自己增加额外排查成本。版本选择还会影响后续打包和部署比如热词里有人提到“springboot jdk1.8打包到docker desktop”踩坑。JDK版本和Docker基础镜像版本不匹配时最常见的报错是UnsupportedClassVersionError或ClassNotFoundException本质都是编译环境和运行环境不一致。这里的原则很清楚先跑通再谈新版本。项目能完整运行、能稳定演示比“用了最新技术”重要得多。3.2 微信小程序登录态最常见也最容易翻车热词中有一条“小程序获取登录后的微信用户失败:wx1cb4398e1413dce7”这类问题几乎每个做过小程序的人都遇到过。它的麻烦在于报错信息往往不够直观而且问题可能出现在好几个不同环节。先理解正确的登录流程小程序端调用wx.login()获取一个临时code。小程序把code发给SpringBoot后端。后端使用appid secret code请求微信的code2Session接口。后端拿到openid和session_key生成自己的登录态token返回给小程序。小程序后续所有请求都携带这个token后端不再直接依赖微信接口。这个链路中最容易出问题的环节是第3步。常见原因包括AppID和AppSecret不匹配。code已经过期或使用过code是一次性的。后端请求微信接口时网络异常或参数名写错。小程序的AppID和后端配置的AppID不是同一个。排查顺序建议先看小程序开发者工具里项目使用的AppID是不是当前项目所属的再检查后端配置里的AppID和AppSecret接着看一下后端日志里微信接口返回的具体状态码最后再怀疑代码逻辑。热词里还有一条“为什么运行到微信小程序模拟器中小程序id还是原来的”这也是典型的配置不一致问题。在HBuilderX或微信开发者工具中项目AppID可能来自manifest.json、project.config.json或开发者工具本地设置多个地方的配置互相覆盖最后运行的就是旧ID。解决方法是把项目配置文件里的AppID统一修改并在微信开发者工具中重新打开项目必要时清缓存重新编译。注意微信登录相关的坑八成不是代码逻辑有多复杂而是AppID、code有效期、后端请求参数这三者的组合出了问题。排查时先看配置再查日志最后才动代码。3.3 AI大模型接入本地部署还是调用API先分清场景“AI大模型”四个字看起来简单落地时第一个问题就是模型从哪来如果条件允许在服务器本地部署开源大模型当然有吸引力但前提是你要有足够的GPU显存和对应的环境维护能力。很多开源模型的部署不是“拉个镜像就能跑”还要考虑显存、量化、推理加速、并发能力。对大多数毕设项目来说这个前置成本太高而且会让项目重心从“业务系统”偏到“模型部署”上。更务实的方案是调用大模型API。这样做的优势很明显集成成本低通过HTTP请求就能拿到模型能力不需要维护GPU环境推荐效果通常比本地小模型好按token计费毕设阶段的调用量一般可控。但调用API也有几个必须注意的点API Key不能写在小程序前端必须由后端保存并代理调用。大模型返回的是文本不是结构化数据。后端要对模型输出做解析和校验不能直接把原始文本塞给前端渲染。必须设置超时时间。大模型API可能慢可能暂时不可用不能让推荐接口因为模型超时整个崩溃。一个常见的做法是后端请求模型时设置3秒超时如果超时或返回内容不满足格式要求系统自动降级为规则推荐——比如按历史订单频次和评分排序。这个过程记录下来写入日志作为答辩时的兜底说明。从工程经验看大模型更像是系统里的一个“决策顾问”而不是一个“唯一真相来源”。它提供建议但系统要负责校验、兜底、记录这才是一个工程正确的接入方式。3.4 开发工具链HBuilderX、小程序ID与运行环境的坑热词里同时出现了“HBuilderX开发微信小程序”和“小程序id还是原来的”这说明很多人使用跨端开发工具来写小程序。这里有一条容易踩的链路如果你用HBuilderX创建项目运行到微信开发者工具时AppID的读取来源是项目的manifest.json。而微信开发者工具本身也会读取本地项目配置。如果两边的AppID不一致就会出现“我在HBuilderX里改了但模拟器里还是原来的AppID”的情况。处理方法是在HBuilderX的manifest.json中找到“微信小程序配置”填入正确的AppID然后在微信开发者工具里删掉旧项目重新导入如果还不行手动修改project.config.json中的appid字段。修改完成后清缓存、重新编译。另一个容易忽略的点是微信公众平台的域名白名单。开发阶段可以在微信开发者工具里勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”但手机预览和正式版会强制校验。如果你的后端地址是本地IP或未备案域名会出现“开发者工具正常手机上看不到数据”的现象。毕设阶段可以使用测试号或内网穿透方案但要清楚这离正式上线还有距离。4. 单点跑通之后怎么补齐工程化能力4.1 数据存储与用户行为埋点推荐系统最怕的一件事是功能实现了但没有任何数据来支撑“推荐”的判断。如果数据库里只有用户表、菜品表、订单表推荐逻辑就很难展开。无论用规则还是大模型都需要行为数据回流。建议在核心业务表之外增加几张和推荐相关的表用户行为日志表记录浏览、搜索、点击、收藏、加购、下单、评价等行为。用户偏好表保存从历史行为或对话中提取出的口味标签、价格偏好、常点品类。推荐日志表记录每次推荐请求的输入、召回候选、排序结果、模型输出、用户是否点击/下单。这三张表不需要一开始设计得很复杂但它们的价值在答辩时非常明显。你可以直接说推荐效果不是靠感觉判断的而是通过推荐日志与行为日志的关联来观察点击率、下单转化率的。前端埋点也简单小程序每个页面的onLoad、onShow、点击事件里把行为类型和业务ID上报给后端。后端提供统一的/api/log/behavior接口异步写入日志表即可。4.2 推荐策略从规则过滤到向量召回再到重排推荐模块不要一上来就想着训练模型。从工程落地角度推荐策略可以做成三个层次。第一层是规则过滤。先根据用户画像做基础过滤比如排除不吃的食材、限制价格区间、保留用户常点品类再按评分、销量、距离等字段排序。这一层简单可靠也是冷启动阶段最重要的兜底方案。第二层是召回。如果数据量足够可以尝试基于用户行为做协同过滤找出相似用户喜欢的菜品也可以把菜品的名称、描述、口味标签做向量化存入向量数据库用用户的历史偏好向量做近似检索。这一层的目的是从全量菜品里快速得到一个候选集。第三层是大模型重排与解释。把候选菜品信息、用户需求、历史行为摘要组合成提示词让大模型做最终排序并生成推荐理由。模型输出不直接作为最终结果后端要解析并校验。对毕设来说建议先完成第一层再按时间精力决定是否做第二层。第三层是亮点但要在前两层跑通的基础上再接否则问题会被放大。4.3 异常处理与日志答辩时最容易被追问的地方答辩老师最常问的一句话是“某个环节挂了你的系统会怎样”没有做过异常处理的方案这一问很容易露馅。至少要为下面四种情况准备兜底方案大模型API超时设置超时时间超时后自动返回规则推荐结果。大模型返回内容无法解析后端做格式校验不满足要求时丢弃本次结果回退到默认推荐。数据库连接失败记录错误日志向前端返回友好提示不要返回500堆栈。推荐结果为空返回热门菜品列表作为默认兜底。日志方面建议使用SLF4J Logback记录每次推荐请求的入参、候选集大小、模型调用耗时、返回内容、是否降级。这些日志既是排查问题的依据也是答辩时展示工程能力的证据。可以顺便做几个基础单元测试覆盖登录接口、推荐接口和降级逻辑。不用追求覆盖率但要让老师看到你有测试意识。注意系统的可靠性不在于每个功能都完美而在于每个关键环节“万一出问题”时行为是可预期的。5. 毕业设计视角从“能运行”到“能答辩”5.1 论文LW的组织逻辑论文不一定要算法多深但一定要体现出“你真的想把问题讲清楚”。比较好的章节组织方式如下绪论为什么选这个题目餐饮外卖决策痛点大模型带来的新可能。相关技术介绍SpringBoot、微信小程序、大模型API、推荐算法概述。系统分析用户角色、功能需求、非功能需求性能、安全、易用性。系统设计总体架构、模块设计、数据库设计、推荐服务流程设计。系统实现按模块描述关键实现配合关键代码和界面截图。系统测试功能测试、接口测试、推荐效果评估、异常场景测试。总结与展望项目完成情况、不足、后续改进方向。一个重要的写作原则不要用论文来贴代码。论文里解释“为什么用这个方案”比粘贴大段代码有价值。比如“这里选择在SpringBoot后端统一代理大模型API是为了避免密钥暴露同时方便做超时降级”这句话就是论文级别的表达。5.2 PPT演示时要展示什么演示PPT的核心不是把每一行源码放上去而是讲清楚三件事你解决的是什么问题、系统是怎么设计的、你做了什么来验证它。演示顺序可以参考先花一分钟讲清楚外卖点餐的决策痛点。再展示整体架构图说明SpringBoot、小程序、大模型各层之间的关系。现场演示一条完整路径用户打开小程序、触发推荐、看到推荐理由、下单。再展示后端日志或数据库中的推荐记录证明推荐逻辑确实发生在后端。切到管理后台展示数据变化。最后讲一下异常处理如果大模型超时系统怎么降级。这里有一个很实用的技巧演示前准备两条不同用户路径一条是“吃辣用户”一条是“清淡健康用户”。两条路径展示出的推荐结果有明显差异才能让人直观感受到“个性化推荐”这个点。5.3 答辩时常被问到的问题和应对思路常见问题大概有这么几类为什么用大模型做推荐和传统协同过滤比有什么优势大模型答错了怎么办推荐结果由谁负责推荐效果怎么评估数据库表之间是什么关系为什么这样设计多用户并发时系统会怎样应对这些问题的核心思路不是背理论而是“先讲业务逻辑再讲技术实现最后讲边界和兜底”。比如“大模型答错了怎么办”可以这样回答系统不会把大模型输出作为唯一结果。后端会先做格式校验如果返回内容不合规就丢弃并降级到规则推荐。每次推荐都会写日志便于回溯问题。也就是说大模型在系统里的角色是增强推荐的可解释性和个性化程度而不是接管整个决策链路。这样的回答既展示了技术理解也展示了工程思维比单纯背一个算法公式更让老师认可。6. 适用边界与长期价值这个项目值得投入多少6.1 适合谁不适合谁这个项目并不适合所有人。做之前先看看自己属于哪一类。适合选这个题目的情况有Java基础和数据库基础希望在一个项目里同时接触后端、小程序和大模型。想通过毕业设计积累一个完整的全栈项目经历方便后续求职或比赛。对推荐系统或AI应用开发感兴趣愿意花时间做数据设计和接口调试。有耐心处理外部依赖问题比如微信小程序配置、大模型API调用。不适合的情况完全不会Java还没跑通过SpringBoot项目。这类同学建议先选一个更简单的管理系统不要一上来就挑战三端集成。没有足够的预留时间项目最后几天才开始做。这个项目外部依赖多任何一个环节都可能卡住。希望算法深度很深想研究推荐模型本身的创新。这个项目的重心在工程集成不是算法创新。6.2 如果放进生产环境还缺什么一定要在论文或答辩中明确这是一个毕业设计级别的原型系统而不是一个可直接商用的产品。如果真要放进真实运营环境还缺很多东西微信支付需要企业主体、商户号、支付证书等资质。订阅消息订单状态变化需要通过微信订阅消息通知用户。权限与角色用户、商家、管理员的权限要单独设计。缓存与限流热门菜品数据建议用Redis缓存接口要做限流防止刷单或异常流量。模型服务独立部署大模型服务要和业务服务解耦最好独立部署、独立扩容。监控与告警接口耗时、错误率、推荐成功率都要有监控。数据合规用户授权、隐私政策、个人信息保护。这些内容不用全部在论文里展开但在“总结与展望”里提一两段会让论文层次更高。答辩时如果老师问“你这个系统能直接商用吗”你的回答是“原型已经验证了核心流程但商用还需要支付、权限、监控、合规等工程能力补齐”这个回答是加分的。6.3 从毕设项目到AI应用开发者的路径这个项目做完之后你收获的不仅是一份毕设论文还有一条非常典型的AI应用开发路径。你至少能回答这些问题微信小程序怎么拿到用户身份登录态如何维持SpringBoot怎么发布一个RESTful接口参数校验和异常处理怎么做在Java代码里怎么调用外部HTTP服务超时怎么控制大模型返回的文本怎么变成结构化数据不可用时怎么兜底为什么不能让前端直接调用大模型API后端代理的价值在哪里推荐结果如何评估行为日志和推荐日志之间是什么关系这些能力比单纯会写一个SpringBoot增删改查要值钱得多。它们本质上是一个AI应用开发者在真实项目中反复要做的决策怎么接模型、怎么控制风险、怎么让结果可解释、怎么让系统在边界情况下仍然可控。回到开头那位学弟。后来他把系统结构调整成了“规则召回兜底 大模型重排解释”只花了两天时间整个系统的逻辑却顺了很多。答辩时老师问他“大模型挂了怎么办”他直接说“系统会自动降级到规则推荐并记录错误日志。我们的推荐结果从来不是模型的中转站而是有边界的工程决策。”那天之后他给我发消息说老师难得点了点头。技术方案本身不难难的是把系统当成一个整体来思考。如果你正在做类似的毕业设计建议先从最小闭环开始一个后端接口、一个小程序页面、一个推荐请求先跑通再加数据、加日志、加兜底。每次增加一个环节就多问自己一句如果它挂了会发生什么把这个过程走完你的项目才算真正“智能”了。