简介：一套面向人机交互课程设计/大作业的多模态情感识别完整工程，覆盖EEG脑电与EOG眼动信号预处理、特征提取、模型训练与结果可视化全流程，适合需要完成课程设计、实训或学科竞赛的高校学生参考复刻。压缩包包含39个文件，以Python脚本、Jupyter Notebook、预处理后的pkl数据集、原始mat数据及训练过程图片等为主，整体548.29MB，其中源码与模型文件可直接运行，图片记录了loss与accuracy变化等关键结果。已有119人浏览学习。项目答辩平均分达96分，附有清晰目录结构与README说明，拿到后可按步骤复现整个多模态情感识别实验，也可基于此扩展改进，用于期末大作业、毕业设计或初期科研立项，具备较好的借鉴价值。
1. 多模态情感识别课设：先想清楚这个 .zip 要证明什么，再动手
先说一个反直觉的结论：多数交上来的“多模态情感识别”人机交互大作业，问题不在模型精度，而在它配不上“多模态”三个字。最常见的情况是，下载一个公开特征集，把文本、语音、图像的向量拼起来喂给一个 MLP，然后在报告里写“完成了多模态融合”。评审老师或实训验收的工程师一眼就能看出来，你有没有真正处理模态之间的时间对齐、采样率差异和缺失情况。这份“人机交互大作业：多模态情感识别.zip课设&实训&大作业”的价值不在压缩包本身，而在压缩包能否证明三件事：一、你理解模态的异质性和对齐；二、你对比过至少两种融合策略；三、代码可复现、环境可重建。这篇文章就按这条路走，从选题、数据集、基线模型、打包自检到评审避坑，把整条链路按工程师标准讲清。适合两周内要交付课设或实训、不想在答辩现场翻车的同学。
2. 拿到题先别碰模型：任务边界、数据集与融合范式的取舍
2.1 情感不是只有七个类：连续维度标签才是人机交互的常考点
先把一个常见误解纠正掉：很多课设报告写“识别七种基本情绪：happy、sad、anger、fear、disgust、surprise、neutral”，然后拿 RAVDESS 数据集跑一个分类任务就收工。这不叫错，但在人机交互方向的课设评分里，它只是及格线。稍微好一点的题目会要求预测效价（valence，正负倾向）和唤醒度（arousal，兴奋程度）。这两个值是连续量，更接近真实交互场景里“用户现在处于什么状态”的判断。
为什么连续维度更贴近人机交互？因为用户交互过程中的情感不是静止标签，而是一条随时间波动的曲线。一个用户对语音助手说“帮我查下航班”，前 0.3 秒可能是平静的，后半句因为着急开始上扬。离散分类会把整句话压成一个点，丢失中间过程；连续维度预测则可以输出“情绪在后半段明显变得急切”，这种输出在情感陪伴、驾驶疲劳监测、在线教育注意力分析里是能直接用的信号。
正因为目标变了，评价指标也要换。离散分类看 accuracy、F1；连续维度用 CCC（Concordance Correlation Coefficient），它同时衡量预测与真值的相关性和偏差。IEMOCAP 上很多论文的 CCC 也只在 0.4~0.6 之间，所以你的课设做到 0.4 以上已经是不错的基线，这组数字心理预期要先建立起来，不然会觉得自己模型“太差”。
然后是模态的问题。文本是离散 token，语音是高频连续波形，视频是密集帧流，三者本质上是三种不同采样制式。刚上手的人最容易犯的错是把它们各自压成一段向量直接横向拼接，完全不做对齐。后面我会展开讲对齐怎么做，这里只记住一个结论：模态对齐和融合位置，才是评审判断你“有没有真正理解多模态”的两个关键点。
2.2 三种融合范式：早期拼接、晚期决策、中间注意力交互
把从业者常用的多模态融合做法归纳成三条路径，这也是评审最爱问的三个方向。
早期融合（early fusion）是把三个模态的特征在输入侧或浅层拼接，再送进后续网络。优点是实现简单、参数少，一份归一化代码可以处理全部模态；缺点是模态间采样率、时间窗不一致时，拼接向量里带着大量“错位”信息，网络得自己学会对齐，课设数据量下很难学明白。
晚期融合（late fusion / decision fusion）是每个模态各自训练一个子模型，最后把 softmax 分数或回归结果加权平均。优点是各模态互不干扰，某个子模型训练失败还能单独补救；缺点是丢掉了模态间的交互信息。比如“皱眉”和“语气上扬”单独看都不明显，但组合在一起就是明确的怒意，晚期融合捕捉不到这种跨模态组合。
中间注意力融合（intermediate fusion with attention）是我建议你在报告里“秀肌肉”的方向。三个模态先各自过编码层得到序列特征，再通过跨模态注意力或加权求和，把三组特征揉进一个公共空间。它的可解释性强：注意力权重可以直接画出来，说明“这一句话里文本和语音分别在哪些时间点起了作用”。课设数据量不需要很深的网络，一层 Transformer Encoder 或一个点乘注意力就够。
| 融合方式 | 实现复杂度 | 模态交互建模 | 可解释性 | 适合场景 |
|---|---|---|---|---|
| 早期拼接 | 低 | 弱，靠深层网络自学 | 低 | 新手快速出基线 |
| 晚期加权 | 低 | 几乎没有 | 高，各模态分数清晰 | 稳定兜底 |
| 中间注意力 | 中 | 强，显式建模对齐 | 高，注意力可视化 | 冲高分 |
| 混合式 | 高 | 最强 | 高 | 时间充足再考虑 |
我的建议是：代码里先做早期拼接，保证一天内跑通基线；报告里再补一个中间注意力的对比实验。这样“对比过至少两种融合策略”就坐实了，评审追问时也有话可答。
2.3 数据集选型：RAVDESS、IEMOCAP、CMU-MOSEI 怎么选
课设和实训场景我常用三个公开数据集，按推荐顺序排。
RAVDESS（Ryerson Audio-Visual Database of Emotional Speech and Song）：单人短视频片段，文本语音视频三个模态都有，24 名演员，标签是分类式（8 类，含 neutral 和 surprised）。优点是下载方便、文件体积小、网上预处理脚本多，一套跑通全链路大概一天；缺点是样本量不大，约 1400 条，且都是“演出来的”情感，迁移到真实交互场景时表现一般。适合时间紧张、想把链路走通的学生。
IEMOCAP：双人对话，包含文本、语音、视频和面部动作单元标注，标签同时给离散类别和 valence/arousal 维度。规模约 12 小时，常用 5 折交叉验证做“说话人独立”评估。它是人机交互方向论文用最多的数据集，评审也认它。缺点是官方申请需要签协议，网格格式五花八门，预处理成本比 RAVDESS 高。适合想认真做对比实验的同学。
CMU-MOSEI：规模更大，超过 23k 条视频片段，来自 1000 多个 YouTube 说话人，标签是离散和连续维度都带。优点是数据量大、场景自然；缺点是噪声大，部分片段有镜头切换、字幕残留、背景音乐，抽特征时容易把画面里的噪声当成情感线索。适合有 GPU、愿意花时间清洗数据的实训项目。
选型判据我总结成一句话：两周以内用 RAVDESS；两周以上且冲高分用 IEMOCAP；已有 GPU 且愿意做数据清洗，再考虑 CMU-MOSEI。无论选哪套，都要在 README 里写清楚数据版权和许可协议，别把 zip 交上去才发现数据集不能随作品分发。
另外，特征层面有一个音频老牌工具 OpenSMILE，提取 eGeMAPS 特征的代码非常短，能输出 88 维音频特征。它的特点是快，适合做晚期融合的语音分支。如果你不想引入预训练音频模型，用 librosa 提取 log-mel 也可以，只是少了模型内部对语音内容的建模能力，在嘈杂环境里效果会差一些。
3. 跑通最小多模态融合基线：环境搭建、特征抽取与训练参数
3.1 环境与目录结构：从零搭一个能复现的工程
我见过太多课设源码的目录：final_version_v2_最终版.zip，里面层层套着“新建文件夹”。这是交付态度问题，不是技术问题。这里给一个我常用、经得起评审问的目录模板：
multimodal_emotion/ ├── data/ │ ├── raw/ # 原始数据，只读 │ ├── features/ # 抽取后的特征，.npy/.npz │ └── splits/ # 训练/验证/测试划分文件 ├── models/ │ ├── base.py # 单模态编码器 │ └── fusion.py # 融合模块：early/late/attention ├── scripts/ │ ├── extract_features.py │ ├── train.py │ └── evaluate.py ├── configs/ # 每次实验的 JSON/YAML 参数 ├── results/ # 指标输出、混淆矩阵、注意力图 ├── notebooks/ # 探索性分析和可视化 ├── README.md ├── requirements.txt └── run_all.sh每个目录只放一类内容，这是为了让你自己在答辩前 20 分钟能快速定位文件，也让评审能在 30 分钟内顺着 README 走一遍。环境我常用 conda 创建：
conda create -n memotion python=3.10 -y conda activate memotion pip install torch torchaudio pip install transformers scikit-learn pandas tqdm pillow opencv-python librosa pip freeze > requirements.txt参数说明：python=3.10是因为 torch 对它的 wheel 覆盖最全；不指定 torch 版本，让 pip 自动选当前平台对应版本。如果你在 CPU 机器上，安装 torch 时可以指定 CPU 来源的 index。代码里统一用torch.device("cuda" if torch.cuda.is_available() else "cpu")就能同时兼容两种环境。
依赖安装有个小坑：pip freeze > requirements.txt会冻结无关传递依赖，跨机器复现时经常因 build 哈希冲突失败。我一般 freeze 之后手工把行挑一遍，保留核心包和主版本号，再逐个验证能装。README 里只写手动安装命令，比甩一个几百行的 txt 更可靠。
3.2 特征抽取：把文本、语音、图像变成可对齐的向量
进入代码前先说清观点：课设级工程不要端到端训练大模型，直接用预训练特征抽取器把每个模态压成向量，再进融合网络。这样做的理由是训练开销和不确定性都可控，也更符合“把主要精力放在融合设计上”的评审期待。
文本模态用 BERT 取倒数第二层隐藏状态做平均池化，得到 768 维向量；语音模态用 Wav2Vec2 输出 512 维，或 librosa 提取 log-mel 特征；视觉模态对视频抽帧，用 ResNet50 的分类前池化层输出 2048 维。一个典型的特征抽取骨架长这样：
# extract_features.py 节选 import cv2, numpy as np, librosa, torch from transformers import AutoTokenizer, AutoModel def extract_text_feature(text, tokenizer, bert_model): # 输入一句原始文本，输出 768 维句子向量 inputs = tokenizer(text, return_tensors="pt", truncation=True, max_length=128) with torch.no_grad(): outputs = bert_model(**inputs, output_hidden_states=True) hidden = outputs.hidden_states[-2].squeeze(0)[1:-1, :] # 去掉 CLS/SEP return hidden.mean(dim=0).numpy() def extract_audio_feature(wav_path, sample_rate=16000): # 统一重采样到 16kHz，截断/补零到 4 秒 y, sr = librosa.load(wav_path, sr=sample_rate, mono=True) y = librosa.util.fix_length(y, size=sample_rate * 4) mels = librosa.feature.melspectrogram(y=y, sr=sr, n_mels=128, hop_length=160) log_mels = librosa.power_to_db(mels) return log_mels.T.mean(axis=0) # 示意输出，真实场景再接编码器 def sample_video_frames(video_path, num_frames=8): # 从视频里均匀抽 8 帧，统一缩放到 224x224 cap = cv2.VideoCapture(video_path) n_total = int(cap.get(cv2.CAP_PROP_FRAME_COUNT)) ids = np.linspace(0, n_total - 1, num=num_frames, dtype=int) frames = [] for idx in ids: cap.set(cv2.CAP_PROP_POS_FRAMES, idx) ok, frame = cap.read() if ok: frames.append(cv2.resize(frame, (224, 224))) cap.release() return np.stack(frames) # (8, 224, 224, 3)逻辑说明：文本分支取 BERT 倒数第二层是因为最后一层更贴近预训练任务，倒数第二层相对中性，做迁移时平均池化后者往往更稳。语音分支固定到 16kHz 和 4 秒窗，是因为批次内变长输入很难对齐；如果你的音频本身不足 4 秒，fix_length会补零，这比截断好。视觉分支抽 8 帧是平衡计算量和信息量的经验值，8 帧足够覆盖一句 4 秒语音中的主要表情变化。
参数说明：max_length=128对一句话足够，超过 128 的句子极少；n_mels=128和hop_length=160在 16kHz 下每个帧窗口为 10ms，分辨率够用又不至于序列太长。显存紧张时把n_mels降到 80。抽完的特征建议统一保存成.npy，因为训练过程反复读原始视频会非常慢。
3.3 融合模型与训练循环：参数怎么调，失败看哪里
现在到融合模型。给一个早期融合基线，30 分钟能跑通第一个实验：
# models/fusion.py 中的 EarlyFusion 模型 import torch.nn as nn class EarlyFusion(nn.Module): def __init__(self, dim_t=768, dim_a=512, dim_v=2048, hidden=256, n_classes=8, dropout=0.3): super().__init__() self.enc_t = nn.Linear(dim_t, hidden) self.enc_a = nn.Linear(dim_a, hidden) self.enc_v = nn.Linear(dim_v, hidden) self.drop = nn.Dropout(dropout) self.cls = nn.Linear(hidden * 3, n_classes) def forward(self, t, a, v): # 三种模态分别投影到同维空间，再拼接分类 ht = torch.relu(self.enc_t(t)) ha = torch.relu(self.enc_a(a)) hv = torch.relu(self.enc_v(v)) h = torch.cat([ht, ha, hv], dim=-1) return self.cls(self.drop(h))逻辑说明：hidden=256是经验值。三个模态先各自过线性层加 ReLU，把 768/512/2048 的异构维度拉到同一个 256 维空间再拼接，避免某个高维模态在梯度里占据主导。dropout=0.3适合几千条数据量；数据更少可以提到 0.5，数据更多降到 0.1。dim_v=2048对应 ResNet50 pool 层输出，如果你换了轻量 CNN，这里要改成对应维度。
训练循环我习惯写成命令行脚本：
python scripts/train.py \ --fusion early \ --hidden 256 \ --dropout 0.3 \ --batch_size 32 \ --lr 1e-3 \ --epochs 30 \ --seed 2025 \ --device cuda参数说明：lr=1e-3适合这个轻量融合网络；如果你在微调 BERT，lr要降到 5e-5，并单独给 BERT 设置参数组。batch_size=32在 8GB 显存下没问题，CPU 机器降到 8。epochs=30配合早停patience=7通常是课设数据的上限，再久就会过拟合到训练集。
还有一个非常常见的失败现象：loss 不降。先看学习率，再看特征是否归一化。我习惯把每个模态特征做 z-score 标准化，否则文本特征均值在 0 附近而视觉特征方差上千，模型会学成“只看视觉模态”。归一化代码加一行：
from sklearn.preprocessing import StandardScaler feat = StandardScaler().fit_transform(feat)训练过程中还要盯一组更细的指标：验证集上不仅看 loss，还要看每个模态单独丢掉的消融结果。这个我们放到第 5 章和最后冲刺部分展开。现在请记住，训练时把 torch.save 的 checkpoint 只留最后一个 epoch 的那份，别把 30 个 epoch 的中间权重都塞进最终 zip，体积太大。
4. 打成 .zip 前的自检：报告论证、复现底线与打包规范
4.1 报告与代码的对应关系：让评审 30 分钟看懂你的工作
课设 zip 的评分逻辑是：评审先看压缩包里的 README 和报告，再决定要不要看代码。如果第一层目录名混乱，大概率直接给中等分。我建议报告采用三段式，对应代码目录也采用三段式。
报告“方案设计”章节对应models/fusion.py里的 EarlyFusion、LateFusion、AttentionFusion 三个类；报告“实验分析”章节对应configs/下每次实验的参数 JSON；报告“结论”章节对应results/下的指标 JSON 和混淆矩阵。最好在图的图注里写“本图由scripts/evaluate.py复现”，评审照着命令跑一遍就能对上。
| 报告章节 | 对应代码文件 | 评审查验动作 |
|---|---|---|
| 方案设计 | models/fusion.py | 看三类融合是否都实现 |
| 实验设计 | scripts/train.py + configs/*.json | 挑一组参数复跑 |
| 结论分析 | results/*.json | 对比指标和报告是否一致 |
一个实用技巧：代码里所有图表输出统一加--save_plot results/xxx.png参数，报告里嵌的每一张图都能从代码重新生成。截图可以伪造，命令输出不能。README 里写明“复现完整流程只需三步：解压、安装依赖、运行run_all.sh”。这里面run_all.sh的内容最好是先抽特征再训练再评估，一条链路跑到结束，评审能直接用就是很重的加分项。
4.2 随机种子、requirements.txt、相对路径：复现的底线
“我先跑的时候是好的”这句答辩口头禅，本质是复现没做好。复现三件套：固定随机种子、固定环境依赖、消除绝对路径。
固定随机种子的标准写法：
# common/seed.py import random, numpy as np, torch def seed_everything(seed=2025): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic = True torch.backends.cudnn.benchmark = False逻辑说明：cudnn.deterministic=True保证卷积算子结果可复现，代价是训练慢约 10%，课设尺度感知不到。cudnn.benchmark=False关闭自动选择卷积算法，两者一起才能保证同样代码在不同机器上结果一致。注意 PyTorch DataLoader 开启多进程时，worker 的随机数要单独处理：
def worker_init_fn(_): import numpy as np np.random.seed(int(torch.utils.data.get_worker_info().seed) % (2**32))requirements.txt 的生成前面提过，pip freeze会混入大量无关包。我一般手工维护核心列表，并注明最低版本：
torch>=2.0 transformers>=4.30 librosa>=0.10 scikit-learn>=1.3 pandas>=2.0最后是相对路径。所有脚本统一用：
import os, sys BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) sys.path.insert(0, BASE_DIR) os.chdir(BASE_DIR)这样 zip 解压到任意位置都能直接跑。不要在自己机器上把D:\homework\...写进任何文件，评审一解压就是 FileNotFoundError。
4.3 打包前必须排查的 5 个环境问题
第一，预训练模型缓存是否被带进来。Hugging Face 缓存通常在~/.cache/huggingface，体积动辄几个 GB，绝对不要打进 zip。应该在 README 写“首次运行会自动下载模型”，或者在脚本里设TRANSFORMERS_CACHE指向项目内置目录由用户自行下载。
第二，是否有 GPU 专属代码。torch.cuda.is_available()要兜底，不要直接在device = "cuda"处硬编码。还有.cuda()这种写法要替换成model.to(device)。
第三，是否包含不带授权的数据。RAVDESS 可以再分发，IEMOCAP 不行。打包前把data/raw/从 zip 里排除，单独放 5 个 demo 样本到data/demo/即可。
第四，临时文件是否清干净。__pycache__、.ipynb_checkpoints、train.log、predictions.npy这类大文件会在评审解压时拖慢速度，也显得工程习惯不好。打包命令里直接排除：
zip -r handin.zip . \ -x "data/raw/*" \ -x ".git/*" \ -x "**/__pycache__/*" \ -x "*.pyc" \ -x "train.log" \ -x "*.npy"第五，压缩包层级是否正确。很多人右键“压缩为 zip”会把最外层变成一个嵌套目录，评委解压后还要点两下才看到 README。我建议在项目根目录执行zip -r handin.zip .，这样解压后直接落在项目根目录。如果你在用第三方压缩工具，注意它的右键菜单常常默认勾选“加密文件名”或“伪加密”，这个默认行为是课设 zip 弹密码框的主要来源之一，打包用命令行 zip 能绕开这些隐藏选项。
5. 解压与验收的避坑：伪加密、EOCD 损坏和演示现场翻车
5.1 zip 伪加密与 zip 密码移除：交作业前最常见的“翻车”
现象：评审或同学收到 zip，双击解压居然弹密码框，你明明没设密码；或者你用压缩工具加了密码，自己也记不清了。
原因：不少校园环境和第三方压缩工具自带“伪加密”。伪加密不是真正加密，只是把 zip 的加密标志位设成 1，文件数据本身没有变化。解压软件看到标志位就停下来要密码，但数据其实完全可读。
解决：如果确认是准加密，可以用十六进制编辑器打开 zip，搜索中央目录文件头签名50 4B 01 02，把通用位标志的最低二进制位从 1 改回 0，保存后重新解压。这个操作能去掉密码框，但改错一个字节可能让整个 zip 报废，操作前记得备份。更稳的做法是在打包环节就避免：不加密、不用第三方压缩工具的“伪加密”选项、不用带密码的压缩包。密码对评审来说不是安全功能，是给自己挖的坑。如果学校特异要求“zip 密码移除后才能审查”，干脆把密码写进 README，评审至少不用猜。
5.2 “导入失败 caused by: invalid zip archive: could not find eocd”是怎么回事
现象：解压工具或 Python 的zipfile.ZipFile报错：caused by: invalid zip archive: could not find eocd。这个报错在高频搜索里出现的次数很多，也是实训验收时最常见的“打不开”原因。
原因：EOCD（End of Central Directory）是 zip 文件末尾的一段固定结构，记录中央目录的偏移和文件总数。解压器在文件末尾约 64KB 范围内找不到 EOCD 签名0x06054b50，就判定不是合法 zip。常见来源有三个：一是下载中断，zip 文件被截断；二是用文本编辑器从网页源码里复制了下载链接，实际保存的是 HTML 文本；三是把.dat或.bin直接改名成.zip。
排查方法用一个小脚本判断尾部：
# check_zip.py 快速诊断 zip 尾部完整性 with open('handin.zip', 'rb') as f: f.seek(-22, 2) # 跳到文件倒数第 22 字节 tail = f.read(22) print(tail[:4].hex()) # 正常输出 504b0506，否则 EOCD 缺失解决：确认截断就重新下载或重新打包。用文本编辑器保存导致的情况，直接删除并回到原始文件重新执行zip -r handin.zip .生成，没有捷径。这一点参考网上各类 zip 便携版安装教程也能得到同样结论——比如 MySQL 8.0 的 zip 免安装版，解压后缺 bin 目录，你要做的是重新完整解压，而不是手动补一个同名空文件。zip 损坏从来不是靠补能解决的，唯一可靠的动作是重新打包。
5.3 演示现场翻车：模型加载慢、GPU 不存在、路径写死
现象：答辩现场，评委说“演示一下吧”，你打开机器发现torch.cuda.is_available()返回 False；或者模型加载权重耗时 30 秒，界面一直空白。
原因：准备时在 GPU 机器跑过，答辩机器是 CPU 或异构环境；权重路径被写死，加载时抛 FileNotFoundError；加载后没有做 warmup，第一次推理触发了卷积算子编译。
解决：
- 设备统一用
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")； - 权重加载用
torch.load(path, map_location=device)，别带 GPU 专属的 map； - 演示脚本启动后先做一次空 forward，预热模型和 CUDA 上下文；
- 准备好一段 30 秒的录屏作为兜底，现场环境实在不行就放录屏，并说明“这段录屏是在相同参数下的复现结果”。
如果现场压力更大，比如多线程 DataLoader 和演示进程在 CPU 上抢资源，可以把 DataLoader 的num_workers设为 0，牺牲一点加载速度换稳定性。这个小改动看起来不起眼，但不少演示卡顿都是它引起的。
5.4 评审被问倒的三个“为什么”
带项目时最常听到三个问题，每个都有标准答法。
“为什么用这种融合方式？”——因为你对比过。把早期拼接、晚期加权、中间注意力三组指标列在同一张表，补一句“中间注意力在验证集上 F1 高出 4%，所以最终方案选它”。这一句话比背任何原理都管用。
“训练集和验证集有没有数据泄露？”——如果用的是 IEMOCAP 这类带说话人的数据集，按说话人划分折叠，保证同一人的片段不会跨集合出现。划分逻辑单独放data/splits/目录，让评审能查看。RAVDESS 因为演员是单人单条，这个问题风险低；但对话类数据集做随机划分就很容易泄露。
“某个模态缺失时模型还 work 吗？”——没测过只能答“没测”。测过就在 README 记一笔：“去掉文本模态 F1 降 12%，去掉音频降 8%，去掉视频降 3%”。这组数字能说明每个模态的贡献排序，评审对这份作业的数字严谨度会立刻调高评价。
5.5 环境跨机器迁移：conda env export 不能照抄
现象：自己机器跑得好好的，解压到机房后 import torch 直接失败，装依赖花掉一下午。
原因：conda env export导出的 env.yaml 带 build 哈希和官方 channel，学校镜像源不一致时常解析失败。
解决：用conda env export --no-builds导出纯版本号，或者在 README 只写手动安装命令。如果对方机器没有 GPU，把 torch 安装命令换成 CPU 版。不要在代码里出现“先测一下torch.cuda.is_available()”这类调试行为，更不要把“GPU 可用”写死为运行前提。兼容的写法是：CPU 机器上自动降级到 CPU 推理，虽然慢一点，但至少能演示，不会现场崩。
环境迁移后建议做一次全量测试：解开 zip 到新目录，创建新 conda 环境，装 requirements，跑python scripts/evaluate.py观察指标和 README 一致。这一步做完，你的课设在技术交付层面就没有明显硬伤了。
6. 既然基线稳了：把“跑通”升级成“讲好”的三个加分项
基线跑通、README 写好后，我会问自己一个问题：这份 zip 如果只体现“我会训练一个模型”，它只能拿及格分；要拿高分，得让人看到思考过程。这里分享三个基于现有代码就能做的加分项，不重造轮子。
第一个是模态缺失实验。在融合层加一个输入侧 dropout：以一定概率把文本或音频或视频特征整体置零，分别测验证集指标。这个实验在报告里只占一句话：“当语音模态被屏蔽时，模型 F1 下降 10.2%，说明语音在本任务中贡献最大”，但说服力超过一整页原理。做法是在融合模型的 forward 里加一个二值 mask 参数，训练时以 0.3 概率把某个模态的向量置零。
第二个是注意力可视化。如果用了中间注意力融合，把跨模态注意力权重输出成 JSON，再挑一个典型样本，画出文本 token 和音频时间窗的注意力热力对应关系。评审看到“当说话人重读某个词时，注意力集中到语气上扬的时间段”这种图，基本就不会再怀疑你是否真正理解了多模态。
第三个是报告里对比表格的规范写法。不要只给最优结果，给五个数字：文本单模态、音频单模态、视频单模态、早期融合、中间注意力融合，每个都带 3 折交叉验证的均值和标准差。例如：文本 F1 0.61±0.03，音频 0.52±0.04，视频 0.47±0.03，早期融合 0.68±0.02，注意力融合 0.72±0.01。这组数字直接证明“多模态有效”“融合设计有效”，同时满足了“对比至少两种策略”的潜台词。
最后是我自己交课设前一定做的事：把 zip 解压到一台干净机器上，从conda create开始完整复跑一遍 README，全程录屏。录屏时哪一步崩了，就现场改 README 或者改代码，改到全链路顺滑。这既是对评审负责，也是给自己留后悔药。走完这一整套，你的课设才真正算“交付”，而不是“交差”。希望这些经验能帮到你，祝你评审顺利。
本文还有配套的精品资源，点击获取
