每年的毕业设计选题总有一批人绕不开“系统 算法 可视化”这个三角。这款题目把 Django、DeepSeek 大模型、新能源汽车销量预测、可视化大屏和推荐系统塞在一个项目里表面看是“什么都想要”实际上是一个很标准的大数据方向的完整闭环数据采集与清洗、特征工程、模型训练、后端接口、前端可视化、推荐逻辑、论文支撑材料全都能在这个题目里落地。说白了它不是让你写一个玩具 CRUD而是要求你把一条数据链路从头到尾跑通。这篇文章写给我自己也写给准备照着这个方向做毕业设计或项目练手的人。我会按真实开发顺序拆开讲为什么选 Django DeepSeek 而不是别的组合、数据怎么设计、预测和推荐到底怎么落地、可视化大屏有哪些坑、答辩时最容易被追问哪些点。我不会只给结论会尽量把每一步的“为什么”也讲清楚。1. 为什么是DjangoDeepSeek这套组合选型逻辑先说说这套技术栈的定位。Django 是 Python 生态里最成熟的全栈 Web 框架之一ORM、Admin 后台、认证、缓存、中间件这些开箱即用对毕业生来说最友好的点在于“少写很多基础设施代码”。DeepSeek 在这里承担的是大模型能力不是普通规则引擎能替代的文本理解、意图识别、自然语言查询解释这类工作。新能源汽车销量预测是业务内核可视化把结果变成能看懂的东西推荐系统则让项目从“分析型系统”变成“分析 决策辅助型系统”。这套组合不是拍脑袋拼出来的它解决了毕业设计里最现实的三件事第一Django 能快速出一个可演示的 Web 系统第二DeepSeek 提供了明显的技术亮点和传统 Java Web 项目拉开差距第三大数据方向的评分点往往集中在对数据处理和模型评估的环节而 Python Django 天生离数据处理最近。换成 Flask 或 SpringBoot 也不是不行但后面接 pandas、scikit-learn、statsmodels 的时候Django 的 ORM 和 Python 生态协同起来最顺。1.1 大模型能力如何落到销量预测场景很多人一看“DeepSeek 大模型新能源汽车销量预测”就觉得是大模型直接输出销量数字这个理解需要纠正。真正合理的做法是分层数值预测交给统计模型跟树模型DeepSeek 负责三类事情——一是解析用户的自然语言查询比如用户在大屏上输入“2024 年下半年哪个价格区间的纯电车型销量增长最快”系统把这句话转成结构化筛选条件和图表类型二是生成预测报告和异常归因比如模型检测到某月销量异常下跌DeepSeek 根据配件舆情、竞品上市时间、政策变化等文本信息给出解释三是辅助数据清洗把“比亚迪 秦PLUS DM-i 2024 款”和“秦PLUS DM-i 新款”这类名称差异统一到同一车型主体。把大模型放在这个位置是因为销量预测本质上是时序问题一个大模型拿不到足够细粒度的市场数据硬让它回归预测效果不稳定还不好解释。倒不如让它做它擅长的事理解资料、生成解释、构造查询。这样在论文里也能说清楚边界——哪部分是统计模型在算哪部分是大模型在增强。评委最反感的就是“黑盒跑了个结果”这种描述你把职责边界列出来专业感立刻不一样。1.2 推荐系统在新能源车场景里的定位推荐系统在这个项目里不是硬凑的它的存在有业务逻辑一个只做销量预测的系统用户看完大屏就结束了但加上推荐功能系统就能基于用户输入的预算、续航偏好、能源类型、品牌偏好返回一批“可能适合你的车型”。这在毕业设计中是一个很好的差异化功能点也让整个系统从“事后分析”延伸到“事前推荐”。实际落地时我建议用两类方法做结合基于车辆参数的相似度推荐物品协同过滤的变体和基于规则的冷启动兜底。因为大部分毕业设计场景没有真实用户行为数据强行做用户协同过滤会面临数据稀疏问题所以主推“以车推车”把每个车型的续航、价格、电机功率、能源类型、销量热度编码成特征向量算余弦相似度推荐相似度最高的TopN。没有用户历史行为就用规则兜底先按价格区间筛选再按能源类型和预算范围排序保证无论什么输入都能给出一列合理推荐。推荐逻辑写清楚后既好演示也好在论文里画流程图。1.3 技术栈对比为什么不用Flask/SpringBoot选型阶段我认真对比过几个方案。Flask 更轻量适合几十行代码的小接口但在这个项目里需要大量配套数据库迁移要自己配、Admin 后台要自己写、缓存要自己接入、用户认证要自己设计。这些组合起来的工作量并不比写 Django 少。SpringBoot 在 Java 生态里很强但问题是数据处理链路主要在 Python 这边一会儿 pandas 处理数据一会儿 Java 写接口工程上割裂感很强调试也麻烦。Django 的好处是“全家桶”ORM 直接操作 MySQL/SQLiteAdmin 后台能管理车型、销量、推荐结果认证模块免费用Celery Redis 接异步任务也很顺手。我整理了一张选型对比表方便理解维度DjangoFlaskSpringBoot开发速度高自带ORM/Admin/认证中需自行整合中低配置多Python数据生态原生支持原生支持需要额外服务与DeepSeek API接入直接requests调用直接requests调用需封装HTTP客户端异步任务Celery/DRF集成成熟需自己搭成熟但偏重毕业设计观感架构完整模块清晰偏轻量偏企业级但学习成本高这个项目最终选了 Django结论很明确不是在追求最潮的技术而是在追求“在有限时间内交付一个结构完整、能跑通全链路、经得起追问的系统”。2. 数据链路设计从字段规划到特征工程销量预测看着是模型问题其实大部分时间都花在数据上。数据没设计好后面所有环节都要返工。这一节我把字段规划、特征构造和清洗经验分开讲照着做能省很多事。2.1 原始数据字段规划先用 Django ORM 设计车型表和销量表核心字段按照“时间 - 车型 - 渠道 - 指标”四大维度来拆。车型表建议这样设计id、车型名称、品牌、能源类型纯电/插混/增程/燃料电池价格区间或者裸车指导价后续自己分桶续航里程、电机最大功率、电池容量、车身级别、上市年份、改款代号所属细分市场轿车/SUV/MPV竞品车型ID列表用于推荐逻辑销量表按月度粒度来一条记录对应“某车型在某年某月的销量”核心字段包括销量数、环比增速、同比增速、省份/城市如果做地域分析、当月是否降价促销、当月是否有改款上市、当月政策补贴系数、充电桩数量增长率等。所有字段都设定好明确类型和来源避免后期文档和代码对不上。数据来源上可以走公开销量发布数据、开源数据集和自己构造合成数据的组合。毕业设计不需要把数据真实性做到行业报告级别但必须交代清楚“数据是哪儿来的处理流程是什么”。我建议至少有 2000 条销量记录覆盖近三年月度数据这样模型才有意义。如果脚本采用随机生成的合成数据要在论文里明确标注不能假装是真实爬取被评委一追问就会露馅。2.2 销量预测特征怎么构造时间序列预测的特征工程和普通分类回归不一样普通项目常做的标准化、独热编码在时序场景里只算基础操作。销量预测最有效的特征是滞后项也就是 t-1 月、t-2 月、t-3 月的销量。为什么这个特征最有用因为汽车销量是强自相关的如果上个月销量大涨这个月大概率延续趋势滞后项本身就能解释很大一部分方差。其他建议构造的特征包括滑动平均过去三个月的平均销量消除偶发波动、环比增速、同比增速、月份/季度/节假日标记、价格区间分桶、该车型所处细分市场的总销量份额、同类竞品平均销量差异值、充电桩增长率的滚动窗口均值。注意市场面上能拿到的充电桩数据可能不齐全那就退一步用“该省份销量占比”做代理变量。特征不是越多越好多出来的无用特征会加剧过拟合先用滞后项 时间成分 价格带构建一个小而稳的基线特征集再把市场类特征加进去对比效果。2.3 数据清洗的几个实际坑销量数据清洗一定是全程最耗时的部分。第一个坑是车型名称不一致同一个车型在不同月份可能会因为改款、后缀变化出现不同写法。比如“Model Y 后轮驱动版”和“Model Y 长续航版”是同一车系的两种配置做车型级分析时可以合并到车系层级做推荐相似度时又可以分开。这个口径问题要在清洗脚本里统一处理。第二个坑是缺失值。汽车销量表中的“0”不一定是真零可能是厂商未报送、停售、换代空档期等情况。处理上不能用全局均值填充最合理的做法是用同车型相邻月份插值如果连续三个月缺失就标记为“停产停售”状态而不是硬补。第三种情况是新车上市导致的销量序列突变比如 2024 年新车型的第一个月销量为 8第二个月突然 1.2 万这种序列不适合直接用滞后项要加一个“上市月数”特征来吸收新车型爬坡效应。我在项目里就遇到了这类问题把“上市月数”加进特征集后新车型的预测误差明显下降。3. DeepSeek接入与预测模型落地这章是项目技术含金量的核心。先说结论预测部分不能只靠 DeepSeek真正给出销量数字的是传统时序和机器学习模型DeepSeek 的价值在于自然语言交互和结果解释。这个定位定好了整个系统逻辑才说得通。3.1 两层预测方案时序基线 大模型增强我在项目里搭了两层方案。第一层是数值预测用 Python 的 statsmodels 和 scikit-learn 实现。推荐至少跑三个模型做对比ARIMA适合捕捉线性趋势和季节性、Prophet对节假日和缺失值容忍度好、XGBoost能融合滞后项和市场特征。第二层是 DeepSeek 增强把模型输出的预测数字喂给 DeepSeek让它生成自然语言的销量解读和风险提示。比如预测结果显示某车型下月销量可能下降 12%DeepSeek 根据资料信息生成一段归因说明“该价位段竞品集中上市叠加国补退坡短期内销量可能承压。”这样设计有一个实际好处答辩的时候评委问“DeepSeek 到底在你的系统里起了什么作用”你不能只说“我用大模型做了预测”而是能清楚地回答“时序模型负责数值预测大模型负责把数值结果转成决策可读的信息并解析用户的自然语言查询”。这句话一出来系统架构的成熟度立刻不一样。3.2 训练与评估时间序列不能随机切分模型训练里最容易犯的错误是直接用train_test_split随机切分。时间序列的样本顺序就是信息本身随机切分会把未来的信息泄漏到训练集里导致结果虚高。正确做法是按时间先后切分比如前 80% 月份做训练后 20% 月份做验证。评估指标一般用三个MAPE平均绝对百分比误差、RMSE均方根误差、MAE平均绝对误差。MAPE 最直观波动好解释。预测结果和用户解释“平均误差在 8% 以内”比给一堆 RMSE 数字更硬。除了指标一定要保存预测结果图和误差分布图到论文素材里因为很多人答辩时被问到“准确率怎么来的”展示图像比念数字更有说服力。给一段 XGBoost 特征矩阵构造的简化思路训练数据是车型维度的月销量滞后项、移动均值、价格带、上市月数、季度标记。跑完模型后算 feature_importance 保留Top10特征把特征重要性图放进论文附录这就是很好的加分素材。3.3 DeepSeek的接入细节与降级方案DeepSeek 在系统里的接入方式很直接Django 后端用普通 HTTP 请求调用 API但有几个细节必须处理。第一API Key 不能写死在前端代码或 GitHub 仓库用环境变量或 Django settings 里的配置项保存。第二请求必须设置超时时间比如 15 秒因为大模型接口在高并发时可能响应慢页面不能一直转圈。第三也是最重要的一定要做降级方案如果 API 调用失败系统要回到规则查询模式比如用关键词匹配历史销量接口而不是整个页面报错。建议在 Django 里封装一个LLMService服务类统一处理 prompt 拼装、请求发送、异常捕获、结果结构化解析。这样所有需要大模型的功能都走同一个服务改模型或换平台只需要动一个类。大模型返回内容尽量让它输出 JSON设置response_format为 JSON 模式解析前先去掉可能出现的 markdown 代码块标记再做json.loads解析失败就抛异常走降级逻辑。这套代码写下来不仅工作量大减也是一个很能写在简历上的工程经验点。4. Django后端架构与API设计后端架构这一章我按照“一个 Django 工程多个 app”的思路来拆。很多初学者喜欢把所有代码写在一个模块里项目一复杂就失控。按照业务边界拆成独立 app开发、调试、写论文都会轻松很多。4.1 项目结构划分建议这样拆分apps/sales销量数据的存储、查询、聚合统计apps/forecast销量预测模型、特征工程、预测结果apps/recommend推荐算法、相似度计算、推荐结果缓存apps/chatDeepSeek 对话、自然语言查询解析、报告生成apps/users用户登录、权限控制、JWT 认证utils公共工具库包括 Redis 客户端、模型加载、外部 API 封装如果你用 Django Rest Framework接口层会非常清晰。每个 app 里写 serializer、viewset、urls前端只需要请求 JSON 接口不用碰模板渲染前后端分离的架构也更接近真实项目。Django Admin 后台可以注册车型和销量模型直接在里面修改数据省掉写管理页面的时间。4.2 核心API设计整个系统最少要有四组接口。第一组是销售概览接口/api/sales/summary返回总销量、同比、环比、月度趋势、品牌销量占比专供可视化大屏首屏。第二组是预测接口/api/forecast/result参数是车型ID和预测月份数返回未来几个月的预测销量和置信区间。第三组是推荐接口/api/recommend/cars参数是用户偏好预算、能源类型、空间需求返回车型列表、相似度得分和推荐理由。第四组是对话接口/api/chat/query接收用户自然语言调用 DeepSeek 解析意图返回数据和图表配置。每组接口都要做好参数校验和错误码设计。比如/api/forecast/result的车型ID不存在时返回 404 加错误信息而不是让前端拿一个空对象去硬渲染。这个习惯很重要大屏系统对接口稳定性要求高一个接口返回异常整块图表可能就白屏了。写单元测试时至少覆盖“正常参数、非法参数、空数据”三种情况放在论文附录里也是加分项。4.3 缓存、异步任务与性能兜底销量预测的模型推理时间通常在几百毫秒到几秒之间用户点一次按钮就实时训练不现实。我的做法是训练任务放到 Celery 异步队列里执行Redis 做消息 broker 和结果缓存。用户在页面上提交预测请求后接口立刻返回“任务已提交”前端轮询任务状态模型跑完后从 Redis 读取预测结果并渲染图表。为什么这个设计值得写因为答辩时评委很可能会问“如果预测接口响应很慢怎么办”。你把“异步任务 缓存”这套机制讲明白就证明你不只是在写 demo而是真的考虑了生产环境里会遇到的问题。另一个容易被忽略的点是大屏首次加载的接口数据量。销售明细表如果几千条全量返回前端渲染会卡顿。接口层要做时间范围过滤和聚合比如只返回最近 12 个月的趋势数据省份地图那部分按省份聚合后再返回数量级小很多前端也流畅。5. 可视化大屏与推荐功能实现可视化在内行人眼里可能是最简单的一块但它真的决定了演示效果。一个干净、信息层次清楚的大屏比一堆高大上的算法更容易让老师产生好感。推荐功能则决定了系统能不能形成“数据 → 分析 → 决策”的完整故事。5.1 大屏图表选型与布局可视化组件我建议用 ECharts免费、文档全、社区案例多对大屏自适应支持也好。别用一个组件库硬撑我见过有的人用 ECharts 改地图改了两天都没解决省名匹配问题其实换成已有的地图数据并做一次名称映射就好了。大屏布局我通常这样规划上半部分是核心 KPI 卡片区展示总销量、本月预测销量、同比增长、环比增长四个数字中间主体左侧是月度销量趋势折线图右侧是品牌销量占比横向条形图中间放一个销量地图热力图下半部分放车型销量排行榜和价格区间分布。这套布局信息密度高但又不至于挤到看不清字。最关键的一点每个图表都要有一个“空数据”状态后端返回空数组时直接显示“暂无数据”不能白屏或报错。5.2 推荐模块从相似度计算到规则兜底推荐系统我用的是以车推车的主逻辑。每个车型建模成特征向量向量维度包括价格、续航、电机功率、能源类型、车身级别、销量热度其中销量热度可以直接用过去 12 个月的平均销量去 log 缩放避免热门车型数值过大影响距离计算。然后用余弦相似度计算车型间相似度这样即使两个车型不属同一品牌只要用户偏好维度相似也能被推荐出来。推荐结果的排序建议用加权分数相似度占 70%销量热度占 30%。这样保证“相似且受欢迎”的车排在前面而不是推一款没人买的冷门车。同时必须做规则兜底如果用户输入的预算为空或偏好条件过于严格导致结果为空就回退到“同价位热门销量排行榜”保证用户永远能看到推荐结果。推荐理由也别只给车型名给一句“价格相近、续航比目标车型多 80km”这类结构化文本演示效果会好很多。5.3 大屏交互细节很多大屏项目做出来像一张静态壁纸问题在于缺少交互逻辑。我建议至少做三个交互一是趋势图点击某个时间点联动更新其他图表的范围二是地图省份点击后下钻到城市销量明细再点击空白区域回退三是预测结果的展示不要和实际销量裂成两张图用同一条折线把历史段和预测段拼接起来在预测段用虚线或不同颜色区分这样评委一眼就能看懂预测效果。还有一个小细节大屏页面要设置定时刷新比如每 60 秒轮询一次核心接口。这样即使数据在后端被手动更新了大屏也能自动拿到新数据。轮询的代码几行就够但对演示效果提升很直接。6. 项目里的踩坑记录与答辩准备最后这部分是整篇总结里我最想写的因为这些问题我基本都遇到过。把坑提前写出来后面做的人能少走一圈弯路。6.1 时间序列泄漏是最容易翻车的地方如果你想在答辩现场被问到“你的预测准确率怎么这么高”那多半是数据泄漏了。最常见的情况是用 StandardScaler 在全部数据上做标准化再切分训练测试集。虽然销量预测里标准化不像分类那么敏感但凡是涉及滑动特征和滞后项都要先切分再构造特征窗口否则测试集信息会通过特征间接进入训练过程。正确的做法是先把数据按时间切好在训练集上构造滞后特征再对测试集做同样的特征变换。这两行代码的区别论文里和现场演示时都能看出差距。6.2 DeepSeek返回格式不稳定怎么办大模型接口返回的内容再强调一遍不要直接json.loads。我实际调用时返回结果里经常出现 markdown 代码块标记、开头有多余空格、偶尔 JSON 末尾多一个逗号。我用的解析方式是先剥离代码块再定位第一个{和最后一个}截取中间内容后尝试解析解析失败就记录原始返回文本到日志并返回降级规则结果。同时在 prompt 里面明确写“务必返回合法 JSON不要包含额外解释”能极大提高成功率。这个经验不是文档里教你的是实际跑接口时踩出来的。6.3 论文和答辩的核心准备方向毕业设计最终还要落到论文和陈述上。论文的逻辑线建议是“数据采集与清洗 → 特征工程 → 销量预测模型构建 → 推荐系统设计 → 系统实现 → 结果分析”。不要把 DeepSeek 吹成万能模型而是把它定位成“大模型增强的交互层”。答辩高频问题大概有三个方向第一预测模型为什么选这几个不选神经网络第二推荐结果怎么评价有没有评指标第三DeepSeek 在项目里到底承担什么角色。准备回答第一题的时候可以对比一下 LSTM 或 Transformer 类模型承认它们理论上能捕捉更复杂时序依赖但需要的数据量和调参成本在这个项目里不划算XGBoost 和 Prophet 在小样本时序上更容易得到稳定结果。第二题推荐评估如果有真实用户购买数据可以算 precisionK 和 recallK没有就用相似度平均分和用户点击反馈做定性分析。第三题直接说明职责边界重点突出整套系统是可解释、可降级的而不是把大模型当黑盒。我个人做下来的最大体会是大模型项目最容易出问题的不是模型本身而是数据链路和系统边界。先把 Django 整条业务链路跑通再把 DeepSeek 作为一个能力节点接入一步步验证每一步的输出是否合理最后做的可视化大屏和推荐才不会变成空中楼阁。这类的选题看起来点很多但只要拆成“数据、模型、接口、界面”四层去推进每周都能有明确产出压力会小很多。如果现在让我重新做一次我会把更多时间花在特征工程的对比实验上因为最后论文里最扎实的章节往往就是“特征怎么构造、实验怎么对比、误差怎么分析”这三块。模型代码网上都有但数据理解和业务转化的过程才是真正属于你自己的工作量。 Django+DeepSeek实战：新能源汽车销量预测与推荐系统设计
每年的毕业设计选题总有一批人绕不开“系统 算法 可视化”这个三角。这款题目把 Django、DeepSeek 大模型、新能源汽车销量预测、可视化大屏和推荐系统塞在一个项目里表面看是“什么都想要”实际上是一个很标准的大数据方向的完整闭环数据采集与清洗、特征工程、模型训练、后端接口、前端可视化、推荐逻辑、论文支撑材料全都能在这个题目里落地。说白了它不是让你写一个玩具 CRUD而是要求你把一条数据链路从头到尾跑通。这篇文章写给我自己也写给准备照着这个方向做毕业设计或项目练手的人。我会按真实开发顺序拆开讲为什么选 Django DeepSeek 而不是别的组合、数据怎么设计、预测和推荐到底怎么落地、可视化大屏有哪些坑、答辩时最容易被追问哪些点。我不会只给结论会尽量把每一步的“为什么”也讲清楚。1. 为什么是DjangoDeepSeek这套组合选型逻辑先说说这套技术栈的定位。Django 是 Python 生态里最成熟的全栈 Web 框架之一ORM、Admin 后台、认证、缓存、中间件这些开箱即用对毕业生来说最友好的点在于“少写很多基础设施代码”。DeepSeek 在这里承担的是大模型能力不是普通规则引擎能替代的文本理解、意图识别、自然语言查询解释这类工作。新能源汽车销量预测是业务内核可视化把结果变成能看懂的东西推荐系统则让项目从“分析型系统”变成“分析 决策辅助型系统”。这套组合不是拍脑袋拼出来的它解决了毕业设计里最现实的三件事第一Django 能快速出一个可演示的 Web 系统第二DeepSeek 提供了明显的技术亮点和传统 Java Web 项目拉开差距第三大数据方向的评分点往往集中在对数据处理和模型评估的环节而 Python Django 天生离数据处理最近。换成 Flask 或 SpringBoot 也不是不行但后面接 pandas、scikit-learn、statsmodels 的时候Django 的 ORM 和 Python 生态协同起来最顺。1.1 大模型能力如何落到销量预测场景很多人一看“DeepSeek 大模型新能源汽车销量预测”就觉得是大模型直接输出销量数字这个理解需要纠正。真正合理的做法是分层数值预测交给统计模型跟树模型DeepSeek 负责三类事情——一是解析用户的自然语言查询比如用户在大屏上输入“2024 年下半年哪个价格区间的纯电车型销量增长最快”系统把这句话转成结构化筛选条件和图表类型二是生成预测报告和异常归因比如模型检测到某月销量异常下跌DeepSeek 根据配件舆情、竞品上市时间、政策变化等文本信息给出解释三是辅助数据清洗把“比亚迪 秦PLUS DM-i 2024 款”和“秦PLUS DM-i 新款”这类名称差异统一到同一车型主体。把大模型放在这个位置是因为销量预测本质上是时序问题一个大模型拿不到足够细粒度的市场数据硬让它回归预测效果不稳定还不好解释。倒不如让它做它擅长的事理解资料、生成解释、构造查询。这样在论文里也能说清楚边界——哪部分是统计模型在算哪部分是大模型在增强。评委最反感的就是“黑盒跑了个结果”这种描述你把职责边界列出来专业感立刻不一样。1.2 推荐系统在新能源车场景里的定位推荐系统在这个项目里不是硬凑的它的存在有业务逻辑一个只做销量预测的系统用户看完大屏就结束了但加上推荐功能系统就能基于用户输入的预算、续航偏好、能源类型、品牌偏好返回一批“可能适合你的车型”。这在毕业设计中是一个很好的差异化功能点也让整个系统从“事后分析”延伸到“事前推荐”。实际落地时我建议用两类方法做结合基于车辆参数的相似度推荐物品协同过滤的变体和基于规则的冷启动兜底。因为大部分毕业设计场景没有真实用户行为数据强行做用户协同过滤会面临数据稀疏问题所以主推“以车推车”把每个车型的续航、价格、电机功率、能源类型、销量热度编码成特征向量算余弦相似度推荐相似度最高的TopN。没有用户历史行为就用规则兜底先按价格区间筛选再按能源类型和预算范围排序保证无论什么输入都能给出一列合理推荐。推荐逻辑写清楚后既好演示也好在论文里画流程图。1.3 技术栈对比为什么不用Flask/SpringBoot选型阶段我认真对比过几个方案。Flask 更轻量适合几十行代码的小接口但在这个项目里需要大量配套数据库迁移要自己配、Admin 后台要自己写、缓存要自己接入、用户认证要自己设计。这些组合起来的工作量并不比写 Django 少。SpringBoot 在 Java 生态里很强但问题是数据处理链路主要在 Python 这边一会儿 pandas 处理数据一会儿 Java 写接口工程上割裂感很强调试也麻烦。Django 的好处是“全家桶”ORM 直接操作 MySQL/SQLiteAdmin 后台能管理车型、销量、推荐结果认证模块免费用Celery Redis 接异步任务也很顺手。我整理了一张选型对比表方便理解维度DjangoFlaskSpringBoot开发速度高自带ORM/Admin/认证中需自行整合中低配置多Python数据生态原生支持原生支持需要额外服务与DeepSeek API接入直接requests调用直接requests调用需封装HTTP客户端异步任务Celery/DRF集成成熟需自己搭成熟但偏重毕业设计观感架构完整模块清晰偏轻量偏企业级但学习成本高这个项目最终选了 Django结论很明确不是在追求最潮的技术而是在追求“在有限时间内交付一个结构完整、能跑通全链路、经得起追问的系统”。2. 数据链路设计从字段规划到特征工程销量预测看着是模型问题其实大部分时间都花在数据上。数据没设计好后面所有环节都要返工。这一节我把字段规划、特征构造和清洗经验分开讲照着做能省很多事。2.1 原始数据字段规划先用 Django ORM 设计车型表和销量表核心字段按照“时间 - 车型 - 渠道 - 指标”四大维度来拆。车型表建议这样设计id、车型名称、品牌、能源类型纯电/插混/增程/燃料电池价格区间或者裸车指导价后续自己分桶续航里程、电机最大功率、电池容量、车身级别、上市年份、改款代号所属细分市场轿车/SUV/MPV竞品车型ID列表用于推荐逻辑销量表按月度粒度来一条记录对应“某车型在某年某月的销量”核心字段包括销量数、环比增速、同比增速、省份/城市如果做地域分析、当月是否降价促销、当月是否有改款上市、当月政策补贴系数、充电桩数量增长率等。所有字段都设定好明确类型和来源避免后期文档和代码对不上。数据来源上可以走公开销量发布数据、开源数据集和自己构造合成数据的组合。毕业设计不需要把数据真实性做到行业报告级别但必须交代清楚“数据是哪儿来的处理流程是什么”。我建议至少有 2000 条销量记录覆盖近三年月度数据这样模型才有意义。如果脚本采用随机生成的合成数据要在论文里明确标注不能假装是真实爬取被评委一追问就会露馅。2.2 销量预测特征怎么构造时间序列预测的特征工程和普通分类回归不一样普通项目常做的标准化、独热编码在时序场景里只算基础操作。销量预测最有效的特征是滞后项也就是 t-1 月、t-2 月、t-3 月的销量。为什么这个特征最有用因为汽车销量是强自相关的如果上个月销量大涨这个月大概率延续趋势滞后项本身就能解释很大一部分方差。其他建议构造的特征包括滑动平均过去三个月的平均销量消除偶发波动、环比增速、同比增速、月份/季度/节假日标记、价格区间分桶、该车型所处细分市场的总销量份额、同类竞品平均销量差异值、充电桩增长率的滚动窗口均值。注意市场面上能拿到的充电桩数据可能不齐全那就退一步用“该省份销量占比”做代理变量。特征不是越多越好多出来的无用特征会加剧过拟合先用滞后项 时间成分 价格带构建一个小而稳的基线特征集再把市场类特征加进去对比效果。2.3 数据清洗的几个实际坑销量数据清洗一定是全程最耗时的部分。第一个坑是车型名称不一致同一个车型在不同月份可能会因为改款、后缀变化出现不同写法。比如“Model Y 后轮驱动版”和“Model Y 长续航版”是同一车系的两种配置做车型级分析时可以合并到车系层级做推荐相似度时又可以分开。这个口径问题要在清洗脚本里统一处理。第二个坑是缺失值。汽车销量表中的“0”不一定是真零可能是厂商未报送、停售、换代空档期等情况。处理上不能用全局均值填充最合理的做法是用同车型相邻月份插值如果连续三个月缺失就标记为“停产停售”状态而不是硬补。第三种情况是新车上市导致的销量序列突变比如 2024 年新车型的第一个月销量为 8第二个月突然 1.2 万这种序列不适合直接用滞后项要加一个“上市月数”特征来吸收新车型爬坡效应。我在项目里就遇到了这类问题把“上市月数”加进特征集后新车型的预测误差明显下降。3. DeepSeek接入与预测模型落地这章是项目技术含金量的核心。先说结论预测部分不能只靠 DeepSeek真正给出销量数字的是传统时序和机器学习模型DeepSeek 的价值在于自然语言交互和结果解释。这个定位定好了整个系统逻辑才说得通。3.1 两层预测方案时序基线 大模型增强我在项目里搭了两层方案。第一层是数值预测用 Python 的 statsmodels 和 scikit-learn 实现。推荐至少跑三个模型做对比ARIMA适合捕捉线性趋势和季节性、Prophet对节假日和缺失值容忍度好、XGBoost能融合滞后项和市场特征。第二层是 DeepSeek 增强把模型输出的预测数字喂给 DeepSeek让它生成自然语言的销量解读和风险提示。比如预测结果显示某车型下月销量可能下降 12%DeepSeek 根据资料信息生成一段归因说明“该价位段竞品集中上市叠加国补退坡短期内销量可能承压。”这样设计有一个实际好处答辩的时候评委问“DeepSeek 到底在你的系统里起了什么作用”你不能只说“我用大模型做了预测”而是能清楚地回答“时序模型负责数值预测大模型负责把数值结果转成决策可读的信息并解析用户的自然语言查询”。这句话一出来系统架构的成熟度立刻不一样。3.2 训练与评估时间序列不能随机切分模型训练里最容易犯的错误是直接用train_test_split随机切分。时间序列的样本顺序就是信息本身随机切分会把未来的信息泄漏到训练集里导致结果虚高。正确做法是按时间先后切分比如前 80% 月份做训练后 20% 月份做验证。评估指标一般用三个MAPE平均绝对百分比误差、RMSE均方根误差、MAE平均绝对误差。MAPE 最直观波动好解释。预测结果和用户解释“平均误差在 8% 以内”比给一堆 RMSE 数字更硬。除了指标一定要保存预测结果图和误差分布图到论文素材里因为很多人答辩时被问到“准确率怎么来的”展示图像比念数字更有说服力。给一段 XGBoost 特征矩阵构造的简化思路训练数据是车型维度的月销量滞后项、移动均值、价格带、上市月数、季度标记。跑完模型后算 feature_importance 保留Top10特征把特征重要性图放进论文附录这就是很好的加分素材。3.3 DeepSeek的接入细节与降级方案DeepSeek 在系统里的接入方式很直接Django 后端用普通 HTTP 请求调用 API但有几个细节必须处理。第一API Key 不能写死在前端代码或 GitHub 仓库用环境变量或 Django settings 里的配置项保存。第二请求必须设置超时时间比如 15 秒因为大模型接口在高并发时可能响应慢页面不能一直转圈。第三也是最重要的一定要做降级方案如果 API 调用失败系统要回到规则查询模式比如用关键词匹配历史销量接口而不是整个页面报错。建议在 Django 里封装一个LLMService服务类统一处理 prompt 拼装、请求发送、异常捕获、结果结构化解析。这样所有需要大模型的功能都走同一个服务改模型或换平台只需要动一个类。大模型返回内容尽量让它输出 JSON设置response_format为 JSON 模式解析前先去掉可能出现的 markdown 代码块标记再做json.loads解析失败就抛异常走降级逻辑。这套代码写下来不仅工作量大减也是一个很能写在简历上的工程经验点。4. Django后端架构与API设计后端架构这一章我按照“一个 Django 工程多个 app”的思路来拆。很多初学者喜欢把所有代码写在一个模块里项目一复杂就失控。按照业务边界拆成独立 app开发、调试、写论文都会轻松很多。4.1 项目结构划分建议这样拆分apps/sales销量数据的存储、查询、聚合统计apps/forecast销量预测模型、特征工程、预测结果apps/recommend推荐算法、相似度计算、推荐结果缓存apps/chatDeepSeek 对话、自然语言查询解析、报告生成apps/users用户登录、权限控制、JWT 认证utils公共工具库包括 Redis 客户端、模型加载、外部 API 封装如果你用 Django Rest Framework接口层会非常清晰。每个 app 里写 serializer、viewset、urls前端只需要请求 JSON 接口不用碰模板渲染前后端分离的架构也更接近真实项目。Django Admin 后台可以注册车型和销量模型直接在里面修改数据省掉写管理页面的时间。4.2 核心API设计整个系统最少要有四组接口。第一组是销售概览接口/api/sales/summary返回总销量、同比、环比、月度趋势、品牌销量占比专供可视化大屏首屏。第二组是预测接口/api/forecast/result参数是车型ID和预测月份数返回未来几个月的预测销量和置信区间。第三组是推荐接口/api/recommend/cars参数是用户偏好预算、能源类型、空间需求返回车型列表、相似度得分和推荐理由。第四组是对话接口/api/chat/query接收用户自然语言调用 DeepSeek 解析意图返回数据和图表配置。每组接口都要做好参数校验和错误码设计。比如/api/forecast/result的车型ID不存在时返回 404 加错误信息而不是让前端拿一个空对象去硬渲染。这个习惯很重要大屏系统对接口稳定性要求高一个接口返回异常整块图表可能就白屏了。写单元测试时至少覆盖“正常参数、非法参数、空数据”三种情况放在论文附录里也是加分项。4.3 缓存、异步任务与性能兜底销量预测的模型推理时间通常在几百毫秒到几秒之间用户点一次按钮就实时训练不现实。我的做法是训练任务放到 Celery 异步队列里执行Redis 做消息 broker 和结果缓存。用户在页面上提交预测请求后接口立刻返回“任务已提交”前端轮询任务状态模型跑完后从 Redis 读取预测结果并渲染图表。为什么这个设计值得写因为答辩时评委很可能会问“如果预测接口响应很慢怎么办”。你把“异步任务 缓存”这套机制讲明白就证明你不只是在写 demo而是真的考虑了生产环境里会遇到的问题。另一个容易被忽略的点是大屏首次加载的接口数据量。销售明细表如果几千条全量返回前端渲染会卡顿。接口层要做时间范围过滤和聚合比如只返回最近 12 个月的趋势数据省份地图那部分按省份聚合后再返回数量级小很多前端也流畅。5. 可视化大屏与推荐功能实现可视化在内行人眼里可能是最简单的一块但它真的决定了演示效果。一个干净、信息层次清楚的大屏比一堆高大上的算法更容易让老师产生好感。推荐功能则决定了系统能不能形成“数据 → 分析 → 决策”的完整故事。5.1 大屏图表选型与布局可视化组件我建议用 ECharts免费、文档全、社区案例多对大屏自适应支持也好。别用一个组件库硬撑我见过有的人用 ECharts 改地图改了两天都没解决省名匹配问题其实换成已有的地图数据并做一次名称映射就好了。大屏布局我通常这样规划上半部分是核心 KPI 卡片区展示总销量、本月预测销量、同比增长、环比增长四个数字中间主体左侧是月度销量趋势折线图右侧是品牌销量占比横向条形图中间放一个销量地图热力图下半部分放车型销量排行榜和价格区间分布。这套布局信息密度高但又不至于挤到看不清字。最关键的一点每个图表都要有一个“空数据”状态后端返回空数组时直接显示“暂无数据”不能白屏或报错。5.2 推荐模块从相似度计算到规则兜底推荐系统我用的是以车推车的主逻辑。每个车型建模成特征向量向量维度包括价格、续航、电机功率、能源类型、车身级别、销量热度其中销量热度可以直接用过去 12 个月的平均销量去 log 缩放避免热门车型数值过大影响距离计算。然后用余弦相似度计算车型间相似度这样即使两个车型不属同一品牌只要用户偏好维度相似也能被推荐出来。推荐结果的排序建议用加权分数相似度占 70%销量热度占 30%。这样保证“相似且受欢迎”的车排在前面而不是推一款没人买的冷门车。同时必须做规则兜底如果用户输入的预算为空或偏好条件过于严格导致结果为空就回退到“同价位热门销量排行榜”保证用户永远能看到推荐结果。推荐理由也别只给车型名给一句“价格相近、续航比目标车型多 80km”这类结构化文本演示效果会好很多。5.3 大屏交互细节很多大屏项目做出来像一张静态壁纸问题在于缺少交互逻辑。我建议至少做三个交互一是趋势图点击某个时间点联动更新其他图表的范围二是地图省份点击后下钻到城市销量明细再点击空白区域回退三是预测结果的展示不要和实际销量裂成两张图用同一条折线把历史段和预测段拼接起来在预测段用虚线或不同颜色区分这样评委一眼就能看懂预测效果。还有一个小细节大屏页面要设置定时刷新比如每 60 秒轮询一次核心接口。这样即使数据在后端被手动更新了大屏也能自动拿到新数据。轮询的代码几行就够但对演示效果提升很直接。6. 项目里的踩坑记录与答辩准备最后这部分是整篇总结里我最想写的因为这些问题我基本都遇到过。把坑提前写出来后面做的人能少走一圈弯路。6.1 时间序列泄漏是最容易翻车的地方如果你想在答辩现场被问到“你的预测准确率怎么这么高”那多半是数据泄漏了。最常见的情况是用 StandardScaler 在全部数据上做标准化再切分训练测试集。虽然销量预测里标准化不像分类那么敏感但凡是涉及滑动特征和滞后项都要先切分再构造特征窗口否则测试集信息会通过特征间接进入训练过程。正确的做法是先把数据按时间切好在训练集上构造滞后特征再对测试集做同样的特征变换。这两行代码的区别论文里和现场演示时都能看出差距。6.2 DeepSeek返回格式不稳定怎么办大模型接口返回的内容再强调一遍不要直接json.loads。我实际调用时返回结果里经常出现 markdown 代码块标记、开头有多余空格、偶尔 JSON 末尾多一个逗号。我用的解析方式是先剥离代码块再定位第一个{和最后一个}截取中间内容后尝试解析解析失败就记录原始返回文本到日志并返回降级规则结果。同时在 prompt 里面明确写“务必返回合法 JSON不要包含额外解释”能极大提高成功率。这个经验不是文档里教你的是实际跑接口时踩出来的。6.3 论文和答辩的核心准备方向毕业设计最终还要落到论文和陈述上。论文的逻辑线建议是“数据采集与清洗 → 特征工程 → 销量预测模型构建 → 推荐系统设计 → 系统实现 → 结果分析”。不要把 DeepSeek 吹成万能模型而是把它定位成“大模型增强的交互层”。答辩高频问题大概有三个方向第一预测模型为什么选这几个不选神经网络第二推荐结果怎么评价有没有评指标第三DeepSeek 在项目里到底承担什么角色。准备回答第一题的时候可以对比一下 LSTM 或 Transformer 类模型承认它们理论上能捕捉更复杂时序依赖但需要的数据量和调参成本在这个项目里不划算XGBoost 和 Prophet 在小样本时序上更容易得到稳定结果。第二题推荐评估如果有真实用户购买数据可以算 precisionK 和 recallK没有就用相似度平均分和用户点击反馈做定性分析。第三题直接说明职责边界重点突出整套系统是可解释、可降级的而不是把大模型当黑盒。我个人做下来的最大体会是大模型项目最容易出问题的不是模型本身而是数据链路和系统边界。先把 Django 整条业务链路跑通再把 DeepSeek 作为一个能力节点接入一步步验证每一步的输出是否合理最后做的可视化大屏和推荐才不会变成空中楼阁。这类的选题看起来点很多但只要拆成“数据、模型、接口、界面”四层去推进每周都能有明确产出压力会小很多。如果现在让我重新做一次我会把更多时间花在特征工程的对比实验上因为最后论文里最扎实的章节往往就是“特征怎么构造、实验怎么对比、误差怎么分析”这三块。模型代码网上都有但数据理解和业务转化的过程才是真正属于你自己的工作量。