SpringBoot整合大语言模型：电商销售分析系统设计实现

每年到了毕设季，后台就会涌进来大量关于电商系统和数据分析的提问。今年问得最猛的方向，已经从单纯的“基于SpringBoot的电商系统”进化成“基于SpringBoot的大语言模型电商销售情况分析系统”。这个题目看起来新，实际上踩中的是最近两年电商数据分析和AI落地结合的典型需求：既要有传统后端框架的工程能力，又要体现大语言模型在业务分析里的实际价值。

我完整跑通了这样一个项目，从数据库设计、模拟数据生成、SpringBoot后端接口开发、ECharts可视化大屏，到本地部署大语言模型并把它集成进系统做销售报告生成和智能问答，最后整理出源码、设计文档、部署说明和演示视频。这篇文章就把整个过程拆开讲透，包括思路、架构、核心代码逻辑、模型选型，以及我实际踩过的坑。这篇文章适合两类人：一类是正在纠结毕设题目和实现的同学，另一类是想把大语言模型引入业务系统的开发者，哪怕你不是做毕设，这套集成思路也能直接迁移到真实项目里。

1. 整体设计与思路拆解

1.1 为什么选这个题目：电商+大模型能做出差异化

先说选题逻辑。很多同学看到“电商销售分析系统”就头大，觉得这是十年前就做烂的方向。确实，如果只是SSM加个ECharts图表，随便搜搜就是几十套雷同代码，答辩老师一眼就能看出来你没花心思。

但加了“大语言模型”这个关键字，整个项目的层次就不一样了。电商销售分析的老问题是：数据报表做出来，一大堆折线图饼图堆在页面上，非技术背景的使用者根本不知道数据变化背后的原因是什么。传统系统的极限是“告诉用户发生了什么”，比如销售额下降了15%，但为什么下降，是因为某品类缺货、还是某区域物流延误、还是价格调整导致的用户流失？这些问题靠规则引擎很难回答，而大语言模型擅长从结构化数据里提取模式、生成可读的自然语言解释。

所以这个题目的核心价值不是“做一个模型”，而是“让模型能看懂系统里的销售数据，并且用中文把结论和原因讲清楚”。这样一个题目，技术栈上覆盖了Java后端全家桶、数据分析、AI接入，答辩时不管是问框架原理、问SQL优化还是问AI工程化，你都能接得住话。

1.2 系统功能拆分：从数据到报告的内容链路

整个系统做下来，功能模块可以拆成五大块：

• 商品管理模块：商品的增删改查、分类管理、价格库存维护。
• 订单与用户模块：订单列表、订单详情、用户管理、用户消费行为记录。
• 销售统计分析模块：按时间维度、品类维度、地区维度、价格带维度做聚合统计。
• 数据可视化模块：用ECharts做销售总览大屏，包括销售额趋势、品类占比、TOP10商品、区域销售地图。
• 大语言模型分析模块：基于统计结果生成销售周报、月报、经营建议，支持对库存数据、销售数据进行自然语言提问。

这套设计的核心思路是：前面的传统模块负责“采集和整理数据”，统计模块负责“把数据变成指标”，大语言模型模块负责“把指标变成洞察”。每一层的输出都是下一层的输入，链路清晰，演示的时候一条线能讲完。

需要注意的是，分析模块不应该直接让模型去查数据库，而是先把数据聚合好，再把聚合结果作为上下文喂给模型。这个设计后面会细说，但你必须一开始就定下来，不然后面会乱。

1.3 核心技术选型：为什么用了这套技术组合

技术栈我最终敲定的是：SpringBoot 2.7 + MyBatis-Plus + MySQL 8.0 + Redis + Vue 3 + ECharts，大语言模型部分用本地方案，配合开源模型权重。这套组合是经过几轮测试才最终定下来的，主要原因有几点。

第一，SpringBoot框架本身是当前Java后端开发的实际标准，毕设题目里已经明确指定用它，那就不折腾别的框架。而且SpringBoot的自动装配和起步依赖能极大降低集成成本，尤其是连Redis、连数据库这些常规操作，基本是配置即用。

第二，大语言模型部分采用本地部署而非全部依赖云端API。原因很现实：毕设答辩现场网络环境不可控，万一现场调云端接口超时，演示就翻车了。本地部署虽然对电脑配置有一点要求，但至少保证任何时候都能跑、都能演示。而且本地部署避开了“接口收费”“免费额度用完”这种尴尬问题，并可以让你在论文里明确写出“本系统采用本地化部署方案，保障数据隐私”，这句话在评审老师那里是加分项。

第三，数据库用了MySQL而不是更重的大数据组件。这个项目虽然带了“大数据”三个字，但毕设场景下的“大数据”应该理解为“大数据处理思路”，而不是强行上Hadoop或者Spark集群。你可以在架构图上体现分布式思维，在代码里用索引优化、分页查询、聚合统计去模拟千万级数据的处理逻辑，但没必要在毕设里真搭三台服务器做集群。我的实际做法是：用造数工具生成百万量级的订单数据，再通过MySQL的GROUP BY和合理的索引来完成统计。这个量级下，MySQL完全扛得住，而且答辩时候可以理直气壮地讲“本方案在百万级数据规模下保持亚秒级响应”。

2. 核心模块解析与实操要点

2.1 数据层设计：订单、商品、用户三张主表怎么建

数据表设计是整个系统的地基。我建表的时候没有搞得很复杂，核心就三张主表加两张辅助表，下面列出关键字段。

订单表（orders）：

• id：主键
• order_no：订单编号，唯一索引
• user_id：用户ID，外键关联用户表
• product_id：商品ID，外键关联商品表
• quantity：购买数量
• amount：订单金额
• order_status：订单状态（已支付/已发货/已完成/已取消）
• payment_time：支付时间
• create_time：下单时间

商品表（product）：

• id：主键
• product_name：商品名称
• category_id：分类ID
• price：售价
• cost_price：成本价
• stock：库存
• sales_count：销量
• status：上下架状态

用户表（user）：

• id：主键
• username：用户名
• gender：性别
• age：年龄
• city：所在城市
• register_time：注册时间
• last_login_time：最近登录时间

订单明细表（order_item）：订单主表之外还需要一个明细表，记录每笔订单下面的商品子项，因为真实电商场景里一单可能买多个商品。不过如果为了简化，也可以直接在订单表里冗余商品ID，按“一单一个商品”处理。我这里为了演示效果，保留了明细表，但二开的时候可以按自己的工作量决定。

表设计时我强烈建议加一个“每日汇总表”，比如sales_daily_summary，字段包括日期、品类、总销售额、总订单数、总销量、客单价。这张表不存原始明细，而是通过定时任务或批量脚本从订单表聚合而来。为什么需要它？因为大语言模型要生成周报月报，如果每次都在几十万条订单上实时跑GROUP BY再喂给模型，响应时间会非常感人。有了汇总表，模型只需要读取几十条聚合结果就能进行总结。这也是真实BI系统里的常见做法：明细数据进数仓，报表数据进汇总表。

2.2 模拟数据生成：百万级电商数据怎么造

真实项目里数据来自业务积累，但毕设系统没有真实用户，所以必须自己造数据。这里我吃过一个亏：一开始直接用SQL的INSERT一条条写，结果写了几百条就放弃了，效率极低。后来改用Python的Faker库写脚本批量生成，效果立竿见影。

造数的脚本思路是这样：先生成用户表，比如5万用户，包括用户名、城市、性别、年龄区间；再生成商品表，比如200个商品，分布在10个品类下；最后根据业务规则生成订单数据，比如模拟一年内的订单，每天几千到几万单不等。

订单金额的生成要符合电商规律，不能纯随机。纯随机数生成的销售额曲线是一条毫无规律的毛刺线，看着特别假。我采用的做法是：给每个品类设定一个基准日销量系数，再叠加周几波动的系数，周一低、周末高；再叠加一个缓慢的上升趋势系数，模拟店铺逐渐起量的过程。这样生成出来的销售曲线，既有明显的周期性，又有宏观趋势，图表展示效果非常自然。

导入MySQL时，如果数据量到了百万级，逐条INSERT会慢到让人怀疑人生。我用的是LOAD DATA方式批量导入，几十万条数据十几秒就能完成。如果你不想装Python环境，也可以直接在Java里写一个初始化Runner，项目启动时调用它来造数，但总体效率不如脚本高。

另外强烈建议：给统计查询涉及到的字段建立索引，尤其是订单表的payment_time、product_id、user_id，还有汇总表的date字段。没有索引的时候，一条聚合SQL跑全表扫描可能要几十秒，加上联合索引之后基本都能优化到几百毫秒以内。这个优化点答辩时一定要写在论文里，属于实打实的性能调优内容。

2.3 可视化大屏的落地细节：ECharts的实用配置

ECharts这块，我踩过的坑比后端还多，重点讲三个实用经验。

第一，数据格式的设计要提前和后端对齐。比如后端返回的销售趋势数据是[{date: "2025-04-01", amount: 12345}, ...]，那么前端ECharts的x轴数据就得用map方法把date字段提取成数组。如果前后端各干各的，联调时八成要返工。我建议在后端统一设计一个返回结构VO，比如SalesTrendVO、CategorySalesVO、TopProductVO，每个VO对应一张图的数据需求，这样前端组件只需按VO接数据就行。

第二，图表容器要有固定高度。ECharts初始化时，如果父容器的height为0或者未设置，图表会初始化失败或者显示空白。我一开始用flex布局，图表div没有设高度，结果画面只显示几个tab不显示图。解决办法是每个图表的容器都显式设置高度，比如style="height: 400px; width: 100%"。这条经验看似基础，但真的能卡掉一堆人。

第三，大屏自动滚动和定时刷新。作为演示系统，页面如果死板地静态展示会显得不够“智能”。我加了一个定时器，每30秒请求一次最新统计接口，刷新各个图表数据，并在大屏首部做了一个“数据更新时间”的动态标签。这样演示时就能说“系统实现了近实时数据监测”，又是个加分细节。

另外做区域销售地图时，需要用到中国地图GeoJSON数据。如果你用的ECharts版本比较新，地图数据可能已经不再内置，需要单独引入或者注册地图。这一步容易绕弯路，建议直接用已经封装好的地图数据文件，在main.js里全局注册一次，之后就能正常使用。

3. 大语言模型集成：本地部署与SpringBoot对接实战

3.1 本地部署方案选型：从Ollama到外置模型服务

大语言模型接入这一章，应该是这个毕设内容最核心的一块，也是论文里最值得大写特写的地方。

我首先排除了直接调用云端API方式，不是因为它不好，而是因为毕设演示环境不稳定，而且答辩现场的网络情况不可控。此外，论文若是写“调用云端接口”，评审可能追问“如果是企业敏感数据怎么办”，这个问题不好回答。反过来，如果写“本地化部署，数据不出内网”，就非常稳妥。

本地部署工具我使用的是目前社区最主流的推理框架：Ollama。它在Windows下安装很简单，装完之后通过命令行就能拉取开源模型权重，并暴露一个本地调用地址，SpringBoot通过HTTP请求即可完成对话。我这里不展开讲下载来源相关的内容，只讲工程接入层面的逻辑：它本质上是在你电脑上启动了一个本地推理服务，默认监听在127.0.0.1的某个端口，你只需要拿到这个服务地址，就能在代码里调用它。

模型选型方面，毕设场景不需要追求超大参数模型，7B到14B量级的开源模型就够用了。参数越小，响应越快，电脑也跑得动。我用默认的7B模型跑销售分析任务，生成几百字的报告大概需要10到20秒，属于可接受范围。如果你电脑配置较低（建议至少16G内存，显卡至少8G显存），也可以考虑更小的量化版本，效果略有牺牲但速度更快。

对于开发联调，还有个免费方案值得一提：某些大模型云厂商会提供免费的开发测试额度，你可以用这个额度来验证提示词的效果，等提示词稳定了再切换到本地模型。不过这只作为开发阶段加速手段，最终演示还是以本地为准。

3.2 提示词工程：让模型输出结构化报告

大语言模型接入代码并不难，难的是让模型输出真正符合业务需求的报告。如果直接把一堆统计数字丢给它，然后说“帮我分析一下”，它可能输出一大段泛泛而谈的话，比如“销售额总体保持稳定，建议继续加大营销力度”，这种内容毫无信息量。

我的做法是设计了一套结构化的提示词模板，要求模型按照指定格式输出。核心思路是：明确角色、明确输入数据、明确输出要求、明确输出格式。

举个例子，生成销售周报的提示词如下：

text复制你是一名资深的电商运营分析师。下面给你一周的销售统计数据，包括销售额、订单量、客单价、各品类销售占比、TOP5商品、销量下滑明显的品类。请你完成以下任务：
1. 总结本周整体销售表现。
2. 指出增长和下滑最明显的品类，并分析可能原因。
3. 给出3条可执行的运营建议。
要求：回答使用中文，分点输出，不要泛泛而谈，每条建议必须结合给定数据给出具体依据。

然后，在代码里把统计数据拼接成JSON格式放在提示词尾部。这样做出来的报告，每一句话都能对应到具体数据，比如“本周休闲食品品类销售额环比下降18%，其中坚果类贡献了主要下降，结合库存数据显示坚果库存偏高，建议下周开始进行满减促销”。这种报告拿到答辩现场，效果和“模板报告”天差地别。

为了让模型输出格式更稳定，我还在系统里加了“JSON模式”或者说“结构化输出模式”的选项，让模型返回固定结构的JSON，再由后端解析成报告对象存储在数据库里。这样报告不仅能展示在前端，还能导出成Excel、Word或PDF，成为系统的正式功能之一。

3.3 SpringBoot接入代码：从HTTP调用到流式返回

SpringBoot对接本地模型服务的代码并不复杂。我封装了一个LLMService，核心方法是通过HTTP客户端调用本地模型服务的生成接口。下面给出简化版代码逻辑。

java复制@Service
public class LLMAnalyzeService {

    private final RestTemplate restTemplate;

    public LLMAnalyzeService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public String generateReport(String systemPrompt, String userData) {
        // 本地模型服务地址，确保服务已启动
        String modelUrl = "http://127.0.0.1:11434/api/generate";

        Map<String, Object> requestBody = new HashMap<>();
        requestBody.put("model", "qwen2.5:7b");
        requestBody.put("prompt", systemPrompt + "\n" + userData);
        requestBody.put("stream", false);

        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_JSON);
        HttpEntity<Map<String, Object>> request = new HttpEntity<>(requestBody, headers);

        ResponseEntity<Map> response = restTemplate.postForEntity(modelUrl, request, Map.class);
        if (response.getStatusCode().is2xxSuccessful() && response.getBody() != null) {
            return (String) response.getBody().get("response");
        }
        return "模型调用失败，请检查本地模型服务是否正常启动";
    }
}

如果你用的是SpringBoot 3.x，需要把RestTemplate替换为新的WebClient，或者配置一个RestTemplate的Bean，这属于版本适配问题，后面讲踩坑时会细说。

调用接口的时机建议这样设计：当用户在前端点击“生成本周销售报告”按钮时，后端先从MySQL聚合统计出本周关键指标，然后调用LLMAnalyzeService，等模型返回后把结果保存到report表中，再把完整报告返回到前端。整个过程是同步的，所以前端要加一个loading状态，否则用户会误以为页面卡死。

如果想要更好的体验，可以改成WebFlux或者SSE流式返回，让报告文字像ChatGPT一样一个字一个字地蹦出来。这个效果演示时非常炫酷，但会提升整个系统的复杂度。我在正式版里做的是同步返回，演示视频里另外录了一个流式展示的小demo，既展示了技术能力，又没把主体系统搞得太复杂。如果你的实力允许，直接上SSE流式输出，论文里能多写一章。

3.4 智能问答与语义分析场景：让模型理解业务口径

除了报告生成，大语言模型模块还承担了“智能业务问答”的功能。这个功能说白了就是：用户在前端输入一个自然语言问题，系统返回一个自然语言答案。

但这里有个关键点：不能让大语言模型自己编造数据。我的处理方式是做了“意图识别 + 参数抽取 + 数据查询 + 答案生成”四步流水线。比如用户输入“上个月休闲食品卖得最好的三个商品是什么”，系统先把这个问题拆解为几个要素：时间范围上个月、分类休闲食品、指标销量TOP3。拆解方式可以交给模型，也可以自己做简单的关键词规则，这里我用的是模型抽取，然后映射到SQL查询条件，查完数据库再把结果拼回提示词，请模型生成最终回答。

这样做的好处是：数据准确性有保证，模型只能基于查询结果进行组织语言，不会瞎编数字。如果你直接把问题丢给模型让它回答，它很可能一本正经地把“销售额12345元”编出来，这在演示时会非常尴尬，被老师一追问就露馅了。

为了提升问答准确率，我在系统里预置了一个“业务口径词典”，比如“客单价=销售额/订单量”、“销售额=已支付订单金额之和”。当模型回答时，提示词里附带这些口径定义，能够显著减少错误理解。这个细节在论文里写出来也很显专业。

4. 完整落地流程与常见问题排查实录

4.1 从零到演示：一条完整的开发与部署路线

很多同学拿到这种项目不知道从哪里下手，总想一口气把全部功能都写完，结果写着写着就乱了。我实际走的开发顺序是：

第一步，先把数据库建好，造数脚本跑通，确保数据规模在百万级。这个阶段不要写任何Java代码，就是把表结构和数据准备好。

第二步，搭一个最小的SpringBoot项目，连上数据库，把用户、商品、订单三个实体的增删改查先跑通。接口用Postman测试，确保能查出数据。

第三步，开发统计分析模块。写SQL聚合查询，返回ECharts需要的JSON结构。这时你可以用浏览器直接访问接口来看返回效果，不急着写前端页面。

第四步，搭一个简单的Vue项目，先做登录页和管理页框架，再逐步把大屏图表接上去。每写完一个图表，就对照数据校验一次。

第五步，本地部署大语言模型，先用命令行对话测试，确认服务正常，再写Java调用代码，实现报告生成和智能问答。

第六步，完善前端交互、权限控制、操作日志，把项目部署打包，录制演示视频，整理部署说明文档。

整个周期如果每天投入4小时左右，软件工程基础一般的同学大概需要三到四周。如果只剩一两周，至少要保证前三步质量，再在大语言模型部分做一个最有把握的报告生成功能，其他功能弱化处理也可以。

4.2 答辩验收时的关注点：怎样证明工作量和技术深度

毕设答辩说白了，老师关心三个问题：是不是你亲手做的，工作量够不够，技术深度达不达标。

工作量这块，源码行数、数据库表数量、页面数量都是直观体现。我最终的项目统计大概在30多个API接口、10张数据库表、8个可视化图表页面、4个核心AI功能场景，文档部分还有需求分析、概要设计、数据库设计、接口文档、测试报告，这个体量在毕设里属于中等偏上，完全能撑住场面。

技术深度这块，除了常规的CRUD和可视化，要重点讲清楚三个地方：一是数据规模上来之后，如何通过索引、分页、聚合表来做性能优化；二是大语言模型接入的真实设计思路，包括为什么选本地部署、提示词如何设计、如何防止模型生成错误数据；三是系统的可扩展性，比如当前用的本地模型，如果切换到更强的云端模型，只需要修改一个HTTP调用即可，这个架构设计体现了松耦合。

另外，论文里我建议画一张系统架构图，从“数据采集层—数据存储层—业务服务层—AI分析层—展示层”逐层拆解。这张图要提前画好，答辩时给老师看到的是“你把这个系统的每一层都吃透了”，印象分会高很多。

4.3 毕设场景下的常见问题与排查方法速查表

我在开发和给别人调试的过程中，遇到过很多典型问题。下面直接上一张排查速查表，碰到问题照着查就行：

4.4 SpringBoot版本过高导致的关联踩坑

网络搜索词里有个“springboot版本太高”，这确实是我亲自踩过的问题。好多人新建项目时图省事，直接选了SpringBoot 3.x最新稳定版，结果后续集成各种组件时麻烦不断。

SpringBoot 3.x有几个和2.x明显不同的地方：javax.x包全部改成了jakarta.x；SpringFox的Swagger需要换成SpringDoc；一些老版本的MyBatis-Plus可能需要升级到对应版本；RestTemplate行为变化，需要手动注入Bean。如果你不是非得用3.x的新特性，我建议毕设项目直接用2.7.x。2.7版本足够稳定，生态兼容性也最好，网上搜到的资料90%都是基于2.x的，遇到问题到处都能找到答案。

如果你非要上3.x，也不是不行，但要做好心理准备。我在调试过程中就把MyBatis-Plus升级到3.5.5版本，Swagger改成了SpringDoc，统一用Jakarta命名空间，才把项目跑通。这个过程中费的时间比预想中多出了一整天，对于赶进度的同学来说不值得。

还有个小建议：IDEA新建SpringBoot项目时，Spring Initializr默认会帮你选最新的SpringBoot版本，记得手动改成2.7.18或者其他你熟悉的稳定版本，能省很多事。

4.5 测试与答辩演示需要注意的细节

系统做完不是结束，演示视频和现场答辩的细节同样决定成败。我建议提前录一个完整的演示视频，时间控制在10分钟以内，流程大致是：展示系统登录和权限管理，进入销售大屏看数据可视化效果，点击生成报告，用自然语言向系统提问，展示模型回答和前后端联动过程。

录视频的时候，务必提前把本地大语言模型服务启动好，不要等录到一半再发现模型没有加载。视频里可以适当制造一些“效果感”，比如提问尽量口语化，回答尽量完整流畅，不用刻意追求完美，但要让老师看到系统真实的交互过程。

现场答辩还有一个容易被忽视的细节：电脑的电源和网络。如果你用的是笔记本，一定要插上电源，并关闭自动休眠和自动更新。有个同学答辩时电脑突然休眠，模型服务被中断，现场再也起不来了，最后只能靠PPT硬撑，成绩大受影响。设备应急预案一定要有：把模型服务配置成开机自启，同时准备一个备用手机热点以防断网。

5. 项目扩展方向与个人经验总结

5.1 还能怎么扩展：实时计算、推荐系统与多轮问答

如果时间充裕，或者在论文里想增加更多亮点，这几个扩展方向我非常建议考虑。

第一个方向是实时计算。当前的统计是离线聚合，数据延迟可能是小时级。你可以引入消息队列加上流处理组件做一个简化版的实时订单统计功能，比如每产生一条新订单，就更新今日实时销售额和订单量。不需要搭完整集群，单机模式跑通流处理流程，在架构图上就能标注“实时计算链路”。这个扩展非常加分，因为它体现了对“大数据”更完整的理解。

第二个方向是智能推荐。基于用户的购买记录，可以用协同过滤算法或者极简的“购买过A的用户也购买了B”逻辑，在用户端页面展示推荐商品。如果能结合大语言模型对用户评论和浏览记录进行意图理解，推荐的解释文本会显得更智能。不过这个功能工作量偏大，适合作为系统的附加模块写到“未来展望”里。

第三个方向是完善智能问答的多轮对话能力。现在系统只支持单轮问答，如果你想支持“上个月销售情况怎么样？那上个月呢？”这种多轮指代，就得在服务端维护会话历史，每次请求把上下文一起发给模型。这个功能实现起来并不算复杂，但交互体验会提升一个档次，演示时特别能唬人。

5.2 复盘：做这种综合性项目，最该关注的三个核心能力

做完整个项目复盘，我发现这类毕设实际考验的不是某个单一技术，而是三件事。

第一是“把复杂问题拆解成可执行模块”的能力。电商销售系统听起来东西很多，但只要拆成数据、接口、可视化、AI、部署几条线，每一条线独立推进，工作量就变得可控了。我在开发时给自己定了每日任务清单，每天只推进一到两个模块，不贪多，这样整个周期下来一直保持清晰的状态。

第二是“让AI能力真正落地”的能力。大语言模型接入本身不难，难的是让它和业务系统有机结合。我亲眼见过很多同学接入了模型，但只是做了一个“聊天机器人”放在页面上，和业务数据毫无关联，评委一看就知道是生搬硬套。真正的结合点，是把模型放在数据分析链条的末端，让它的输出基于实际数据、服务于实际决策。这个思路不仅适用于毕设，也适用于企业里的AI项目。

第三是“文档和代码同样规范”的能力。毕设评审里文档占的比重很高。我在编码的时候每完成一个接口，就同步更新一次接口文档，每完成一个模块，就补一段设计文档。最后论文成形时，有大量一手素材可以直接用，不用临时编造。这个习惯后来到了工作岗位也让我受益很深。

5.3 关于“一条龙”资源的正确使用心态

市面上确实存在大量卖毕设源码、送文档送视频的资源。我的观点是：可以把它当作参考资料，但一定要把系统跑起来，看懂每条业务逻辑，能自己改代码、讲清原理。毕设答辩的核心是验证你是不是真的掌握了项目，如果你只会照着演示视频念稿子，老师连续追问三个问题就会露馅。

我写这篇文章的方法也类似：把整个项目的架构、表设计、代码逻辑、AI接入方式全部讲清楚，你跟着走一遍，能顺利把系统在自己电脑上跑起来，再根据自己的业务需求改一改前端样式、换一换模型名称，花点心思做二次开发，这个项目就成了你自己的东西。

如果你在搭建过程中遇到问题，也可以沿着我文中提到的几个关键点排查：先确认MySQL数据导入是否成功，再确认本地模型服务是否启动，再用Postman测试统计接口，用Chrome开发者工具看前端报错，基本能解决九成问题。最后祝各位毕设顺利，尤其是打算在这个题目上做出差异化的同学，沉下心把这篇文档里的每一块都走通，答辩的时候你会很有底气。