1. 项目拆解新闻情感分析系统到底在做什么先给结论这个毕业设计项目的核心不是“把模型跑通”而是完整走通一条从新闻数据采集、清洗、标注到深度学习模型训练再到结果可视化、可交互预测的数据链路。标题里的“Python深度学习”“新闻可视化”“大数据”三个词看着唬人但实际上每一步都是有标准答案的工程问题。很多同学拿到这个题目第一反应就是“情感分析上来就用 BERT 微调”结果真开工后才发现数据采集和清洗可能占掉整个项目 60% 以上的工作量。我之前也带过几个做类似题目的学弟学妹最常出现的情况是答辩前两周还在改爬虫原因是新闻站点改版、正文提取不干净、标注数据分布不均匀。这篇文章我会把这条链路上的每个环节拆开讲清楚包括我自己踩过的坑以及反复试过真正有效的做法。这篇内容适合三类人看一是已经定了或正在考虑“新闻情感分析”“文本情绪识别”“新闻可视化系统”作为毕设题目的同学二是想用 Python PyTorch 做自然语言处理方向入门项目、又希望项目有完整演示效果的人三是在做大数据方向课程设计想把爬虫、数据分析和可视化串起来做一个“能跑、能看、能讲”的系统的人。我不打算堆理论而是尽量说落地的事。1.1 系统模块到底怎么拆毕业设计题目里的“源码 LW 文档 PPT 讲解”只是交付形式真正决定项目质量的是你有没有把系统拆成足够清晰的功能模块。一个能拿去答辩的新闻情感分析预测系统一般拆成六个部分新闻数据采集模块负责从新闻网站、RSS 源或公开 API 获取新闻标题和正文内容存成结构化数据。这一步解决“数据从哪来”的问题。数据预处理模块负责清洗 HTML 标签、抽取正文、去噪声、分句、分词、去停用词、构建词典把原始文本变成模型能读的数值序列。模型训练与评估模块用标注好的语料训练情感分类模型输出准确率、精确率、召回率、F1 和混淆矩阵并且能保存模型文件。情感预测与统计模块对新的新闻内容输出正面、负面、中性的概率支持单条预测和批量预测。可视化展示模块用 ECharts 或 pyecharts 展示新闻情感分布、时间趋势、热词词云、分类结果对比等。前端交互模块提供一个简洁的 Web 页面输入新闻文本或者上传批量数据就能看到预测结果和对应图表。单纯训练一个文本分类模型其实拿不到高分真正拉开差距的是“可视化”和“预测系统”这两个关键词。答辩评委通常不会死抠你的损失函数但会非常在意“图表数据是怎么来的”“遇到新数据系统还能不能正常预测”“爬虫挂了你的系统会不会直接瘫痪”。模块拆得清楚回答这些问题才不慌。1.2 技术栈选型的底层逻辑技术选型没有绝对标准但有一条现实原则能快速出结果、能讲清楚原理、能稳定演示的方案就是好方案。数据采集推荐 Python 的 requests 配合 BeautifulSoup 或 lxml。有些新闻网站有 JSON 接口用 requests 直接请求 JSON 比解析 HTML 稳定得多。比如一些新闻聚合站点会提供搜索接口返回结构化的标题和正文这种源一定要优先用能省掉大量清洗时间。数据存储不建议上 MongoDB 或 MySQL 这种重量级方案CSV 或 SQLite 足够应付几万条新闻数据。答辩时如果需要讲“大数据”可以强调数据采集的规模和处理流程而不是盲目吹分布式存储。一套能正常处理 2 万条新闻数据的系统比一台只搭了 Hadoop 环境但业务逻辑没跑通的项目实用得多。模型选型方面我推荐 PyTorch 作为主力框架。原因有三点第一PyTorch 的生态和自然语言处理相关教程最丰富遇到问题搜起来快第二文本分类场景下 PyTorch 的 API 设计比 TensorFlow 更适合快速迭代第三从词向量到 LSTM、TextCNN 再到 BERTPyTorch 都能平滑迁移答辩时可以展示“我用同一条代码改几行就换了模型”的对比实验。可视化层用 pyecharts 最省事它是 Python 对 ECharts 的封装直接把数据和配置项传给图表对象能生成 HTML 页面。如果选择前后端分离的展示方式就用 FastAPI 提供 JSON 接口前端用 Vue 或原生 HTML 加 ECharts。这里要提醒一句如果你对前端不熟不要硬上 Vue用 Flask/FastAPI 渲染一个简单的 HTML 模板就够了项目完整度才是关键。2. 数据链路搭建新闻数据采集与预处理很多人忽略数据链路以为直接下载别人整理好的 CSV 就能训练这在竞赛里没问题但在毕业设计答辩里很容易被问住。评委大概率会追问“你的训练数据来自哪里”“如何保证数据质量”“数据量大概多少”。如果你连原始数据是怎么来的、清洗过哪些步骤都说不清楚模型的性能数字再漂亮也站不住脚。2.1 数据来源与采集策略新闻数据的来源可以分三类第一类是自己写爬虫抓取公开新闻页面。优点是获取方便、可以自定义数据规模缺点是需要处理反爬和正文抽取。我建议选 3 到 4 个结构稳定的新闻入口作为训练数据来源不要贪多。一旦来源多了新闻去重、时间格式统一、正文编码处理都会变成负担。第二类是使用公开的新闻 API 和 RSS。RSS 源结构固定通常直接包含标题、摘要、发布时间解析起来简单。部分新闻站点提供历史 API可以按时间范围拉取文章列表。这类方式的代码量最少稳定性也最高适合用来打底。第三类是使用开源的新闻数据集比如一些公开的标题分类、情绪分析数据集。这类数据适合用来做预训练和模型调试但答辩时要注意说明数据来源和版权问题不要把它说成自己采集的。采集策略上有一个强烈建议同时存两份数据一份是原始 HTML一份是解析后的结构化文本。原始 HTML 可以用来回溯清洗逻辑问题结构化文本用来训练和可视化。我自己曾遇到过清洗规则写错导致正文混入大量“点击查看更多”这类干扰文字模型效果莫名其妙变差返工检查原始数据才发现问题。2.2 清洗、分词与去停用词怎么做拿到原始新闻文本后需要按顺序处理去掉 HTML 标签和脚本代码处理 CSS 样式块。抽取正文区域。如果用的是请求 JSON 接口的数据这一步可以省掉。处理特殊符号全半角统一、去掉连续空格、去除非文字字符。去除重复新闻。很多新闻站点会互相转载标题相似度极高。可以用标题的 MD5 值去重也可以用 minhash 或 simhash 做近似去重。分句和分词。中文分词用 jieba 就好注意加载自定义词典把“新能源汽车”“数字经济”这类领域词切成一个整体否则模型会把这些词拆得七零八落。英文场景则直接用空格分词并做词形还原。去停用词这块要谨慎。中文停用词表有很多公开版本但不建议直接套用大而全的列表比如“我们”“你们”“自己”这类词如果用得太猛会丢失新闻里的主语关系。更合理的方法是保留所有在训练集里出现频率较高但对分类没有明显作用的词然后只去掉其中的一部分。你可以先跑一版不过滤停用词的模型再对比过滤后的效果用实验数据决定最终方案这样答辩也更有的说。分词完成后还有一个容易被忽略的步骤构建词典。把训练数据里出现次数大于某个阈值的词纳入词典比如出现频率少于 2 次的词直接丢弃映射成“未知词”传给模型的输入就变成一列整数 ID。这样既减少了模型参数量也提升了对未登录词的泛化能力。2.3 标签体系与样本标注思路新闻情感一般分成正面、负面、中性三类不建议选二分类。因为很多新闻用中性语气陈述事件硬分成正负两类会让人工标注非常纠结模型也很难收敛。三分类能照顾到客观新闻的比例实际答辩时也更符合常识。标注数据是最耗时的一步。如果你实在凑不齐人工标注量可以采取“半自动标注 人工校验”的方式先用一个开源情绪词典对句子打粗标然后人工检查不一致的部分。虽然这种方式有一定噪声但能快速拿到几千条可用语料。更稳妥的做法是在公开新闻数据集上做迁移学习先用已有的通用中文情感语料训练一个基础模型再用你自己采集的新闻语料做小额微调。这样即使有标注数据只有几百条模型也不会因为样本太少而完全学不到语义。答辩的时候可以说清楚“哪些数据是公开的、哪些是自建的、自建数据怎么验证质量”这种严谨度反而是加分项。训练样本数量方面来自真实项目的经验是做三分类情感分析如果用的是 BiLSTM 或 TextCNN 这类非预训练模型单类别至少要有 1500 条以上样本整体不低于 5000 条效果才比较稳定。如果换成 BERT 这类预训练模型且用全量微调单类别 500 条也能跑出不错效果但训练时间和显存要求会上去。3. 情感分析模型从词向量到深度学习的落地思路模型部分是整个项目的技术核心但也是最容易“堆复杂度”的地方。很多同学喜欢把模型做得特别复杂加双向 LSTM、加多层的 Attention、再用各种技巧调参最后答辩时讲不完自己也被各种细节绕晕。我个人的意见是先做减法再谈优化。3.1 为什么不能只靠情感词典情感词典是最基础的方案——给每个词分配一个情感极性分值句子情感分直接累加。这个方案在文言文风格明显的短文本上效果还行但新闻文本场景存在两类问题。第一是语境问题。新闻里常有“取消关税”“化解风险”“防止污染”这类短语“取消”和“防止”本身是负面动作但修饰的对象可能是中性事物。情感词典无法建模词语之间的修饰关系和否定逻辑准确率自然上不去。第二是新闻语言的客观表达。新闻正文喜欢用“据统计”“相关人士表示”“有关部门回应”这类中性引导语情感词典会把注意力分散在这些无意义词上。深度学习模型至少能通过注意力机制和上下文编码学到“整句话的真正情绪是什么”这是词典方法做不到的。因此这个项目的模型必须放在深度学习框架里做。哪怕你用的是一个很简单的 TextCNN从数据流上讲也是“词向量查找 卷积池化 全连接分类”的端到端学习完整覆盖了语义表示、特征提取和分类决策三个环节答辩时的可讲性比词典方案强太多。3.2 LSTM、TextCNN 与 BERT 怎么取舍实际工程项目里有三套主流情感分析模型各自的适用场景差别很大TextCNN经典且轻量适合大多数中文短文本分类任务。速度快、显存占用低、调参简单适合毕设项目保底。BiLSTM能捕捉长距离依赖适合新闻正文这种长文本但训练速度比 TextCNN 慢序列太长时需要截断。BERT效果最好但显存、训练时间、部署资源要求也最高适合作为对比实验模型而不是唯一方案。我的建议是主线用 TextCNN 或 BiLSTM 之一把 BERT 作为“锦上添花”的对比实验。讲对比实验的意义在于展示你对模型原理的理解TextCNN 用卷积核抓取局部 n-gram 特征BiLSTM 抓时序上下文BERT 利用大规模预训练语义表示。三类模型的结构差异、效果差异、训练成本差异就是答辩时最好的素材。如果你选择 BiLSTM输入层推荐用 100 到 200 维的随机初始化的词向量训练过程中一起更新比使用固定词向量效果更好。另外可以考虑在 LSTM 输出上增加一个 Self-Attention 加权层把各个时间步的隐藏状态加权合并这部分代码量不大但能明显提升长新闻的情感捕捉能力。如果训练数据量确实不够再考虑加载预训练词向量例如从公开的腾讯词向量数据中匹配你的词典。注意词向量维度一般 200 维左右加载后冻结若干轮再放开微调效果比全程冻结要好。3.3 训练细节早停、学习率与过拟合控制训练模型其实有很多琐碎但关键的决定直接影响最终答辩时的性能数值。我经常见同学把训练轮数设成固定 50 轮结果第 20 轮就已经过拟合验证集准确率持续下降后面 30 轮纯粹浪费时间。所以一定要做早停。早停怎么写很简单每个 epoch 结束后在验证集上计算损失如果连续 N 轮验证集损失没有下降就恢复最佳模型权重并停止训练。我常用的是 patience 设 5 轮保存验证集 F1 最高的模型 checkpoint最后用这个 checkpoint 做预测。学习率建议从 3e-4 或 1e-3 起步文本分类小模型用 Adam 优化器比较稳妥。如果训练时出现 loss 下降缓慢或震荡可以尝试在训练中期把学习率降低一半。学习率 1e-2 以上的初始值在深度学习文本任务里基本就是灾难除非你在用非常大的 batch。控制过拟合的另一个有效手段是调节 dropout。TextCNN 和 BiLSTM 的 embedding 层后建议加 0.3 左右的 dropout模型输出层前再加一轮 dropout一般 0.3 到 0.5 之间调整即可。很多同学只顾调模型结构忘了调 dropout结果验证集和训练集差距越来越大。还有一个容易被忽略的员工是类别不平衡。新闻数据里正面和中性通常远多于负面纯用交叉熵会把模型往多数组偏。可以用加权交叉熵把每个类别的权重设成样本数量的反比或使用 focal loss 做困难样本挖掘。答辩时如果能解释清楚为什么引入类别权重是一个很加分的技术点。4. 新闻可视化与预测系统集成从模型到产品模型训完后还需要把模型“包装”成一个用户能感知的系统这部分既是毕设的功能验收重点也是演示环节最容易出彩的地方。很多课程设计只提供一个训练脚本和几个准确率数字这让整个项目的完整度大打折扣。新闻可视化预测系统的本质是把模型能力变成交互入口。4.1 可视化内容怎么设计可视化并不是把图表堆上去就行而是要让每张图表能回答一个具体问题。我建议按数据来源分四个视角展示整体情感分布用环形饼图展示全部新闻中正面、负面、中性占比。时间趋势变化用折线图展示近几个月内三种情感随时间的波动趋势帮助观察舆情走势。热词词云对正面新闻和负面新闻分别统计高频词生成两个词云对比两类新闻关注的话题差异。媒体来源对比用柱状图对比不同新闻来源的情感倾向分布展示哪些来源更偏正面、哪些更偏负面。这里有个实操细节时间趋势图的数据聚合最好在 Python 后端完成只把聚合后的 JSON 传给前端不要在浏览器端再现写过滤逻辑。你得保证图表里的数据格式和模型预测结果严格对应否则答辩现场会出现“图表显示正面新闻占比 70%但我刚才输入的这条新闻预测是负面”这种尴尬。pyecharts 的做法很简单把 model.predict 的输出结果拆成 DataFrame然后按时间字段 groupby再调用 Pie、Line、WordCloud 等组件。如果需求是把新闻文本和情感标签一起展示可以做一个简单的表格组件分页显示每条新闻的预测结果和置信度。4.2 后端接口与前端展示如何对接前端展示和后端接口的对接目标是把模型预测能力包装成 Web 服务。推荐用 FastAPI 或 Flask 写接口。FastAPI 自带异步能力和自动生成的 API 文档演示时打开文档页面显得项目更专业Flask 则更简单直观适合已经没有太多时间改代码的情况。后端要有两个核心接口单条预测接口POST /predict接收 JSON 格式的新闻标题和正文返回情感类别、各类别概率、关键词列表。批量预测接口POST /predict_batch接收 CSV 文件或 JSON 列表返回带标签的完整表格数据直接供可视化模块使用。服务端加载模型要注意两点。一是用中文分词时需要把 jieba 的初始化放到应用启动时完成避免每次请求都重新加载词典。二是用 PyTorch 的 torch.load 加载模型时要指定 map_location 参数否则在 GPU 上训练的模型部署到 CPU 环境会直接报错。这个坑非常常见我见过至少三个人在答辩演示的前一天晚上被卡在这里。加载模型后用 predict 脚本解析文本把分词、词典映射、padding、模型 forward、softmax 概率计算串成同一个函数。建议不要加太多复杂的服务层保持逻辑简单能跑通就是胜利。4.3 前端页面怎么设计才稳前端页面不建议写得太花哨一个干净的布局就够顶部是标题栏和说明文字中间是一个多行文本框用来粘贴新闻右侧或下方是预测结果卡片底部是图表展示区域。表单提交建议用异步请求不用刷新整个页面。点击“分析”按钮后页面把输入内容发送到 /predict 接口拿到结果后动态渲染情感标签、概率进度条和关键热词同时请求可视化接口把整体分布饼图和趋势折线图一起刷新。页面交互里最容易翻车的是中文乱码和图表刷新失败。解决方案是统一字符集 UTF-8并在后端响应头里指定 charsetutf-8。附带的经验是演示时先输入一条测试文本预先把图表数据缓存好避免现场网络波动导致图表加载不出来。毕业设计答辩现场通常网络环境不稳定所有资源尽量本地化ECharts 静态资源也下载到本地目录别依赖 CDN。5. 论文、PPT 与答辩准备的实战清单毕业设计不只是代码最终分数很大一部分来自论文、PPT 和答辩讲解。标题里的“LW 文档 PPT 讲解”放在源码后面看起来像附加品实际上很多学生恰恰因为忽视这三项而丢了分。论文和 PPT 的组织逻辑必须和代码结构互相呼应。5.1 论文结构怎么组织论文不要写成“用户手册”而要按“问题提出-方案设计-系统实现-实验验证”这条主线展开。我建议参考这个结构第一章绪论写研究背景和意义说明新闻情感分析在舆情管理、信息推荐、内容监控等场景的价值。写完背景后必须写国内外研究现状不要只罗列别人论文的名字要总结“目前已经有哪几类方法、有哪些不足、你准备在哪些方面改进”。第二章需求分析要写清楚系统的功能需求和非功能需求可以配合用例图和数据流图。即使你代码里没有完整的软件工程流程论文中也要体现需求到功能的映射关系答辩老师很吃这一套。第三章系统设计写总体架构、模块设计、数据库表和接口规范。这里把 1.1 节拆出来的功能模块解释清楚把数据表和接口列表列全论文看起来就会很专业。第四章核心模型设计是论文重点写清词嵌入方式、模型结构、损失函数、训练策略。比例要放大最好配合层次图说明数据从输入到输出的流转过程。关键公式可以写但必须配合文字解释别让公式直接裸奔。第五章系统实现写界面截图和关键代码片段界面截图一定要高清、有标注、能说明业务逻辑。代码片段只贴核心部分不要把所有源码贴上去。第六章实验与结果分析写数据集、评价指标、对比实验结果、可视化结果。这部分要给出表格模型名称、准确率、精确率、召回率、F1、训练时长。答辩时老师大概率会盯着这个表格提问。5.2 PPT 怎么做到一页讲一个重点PPT 总页数不建议超过 20 页。很多学生一上来就放 30 多页每页都是大段代码评委根本看不完自己也讲得毫无节奏。我的经验是遵守“一页一个重点”原则第 1 页放项目名称和你的基本信息第 2 页放研究背景和选题意义第 3 页放系统功能架构图让评委一目了然第 4 到 6 页放数据采集和预处理流程重点展示清洗前后对比第 7 到 9 页放模型结构和训练细节展示你如何调参、如何评估第 10 页放实验结果表格重点展示模型对比第 11 到 13 页放系统界面截图和效果演示第 14 页放创新点和不足创新点实事求是讲两三条就够不足之处也不用回避但要紧接着说改进思路第 15 页是总结和致谢。PPT 里不要只贴大段源码可以把代码截图裁小并加边框标注旁边用文字说明“这里实现什么功能”。图形、表格、截图三者的比例最好占到 60% 以上文字越少越好。5.3 答辩高频问题怎么准备答辩时间一般控制在 10 到 15 分钟提问环节大概会有 5 到 10 个问题。高频问题集中在下面几个方向数据方面数据用来训练的有多少条怎么保证数据质量类别不平衡如何处理模型方面为什么选这个模型和另一个模型比较过没有模型参数怎么确定的有没有试过其他损失函数系统方面如果新闻来源变了系统还能跑吗爬虫失败怎么办模型加载内存占用是多少可视化方面图表的数据是实时生成的吗刷新频率是多少时间趋势怎么聚合的这些问题的答案最好提前写进论文里答辩时直接引用论文相应章节。还有一个容易被问到的细节是“讲一下系统处理一条新新闻的完整流程”必须能把这个流程从页面提交、后端接收、文本预处理、模型预测到图表更新一口气讲清楚中间不卡壳。答辩前建议自己对着流程跑两遍。6. 常见问题与排查技巧我踩过的坑最后这部分我想系统整理一些项目实施过程中容易遇到的问题。这些问题分散在数据、模型、部署三个环节每一个我都实际遇到过并给出了可行的排查思路。6.1 数据标注效果差、类别失衡怎么办我最早用 3000 条新闻数据训练三分类模型负面样本只有 300 条结果负面类别的 F1 只有 0.3 左右。这个问题的根源不是模型结构差而是数据分布严重失衡。解决方法是先做类别统计再策略性调整样本量。负面新闻不足就从新闻采集源里筛选负面关键词较多的文本补采或者用公开的负面情感语料混合进来。没时间补数据就做数据增强用同义词替换、随机删除部分词、回译等手段扩充负样本。注意回译生成的数据会有噪声需要人工抽检。还有一个可行办法是把三分类改成“正/非正”的粗粒度二分类再针对负面类别单独训练一个检测模型。但如果论文里已经写了三分类不建议临阵改任务会留下较大的逻辑漏洞。6.2 模型训练 loss 不下降或溢出训练初期常见三种现象loss 一直不变、loss 快速变成 nan、验证集准确率异常低。loss 一直不变大概率是学习率太低或模型输入没对齐。检查输入的序列 ID 范围看看 padding 后是否全是 0。注意 PyTorch 的 Embedding 层要从 0 开始编码如果词典索引从 1 开始0 就会被当作 padding这是很多新手容易搞混的细节。loss 变成 nan 的原因通常是学习率过高、文本序列过长导致梯度爆炸。可以尝试把梯度裁剪值设成 5.0 或者把学习率降到 1e-4。中文长新闻的序列长度经常超过 1000如果直接用 BiLSTM 不截断很容易发生梯度累积问题。建议统一截断到 300 或 500 token超过部分丢弃不够的用 0 补齐。另一个导致验证集准确率不佳的原因是标签类别映射混乱。标注时如果用了“0 表示负面、1 表示正面、2 表示中性”模型输出层也必须是同一顺序。我在一个项目里见过标注和模型输出顺序颠倒准确率一直在 40% 左右徘徊查了半天才找到问题。6.3 部署和演示现场的救命技巧毕业设计最怕的事就是答辩现场出各种环境问题。这里有几个可以提前规避的技巧把所有依赖提前打包成 requirements.txt并在答辩前在一台干净机器上跑一遍完整流程。有些同学在自己电脑上能跑换台机器各种缺包现场直接翻车。如果答辩用教室电脑尽量把系统做成浏览器访问模式避免现场安装 Anaconda、CUDA 等环境。或者把模型部署成本太低成本的 Web 服务让演示只需要打开一个网页。提前准备测试文本。准备三五条典型新闻比如一条明显正面的科技突破新闻、一条明显负面的灾害新闻、一条中性政策新闻现场把这些文本输入系统预测结果必须稳定。模型文件不要用检查点方式保存直接把经过验证的 best_model.pt 导出成一个文件并写一个单独的 predict.py 来加载它。因为 torch.load 在默认模式下可能会遇到类定义引用问题单独写脚本虽然多几行代码但比在服务器上临时调试安全得多。6.4 图表不显示或数据显示为空可视化模块最常见的错误是前端拿不到后端数据。排查顺序是先打开浏览器开发者工具的 Network 面板看接口有没有返回 JSON再确认返回的 JSON 里字段名和前端取数逻辑是否完全一致比如后端返回 sentiment_label前端写成 label这副不亚于一个严肃 bug。最后检查 ECharts 初始化时是否在 DOM 元素加载完成之后执行否则图表容器高度为 0图自然不显示。另一个问题是词云里的中文不显示这种情况通常是 pyecharts 版本和全局字体配置问题。可以不用自定义字体直接设置全局字体为宋体或微软雅黑并把词云图片保存为 SVG避免字体渲染差异。我从做过的类似项目里总结出一个原则无论是代码、文档还是答辩所有东西都要在演示当天提前完整走一遍。毕业设计里最贵的不是代码而是“确定性”。把环境影响降到零你就赢了大多数临时抱佛脚的同学。最后再分享一点个人体会做这个题目最让我收获很大的不是模型训练本身而是把一堆杂乱新闻变成可视化图表的完整过程。刚开始我也走了弯路花了很多时间想去调出一个完美模型后来才意识到毕业设计考察的是工程闭环能力和表达逻辑。把数据流讲清楚、把模块边界划清楚、把演示流程跑顺这三件事做好了整个项目就在平均水平之上了。如果你还想让项目更有竞争力可以在最后阶段加两个小功能一个是保存每条新闻的预测置信度再做一个“置信度高频词”的分析观察哪些词让模型最笃定另一个是做简单的舆情预警当负面新闻占比或负面新闻数量在某个时间段突然上升时页面给出提醒。这两个功能代码量都不大但会让你的系统和“预测”两个字更加名副其实。做完这两个增强点再回过来打磨论文里的实验对比这个项目基本就圆满了。