尧图网站建设 
每年到了毕业设计季节后台总有一堆同学在问同一个问题想做点有区分度的题目但选来选去都是“XX管理系统”“XX平台设计与实现”答辩时老师看一眼标题就失去了兴趣。这篇文章就围绕一个具体又比较有代表性的毕业设计题目展开基于 SpringBoot 微信小程序 AI 的智能外卖点餐推荐系统。先说判断这个项目真正的竞争点不在“外卖点餐”三个字而在“智能推荐”这四个字。传统的外卖点餐系统技术栈再完整也只是一个 CRUD 展示但当你把 AI 大模型接入到推荐环节让系统可以根据用户的历史行为、口味偏好甚至一段自然语言描述来推荐菜品时项目的技术含量和答辩说服力就完全不同了。接下来我会从选题分析、系统架构、数据库设计、SpringBoot 后端实现、微信小程序端实现、推荐引擎与大模型接入、运行验证、常见问题到工程建议把这个项目完整拆解一遍。就算你还没开始动手写代码看完这篇也能知道每一步该做什么、为什么这么做。1. 这篇文章真正要解决的问题很多计算机专业学生做毕业设计时会陷入两个极端。第一个极端是“为了求稳做一个纯管理系统”。用户管理、菜品管理、订单管理、公告管理再加几个图表统计完事。这类系统代码量大但技术含量低答辩时老师的提问基本集中在“你的创新点是什么”而这个问题往往答不上来。第二个极端是“盲目追新把项目做得过于复杂”。一上来就要做分布式、微服务、高并发、消息队列结果工作量失控写到一半写不下去反而连基本功能都完不成。这两个极端之间真正合适的方向是用主流可靠的技术栈完成一个有明确价值主张的业务系统并在一两个关键环节做出有深度的亮点。本文要拆解的智能外卖点餐推荐系统就是一个典型代表。它的技术栈是 SpringBoot 微信小程序 MyBatis-Plus AI 大模型业务范围是外卖点餐的完整闭环。它的差异化亮点是推荐模块不是简单地按销量排序而是结合用户行为数据和 AI 大模型能力给出有解释、有温度、可交互的推荐结果。这个题目的价值在于技术覆盖面广前后端分离、移动端小程序、数据库设计、接口开发、AI 能力接入一个项目把本科阶段的核心技能点都串起来了。工作量可控核心模块清晰可以按阶段推进不会出现做到一半失控的情况。答辩有亮点AI 推荐引擎是老师最容易感兴趣也最容易提问的部分只要原理讲清楚、效果能演示这就是论文和答辩的核心加分项。有真实业务场景支撑外卖点餐是所有人都熟悉的场景系统边界容易理解需求分析不会空洞。如果你正在犹豫毕业设计选题或者已经选了类似题目但不知道从哪下手这篇文章值得收藏细读。2. 智能外卖点餐推荐系统的核心概念在写代码之前先弄清楚三组关键概念推荐系统怎么工作、大模型在推荐里扮演什么角色、它们和外卖点餐场景怎么结合。2.1 推荐系统的基本逻辑推荐系统的本质是在“信息过载”的环境里帮助用户从大量选择中找到最可能感兴趣的内容。外卖平台上有几十上百个菜品用户不可能一一浏览。推荐系统要做的就是猜这个用户现在最想吃什么。常见的推荐算法有三类推荐类型核心逻辑比喻适合场景基于协同过滤“和你口味相似的人也在吃这些”朋友推荐有大量用户行为数据基于内容推荐“你过去爱吃辣所以推荐辣味菜品”口味画像用户历史行为明确混合推荐多种策略加权组合取长补短综合顾问实际系统的主流方案在外卖场景下协同过滤有一个现实难题如果用户是新用户或者订单数据很少协同过滤就无从算起。这就是所谓“冷启动问题”。解决冷启动传统方案是“热门兜底”也就是推荐销量最高、评分最好的菜品。而在这个项目里我们可以用 AI 大模型做更高级的冷启动处理让用户用一句话描述今天想吃什么系统基于自然语言理解来推荐。这是传统推荐系统做不到的。2.2 大模型在推荐系统中的角色大模型不是来替代整个推荐系统的而是作为其中一个关键组件负责两件事第一理解用户的自然语言输入。传统系统里用户只能点按钮、选分类、看列表接入了大模型之后用户可以输入“今天想吃点清淡的不要太辣适合一个人吃”系统解析出关键词口味清淡、不吃辣、一人食然后到菜品库中匹配候选集。第二生成推荐解释。推荐系统算出结果之后如果只是丢给用户一个菜品列表说服力有限。大模型可以为每个推荐结果生成一句推荐语比如“这道番茄鸡蛋汤口味清淡酸甜开胃一个人吃刚刚好适合今天没什么胃口的你”。这大大提升了用户体验也能在答辩时作为“AI 能力落地”的直接证据。2.3 系统里有哪些角色一个完整的外卖点餐推荐系统至少要包含三种角色普通用户浏览菜品、搜索、下单、查看订单、查看个性化推荐。管理员管理菜品分类、菜品信息、用户状态、订单状态、推荐策略配置。系统后台服务处理业务逻辑调用推荐引擎和大模型接口。这三类需求叠加起来系统的功能边界就清楚了。3. 系统架构与技术选型这个项目的架构属于典型的小型前后端分离架构。它不追求微服务级别的拆分但要求层次清晰、职责分明。整体架构分为三层第一层是微信小程序端承担用户交互。用户在小程序里浏览菜品、查看推荐、下单支付、管理个人信息。小程序通过 HTTP 请求调用后端接口数据交换格式为 JSON。第二层是SpringBoot 后端服务承担业务逻辑。后端分成控制层、服务层、数据访问层。控制层负责接收请求和返回结果服务层实现具体业务比如下单流程、推荐流程数据访问层使用 MyBatis-Plus 操作数据库。第三层是数据与外部能力层包括 MySQL 数据库存储业务数据以及 AI 大模型接口能力。大模型接口在这一层以 HTTP 的方式被后端服务调用后端不直接面向小程序暴露大模型的密钥和配置。这种分层的好处是每一层都可以独立修改和替换。比如今天接的是某一个云端大模型接口明天想换成本地部署的模型只需要修改后端调用大模型的 Service 实现小程序端完全不用动。核心模块划分如下模块主要功能涉及技术用户模块微信登录、用户信息维护SpringBoot、MyBatis-Plus菜品模块分类浏览、菜品详情SpringBoot、MySQL订单模块购物车、下单、订单查询SpringBoot、MyBatis-Plus推荐模块相似菜品推荐、大模型个性化推荐推荐算法、AI 大模型接口管理模块菜品管理、订单管理、推荐管理SpringBoot、Vue 或原生页面这里要特别提醒一点不要在一开始就追求复杂架构。把 SpringBoot 工程拆成 controller / service / mapper 三个标准包再加上一个 config 包和一个 common 包对毕业设计来说完全足够也方便论文画架构图。4. 环境准备与数据库设计4.1 开发环境清单在动手之前先把环境准备好。以下环境以实际安装版本为准本文侧重通用实现思路不在版本号上死磕。JDK 1.8 或 17推荐使用稳定版本。Maven 3.6 以上用于依赖管理。MySQL 5.7 或 8.0存储业务数据。微信开发者工具用于运行小程序端。IDEA 或 Eclipse用于后端开发。一个可用的 AI 大模型接口本文以兼容 OpenAI 格式的 API 为例也可以用国内大模型平台的接口只需替换 SDK 和 base-url。4.2 数据库设计数据库是业务系统的地基。这个项目建议设计如下核心表用户表 t_userCREATE TABLE t_user ( id bigint(20) NOT NULL AUTO_INCREMENT, openid varchar(64) DEFAULT NULL COMMENT 微信openid, nickname varchar(50) DEFAULT NULL COMMENT 昵称, avatar varchar(255) DEFAULT NULL COMMENT 头像, phone varchar(20) DEFAULT NULL COMMENT 手机号, taste_tag varchar(255) DEFAULT NULL COMMENT 口味偏好标签如辣、清淡, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;菜品表 t_dishCREATE TABLE t_dish ( id bigint(20) NOT NULL AUTO_INCREMENT, category_id bigint(20) DEFAULT NULL COMMENT 分类id, name varchar(100) DEFAULT NULL COMMENT 菜品名称, description varchar(500) DEFAULT NULL COMMENT 菜品描述, price decimal(10,2) DEFAULT NULL COMMENT 价格, image varchar(255) DEFAULT NULL COMMENT 图片地址, spicy_level int(11) DEFAULT 0 COMMENT 辣度0不辣 1微辣 2中辣 3特辣, taste_tags varchar(255) DEFAULT NULL COMMENT 口味标签如清淡、重口、甜口, sales_count int(11) DEFAULT 0 COMMENT 销量, status int(11) DEFAULT 1 COMMENT 上架状态 1上架 0下架, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT菜品表;用户行为表 t_user_behaviorCREATE TABLE t_user_behavior ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) DEFAULT NULL COMMENT 用户id, dish_id bigint(20) DEFAULT NULL COMMENT 菜品id, behavior_type varchar(20) DEFAULT NULL COMMENT 行为类型view点赞、order下单、collect收藏, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户行为记录表;订单表 t_order和订单明细表 t_order_item也必不可少订单表记录订单号、用户、总金额、状态订单明细表记录每个订单包含哪些菜品、数量、单价。这里的设计思路是推荐系统的基础数据来自用户的真实行为。用户浏览了哪些菜、收藏了哪些菜、下单了哪些菜这些行为是判断用户口味偏好的原始依据。如果项目演示阶段缺少真实数据可以写一个数据初始化脚本批量生成模拟用户行为数据。5. SpringBoot 后端核心实现SpringBoot 是整个系统的中枢。下面按依赖、配置、代码三层来拆解。5.1 Maven 依赖在pom.xml中引入核心依赖SpringBoot Web、MyBatis-Plus、MySQL 驱动、Lombok以及大模型 HTTP 调用所需的工具包。!-- 文件路径pom.xml -- dependencies !-- SpringBoot Web -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- MyBatis-Plus -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency !-- MySQL 驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- Lombok -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency !-- Hutool 工具包封装了 HTTP 请求 -- dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.18/version /dependency /dependenciesHutool 在调用大模型 API 时非常方便不需要额外引入 Feign 或 RestTemplate 的复杂配置。5.2 application.yml 配置# 文件路径src/main/resources/application.yml server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/ai_order?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password servlet: multipart: max-file-size: 10MB mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 # AI 大模型接口配置 ai: model: api-key: your_api_key_here base-url: https://your-model-endpoint.com/v1 model-name: your-model-name这里最需要强调的是ai.model.api-key。这个配置项绝对不能写死在小程序前端也不能提交到公开的代码仓库。实际项目里建议通过环境变量或配置中心注入比如api-key: ${AI_API_KEY}。5.3 菜品推荐接口实现推荐模块是核心亮点单独拆出来讲。推荐接口的流程是用户进入小程序首页请求/api/recommend/list。后端拿到用户 ID查询用户历史行为记录。如果用户行为数据充足使用基于用户的协同过滤思想找到相似用户推荐他们喜欢的菜品。如果用户行为数据不足使用用户输入的偏好文本调用大模型解析口味关键词然后按标签匹配菜品。最终结果统一包装成RecommendResponse返回给小程序。先定义一个菜品实体// 文件路径src/main/java/com/example/aiorder/entity/Dish.java Data TableName(t_dish) public class Dish { TableId(type IdType.AUTO) private Long id; private Long categoryId; private String name; private String description; private BigDecimal price; private String image; private Integer spicyLevel; private String tasteTags; private Integer salesCount; private Integer status; }再写推荐服务的核心逻辑// 文件路径src/main/java/com/example/aiorder/service/RecommendService.java Service public class RecommendService { Resource private DishMapper dishMapper; Resource private UserBehaviorMapper behaviorMapper; Resource private AiModelService aiModelService; public ListDish recommend(Long userId, String userInput) { // 1. 查询用户历史行为统计兴趣标签 ListUserBehavior behaviors behaviorMapper.selectList( new LambdaQueryWrapperUserBehavior() .eq(UserBehavior::getUserId, userId) .orderByDesc(UserBehavior::getCreateTime) .last(limit 50) ); // 2. 根据行为记录计算用户口味标签权重 MapString, Integer tagWeight new HashMap(); if (behaviors.isEmpty() StrUtil.isNotBlank(userInput)) { // 3. 冷启动调用大模型解析用户输入提取标签 ListString tags aiModelService.analyzeUserInput(userInput); return matchDishByTags(tags); } // 4. 有行为数据基于标签权重推荐 for (UserBehavior behavior : behaviors) { Dish dish dishMapper.selectById(behavior.getDishId()); if (dish ! null StrUtil.isNotBlank(dish.getTasteTags())) { for (String tag : dish.getTasteTags().split(,)) { tagWeight.put(tag, tagWeight.getOrDefault(tag, 0) 1); } } } // 5. 按权重排序取 Top 标签再匹配菜品 ListString topTags tagWeight.entrySet().stream() .sorted(Map.Entry.String, IntegercomparingByValue().reversed()) .limit(3) .map(Map.Entry::getKey) .collect(Collectors.toList()); return matchDishByTags(topTags); } private ListDish matchDishByTags(ListString tags) { // 按标签模糊匹配菜品并按销量排序 return dishMapper.selectList( new LambdaQueryWrapperDish() .eq(Dish::getStatus, 1) .like(StrUtil.isNotBlank(tags.get(0)), Dish::getTasteTags, tags.get(0)) .orderByDesc(Dish::getSalesCount) .last(limit 10) ); } }控制层接口// 文件路径src/main/java/com/example/aiorder/controller/RecommendController.java RestController RequestMapping(/api/recommend) public class RecommendController { Resource private RecommendService recommendService; GetMapping(/list) public ResultListDish recommend( RequestParam(required false) Long userId, RequestParam(required false) String userInput) { ListDish dishes recommendService.recommend(userId, userInput); return Result.success(dishes); } }这个实现有几个关键点值得注意。第一LambdaQueryWrapper是 MyBatis-Plus 提供的条件构造器用起来比手写 XML 高效很多也是毕业设计代码里的加分细节。第二冷启动处理是推荐系统的核心难点。这里用了“用户没有行为数据时通过自然语言输入 大模型标签提取”的方案比单纯返回热门菜品更有技术说服力。第三推荐过程不是一次性把大模型接口放到主链路里而是先标签化、再匹配、再排序这样可以保证接口响应速度。直接让大模型生成整个推荐列表响应慢且结果不可控这是实际系统里的常见坑。6. 大模型接入与提示词工程大模型在这个项目里除了做冷启动标签解析还可以做推荐解释生成。这部分是答辩时的展示亮点。6.1 大模型调用服务// 文件路径src/main/java/com/example/aiorder/service/AiModelService.java Service public class AiModelService { Value(${ai.model.api-key}) private String apiKey; Value(${ai.model.base-url}) private String baseUrl; Value(${ai.model.model-name}) private String modelName; public ListString analyzeUserInput(String userInput) { String prompt buildPrompt(userInput); String response callModel(prompt); return parseTags(response); } public String generateRecommendReason(String dishName, String userInput) { String prompt 请用一句话为菜品【 dishName 】生成推荐理由 用户的需求是 userInput 。要求语言自然、贴合场景不超过30个字。; return callModel(prompt); } private String callModel(String prompt) { MapString, Object params new HashMap(); params.put(model, modelName); params.put(messages, new Object[]{ Map.of(role, user, content, prompt) }); params.put(temperature, 0.7); String body JSONUtil.toJsonStr(params); HttpResponse response HttpRequest.post(baseUrl /chat/completions) .header(Authorization, Bearer apiKey) .header(Content-Type, application/json) .body(body) .timeout(10000) .execute(); return response.body(); } }6.2 提示词模板提示词直接决定了大模型输出质量。同一个需求提示词写得好不好效果差异巨大。弱提示词请根据用户的输入推荐菜品。强提示词你是一个专业的美食推荐助手。请从用户的描述中提取口味标签标签范围包括辣、清淡、甜口、酸口、重口、素食、低脂、一人食、多人聚餐。 用户描述${userInput} 请只输出标签列表用逗号分隔不要输出其他内容。强提示词的要点是定义角色、明确任务、限定输出格式。这样大模型就不会输出一大堆解释而是乖乖返回“清淡,一人食,不辣”这样的结构化标签。提示词要单独写成一个常量类方便调优和论文里展示。6.3 大模型与推荐链路的关系要清楚一点大模型不是推荐的主体而是推荐链路上的辅助组件。推荐的主体还是基于用户行为和标签匹配的算法逻辑。大模型负责两件事解析语义标签、生成推荐语。这样设计有实际好处。第一响应速度快。菜品匹配和排序走数据库索引毫秒级返回大模型只用在小概率的冷启动和解释生成场景。第二结果稳定。数据库标签匹配的结果是可复现的不会出现同一个用户两次请求推荐结果完全不一样的情况。第三成本可控。大模型按调用次数计费如果每次请求都调用大模型成本高且答辩演示时万一网络不通整个推荐模块就瘫痪了。7. 微信小程序端实现小程序端是用户直接接触的界面好坏直接影响演示效果。小程序包括四个核心页面首页、点餐页、购物车与订单页、个人中心页。7.1 首页推荐展示首页进入时调用推荐接口渲染推荐菜品列表。用户可以在顶部搜索框输入口味偏好比如“今天想吃点辣的开开胃”然后触发推荐。// 文件路径pages/index/index.js Page({ data: { recommendList: [], userInput: }, onLoad() { this.fetchRecommend(); }, fetchRecommend(input) { const app getApp(); wx.request({ url: app.globalData.baseUrl /api/recommend/list, method: GET, data: { userId: app.globalData.userId, userInput: input }, success: (res) { if (res.data.code 200) { this.setData({ recommendList: res.data.data }); } } }); }, onInputChange(e) { this.setData({ userInput: e.detail.value }); }, onSearch() { this.fetchRecommend(this.data.userInput); } });对应的小程序页面结构!-- 文件路径pages/index/index.wxml -- view classsearch-bar input placeholder输入你的口味偏好例如想吃清淡的 bindinputonInputChange / button bindtaponSearch智能推荐/button /view view classrecommend-list view classdish-card wx:for{{recommendList}} wx:keyid image src{{item.image}} / view classdish-info text classdish-name{{item.name}}/text text classdish-desc{{item.description}}/text text classdish-price{{item.price}}/text button bindtapaddToCart>// 文件路径pages/cart/cart.js submitOrder() { const cartList this.data.cartList; const app getApp(); wx.request({ url: app.globalData.baseUrl /api/order/create, method: POST, data: { userId: app.globalData.userId, items: cartList.map(item ({ dishId: item.id, quantity: item.quantity })) }, success: (res) { if (res.data.code 200) { wx.showToast({ title: 下单成功 }); this.setData({ cartList: [] }); } } }); }后端订单创建的代码这里先不做完整展开核心逻辑是事务开启后先写入订单主表再循环写入订单明细表同时扣减菜品销量字段最后提交事务。涉及金额和库存的操作事务是必须的。需要提醒的是如果项目涉及微信支付需要小程序具备微信支付商户号资质。如果是毕业设计演示一般建议把支付模块做成模拟支付也就是在界面上提供一个“模拟支付”按钮跳到支付成功页。这样既不影响完整流程演示也不会卡在资质审核上。8. 运行效果与验证方法项目写完以后验证环节不能省。按下面顺序操作能较快发现问题。8.1 后端启动mvn clean package -DskipTests java -jar target/ai-order-0.0.1-SNAPSHOT.jar看到类似输出说明启动成功Tomcat started on port(s): 8080 (http) Started AiOrderApplication in 5.23 seconds8.2 接口验证启动后端后用浏览器直接访问推荐接口http://localhost:8080/api/recommend/list?userId1userInput想吃清淡的预期返回 JSON 格式的菜品列表。如果返回了菜品数据说明数据库连接、MyBatis-Plus 映射、推荐逻辑都正常。8.3 小程序端验证在微信开发者工具中导入小程序项目修改app.js里的baseUrl指向本机局域网 IP 或已部署的服务器地址。验证时重点检查几个场景新用户首次进入不输入任何内容能看到“热门推荐”兜底菜品。新用户输入“想吃点辣的”推荐结果与辣味菜品匹配。老用户多次浏览和收藏某类菜品后推荐结果中同类菜品占比上升。用户可以将菜品加入购物车、提交订单、在订单列表看到订单记录。管理员后台可以新增菜品客户端刷新后能看到新菜品。如果第 2 项和第 3 项表现不明显最可能的原因是菜品数据里没有维护taste_tags字段或者行为数据太少。解决方法是先造一批带有明确标签的菜品数据再生成足够的模拟行为数据。9. 常见问题与排查思路问题现象可能原因排查方式解决方案后端启动报数据库连接失败MySQL 未启动或账号密码错误查看日志中最后一条异常堆栈检查数据库服务和application.yml配置小程序请求接口报 500后端接口异常打开浏览器直接访问接口查看后端控制台日志根据异常堆栈修复代码常见是 SQL 错误或空指针小程序请求接口报 404请求路径与后端接口不一致对比控制层RequestMapping和小程序 URL统一接口路径建议用常量管理推荐结果为空数据库中无匹配标签的菜品查看t_dish表taste_tags字段为菜品补充口味标签数据AI 接口调用超时网络不稳定或模型响应慢查看后端日志是否有超时异常调整超时时间增加备用模型接口大模型返回内容无法解析提示词输出格式不稳定打印大模型原始返回内容优化提示词限定 JSON 或纯标签输出格式小程序页面白屏JS 报错或路径错误打开开发者工具调试器 Console 面板根据报错修复页面逻辑启动时依赖冲突spring-boot 与 mybatis-plus 版本不匹配执行mvn dependency:tree查看依赖树统一 SpringBoot 与 MyBatis-Plus 版本10. 最佳实践与工程建议毕业设计不只是把功能跑通更要在论文和答辩中体现工程思维。下面这些建议是项目真正拉开差距的地方。10.1 代码规范包名统一使用com.example.aiorder尽量用有意义的类名。实体类用Data注解避免手写 Getter/Setter。Controller 只负责参数接收和结果返回不要写业务逻辑。Service 中处理业务Mapper 只操作数据。10.2 安全性第一大模型 API Key 必须放在后端配置里由环境变量注入不能出现在小程序代码或前端请求里。第二小程序端的登录要使用微信授权 code后端通过 code 换取 openid再建立自己的用户体系而不是直接拿前端传的用户 ID 做所有操作。第三管理端接口要增加管理员鉴权避免任意用户直接调用管理接口。10.3 推荐效果优化如果想让推荐结果更合理可以在行为标签计算中加入时间衰减。比如30 天前的行为权重为 0.5一周内的行为权重为 1.0。这样即使用户以前爱吃辣、最近口味变清淡推荐结果也能跟上变化。10.4 答辩准备这个题目答辩时老师大概率会问三个问题第一个问题推荐算法用了什么 回答思路基于标签的推荐结合用户行为数据统计口味偏好配合大模型冷启动解析。协同过滤是理论基础实际实现时简化成标签匹配保证响应速度。第二个问题大模型在系统里起什么作用 回答思路不承担全部推荐只负责两个环节——冷启动时解析自然语言、生成推荐解释。主链路还是传统算法这样可以解释为什么系统稳定、可控、成本低。第三个问题推荐效果怎么评价 回答思路可以用点击率或下单转化率来验证。项目里设计一张用户行为表如果用户看了推荐菜品之后产生了下单行为说明推荐有效。可以统计推荐位的下单转化率作为效果指标。10.5 版本管理开发过程中建议从第一天就用 Git 管理代码。后端、小程序、数据库脚本、论文文档分类存放在不同目录。即使只有一个人开发版本管理也能让你随时回退到可运行的状态避免改崩了无法恢复的尴尬局面。11. 总结与后续学习方向这个智能外卖点餐推荐系统本质上是一次整合实践。SpringBoot 处理业务与接口微信小程序解决用户触达MySQL 承载数据AI 大模型为推荐体验注入智能化能力。四者组合在一起形成了比普通管理系统更有技术深度的毕业设计选题。文章已经把核心的技术链路拆完了从需求分析到架构设计从数据库建模到后端实现从大模型接入到小程序开发从运行验证到答辩准备。照着这个思路推进每一步都清楚。接下来你可以按三个方向继续深入学习。第一个方向是推荐系统本身。学一下协同过滤、矩阵分解、向量召回把这些算法逐步替换掉现在用的标签匹配这就是从一个毕业设计项目迈向真实工业级推荐系统的一条学习路径。第二个方向是大模型应用开发。重点研究提示词工程、模型微调和 Agent 编排。当前大模型能力更新非常快用同一个系统接入 ChatGPT、文心一言、通义千问、DeepSeek 等模型只需要改配置和少量代码这个敏感性非常有价值。第三个方向是工程化能力。把项目部署到云服务器配置 HTTPS 域名接入微信支付完善日志和监控体系。如果这套都完成了你掌握的就已经超过“毕业设计”的层面了。如果有条件强烈建议把项目跑起来认真走一遍完整流程。遇到问题不要急回头查看第 9 节的排查表和系统日志大多数问题都能快速定位。祝项目顺利完成答辩顺利。 SpringBoot+微信小程序+AI大模型：智能外卖点餐推荐系统实战解析
每年到了毕业设计季节后台总有一堆同学在问同一个问题想做点有区分度的题目但选来选去都是“XX管理系统”“XX平台设计与实现”答辩时老师看一眼标题就失去了兴趣。这篇文章就围绕一个具体又比较有代表性的毕业设计题目展开基于 SpringBoot 微信小程序 AI 的智能外卖点餐推荐系统。先说判断这个项目真正的竞争点不在“外卖点餐”三个字而在“智能推荐”这四个字。传统的外卖点餐系统技术栈再完整也只是一个 CRUD 展示但当你把 AI 大模型接入到推荐环节让系统可以根据用户的历史行为、口味偏好甚至一段自然语言描述来推荐菜品时项目的技术含量和答辩说服力就完全不同了。接下来我会从选题分析、系统架构、数据库设计、SpringBoot 后端实现、微信小程序端实现、推荐引擎与大模型接入、运行验证、常见问题到工程建议把这个项目完整拆解一遍。就算你还没开始动手写代码看完这篇也能知道每一步该做什么、为什么这么做。1. 这篇文章真正要解决的问题很多计算机专业学生做毕业设计时会陷入两个极端。第一个极端是“为了求稳做一个纯管理系统”。用户管理、菜品管理、订单管理、公告管理再加几个图表统计完事。这类系统代码量大但技术含量低答辩时老师的提问基本集中在“你的创新点是什么”而这个问题往往答不上来。第二个极端是“盲目追新把项目做得过于复杂”。一上来就要做分布式、微服务、高并发、消息队列结果工作量失控写到一半写不下去反而连基本功能都完不成。这两个极端之间真正合适的方向是用主流可靠的技术栈完成一个有明确价值主张的业务系统并在一两个关键环节做出有深度的亮点。本文要拆解的智能外卖点餐推荐系统就是一个典型代表。它的技术栈是 SpringBoot 微信小程序 MyBatis-Plus AI 大模型业务范围是外卖点餐的完整闭环。它的差异化亮点是推荐模块不是简单地按销量排序而是结合用户行为数据和 AI 大模型能力给出有解释、有温度、可交互的推荐结果。这个题目的价值在于技术覆盖面广前后端分离、移动端小程序、数据库设计、接口开发、AI 能力接入一个项目把本科阶段的核心技能点都串起来了。工作量可控核心模块清晰可以按阶段推进不会出现做到一半失控的情况。答辩有亮点AI 推荐引擎是老师最容易感兴趣也最容易提问的部分只要原理讲清楚、效果能演示这就是论文和答辩的核心加分项。有真实业务场景支撑外卖点餐是所有人都熟悉的场景系统边界容易理解需求分析不会空洞。如果你正在犹豫毕业设计选题或者已经选了类似题目但不知道从哪下手这篇文章值得收藏细读。2. 智能外卖点餐推荐系统的核心概念在写代码之前先弄清楚三组关键概念推荐系统怎么工作、大模型在推荐里扮演什么角色、它们和外卖点餐场景怎么结合。2.1 推荐系统的基本逻辑推荐系统的本质是在“信息过载”的环境里帮助用户从大量选择中找到最可能感兴趣的内容。外卖平台上有几十上百个菜品用户不可能一一浏览。推荐系统要做的就是猜这个用户现在最想吃什么。常见的推荐算法有三类推荐类型核心逻辑比喻适合场景基于协同过滤“和你口味相似的人也在吃这些”朋友推荐有大量用户行为数据基于内容推荐“你过去爱吃辣所以推荐辣味菜品”口味画像用户历史行为明确混合推荐多种策略加权组合取长补短综合顾问实际系统的主流方案在外卖场景下协同过滤有一个现实难题如果用户是新用户或者订单数据很少协同过滤就无从算起。这就是所谓“冷启动问题”。解决冷启动传统方案是“热门兜底”也就是推荐销量最高、评分最好的菜品。而在这个项目里我们可以用 AI 大模型做更高级的冷启动处理让用户用一句话描述今天想吃什么系统基于自然语言理解来推荐。这是传统推荐系统做不到的。2.2 大模型在推荐系统中的角色大模型不是来替代整个推荐系统的而是作为其中一个关键组件负责两件事第一理解用户的自然语言输入。传统系统里用户只能点按钮、选分类、看列表接入了大模型之后用户可以输入“今天想吃点清淡的不要太辣适合一个人吃”系统解析出关键词口味清淡、不吃辣、一人食然后到菜品库中匹配候选集。第二生成推荐解释。推荐系统算出结果之后如果只是丢给用户一个菜品列表说服力有限。大模型可以为每个推荐结果生成一句推荐语比如“这道番茄鸡蛋汤口味清淡酸甜开胃一个人吃刚刚好适合今天没什么胃口的你”。这大大提升了用户体验也能在答辩时作为“AI 能力落地”的直接证据。2.3 系统里有哪些角色一个完整的外卖点餐推荐系统至少要包含三种角色普通用户浏览菜品、搜索、下单、查看订单、查看个性化推荐。管理员管理菜品分类、菜品信息、用户状态、订单状态、推荐策略配置。系统后台服务处理业务逻辑调用推荐引擎和大模型接口。这三类需求叠加起来系统的功能边界就清楚了。3. 系统架构与技术选型这个项目的架构属于典型的小型前后端分离架构。它不追求微服务级别的拆分但要求层次清晰、职责分明。整体架构分为三层第一层是微信小程序端承担用户交互。用户在小程序里浏览菜品、查看推荐、下单支付、管理个人信息。小程序通过 HTTP 请求调用后端接口数据交换格式为 JSON。第二层是SpringBoot 后端服务承担业务逻辑。后端分成控制层、服务层、数据访问层。控制层负责接收请求和返回结果服务层实现具体业务比如下单流程、推荐流程数据访问层使用 MyBatis-Plus 操作数据库。第三层是数据与外部能力层包括 MySQL 数据库存储业务数据以及 AI 大模型接口能力。大模型接口在这一层以 HTTP 的方式被后端服务调用后端不直接面向小程序暴露大模型的密钥和配置。这种分层的好处是每一层都可以独立修改和替换。比如今天接的是某一个云端大模型接口明天想换成本地部署的模型只需要修改后端调用大模型的 Service 实现小程序端完全不用动。核心模块划分如下模块主要功能涉及技术用户模块微信登录、用户信息维护SpringBoot、MyBatis-Plus菜品模块分类浏览、菜品详情SpringBoot、MySQL订单模块购物车、下单、订单查询SpringBoot、MyBatis-Plus推荐模块相似菜品推荐、大模型个性化推荐推荐算法、AI 大模型接口管理模块菜品管理、订单管理、推荐管理SpringBoot、Vue 或原生页面这里要特别提醒一点不要在一开始就追求复杂架构。把 SpringBoot 工程拆成 controller / service / mapper 三个标准包再加上一个 config 包和一个 common 包对毕业设计来说完全足够也方便论文画架构图。4. 环境准备与数据库设计4.1 开发环境清单在动手之前先把环境准备好。以下环境以实际安装版本为准本文侧重通用实现思路不在版本号上死磕。JDK 1.8 或 17推荐使用稳定版本。Maven 3.6 以上用于依赖管理。MySQL 5.7 或 8.0存储业务数据。微信开发者工具用于运行小程序端。IDEA 或 Eclipse用于后端开发。一个可用的 AI 大模型接口本文以兼容 OpenAI 格式的 API 为例也可以用国内大模型平台的接口只需替换 SDK 和 base-url。4.2 数据库设计数据库是业务系统的地基。这个项目建议设计如下核心表用户表 t_userCREATE TABLE t_user ( id bigint(20) NOT NULL AUTO_INCREMENT, openid varchar(64) DEFAULT NULL COMMENT 微信openid, nickname varchar(50) DEFAULT NULL COMMENT 昵称, avatar varchar(255) DEFAULT NULL COMMENT 头像, phone varchar(20) DEFAULT NULL COMMENT 手机号, taste_tag varchar(255) DEFAULT NULL COMMENT 口味偏好标签如辣、清淡, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;菜品表 t_dishCREATE TABLE t_dish ( id bigint(20) NOT NULL AUTO_INCREMENT, category_id bigint(20) DEFAULT NULL COMMENT 分类id, name varchar(100) DEFAULT NULL COMMENT 菜品名称, description varchar(500) DEFAULT NULL COMMENT 菜品描述, price decimal(10,2) DEFAULT NULL COMMENT 价格, image varchar(255) DEFAULT NULL COMMENT 图片地址, spicy_level int(11) DEFAULT 0 COMMENT 辣度0不辣 1微辣 2中辣 3特辣, taste_tags varchar(255) DEFAULT NULL COMMENT 口味标签如清淡、重口、甜口, sales_count int(11) DEFAULT 0 COMMENT 销量, status int(11) DEFAULT 1 COMMENT 上架状态 1上架 0下架, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT菜品表;用户行为表 t_user_behaviorCREATE TABLE t_user_behavior ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) DEFAULT NULL COMMENT 用户id, dish_id bigint(20) DEFAULT NULL COMMENT 菜品id, behavior_type varchar(20) DEFAULT NULL COMMENT 行为类型view点赞、order下单、collect收藏, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户行为记录表;订单表 t_order和订单明细表 t_order_item也必不可少订单表记录订单号、用户、总金额、状态订单明细表记录每个订单包含哪些菜品、数量、单价。这里的设计思路是推荐系统的基础数据来自用户的真实行为。用户浏览了哪些菜、收藏了哪些菜、下单了哪些菜这些行为是判断用户口味偏好的原始依据。如果项目演示阶段缺少真实数据可以写一个数据初始化脚本批量生成模拟用户行为数据。5. SpringBoot 后端核心实现SpringBoot 是整个系统的中枢。下面按依赖、配置、代码三层来拆解。5.1 Maven 依赖在pom.xml中引入核心依赖SpringBoot Web、MyBatis-Plus、MySQL 驱动、Lombok以及大模型 HTTP 调用所需的工具包。!-- 文件路径pom.xml -- dependencies !-- SpringBoot Web -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- MyBatis-Plus -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency !-- MySQL 驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- Lombok -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency !-- Hutool 工具包封装了 HTTP 请求 -- dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.18/version /dependency /dependenciesHutool 在调用大模型 API 时非常方便不需要额外引入 Feign 或 RestTemplate 的复杂配置。5.2 application.yml 配置# 文件路径src/main/resources/application.yml server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/ai_order?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password servlet: multipart: max-file-size: 10MB mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 # AI 大模型接口配置 ai: model: api-key: your_api_key_here base-url: https://your-model-endpoint.com/v1 model-name: your-model-name这里最需要强调的是ai.model.api-key。这个配置项绝对不能写死在小程序前端也不能提交到公开的代码仓库。实际项目里建议通过环境变量或配置中心注入比如api-key: ${AI_API_KEY}。5.3 菜品推荐接口实现推荐模块是核心亮点单独拆出来讲。推荐接口的流程是用户进入小程序首页请求/api/recommend/list。后端拿到用户 ID查询用户历史行为记录。如果用户行为数据充足使用基于用户的协同过滤思想找到相似用户推荐他们喜欢的菜品。如果用户行为数据不足使用用户输入的偏好文本调用大模型解析口味关键词然后按标签匹配菜品。最终结果统一包装成RecommendResponse返回给小程序。先定义一个菜品实体// 文件路径src/main/java/com/example/aiorder/entity/Dish.java Data TableName(t_dish) public class Dish { TableId(type IdType.AUTO) private Long id; private Long categoryId; private String name; private String description; private BigDecimal price; private String image; private Integer spicyLevel; private String tasteTags; private Integer salesCount; private Integer status; }再写推荐服务的核心逻辑// 文件路径src/main/java/com/example/aiorder/service/RecommendService.java Service public class RecommendService { Resource private DishMapper dishMapper; Resource private UserBehaviorMapper behaviorMapper; Resource private AiModelService aiModelService; public ListDish recommend(Long userId, String userInput) { // 1. 查询用户历史行为统计兴趣标签 ListUserBehavior behaviors behaviorMapper.selectList( new LambdaQueryWrapperUserBehavior() .eq(UserBehavior::getUserId, userId) .orderByDesc(UserBehavior::getCreateTime) .last(limit 50) ); // 2. 根据行为记录计算用户口味标签权重 MapString, Integer tagWeight new HashMap(); if (behaviors.isEmpty() StrUtil.isNotBlank(userInput)) { // 3. 冷启动调用大模型解析用户输入提取标签 ListString tags aiModelService.analyzeUserInput(userInput); return matchDishByTags(tags); } // 4. 有行为数据基于标签权重推荐 for (UserBehavior behavior : behaviors) { Dish dish dishMapper.selectById(behavior.getDishId()); if (dish ! null StrUtil.isNotBlank(dish.getTasteTags())) { for (String tag : dish.getTasteTags().split(,)) { tagWeight.put(tag, tagWeight.getOrDefault(tag, 0) 1); } } } // 5. 按权重排序取 Top 标签再匹配菜品 ListString topTags tagWeight.entrySet().stream() .sorted(Map.Entry.String, IntegercomparingByValue().reversed()) .limit(3) .map(Map.Entry::getKey) .collect(Collectors.toList()); return matchDishByTags(topTags); } private ListDish matchDishByTags(ListString tags) { // 按标签模糊匹配菜品并按销量排序 return dishMapper.selectList( new LambdaQueryWrapperDish() .eq(Dish::getStatus, 1) .like(StrUtil.isNotBlank(tags.get(0)), Dish::getTasteTags, tags.get(0)) .orderByDesc(Dish::getSalesCount) .last(limit 10) ); } }控制层接口// 文件路径src/main/java/com/example/aiorder/controller/RecommendController.java RestController RequestMapping(/api/recommend) public class RecommendController { Resource private RecommendService recommendService; GetMapping(/list) public ResultListDish recommend( RequestParam(required false) Long userId, RequestParam(required false) String userInput) { ListDish dishes recommendService.recommend(userId, userInput); return Result.success(dishes); } }这个实现有几个关键点值得注意。第一LambdaQueryWrapper是 MyBatis-Plus 提供的条件构造器用起来比手写 XML 高效很多也是毕业设计代码里的加分细节。第二冷启动处理是推荐系统的核心难点。这里用了“用户没有行为数据时通过自然语言输入 大模型标签提取”的方案比单纯返回热门菜品更有技术说服力。第三推荐过程不是一次性把大模型接口放到主链路里而是先标签化、再匹配、再排序这样可以保证接口响应速度。直接让大模型生成整个推荐列表响应慢且结果不可控这是实际系统里的常见坑。6. 大模型接入与提示词工程大模型在这个项目里除了做冷启动标签解析还可以做推荐解释生成。这部分是答辩时的展示亮点。6.1 大模型调用服务// 文件路径src/main/java/com/example/aiorder/service/AiModelService.java Service public class AiModelService { Value(${ai.model.api-key}) private String apiKey; Value(${ai.model.base-url}) private String baseUrl; Value(${ai.model.model-name}) private String modelName; public ListString analyzeUserInput(String userInput) { String prompt buildPrompt(userInput); String response callModel(prompt); return parseTags(response); } public String generateRecommendReason(String dishName, String userInput) { String prompt 请用一句话为菜品【 dishName 】生成推荐理由 用户的需求是 userInput 。要求语言自然、贴合场景不超过30个字。; return callModel(prompt); } private String callModel(String prompt) { MapString, Object params new HashMap(); params.put(model, modelName); params.put(messages, new Object[]{ Map.of(role, user, content, prompt) }); params.put(temperature, 0.7); String body JSONUtil.toJsonStr(params); HttpResponse response HttpRequest.post(baseUrl /chat/completions) .header(Authorization, Bearer apiKey) .header(Content-Type, application/json) .body(body) .timeout(10000) .execute(); return response.body(); } }6.2 提示词模板提示词直接决定了大模型输出质量。同一个需求提示词写得好不好效果差异巨大。弱提示词请根据用户的输入推荐菜品。强提示词你是一个专业的美食推荐助手。请从用户的描述中提取口味标签标签范围包括辣、清淡、甜口、酸口、重口、素食、低脂、一人食、多人聚餐。 用户描述${userInput} 请只输出标签列表用逗号分隔不要输出其他内容。强提示词的要点是定义角色、明确任务、限定输出格式。这样大模型就不会输出一大堆解释而是乖乖返回“清淡,一人食,不辣”这样的结构化标签。提示词要单独写成一个常量类方便调优和论文里展示。6.3 大模型与推荐链路的关系要清楚一点大模型不是推荐的主体而是推荐链路上的辅助组件。推荐的主体还是基于用户行为和标签匹配的算法逻辑。大模型负责两件事解析语义标签、生成推荐语。这样设计有实际好处。第一响应速度快。菜品匹配和排序走数据库索引毫秒级返回大模型只用在小概率的冷启动和解释生成场景。第二结果稳定。数据库标签匹配的结果是可复现的不会出现同一个用户两次请求推荐结果完全不一样的情况。第三成本可控。大模型按调用次数计费如果每次请求都调用大模型成本高且答辩演示时万一网络不通整个推荐模块就瘫痪了。7. 微信小程序端实现小程序端是用户直接接触的界面好坏直接影响演示效果。小程序包括四个核心页面首页、点餐页、购物车与订单页、个人中心页。7.1 首页推荐展示首页进入时调用推荐接口渲染推荐菜品列表。用户可以在顶部搜索框输入口味偏好比如“今天想吃点辣的开开胃”然后触发推荐。// 文件路径pages/index/index.js Page({ data: { recommendList: [], userInput: }, onLoad() { this.fetchRecommend(); }, fetchRecommend(input) { const app getApp(); wx.request({ url: app.globalData.baseUrl /api/recommend/list, method: GET, data: { userId: app.globalData.userId, userInput: input }, success: (res) { if (res.data.code 200) { this.setData({ recommendList: res.data.data }); } } }); }, onInputChange(e) { this.setData({ userInput: e.detail.value }); }, onSearch() { this.fetchRecommend(this.data.userInput); } });对应的小程序页面结构!-- 文件路径pages/index/index.wxml -- view classsearch-bar input placeholder输入你的口味偏好例如想吃清淡的 bindinputonInputChange / button bindtaponSearch智能推荐/button /view view classrecommend-list view classdish-card wx:for{{recommendList}} wx:keyid image src{{item.image}} / view classdish-info text classdish-name{{item.name}}/text text classdish-desc{{item.description}}/text text classdish-price{{item.price}}/text button bindtapaddToCart>// 文件路径pages/cart/cart.js submitOrder() { const cartList this.data.cartList; const app getApp(); wx.request({ url: app.globalData.baseUrl /api/order/create, method: POST, data: { userId: app.globalData.userId, items: cartList.map(item ({ dishId: item.id, quantity: item.quantity })) }, success: (res) { if (res.data.code 200) { wx.showToast({ title: 下单成功 }); this.setData({ cartList: [] }); } } }); }后端订单创建的代码这里先不做完整展开核心逻辑是事务开启后先写入订单主表再循环写入订单明细表同时扣减菜品销量字段最后提交事务。涉及金额和库存的操作事务是必须的。需要提醒的是如果项目涉及微信支付需要小程序具备微信支付商户号资质。如果是毕业设计演示一般建议把支付模块做成模拟支付也就是在界面上提供一个“模拟支付”按钮跳到支付成功页。这样既不影响完整流程演示也不会卡在资质审核上。8. 运行效果与验证方法项目写完以后验证环节不能省。按下面顺序操作能较快发现问题。8.1 后端启动mvn clean package -DskipTests java -jar target/ai-order-0.0.1-SNAPSHOT.jar看到类似输出说明启动成功Tomcat started on port(s): 8080 (http) Started AiOrderApplication in 5.23 seconds8.2 接口验证启动后端后用浏览器直接访问推荐接口http://localhost:8080/api/recommend/list?userId1userInput想吃清淡的预期返回 JSON 格式的菜品列表。如果返回了菜品数据说明数据库连接、MyBatis-Plus 映射、推荐逻辑都正常。8.3 小程序端验证在微信开发者工具中导入小程序项目修改app.js里的baseUrl指向本机局域网 IP 或已部署的服务器地址。验证时重点检查几个场景新用户首次进入不输入任何内容能看到“热门推荐”兜底菜品。新用户输入“想吃点辣的”推荐结果与辣味菜品匹配。老用户多次浏览和收藏某类菜品后推荐结果中同类菜品占比上升。用户可以将菜品加入购物车、提交订单、在订单列表看到订单记录。管理员后台可以新增菜品客户端刷新后能看到新菜品。如果第 2 项和第 3 项表现不明显最可能的原因是菜品数据里没有维护taste_tags字段或者行为数据太少。解决方法是先造一批带有明确标签的菜品数据再生成足够的模拟行为数据。9. 常见问题与排查思路问题现象可能原因排查方式解决方案后端启动报数据库连接失败MySQL 未启动或账号密码错误查看日志中最后一条异常堆栈检查数据库服务和application.yml配置小程序请求接口报 500后端接口异常打开浏览器直接访问接口查看后端控制台日志根据异常堆栈修复代码常见是 SQL 错误或空指针小程序请求接口报 404请求路径与后端接口不一致对比控制层RequestMapping和小程序 URL统一接口路径建议用常量管理推荐结果为空数据库中无匹配标签的菜品查看t_dish表taste_tags字段为菜品补充口味标签数据AI 接口调用超时网络不稳定或模型响应慢查看后端日志是否有超时异常调整超时时间增加备用模型接口大模型返回内容无法解析提示词输出格式不稳定打印大模型原始返回内容优化提示词限定 JSON 或纯标签输出格式小程序页面白屏JS 报错或路径错误打开开发者工具调试器 Console 面板根据报错修复页面逻辑启动时依赖冲突spring-boot 与 mybatis-plus 版本不匹配执行mvn dependency:tree查看依赖树统一 SpringBoot 与 MyBatis-Plus 版本10. 最佳实践与工程建议毕业设计不只是把功能跑通更要在论文和答辩中体现工程思维。下面这些建议是项目真正拉开差距的地方。10.1 代码规范包名统一使用com.example.aiorder尽量用有意义的类名。实体类用Data注解避免手写 Getter/Setter。Controller 只负责参数接收和结果返回不要写业务逻辑。Service 中处理业务Mapper 只操作数据。10.2 安全性第一大模型 API Key 必须放在后端配置里由环境变量注入不能出现在小程序代码或前端请求里。第二小程序端的登录要使用微信授权 code后端通过 code 换取 openid再建立自己的用户体系而不是直接拿前端传的用户 ID 做所有操作。第三管理端接口要增加管理员鉴权避免任意用户直接调用管理接口。10.3 推荐效果优化如果想让推荐结果更合理可以在行为标签计算中加入时间衰减。比如30 天前的行为权重为 0.5一周内的行为权重为 1.0。这样即使用户以前爱吃辣、最近口味变清淡推荐结果也能跟上变化。10.4 答辩准备这个题目答辩时老师大概率会问三个问题第一个问题推荐算法用了什么 回答思路基于标签的推荐结合用户行为数据统计口味偏好配合大模型冷启动解析。协同过滤是理论基础实际实现时简化成标签匹配保证响应速度。第二个问题大模型在系统里起什么作用 回答思路不承担全部推荐只负责两个环节——冷启动时解析自然语言、生成推荐解释。主链路还是传统算法这样可以解释为什么系统稳定、可控、成本低。第三个问题推荐效果怎么评价 回答思路可以用点击率或下单转化率来验证。项目里设计一张用户行为表如果用户看了推荐菜品之后产生了下单行为说明推荐有效。可以统计推荐位的下单转化率作为效果指标。10.5 版本管理开发过程中建议从第一天就用 Git 管理代码。后端、小程序、数据库脚本、论文文档分类存放在不同目录。即使只有一个人开发版本管理也能让你随时回退到可运行的状态避免改崩了无法恢复的尴尬局面。11. 总结与后续学习方向这个智能外卖点餐推荐系统本质上是一次整合实践。SpringBoot 处理业务与接口微信小程序解决用户触达MySQL 承载数据AI 大模型为推荐体验注入智能化能力。四者组合在一起形成了比普通管理系统更有技术深度的毕业设计选题。文章已经把核心的技术链路拆完了从需求分析到架构设计从数据库建模到后端实现从大模型接入到小程序开发从运行验证到答辩准备。照着这个思路推进每一步都清楚。接下来你可以按三个方向继续深入学习。第一个方向是推荐系统本身。学一下协同过滤、矩阵分解、向量召回把这些算法逐步替换掉现在用的标签匹配这就是从一个毕业设计项目迈向真实工业级推荐系统的一条学习路径。第二个方向是大模型应用开发。重点研究提示词工程、模型微调和 Agent 编排。当前大模型能力更新非常快用同一个系统接入 ChatGPT、文心一言、通义千问、DeepSeek 等模型只需要改配置和少量代码这个敏感性非常有价值。第三个方向是工程化能力。把项目部署到云服务器配置 HTTPS 域名接入微信支付完善日志和监控体系。如果这套都完成了你掌握的就已经超过“毕业设计”的层面了。如果有条件强烈建议把项目跑起来认真走一遍完整流程。遇到问题不要急回头查看第 9 节的排查表和系统日志大多数问题都能快速定位。祝项目顺利完成答辩顺利。