基于SpringBoot+Vue.js的智能课程社区平台：AI推荐、对话与情感分析实战

1. 项目缘起与整体设计思路

1.1 这个平台到底要解决什么问题

在线课程社区这几年发展得特别快，几乎每个做知识付费或者在线教育的团队都在搭建自己的社区模块。但真正用起来就会发现一个很尴尬的现象：课程越来越多，用户却越来越迷茫。一个平台上架了几百门课，用户进来之后根本不知道从哪看起，搜索框里敲几个关键词出来的结果排序也很粗糙，基本就是按上架时间或者销量硬排。另一边，课程评论区积累了大量的用户反馈，运营人员一条条看根本看不过来，哪些课口碑在崩、哪些课有潜在爆点，全靠人工感觉去判断，效率极低。

这个项目要做的，就是给课程社区装上一套“智能大脑”。核心目标有三个：第一，让每个用户打开首页就能看到真正适合自己口味的课程推荐，而不是千篇一律的热门榜单；第二，提供一个能理解课程内容的AI对话助手，用户可以直接用自然语言问“有没有适合零基础学Python的课”，系统能给出有针对性的回答；第三，对社区里的评论做情感分析，自动识别正面、负面、中性情绪，帮运营团队快速定位问题课程和优质内容。

技术栈上选的是SpringBoot做后端、Vue.js做前端，前后端完全分离。AI能力这块，推荐算法、对话模型、情感分析模型都集成在SpringBoot服务层里，通过统一的API对外暴露。另外还加了一个爬虫模块，用来抓取外部公开的课程评价数据，作为推荐和情感分析的补充语料。可视化数据分析模块则是给运营人员看的，把用户行为、课程热度、情感趋势用图表直观呈现出来。

这个项目适合谁参考呢？如果你是在校学生做毕业设计，这个选题的完整度足够撑起一个像样的论文；如果你是刚入行的全栈开发者，想找一个能把前后端+AI+数据分析串起来的练手项目，这个结构也很合适；甚至如果你是小团队的技术负责人，想快速搭一个课程社区的MVP，这里面的架构思路和踩坑经验可以直接拿去用。

1.2 为什么选SpringBoot+Vue.js这套组合

后端选SpringBoot，理由很直接：生态成熟、上手快、社区资源多。做AI集成的时候，无论是调用外部API还是本地部署模型，SpringBoot都能通过简单的HTTP客户端或者SDK快速对接。而且SpringBoot的自动配置机制让数据库连接、缓存、消息队列这些基础设施的搭建变得非常省心，可以把精力集中在业务逻辑和AI能力上。

前端选Vue.js，主要是考虑到课程社区这类应用交互比较频繁，Vue的响应式数据绑定和组件化开发模式能让页面状态管理变得清晰。比如推荐列表的实时刷新、聊天窗口的消息流、评论情感标签的动态渲染，用Vue的组件来封装都很自然。而且Vue的学习曲线相对平缓，如果团队里有前端基础一般的成员，也能较快上手。

前后端分离的架构带来的好处是职责清晰。前端只负责展示和交互，后端只负责数据和逻辑，两边通过RESTful API通信。这样在开发阶段，前端可以用Mock数据先跑起来，后端可以独立测试接口，互不阻塞。部署的时候，前端打包成静态资源扔到Nginx，后端打成JAR包独立运行，扩展和运维都方便。

1.3 AI能力的三条主线怎么串起来

这个项目里AI不是单独一个模块，而是贯穿了三条主线。第一条是推荐线：用户的行为数据（浏览、收藏、购买、评分）经过清洗和特征提取后，输入到推荐算法里，生成个性化的课程列表。第二条是对话线：用户用自然语言提问，系统先做意图识别，然后从课程库里检索匹配的内容，再组织成自然语言回复。第三条是情感分析线：评论数据进入情感分类模型，输出情绪标签和置信度，结果既用于运营看板，也反哺推荐算法（比如负面评论多的课程降权）。

这三条线在数据层面是打通的。推荐算法用到的用户画像里，会包含该用户在评论中表达过的情感倾向；对话助手在回答时，也会参考课程的评论情感分布，如果一门课差评率很高，助手在推荐时会主动提醒。这种交叉引用让整个系统的智能感更强，而不是三个孤立的AI功能拼在一起。

2. 核心模块拆解与技术选型考量

2.1 智能推荐模块：从协同过滤到内容画像

推荐模块是整个平台最核心的部分。我采用的是混合推荐策略，把协同过滤和基于内容的推荐结合起来。协同过滤负责“跟你相似的人还看了什么”，基于内容的推荐负责“这门课和你之前学过的很像”。两者加权融合，避免单一策略的偏差。

协同过滤这块，用户-物品评分矩阵用稀疏矩阵存储，因为课程数量可能上千，但单个用户评过分的课程通常只有几十个。相似度计算用余弦相似度，比欧氏距离更适合高维稀疏向量。实际跑下来，用户-based的协同过滤在用户量不大的时候效果更稳，因为课程之间的相似度计算需要足够的共同评分用户才能准确。所以初期我建议先用用户-based，等数据量上来了再切到物品-based。

基于内容的推荐需要给每门课打标签。标签来源有三个：课程标题和描述的分词结果、课程分类、以及从评论中提取的关键词。分词用结巴分词，提取TF-IDF权重最高的若干个词作为内容特征。用户画像则是把用户历史交互过的课程标签做加权平均，权重按交互类型区分——购买权重最高，收藏次之，浏览最低。

冷启动问题是推荐系统绕不开的坎。新用户没有行为数据，新课程没有评分数据。我的处理方式是：新用户注册时让ta选几个感兴趣的方向，用这些方向做初始推荐；新课程则给它一个“新课程扶持期”，在推荐列表里强制插入一定比例的新课，同时用内容相似度把它推给可能感兴趣的老用户。

2.2 AI对话模块：意图识别+检索增强生成

对话模块不是要做一个通用聊天机器人，而是聚焦在课程咨询这个垂直场景。用户问的问题基本围绕“有没有XX课”“XX课怎么样”“XX和YY哪个适合我”这几类。所以我的设计是：先做意图分类，再走不同的处理管道。

意图分类用的是一个轻量级的文本分类模型，输入是用户query，输出是意图标签（找课程、问评价、做对比、闲聊等）。这个模型可以用BERT微调，也可以用FastText快速搭一个baseline。实际测试下来，在课程咨询这个限定领域，FastText加上关键词特征就能达到不错的效果，推理速度还快很多。

识别出“找课程”意图后，系统会从课程库里检索相关课程。检索用的是Elasticsearch，把课程标题、描述、标签都建了索引。用户query经过分词和同义词扩展后去ES里查，返回Top-N结果。然后把这些结果作为上下文，交给生成模块组织成自然语言回复。生成模块我试过两种方案：一种是模板填充，把检索结果套进预设的回复模板里；另一种是调用大模型API做生成。模板方案稳定可控但略显生硬，大模型方案灵活但偶尔会胡编。最终我采用的是混合方案：简单查询走模板，复杂查询走大模型，并且在prompt里明确要求“只根据提供的课程信息回答，不要编造”。

对话历史的管理也很重要。我用Redis存最近N轮对话，每次请求都把历史带上，这样多轮对话的上下文不会丢。但要注意控制token长度，太长的历史反而会干扰模型判断。

2.3 评论情感分析：从规则到模型

情感分析模块的输入是用户评论，输出是情感标签（正面/负面/中性）和置信度。我一开始想用现成的情感词典做规则匹配，但实际跑下来发现课程评论里有很多领域特定的表达，比如“老师讲得很水”这种，通用词典根本识别不了。所以后来转向了有监督的机器学习方案。

数据标注是个体力活。我从爬虫抓来的公开评论里抽样了几千条，人工标了情感标签。标注标准要提前定清楚：包含明确褒义词且无转折的算正面，包含明确贬义词且无转折的算负面，有褒有贬或者语气平淡的算中性。标注一致性用Kappa系数检验，低于0.7就重新对齐标准。

模型选型上，BERT微调的效果最好，但推理成本高。如果QPS要求不高，用BERT没问题；如果要支撑高并发，可以蒸馏成小模型，或者用ALBERT这类轻量级变体。我最终部署的是BERT-base，用ONNX Runtime做推理加速，单条评论的处理时间控制在50ms以内。

情感分析的结果不只是打个标签就完了。我会把负面评论按时间维度做趋势分析，如果某门课的负面评论在短时间内激增，系统会自动给运营人员发预警。正面评论里的高频关键词也会被提取出来，作为课程亮点展示在详情页。

2.4 爬虫模块：数据补充与合规边界

爬虫模块的作用是抓取外部公开的课程评价数据，用来扩充训练语料和做竞品分析。这里必须强调合规问题：只抓取公开可见的、不涉及个人隐私的数据，遵守目标网站的robots.txt规则，请求频率控制在合理范围内，不造成对方服务器压力。

技术实现上，用Python的Scrapy框架比较顺手。爬虫和主业务系统是解耦的，爬下来的数据先落到MongoDB里做清洗，清洗完再导入到主数据库。清洗包括去重、去广告、去乱码、统一编码格式。情感分析模型的训练数据有一部分就来自这里。

爬虫的调度用Celery做分布式任务队列，可以按需扩展爬虫节点。但要注意设置好User-Agent和请求间隔，避免被目标网站封IP。我一般会配置多个User-Agent轮换，请求间隔随机在2-5秒之间。

2.5 可视化数据分析：给运营看的仪表盘

可视化模块用ECharts做图表库，前端用Vue组件封装。核心指标包括：日活用户趋势、课程热度排行、情感分布饼图、用户留存漏斗、推荐点击率等。数据从后端API拉取，后端用定时任务做预聚合，避免每次查询都扫全表。

仪表盘的设计原则是“一屏看懂”。运营人员不需要复杂的筛选条件，打开页面就能看到最关键的数据。所以我做了几个预设视图：概览视图看大盘，课程视图看单课表现，用户视图看人群画像。每个视图下面再提供下钻能力，比如点击某个课程可以看它的详细评论情感趋势。

3. 实操过程与核心环节实现

3.1 环境搭建与项目骨架生成

先说一下基础环境。后端需要JDK 1.8或以上、Maven 3.6+、MySQL 5.7+、Redis 5.0+、Elasticsearch 7.x。前端需要Node.js 14+和npm或yarn。AI模型推理如果走本地部署，还需要Python 3.8+和相应的深度学习框架。

项目骨架用Spring Initializr生成，选上Web、MySQL、Redis、Elasticsearch这几个依赖。生成后先跑一个Hello World确认环境没问题。然后建包结构：controller层放接口，service层放业务逻辑，dao层放数据库操作，config层放配置类，utils放工具类。AI相关的代码单独建一个ai包，里面再分recommend、chat、sentiment三个子包。

前端用Vue CLI创建项目，选上Router、Vuex、Axios。目录结构按功能模块划分：views放页面组件，components放通用组件，api放接口封装，store放Vuex状态管理，utils放工具函数。

数据库设计这块，核心表有：用户表、课程表、评论表、用户行为表、推荐结果表、对话历史表。用户行为表要记录用户ID、课程ID、行为类型（浏览/收藏/购买/评分）、时间戳。这张表是推荐算法的数据基础，索引要建好，不然查询会很慢。

3.2 推荐算法的代码实现与调参

协同过滤的核心代码不复杂，但细节很多。先构建用户-物品评分矩阵，用Map<Integer, Map<Integer, Double>>来存，外层key是用户ID，内层key是课程ID，value是评分。评分可以从行为数据里折算：购买算5分，收藏算4分，评分按实际分数，浏览算1分。

相似度计算用余弦相似度，公式是两向量点积除以模长乘积。实际写代码的时候要注意处理零向量，不然会除零报错。计算完相似度后，取Top-K个最相似用户，把他们评过但目标用户没评过的课程拿出来，按相似度加权求和作为预测评分。

基于内容的推荐需要先给课程打标签。我用结巴分词对课程标题和描述做分词，去掉停用词，然后计算TF-IDF。取TF-IDF最高的20个词作为课程的内容特征向量。用户画像则是把用户交互过的课程特征向量按行为权重加权平均。

混合推荐的融合公式是：最终得分 = α × 协同过滤得分 + (1-α) × 内容推荐得分。α这个权重需要调，我试过0.3到0.7之间的几个值，最终在0.5左右效果比较均衡。调参的时候用A/B测试，看点击率和转化率的变化。

冷启动的处理前面提过了，这里补充一个细节：新用户注册时选的兴趣方向，我会映射到课程分类上，然后从对应分类里挑评分最高的课程做推荐。同时给这些推荐打上“新用户专享”的标签，引导用户点击。

3.3 对话模块的意图分类与检索增强

意图分类模型的训练数据需要自己构造。我从用户历史提问里抽样，人工标注意图标签。标签体系设计为：找课程、问评价、做对比、问价格、闲聊、其他。每个标签至少标200条，保证类别平衡。

FastText训练很快，命令行几行就能跑。训练完的模型文件很小，加载到内存里做推理，单条耗时不到1ms。推理的时候，输入query先做分词和去停用词，然后喂给模型，取概率最高的标签作为意图。

检索增强这块，Elasticsearch的查询构造很关键。我用的是multi_match查询，对title、description、tags三个字段分别设权重，title权重最高。查询前先对用户query做同义词扩展，比如“编程”扩展成“编程、代码、开发”，“入门”扩展成“入门、基础、零基础”。同义词表可以手工维护，也可以用词向量自动挖掘。

生成模块的prompt设计有讲究。我用的模板大致是：“你是一个课程咨询助手。根据以下课程信息回答用户问题。如果信息不足，就说没有找到相关课程，不要编造。课程信息：{检索结果}。用户问题：{query}。”这样能有效抑制模型胡编。

多轮对话的管理用Redis的List结构，key是sessionId，value是消息列表。每次请求把最近5轮对话取出来拼到prompt里。注意要控制总长度，超过模型上下文限制就截断最早的对话。

3.4 情感分析模型的训练与部署

数据标注完成后，按8:1:1划分训练集、验证集、测试集。用BERT-base做微调，学习率设2e-5，batch size设16，训练3个epoch。验证集上的F1值如果连续两个epoch不提升就早停。

训练完的模型用ONNX导出，然后用ONNX Runtime做推理。ONNX Runtime支持多线程和批处理，吞吐量比原生PyTorch高不少。部署的时候把模型文件放在后端服务的resources目录下，服务启动时加载到内存。

推理接口的设计是：输入评论文本，输出情感标签和置信度。置信度低于阈值的（比如0.6），标记为“待人工复核”，不直接展示给用户。这样能避免模型误判带来的负面影响。

情感分析结果的反哺逻辑是：如果一门课的负面评论占比超过30%，推荐算法里给这门课降权；如果正面评论里某个关键词出现频率特别高，把这个关键词加到课程标签里，提升内容推荐的准确度。

3.5 爬虫的调度与数据清洗

Scrapy爬虫写好后，用Celery做定时调度。Celery的broker用Redis，backend也用Redis。任务定义在tasks.py里，用@shared_task装饰器标记。调度用Celery Beat，配置crontab表达式，比如每天凌晨2点跑一次。

数据清洗的流程是：先去重，用评论内容的MD5做唯一索引；然后去广告，用正则匹配常见的广告关键词；接着去乱码，用chardet检测编码后统一转UTF-8；最后做分词和停用词过滤，把清洗后的文本存到MySQL。

爬虫的合规检查清单：确认目标网站robots.txt允许抓取、设置合理的请求间隔、不抓取需要登录才能看的内容、不抓取个人隐私信息、不频繁请求造成对方压力。这些都要在代码里硬编码约束，不能靠自觉。

3.6 可视化仪表盘的前后端联调

后端提供聚合数据的API，比如/api/dashboard/overview返回日活、课程总数、评论总数等概览数据。这些数据用定时任务预计算，存到一张统计表里，API直接查统计表，响应很快。

前端用ECharts的Vue封装组件，把图表配置项抽成props，方便复用。数据请求用Axios，在Vuex的action里统一管理。图表联动用ECharts的connect功能，多个图表之间可以共享数据高亮。

联调的时候注意跨域问题。开发阶段后端配CORS，生产环境用Nginx做反向代理，把前端静态资源和后端API放在同一个域名下，避免跨域。

4. 常见问题与排查技巧实录

4.1 推荐结果偏差大怎么办

推荐系统上线后最常见的问题就是“推的东西不对”。排查思路是分步定位：先看数据质量，用户行为数据有没有缺失或异常；再看特征工程，课程标签和用户画像是否合理；最后看算法参数，相似度阈值和融合权重是否需要调整。

我遇到过一个典型问题：新用户注册后推荐的课程全是冷门课。查下来发现是冷启动策略里，新用户兴趣方向映射到课程分类时，分类下的课程按评分排序，但评分数据稀疏，很多课只有一两个评分，导致排序不稳定。解决办法是引入贝叶斯平均，给评分加上一个先验值，避免小样本导致的极端排序。

还有一个问题是推荐结果同质化严重，用户反馈“怎么推来推去都是这几门课”。这是探索与利用的平衡问题。我在推荐列表里强制插入10%的随机课程，或者用Bandit算法做动态调整，让系统有机会探索用户可能感兴趣但尚未被发现的内容。

4.2 对话助手答非所问怎么调

对话模块的bad case主要有几类：意图识别错误、检索结果不相关、生成内容胡编。意图识别错误的话，看混淆矩阵，找出容易混淆的类别对，补充训练数据。检索不相关的话，调整ES的查询权重和同义词表。生成胡编的话，收紧prompt约束，或者降低大模型调用的温度参数。

我踩过的一个坑是：用户问“有没有讲Django的课”，意图识别成了“问评价”，因为“讲”这个字在训练数据里更多出现在评价类query里。解决办法是在训练数据里补充“找课程”意图中包含“讲”“教”“学”等动词的样本，让模型学到更细粒度的特征。

还有一个坑是检索结果太多导致prompt超长。我的处理是限制检索返回的课程数量，最多5门，每门只保留标题和一句话描述。这样既控制了长度，又保留了关键信息。

4.3 情感分析误判的排查与修正

情感分析误判的常见原因是领域特定表达和反讽。比如“这课真是绝了”可能是正面也可能是负面，取决于上下文。还有“老师讲得真‘好’”，带引号的“好”其实是反讽。

排查方法是把误判样本单独拿出来分析，看是否有共同的模式。如果是领域词的问题，补充到情感词典里；如果是反讽，这个比较难，可以考虑引入上下文信息，或者用更大的预训练模型。

我实际处理的时候，建了一个“误判样本库”，每次发现误判就加进去，定期用这些样本做增量训练。这样模型会越来越适应自己平台的评论风格。

4.4 爬虫被封的应对策略

爬虫被封IP是家常便饭。应对策略有几个层次：最基础的是降低请求频率，加随机延迟；进阶一点的是轮换User-Agent和代理IP；再高级一点的是模拟真实用户行为，比如随机点击、滚动页面。

但我要强调的是，不要为了抓数据而突破对方的反爬机制。如果对方明确禁止抓取，就换数据源或者放弃。合规永远是第一位的。

4.5 前后端联调的典型问题速查

4.6 性能优化的几个实操技巧

数据库层面，用户行为表按时间分区，历史数据归档到冷存储。查询的时候只查最近N天的数据，避免全表扫描。Redis缓存热点数据，比如课程详情、推荐结果，设置合理的过期时间。

AI推理层面，情感分析模型用批处理，攒够一批再推理，提高GPU利用率。推荐算法的结果可以预计算，每天凌晨跑一次离线推荐，在线请求直接查预计算结果，响应时间从几百毫秒降到几毫秒。

前端层面，Vue组件按需加载，路由懒加载，图片懒加载。ECharts图表在数据量大时开启大数据模式，或者做数据采样。

5. 项目扩展方向与个人经验分享

5.1 后续可以怎么扩展

这个项目的骨架已经比较完整了，但还有很多可以深挖的方向。推荐算法可以引入深度学习模型，比如用Neural Collaborative Filtering替代传统的矩阵分解，效果通常会有提升。对话模块可以接入知识图谱，把课程之间的先修关系、关联关系结构化，让回答更精准。

情感分析可以细粒度到方面级，不只是判断整条评论的情感，而是识别出评论针对的是“内容质量”“讲师水平”“价格”哪个方面。这样运营能更精准地定位问题。

可视化模块可以加实时大屏，用WebSocket推送实时数据，适合运营团队挂在办公室看。爬虫模块可以加增量抓取和变化检测，只抓新出现的评论，减少重复处理。

5.2 我在这个项目里踩过的坑

第一个坑是低估了数据清洗的工作量。爬下来的评论里各种乱七八糟的字符、表情、广告，清洗规则写了又改，改了又写。建议一开始就建一个清洗规则文档，每加一条规则就记录原因和效果。

第二个坑是推荐算法的冷启动处理太粗糙。一开始新用户推荐就是随机推热门课，点击率很低。后来改成让用户选兴趣方向，点击率明显提升。这个改动不大，但效果立竿见影。

第三个坑是对话模块的prompt没有做长度控制，有时候检索结果太多，拼出来的prompt超过模型限制，直接报错。后来加了截断逻辑，并且限制检索返回的数量，问题才解决。

第四个坑是情感分析模型上线后发现推理速度跟不上。BERT-base在CPU上单条要200ms，并发一高就排队。后来换成ONNX Runtime加批处理，才把延迟降下来。

5.3 给准备做类似项目的朋友几点建议

如果你打算做类似的项目，我的建议是：先把数据流理清楚，用户行为数据怎么采集、怎么存储、怎么用于推荐，这条链路要提前设计好，不然后面改起来很痛苦。AI模块不要一开始就追求高大上，先用简单方案跑通闭环，再逐步替换成复杂模型。前后端分离的项目，接口文档要提前定好，用Swagger或者YApi都行，避免联调的时候扯皮。

还有一点很重要：不要忽视非功能性需求。性能、安全、可扩展性这些，在项目初期就要考虑。比如数据库索引、缓存策略、接口限流，这些看起来是细节，但上线后出问题往往就出在这些地方。

最后，做项目的过程中多记录。踩过的坑、试过的方案、最终的选择理由，这些都记下来。一方面方便自己复盘，另一方面如果以后要写文档或者做分享，这些都是现成的素材。我个人的习惯是建一个Markdown笔记，每天收工前花十分钟把当天的关键决策和问题记下来，积累下来就是一笔财富。