毕业设计选题的时候我见过太多同学一头扎进“XX管理系统”——图书管理、超市进销存、宿舍管理页面做得再花本质还是围着增删改查打转。答辩时老师一句“你的系统解决了什么问题”场面往往就冷下来了。而“Python新能源车评分析与协同过滤推荐系统”这个题目赢在选题思路上它不是一个单页面功能的堆叠而是一个从数据采集、文本分析到推荐服务的完整数据产品。这篇文章我会把整条链路拆开讲清楚——requests爬虫怎么采数据snowNLP怎么做情感分析协同过滤推荐算法怎么从用户行为里算出“猜你喜欢”最后Django怎么把这些能力集成成可演示的Web系统外加可视化看板。每一步都会带上关键代码和我在实际开发中踩过的坑。适合正在做毕业设计的学生想练一个“全栈数据分析”项目的开发者以及刚入行做Web开发、想拓展算法知识面的朋友。建议先收藏留着做完整个项目再回来看一遍感受会很不一样。1. 先聊透这个选题它为什么比“管理系统”更值得做1.1 一个完整的数据产品而不是几个孤立页面所有管理系统类项目的通病是数据靠手工录入、逻辑只有CRUD、没有算法没有流程。这类项目做得再工整也撑不起毕业设计要求的“工作量”和“创新点”。而这个题目天然带着三层深度。第一层是数据获取你需要用爬虫去抓新能源车评数据这涉及网络请求、数据解析、反爬应对本身就够写一章论文第二层是文本分析与算法拿到评论后不是放着看而是用snowNLP算情感倾向再用协同过滤算法挖掘用户偏好这一步直接决定了项目的含金量第三层是工程化呈现Django负责把数据、算法结果、可视化图表组织成一个可交互的网站让评审老师能直观看到效果。所以这个项目从立题开始就自带一条“采集—清洗—分析—建模—呈现”的完整业务链。答辩时老师问“你的创新点在哪里”你可以从“数据驱动的购车决策辅助”这个视角去组织答案而不是干巴巴地说“我用了xx框架”。1.2 系统最终能演示的四层能力我按最终交付版本梳理了一下这套系统在实际运行中应该具备以下能力也推荐你在设计数据库和页面时按这个清单去拆分模块层级能力技术落点数据层新能源车评论采集与存储requests MySQL/pymysql分析层评论情感评分与关键词提取snowNLP jieba分词算法层相似车型与个性化推荐协同过滤ItemCF展示层数据看板与推荐页面Django ECharts/pyecharts这四层不是各做各的而是层层有依赖关系。爬虫采回来的数据要清洗后写入数据库情感分析要读取评论文本做批量打分协同过滤要基于用户的历史评分构建矩阵最后的可视化页面又要从情感分析结果和推荐结果里拉数据。这种数据流上的串联正是答辩时最能体现“系统完整性”的地方。2. 技术栈拆解Django snowNLP 协同过滤为什么是黄金组合2.1 Django一个能扛住演示和答辩的Web框架选Django而不是Flask我算是吃过亏后得出的结论。一开始为了追求“轻量”我用Flask写了个单文件应用结果项目越加越大——爬虫独立成一个模块、情感分析一个模块、推荐一个模块、后台管理还要另写单文件马上失控。Django的MTV架构天然对这个场景友好Model管数据库表Template管页面View管业务逻辑App之间可以拆得很干净。另外Django自带Admin后台。评论数据、用户数据、车型数据这些需要人工审核和调整的内容直接在后台点一点就能修改不需要自己额外写一套管理界面。这对于毕业设计来说等于白送了一个管理模块的工作量。再加上Django的ORM操作MySQL很方便分页、事务、缓存这些高频功能都有现成实现能省下大量调bug的时间。2.2 snowNLP与requests轻量级方案的优势很多人一看到情感分析就想着上BERT、上深度学习但毕业设计场景里snowNLP这样的轻量级库反而更合适。snowNLP是一个纯Python实现的中文文本处理库不需要复杂的模型训练环境pip装完就能用。它内置了情感分析、中文分词、关键词提取等功能接口简单到一行代码就能出情感得分非常适合做快速原型验证。我在实际测试里发现它对汽车评论的基础情感判断大致可用但确实存在领域偏差后面第4节我会详细讲怎么优化。requests爬虫同理。Scrapy虽然功能强大但学习曲线陡、部署复杂而且结构化程度高反而不利于毕业设计中“把每一步讲清楚”的需求。requests库几十行代码就能写出一个能用的爬虫每一步都在明面上指导老师问起来你解释起来也轻松。对于几千到几万条的中等数据量requests的速度完全够用。2.3 系统整体的数据流与模块划分整个项目我划分为四个模块开发时按依赖顺序进行spider模块用requests请求评论接口解析JSON清洗后写入数据库。analysis模块读取评论文本用snowNLP计算情感得分聚合出车型维度的口碑指标。recommend模块从用户评分数据中构建评分矩阵用协同过滤算法计算相似车型并生成推荐列表。web模块Django主应用承载页面路由、登录交互、可视化图表展示和推荐结果展示。这个划分的好处是每个模块都可以单独测试、单独写论文章节。我实际开发时也是按这个顺序推进的先把数据爬到本地再离线做情感分析和推荐实验最后才把它们接进Django页面里。如果一上来就想着全套集成遇到问题会很难定位是爬虫的问题还是Web框架的问题。3. 数据采集用requests爬取新能源车评的完整实现3.1 先搞清楚要采什么字段爬虫不是拿到什么存什么而是要以分析目标为导向反推字段。这个项目里我们最终要做的情感分析和协同过滤分别需要两类不同的数据情感分析需要评论内容、评论时间、车型名称。协同过滤需要用户标识、车型标识、用户评分。所以爬虫核心表结构可以确定为评论ID、用户ID、车型名称、评分1-5星、评论内容、发布时间。其中用户ID和评分是协同过滤的关键输入评论内容是国家重点情感分析的关键输入。建议在爬虫设计阶段就先把字段想好否则后面数据清洗会非常痛苦。3.2 请求伪装与频率控制别把自己送进IP黑名单很多车评数据来自网页接口直接requests.get就能拿到JSON格式的响应但前提是你要先伪装成一个正常用户。这里有几件常规操作import requests import time import random HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://www.example.com/, Accept-Language: zh-CN,zh;q0.9 } def fetch_comments(page): url https://api.example.com/v1/comment/list params {car_id: 17, page: page, page_size: 20} resp requests.get(url, headersHEADERS, paramsparams, timeout10) return resp.json() for page in range(1, 50): data fetch_comments(pagepage) save_to_database(data) time.sleep(random.uniform(1.5, 3.5)) # 随机休眠模拟人工浏览这段代码中time.sleep(random.uniform(1.5, 3.5))是最容易被忽略的细节。我一开始图省事直接跑了一个for循环连续请求结果大约在几十个请求之后就触发了服务端的限流返回状态码429也就是Too Many Requests。这个错误不是你的代码语法有问题而是请求太频繁被服务端识别为爬虫了。3.3 从接口响应到结构化数据的清洗逻辑接口返回的JSON一般长这样{ code: 0, data: { list: [ { comment_id: 1024, user_name: 车友_5278, car_model: Model Y, star_level: 5, content: 续航扎实空间大唯一不满的是隔音一般, create_time: 2024-05-12 10:23:00 } ], total: 1500 } }存库前一定要做数据清洗我总结了四个必做的步骤第一去空值与兜底值。有些评论内容为空有些评分字段缺失直接丢弃或填充默认值否则后面情感分析时None值会直接报错。第二去重复。翻页时偶尔会出现重复数据按评论ID做一次排重要比存完再查高效得多。第三字段截断。评论内容有的很长建议统一截取到200-500字防止数据库字段长度溢出。第四时间格式化。create_time转成统一的时间格式后续做时间维度分析时就不用再救火。import pymysql conn pymysql.connect( hostlocalhost, userroot, password123456, databasecar_review, charsetutf8mb4 ) def save_to_database(items): with conn.cursor() as cursor: for item in items: content item[content].strip()[:500] if not content: continue sql INSERT INTO comments (comment_id, user_name, car_model, star_level, content, create_time) VALUES (%s, %s, %s, %s, %s, %s) ON DUPLICATE KEY UPDATE comment_idcomment_id cursor.execute(sql, ( item[comment_id], item[user_name], item[car_model], item[star_level], content, item[create_time] )) conn.commit()这里有一个重要的细节数据库字符集一定用utf8mb4而不是utf8。因为评论里经常有emoji表情utf8存不了四字节字符入库会直接报错。这也是为什么我在热搜词里看到很多人搜索“MySQL编码”相关的问题绝大多数都栽在这里。3.4 遇到429 Too Many Requests的完整排查链路如果你也碰上了热搜词里那条exceeded retry limit, last status: 429 too many requests不要慌它本质是服务端限流不是代码逻辑错误。我当时的排查步骤是这样的你可以照着走一遍第一步确认报错位置。把请求日志打印出来看是连续第几个请求开始报429的记录报错前的时间间隔。我当时是连续请求不到几十次就开始报错说明默认的无间隔请求肯定不行。第二步增加随机延时。把固定sleep(1)改成随机sleep(1.5~3.5)让请求间隔更像人工操作。第三步如果还在报错检查是否被识别出非浏览器行为尝试补充完整的请求头特别是Referer和Cookie。有些接口需要先访问页面拿到Cookie才能请求数据。第四步如果依然被限流只能降低爬取总量分时段进行比如白天爬一部分、晚上再爬一部分。最后强调一点爬虫只用于学习和研究控制好频率、不要给目标站点造成压力这是基本的职业底线。4. 情感分析落地snowNLP在汽车评论场景的真实表现4.1 snowNLP是怎么算出情感得分的snowNLP的中文名是“一个友好的中文文本处理库”它的情感分析实现基于朴素贝叶斯分类器提前用正面语料和负面语料训练好模型对新输入的评论文本做分词再计算它属于正面类别的概率。输出的sentiments值介于0到1之间越接近1越正向越接近0越负向一般以0.5为分界线。from snownlp import SnowNLP text 底盘扎实转向精准开起来很稳 s SnowNLP(text) print(s.sentiments) # 输出接近0.9判定为正面这段代码看着简单但它背后的分词和概率计算是完整的。我用相同逻辑跑了上千条评论整体判断趋势是可用的但单条评论会有偏差原因是预训练语料和汽车评论的语感存在差异。4.2 汽车评论与电商评论的“语感差”snowNLP预训练语料主要来自电商购物评论比如“快递很快”、“质量不错”、“客服态度好”这类句子。而汽车评论是另外一个语料体系“低速顿挫”、“胎噪偏大”、“底盘滤震不错”、“操控指向性好”——这里面“顿挫”和“滤震”这类词在通用模型里根本没见过分词阶段就可能被切得七零八落情感概率自然不准。我做过一个小测试从全量评论里抽了400条人工标注正负中性用原始snowNLP跑一遍准确率只有七成左右。这说明直接拿来用可以但如果你想把这个项目做成“有优化过程、有实验对比”的毕业设计这个准确率数据反而是你最好的素材发现问题、分析原因、给出优化、验证效果完整的科研闭环就出来了。4.3 通过词典扩展和自定义训练提升准确率提升情感分析准确率有两个实用路径。第一个路径是扩展情感词典。snowNLP内置的情感词典位于snownlp/sentiment/__init__.py的sentiment_dict中你可以读取出来把汽车领域的高频情感词加进去。比如“推背感”、“扎实”、“隔音好”归入正向“顿挫”、“异响”、“掉电严重”归入负向。虽然是笨办法但效果立竿见影。第二个路径是自定义训练。先人工准备负面语料和正面语料各若干条然后调用snowNLP的训练接口from snownlp import sentiment # 每行一条评论 sentiment.train(./data/neg.txt, ./data/pos.txt) sentiment.save(./data/sentiment.marshal)训练完成后把生成的sentiment.marshal文件复制到snownlp/sentiment/目录下覆盖原文件再重启项目情感分析就会自动使用新模型。我当时用这个方法把准确率从七成左右提到了大约八成半。训练语料不用太多汽车领域每种正负各几百条就足以看到明显提升。4.4 让情感分析结果变成可业务化的指标情感分析不是算完单个得分就结束了我们要把结果聚合到“车型”这个业务维度上。对每个车型统计它的评论总数、平均情感得分、正向评论占比、负向评论占比按时间序列再统计一下走势就能看出“这一款车在最近半年口碑是变好还是变差”。这些指标是第6节可视化看板的主要数据来源。SELECT car_model, AVG(sentiment_score) AS avg_score, SUM(CASE WHEN sentiment_score 0.5 THEN 1 ELSE 0 END) / COUNT(*) AS pos_ratio, COUNT(*) AS comment_cnt FROM comments GROUP BY car_model;这条SQL相当于把几万条评论压缩成了一个二维表格每个车型一行记录。后面的可视化页面只用读取这个结果集就能画出柱状图、饼图和趋势线不需要在页面里再做任何计算。5. 协同过滤推荐从用户行为到“猜你喜欢”5.1 为什么选协同过滤而不是基于内容推荐内容推荐需要给每个车型构建属性向量比如价格区间、续航里程、车身尺寸还要做文本相似度计算工程量大且有主观性。协同过滤的思路完全不同它不需要知道车型本身有什么属性只需要用户的历史行为就能算出“看了这款车的人也被另一款车吸引”。对毕业设计来说协同过滤还有一个隐藏优势可解释。你可以给每个推荐结果附上一句话推荐理由比如“因为你给Model Y打了5星和你口味相似的用户也关注了极氪007”这种有业务故事性的推荐结果在答辩现场非常加分。5.2 从爬虫数据构建用户-车型评分矩阵在数据采集阶段我们存了user_name、car_model、star_level三个字段这正好是协同过滤的三要素。现在要把这些原始记录转成用户-车型评分矩阵行是用户列是车型交叉点是评分。import pandas as pd df pd.read_sql(SELECT user_name, car_model, star_level FROM comments, conn) rating_matrix df.pivot_table( indexuser_name, columnscar_model, valuesstar_level ).fillna(0)注意一个现实问题评论数据天然是稀疏的绝大多数用户只评论过一两款车矩阵里大量是0。这在协同过滤场景是正常的算法就是要从这稀疏的行为里找关联。如果觉得数据不够可以在爬虫阶段补充采集用户的“已关注车型”或“浏览记录”字段作为隐式评分的补充。5.3 基于物品的协同过滤的完整实现我推荐优先做基于物品的协同过滤ItemCF。原因是用户数膨胀的速度比车型数快得多车型数量相对固定计算物品相似矩阵的代价更可控。算法分两步第一步计算车型之间的相似度用余弦相似度即可第二步对用户已评分的车型按相似度加权汇总得到用户对未购车型的预测分。import numpy as np def cos_sim(a, b): if np.linalg.norm(a) 0 or np.linalg.norm(b) 0: return 0 return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)) matrix rating_matrix.T.values # 转置后行车型列用户 car_names rating_matrix.columns.tolist() n_items matrix.shape[0] item_sim np.zeros((n_items, n_items)) for i in range(n_items): for j in range(i 1, n_items): sim cos_sim(matrix[i], matrix[j]) item_sim[i][j] sim item_sim[j][i] sim def recommend(user_id, top_n5): user_vec rating_matrix.loc[user_id].values user_scores np.zeros(n_items) for i in range(n_items): if user_vec[i] 0: for j in range(n_items): if i ! j: user_scores[j] item_sim[i][j] * user_vec[i] top_indices np.argsort(user_scores)[::-1][:top_n] return [car_names[int(idx)] for idx in top_indices]这段代码的核心逻辑是某款车和用户已评分的车越相似它在用户推荐列表里的排序就越靠前。实际生产环境会用Spark或者更复杂的算法但这个简版实现完全够毕设演示和论文讲解了。5.4 冷启动与推荐结果的后处理协同过滤有一个典型问题叫“冷启动”新用户没有行为记录算法就无法推荐新车没有销量数据也无法被算法发现。我的兜底方案很简单——热门榜兜底。在首页设置一个“热门新能源车”板块按评论数量和平均评分排序让没有历史记录的用户也能看到不错的内容。推荐结果的后处理同样重要。裸跑算法时会发现一个现象推荐列表里全是同一品牌的车或者全是同一价位区间的车因为相似度计算不考虑品牌和价格。我会在推荐结果上做一层业务过滤比如按热度加权、限制单品牌最多出现两款车甚至结合价格区间微调让推荐结果更“像人话”。6. Django整合与可视化把分析结果变成产品界面6.1 核心数据模型和Django项目结构Django层面的核心是把第3、4、5节产出的数据接入Web框架。我建议按下面的方式组织项目目录car_review_system/ ├── manage.py ├── dataserver/ │ ├── models.py # 数据表结构 │ ├── views.py # 页面视图 │ ├── urls.py # 路由 │ └── admin.py # 后台注册 ├── static/ # 静态资源 ├── templates/ # HTML模板 ├── spider/ # 爬虫模块 ├── analysis/ # 情感分析模块 └── recommend/ # 协同过滤模块数据模型至少需要三张表Car车型表车型名称、品牌、价格段、发布日期、Comment评论表用户ID、车型外键、评分、内容、时间、情感得分、Rating评分表用户ID、车型外键、评分、时间。情感得分作为评论表的一个字段在分析模块批量计算后回写即可。from django.db import models class Car(models.Model): name models.CharField(max_length100, uniqueTrue) brand models.CharField(max_length50) price_range models.CharField(max_length20) class Comment(models.Model): car models.ForeignKey(Car, on_deletemodels.CASCADE, related_namecomments) user_name models.CharField(max_length100, db_indexTrue) rating models.IntegerField() content models.TextField() sentiment_score models.FloatField(default0.5) create_time models.DateTimeField(db_indexTrue)6.2 可视化看板图表选型与数据接口可视化我推荐直接用ECharts通过Django的JSON接口把数据喂给前端。如果不想手写前端pyecharts可以在Python侧直接生成HTML和JS适合不熟悉前端的同学。下面是一个典型的数据接口和图表思路# views.py def dashboard_data(request): result Comment.objects.values(car__name) \ .annotate(avg_scoreAvg(sentiment_score), comment_cntCount(id)) return JsonResponse(list(result), safeFalse)前端拿到这个接口以后可以做三张核心图表第一张是车型情感得分柱状图X轴是车型Y轴是平均情感分一眼看出谁的口碑最好第二张是评论情绪占比饼图统计全部评论正负向比例第三张是时间趋势折线图按月份统计平均情感分数观察口碑随时间的变化。图表不是堆得越多越好关键是每张图都要能解释一个业务问题。答辩时你指着图说“这是口碑最好的三款车主要正面评价集中在操控和续航”比放十个花哨图表但没有结论要有力得多。6.3 推荐结果页让推荐“看得懂、讲得清”推荐结果页设计上要突出两样东西一是推荐的车型列表二是推荐理由。车型列表直接调用第5节的recommend函数把当前登录用户的ID传进去得到车型ID列表后再去数据库查详情。推荐理由则是模板化的比如“根据你评论过的高分车型我们为你找到以下相似选择”。页面布局上我建议在顶部放一句个性化的提示语如“你好你一共评价过5款车型我们为你精选了以下3款”中部是推荐车型卡片带图片、价格区间、情感得分星标底部放一个“换一批”按钮调用相同推荐接口但排除已展示车型。这样的页面逻辑简单清晰却完整呈现了“数据驱动”的价值。7. 开发与答辩中躲不开的坑7.1 我在开发过程中踩过的高频报错这里挑几个真实遇到的报错按“报错信息-原因-解法”三列整理成表方便你遇到时直接查报错现象根本原因解决办法429 Too Many Requests请求频率过高被服务端限流降低频率、随机sleep、补充完整请求头Incorrect string value: \xF0\x9F...emoji无法存入utf8编码表数据库连接和表结构都改成utf8mb4ModuleNotFoundError: No module named snownlp未安装或虚拟环境未激活pip install snownlp激活对应环境MultiValueDictKeyError前端表单参数名和视图读取的Key不一致打印request.GET/request.POST核对参数名OperationalError: (2013, Lost connection...)爬虫跑太久导致MySQL连接空闲断开连接复用或每次操作后重连设置连接池推荐结果全为同一品牌协同过滤只用相似度未做业务过滤加入品牌去重、热度权重、价格段过滤7.2 答辩演示的关键路线答辩演示不要一上来就打开首页而是要按照“数据从哪里来、数据如何处理、算法如何工作、结果如何展示”这条主线来演。我总结了四个步骤第一步打开数据库或爬虫日志展示你已采集的评论数据规模证明工作量第二步进入情感分析模块现场贴一段评论文本展示情感打分过程和聚合结果第三步打开协同过滤推荐页找一个有历史记录的用户登录展示推荐列表和推荐理由第四步回到可视化看板把情感得分、趋势、占比用图表复述一遍。每一步之间要说一句承上启下的话。比如“刚才我们看了数据的分布接下来我用snowNLP对这个文本字段做批量情感分析结果已经写回数据库”“有了用户评分数据我们就可以用协同过滤计算车型相似度了”。这样整个演示就像讲故事一样老师跟着你的思路走提问也会更聚焦在细节而非宏观框架上。7.3 给代码仓库留出“呼吸感”最后这点是很多毕业设计容易忽略的代码仓库的组织方式直接影响到老师对你的印象分。我的习惯是一个清晰的README放在最前面写清楚项目简介、环境依赖、安装步骤、启动命令、模块说明和爬虫伦理声明。requirements.txt必须生成确保换一台机器也能一键复现环境。重要代码写注释但注释要写“为什么”而不是“做了什么”后者是废话。部署层面如果你想在答辩前把系统部署到服务器上可以用宝塔面板做一键部署Django项目配gunicorn Nginx很常见。这样即使教室的电脑环境不干净你也能用浏览器访问线上地址避免“演示现场环境崩了”的尴尬。我个人做完整套项目的最大体感是这种全链路项目的风险不在算法本身而在模块之间的衔接。爬虫字段和数据库表对不上、数据库表和ORM模型对不上、分析模块输出和前端接口对不上——任何一处脱节都会花掉大量调试时间。所以我的建议是动手写代码前先把字段设计、接口约定、页面原型三份文档列清楚哪怕就写在草稿本上也能让后面的开发顺畅得多。最后再分享一个小技巧开发时把情感分析的结果字段和推荐结果都存进数据库而不是每次请求页面时实时计算。一方面是速度更快另一方面是答辩演示时网络不稳定离线缓存好的结果能保证演示万无一失。这个项目做完之后你收获的绝不止是一个“能运行的系统”而是一整套从数据到价值的思考方式这正是毕业设计真正想要你练的东西。 
长河君 · 2026/9/9 20:58:35 · 阅读 1.2k 基于Python的新能源车评情感分析与协同过滤推荐系统设计
毕业设计选题的时候我见过太多同学一头扎进“XX管理系统”——图书管理、超市进销存、宿舍管理页面做得再花本质还是围着增删改查打转。答辩时老师一句“你的系统解决了什么问题”场面往往就冷下来了。而“Python新能源车评分析与协同过滤推荐系统”这个题目赢在选题思路上它不是一个单页面功能的堆叠而是一个从数据采集、文本分析到推荐服务的完整数据产品。这篇文章我会把整条链路拆开讲清楚——requests爬虫怎么采数据snowNLP怎么做情感分析协同过滤推荐算法怎么从用户行为里算出“猜你喜欢”最后Django怎么把这些能力集成成可演示的Web系统外加可视化看板。每一步都会带上关键代码和我在实际开发中踩过的坑。适合正在做毕业设计的学生想练一个“全栈数据分析”项目的开发者以及刚入行做Web开发、想拓展算法知识面的朋友。建议先收藏留着做完整个项目再回来看一遍感受会很不一样。1. 先聊透这个选题它为什么比“管理系统”更值得做1.1 一个完整的数据产品而不是几个孤立页面所有管理系统类项目的通病是数据靠手工录入、逻辑只有CRUD、没有算法没有流程。这类项目做得再工整也撑不起毕业设计要求的“工作量”和“创新点”。而这个题目天然带着三层深度。第一层是数据获取你需要用爬虫去抓新能源车评数据这涉及网络请求、数据解析、反爬应对本身就够写一章论文第二层是文本分析与算法拿到评论后不是放着看而是用snowNLP算情感倾向再用协同过滤算法挖掘用户偏好这一步直接决定了项目的含金量第三层是工程化呈现Django负责把数据、算法结果、可视化图表组织成一个可交互的网站让评审老师能直观看到效果。所以这个项目从立题开始就自带一条“采集—清洗—分析—建模—呈现”的完整业务链。答辩时老师问“你的创新点在哪里”你可以从“数据驱动的购车决策辅助”这个视角去组织答案而不是干巴巴地说“我用了xx框架”。1.2 系统最终能演示的四层能力我按最终交付版本梳理了一下这套系统在实际运行中应该具备以下能力也推荐你在设计数据库和页面时按这个清单去拆分模块层级能力技术落点数据层新能源车评论采集与存储requests MySQL/pymysql分析层评论情感评分与关键词提取snowNLP jieba分词算法层相似车型与个性化推荐协同过滤ItemCF展示层数据看板与推荐页面Django ECharts/pyecharts这四层不是各做各的而是层层有依赖关系。爬虫采回来的数据要清洗后写入数据库情感分析要读取评论文本做批量打分协同过滤要基于用户的历史评分构建矩阵最后的可视化页面又要从情感分析结果和推荐结果里拉数据。这种数据流上的串联正是答辩时最能体现“系统完整性”的地方。2. 技术栈拆解Django snowNLP 协同过滤为什么是黄金组合2.1 Django一个能扛住演示和答辩的Web框架选Django而不是Flask我算是吃过亏后得出的结论。一开始为了追求“轻量”我用Flask写了个单文件应用结果项目越加越大——爬虫独立成一个模块、情感分析一个模块、推荐一个模块、后台管理还要另写单文件马上失控。Django的MTV架构天然对这个场景友好Model管数据库表Template管页面View管业务逻辑App之间可以拆得很干净。另外Django自带Admin后台。评论数据、用户数据、车型数据这些需要人工审核和调整的内容直接在后台点一点就能修改不需要自己额外写一套管理界面。这对于毕业设计来说等于白送了一个管理模块的工作量。再加上Django的ORM操作MySQL很方便分页、事务、缓存这些高频功能都有现成实现能省下大量调bug的时间。2.2 snowNLP与requests轻量级方案的优势很多人一看到情感分析就想着上BERT、上深度学习但毕业设计场景里snowNLP这样的轻量级库反而更合适。snowNLP是一个纯Python实现的中文文本处理库不需要复杂的模型训练环境pip装完就能用。它内置了情感分析、中文分词、关键词提取等功能接口简单到一行代码就能出情感得分非常适合做快速原型验证。我在实际测试里发现它对汽车评论的基础情感判断大致可用但确实存在领域偏差后面第4节我会详细讲怎么优化。requests爬虫同理。Scrapy虽然功能强大但学习曲线陡、部署复杂而且结构化程度高反而不利于毕业设计中“把每一步讲清楚”的需求。requests库几十行代码就能写出一个能用的爬虫每一步都在明面上指导老师问起来你解释起来也轻松。对于几千到几万条的中等数据量requests的速度完全够用。2.3 系统整体的数据流与模块划分整个项目我划分为四个模块开发时按依赖顺序进行spider模块用requests请求评论接口解析JSON清洗后写入数据库。analysis模块读取评论文本用snowNLP计算情感得分聚合出车型维度的口碑指标。recommend模块从用户评分数据中构建评分矩阵用协同过滤算法计算相似车型并生成推荐列表。web模块Django主应用承载页面路由、登录交互、可视化图表展示和推荐结果展示。这个划分的好处是每个模块都可以单独测试、单独写论文章节。我实际开发时也是按这个顺序推进的先把数据爬到本地再离线做情感分析和推荐实验最后才把它们接进Django页面里。如果一上来就想着全套集成遇到问题会很难定位是爬虫的问题还是Web框架的问题。3. 数据采集用requests爬取新能源车评的完整实现3.1 先搞清楚要采什么字段爬虫不是拿到什么存什么而是要以分析目标为导向反推字段。这个项目里我们最终要做的情感分析和协同过滤分别需要两类不同的数据情感分析需要评论内容、评论时间、车型名称。协同过滤需要用户标识、车型标识、用户评分。所以爬虫核心表结构可以确定为评论ID、用户ID、车型名称、评分1-5星、评论内容、发布时间。其中用户ID和评分是协同过滤的关键输入评论内容是国家重点情感分析的关键输入。建议在爬虫设计阶段就先把字段想好否则后面数据清洗会非常痛苦。3.2 请求伪装与频率控制别把自己送进IP黑名单很多车评数据来自网页接口直接requests.get就能拿到JSON格式的响应但前提是你要先伪装成一个正常用户。这里有几件常规操作import requests import time import random HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://www.example.com/, Accept-Language: zh-CN,zh;q0.9 } def fetch_comments(page): url https://api.example.com/v1/comment/list params {car_id: 17, page: page, page_size: 20} resp requests.get(url, headersHEADERS, paramsparams, timeout10) return resp.json() for page in range(1, 50): data fetch_comments(pagepage) save_to_database(data) time.sleep(random.uniform(1.5, 3.5)) # 随机休眠模拟人工浏览这段代码中time.sleep(random.uniform(1.5, 3.5))是最容易被忽略的细节。我一开始图省事直接跑了一个for循环连续请求结果大约在几十个请求之后就触发了服务端的限流返回状态码429也就是Too Many Requests。这个错误不是你的代码语法有问题而是请求太频繁被服务端识别为爬虫了。3.3 从接口响应到结构化数据的清洗逻辑接口返回的JSON一般长这样{ code: 0, data: { list: [ { comment_id: 1024, user_name: 车友_5278, car_model: Model Y, star_level: 5, content: 续航扎实空间大唯一不满的是隔音一般, create_time: 2024-05-12 10:23:00 } ], total: 1500 } }存库前一定要做数据清洗我总结了四个必做的步骤第一去空值与兜底值。有些评论内容为空有些评分字段缺失直接丢弃或填充默认值否则后面情感分析时None值会直接报错。第二去重复。翻页时偶尔会出现重复数据按评论ID做一次排重要比存完再查高效得多。第三字段截断。评论内容有的很长建议统一截取到200-500字防止数据库字段长度溢出。第四时间格式化。create_time转成统一的时间格式后续做时间维度分析时就不用再救火。import pymysql conn pymysql.connect( hostlocalhost, userroot, password123456, databasecar_review, charsetutf8mb4 ) def save_to_database(items): with conn.cursor() as cursor: for item in items: content item[content].strip()[:500] if not content: continue sql INSERT INTO comments (comment_id, user_name, car_model, star_level, content, create_time) VALUES (%s, %s, %s, %s, %s, %s) ON DUPLICATE KEY UPDATE comment_idcomment_id cursor.execute(sql, ( item[comment_id], item[user_name], item[car_model], item[star_level], content, item[create_time] )) conn.commit()这里有一个重要的细节数据库字符集一定用utf8mb4而不是utf8。因为评论里经常有emoji表情utf8存不了四字节字符入库会直接报错。这也是为什么我在热搜词里看到很多人搜索“MySQL编码”相关的问题绝大多数都栽在这里。3.4 遇到429 Too Many Requests的完整排查链路如果你也碰上了热搜词里那条exceeded retry limit, last status: 429 too many requests不要慌它本质是服务端限流不是代码逻辑错误。我当时的排查步骤是这样的你可以照着走一遍第一步确认报错位置。把请求日志打印出来看是连续第几个请求开始报429的记录报错前的时间间隔。我当时是连续请求不到几十次就开始报错说明默认的无间隔请求肯定不行。第二步增加随机延时。把固定sleep(1)改成随机sleep(1.5~3.5)让请求间隔更像人工操作。第三步如果还在报错检查是否被识别出非浏览器行为尝试补充完整的请求头特别是Referer和Cookie。有些接口需要先访问页面拿到Cookie才能请求数据。第四步如果依然被限流只能降低爬取总量分时段进行比如白天爬一部分、晚上再爬一部分。最后强调一点爬虫只用于学习和研究控制好频率、不要给目标站点造成压力这是基本的职业底线。4. 情感分析落地snowNLP在汽车评论场景的真实表现4.1 snowNLP是怎么算出情感得分的snowNLP的中文名是“一个友好的中文文本处理库”它的情感分析实现基于朴素贝叶斯分类器提前用正面语料和负面语料训练好模型对新输入的评论文本做分词再计算它属于正面类别的概率。输出的sentiments值介于0到1之间越接近1越正向越接近0越负向一般以0.5为分界线。from snownlp import SnowNLP text 底盘扎实转向精准开起来很稳 s SnowNLP(text) print(s.sentiments) # 输出接近0.9判定为正面这段代码看着简单但它背后的分词和概率计算是完整的。我用相同逻辑跑了上千条评论整体判断趋势是可用的但单条评论会有偏差原因是预训练语料和汽车评论的语感存在差异。4.2 汽车评论与电商评论的“语感差”snowNLP预训练语料主要来自电商购物评论比如“快递很快”、“质量不错”、“客服态度好”这类句子。而汽车评论是另外一个语料体系“低速顿挫”、“胎噪偏大”、“底盘滤震不错”、“操控指向性好”——这里面“顿挫”和“滤震”这类词在通用模型里根本没见过分词阶段就可能被切得七零八落情感概率自然不准。我做过一个小测试从全量评论里抽了400条人工标注正负中性用原始snowNLP跑一遍准确率只有七成左右。这说明直接拿来用可以但如果你想把这个项目做成“有优化过程、有实验对比”的毕业设计这个准确率数据反而是你最好的素材发现问题、分析原因、给出优化、验证效果完整的科研闭环就出来了。4.3 通过词典扩展和自定义训练提升准确率提升情感分析准确率有两个实用路径。第一个路径是扩展情感词典。snowNLP内置的情感词典位于snownlp/sentiment/__init__.py的sentiment_dict中你可以读取出来把汽车领域的高频情感词加进去。比如“推背感”、“扎实”、“隔音好”归入正向“顿挫”、“异响”、“掉电严重”归入负向。虽然是笨办法但效果立竿见影。第二个路径是自定义训练。先人工准备负面语料和正面语料各若干条然后调用snowNLP的训练接口from snownlp import sentiment # 每行一条评论 sentiment.train(./data/neg.txt, ./data/pos.txt) sentiment.save(./data/sentiment.marshal)训练完成后把生成的sentiment.marshal文件复制到snownlp/sentiment/目录下覆盖原文件再重启项目情感分析就会自动使用新模型。我当时用这个方法把准确率从七成左右提到了大约八成半。训练语料不用太多汽车领域每种正负各几百条就足以看到明显提升。4.4 让情感分析结果变成可业务化的指标情感分析不是算完单个得分就结束了我们要把结果聚合到“车型”这个业务维度上。对每个车型统计它的评论总数、平均情感得分、正向评论占比、负向评论占比按时间序列再统计一下走势就能看出“这一款车在最近半年口碑是变好还是变差”。这些指标是第6节可视化看板的主要数据来源。SELECT car_model, AVG(sentiment_score) AS avg_score, SUM(CASE WHEN sentiment_score 0.5 THEN 1 ELSE 0 END) / COUNT(*) AS pos_ratio, COUNT(*) AS comment_cnt FROM comments GROUP BY car_model;这条SQL相当于把几万条评论压缩成了一个二维表格每个车型一行记录。后面的可视化页面只用读取这个结果集就能画出柱状图、饼图和趋势线不需要在页面里再做任何计算。5. 协同过滤推荐从用户行为到“猜你喜欢”5.1 为什么选协同过滤而不是基于内容推荐内容推荐需要给每个车型构建属性向量比如价格区间、续航里程、车身尺寸还要做文本相似度计算工程量大且有主观性。协同过滤的思路完全不同它不需要知道车型本身有什么属性只需要用户的历史行为就能算出“看了这款车的人也被另一款车吸引”。对毕业设计来说协同过滤还有一个隐藏优势可解释。你可以给每个推荐结果附上一句话推荐理由比如“因为你给Model Y打了5星和你口味相似的用户也关注了极氪007”这种有业务故事性的推荐结果在答辩现场非常加分。5.2 从爬虫数据构建用户-车型评分矩阵在数据采集阶段我们存了user_name、car_model、star_level三个字段这正好是协同过滤的三要素。现在要把这些原始记录转成用户-车型评分矩阵行是用户列是车型交叉点是评分。import pandas as pd df pd.read_sql(SELECT user_name, car_model, star_level FROM comments, conn) rating_matrix df.pivot_table( indexuser_name, columnscar_model, valuesstar_level ).fillna(0)注意一个现实问题评论数据天然是稀疏的绝大多数用户只评论过一两款车矩阵里大量是0。这在协同过滤场景是正常的算法就是要从这稀疏的行为里找关联。如果觉得数据不够可以在爬虫阶段补充采集用户的“已关注车型”或“浏览记录”字段作为隐式评分的补充。5.3 基于物品的协同过滤的完整实现我推荐优先做基于物品的协同过滤ItemCF。原因是用户数膨胀的速度比车型数快得多车型数量相对固定计算物品相似矩阵的代价更可控。算法分两步第一步计算车型之间的相似度用余弦相似度即可第二步对用户已评分的车型按相似度加权汇总得到用户对未购车型的预测分。import numpy as np def cos_sim(a, b): if np.linalg.norm(a) 0 or np.linalg.norm(b) 0: return 0 return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)) matrix rating_matrix.T.values # 转置后行车型列用户 car_names rating_matrix.columns.tolist() n_items matrix.shape[0] item_sim np.zeros((n_items, n_items)) for i in range(n_items): for j in range(i 1, n_items): sim cos_sim(matrix[i], matrix[j]) item_sim[i][j] sim item_sim[j][i] sim def recommend(user_id, top_n5): user_vec rating_matrix.loc[user_id].values user_scores np.zeros(n_items) for i in range(n_items): if user_vec[i] 0: for j in range(n_items): if i ! j: user_scores[j] item_sim[i][j] * user_vec[i] top_indices np.argsort(user_scores)[::-1][:top_n] return [car_names[int(idx)] for idx in top_indices]这段代码的核心逻辑是某款车和用户已评分的车越相似它在用户推荐列表里的排序就越靠前。实际生产环境会用Spark或者更复杂的算法但这个简版实现完全够毕设演示和论文讲解了。5.4 冷启动与推荐结果的后处理协同过滤有一个典型问题叫“冷启动”新用户没有行为记录算法就无法推荐新车没有销量数据也无法被算法发现。我的兜底方案很简单——热门榜兜底。在首页设置一个“热门新能源车”板块按评论数量和平均评分排序让没有历史记录的用户也能看到不错的内容。推荐结果的后处理同样重要。裸跑算法时会发现一个现象推荐列表里全是同一品牌的车或者全是同一价位区间的车因为相似度计算不考虑品牌和价格。我会在推荐结果上做一层业务过滤比如按热度加权、限制单品牌最多出现两款车甚至结合价格区间微调让推荐结果更“像人话”。6. Django整合与可视化把分析结果变成产品界面6.1 核心数据模型和Django项目结构Django层面的核心是把第3、4、5节产出的数据接入Web框架。我建议按下面的方式组织项目目录car_review_system/ ├── manage.py ├── dataserver/ │ ├── models.py # 数据表结构 │ ├── views.py # 页面视图 │ ├── urls.py # 路由 │ └── admin.py # 后台注册 ├── static/ # 静态资源 ├── templates/ # HTML模板 ├── spider/ # 爬虫模块 ├── analysis/ # 情感分析模块 └── recommend/ # 协同过滤模块数据模型至少需要三张表Car车型表车型名称、品牌、价格段、发布日期、Comment评论表用户ID、车型外键、评分、内容、时间、情感得分、Rating评分表用户ID、车型外键、评分、时间。情感得分作为评论表的一个字段在分析模块批量计算后回写即可。from django.db import models class Car(models.Model): name models.CharField(max_length100, uniqueTrue) brand models.CharField(max_length50) price_range models.CharField(max_length20) class Comment(models.Model): car models.ForeignKey(Car, on_deletemodels.CASCADE, related_namecomments) user_name models.CharField(max_length100, db_indexTrue) rating models.IntegerField() content models.TextField() sentiment_score models.FloatField(default0.5) create_time models.DateTimeField(db_indexTrue)6.2 可视化看板图表选型与数据接口可视化我推荐直接用ECharts通过Django的JSON接口把数据喂给前端。如果不想手写前端pyecharts可以在Python侧直接生成HTML和JS适合不熟悉前端的同学。下面是一个典型的数据接口和图表思路# views.py def dashboard_data(request): result Comment.objects.values(car__name) \ .annotate(avg_scoreAvg(sentiment_score), comment_cntCount(id)) return JsonResponse(list(result), safeFalse)前端拿到这个接口以后可以做三张核心图表第一张是车型情感得分柱状图X轴是车型Y轴是平均情感分一眼看出谁的口碑最好第二张是评论情绪占比饼图统计全部评论正负向比例第三张是时间趋势折线图按月份统计平均情感分数观察口碑随时间的变化。图表不是堆得越多越好关键是每张图都要能解释一个业务问题。答辩时你指着图说“这是口碑最好的三款车主要正面评价集中在操控和续航”比放十个花哨图表但没有结论要有力得多。6.3 推荐结果页让推荐“看得懂、讲得清”推荐结果页设计上要突出两样东西一是推荐的车型列表二是推荐理由。车型列表直接调用第5节的recommend函数把当前登录用户的ID传进去得到车型ID列表后再去数据库查详情。推荐理由则是模板化的比如“根据你评论过的高分车型我们为你找到以下相似选择”。页面布局上我建议在顶部放一句个性化的提示语如“你好你一共评价过5款车型我们为你精选了以下3款”中部是推荐车型卡片带图片、价格区间、情感得分星标底部放一个“换一批”按钮调用相同推荐接口但排除已展示车型。这样的页面逻辑简单清晰却完整呈现了“数据驱动”的价值。7. 开发与答辩中躲不开的坑7.1 我在开发过程中踩过的高频报错这里挑几个真实遇到的报错按“报错信息-原因-解法”三列整理成表方便你遇到时直接查报错现象根本原因解决办法429 Too Many Requests请求频率过高被服务端限流降低频率、随机sleep、补充完整请求头Incorrect string value: \xF0\x9F...emoji无法存入utf8编码表数据库连接和表结构都改成utf8mb4ModuleNotFoundError: No module named snownlp未安装或虚拟环境未激活pip install snownlp激活对应环境MultiValueDictKeyError前端表单参数名和视图读取的Key不一致打印request.GET/request.POST核对参数名OperationalError: (2013, Lost connection...)爬虫跑太久导致MySQL连接空闲断开连接复用或每次操作后重连设置连接池推荐结果全为同一品牌协同过滤只用相似度未做业务过滤加入品牌去重、热度权重、价格段过滤7.2 答辩演示的关键路线答辩演示不要一上来就打开首页而是要按照“数据从哪里来、数据如何处理、算法如何工作、结果如何展示”这条主线来演。我总结了四个步骤第一步打开数据库或爬虫日志展示你已采集的评论数据规模证明工作量第二步进入情感分析模块现场贴一段评论文本展示情感打分过程和聚合结果第三步打开协同过滤推荐页找一个有历史记录的用户登录展示推荐列表和推荐理由第四步回到可视化看板把情感得分、趋势、占比用图表复述一遍。每一步之间要说一句承上启下的话。比如“刚才我们看了数据的分布接下来我用snowNLP对这个文本字段做批量情感分析结果已经写回数据库”“有了用户评分数据我们就可以用协同过滤计算车型相似度了”。这样整个演示就像讲故事一样老师跟着你的思路走提问也会更聚焦在细节而非宏观框架上。7.3 给代码仓库留出“呼吸感”最后这点是很多毕业设计容易忽略的代码仓库的组织方式直接影响到老师对你的印象分。我的习惯是一个清晰的README放在最前面写清楚项目简介、环境依赖、安装步骤、启动命令、模块说明和爬虫伦理声明。requirements.txt必须生成确保换一台机器也能一键复现环境。重要代码写注释但注释要写“为什么”而不是“做了什么”后者是废话。部署层面如果你想在答辩前把系统部署到服务器上可以用宝塔面板做一键部署Django项目配gunicorn Nginx很常见。这样即使教室的电脑环境不干净你也能用浏览器访问线上地址避免“演示现场环境崩了”的尴尬。我个人做完整套项目的最大体感是这种全链路项目的风险不在算法本身而在模块之间的衔接。爬虫字段和数据库表对不上、数据库表和ORM模型对不上、分析模块输出和前端接口对不上——任何一处脱节都会花掉大量调试时间。所以我的建议是动手写代码前先把字段设计、接口约定、页面原型三份文档列清楚哪怕就写在草稿本上也能让后面的开发顺畅得多。最后再分享一个小技巧开发时把情感分析的结果字段和推荐结果都存进数据库而不是每次请求页面时实时计算。一方面是速度更快另一方面是答辩演示时网络不稳定离线缓存好的结果能保证演示万无一失。这个项目做完之后你收获的绝不止是一个“能运行的系统”而是一整套从数据到价值的思考方式这正是毕业设计真正想要你练的东西。