简介一套面向人机交互课程设计/大作业的多模态情感识别完整工程覆盖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连续维度用 CCCConcordance 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 怎么选课设和实训场景我常用三个公开数据集按推荐顺序排。RAVDESSRyerson 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 python3.10 -y conda activate memotion pip install torch torchaudio pip install transformers scikit-learn pandas tqdm pillow opencv-python librosa pip freeze requirements.txt参数说明python3.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_tensorspt, truncationTrue, max_length128) with torch.no_grad(): outputs bert_model(**inputs, output_hidden_statesTrue) hidden outputs.hidden_states[-2].squeeze(0)[1:-1, :] # 去掉 CLS/SEP return hidden.mean(dim0).numpy() def extract_audio_feature(wav_path, sample_rate16000): # 统一重采样到 16kHz截断/补零到 4 秒 y, sr librosa.load(wav_path, srsample_rate, monoTrue) y librosa.util.fix_length(y, sizesample_rate * 4) mels librosa.feature.melspectrogram(yy, srsr, n_mels128, hop_length160) log_mels librosa.power_to_db(mels) return log_mels.T.mean(axis0) # 示意输出真实场景再接编码器 def sample_video_frames(video_path, num_frames8): # 从视频里均匀抽 8 帧统一缩放到 224x224 cap cv2.VideoCapture(video_path) n_total int(cap.get(cv2.CAP_PROP_FRAME_COUNT)) ids np.linspace(0, n_total - 1, numnum_frames, dtypeint) 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_length128对一句话足够超过 128 的句子极少n_mels128和hop_length160在 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_t768, dim_a512, dim_v2048, hidden256, n_classes8, dropout0.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))逻辑说明hidden256是经验值。三个模态先各自过线性层加 ReLU把 768/512/2048 的异构维度拉到同一个 256 维空间再拼接避免某个高维模态在梯度里占据主导。dropout0.3适合几千条数据量数据更少可以提到 0.5数据更多降到 0.1。dim_v2048对应 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参数说明lr1e-3适合这个轻量融合网络如果你在微调 BERTlr要降到 5e-5并单独给 BERT 设置参数组。batch_size32在 8GB 显存下没问题CPU 机器降到 8。epochs30配合早停patience7通常是课设数据的上限再久就会过拟合到训练集。还有一个非常常见的失败现象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(seed2025): 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.deterministicTrue保证卷积算子结果可复现代价是训练慢约 10%课设尺度感知不到。cudnn.benchmarkFalse关闭自动选择卷积算法两者一起才能保证同样代码在不同机器上结果一致。注意 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会混入大量无关包。我一般手工维护核心列表并注明最低版本torch2.0 transformers4.30 librosa0.10 scikit-learn1.3 pandas2.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。这个报错在高频搜索里出现的次数很多也是实训验收时最常见的“打不开”原因。原因EOCDEnd 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_locationdevice)别带 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 或者改代码改到全链路顺滑。这既是对评审负责也是给自己留后悔药。走完这一整套你的课设才真正算“交付”而不是“交差”。希望这些经验能帮到你祝你评审顺利。本文还有配套的精品资源点击获取