企业官网建设流程全解析

毕业设计里经常有一类题，叫“微博舆情分析系统”。很多同学拿到题目后的第一反应，是找一份现成源码，改个logo就交差。但答辩时老师只要追问一句“情感分析是怎么做的”“预测模型为什么选这个”，现场就会冷场。这篇内容不想只给一个能运行的demo，而是把基于Python+Django的短文本社交平台舆情分析与趋势预测系统，按照真实开发顺序拆开讲：数据采集、清洗与情感计算、趋势预测、Web展示，再到源码、文档、PPT和讲解视频怎么准备。你会看到我在每个环节做过的取舍、踩过的坑，以及哪些地方最容易被追问。

1. 开工前先拆需求，别让系统只剩爬虫

1.1 先定义你必须回答的四个问题

我见过不少舆情项目的初版源码：爬虫单独写了几个脚本，数据塞进SQLite，再用ECharts拉两个统计图就结束了。这种项目确实能跑，但整个产品的“分析”价值很弱。做这套系统之前，我先把“舆情分析”拆成了四个必须回答的问题。

第一，一个话题在某段时间内被讨论了多少次，趋势是在上升还是下降。这是最基础的热度判断，对应到系统里就是“话题-时间-发帖量”的聚合统计。第二，这些讨论里正面、负面、中性各占多少，转折点出现在什么时候。这需要文本情感识别，并且要把时间维度叠加进去，才能看到情绪变化。第三，大家围绕哪些关键词在说话，高频词和情绪倾向有没有关系。这对应关键词提取和共现分析。第四，基于历史数据，未来24小时的热度和负面占比大概率会是什么水平。这一块就是舆情预测模块，也是毕业设计里最有区分度的部分。

如果你把这四个问题当成验收标准，会发现很多“源码”根本不合格。比如只做了爬虫和饼图，没有预测；或者预测只是套了一个LSTM，但特征只有一条发帖量序列，训练集和测试集混在一起。答辩时老师特别容易抓住这些漏洞。所以项目的起点不是“我该用哪个爬虫库”，而是“用户打开页面后，到底能回答哪些问题”。

1.2 模块划分与数据流向

按照上面的四个问题，系统自然被拆成这几个模块：数据采集、文本预处理、情感分析、舆情预测、展示与接口。每个模块的边界越清晰，后期Django整合就越省事。

我当时画了一张模块表，内容和下面这张差不多：

数据流向也很直接：爬虫把文本写入原始表，清洗脚本产出标准语料，分析脚本把情感分数和聚合指标写回数据库，预测模块读取最近N天的指标做时间序列建模，展示层通过Django接口读数据并渲染图表。这条链路一定不能断。很多项目失败，就是因为中间某个字段没有落库，导致后面只能用一次性脚本算，页面刷新一次就要重跑一次全部模型。

我当时还有一个心得：先花一天把表结构定下来，再写爬虫。磨刀不误砍柴工，后面几乎没返工。

2. 采集层：开放接口、页面解析与合规优先级

2.1 采集方式别一上来就怼Selenium

很多同学做爬虫，第一反应就是Selenium开浏览器硬抓。但短文本社交平台的数据采集，最忌讳一上来就写重度自动化脚本。效率低不说，还容易触发风控。我对三种采集方式做过对比，最后按优先级排列：开放接口第一，页面解析第二，公开数据集当作补充。

我实际采用的策略是这样的：以开放接口抓正文、发布时间、点赞数、评论数和转发数；只对缺失的字段做页面解析，而且每秒最多请求1到2次，间隔加入随机延迟。另外，像验证码、滑块、账号风控这类机制，我明确不碰。做毕业设计完全没有必要为了多抓几千条数据去冒合规风险，更不值得把自己机器IP搭进去。

合规性一定要写进文档里。老师很看重这一点，能不能讲清楚“我在采集时怎么遵守平台规则”，比你爬了多少万条数据重要得多。

2.2 数据表设计要顺着分析指标走

我一开始犯过一个错：把爬到的数据全部拼成一个JSON字段塞进数据库。结果统计“每小时发帖量”的时候，要从JSON里一层一层拆，又慢又痛苦。后来所有核心字段都用了独立列。

帖子主表至少要包含这些字段：内容、话题、发布时间、作者id、点赞数、评论数、转发数、情感极性、情感分数。用户表可以存昵称、粉丝数、认证状态，后面做影响力分析时会用到。评论表可选，但我建议保留，因为答辩展示时，评论里的观点比帖子正文更有说服力。

存储方面建议用MySQL，并设置成utf8mb4字符集，而不是图省事用SQLite。短文本平台的中文内容里有大量生僻字和表情符号，utf8mb4兼容性更好。数据量控制在1万条以内时，单机MySQL完全够用，不需要上Hadoop。但文档里可以提一句：表结构已经按分表方向预留了按时间分区的字段，这样显得你有大数据意识，又不会把系统做过度。

3. 文本清洗与情感分析：建立能讲清逻辑的舆情指标

3.1 清洗比选模型更影响结果

短文本社交平台的文本噪音，比例高得吓人。网页链接、@用户名、话题标签、表情符号、繁体字、英文混写、乱码，全都会混在一句话里。如果你不做清洗，情感模型的分词结果会非常离谱。

我设计的清洗管线顺序是这样的：第一步，去掉HTML标签和URL，不处理直接分词会把分词器弄乱；第二步，去掉@用户名，保留话题词，但话题词要单独提取出来作为关键词；第三步，统一简繁体，很多平台内容会是繁体或混排；第四步，按内容做精确去重和相似度去重，因为同一个热点会被反复转发，不拆掉会虚增热度；第五步，用jieba分词，过滤停用词和低频词。

这步看起来不起眼，但实测下来，去重和繁体转换对后续情感准确率的影响，可能比换一个更大的模型还明显。所以每次有人问我模型选什么，我都会先说一句：先把清洗跑扎实。

3.2 情感分析：词典打底，机器学习校准

如果你只有几千条未标注数据，直接上手微调语言模型并不现实，容易过拟合，而且答辩时很难解释训练过程。我更推荐三层组合方案。

第一层，先用一个中文情感词典给每个句子算基础分值。词典的方法虽然有瓶颈，但它能给每个词一个可解释的权重。第二层，用TF-IDF加逻辑回归训练一个三分类器，类别是负向、中性、正向。逻辑回归在这里合适，是因为训练快、可复现，而且能把重要特征词和对应的权重直接列出来，老师一看就明白。第三层，拿人工标注的一小批样本做验证。我当时标了差不多2000条，对比词典结果和模型结果，把不一致的样本捞出来人工复核，再回填到训练集里。

这样做出来的情感模型，准确率不一定比预训练大模型高很多，但它有一个毕业设计最需要的东西：可解释性。老师问“情感分数是怎么来的”，你可以直接打开一个词的权重表说清楚。这套组合也保留了扩展空间，后续如果数据量够，完全可以换成预训练模型，但那是加分项，不是这里的保底方案。

3.3 从单条情感聚合到舆情指标

情感值只有聚合之后才有业务意义。我把数据按“小时＋话题”两个维度聚合，生成三种指标：情感平均值，取值范围0到1；负面占比，计算负向样本在所有非中性样本中的比例；热度指数，对发帖量做对数变换，避免一个爆款帖把曲线拉得过陡。

有一个细节非常重要：单条帖子的情感分数在清洗阶段就要算好并写入数据库。后面的聚合、预测、图表展示全部直接读取这个字段，而不是页面每次刷新都重算一次。这样不仅快，还能保证整条链路的指标口径一致。否则你在热度图里看到的情感均值，和预测模块里用的情感均值可能是两套结果，答辩时直接翻车。

4. 舆情预测的简化策略：不要为了用模型而用模型

4.1 预测对象和特征工程

很多项目把“舆情预测”写成黑盒：输入历史帖文，输出未来趋势，但特征只有一条发帖量序列。这样做出来的预测往往不稳定，而且老师一问“为什么选这个模型”就答不上来。我在系统里把预测拆成了两个对象：热度预测，预测未来6小时或24小时的发帖量；情绪倾向预测，预测未来时段的负面占比或情感均值。

特征工程上，除了历史值，我还把“小时序号”和“星期序号”作为周期特征放进去。短文本平台有明显的活跃周期，比如晚饭后、睡觉前是高峰期，周日和工作日也有差别。再看滞后特征：过去3小时、6小时、12小时的平均情感值，这些能帮模型抓住舆情的惯性。如果只给单变量时间序列，模型很难学到这些规律。

4.2 模型选型：从基线到ARIMA，再到Prophet对比

先别急着上LSTM。短时序、样本量只有几百条，LSTM非常容易过拟合，而且调参过程很难在答辩时讲清楚。我首选的基线是简单移动平均，用处是兜底；第二步用SARIMA，它能表达小时级别和星期级别的季节性；如果数据周期比较稳定，我再跑一个Prophet做对照。

经验是：舆情类时间序列很少平滑到能稳定预测7天，预测24小时以内更靠谱。验证时一定要把数据切成训练集和测试集，用RMSE和MAE评价，并且要和“上一时刻不变”的基线做对比。如果模型跑不过基线，不如直接在界面上显示基线结果。这么做看起来不酷，但它在学术上更诚实。

4.3 预测结果在界面上怎么展示

预测结果展示有很多坑。最典型的一个，是把预测值和真实值连成一条曲线，看起来像未来已经被验证了一样。答辩老师看到一定会问：你确定未来真的这样走吗？

我的做法是，用虚线表示预测值，真实值用实线，两者之间有明显视觉区分。预测部分配上置信区间的阴影，并在图表标题旁标注RMSE。页面下方放一行说明：“预测结果仅代表模型推断，不作为决策依据。”这句话既严谨，又能让老师觉得你清楚模型的边界。

5. Django整合：从零散脚本到可演示的Web系统

5.1 项目结构、后台任务和缓存

把爬虫、分析和预测脚本整合进Django时，最忌讳把所有代码都堆在几个脚本里。我采用的分层结构是：一个config目录放settings和核心配置；四个应用分别叫crawler、analysis、prediction、dashboard，各管一段。这样后期改爬虫策略时，不会动到预测代码。

定时任务这一层，我推荐用django-apscheduler，而不是一上来就上Celery。毕业设计不需要消息队列，一个轻量后台调度器就够了。爬虫定期抓数据，分析脚本定期更新情感指标，预测模块定时重算未来趋势，都挂在同一个调度器上。

这里有一个稳定性的关键点：定时任务里不要跑同步的重量级模型。预测脚本一旦运行超过10秒，页面刷新就会被卡住。我的方案是把耗时任务全部放到后台线程，结果写回数据库或Redis缓存，前端只读取缓存好的聚合数据。页面访问自然就会很快。

5.2 接口设计与可视化面板

接口层我用Django REST framework提供三个核心接口：话题列表与热度数据、情感分布、预测结果序列。前端用Django模板渲染主面板，图表选ECharts，不需要引入太重的前端框架。

对答辩演示来说，最怕的不是功能不完整，而是现场网络慢、图表半天出不来。我把最近7天的聚合结果在每小时结束后预先算好，存入Redis缓存。用户打开页面时，只要命中缓存就直接展示；只有当天的实时数据没有缓存了，才重新计算。这样演示时图表基本能在2秒内出结果。另外，我还预留了一个“清缓存”按钮，方便在答辩现场重复演示时，随时触发重新计算。

6. 交付物怎么准备：源码、文档、PPT和演示讲解

6.1 LW文档/设计文档应该写多少，重点写什么

毕业设计交付里，源码是底线，文档才决定上限。所谓LW文档，很多人以为越厚越好，其实老师真正会看的是两部分：需求分析和系统设计。

需求分析不要写空话，要写清楚用户角色、功能清单、数据字典。比如帖子主表有哪些字段、每个字段的类型和含义，都要列出来。系统设计至少要画四张图：系统架构图、模块流程图、数据库ER图、关键流程时序图。技术选型部分，一定要写“为什么选Django、为什么用MySQL、为什么用词典加逻辑回归的情感方案”。写成对比表格，比大段文字更能体现思考。文档里要包含可复现的命令和配置，别人拿到你的文档，能一步步把环境搭起来，这才叫完整。

6.2 PPT和现场演示的节奏

PPT我控制在12页以内，核心逻辑是：问题背景、系统架构、三项关键技术、效果展示、不足与改进。每页只放一个结论，配一张截图，不要堆满代码。

现场演示时，至少预演两遍完整流程：从启动爬虫开始，到页面图表刷新，到查看预测结果，每一步都要真实操作，别用提前录好的视频替代。老师常追问的角度其实很固定：数据怎么保证实时性，情感模型怎么来的，预测用什么指标评价，数据量大了怎么办。这四个问题分别对应调度器、词典加分类器加人工复核、RMSE与基线对比、缓存和分表策略。你在文档对应小节里能快速找到答案，答辩就不会慌。

6.3 讲解视频和讲解稿怎么录

如果交付物里有详细讲解，录屏时不要只盯着代码讲，而是先讲整体流程，再跑一遍界面，最后翻文档。中间遇到报错也不要剪掉，直接讲原因，这反而显得真实可信。视频时长控制在10到15分钟，每1分钟左右讲一个点，节奏会舒服很多。讲解稿不要写成一字不差的逐字稿，列关键词和讲法就够了，否则念稿痕迹太重。

最后说一点真实体会：舆情分析系统的区分度，从来不在某个模型多亮眼，而在于整条链路是否闭环，每个环节能不能讲清楚取舍。我做完这套系统之后最大的感触是，爬虫、清洗、模型、展示单独拿出来都不难，难的是衔接处的细节。比如情感字段什么时候落库、预测曲线要不要标置信区间、定时任务怎么不卡页面。这些细节会在答辩时真正成为你的护城河。如果你也正在做类似题目，强烈建议先把需求和数据表设计做扎实，这部分想清楚了，后面基本不需要返工。