“基于机器学习的日化产品销量影响因素的分析与预测”——这是我近期带过的一个毕业设计项目的完整复盘也是我建议正在选题的同学认真考虑的毕设题目。先把一句话说透这个题目表面挂的是“机器学习”和“深度学习”两个热门标签但真正做题时会发现核心难点根本不在模型有多新而在“影响因素分析”这条线上怎么证明价格、促销、季节、渠道确实影响了销量影响的量级有多大方向和强度该怎么量化这些问题在论文里不是靠一句“有关系”就能糊弄过去的。这个项目最吸引人的地方是它天然带着“分析”和“预测”两条主线的双重要求。分析线要回答“为什么涨、为什么跌”预测线要回答“未来一周能卖多少”。两条线共用一套数据集和特征工程却需要不同的方法与呈现方式。我把从数据清洗到模型调参、再到论文答辩的整体思路完整梳理一遍里面有完整的特征清单、参数配置、踩坑记录和论文写作要点。如果你正准备做数据科学方向的毕设或者想自己完整跑一个销量预测项目这篇内容可以直接拿来当路线图参考。1. 项目整体思路与技术选型1.1 一个毕业设计为什么要花大力气做“分析”很多同学拿到这个题目第一反应是“找个深度学习模型把销量预测出来就完事了”。但真正做完一轮才发现单纯的销量预测在毕业设计中其实很常见如果只堆模型不解释结果论文里的讨论部分基本写不出内容。日化品销量受多个业务变量驱动这些变量之间还有交互效应比如“打折线上渠道”的组合和“打折线下渠道”的效果往往是两回事。把这种关系拆解清楚才是题目里“影响因素分析”真正要考验的内容。所以我在设计目标时把项目明确拆成两条线一条是预测线用模型估算未来7天销量另一条是分析线用特征重要性和SHAP等工具回答“哪些因素影响大、往哪个方向影响”。两条线共用同一套特征工程和数据但评估方式完全不同。预测线看误差指标分析线看归因解释。这样的设计让论文天然形成了一条完整的叙事链条数据进来特征建好先分析原因再预测结果最后输出业务建议。现实中的日化销售数据也有这个特点数据规模不大但业务含义密集。我用的模拟数据是一家中小规模厂商的脱敏记录包含洗发水、沐浴露、洗衣液、洗手液等几个品类覆盖线上和线下两个渠道时间跨度为一年以上的日粒度数据。训练样本量在几万行到十几万行之间每个SKU都有完整的价格、促销、销量记录。这个数据量级对机器学习方法来说不算大但对毕业论文的实验设计来说刚刚好既能跑出可靠结论又不会因为数据太大导致训练时间不可控。1.2 技术栈选型为什么树模型是主线深度学习做对比这个项目的技术选型我纠结过一阵子最初也考虑过上来就用LSTM做时间序列预测。但回头审视数据后发现几万行的日粒度表格数据直接上深度学习并不是最优解。这里有几个实际考量第一是数据规模问题。几万个样本对深度学习来说太小了简单全连接网络或者单层LSTM很容易过拟合调参又费时间。而树模型在这种中小规模表格数据上是公认的强项不需要做复杂的归一化对缺失值和异常值也有一定容忍度训练一个LightGBM模型只需要几十秒。第二是解释性问题。答辩时老师一定会问“哪个因素对你预测的影响最大”树模型可以直接输出特征重要性配合SHAP库能给出每个样本的归因而这些深度学习模型很难做到。第三是项目工程量的可控性。树模型迭代快、文档多、可复现性强适合毕设这种有时间限制的场景。我最终确定的方案是主线用LightGBM和XGBoost做销量预测用SHAP做影响因素归因用LSTM做一组对比实验来体现“深度学习也试过了”的完整性。这个组合既覆盖了题目里“机器学习”和“深度学习”两个关键词又不会让项目复杂度失控。1.3 技术路线从原始数据到论文结论的全流程设计实际实现时我把整个项目流程拆成了六个环节数据采集与整理、数据清洗与预处理、特征工程、EDA和相关性分析、模型训练与对比、结果解释与可视化。这个流程看起来是流水账但每一步都有独立的输出文件后续再调整时非常方便。代码层面我坚持模块化设计避免把所有逻辑都堆在一个Notebook里。项目目录大致分为三个部分data目录放原始数据和处理后的数据src目录放各个功能模块output目录放图表和模型文件。每个模块都能独立运行比如改完特征工程后只需要重新跑模型训练模块不用从头执行数据清洗。这个习惯在项目后期帮了大忙——答辩前一周我临时调整了促销特征的构造方式只改了feature_build模块其他部分完全复用。另外还有个容易被忽视的细节配置文件单独放。数据路径、参数、随机种子这些全局变量统一放在config.py里这样所有模块引用同一个配置不会出现改了A模块的参数但B模块还在用旧值的情况。2. 数据集构建与特征工程2.1 数据字段该怎么设计一份可复用的日化销售数据字典做数据科学项目的第一步不是找模型而是把数据字典设计清楚。我用的数据集字段比较完整可以直接作为参考字段名类型说明日期date销售日期精确到天产品编码strSKU编码如PC001、PC002品类str洗发水、沐浴露、洗衣液、洗手液等销售渠道str线上商城或线下商超单价float当日实际销售均价单位元销量int当日该SKU在该渠道的销量单位件促销类型str无、满减、直降、买赠折扣力度float1减去实际成交价除以原价0表示无折扣是否节假日int0或1包含法定假期和大型电商购物节平均气温float当日平均气温单位摄氏度平均湿度float当日平均相对湿度单位百分比这些字段不是拍脑袋想出来的。日化行业的销量逻辑大致可以归到四个维度产品本身、营销动作、渠道环境、外部环境。价格和促销属于营销动作渠道维度体现线上线下完全不同的消费场景气温和湿度则作为外部辅助变量。比如沐浴露和洗发水在夏季销量明显上升护手霜和身体乳在冬季起量这些季节规律光靠日期特征也能捕捉一部分但加上气温后模型能学得更准。2.2 数据清洗实操过度清洗比不清洗更危险数据清洗环节我踩过一个印象深刻的坑。拿到原始数据后发现某些日期销量异常高比如某个SKU某天销量比平时高出十倍当时第一反应是“异常值删掉”。后来一查日历那天正好是电商大促日促销叠加渠道活动导致销量真正爆发。如果把这些值直接删掉模型就永远学不会“大促日销量激增”这个规律真实预测时反而会严重低估。正确的清洗逻辑应该是分类处理重复记录直接去重合并同一SKU同一天同一渠道的多条记录按销量求和、价格按销量加权平均真实异常值比如价格低于0或销量为负的退货记录直接剔除促销带来的销量峰值则保留原值同时新增“是否大促”特征让模型自己学习这种周期性波动。缺失值处理也需要注意日化品工作日销量相对稳定用前后7天的中位数填充比用全体均值合理得多。这里有个通用原则清洗的目的是去掉“错误数据”而不是去掉“不符合直觉的数据”。做这个项目时可以在清洗前后各保存一份数据后续对比特征重要性或在论文中说明数据预处理步骤时前后对照能让整个过程更清晰。2.3 特征工程从原始字段到模型输入的完整清单特征工程是影响最终模型效果最直接的部分。我在这个项目中构建的特征可以分为六类时间特征星期几、是否周末、月份、季度、距离上一次大促的天数、距离下一次大促的天数滞后特征前1天、前3天、前7天、前14天、前30天的销量滚动统计特征近7天销量均值、近14天销量均值、近30天销量均值、对应标准差、近7天最大值价格特征当前价格与上一周期的变动率、折扣力度外部特征平均气温、平均湿度交叉特征促销类型与渠道的组合、折扣力度与价格区间的组合滞后特征和滚动统计特征尤其重要因为销量序列本身有强烈的自相关性。上周销量低本周往往延续疲软大促当天卖爆随后几天会因为“透支”效应出现断崖式下跌。滞后特征就是把这些历史惯性告诉模型。交叉特征则能帮模型捕捉“线上满减”和“线下直降”之类的组合效应。做特征工程时有几条经验值得记住一是所有特征必须只用历史信息建模时任何涉及目标的特征都不能来自未来二是要区分“特征丰富”和“特征冗余”几十个相关性极高的特征反而容易让树模型分裂不稳定三是每加一类特征都记录一下验证集效果的变化这样论文里可以写“通过逐步添加特征验证集MAPE从X%下降到Y%”这比空谈特征工程重要得多。2.4 标签定义预测多少天、怎么划分数据才合理这个项目的预测目标定为“未来7天总销量”而不是单日销量。原因有三第一日化产品的补货周期通常以周为单位预测7天总量更贴近实际业务第二单日销量噪声很大尤其受偶发促销影响预测总量更平滑第三从模型角度看7天预测窗口比单日预测更能体现机器学习方法的优势传统统计方法在单日预测上可能都够用。数据划分是个容易被忽视但极其关键的环节。我按时间顺序切分前70%作为训练集中间10%作为验证集用于调参和早停最后20%作为测试集评估最终效果。千万不要用sklearn的train_test_split做随机划分时间序列数据的未来信息在训练集中出现会造成严重的数据泄漏这个坑我在后面专门展开讲。为了增加评估的稳健性我还补了一组滚动时间序列验证固定训练窗口每次向前滚动7天做一次预测滚动4次取平均误差。滚动验证的结果比单次划分更稳论文里同时放单次划分和滚动验证的结果会显得实验设计更扎实。3. 影响因素分析不是画出热力图就完事3.1 相关性分析和EDA先确认业务直觉拿到清洗好的数据后我首先做的是一轮完整的探索性数据分析。这步的意义不仅在“看看数据长什么样”更重要的是先验证业务直觉是否在数据中成立。我用皮尔逊相关系数看连续变量价格、气温、折扣力度与销量的关系用箱线图和分组均值看离散变量节假日、促销类型、渠道对销量的影响。一个典型发现是沐浴露品类在满减促销期间日均销量是非促销期的1.8倍而买赠活动的提升效果只有1.3倍。另一个发现是线上渠道对折扣的敏感度明显高于线下折扣力度从0.1提高到0.3时线上销量增长超过60%线下只增长约25%。这些结论本身就是写论文的好素材。但要注意相关性分析只能说明“有关系”不能说明“因果”。我在论文里把这部分定位为“初步探索”真正的归因分析最后交给了树模型的特征重要性和SHAP值。另外相关性分析时最好先做共线性检查。价格和折扣力度天然高度相关同时放进模型容易让树模型的分裂顺序不稳定进而导致特征重要性的解释产生偏差。我处理的方式是把价格特征保留原值折扣力度作为独立维度输入让模型自行学习两者各自的作用。3.2 树模型特征重要性两种算法结果可能完全不同LightGBM和XGBoost都自带特征重要性输出但不同计算方式给出的排序差异很大。LightGBM默认提供两种基于分裂次数和基于信息增益。分裂次数多不代表影响力大举一个实际例子日期类特征在分裂次数上经常排第一因为树会反复按日期切分数据但对销量的真实解释能力其实很弱。信息增益能更直接地反映“这个特征帮我减少了多少不确定性”比分裂次数更可靠。为了进一步排除偶然因素我额外计算了Permutation Importance也就是把某一列特征的值随机打乱后观察模型误差上升的幅度。误差上升越多说明该特征越重要。Permutation Importance不受分裂次数干扰在日化品数据上求出的排序更符合业务直觉折扣力度、促销类型、滞后销量排在最前面日期类特征排到了后面。这里有个实操时发现的细节原始数据用0填充缺失值后Permutation Importance会给一个“缺失指示特征”非常高的分数。这其实说明缺失模式本身和销量存在关联比如大促日某些字段容易缺失。要不要保留这种特征要看业务合理性但至少要知道这个现象存在避免误读。3.3 用SHAP做更细粒度的归因解读SHAPShapley Additive Explanations是这个项目里我认为最有价值的一个工具。它计算的是每个特征在每次预测中的边际贡献输出值可正可负。正SHAP值表示该特征把预测销量往上推负值表示往下拉绝对值越大影响越强。相比全局特征重要性SHAP能回答“在某个SKU某一天到底是什么因素导致销量异常”。日常分析里我习惯生成三张图第一张是SHAP Summary Plot散点图形式每个点是一个样本横轴是SHAP值颜色表示特征值大小。这张图可以直观看出折扣力度高红色时SHAP值多为正价格高时SHAP值多为负也就是说折扣推高销量、高价压制销量。第二张是SHAP Dependence Plot看单个特征和预测值的关系是否存在非线性比如价格与销量的关系里可能不是简单单调下降而是存在一个“价格不敏感区间”。第三张是Waterfall瀑布图针对某个具体SKU某天的预测做归因展示各个特征如何把基准预测一步步推向最终值。我建议在做毕设时把SHAP部分当成“分析线”的核心成果来写。表格可以给全局结论瀑布图可以给个案解释图文搭配的论文更有说服力。答辩时老师问到“你怎么知道某个因素影响销量”直接打开SHAP图展示归因过程比任何口头解释都管用。3.4 从模型结论到业务建议这一步决定论文的上限光给出“折扣力度重要”这样的结论论文还是显得单薄。我额外做了一步把分析结果翻译成可执行的业务建议。基于SHAP分析和特征重要性我输出了四条日化产品销量影响因素结论第一促销并非越多越好满减活动的转化效果优于买赠高频小折扣对长期销量提升有限第二价格弹性在品类间差异明显某款洗发水价格上调5%销量下降约7%而洗衣液对价格不敏感这类产品有更大的定价空间第三季节性规律前置防晒和沐浴露品类在夏季前一个月即开始起量冬季护手霜类似第四线上渠道对促销的依赖更重线下的价格敏感度更高两类渠道需要不同的运营策略。这些建议在论文里放在“讨论”章节既呼应了标题的“影响因素分析”也说明整个项目不只是做了个模型而是真的解决了一个业务问题。答辩评审的关注点往往就是你能不能从数据里提炼出这样的可解释结论。4. 销量预测模型从基准到对比实验4.1 先跑基准模型给后面所有模型一个参照建模的第一步不是直接上LightGBM而是先跑一个最简单的基准模型。我用的是“过去7天销量均值作为未来7天销量预测”。这个方法几乎不需要编程但它的意义在于界定了“不建模时能达到的精度下限”。在这个项目里某主力SKU的7日均值基准MAPE大约是28%MAE约420件。后面所有模型的评估都跟这个基准对比只有明显超过基准才说明特征工程和模型选择是有价值的。如果新模型连这个简单基准都打不过大概率是特征工程出了问题或者数据划分存在泄漏。基准模型跑完后我记录了三个指标MAE、RMSE、MAPE这是后面所有实验统一的评价标准。4.2 LightGBM实现与关键参数调优LightGBM是这个项目的主力模型。核心训练代码可以简化为如下结构import lightgbm as lgb from sklearn.model_selection import TimeSeriesSplit params { objective: regression, metric: rmse, learning_rate: 0.05, num_leaves: 31, max_depth: -1, min_child_samples: 20, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, lambda_l1: 0.1, lambda_l2: 1.0, verbose: -1 } model lgb.train(params, lgb_train, num_boost_round1000, valid_sets[lgb_valid], callbacks[lgb.early_stopping(100), lgb.log_evaluation(50)])调参顺序我建议分阶段先用0.05的低学习率和较大的迭代轮数配合早停确定大致的迭代范围然后调num_leaves和min_child_samples控制树的复杂度接着调feature_fraction和bagging_fraction降低方差最后用lambda_l1和lambda_l2做正则。不要一上来就全参数网格搜索那样又慢又容易过拟合到验证集上。有个实用细节值得注意所有模型训练前都要设置random_state并且保存好每次实验的配置。否则答辩时老师问“你这个MAPE是怎么跑出来的”如果自己都复现不了整个实验的可信度会大打折扣。4.3 LSTM对比实验深度学习在这个数据集上真实表现如何考虑到标题里有“深度学习”我做了一组LSTM对比实验用TensorFlow和Keras实现一个简单的两层LSTM结构from tensorflow.keras.models import Sequential from tensorflow.keras.layers import LSTM, Dense, Dropout from tensorflow.keras.optimizers import Adam model Sequential([ LSTM(64, return_sequencesTrue, input_shape(window, n_features)), Dropout(0.2), LSTM(32), Dense(16, activationrelu), Dense(1) ]) model.compile(optimizerAdam(learning_rate1e-3), lossmse)LSTM输入需要构造滑窗样本把所有特征归一化到0到1之间窗口长度我试了14天和30天两种。结果符合预期LSTM在这个数据量级下没有超过LightGBM测试集MAPE约23%比LightGBM的17%要差。原因不复杂日化品销售数据量有限且特征是典型的异构表格数据树模型天然能处理离散和连续特征的混合结构而LSTM需要更多数据才能发挥序列建模优势。但这组实验依然值得做。第一它回应了题目里的“深度学习”标签展示了完整的对比图谱第二它说明了“模型不是越复杂越好”这个方法论观点在论文里是有价值的讨论素材。答辩时如果老师问“你为什么不用更复杂的模型”就可以用这份实验数据直接回应。4.4 模型效果评估指标怎么呈现才最有说服力最终我汇总了四个模型的评估结果可参考的表格结构如下模型MAERMSEMAPER²历史7日均值基准42061028%0.71XGBoost32248018%0.85LightGBM31046517%0.86LSTM38054023%0.79需要特别提醒表格里的数字是用于演示对比结构的示例值实际做项目时一定要填自己真实跑出来的结果。我在论文里还分了线上和线下两个渠道分别计算误差发现线下的MAPE比线上低约五个百分点。原因是线下销量波动更小促销节奏稳定线上受大促冲击峰值更难捕捉。这种细粒度的误差分析比只给一个总的MAPE更有价值也能体现对数据理解的深度。评估时还有个容易被忽略的步骤画预测值与真实值的对比折线图以及残差图。如果残差图显示出明显的模式比如低销量日期系统性高估、高销量日期系统性低估说明模型还有未利用的信息需要在特征工程上继续迭代。这些分析在论文的“讨论”和“展望”部分都是很好的内容。5. 项目交付物可视化、代码组织与论文写作5.1 论文里不可缺少的图表清单毕业设计最终交付的成果绝不只是代码照片化的图表是论文最重要的“证据”。我在项目里沉淀了这样一套图表每一张都对应明确的论证目的销量总趋势折线图展示时序全貌分品类销量箱线图对比不同产品的量级差异促销与非促销销量对比柱状图支持营销分析的结论特征重要性条形图展示全局因素排序SHAP Summary Plot揭示影响方向预测值与真实值对比折线图评估模型效果残差分布图定位模型薄弱场景。图表与结论必须一一对应。比如文字写“折扣力度是影响销量的首要因素”配图就要能直观看出折扣力度在特征重要性中排名第一SHAP值分布显示高折扣对应高销量。图文对不上是答辩时最容易被挑出的毛病。5.2 代码工程化让答辩老师看懂你的项目结构好的项目代码组织比花哨的算法更打动评审。我用的目录结构清晰模块职责分明project/ ├── data/ │ ├── raw/ │ └── processed/ ├── src/ │ ├── config.py │ ├── data_prep.py │ ├── feature_build.py │ ├── eda_analysis.py │ ├── model_train.py │ └── interpret.py ├── output/ │ ├── figures/ │ └── models/ ├── run_pipeline.py └── README.md每个模块只做一件事data_prep负责数据清洗和合并feature_build负责生成特征表eda_analysis输出探索性图表model_train负责训练和评估interpret负责SHAP分析和业务结论。run_pipeline.py把整个流程串成一条命令答辩现场直接演示这条命令从原始数据到预测结果一次性跑通观感非常好。README要写清楚四件事运行环境及依赖库版本、数据格式说明、运行命令、结果文件说明。不要小看这份文档很多同学代码能跑但说不清怎么跑最后在答辩上被扣分。5.3 论文结构安排七个章节把逻辑串成闭环最终论文我建议采用七章结构第一章绪论讲背景和意义第二章介绍机器学习、XGBoost/LightGBM、SHAP的技术基础第三章讲数据来源、字段说明和预处理流程第四章是特征工程方案与实验结果第五章是销量影响因素分析包括相关性分析、特征重要性和SHAP归因第六章是销量预测模型构建与对比实验第七章是总结与展望。摘要部分要把核心成果直接亮出来比如“本文构建了基于LightGBM的日化产品销量预测模型测试集MAPE为17%与基准模型相比提升约11个百分点并结合SHAP分析发现折扣力度、促销类型和渠道是影响销量的主要因素”。把关键词放在前面评审一眼就能抓住项目价值。论文篇幅方面我建议正文写到1.2万字到1.5万字之间图表不少于15张这样无论是内容量还是呈现密度都处于比较稳妥的水平。6. 常见问题与避坑实录6.1 时间序列数据里的泄漏问题最隐蔽也最致命做销量预测最常见的坑就是时间泄漏。如果直接把数据集交给train_test_split做随机划分测试集里可能出现12月的数据而训练集里也有12月甚至更晚的样本模型等于提前“看见”了未来的规律测试指标会漂亮到不真实。更隐蔽的是特征级泄漏比如构造“未来7天是否有大促”这个特征时如果直接用完整的促销排期表填充模型在训练和测试阶段都会偷偷使用未来信息。正确的做法有两个层面数据划分上严格按照时间顺序切分特征构建上确保每个时间点只能使用它之前的信息。判断特征是否泄漏有一个简单原则把特征构建代码放在真实预测场景里推演一遍——如果预测当天根本拿不到这个值这个特征就不该进模型。我在项目里专门加了一个验证步骤用截止到某天的历史数据训练模型预测未来7天再和实际值对比这种方法能有效暴露泄漏问题。6.2 特征重要性的误读数字不会说谎但会误导特征重要性高不代表业务因果强。一个高基数的无关特征比如产品编码在树模型里会频繁参与分裂重要性排名可能虚高。这时候不要急着下业务结论先用Permutation Importance做交叉验证再结合SHAP值的方向和幅度综合判断。另外如果两个特征高度相关比如价格和折扣力度树模型可能在一次实验中把重要性全部分给前者另一次又分给后者导致排序不稳定。解决办法是可以做特征冗余检查共线性高的特征只保留其中一个或者用组合特征替代。我在实际分析中就遇到过价格和折扣力度的重要性排名在不同随机种子下波动的情况后来把价格特征换成了“与上一周期的价格变动率”情况明显改善因为变动率消除了量纲和平稳性的干扰模型学到的信息更稳定。6.3 过度清洗和过度调参两个方向的操作风险过度清洗的问题前面提到过把大促峰值当异常值删掉等于把数据里最有信息量的业务场景抹掉了。调参也是同理不要追求验证集MAPE无限下降。树模型的num_leaves从31调到64验证集误差降了0.5个百分点但测试集不降反升这就是过拟合的典型信号。我建议调参时以“在验证集上取得稳定提升”为验收标准每调一组参数至少跑两次取平均值避免被随机性误导。另一个容易忽视的问题是评估指标的选择。日化销量包含较多零值和小销量样本RMSE会把大单日的误差放大只看RMSE容易忽略日常预测的精度。我一般同时看MAE和MAPEMAPE对小销量样本更敏感能反映模型的综合稳定性。对于销量特别小的SKU单独计算MAPE意义不大可以改用WAPE以真实销量为分母加权避免被极端值带偏。6.4 答辩和论文写作里常见的低级错误论文写作中比较常见的硬伤是把“相关性”直接写成“因果性”。比如“气温升高导致销量增加”这句话如果只看相关性分析就不算严谨因为夏季本身有更多户外活动和促销安排气温和销量之间可能是伴随关系而不是因果关系。更稳妥的写法是“在本文数据范围内观察到气温与某些品类销量存在正相关”。这种表达既说明了发现又不会在答辩时被追问到漏洞。还有一类问题是实验记录不全。每次实验的随机种子、数据划分方式、特征版本、超参数配置都要保留下来。答辩老师问“你这个结果是怎么复现的”时如果能打开实验记录表逐一对应是很大的加分项。建议从项目一开始就维护一份简单的Excel或者Markdown实验日志记录每次改动的版本和对应指标这比临时回忆可靠得多。6.5 让演示环节加分的三个小技巧如果答辩有现场演示要求不要只打开Notebook逐格执行。我建议额外做一个轻量的可视化页面用Streamlit或者Flask写一个简单的交互界面选择某个SKU和日期后自动展示历史销量曲线、模型预测曲线和该预测的SHAP归因图。这样演示时可以直接给评审看“为什么这一天预测高因为促销力度大、价格较上周下降”这个体验远比代码滚动要直观。我还养成了一个习惯答辩前准备两套话术一套用30秒讲清楚“项目做了什么、核心结果是什么”另一套用3分钟讲清楚“数据怎么处理、模型怎么对比、结论怎么得到”。前者用于开场介绍后者用于深入问答。任何水平的评审都不可能对30秒版完全无动于衷。最后聊一点个人体会做完这个项目后我最大的感受是销量预测这类题目真正拉开差距的地方往往不是模型有多高级而是数据处理和业务解释是否扎实。如果你打算选这个方向我的建议很朴素先把数据字典吃透把所有特征按照“是否只用历史信息”自查一遍再谈建模预测和分析两条线要分开衡量模型看误差解释看SHAP不要混在一起。最后再分享一个实用技巧——从项目第一天起就维护一份实验日志记录每次数据变换、特征增删、参数调整和对应指标。这个习惯会在写论文和准备答辩时帮你节省大量时间也是我认为这个项目里最值得保留的经验。