基于Python的新能源车评情感分析与协同过滤推荐系统设计

毕业设计选题的时候，我见过太多同学一头扎进“XX管理系统”——图书管理、超市进销存、宿舍管理，页面做得再花，本质还是围着增删改查打转。答辩时老师一句“你的系统解决了什么问题”，场面往往就冷下来了。而“Python新能源车评分析与协同过滤推荐系统”这个题目，赢在选题思路上：它不是一个单页面功能的堆叠，而是一个从数据采集、文本分析到推荐服务的完整数据产品。

这篇文章我会把整条链路拆开讲清楚——requests爬虫怎么采数据，snowNLP怎么做情感分析，协同过滤推荐算法怎么从用户行为里算出“猜你喜欢”，最后Django怎么把这些能力集成成可演示的Web系统，外加可视化看板。每一步都会带上关键代码和我在实际开发中踩过的坑。适合正在做毕业设计的学生，想练一个“全栈数据分析”项目的开发者，以及刚入行做Web开发、想拓展算法知识面的朋友。建议先收藏，留着做完整个项目再回来看一遍，感受会很不一样。

1. 先聊透这个选题：它为什么比“管理系统”更值得做

1.1 一个完整的数据产品，而不是几个孤立页面

所有管理系统类项目的通病是：数据靠手工录入、逻辑只有CRUD、没有算法没有流程。这类项目做得再工整，也撑不起毕业设计要求的“工作量”和“创新点”。

而这个题目天然带着三层深度。第一层是数据获取，你需要用爬虫去抓新能源车评数据，这涉及网络请求、数据解析、反爬应对，本身就够写一章论文；第二层是文本分析与算法，拿到评论后不是放着看，而是用snowNLP算情感倾向，再用协同过滤算法挖掘用户偏好，这一步直接决定了项目的含金量；第三层是工程化呈现，Django负责把数据、算法结果、可视化图表组织成一个可交互的网站，让评审老师能直观看到效果。

所以这个项目从立题开始，就自带一条“采集—清洗—分析—建模—呈现”的完整业务链。答辩时老师问“你的创新点在哪里”，你可以从“数据驱动的购车决策辅助”这个视角去组织答案，而不是干巴巴地说“我用了xx框架”。

1.2 系统最终能演示的四层能力

我按最终交付版本梳理了一下，这套系统在实际运行中应该具备以下能力，也推荐你在设计数据库和页面时按这个清单去拆分模块：

这四层不是各做各的，而是层层有依赖关系。爬虫采回来的数据要清洗后写入数据库；情感分析要读取评论文本做批量打分；协同过滤要基于用户的历史评分构建矩阵；最后的可视化页面又要从情感分析结果和推荐结果里拉数据。这种数据流上的串联，正是答辩时最能体现“系统完整性”的地方。

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 系统整体的数据流与模块划分

整个项目我划分为四个模块，开发时按依赖顺序进行：

1. spider模块：用requests请求评论接口，解析JSON，清洗后写入数据库。
2. analysis模块：读取评论文本，用snowNLP计算情感得分，聚合出车型维度的口碑指标。
3. recommend模块：从用户评分数据中构建评分矩阵，用协同过滤算法计算相似车型并生成推荐列表。
4. 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;q=0.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, headers=HEADERS, params=params, timeout=10) return resp.json() for page in range(1, 50): data = fetch_comments(page=page) 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( host="localhost", user="root", password="123456", database="car_review", charset="utf8mb4" ) 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_id=comment_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( index='user_name', columns='car_model', values='star_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_n=5): 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_length=100, unique=True) brand = models.CharField(max_length=50) price_range = models.CharField(max_length=20) class Comment(models.Model): car = models.ForeignKey(Car, on_delete=models.CASCADE, related_name='comments') user_name = models.CharField(max_length=100, db_index=True) rating = models.IntegerField() content = models.TextField() sentiment_score = models.FloatField(default=0.5) create_time = models.DateTimeField(db_index=True)

6.2 可视化看板：图表选型与数据接口

可视化我推荐直接用ECharts，通过Django的JSON接口把数据喂给前端。如果不想手写前端，pyecharts可以在Python侧直接生成HTML和JS，适合不熟悉前端的同学。下面是一个典型的数据接口和图表思路：

# views.py def dashboard_data(request): result = Comment.objects.values('car__name') \ .annotate(avg_score=Avg('sentiment_score'), comment_cnt=Count('id')) return JsonResponse(list(result), safe=False)

前端拿到这个接口以后，可以做三张核心图表：第一张是车型情感得分柱状图，X轴是车型，Y轴是平均情感分，一眼看出谁的口碑最好；第二张是评论情绪占比饼图，统计全部评论正负向比例；第三张是时间趋势折线图，按月份统计平均情感分数，观察口碑随时间的变化。

图表不是堆得越多越好，关键是每张图都要能解释一个业务问题。答辩时你指着图说“这是口碑最好的三款车，主要正面评价集中在操控和续航”，比放十个花哨图表但没有结论要有力得多。

6.3 推荐结果页：让推荐“看得懂、讲得清”

推荐结果页设计上要突出两样东西：一是推荐的车型列表，二是推荐理由。车型列表直接调用第5节的recommend函数，把当前登录用户的ID传进去，得到车型ID列表后再去数据库查详情。推荐理由则是模板化的，比如“根据你评论过的高分车型，我们为你找到以下相似选择”。

页面布局上，我建议在顶部放一句个性化的提示语，如“你好，你一共评价过5款车型，我们为你精选了以下3款”；中部是推荐车型卡片，带图片、价格区间、情感得分星标；底部放一个“换一批”按钮，调用相同推荐接口但排除已展示车型。这样的页面逻辑简单清晰，却完整呈现了“数据驱动”的价值。

7. 开发与答辩中躲不开的坑

7.1 我在开发过程中踩过的高频报错

这里挑几个真实遇到的报错，按“报错信息-原因-解法”三列整理成表，方便你遇到时直接查：

7.2 答辩演示的关键路线

答辩演示不要一上来就打开首页，而是要按照“数据从哪里来、数据如何处理、算法如何工作、结果如何展示”这条主线来演。我总结了四个步骤：第一步，打开数据库或爬虫日志，展示你已采集的评论数据规模，证明工作量；第二步，进入情感分析模块，现场贴一段评论文本，展示情感打分过程和聚合结果；第三步，打开协同过滤推荐页，找一个有历史记录的用户登录，展示推荐列表和推荐理由；第四步，回到可视化看板，把情感得分、趋势、占比用图表复述一遍。

每一步之间要说一句承上启下的话。比如“刚才我们看了数据的分布，接下来我用snowNLP对这个文本字段做批量情感分析，结果已经写回数据库”，“有了用户评分数据，我们就可以用协同过滤计算车型相似度了”。这样整个演示就像讲故事一样，老师跟着你的思路走，提问也会更聚焦在细节而非宏观框架上。

7.3 给代码仓库留出“呼吸感”

最后这点是很多毕业设计容易忽略的：代码仓库的组织方式，直接影响到老师对你的印象分。我的习惯是一个清晰的README放在最前面，写清楚项目简介、环境依赖、安装步骤、启动命令、模块说明和爬虫伦理声明。requirements.txt必须生成，确保换一台机器也能一键复现环境。重要代码写注释，但注释要写“为什么”而不是“做了什么”，后者是废话。

部署层面，如果你想在答辩前把系统部署到服务器上，可以用宝塔面板做一键部署，Django项目配gunicorn + Nginx很常见。这样即使教室的电脑环境不干净，你也能用浏览器访问线上地址，避免“演示现场环境崩了”的尴尬。

我个人做完整套项目的最大体感是：这种全链路项目的风险不在算法本身，而在模块之间的衔接。爬虫字段和数据库表对不上、数据库表和ORM模型对不上、分析模块输出和前端接口对不上——任何一处脱节都会花掉大量调试时间。所以我的建议是，动手写代码前先把字段设计、接口约定、页面原型三份文档列清楚，哪怕就写在草稿本上，也能让后面的开发顺畅得多。

最后再分享一个小技巧：开发时把情感分析的结果字段和推荐结果都存进数据库，而不是每次请求页面时实时计算。一方面是速度更快，另一方面是答辩演示时网络不稳定，离线缓存好的结果能保证演示万无一失。这个项目做完之后，你收获的绝不止是一个“能运行的系统”，而是一整套从数据到价值的思考方式，这正是毕业设计真正想要你练的东西。