1. 系统整体架构与核心模块拆解1.1 先想清楚系统定位你做的到底是个“看板”还是“决策工具”选淘宝用户购物可视化与行为预测这个题说白了就是因为它站在一个很微妙的位置上不需要真去啃 Hadoop 全家桶又能把Django、深度学习、数据可视化这几块硬技能全部抡起来。很多同学拿到这类题目第一反应是先把界面做得花里胡哨各种图表往上堆结果答辩时老师问一句“这个展示解决了什么问题”就答不上来了。我在做这个项目时第一件事是给系统定了位它不是“数据展示系统”而是“基于用户行为的分析与决策支持系统”。这个定位决定了功能模块怎么划分。数据层存储用户行为日志、商品信息、用户信息完成数据的清洗与预处理。特征层从原始行为日志中计算用户活跃度、品类偏好、购物习惯、时段偏好等特征。模型层基于行为序列 深度学习模型构建购买行为预测模型输出用户在未来时间窗购买指定品类商品的概率。应用层Django 提供查询和预测 API前端可视化大屏做展示管理员后台做数据管理。这样做的好处是你从数据到特征、从特征到模型、从模型再到业务展示整个链路是闭环的。答辩的时候无论老师从哪个角度往下问你都能顺着链路往深处答。如果你只是做了个“图表集合”那基本就是一问一个准全都说不清楚。1.2 Django 在整个系统里到底扮演什么角色选 Django 而不是 Flask也不上 Spring Boot核心原因就三个字省时间。这个题目涉及的任务除了写接口还有大量数据清洗、聚合统计、后台管理等操作。Django 自带的 ORM、Admin 后台、数据迁移机制能让你把精力集中在“业务逻辑”和“模型训练”上而不是去造轮子搭框架。在我的实现里Django 承担了这些职责用户认证与权限管理区分管理员和普通访客管理员可以查看全量数据和大屏访客只能看脱敏后的统计结果。数据资产管理通过 Django ORM 将 MySQL 中的行为日志映射成UserBehavior、ItemInfo、UserProfile等数据模型。API 服务用 Django REST FrameworkDRF提供可视化大屏所需的 JSON 接口例如销量趋势接口、品类分布接口、用户活跃度接口、预测结果接口。模型服务挂载加载训练好的深度学习模型权重对外提供predict接口接收用户 ID 和品类 ID返回购买概率。这里有一个容易踩的坑不要把模型的训练逻辑直接写进 Django 的视图函数里。训练是离线任务推理是在线任务两者必须解耦。正确做法是写一个独立的train.py训练脚本保存模型权重到磁盘Django 启动时通过一个模型服务类加载权重在内存里做推理。这样即使模型训练要跑半小时也不会阻塞 Web 请求。1.3 数据流向一条从原始日志到预测结果的生产线我把整个数据流向归纳成一句话原始行为日志 → 清洗 → 特征工程 → 模型训练/推理 → 可视化呈现。这一条链路是整个系统的骨架也是你答辩时最好的讲解线索。拿淘宝用户购物场景举例原始数据往往是这样的一个用户在某个时间点对某个商品进行了某种操作浏览、收藏、加购、购买。这些行为混杂在一起量级可能达到几十万甚至上百万条。如果直接拿这些原始数据做展示前端图表能画出来但根本没有任何业务含义。你必须先做聚合和特征提取按天聚合得到“每天各个品类被浏览了多少次、购买了多少次”按用户聚合得到“每个用户过去 7 天活跃了多少天、购买了多少个品类”按时段聚合得到“每天 0 点到 23 点哪个时段用户最活跃”。聚合后的结果分别进入两类存储统计分析结果用于可视化大屏存到 MySQL 或 Redis 缓存中供接口快速读取。用户特征宽表用于模型训练和推理每行是一个用户的特征向量包含统计特征和行为序列特征。这个过程我用一个餐厅做类比原始日志是刚买回来的菜有泥、有烂叶你要摘洗切配清洗和特征工程配好的菜分两份一份直接做成成品菜端上桌统计聚合可视化另一份按特定分量装盘备用模型输入数据。两边并行互不干扰。2. 数据处理与用户购物特征工程2.1 没有真实淘宝数据怎么办公开数据集与模拟数据兜底很多同学一开始最焦虑的问题是“我没有淘宝的真实数据怎么做”答案是这个题目要的不是真实的淘宝数据而是符合电商行为模式的数据。有三种常见获取方式。第一公开数据集。阿里天池上有一个非常经典的淘宝用户行为数据集包含用户 ID、商品 ID、商品类目 ID、行为类型pv、fav、cart、buy和行为时间戳大概百万级规模做毕设绰绰有余。优点是有真实的行为分布缺点是需要自己去下、去解压、去清洗字段命名也比较原始。第二自己写脚本模拟。如果你拿不到公开数据完全可以用 Python 写一个行为生成器设定商品池 5000 个、用户池 20000 个按幂律分布让少量高活跃用户产生大部分行为行为类型按概率分配浏览 80%、加购 12%、收藏 5%、购买 3%。再用randomdatetime生成分布在 90 天内的行为时间点。模拟数据的优点是你能完全控制数据分布的“规律”生成的结果在可视化上看非常干净特征也容易呈现出预期模式。第三两者结合。用公开数据集做模型训练和核心图表用模拟数据做压力测试和演示补充。字段格式建议统一成下面这样字段名含义示例user_id用户唯一标识100086item_id商品唯一标识800391category_id商品所属品类4582behavior_type行为类型pv浏览/fav收藏/cart加购/buy购买buytimestamp行为发生时间2024-11-18 20:15:30拿到数据后的第一步我会先做一个数据体检统计总行数、缺失值、重复值、时间范围、用户数和商品数再把行为类型的分布画出来看一眼。这一步能帮你提前预判后面特征工程的难度。如果发现购买行为占比极低比如只有 0.5%你就要做好正负样本不平衡的准备。2.2 用 Django 批量写入和高效查询千万不要逐条 insert把清洗后的 CSV 导入数据库是第一个容易出现严重性能问题的环节。我见过不少同学直接用for row in data: Model.objects.create(**row)几十万条数据一跑就是一个通宵。正确方案是使用 Django ORM 的bulk_createfrom myapp.models import UserBehavior import csv from datetime import datetime batch [] batch_size 5000 count 0 with open(user_behavior.csv, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: batch.append(UserBehavior( user_idint(row[user_id]), item_idint(row[item_id]), category_idint(row[category_id]), behavior_typerow[behavior_type], timestampdatetime.fromisoformat(row[timestamp]), )) count 1 if count % batch_size 0: UserBehavior.objects.bulk_create(batch, batch_sizebatch_size) batch.clear() print(f已导入 {count} 条) if batch: UserBehavior.objects.bulk_create(batch, batch_sizebatch_size)bulk_create是把多条 SQL INSERT 语句合并成一次执行几十万条数据的导入时间能从小时级缩短到秒级。查询端同样有讲究。如果后面要频繁按用户 ID 和时间范围做统计必须在建表时先加好索引。用 Django 的迁移语法在UserBehavior模型的 Meta 里声明class Meta: indexes [ models.Index(fields[user_id, timestamp]), models.Index(fields[behavior_type, timestamp]), models.Index(fields[category_id, behavior_type]), ]这三个联合索引对应了三个高频查询场景按用户查时间序列、按行为类型查趋势、按品类查行为分布。没有索引的情况下百万级表上做一次带 WHERE 的 COUNT 可能要好几秒加完联合索引基本能压到百毫秒以内。2.3 特征工程从“用户干了啥”到可训练的宽表淘宝用户的购物行为可以拆成四个基础维度活跃度、品类偏好、消费能力、时间规律。特征工程就是把这四个维度量化成数字。我推荐用 Pandas 做特征计算洗成宽表后再写回 MySQL。不要指望纯用 Django ORM 算复杂特征——SQL 做简单的 GROUP BY 没问题但像行为序列切片、滑动窗口统计这类操作Pandas 的灵活性远超 SQL。举个例子给每个用户构造“近 7 天活跃特征”import pandas as pd df pd.read_csv(user_behavior_clean.csv, parse_dates[timestamp]) df[date] df[timestamp].dt.date # 近7天每个用户的行为统计 recent_7d df[df[timestamp] df[timestamp].max() - pd.Timedelta(days7)] user_active_7d recent_7d.groupby(user_id).agg( active_days(date, nunique), total_pv(behavior_type, lambda s: (s pv).sum()), total_buy(behavior_type, lambda s: (s buy).sum()), total_cart(behavior_type, lambda s: (s cart).sum()), ).reset_index()特征列表我大致分四类承上启下的统计特征近 7/30 天活跃天数、浏览/收藏/加购/购买次数、加购到购买的转化率。品类偏好特征按品类统计的行为占比、购买次数 Top3 品类、品类熵判断用户是单一偏好还是分散偏好用-sum(p*log(p))计算。时间规律特征凌晨活跃次数占比、工作日与周末行为差异、平均每次会话停留时长。行为序列特征把用户最近 50 次行为按时间排序得到行为类型序列和品类序列对应每条行为的时间间隔。最终每行用户特征类似这样user_idactive_7dbuy_30dfav_ratetop_catcat_entropynight_ratioseq_len1000865120.2345821.870.4550有了这些特征行为预测模型的输入就有了。所以这个特征宽表是整个系统里承上启下的关键产物做得好后续模型效果事半功倍做得毛糙深度学习模型接下去就是灾难。3. 可视化大屏的实现路径从 Django 接口到 ECharts3.1 可视化不是前端的事先把接口设计成“可讲故事”的结构很多人一想到可视化就埋头去写前端代码。但真正做的时候你会发现最大的坑不是图表配错而是接口设计混乱。大屏上的每一块图表背后都要有一个稳定的数据接口接口的返回结构必须经过设计。我用 DRF 定义接口时把大屏拆成了六个区块分别对应六个 API/api/trend/sales/总销售额和订单量按天趋势返回[{date: 2024-11-18, gmv: 12345, orders: 678}]。/api/category/distribution/品类购买占比返回饼图数据[{name: 数码, value: 3200}, {name: 服饰, value: 2100}]。/api/user/activity/按小时统计的用户活跃度返回折线图数据。/api/user/portrait/当前用户画像摘要用于页面顶部展示关键指标卡片。/api/predict/result/模型预测结果分布返回未来 7 天各品类的购买概率。/api/shop/top/商品热卖排行 Top10。接口除了数据本身我强烈建议额外增加一层统一响应包装{code: 0, msg: success, data: ...}。这样前端可以统一处理错误不需要每个接口各自写一套 try-catch 逻辑。后续调试和讲解都方便得多。3.2 高并发场景下的查询优化Redis 缓存与聚合策略大屏的图表数据其实具有一个很明显的特征同一份统计结果在短时间内不会变。比如“今天的销量趋势”一分钟内刷新 100 次结果也一样。所以直接从 MySQL 里反复查同一个聚合 SQL 是很浪费的。我的方案是用 Redis 做分钟级缓存。Django 里接 Redis 最省事的方式是django-redisCACHES { default: { BACKEND: django_redis.cache.RedisCache, LOCATION: redis://127.0.0.1:6379/1, OPTIONS: {CLIENT_CLASS: django_redis.client.DefaultClient}, } }视图层直接配合 Django 的cache_page装饰器给统计接口加上分钟级缓存from django.views.decorators.cache import cache_page cache_page(60 * 5) # 缓存5分钟 def sales_trend_api(request): data calculate_daily_sales() return JsonResponse({code: 0, data: data})这里有个小技巧如果数据更新不太频繁用装饰器最简单。但如果某些接口返回的数据是“用户维度”的、不同用户看到的预测结果不同就不能直接缓存整页而应该在数据计算层自己写缓存逻辑用cache.set(key, value, timeout)按 key 缓存。调试 Redis 缓存的时候建议装一个redis可视化客户端比如 Another Redis Desktop Manager 或 RedisInsight。你可以在可视化界面里直接看到哪些 key 已经被缓存、TTL 还剩多少排查“为什么页面数据一直不变”这类问题时非常好用。3.3 可视化大屏为什么选 ECharts而不是其他图表库市面上主流的图表库无非几种ECharts、Highcharts、AntV G2Plot、Hightopo 等。我在选型时考虑了三件事上手速度毕设周期有限图表库的学习成本要压到最低。ECharts 的文档和示例是最齐全的随便搜一个需求基本能找到官方示例改改就能用。视觉效果大屏评比很看“第一眼”ECharts 在大屏场景下配合暗色主题视觉效果直接拉满。商业模式和协议ECharts 是 Apache 2.0 协议完全免费没有任何商用和学校使用限制而某些图表库对大屏项目有授权要求用起来有隐患。大屏布局我建议采用“总—分—总”结构顶部一行放核心 KPI 指标卡片总用户数、总订单量、总销售额、预测准确率中间主区域放最重要的图表——每日销量趋势或品类分布左右两侧放辅助图表——用户活跃时段热力图、商品排行、转化漏斗、预测结果分布。主视觉用深色渐变背景配合发光效果答辩演示时天然加分。一个处理过的 ECharts 核心配置大概长这样const trendChart echarts.init(document.getElementById(trendChart)); trendChart.setOption({ backgroundColor: transparent, title: { text: 近30天销售趋势, left: center, textStyle: { color: #fff } }, tooltip: { trigger: axis }, xAxis: { type: category, data: dates, axisLabel: { color: #aaa } }, yAxis: { type: value, axisLabel: { color: #aaa } }, series: [ { name: 销售额, type: line, smooth: true, data: values, areaStyle: { gradient } } ] });还要注意一点大屏上的图表必须能响应窗口尺寸变化不然答辩现场用的屏幕和你开发时的不一样图表会显示不全。记得在window.addEventListener(resize, () trendChart.resize())。3.4 每张图表都要能回答一个业务问题这是我在答辩前复盘时总结出的一条“铁律”大屏上的每一块都得能回答老师可能的追问。比如“销量趋势折线图”你不仅要看涨跌还得能解释“为什么 11 月 11 日前后有一个尖峰”——因为电商平台大促日流量集中释放。“用户活跃热力图”要能说出“晚上 20 点到 23 点是用户活跃高峰高活跃时段和购买转化率的正相关关系”。“品类占比图”要能分析出这个平台的主力品类是哪一个用户在不同品类的行为差异。如果哪张图你自己都解释不清楚它跟“购物可视化与行为预测”有什么关系趁早删掉或替换。答辩场上最怕的就是一个图表摆在那里结果自己都说不出它展示了什么结论。4. 深度学习行为预测模型从入门到能答辩4.1 把预测问题定义清楚分类任务还是排序任务模型训练前先想清楚一个问题你的模型到底要输出什么我最终选定的是二分类预测用户在未来 7 天内是否会购买某个品类的商品。输出的是概率值用户测试的时候选择任意一个品类模型返回这个用户“可能购买”的概率。正负样本的构造是整个模型训练的重中之重。抽取样本时不能简单地把“购买过”和“没购买过”的用户各取一半就开训那样会导致训练集和真实场景不一致。正确做法是把用户行为数据按时间切分前 80% 的时间段用于构造特征后 20% 的时间段用于标注。如果用户在后 20% 时间内购买过目标品类则标记为 1否则标记为 0。负样本采样时基于前 80% 时间段内有行为但后 20% 时间段没有购买行为的用户抽样。这样做的核心原因在于模型学的是“从历史行为推断未来行为”的规律而不是“在标签数据里学习记忆”。切分不当你的模型精度再高答辩时老师一问数据泄漏问题就露馅了。4.2 模型的递进方案从逻辑回归到带 Embedding 的深度模型如果你直接上一套 LSTM 或 Transformer数据集又小很可能训练半天效果还不如一个逻辑回归。我的建议是分两步走。第一步用特征宽表跑一个轻量级模型逻辑回归、XGBoost、LightGBM作为基线。当基线的 AUC 到 0.75 左右后你已经验证了特征工程是有效的这时再上深度学习模型心里有底效果也可控。第二步深度学习模型不搞复杂结构而是做“用户行为序列 Embedding”的建模思路。行业内通俗叫“深度兴趣网络”或“序列行为建模”的简化版。整体架构是用户的商品行为序列最近浏览过的 N 个品类 ID经过 Embedding 层映射成向量向量序列输入一个 GRU 或 LSTM 层提取行为演化规律统计特征活跃度、偏好熵等经全连接层变换两路特征拼接进入输出层用 Sigmoid 输出购买概率。下面是一个可直接跑的 PyTorch 简化示例import torch import torch.nn as nn class BehaviorPredictionModel(nn.Module): def __init__(self, num_items, emb_size64, hidden_size32, num_stats16): super().__init__() self.embedding nn.Embedding(num_items, emb_size, padding_idx0) self.gru nn.GRU(emb_size, hidden_size, batch_firstTrue) self.fc_stats nn.Linear(num_stats, 16) self.fc_out nn.Linear(hidden_size 16, 1) def forward(self, item_seq, stats_feat): emb self.embedding(item_seq) # [B, L, E] _, hidden self.gru(emb) # [1, B, H] hidden hidden.squeeze(0) # [B, H] stats_hidden torch.relu(self.fc_stats(stats_feat)) feat torch.cat([hidden, stats_hidden], dim1) return torch.sigmoid(self.fc_out(feat))训练脚本里用BCEWithLogitsLoss做损失函数优化器建议AdamW初始学习率 3e-4batch size 看显存定一般 256 或者 512 都可以。评估指标重点看 AUC因为正负样本往往不平衡只看准确率会被带偏。4.3 模型要部署到 Django 里离线训练和在线推理必须解耦训练脚本和 Django 服务分成两个独立进程是这条链路里我认为最关键的一点。训练过程随时可能要调整参数、跑实验如果跟 Web 服务耦合在一起改一次代码要把整个服务重启非常痛苦。我的做法是train.py脚本离线读取特征宽表训练模型把state_dict保存到model/best_model.pt同时把模型使用的特征列名单、Embedding 的商品映射表保存为 JSON。Django 项目里写一个model_service.py在 APP 启动时加载模型和映射表封装predict(user_features, target_category_id)方法。视图收到预测请求后把实时计算的用户特征拼装好调用predict方法返回概率值。这里还要做一个关键的优化不要每次请求都走一遍完整深度学习推理。如果多个用户同时查同一个品类的预测概率结果没有区别。我做了结果缓存用user_id category_id做 key缓存一小时。这能极大降低模型服务在高并发演示场景下的压力。4.4 深度学习效果不稳定时的兜底策略模型不是万能的。如果演示时输入一个冷启动用户历史行为极少模型的预测结果可能会非常模糊。我为此加了两层兜底第一层规则兜底。如果用户历史行为数小于阈值直接不再用深度学习模型的概率退化为规则判断用户加购过但没买 → 高概率收藏过 → 中概率只看过 → 低概率。规则简单直白且可解释性极强。第二层模型增强。当特征不足时把序列长度补零到固定长度同时通过商品 Embedding 的相似度做冷启动补全用该商品所属品类最热门的商品序列填充缺失位置。这个方法来源于推荐系统里的“冷启动召回”答辩时提一句会显得比较懂行。5. 实操过程中最常踩的坑与排查实录5.1 Django 和深度学习框架的环境兼容性版本锁死前别动手环境问题是这类项目最容易一开始就卡住的地方。举几个我实际遇到过的真实问题Python 3.10 环境下安装老版本的 TensorFlow 会直接报找不到distutils的错误原因是 Python 3.10 之后移除了部分老 API。PyTorch 和 CUDA 版本不匹配在torch.cuda.is_available()返回False你训练脚本跑得慢还不报错。Django 4.2 DRF 3.14 的搭配相对稳但 Django 5.0 刚出来时一些第三方库还没跟进会出现不兼容警告。我的建议非常朴素先建虚拟环境把 Python 版本固定在 3.9 或 3.10再逐个安装依赖。不要用系统全局环境不要一上来就装最新版。装完依赖后跑一个最小验证确认import django、import torch、import sklearn都正常再继续往下做。最后把安装成功的依赖版本号导出来生成一份 requirements.txt。这样你在远程调试时不管换到谁的服务器一条pip install -r requirements.txt就能还原环境。5.2 数据量大了以后 Django 查询慢怎么定位和优化百万级数据量对 Hadoop 来说是小意思但对 Django 单机 MySQL 来说已经是需要认真对待的规模。常见的慢查询场景是大屏的统计接口要跨整张行为表做GROUP BY结果接口响应要三四秒刷新一次页面等半天。定位慢查询我推荐用django-debug-toolbar它能显示每个页面请求里的 SQL 和耗时一屏就能看出是哪条语句拖慢了。另外 MySQL 的慢查询日志也要开着把long_query_time设为 1。找到慢查询后的优化思路按优先级排列先看索引是否命中EXPLAIN看type是ALL还是ref索引没建就建。把QuerySet中不需要的字段用values()或only()限制返回减少内存和序列化开销。用聚合表。把大屏要展示的“每日销量”“品类分布”提前算好存入汇总表前端接口只查汇总表不再碰原始大表。这就是典型的大数据里的“预聚合”思想放毕设里非常加分。最后再上 Redis 缓存把热点查询的结果缓存几分钟。这一套组合拳下来我实测最关键的接口从 3 秒以上降到了 100 毫秒以内。5.3 答辩高频问题怎么答才不心虚我整理了一下答辩场上最容易遇到的几个问题以及对应的回答思路。问题推荐回答思路数据是从哪里来的明确说明是公开数据集或基于用户行为规律的模拟生成强调“数据是仿真的、方法是真实可落地的”。为什么选 DjangoDjango 自带 ORM、Admin、迁移适合数据密集型应用且 Python 生态能无缝对接 PyTorch不用跨语言维护两套技术栈。为什么不上 Hadoop/Spark说明技术选型取决于数据规模和时效性基于当前百万级数据和单机场景MySQL 预聚合 缓存是更经济可靠的方案但系统预留了数据分层的扩展空间。深度学习模型准确率为什么不更高分析数据稀疏性、用户行为噪声补充后续可以用更长的行为序列、更多特征、调参、样本加权等方式提升。你的预测结果有没有实际业务价值结合“加购未买用户召回”“高概率用户定向营销”等场景展开说明预测是服务于运营策略的。回答的关键是“逻辑自洽”而不是“模型最先进”。记住这一点答辩就成功了一大半。6. 部署调试、远程演示与定制扩展的完整经验6.1 远程调试的环境准备本地开发、远程 GPU、模型在中间这个项目涉及深度学习训练很多同学的笔记本跑不动大规模训练需要远程服务器。远程调试的核心不是“远程桌面连上去敲代码”而是要解决三个问题代码同步、环境一致、端口可达。我用的是 PyCharm 的远程解释器功能本地写代码自动同步到服务器在服务器上创建虚拟环境跑训练脚本。这样既享受本地的代码智能提示又用上了服务器的 GPU。如果条件简陋不用 PyCharm也可以用rsync做代码同步用 SSH 隧道做端口转发比如把远程服务器的8000端口映射到本地8000端口浏览器里直接访问localhost:8000就能看到运行在服务器上的 Django 服务。6.2 从开发到部署一台能演示的服务器就够答辩演示场景下不一定非要高可用部署。我推荐的做法是开发环境用 Django 自带的runserver先保证功能完整答辩前再部署到 Linux 服务器上用 Nginx uWSGI 做生产级部署。生产部署的步骤顺下来就是服务器上安装 Python 3.9、MySQL、Redis、Nginx。同步代码到服务器创建虚拟环境安装 requirements.txt。执行python manage.py migrate初始化数据库再导入数据。执行python manage.py collectstatic收集静态文件。用 uWSGI 启动 Django[uwsgi] http 0.0.0.0:8000 chdir /path/to/project module config.wsgi:application master true processes 2 threads 2 vacuum true uid www-data gid www-dataNginx 反向代理配置一个 server 块location /指向 uWSGI 的 8000 端口location /static直接指向collectstatic收集好的静态文件目录。这样外网只需要开 80 和 443 端口即可访问整套系统。6.3 定制扩展方向毕设做得比要求多一步的聪明办法如果你做完基准功能还有余力我建议按优先级考虑以下扩展方向第一RFM 用户分群。基于近期购买时间、购买频率、消费金额三个维度把用户分为高价值、流失预警、新用户等群组在大屏上增加用户构成图。这个扩展不复杂但对“大数据”和“业务价值”的体现立竿见影。第二协同过滤推荐模块。预测行为之后顺带推荐“该用户可能也会喜欢”的商品用简单的 ItemCF 即可。加入这个模块后系统的业务闭环就完整了分析—预测—推荐。第三更细粒度的模型升级。用 Transformer Encoder 替代 GRU 做行为序列建模在答辩时可以说“这是对自注意力机制在用户兴趣建模上的应用尝试”。规模不用大主要是体现完整的方法论。我个人在反复打磨这个题目的过程中最大的体会是这类系统设计题真正考察的不是某一个算法的精度而是你对整个数据处理和产品化链路有没有整体掌控。把数据从原始到特征、从特征到模型、从模型到可视化这条链路讲顺把每个环节的选型和利弊讲清楚就足以撑起一份漂亮的毕设。最后再分享一个小技巧演示前一定要准备一份“演示脚本”把每一步操作、每一张图表要讲的业务结论提前写成口播稿。答辩时你不会因为紧张而语无伦次每点到一个图表都能自然引出下一个模块整个演示一气呵成得分自然不一样。