企业官网建设流程全解析

1. 为什么电商销量预测是毕设里的"高分题目"

每年带毕业设计，我都能看到大量电商相关的选题。但说实话，真正能在一堆选题里做出辨识度、让答辩老师眼前一亮的项目并不多。核心原因在于，很多学生把电商系统做成了"增删改查"的CRUD演示——前端一个商品列表，后端几张表，加上购物车和订单，就算交差了。这种项目放在十年前还能看，放在现在的大数据背景下，很难体现出技术含量。

销量预测系统恰好是另一个极端：它足够复杂，复杂到能把数据分析、机器学习、工程化落地、可视化展示几个维度全部串起来。而这也是计算机专业毕业设计最稀缺的东西——完整性和纵深。

先说完整性。一个电商销量预测系统，从数据采集、数据清洗、特征工程、模型训练、模型评估到可视化大屏展示，整个链路是自洽的。它不是东拼西凑的几个独立模块，而是有一条清晰的数据流：原始数据经过层层加工，最终转化为业务可读的预测结果和趋势判断。这种完整的数据闭环，天然适合用来展示学生的工程能力和业务理解能力。

再说纵深。销量预测这个任务本身，从简单到复杂跨度很大。

• 最简单的是用时间序列模型（ARIMA、Prophet）做预测；
• 进阶一点是构造特征后上机器学习模型（XGBoost、LightGBM）；
• 再进一步是用深度学习模型（LSTM、Transformer）捕捉长期依赖。

也就是说，无论你当前的技术水平在哪个层次，都能找到合适的切入点。基础薄弱的可以用LightGBM做一版，追求高分的可以尝试序列模型+注意力机制。这就让一个题目能适配不同水平的学生，而不是像某些题一样，会就是会，不会就完全无从下手。

再加上可视化这个加分项。电商可视化大屏是近几年的热门方向，一个设计合理、信息层级清晰的Dashboard，在答辩现场的效果远远好过十页文字描述。老师打开你的系统，看到的是实时数据滚动、预测曲线对比、各品类销售排行，这种直观的视觉冲击比任何口头解释都有说服力。

当然，选这个题目还有一个很实际的好处——就业方向对口。电商销量预测本质上就是库存管理、需求预测、智能供应链这些业务场景的技术底座。不管以后去电商公司做数据挖掘，还是去零售行业做商业分析，这个项目的经验都直接可复用。简历上写着"基于Python的电商销量预测系统"，面试官很难不对这个项目多问几句。

所以我的结论很直接：如果你正在纠结毕业设计选题，电商销量预测系统是一个性价比极高的选择。技术栈有广度、方法有深度、展示有效果、就业有衔接，四样全占。接下来要理清楚的问题就是：这个系统到底怎么架构、模型怎么做、可视化怎么设计，以及哪些坑必须提前避开。

2. 系统整体架构与数据流转：从数据采集到可视化，一条链路打通

很多学生拿到这个题目后的第一反应是"从搭建环境开始"，这其实是个误区。比环境更重要的，是先把架构想清楚。你的数据从哪来？存到哪里？怎么加工？模型训练好之后如何对外服务？前端图表的数据从哪取？这些环节任何一个卡住，整个项目都会中断。所以我会建议学生把系统拆成四层来设计：数据源层、数据存储层、业务逻辑层、展示层。

2.1 数据源设计：公开数据集+爬虫补充，两条路都行

数据是预测系统的燃料。网上公开的电商数据集并不少，这里需要特别注意数据质量。我遇到过很多次，学生下载一个几万条的数据集欣喜若狂，结果仔细一看——时间字段不连续、商品ID大量缺失、销售额还有负数，清洗成本远比想象中高。

这里给大家一个判断标准：做销量预测的核心数据结构必须是"日期 x 维度 x 指标"。维度可以是商品、品类、店铺、区域，指标是销量、销售额、订单量等。如果你的数据集中没有明确的时间字段，或者时间粒度过粗（比如只有月份），这个数据基本不可用。

常用的数据获取路径：

• 公开数据集：Kaggle、天池、DataFountain上的电商销售数据，选那些时间跨度长、字段完整的。这种方案最省事，适合重点投入在模型和可视化上的学生。
• 爬虫抓取：针对某个具体电商平台的公开页面做数据采集，更符合"大数据获取"的毕设要求。但要注意爬虫的开发周期和合规问题，建议只抓取公开接口或静态页面，并控制请求频率。这块如果做得过重，容易挤压模型开发的时间。
• 模拟数据生成：如果找不到合适的数据源，写脚本模拟生成一份带时间趋势和周期性的销售数据，也是完全可行的。只要保证数据分布接近真实场景（有周周期、月周期、促销冲高、节假日波动），模型的训练和演示效果依旧能打。

我自己带的项目中，多数学生会选择公开数据集+模拟补充的方式，在有限时间内把精力聚焦在建模和可视化上，效果普遍更稳。

2.2 存储选型与数据加工：MySQL做业务落点，Pandas完成特征加工

存储层方面，我不太建议一上来就上Hadoop、Hive这种重组件。原因很简单：毕业设计的时间和机器资源都有限，把精力消耗在集群运维上，是在本末倒置。虽然题目里带了"大数据"标签，但"大数据思维"的核心是分布式处理思想，而不是必须搭建一个分布式集群才能证明你懂大数据。在单机上用Pandas处理几万到几十万条数据、再用数据库存储和查询，是完全够用的方案。

如果导师对大数据组件有硬性要求，做个折中：用Pandas做单机数据处理，同时写一个基于Dask或Modin的并行处理版本做对比测试，展示你对分布式计算原理的理解。这样既能从原理层面满足"大数据"要求，又不至于掉进集群环境搭建的泥潭。

存储推荐方案是：

• 原始数据和清洗后的结构化数据存MySQL或SQLite。MySQL是主流企业的标配，写进简历更硬气。
• 模型预测结果用Redis缓存，方便可视化层快速读取。不熟悉Redis的可以跳过这一步，直接从MySQL读也够用。

这里有一个需要注意的设计点：不要把原始数据、清洗后数据、特征数据混在一张表里。实际开发中，我会分开三张表——原始数据表、清洗后的基础数据表、特征宽表。每一层的变化清晰可查，排查问题时能少掉不少头发。

数据加工环节主要是两件事：

• 数据清洗。处理缺失值、异常值、重复记录，统一时间格式，规范类别字段的取值（比如"上海"和"上海市"这种同义不同值的情况）。
• 特征构造。这一步直接决定模型的天花板。时间特征（年、月、周、日、节假日）、历史统计特征（最近7天/14天/30天均值、标准差）、商品属性特征（品类、价格区间）都要在这里完成。我的经验是，这部分花费的时间绝不比模型调参少，甚至更多。

2.3 算法服务与展示层：模型落地的两种方式

模型训练完成后，需要把它封装成服务供上层调用。我见过很多学生止步于"训练出一个模型并打印评估指标"——这离系统还有很远的距离。一个完整的毕设，至少要让它跑起来，然后有一个对外接口。

两种常见方式：

• 方式一：Flask/FastAPI封装成HTTP接口。当用户在前端选择某个商品和时间范围，后端接收到请求后调用模型推理，把预测结果返回给前端展示。这种方式最贴近真实业务，也是企业里标准做法。FastAPI自带文档界面，答辩演示时很好用。
• 方式二：脚本批量预测，结果写数据库或CSV。前端图表只负责展示预测结果，不实时触发模型计算。这种方式的优点是实现简单，缺点是不灵活，只能看预先算好的内容。

个人推荐方式一。虽然工作量稍大，但"前端交互-后端接口-模型推理"的完整链路，是老师最想看到的工程能力体现。

展示层的技术选型上，有两个方向：

• 纯前端：使用ECharts + Vue或React，通过Axios调用后端接口。优点是灵活度高、视觉效果上限高。缺点是学习成本偏高，需要懂前端框架。
• Python方案：Flask/Streamlit + ECharts。Streamlit上手极快，适合Python基础不错但不太熟悉前端的学生，半天时间就能搭一个能用的仪表盘。如果想精细控制布局，直接用HTML+CSS+JS，本地渲染ECharts图表。

还有一个加分项，用PyECharts生成图表后嵌入Web页面。既省去了前端写JS的麻烦，又能通过简单的Python代码生成高质量的交互图表，是性价比最高的一条路线。

3. 数据清洗与特征工程：决定模型上限的关键环节

我在指导学生做销量预测时，最常说的一句话是：模型决定的是下限，特征决定的是上限。同样的算法，有人跑出来RMSE低得感人，有人跑出来结果惨不忍睹，差距往往不在算法本身，而在数据处理环节。这个部分做扎实了，后面的建模会非常顺畅。

3.1 清洗环节的三个常见坑与处理方案

时间字段格式不统一是最常见的问题。有的数据是"2024/1/5 10:23:45"，有的数据是"2024-01-05"，还有的是杂乱的字符串。第一步就是统一格式并提取出所有需要的时间维度。我的建议是直接用Pandas的to_datetime一步到位，然后从这个统一的datetime列中衍生出year、month、weekday、is_weekend等字段。

import pandas as pd df = pd.read_csv('sales_raw.csv') df['order_date'] = pd.to_datetime(df['order_date'], format='mixed') df['year'] = df['order_date'].dt.year df['month'] = df['order_date'].dt.month df['weekday'] = df['order_date'].dt.weekday df['is_weekend'] = df['weekday'].apply(lambda x: 1 if x >= 5 else 0)

这种代码的速度很快，即便是几十万行的数据也几乎不会感觉到延迟。

缺失值处理要分字段区别对待。销量、销售额这类核心指标如果缺失，需要谨慎填充；辅助字段缺失可以直接删除对应记录，或者用统计量填充。尤其要注意的是，不要把带有时间跨度的记录整行删除——删除之后会打断时间序列的连续性，直接影响后续特征构造和模型输入。比如"2024-01-03"这一天如果只剩几条残缺记录，删除整行会导致这一天的数据完全消失，预测时会出偏差。

异常值检测方面，电商场景最容易出现的就是大促期间的销量激增（双11、618等）。我的处理方式是：不一定把这些值当作异常值删除，而是单独构造一个"是否大促"的二值特征。这样模型既能学习到平日的规律，又能感知到大促的冲击，比简单粗暴地把大促数据删掉要合理得多。

3.2 特征工程的黄金组合：时间特征+滞回特征+滚动统计

经过多年实践，我发现销量预测模型最有效、最稳的特征组合基本固定在这三类。各自的作用如下：

• 时间特征：星期、月份、季度、节假日。销量和星期几强相关（周末通常会高于工作日，但部分品类可能相反），和节假日强相关（春节、国庆流量呈爆发式增长）。光这几个特征就能为模型贡献一大截预测精度。
• 滞回特征（Lag Features）：前1天、前7天、前14天、前30天的销量。因为销量是典型的时间序列，今天的销量和昨天的销量往往高度相关。这类特征能让模型直接"看到"历史信息。
• 滚动统计特征（Rolling Statistics）：近7天/14天/30天的均值、最大值、最小值、标准差。这些特征帮助模型捕捉趋势和波动幅度，比单一滞后值更稳定，鲁棒性更强。

特征构造的代码思路如下：

df = df.sort_values(['product_id', 'year', 'month', 'day']) # 滞后特征 df['lag_1'] = df.groupby('product_id')['sales'].shift(1) df['lag_7'] = df.groupby('product_id')['sales'].shift(7) df['lag_30'] = df.groupby('product_id')['sales'].shift(30) # 滚动统计特征 df['rolling_mean_7'] = df.groupby('product_id')['sales'].transform( lambda x: x.rolling(window=7, min_periods=1).mean()) df['rolling_std_14'] = df.groupby('product_id')['sales'].transform( lambda x: x.rolling(window=14, min_periods=1).std()) # 节假日特征 df['is_holiday'] = df['order_date'].isin(holiday_list).astype(int)

代码逻辑不难，但有两个细节必须提醒：

• groupby('product_id')是必须的。每个商品有各自的销售规律，不同商品的销量绝对数值差异很大，如果不分组就做shift和rolling，相当于把不同商品的数据混在一起算，特征完全失真。
• min_periods=1这个参数很实用。它保证数据序列开头部分的窗口内样本数不足时也不会生成NaN，保留更多可用数据用于训练。早期的序列数据预测值误差会偏大一些，但总比缺值强。

3.3 数据划分的注意事项：时间序列不能随便乱切

涉及时序预测，最容易被忽视的就是数据划分方式。普通机器学习任务随机打乱后切分训练集和测试集没问题，但时间序列数据如果用随机切分，模型会"偷看未来"，评估结果虚高，答辩时被老师一问就露馅。

正确做法是按时间顺序切分：假设数据覆盖2023年1月到2024年6月，可以用2023全年作为训练集，2024年前5个月作为验证集，最后1个月作为测试集，或者采用滚动预测式验证。这样模型评估的是"对未见过的未来时间的预测能力"，才是真实业务场景下的评估方式。

train_df = df[df['order_date'] < '2024-05-01'] valid_df = df[(df['order_date'] >= '2024-05-01') & (df['order_date'] < '2024-06-01')] test_df = df[df['order_date'] >= '2024-06-01']

这个处理方式本身就值得在论文里拿出来当创新点——多数学员项目没有这个意识，你能做出来，就体现了对业务场景的理解。

4. 销量预测模型的选型与调优：从基线到深度模型的演进路线

模型选型这块，我一般建议学生走"渐进式对比"的路线：先做基线，再做进阶，最后做深度模型。每一步都有结果，每一步都有提升，答辩的时候就是一个完整的技术演进故事，远远好过"我用XGBoost做出来了"的一句话汇报。

4.1 基线模型：线性回归与决策树

基线模型不是用来拿高分的，而是用来确立参考系的。没有基线，你说LSTM效果多好都没有依据。

线性回归作为基线的好处是，你可以在答辩时清晰解释每个特征的权重：某个商品在周末销量比工作日平均高30%，大促期间销量相比平日提升2.5倍。这些发现本身就是有价值的业务洞察，也说明你对业务有理解。

from sklearn.linear_model import LinearRegression from sklearn.metrics import mean_absolute_error, mean_squared_error model = LinearRegression() model.fit(x_train, y_train) preds = model.predict(x_test) print(f'MAE: {mean_absolute_error(y_test, preds):.2f}') print(f'RMSE: {mean_squared_error(y_test, preds, squared=False):.2f}')

决策树模型可以顺便看下它对特征重要性的判断，为后面选择特征提供依据。这两个模型跑通，基线就有了。

4.2 进阶模型：XGBoost/LightGBM成为标配

XGBoost几乎成了大数据竞赛和工业界的"万金油"模型，处理表格型数据，它的表现通常远好于线性模型和决策树。关键在于它能自动处理特征之间的非线性关系，而且对缺失值和异常值有较强的鲁棒性。

import xgboost as xgb model = xgb.XGBRegressor( n_estimators=500, max_depth=6, learning_rate=0.05, subsample=0.8, colsample_bytree=0.8, random_state=42 ) model.fit(x_train, y_train, eval_set=[(x_valid, y_valid)], verbose=False)

几个参数的解释：

• max_depth=6：控制树的复杂度。太浅学不到规律，太深过拟合严重，在几千到几万条数据上6-8是个安全的起点。
• learning_rate=0.05：学习率越小，模型越稳健，但需要更多棵树。500棵树配0.05是常规组合，效果稳定。
• subsample=0.8和colsample_bytree=0.8：每棵树随机使用80%的样本和80%的特征，增加多样性，降低过拟合风险。

如果要进一步提升，可以加上网格搜索或贝叶斯优化来调参。但要提醒一句：不要把时间全耗在调参上。与其在XGBoost上调两三百组参数，不如往前再走一步，试试深度模型——后者的"故事性"强太多了。

4.3 深度模型：LSTM建模时序依赖

LSTM的价值在于它天然适合序列数据。销量预测的历史数据本质上是按时间排列的序列，LSTM通过门控机制能记住长期依赖模式，比如季节性趋势、促销活动带来的连续效应。对比XGBoost需要手动构造滞后特征，LSTM可以自动从序列中学习这些关系。

import torch import torch.nn as nn class SalesLSTM(nn.Module): def __init__(self, input_size, hidden_size=64, num_layers=2): super().__init__() self.lstm = nn.LSTM(input_size, hidden_size, num_layers, batch_first=True) self.fc = nn.Linear(hidden_size, 1) def forward(self, x): out, _ = self.lstm(x) out = self.fc(out[:, -1, :]) return out

这里有几个在实操中容易踩的点：

• 数据必须做归一化。销量数据的量纲差异可能非常大（有的商品日均销量个位数，有的上千），不归一化的话LSTM训练极易发散或缓慢收敛。推荐用MinMaxScaler或StandardScaler，归一化后训练速度快很多。
• 滑动窗口长度决定了模型用多长的历史预测未来一天。常用的窗口大小是7、14、30，分别对应一周、两周、一个月的周期。做过实验，窗口7天和14天在销量预测中效果差距不大，30天会明显引入更多噪声，7-14天是更稳的选择。
• 批量训练时要注意序列边界。如果你随机抽取所有时间点作为训练样本，模型可能通过严重的穿越型特征（如未来的均值、未来的销量）"作弊"，导致评估结果虚高。正确的做法是严格按照时间顺序构造训练集和验证集。

下表是不同模型的对比方式，答辩时可以放在PPT里：

记住一点：不要只报一个最好模型的指标，而是要把"从基线到深度模型的完整演进过程"讲清楚。老师想听到的是你的分析和思考，不是冷冰冰的数字。

4.4 误差分析：不止看平均，还要拆到维度里

很多学生的模型报告只写一个整体的MAE、RMSE、MAPE，这远远不够。真正有说服力的做法是把误差拆分到不同维度，看看模型在什么条件下表现得差。

比如：按品类拆，是否某个品类预测误差特别大？按日期拆，是否周末和节假日的误差明显高于工作日？按销量区间拆，是否低销量商品的相对误差更高？

# 按品类查看误差 results = pd.DataFrame({'actual': y_test, 'pred': preds, 'category': x_test['category']}) results['abs_error'] = (results['actual'] - results['pred']).abs() category_error = results.groupby('category')['abs_error'].mean().sort_values(ascending=False)

这个维度的误差分析会在答辩时给老师留下深刻印象。因为它说明你不只是"跑通了一个模型"，而是真的在理解数据和业务。

5. 可视化大屏的三个层次：展示数据、暴露问题、支撑决策

可视化大屏是电商销量预测系统里最能直观呈现成果的部分。但很多同学做完图表后自己都觉得没底，原因是他们把可视化做成了"图表的堆砌"。真正好的大屏设计，必须回答三个问题：这张图回答了业务的什么问题？用户看完后会采取什么行动？设计是否层次分明、信息易读？

5.1 第一层：核心指标总览

页面顶部区域应该是整个系统的"仪表盘层"——总销售额、总订单量、客单价、预测销量。这几个数字要用大字号卡片展示，最好加上和上期对比的百分比变化，让观看者能在3秒内抓住整体经营状况。

我见过一个做得不错的案例：卡片上不仅展示数值，还带一个迷你趋势图（Sparkline），一眼就能看出这个指标最近的走势。这种设计成本很低，但视觉效果好很多，观感立刻和专业系统拉开差距。

5.2 第二层：趋势与结构分析

中间区域是系统的主战场，需要包含三类核心图表：

• 整体销量趋势图：用折线图展示实际销量和预测销量的对比。这是系统最核心的图表，预测效果的好坏一眼就能看出来。建议把实际值和预测值放在同一张图中，用不同颜色标注，并可以切换不同商品、不同品类。
• 品类销售结构：用饼图或环形图展示不同品类销量占比。要注意的是，如果品类太多，饼图会变得极其混乱，可以先按销售额排序取Top 10，剩下的合并为"其他"。
• 销量排行：使用横向条形图展示Top 10热销商品。简洁明了，信息密度高，视觉上又不会太过杂乱。

选图表时有一个通用原则：趋势看折线，占比看饼图/环图，排行看条形，分布看直方/箱线。不要为了炫技用一些花哨的图表类型，信息传达的清晰度永远是第一位的。

5.3 第三层：预测对比与业务标注

第三层是系统的精髓——把预测结果和实际值放在一起对比，并标注出关键业务事件（大促、节假日、上新等）。ECharts在这方面支持得很好，可以用markLine和markArea来做标注，在大促日期上画一条竖线或标记一个区域，直观看到大促前后销量预测和实际的吻合程度。

from pyecharts.charts import Line from pyecharts import options as opts line = ( Line() .add_xaxis(date_list) .add_yaxis("实际销量", actual_list, is_smooth=True) .add_yaxis("预测销量", pred_list, is_smooth=True, is_symbol_show=False) .set_series_opts( markline_opts=opts.MarkLineOpts( data=[opts.MarkLineItem(name="双11", x="2024-11-11")] ) ) .set_global_opts(title_opts=opts.TitleOpts(title="销量预测对比")) ) line.render("sales_forecast.html")

这种带上业务事件标注的图表，展示给老师时特别有说服力。它说明你的系统不只是"算了个数"，而是把预测结果放在真实业务场景中去理解。

5.4 可视化技术选型的建议

如果你为了快速实现，推荐PyECharts——用Python生成并渲染成HTML，嵌入网页就能用。非常适合时间紧、不想折腾前端的场景。开发和调试速度快，图表交互效果也够用。

如果你希望在展示效果上有更多层次，比如大屏文字配合背景动效、多个图表联动（点击品类，其他图表同步过滤），那就需要用到Flask/FastAPI + Vue/React + ECharts这套组合。前端的可交互能力更强，展示效果确实高一档，但学习成本和开发周期都会增加。

我给学生的一个折中方案：先用PyECharts快速出整体框架，再对核心图表单独用ECharts定制优化。这样既保证项目按时完成，又能在核心部分体现出精品度，不至于所有图表都是一个模板样式。

6. 项目实操中的高频问题与避坑清单

这一节整理的是我在带学生过程中反复遇到的问题，每个都对应一条真实的踩坑记录。如果你正在做这个项目，这份清单能帮你节省大量排查时间。

6.1 库存、退货、优惠券等数据到底要不要管

很多初学者会把项目数据模型做得异常复杂——要管库存，要管退货，还要管优惠券核销。我理解这种心理，但实话实说，毕设项目最忌讳的就是试图覆盖所有业务，结果每个业务都浅尝辄止。

做电商销量预测，最核心的动作就是"预测未来某个时间段的销量"。围绕这个目标，你需要的数据是历史销量、影响销量的特征（价格、促销、节假日、品类），以及交叉维度的运营数据。库存数据可以做拓展，作为下游"库存告警"的一个联动模块，但不要在预测主链路中引入过多表关联。退货数据的处理逻辑完全不同，做进去会让整个系统臃肿。把主链路做深、做透，远比把表面铺宽重要。

6.2 模拟数据生成时，要注意分布合理性

很多同学图省事，用random直接生成销量，结果模型训练出来的预测值完全没规律，答辩没法讲。生成模拟数据有一个原则要牢记：数据要体现周期性和趋势性。

一段相对合理的模拟数据生成逻辑应该是这样：

import numpy as np import pandas as pd np.random.seed(42) dates = pd.date_range('2023-01-01', '2024-06-30', freq='D') n = len(dates) # 基础销量：30 + 周末系数 + 整体增长趋势 + 季节性 + 随机噪声 base = 30 weekend_effect = np.where(dates.dayofweek >= 5, 15, 0) trend = np.linspace(0, 10, n) # 整体增长 seasonality = 8 * np.sin(np.arange(n) * 2 * np.pi / 365) # 年周期 noise = np.random.normal(0, 5, n) sales = base + weekend_effect + trend + seasonality + noise sales = np.maximum(0, sales).round(1)

这种有趋势、有周期、有噪声的数据，训练出来的模型才有意义，可视化才好看，答辩时也能把数据生成的逻辑讲得头头是道。

6.3 预测未来多步的问题怎么处理

很多毕设止步于"预测下一天"，但电商实际的预测需求往往是"预测未来7天或30天每天的销量"。这里有个实现技巧：递归预测（第一天预测出来，作为第二天的输入特征，再预测第三天）和直接多输出（模型结构从一开始就设计为输出未来7个值）是两种不同的策略。

• 简单场景直接做一天预测即可，系统演示效果差别不大。
• 想在论文里增加亮点的话，可以做递归多步预测，并评估误差随预测步长的累积变化。

而且这个递进过程在论文里很好写：先做单步预测验证模型能力，再做多步预测探索模型的实际应用边界。答辩时提出问题、验证问题、给出结论的路径就非常清晰了。

6.4 关于答辩加分与工程完善

毕业答辩最怕的就是"做出来了但说不清"。我经常和学生说，你要能做到用三句话把系统讲明白：数据从哪来？怎么处理？怎么用？这三句话说不清，项目多半是做得模模糊糊的。

准备答辩时，把这几块工作做扎实：

1. 画出完整的数据流图（UML或简单的架构图即可），确认自己能在5分钟内把从数据接入到页面展示的整个流程讲清楚。这个图在论文里也是必备要素。
2. 记录每一次模型迭代的效果对比。从线性回归到XGBoost再到LSTM的指标变化、关键调整点、踩过的坑，这些都是答辩现场展示你思考过程最好的素材。
3. 准备1-2个失败案例。比如某个特征加了之后效果反而变差，你如何分析原因、如何调整。讲清楚失败的实验过程，反而比只讲成功更能体现你做了深度工作。

做这个项目期间还有一个很常见的现象：环境配置问题上头，影响进度。Python版本、NumPy版本、Pandas版本之间的兼容性问题，pyecharts渲染不出来，torch装不上GPU版本，这类问题几乎每位同学都会碰到。我的建议是：固定使用一个Python虚拟环境，把所有的框架版本写进requirements.txt，在项目开始时就把环境搭建完整并做一次端到端的冒烟测试——确认数据能读、模型能跑通、页面能打开。环境问题是所有项目里性价比最高要先解决的问题，越早搞定越省时间。

最后想分享一个我的个人习惯：项目的里程碑管理对进度至关重要。最开始先跑通一个最简版本（用线性回归做单品类预测，页面展示一个折线图），再把功能一步步叠加。很多同学死在第一条主链路都没跑通的情况下，就急着在可视化上精雕细琢，结果中途发现问题要整体推翻重来。先做通、再做完善，这个顺序几乎所有项目都适用。