企业官网建设流程全解析

每年的毕业设计选题，总有一批人绕不开“系统 + 算法 + 可视化”这个三角。这款题目把 Django、DeepSeek 大模型、新能源汽车销量预测、可视化大屏和推荐系统塞在一个项目里，表面看是“什么都想要”，实际上是一个很标准的大数据方向的完整闭环：数据采集与清洗、特征工程、模型训练、后端接口、前端可视化、推荐逻辑、论文支撑材料全都能在这个题目里落地。说白了，它不是让你写一个玩具 CRUD，而是要求你把一条数据链路从头到尾跑通。

这篇文章写给我自己，也写给准备照着这个方向做毕业设计或项目练手的人。我会按真实开发顺序拆开讲：为什么选 Django + DeepSeek 而不是别的组合、数据怎么设计、预测和推荐到底怎么落地、可视化大屏有哪些坑、答辩时最容易被追问哪些点。我不会只给结论，会尽量把每一步的“为什么”也讲清楚。

1. 为什么是Django+DeepSeek这套组合：选型逻辑

先说说这套技术栈的定位。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/SQLite，Admin 后台能管理车型、销量、推荐结果，认证模块免费用，Celery + Redis 接异步任务也很顺手。

我整理了一张选型对比表，方便理解：

这个项目最终选了 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/chat：DeepSeek 对话、自然语言查询解析、报告生成
• 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 在小样本时序上更容易得到稳定结果。第二题推荐评估，如果有真实用户购买数据可以算 precision@K 和 recall@K，没有就用相似度平均分和用户点击反馈做定性分析。第三题直接说明职责边界，重点突出整套系统是可解释、可降级的，而不是把大模型当黑盒。

我个人做下来的最大体会是：大模型项目最容易出问题的不是模型本身，而是数据链路和系统边界。先把 Django 整条业务链路跑通，再把 DeepSeek 作为一个能力节点接入，一步步验证每一步的输出是否合理，最后做的可视化大屏和推荐才不会变成空中楼阁。这类的选题看起来点很多，但只要拆成“数据、模型、接口、界面”四层去推进，每周都能有明确产出，压力会小很多。

如果现在让我重新做一次，我会把更多时间花在特征工程的对比实验上，因为最后论文里最扎实的章节往往就是“特征怎么构造、实验怎么对比、误差怎么分析”这三块。模型代码网上都有，但数据理解和业务转化的过程才是真正属于你自己的工作量。