企业官网建设流程全解析

注意：以下是一个关于计算机毕业设计项目的技术剖析与经验分享长文。

1. 项目解剖：舆情分析系统到底在做什么

毕业设计选“网络舆情分析”这个方向，这些年越来越常见，但很多同学一看到“大数据”“深度学习”这些词就先把自己吓住了。实际上，只要把这个题目拆开看，它的内核非常清晰：做一套能抓取特定事件相关讨论数据、能自动判断网民情绪倾向、能用可视化方式展示舆情演变过程的Web系统。我见过太多学生把精力浪费在“多模态”“知识图谱”这类炫技词上，结果连最基本的数据闭环都没跑通。所以这篇内容，我先把这套Django+Vue架构下的舆情分析系统从需求到答辩整个链路讲透，帮准备做类似题目的同学把骨架立起来。

先说清这套系统解决什么问题。传统的人工舆情监测，是让人每天去各平台搜关键词、看评论、手动汇总报告，效率低而且主观性强。毕设要做的事情，就是把这个流程自动化：系统定时去采集某事件下的公开讨论内容，接着对文本做清洗和结构化存储，然后调用深度学习模型判断每条文本的情感倾向（正面、负面、中性），再通过聚类和热度计算识别出事件讨论的子话题和演变趋势，最后在Vue搭建的前端页面上以榜单、趋势图、词云、情感占比图等组件呈现出来。用户还可以通过后台配置事件关键词，比如“某地城市形象宣传事件”（这里用虚拟事件举例，系统本身不绑定具体事件），系统就围绕这个关键词启动一轮采集与分析。

这个题目适合什么样的学生？如果你是计算机科学与技术、软件工程、大数据相关专业的本科生，想兼顾工程能力和算法展示，这个方向非常合适。它的优点在于：工程层面有完整的前后端交互和数据库设计，算法层面有深度学习模型的训练与调用，数据层面有爬虫采集与清洗，演示层面有大屏可视化，几乎覆盖了毕设答辩里评委最爱问的几大模块。相比纯管理系统（学生管理、图书管理这类），它的技术深度和话题度都高出一个档次；相比纯算法研究（发论文那种），它又不会让你陷在数学推导里出不来。一句话总结：它是一道“技术栈全面、工作量可见、答辩好讲故事”的经典题目。

但同时也得提醒一句：这个题目最大的坑在于数据获取的合法合规性。很多教程上来就教你去爬某博、某吧、某红书，这在毕设场景里是有风险的。后面我会专门讲一套稳妥的数据获取方案，这是很多学生栽跟头的地方，也是答辩时老师一定追问的点。

2. 技术选型背后：Django + Vue + 深度学习这套组合的逻辑

2.1 Django作为后端：为什么不用Spring Boot

很多学生纠结后端框架选Java的Spring Boot还是Python的Django。我的观点很直接：如果核心算法用Python写，那后端就没必要再引入Java，除非你对Java特别熟。Django的优势在于三点。

第一，它是“全家桶”式的框架，ORM、Admin后台、认证体系、序列化这些都是现成的，能省掉大量重复造轮子的时间。对于毕设这种短周期项目，这个优势是决定性的。你如果用Spring Boot，光搭权限和实体映射就要多花两三周，而Django的Admin后台甚至可以零代码生成一个数据管理界面，拿来演示“系统管理模块”特别方便。

第二，Python语言在数据分析和深度学习方面的生态是可以直接用上的。你写的文本清洗函数、情感分析模型、热度计算算法，全部可以以原生函数的形式挂在Django视图层或独立的服务层里，不需要跨语言调用。如果后端用Java，你就得用HTTP方式去调Python的推理接口，项目复杂度立刻上一个台阶。

第三，Django的ORM对毕设级别的数据量完全够用。舆情数据一天几十万条已经算很多了，而Django配PostgreSQL做索引优化后处理这个量级的数据没有任何问题。有些同学一听到“大数据”就想着上Hadoop、Spark，这就是典型的过度设计——毕设评审看的是你有没有能力判断数据的真实规模，而不是看你敢不敢堆组件。

2.2 Vue作为前端：大屏可视化的正确打开方式

前端选Vue而不是React或传统JSP，核心原因是Vue生态里有非常成熟的中后台方案和可视化组件，搭页面速度快，而且招聘市场上的认可度也高。我推荐用Vue 3 + Element Plus + ECharts这套组合。

舆情系统的前端核心不是交互复杂度，而是信息展示的层次感。你要让用户一进页面就看出三件事：当前事件整体热度多少、正负面情绪占比如何、讨论焦点在哪里。这需要的是大屏仪表盘式的设计能力，而不是表单和列表的堆叠。ECharts在这套场景里是首选，它的词云图、南丁格尔玫瑰图、地图热力图、时间轴折线图都有现成示例，改改数据和配置就能用。Vue的响应式机制则让前端能实时反映后端分析结果的变化——后端分析完一批新数据，前端定时轮询或通过WebSocket推送更新图表，这种动态感在答辩演示时非常加分。

2.3 深度学习在舆情系统里的真实定位

这是我觉得最需要给同学们掰开揉碎讲的一点。深度学习在舆情系统里不是用来“装门面”的，它要解决两个核心问题：情感分类和话题聚类。

情感分类，就是判断一段文本是支持、反对还是中立。传统做法是情感词典打分，虽然也能跑，但泛化能力差——网络用语每天都在变，“绝绝子”“破防了”这种词老词典根本覆盖不了。深度学习模型的优势在于它可以捕捉上下文语境，比如“这波操作我看不懂”这种反讽表达，用词典法很容易判错，用模型就有机会正确识别。所以这里用深度学习是合理的，不是凑技术点。

话题聚类，就是在一大堆讨论文本中找到人们实际在聊的几个子话题。举例来说，一个事件可能同时包含关于涉事方行为的讨论、关于官方回应的讨论、关于当事人背景的讨论，这些不能混在一起算热度，得分开聚类再分别统计趋势。文本聚类这个方向用深度学习做通常是指先用BERT之类的模型把句子转成向量，再做聚类。这里有个经验之谈：对毕设来说，不一定非要上BERT，用TF-IDF加词向量融合，配合K-Means或DBSCAN，往往就能得到不错的效果，而且训练和调参成本低得多。深度学习要放在刀刃上，情感分类用深度模型，聚类用传统方法加向量化，这个组合是最务实的选择。

3. 系统架构与数据流转全链路

3.1 数据采集层的合法合规方案

先给一个严肃提醒：毕设涉及的数据采集，一定要避开用户协议明确禁止抓取的平台，也不要直接去踩需要用户名密码登录才能访问的后台接口。这不是小题大做，这个领域近年来的监管边界越来越清晰，答辩评委也非常关注你是否具备合规意识。一套稳妥的思路是：优先使用平台提供的开放接口，如果接口权限不够，则通过公开的搜索页面以正常用户速率获取公开可见的内容摘要，并且明确在论文中声明“仅用于学术研究、数据量有限”。

数据源怎么选也很关键。我的建议是不要只盯着一两个平台，而是选三类数据源做融合：一类是新闻门户的公开评论接口（这类内容规范、情感表达明确，适合作为情感模型的训练语料）；一类是问答社区和论坛的公开帖子列表（适合做话题聚类）；还有一类就是你自己通过调研问卷等形式采集的小规模标注数据（适合做模型验证）。这种多源组合的好处有二：一是降低单个数据源平台政策变动导致系统瘫痪的风险，二是让你的论文“数据来源”章节有的写。

采集模块在工程上最好做成可配置的。我在这个项目里建议用后端定时任务加采集代理的方式：Django的Celery Beat负责周期性触发采集任务，每个采集器是一个独立的Python类，输入是事件关键词和采集数量上限，输出是统一格式的JSON数据。为什么要用Celery而不是直接用定时器？因为采集任务往往耗时较长，如果同步跑在Web进程里，用户前端请求会一直阻塞，体验非常差。Celery把任务放到后台异步执行，用户只管看进度条，任务是死是活都有日志可查。这个细节属于“做了没人在意、不做必被扣分”的类型，但答辩时你主动提出来，印象分立刻不一样。

3.2 数据清洗与存储：决定分析质量的隐藏工程

很多人忽视清洗环节，直接把采集到的原始文本丢给模型做分析，这是系统跑偏的根源。我见过一个案例：某学生分析一个事件的情感倾向，因为没做清洗，大量营销号的重复转帖把“中性”标签的比例拉到了80%，整个情感分析模块完全失去参考价值。清洗至少要做四件事：去重、去噪、格式归一化和敏感信息过滤。

去重是舆情场景特有的难题。同一个内容可能被多个账号改写转发，直接去重会丢掉讨论热度信息，不去重又会造成数据倾斜。我的方案是“两层去重”：完全相同的文本用哈希去重；高度相似的文本用局部敏感哈希（SimHash）近似去重，相似度超过阈值的合并为一条原始数据但保留转发次数权重。这样热度计算既不失真，又不会被垃圾数据灌水。

存储层面我推荐MySQL加Elasticsearch的组合。MySQL存用户、事件配置、分析报告等业务数据；Elasticsearch存采集到的文本和分析结果，因为后面要按时间范围、关键词、情感标签做组合检索，ES的倒排索引在这种场景下比MySQL的LIKE查询快一个数量级。这两者都通过Django的ORM或官方客户端接入，代码复用度很高。如果你对ES不熟，也可以用PostgreSQL的全文检索功能替代，效果接近，部署简单很多。

3.3 分析与展示的对接方式

分析结果怎么送到前端，这是个看似不起眼但直接影响演示效果的问题。我的建议是设计两种数据出口：实时结果和周期报告。

实时结果走RESTful API。采集和情感分析的任务完成一部分，就通过Celery的回调更新数据库里的分析表，同时给前端推一个WebSocket通知或者让前端5秒轮询一次，图表自动刷新。周期报告则是每天定时生成一份事件舆情日报，内容包括当日新增讨论量、情感占比变化、热度峰值时段、Top子话题列表，以JSON形式存储，前端在“历史报告”页面展示。

在对接上有一个重要经验：深度学习模型的推理速度较慢，千万不能让前端请求直接同步等待模型推理。正确做法是在模型推理前先给前端返回“任务受理”状态，推理完成后主动推送结果。这套异步思想在舆情系统里是必须体现的设计亮点。

4. 核心模块实现与关键参数

4.1 热点检测：如何量化“事件热度”

热点检测要做的事情是回答“这件事在某个时间点有多受关注”。我的实现方式是三个维度的加权融合：讨论量（一定时间内采集到的相关文本数）、参与度（去重后的独立用户数）、传播速度（当前时间窗口讨论量相对上一窗口的增长率）。公式可以简化成下面这样：

热度值 = 0.4 × 讨论量分 + 0.3 × 参与度分 + 0.3 × 传播速度分

三个分项都做Min-Max归一化到0到100。这里有个关键参数——时间窗口的选择。窗口太短（比如5分钟），数据量少，波动剧烈，看不出趋势；窗口太长（比如24小时），又丢失了实时性。我反复调下来，取1小时作为基本窗口、4小时作为趋势窗口比较合适。事件刚爆发时你会发现传播速度这一项贡献了大部分热度值，因为基数小但增速快；进入平稳期后则是讨论量占据主导。这个设计在答辩时可以主动演示：用系统自带的事件数据模拟功能，输入一个冲高回落的序列，让评委看到热度曲线从爬升到见顶再到回落的完整形态。

子话题发现我前面提过用向量化加聚类。具体做法是把每条文本清洗后输入一个轻量级句子向量模型（这里不要求特别高精度，选择通用Sentence-BERT类的模型即可），得到768维向量，然后降维到50维后用DBSCAN聚类。为什么要降维？因为高维空间下距离计算噪声大、聚类不稳定，降维后簇的形状更紧凑。DBSCAN的好处是你不需要预先指定聚成几类，它靠密度自动发现簇的形状，这点很契合事件的子话题天然不确定数量的实际情况。我调参时把eps设为0.5、min_samples设为5，聚类效果比较理想。参数在配置文件中暴露出来，答辩时能讲出调整逻辑，这又是加分项。

4.2 情感分析：模型选型与训练细节

情感分析是这套系统里最核心也最容易被问出漏洞的模块。这里我把训练细节完整展开。

模型选型，我建议在TextCNN和BiLSTM之间选一个作为基线，再用预训练模型做对比实验。TextCNN结构简单、训练速度快、在短文本分类上表现稳定，适合作为基准模型。BiLSTM能捕捉长距离依赖，但训练慢、调参复杂，我把它作为对比模型。如果时间允许，再用开源的预训练中文模型做一次微调作为性能上限参考。论文里有三个模型的对比数据，答辩时说服力会强得多。

训练数据的获取是关键。直接使用网络评论作为训练集是不行的，因为缺少标注。我的做法是分两步构建：第一步从公开开源的中文情感数据集（酒店评论、电商评论这类公开数据集）选一批数据作为基础训练集，这部分数据量足够让模型学到基本的情感表达模式。第二步从自己的数据源里抽一小部分，按正面、负面、中性三类人工标注，补进训练集做领域自适应。比如你要分析的是某虚拟社会热点事件，网络用语大量使用表情符号和梗，通用模型容易误判，补齐这部分标注数据后准确率平均能提升6到8个百分点。

训练参数上，请直接参考以下配置作为起点：优化器用AdamW，学习率设为2e-5，batch size设为32，max sequence length设为128，训练轮数设为3到5轮。学习率这一步特别说明：如果直接用默认学习率去微调预训练模型，loss很容易震荡甚至飞掉。用2e-5这样的低学习率是业内通用做法，因为预训练模型本身已经收敛，你只是让它去适应新任务，步子不能迈大。如果你的数据量小（几千条），建议只微调模型顶部的分类层，冻结底层的编码器，这样可以减少过拟合风险。

最后要加一个置信度阈值设计。模型输出的是每个类别的概率，我设置预测置信度低于0.6的样本统一归入“中性或待定”类别。为什么要这么做？因为舆情数据里大量是表达模糊的片段，硬给它们贴上正面或负面标签反而会让统计分析失真，不如单独归为一类，在展示时用“观点明确率”这个指标解释才会有说服力。

4.3 可视化大屏与交互细节

可视化层面要抓住几个核心组件做深做细，而不是堆砌图表数量。我在这个项目里重点做了四类视图：热度趋势图、情感占比玫瑰图、子话题气泡图、关键词词云。

热度趋势图用ECharts的折线图，横轴是时间、纵轴是热度值，同时叠加一个“观点明确率”的堆叠面积图，一眼能看出事件热度变化和讨论质量的关系。情感占比玫瑰图比普通饼图好在视觉冲击力强，南丁格尔玫瑰图的扇区角度一致、半径代表数值，正负情感占比的差异会很直观。子话题气泡图用ECharts的Scatter加气泡大小映射讨论量，气泡的位置用聚类中心做二维坐标映射，这里需要把DBSCAN的高维聚类结果通过t-SNE降维到二维，才能得到可视化上有意义的分布效果。

前端代码在Vue中的写法并不复杂，核心是数据请求和配置更新。一个大致的示意逻辑是：图表组件接收trendData这个props，内部watch数据变化然后调用ECharts实例的setOption方法做增量更新。我实践下来特别要提醒一个点：ECharts的图表实例一定要在组件卸载时调用dispose销毁，否则在Vue路由切换的过程中会报内存泄漏的警告，答辩演示时页面上弹出红色报错，那场面会很尴尬。

词云组件也不建议自己造轮子，用现成的ECharts词云扩展就能跑。它需要注意的是文本清洗——如果不去掉“了”“的”“吗”这类停用词，词云里最大的几个字全是语气助词，毫无信息量。这个坑我几乎每个项目都会踩一遍，所以后来我在清洗模块里专门画了一个停用词表的维护函数。

5. 答辩实战：如何把项目讲得又深又稳

5.1 答辩演示的黄金流程

答辩现场最忌讳的是从头到尾咔咔点页面、不解释设计逻辑。评委一天看十几个项目，你如果上来就展示页面，他根本不知道你想表达什么。我建议的演示流程是三段式：讲痛点、跑链路、亮数据。

讲痛点，用两分钟说清楚“人工监测舆情为什么低效”，以及你的系统把哪些环节自动化了。这里的要点是你要展现出“系统是为了解决问题而做的”，而不是“我会这些技术所以我拼了一个”。

跑链路，是全场唯一的演示机会。你先打开事件配置页面，输入一个虚拟事件的关键词（比如“某虚拟音乐节舆情分析”这种无关敏感话题的例子），然后把后台采集任务打开，现场展示数据入库、清洗、模型推理、结果更新这条链路。这里建议提前准备两批数据：一批小数据用于现场演示（几秒出结果），另一批大数据在答辩前提前跑完，演示后用对比口吻说“刚才运行的是实时增量更新，目前系统里已经积累了数万条历史数据的分析结果”。

亮数据，就是展示分析报表和可视化图表。每切到一个图表，都用一句话解释它的业务含义，比如“这张图里可以清晰看到凌晨2点到6点讨论量是低谷，结合子话题气泡图可以发现这段时间的主要讨论焦点是事件后续产生的衍生信息，而不是事件本身进展”。这种跨图表的关联解释能力，是评委判断你是否真正理解系统的关键。

5.2 高频问题与应对思路

列举我在模拟答辩和实际围观中见过的高频问题，按出现概率排个序：

“你的数据量这么小，能叫大数据吗？”这是最容易被问的问题。回答思路不能是狡辩，而是正面承认并解释系统架构的扩展性。你回答时说：“毕设场景下数据量有限是事实，但系统设计时采用了分层的Celery任务队列和Elasticsearch集群化的存储方案，理论上可以通过横向扩展节点数量支撑更大数据规模。同时，深度学习模型的训练不依赖采集到的数据量，而是使用公开数据集加迁移学习，所以大数据的体量主要体现在处理流程的架构设计。这个回答既展示了你的系统设计意识，又避免了技术空洞。”

“深度学习模型如果遇到完全没见过的网络新词怎么办？”这是个极好的问题，因为几乎所有的网络舆情项目都会遇到。回答有三层：第一层，模型输入层加入了分词器的动态词表扩展机制，出现新词时先查自定义词典；第二层，系统设计了“未登录词反馈循环”，当模型预测置信度低于阈值时，会把文本打上新词候选标签，采集后台定期人工确认后加入词典；第三层，在训练环节，每隔一段时间用增量数据对模型做二次微调，这就是前面提到过的领域自适应。这三层说出来，评委立刻会认为你是真正跑过这套系统的。

“情感分析准确率多少？为什么可信？”对准确率数字不要虚报。你直接展示实验记录表：TextCNN准确率88.2%、BiLSTM准确率89.5%、预训练模型微调后准确率92.7%，再补一句：“实际线上运行中因为遇到大量口语化和反讽表达，我们通过置信度阈值策略放弃了约15%的低置信样本，剩余样本的估算准确率在93%左右，以换取分析结果的可靠性，这也是舆情分析服务落地时的常见取舍。”这个回答里“取舍”两个字是核心。

5.3 给自己留的加分细节

答辩时主动讲出来但不过度炫耀的小细节，往往能形成评审的记忆点。我这里列几个成本低、回报高的：

第一，项目里所有定时任务都有日志留痕。Listen的收集模块每完成一次采集，都会在后台记录采集耗时、新增数据量、重复率、清洗丢弃率四项指标。这个日志面板在前端的“系统监控”页面可见。评委看到的不是一句“系统稳定”，而是一个完整可追踪的运行体系。

第二，为演示准备一个“故障恢复”小脚本。答辩时如果评委问你系统挂了怎么办，你可以现场演示：手动停掉Celery进程，再启动，前端页面显示任务状态从失败恢复为运行中，历史数据不丢失。这个场景是用Celery的持久化任务队列实现的，代码量很少，但画面说明力极强。

第三，在论文结论里写出“系统局限性”，比如未支持多事件并行分析、未支持跨平台实时对比等。别小看这一小节，这是很多学生不敢写或者忽略的地方。坦诚地写局限性，反而让前面的工作更可信。

6. 踩坑实录与经验速查

6.1 采集阶段：机器人检测与数据质量

很多平台对高频访问有风控机制。我踩过的坑是：用单线程循环去抓公开页面数据，抓了十分钟就被限流，IP被临时封禁。后来改成两个策略：第一，把采集请求频率控制在“人类浏览速度”范围内，每两次请求间隔8到15秒的随机延迟；第二，把采集器设计成可暂停可恢复的断点状态，每批次任务结束把游标存到数据库，下次从断点继续。这两条策略让我的采集任务稳定跑完整个毕设周期。

更隐蔽的一个坑是数据质量的不均衡。搜索结果页前几页往往被高热度讨论占据，往后的讨论热度递减，如果你只采集前几页，分析出来的情感分布会严重偏向高热度内容。我后来强制设定每个关键词的采集配额覆盖多个搜索页，并且记录每条数据在搜索结果中的排位，把它作为“曝光权重”加入热度计算。这个细节让我情感分布的可信度大大提升。

6.2 模型训练阶段：显存、过拟合与切词

如果笔记本显存不够跑预训练模型，我建议直接用在线平台或者云端GPU的免费额度，没必要因此放弃预训练模型。模型微调时显存占用大概在5到7GB，GTX 1660 Super级别以上的卡都带得动。如果你的环境只有CPU，那就果断放弃预训练模型路线，用TextCNN加Word2vec词向量，照样能跑出82%以上的准确率。

过拟合是另一个高频问题。我在标注数据只有几千条时，用BiLSTM训练到第7轮后验证集准确率停滞、训练集准确率接近100%，这就是明显过拟合。解决办法是加早停机制（Early Stopping）：验证集loss连续3轮不下降就停止训练，同时把dropout提到0.5。这两个小改动让最终模型的泛化能力提升了一个小档。

切词环节也有讲究。纯用默认词表分词，“新冠”“疫苗”“核酸”这类领域词会被拆碎，情感判断失去语境。正确做法是在训练前准备一个领域词表文件，用分词器的add_word方法把这些词固化进去。我亲测一个例子：“绝绝子”不加入词表会被切分成“绝”“绝”“子”，模型根本看不懂，加入词表后情感分类直接判正面，准确率立竿见影。

6.3 前后端联调与部署阶段的坑

前后端联调里最常见的坑是跨域问题。Vue开发服务器跑在8080端口，Django跑在8000端口，不一致就要处理跨域。用Django的django-cors-headers库配置允许的域名白名单就能解决。但我要强调一个细节：不要把CORS设置成允许所有来源，答辩时安全问答题你会答得心虚。正确做法是把Vue应用的实际地址和维护环境地址写进CORS_ALLOWED_ORIGINS。

部署阶段我推荐直接用Docker Compose编排Django、Celery、Redis、MySQL、Elasticsearch和Nginx六个容器。这个方案的好处是答辩时如果评委想看系统运行环境，你一行docker compose up -d就能把整个系统拉起来，这比在本地装一堆环境要干净得多。部署中要注意两个细节：一是Django的DEBUG变量在生产模式必须设为False，否则会直接暴露内部错误堆栈；二是Celery的任务结果要避免存默认的内存后端，改存Redis，这样任务执行记录才能保留下来供系统监控页面展示。

同步数据推送那里也有个坑：如果直接让前端用原生WebSocket连Django，遇到消息格式变动非常痛苦。建议用Django Channels封装好WebSocket协议，后端统一推送JSON格式的消息体，前端订阅固定频道，双方约定好字段命名，这样联调难度会大幅下降。

6.4 快速排查表：常见运行异常一句话定位

在系统运行的过程中，无论是自测还是答辩前预演，这套排查逻辑可以帮你迅速定位问题：

这套速查表高度实用，你直接拿去当进度自查清单也行，答辩前跑一遍也踏实。

7. 项目升华：做完之后还能怎么用

这个项目做完之后，嘲讽余地其实很大。比如前端报表模块可以扩展成移动端适配，把大屏换成一套移动版简报，便于“身在别处也能随时关注事件走势”。再比如情感分析模型可以换成语种更丰富的预训练模型，用来分析外文讨论数据。还有些同学会往里加“意见领袖发现”功能，就是通过转发网络中的入度出度计算找到讨论关键节点，这个算法能够为舆情分析增加从“整体情绪”到“关键传播人”的分析视角。

如果用这个项目去参加一些创新类实践评选，建议以“事件演化的全周期视角”作为包装主线，而不仅仅是“实现了一个情感分类”。评委会更关注系统层面的分析与思考，比如你如何把数据采集、存储、建模、可视化串成一条职责链，以及在做舆情研判的时候应该更看重哪些指标——这个问题正确答案是“不要只盯情感比例，更要盯观点明确率与子话题迁移”，因为前者只告诉你人们态度冷暖，后者才告诉你事件真正的演进方向。

我个人在实际操作中的体会是，毕设项目最怕的不是技术难题，而是逻辑断裂。你今天会写爬虫，明天会调模型，后天会画图表，但每一步都独立成块、串不起来，最后做出来的东西就是一个技术零件集合，不是一个系统。舆情分析项目的魅力恰恰在于，它逼着你在“数据—算法—产品”这条链上做取舍：为了响应速度牺牲一点模型精度，为了展示效果重新设计数据聚合方式，这些都是教科书上不会写的真实工程决策。这些取舍你都经历过一遍，答辩时你根本不需要背稿，因为评委问的每一个问题，都是你脑子里已经过过一遍的真实项目细节。祝各位答辩顺利，项目落地成优秀毕设。