毕业设计做“Django+DeepSeek大模型新能源汽车销量预测分析可视化+推荐系统”,这个选题我第一眼看到就觉得挺聪明的。它把Web开发、数据分析、机器学习、大模型应用几个热点全串起来了,而且切的是新能源车这个热门行业,无论是毕业答辩还是找工作拿出来聊,都很有话题性。最近后台也经常有学弟学妹问这类项目怎么从零搭起来,今天就结合我自己做过的类似项目,把这条技术路线完整拆一遍,从技术选型、数据准备、模型实现到可视化落地,再到答辩常踩的坑,一次性说清楚。
1. 项目全貌与技术选型分析
1.1 这个项目到底在做什么
先花半分钟把项目边界理清楚。表面上这是一个毕设项目,实际上它包含三条相对独立又互相嵌套的功能线:
- 销量预测:基于新能源汽车的历史销量数据,预测未来一段时间(比如未来3个月)的销量走势。
- 分析可视化:把销量数据按品牌、车型、地域、时间维度做统计分析,用图表呈现出来,形成数据大屏。
- 智能推荐:基于用户的行为数据或车辆属性,推荐适合用户的新能源车型。
而DeepSeek大模型在这三条线里都有用武之地:它可以做销量预测的辅助分析、生成推荐理由、处理自然语言查询,甚至帮你生成可视化的图表配置代码。
简单说,这个项目就是用Django把后端服务、预测模型和推荐逻辑串起来,用前端可视化呈现结果,再用DeepSeek大模型做智能化的增强。整套系统做下来,Web、算法、大模型三个方向的能力全展示到了,这是它作为毕设项目的核心价值。
1.2 技术栈选型的真实原因
我见过不少同学一上来就追新求全,非要上Spring Boot、Vue3、ClickHouse、Flink那一整套,结果三个月连环境都没调通。毕设项目第一原则是能在有限时间内完整落地,不是造火箭。
选Django的原因很直接:
- 自带Admin后台:数据管理页面几乎零代码生成,展示CRUD能力非常方便。
- ORM数据库操作:不用手写SQL,对于非科班或者数据库基础薄弱的同学很友好。
- 生态成熟:配合DRF(Django REST Framework)写API接口非常快,前端展示层随便你怎么接。
- 部署资料多:宝塔面板一键部署Django项目的教程遍地都是,答辩演示出问题的概率低。
选DeepSeek大模型的原因更简单:它提供了开放的API接口,不需要你本地部署推理服务,注册后拿Key就能调用,成本低、速度快、效果也很能打。需要注意的是,DeepSeek提供了多个版本的API,有对话补全接口,也有推理模型接口,本项目里我推荐用对话补全接口来做辅助分析和推荐理由生成,性价比最高。
1.3 毕设版与生产版的尺度把握
这个项目必须想清楚“论文怎么写”和“系统怎么做”之间的边界。不要试图把推荐系统做成抖音那种实时流式计算,也不要试图把销量预测做到精确到个位数。毕设的核心逻辑是:体现你掌握了技术方法,并且能合理解释结果。
我给学生定的标准是:
- 销量预测:用传统时序模型(ARIMA、Prophet、LSTM)做主力预测,用DeepSeek做结果解读和大模型辅助修正。
- 推荐系统:用基于内容的推荐(车型属性相似度)做主力,用协同过滤做辅助,用DeepSeek生成个性化的推荐理由。
- 可视化:用ECharts渲染大屏图表,用Django提供数据接口。
这样每个环节都有明确的技术点,每个技术点都是面试官/答辩老师熟悉的东西,而且大模型的应用点非常突出,属于“加分项”设计。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据准备与特征工程
2.1 数据集怎么来
数据是这类项目最大的拦路虎。很多同学卡在“没有数据”这一步,其实有几条可行的路子:
- 公开数据集:国内有第三方数据平台提供新能源汽车销量数据,比如一些数据竞赛平台的历史数据,搜“新能源汽车销量数据集”能找到不少。
- 爬虫获取:从汽车垂直网站爬销量榜单数据,这个技术上可行,但要注意爬取频率,别给人家服务器添麻烦。
- 模拟生成:实在找不到数据,就用Python的Faker库配合正态分布模拟一批符合真实分布规律的数据。重点是数据字段要完整:日期、品牌、车型、销量、省份、城市、售价区间、续航里程、电池类型等。
我个人建议数据量至少覆盖36个月,因为月度销量数据要看出趋势和季节性,至少需要两年半以上的数据窗口。如果你用的是周度数据,那数据量可以适当减少。
2.2 特征工程的三个核心方向
销量预测和推荐系统本质上都是在和特征打交道。这部分的处理质量直接决定后续模型效果,千万不能马虎。
时间特征:对于销量预测,年月日、季度、月份、是否节假日、是否月初/月末(汽车销售有月底冲量规律)这些都要拆出来。如果是做月度预测,至少要保留月份、季度、年份三个维度。
车型属性特征:对于推荐系统,车型的售价、级别(微型/紧凑型/中型/中大型/SUV/MPV)、能源类型(纯电/插混/增程)、续航里程、电池容量、加速性能、智能化配置水平,这些都是计算相似度的重要维度。
外部环境特征:如果有条件,把油价、补贴政策、新车型上市时间作为外部变量加入预测模型,预测精度会有明显提升。这块做得好,论文里能多写两页,面试时也能讲出彩。
2.3 数据清洗的几个坑
这块我实测踩过不少坑,单拎出来说:
- 销量数据缺失:有些冷门车型某个月销量为0或者缺失,直接删掉会影响数据连续性,建议用前后月均值填充。
- 同品牌多车型合并:同一个品牌下车型名称混乱(比如“Model Y”和“Model Y 后驱版”算同一车型),需要手动做归一化处理。
- 日期格式不统一:从不同来源拿到的数据,日期有“2024-01”“2024年1月”“2024/1/1”各种格式,统一用Pandas的to_datetime处理。
- 异常值识别:某些月份的销量会突然暴增或暴跌(比如某车型集中交付),这可能是真实数据也可能是录入错误。建议用3sigma原则识别异常值,但不建议直接删除,要结合背景判断。
提示:处理完的数据务必导出成CSV存档,并写一份数据说明文档,包含字段含义、数据来源、清洗规则。答辩时老师很可能追问数据来源和处理过程,这份文档就是你的“护身符”。
3. 销量预测模块的实现
3.1 预测模型选型:传统时序模型还是大模型
关于销量预测,很多同学的直觉是“让DeepSeek直接预测”。说实话,纯靠大模型做数值预测,效果并不稳定。大模型本质上是语言模型,它的强项是理解和生成文本,而不是精确的数值回归。
我的做法是双引擎结构:
- 数值预测引擎:使用传统时序模型(Prophet或者LSTM)给出基准预测值。
- 语义增强引擎:把历史销量统计特征、模型预测结果、市场背景信息组装成Prompt,让DeepSeek做两件事——第一,对预测结果做合理性校验;第二,输出自然语言的预测分析报告。
这样做的好处是:论文里你既展示了经典机器学习的功底,又展示了大模型应用的能力,两个技术路线都有实际落地,不是单纯的“调包”。
3.2 Prophet模型的核心实现
Prophet是Facebook开源的时间序列预测库,对非专业出身很友好,不需要太多调参就能得到不错的结果。核心代码如下:
python复制import pandas as pd
from prophet import Prophet
import matplotlib.pyplot as plt
# 读取数据,Prophet要求两列:ds(日期)、y(销量)
df = pd.read_csv('sales_data.csv')
df['ds'] = pd.to_datetime(df['date'])
df['y'] = df['sales']
# 初始化模型,添加年周期和月周期
model = Prophet(
yearly_seasonality=True,
weekly_seasonality=False,
daily_seasonality=False,
seasonality_mode='multiplicative'
)
# 添加节假日效应(比如春节、国庆对销售的影响)
model.add_country_holidays(country_name='CN')
model.fit(df)
# 预测未来90天
future = model.make_future_dataframe(periods=90)
forecast = model.predict(future)
# 输出预测结果
result = forecast[['ds', 'yhat', 'yhat_lower', 'yhat_upper']].tail(90)
print(result)
这里有两个细节值得注意:
- seasonality_mode选择multiplicative:汽车销量受旺季、淡季影响增幅较大,乘法季节性比加法季节性拟合效果更好,误差通常能降低10%-15%。
- add_country_holidays('CN'):这个方法会自动加载中国的法定节假日列表,春节、国庆期间的销量波动会被模型识别为假日效应,预测曲线不会出现突兀的“尖刺”。
3.3 DeepSeek API调用与Prompt设计
DeepSeek的API调用方式与OpenAI兼容,直接用Python的requests或者openai库就行。我习惯用openai库,因为它在中文环境下资料多、坑少:
python复制from openai import OpenAI
client = OpenAI(
api_key="你的DeepSeek API Key",
base_url="https://api.deepseek.com"
)
def get_prediction_analysis(history_stats, forecast_values, model_name):
prompt = f"""
你是一名资深的新能源汽车市场分析师。
以下是某品牌近12个月的实际销量数据和模型预测的未来90天销量数据:
近12个月历史销量(月):
{history_stats}
模型({model_name})预测的未来90天销量(周粒度):
{forecast_values}
请完成以下任务:
1. 判断该预测结果是否合理,若不合理请说明可能的原因;
2. 解读销量变化趋势,指出关键拐点和可能的影响因素;
3. 给出针对市场策略的简短建议。
请用简洁的中文回答,控制在300字以内。
"""
response = client.chat.completions.create(
model="deepseek-chat",
messages=[
{"role": "system", "content": "你是新能源市场分析专家,输出专业且简洁的分析报告。"},
{"role": "user", "content": prompt}
],
temperature=0.3,
max_tokens=800
)
return response.choices[0].message.content
这块的Prompt设计有三个经验:
- temperature设置低一点:分析类任务希望模型输出稳定,0.2到0.4之间的区间最合适,太高的温度会输出“抖机灵”式的答案。
- 把具体数据放进Prompt:一定要把真实的统计特征和预测数值粘贴进去,让模型“带着数据”分析,而不是让它凭空发挥。
- 明确角色定位:System消息里设置“新能源市场分析专家”,能让模型输出的专业性和用词准确度明显提升。
4. 推荐系统模块的实现
4.1 推荐策略:基于内容的相似度计算
毕设项目里我最推荐基于内容(Content-Based)的推荐算法,原因是:不需要用户行为历史数据,不需要处理冷启动问题,实现逻辑一眼就能看懂,答辩时最稳。
核心逻辑:计算目标用户感兴趣的车型(或用户画像特征向量)与车型库中每个车型的相似度,取Top N作为推荐结果。
python复制import numpy as np
import pandas as pd
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity
# 加载车型数据
cars = pd.read_csv('car_data.csv')
# 构造车型的文本描述特征(将多个属性拼成文本)
cars['feature_text'] = (
cars['brand'] + ' ' +
cars['level'] + ' ' +
cars['energy_type'] + ' ' +
cars['price_range'] + ' ' +
cars['range_km'].astype(str) + 'km ' +
cars['battery_type'] + ' ' +
cars['intelligence_level']
)
# TF-IDF向量化
tfidf = TfidfVectorizer(token_pattern=r'(?u)\b\w+\b')
feature_matrix = tfidf.fit_transform(cars['feature_text'])
# 计算余弦相似度矩阵
similarity_matrix = cosine_similarity(feature_matrix, feature_matrix)
# 推荐函数:输入车型ID,返回Top N相似车型
def recommend_similar_cars(car_id, top_n=5):
sim_scores = list(enumerate(similarity_matrix[car_id]))
sim_scores = sorted(sim_scores, key=lambda x: x[1], reverse=True)
sim_scores = sim_scores[1:top_n+1] # 去掉自身
car_indices = [i[0] for i in sim_scores]
return cars.iloc[car_indices][['brand', 'model', 'price_range', 'range_km']]
这个方案的关键点在于特征文本的构造。文本里包含的信息越丰富,相似度计算结果就越合理。比如一个用户关注“比亚迪 宋PLUS DM-i”,系统会优先推荐同样属于插混SUV、价格区间相近的车型,而不是把微型车推给用户。
4.2 大模型生成个性化推荐理由
推荐结果有了,但如果只是罗列车型清单,那也太“朴素”了。这里让DeepSeek上场,为每个推荐结果生成一段推荐理由,用户体验和演示效果都会有质的飞跃:
python复制def generate_recommendation_reason(user_pref, car_info):
prompt = f"""
用户偏好描述:{user_pref}
推荐车型信息:{car_info}
请基于用户偏好和车型信息,生成一段不超过80字的推荐理由,
要求:从用户需求出发,说明该车型为何匹配,语言自然不生硬,不要使用营销夸张词汇。
"""
# 调用DeepSeek API(同上模式,省略重复代码)
# ...
4.3 冷启动问题的处理
很多同学在答辩时被问到“新用户没有任何偏好数据怎么办”,这就是冷启动问题。我的处理方案比较务实:
- 热门推荐兜底:新用户没有偏好时,按照销量榜、口碑分做综合排序推荐,这就是“最热车型榜”。
- 引导式偏好采集:在系统页面上让用户选择几个偏好标签(比如预算区间、偏好级别、能源类型),瞬间生成粗粒度的用户画像,然后直接走基于内容的推荐流程。
- 大模型对话兜底:做一个“智能选车助手”页面,用户直接用自然语言描述需求(“我想找一台20万左右、续航600公里以上的SUV”),DeepSeek从文本中抽取结构化偏好,再交给推荐引擎处理。
最后一个方案我强烈建议做进去,因为它不仅解决了冷启动,还是你项目中大模型应用的最好展示窗口。答辩演示时现场让评委输入一句需求,系统自动推荐车型并输出理由,效果直接拉满。
5. Django集成与可视化展示
5.1 Django项目结构怎么组织
这部分非常容易做乱。很多同学把预测代码、推荐代码、视图函数全塞在views.py里,最后代码几千行根本没法维护。我这里给一个清晰的分层方案:
text复制newenergy_system/
├── manage.py
├── config/ # 项目配置目录
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ ├── sales/ # 销量管理应用
│ │ ├── models.py
│ │ ├── views.py
│ │ ├── forecast.py # 预测逻辑封装
│ │ └── urls.py
│ ├── recommend/ # 推荐系统应用
│ │ ├── models.py
│ │ ├── views.py
│ │ ├── recommendation.py # 推荐算法封装
│ │ └── urls.py
│ └── users/ # 用户管理应用(可选)
├── static/ # 静态资源
│ ├── css/
│ ├── js/
│ └── echarts/
├── templates/ # 前端模板
│ ├── dashboard.html
│ ├── forecast.html
│ └── recommend.html
└── utils/
├── deepseek_api.py # DeepSeek API统一封装
└── data_loader.py # 数据加载与预处理
预测逻辑封装成独立模块是我强烈建议的做法。不要直接在views.py里调Prophet,而是让views调用apps/sales/forecast.py里的函数,这样代码结构清晰,也方便在单元测试里单独测试预测功能。
5.2 可视化方案:ECharts + Dashboard
可视化是另一个展示大项,工作做得好不好,答辩时的直观印象差别很大。我推荐用ECharts,它对中文文档友好、图表类型丰富、上手成本低。
核心可视化图表至少要有:
- 销量趋势折线图:展示历史销量和预测销量,预测部分用虚线区分。
- 品牌占比饼图:展示不同品牌销量占比。
- 车型销量排行条形图:Top10车型销量排行。
- 地域分布热力图:展示各省市销量分布(如果数据里有地域字段)。
- 预测置信区间图:展示预测值上下界,体现“我在做预测,我知道预测有不确定性”。
Django侧只需要提供JSON接口,前端用Ajax拉数据渲染图表。核心接口示例:
python复制# apps/sales/views.py
import json
from django.http import JsonResponse
from .forecast import run_forecast
def forecast_data_api(request):
result = run_forecast()
return JsonResponse({
'status': 'success',
'history': result['history'],
'forecast': result['forecast'],
'upper': result['upper'],
'lower': result['lower']
})
前端拿到数据后,用ECharts的setOption渲染折线图,大约30行代码就能搞定一个带联动交互的预测图表。
5.3 前后端交互的几个细节
- 接口统一返回JSON格式:不要顺便返回HTML,前后端分离结构更清晰,也方便后续做移动端适配。
- 异步加载数据:用Ajax请求接口,页面初始加载时先显示骨架屏,数据到了再渲染图表,体验好很多。
- 加上简单的接口缓存:销量预测比较耗时(Prophet模型训练需要几秒),不要每次刷新页面都重算。可以把预测结果缓存到Django的cache框架里,设置TTL为1小时,性能提升立竿见影。
6. 部署上线与性能优化
6.1 从本机跑到云服务器的迁移
答辩前一定要把项目部署到公网可访问的服务器上,这样评委随时可以用手机、电脑访问你的系统,印象分会高很多。部署路线推荐:
方案一:宝塔面板(最推荐)
宝塔面板几乎是把Django部署难度降到了最低。大致流程:
- 服务器安装宝塔面板。
- 在宝塔中安装Python项目管理器、Nginx、MySQL。
- 上传项目代码,创建Python虚拟环境,安装requirements.txt依赖。
- 配置Gunicorn作为WSGI服务器,Nginx反向代理静态文件和转发请求。
- 设置HTTPS证书(宝塔免费申请)。
方案二:Docker Compose(加分项)
用Docker部署虽然前期配置多点,但能体现工程化能力。写一个docker-compose.yml,把Django应用、MySQL、Redis(缓存)拆成三个服务,一条命令全部启动。这块在论文的“系统部署”章节能写出一大段亮点。
提示:部署时最容易出错的是静态文件配置。Django的DEBUG模式和生产模式对静态文件的处理逻辑不一样,记得用collectstatic命令收集静态文件,并在Nginx中配置static目录的alias。
6.2 性能优化关键点
数据库优化:销量数据模型要给日期的字段加索引,推荐车型表的品牌、价格区间字段也加索引。数据量不大时不太明显,一旦有几万条记录,加了索引之后查询速度快一个数量级。
API响应优化:DeepSeek API调用是网络IO,耗时在几百毫秒到几秒不等。前端需要做异步处理,不能让用户页面一直转圈。推荐做法是用Django的Celery做异步任务队列,或者至少用Ajax轮询的方式,先返回“正在分析”,分析完成后推送结果。
数据缓存:热搜车型榜、品牌销量榜这些基本不变化的数据,可以直接缓存到Redis或者Django默认的LocMemCache,减少数据库查询次数。
7. 常见问题与排查技巧实录
7.1 问题速查表
这块儿把我自己和学生做项目时遇到过的典型问题整理成一张速查表:
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| DeepSeek API调用超时 | 网络不稳定或请求体过大 | 开启超时重试机制,减少Prompt中的冗余数据 |
| Prophet预测结果全是趋势线 | 数据量太少(少于24个月) | 补充更多历史数据,或切换到月度粒度预测 |
| Django页面加载极慢 | 每次请求都重新训练预测模型 | 增加缓存机制,模型训练结果缓存1小时以上 |
| 中文乱码 | 数据库连接未设置utf8mb4 | 在settings.py中设置数据库OPTIONS为utf8mb4 |
| ECharts图形不显示 | 高度未设置或数据格式不对 | 检查容器div是否有固定高度,检查JSON字段名是否匹配 |
| 推荐结果明显不合理 | 特征文本构造不合理 | 检查价格区间划分粒度,细化车型属性文本 |
| 部署后静态文件404 | Nginx未正确配置静态目录 | 执行collectstatic并配置alias路径 |
| LSTM训练损失不下降 | 数据未归一化或学习率过大 | 使用MinMaxScaler归一化,降低学习率至0.001以下 |
7.2 答辩之前一定要准备好的问题
这个项目涉及的技术点多,答辩时被追问的概率也大。根据经验,以下问题必须在答辩前练成“脱口而出”:
-
为什么销量预测不用深度学习,而用Prophet?
答:深度学习模型(LSTM)需要大量数据才能训练出稳定效果,而公开数据量有限,Prophet在中小规模时间序列上简洁高效,且能方便地加入节假日效应。同时我在系统中保留了大模型辅助分析能力,弥补了单一模型的局限性。 -
大模型在这个系统里到底起到了什么不可替代的作用?
答:传统模型只能输出数值预测,无法解释“为什么”。DeepSeek能够基于数据和上下文生成分析报告、推荐理由,让系统的输出从“冷冰冰的数据”变成“有逻辑的决策建议”,这是传统算法做不到的。 -
推荐系统如何评估好坏?
答:毕设阶段用离线指标(精确率、召回率、覆盖率)做基础评估,再用用户问卷或后台点击数据进行反馈评估。要提前跑一遍评估脚本,把指标数字记在PPT里。 -
数据量这么小,模型结论可信吗?
答:坦诚数据量的局限性,同时说明数据量不是评价系统好坏的唯一标准,系统的价值在于“从数据到决策”的完整链路,以及技术方法的应用实践。
7.3 最后几点实用建议
做完这个项目,有几件事如果时间允许,建议一定要做:
- 写一份清晰的项目README:包含项目介绍、技术栈、目录结构、启动方式和API说明。不仅答辩老师会看,面试官也会把它当作了解你代码水平的第一入口。
- 录一段系统演示视频:把核心功能全部操作一遍并录屏保存,万一答辩现场网络出问题、API超时,你还能放视频救急。
- 做好数据备份:数据库、CSV源文件、模型训练脚本、预测结果全部传到网盘或者Git仓库,别让几个月的心血毁于硬盘故障。
写在最后的一点经验
我实际带过不少毕设项目,新能源销量预测+推荐系统这个组合,本身已经比绝大多数“图书管理系统”“购物商城”的题目高出一个段位了。但同样的选题,不同人的完成度天差地别。差别不在谁用了更新的模型,而在谁把每个环节的细节做扎实了——数据来源可靠、特征工程有逻辑、模型选型有解释、代码结构清晰、可视化能讲出故事、大模型用得合理而不是镶边。如果你照着这篇文章的思路一步一步走下来,答辩那天你会非常有底气。最后再提醒一句:DeepSeek的API Key保管好,别提交到公开的代码仓库里,这个坑我见过太多次了。
