企业官网建设流程全解析

每年一到毕业设计选题季，总有一批人被“Python+大模型+舆情分析”这类关键词吸引。说实话，这个题目能流行是有道理的：技术栈完整、可视化效果直观、答辩时展示性强，而且从数据采集到模型部署每一步都能写进论文里当“工作量”。但真正动手做的人才会明白，这类项目最难的从来不是某一个算法，而是把“数据——分析——预测——展示”这条链路完整跑通。这篇就把微博舆情分析预测这个毕设题目从头拆到尾，从需求分解、技术选型，到爬虫、情感分析、趋势预测、可视化落地的完整实操，以及我在实际辅导过程中看到的典型坑，一次性说清楚。

1. 先把题目翻译成人话：这个毕设到底在做什么

讲真，很多同学拿到这个题目的第一反应是“我要做一个智能系统”。但你要是把题目拆开看，它其实是在要求你完成一个全链路的舆情分析闭环：从微博平台上抓取指定话题或关键词下的文本数据，对数据进行清洗和预处理，然后判断每条微博携带的情感倾向是正面、负面还是中性，再把这些情感结果聚合出舆情指数，用时间序列模型去预测未来一段时间内的情感走向，最后把整个过程的结果用可视化图表呈现出来。

为什么要拆得这么清楚？因为答辩时老师不会只盯着某一个模型问，他们更关注你对整个系统的掌控力。比如“你的数据是哪来的”“数据清洗做了什么”“情感分析的准确率如何评估”“预测模型为什么选这个”“可视化数据是怎么流转的”——这些问题全部指向同一个能力：你是否理解每个模块在整条链路中的角色。

1.1 表层需求与深层考点

从交付物角度看，题目要求的是源码、LW文档、PPT、讲解视频。源码不用说，是整套系统能跑起来的最基本保障；LW文档本质上是你把需求分析、系统设计、数据库设计、模块实现、测试结果这些过程按规范写下来；PPT和讲解则是答辩现场的门面。

但从深层来看，这个题目真正考察的是四件事：

• 数据获取能力：微博平台反爬比较严格，你要在不违规的前提下拿到足够量的数据，这考验你的工程能力。
• 文本处理与分析能力：中文分词、去噪、去除停用词、情感判断，这是NLP基础功。
• 模型应用与评估能力：无论是传统机器学习还是大模型API，你要能讲清楚准确率、召回率、F1值这些指标，并且知道如何提升。
• 系统集成与可视化能力：后端接口、前端图表、前后端数据流转，展示一个完整可用的系统。

说白了，这不只是一个“调包”项目，而是一个能让你把本科阶段学过的网络爬虫、数据库、数据分析、机器学习、Web开发全部串起来的大杂烩。也正是因为覆盖面广，每年才会有一批人选它作为冲刺优秀毕设的题目。

1.2 四个核心模块的职责边界

我习惯把这类系统切分成四个模块，这样无论做代码还是写文档，思路都会清晰很多：

这个划分本身就是论文里“系统总体架构”部分的雏形。代码里把每个模块拆成独立文件夹，文档里就对应每一章，答辩时讲起来也顺理成章。

2. 技术选型：为什么是Python+大模型，而不是传统方案

很多同学纠结“我到底用哪种情感分析方式”。这里我先把技术选型的逻辑捋一遍。你选的每一层技术，都要能回答一个问题：为什么选它，比其他方案好在哪？

2.1 Python生态在舆情分析里的统治力

这个题目叫“Python+百度千问大模型”，Python为什么是首选？原因很简单：从爬虫到数据分析到机器学习到Web后端，Python是唯一一个几乎全流程都能覆盖的主流语言。

爬虫环节有requests、Scrapy；文本处理有jieba、snownlp、gensim；数据处理有pandas、numpy；时间序列有statsmodels、fbprophet；Web展示有Flask、Django；可视化有pyecharts。这意味着你不需要像Java那样在不同框架之间切换语言，也不需要像C++那样手写底层数据处理逻辑。对于要在几个月内独立完成整套系统的学生来说，Python是性价比最高的选择。

2.2 传统情感分析方案的三个局限

这里我必须说点实在的。在百度千问这类大模型接口普及之前，大家做微博情感分析基本就三条路：

• 情感词典法：维护一个正负情感词表，对句子里的情感词做加权打分。优点是简单、可解释性强；缺点是中文网络用语更新太快，“绝绝子”“yyds”“破防了”这些词在传统词典里根本没有，模型一遇到就失灵。
• 机器学习法：用朴素贝叶斯、SVM、逻辑回归等算法训练分类器。优点是不需要人工维护词表；缺点是需要大量人工标注数据，而且特征工程做不好时，准确率很难突破80%。
• 深度学习法：用BiLSTM、BERT等模型做序列分类。效果确实好，但对于普通学生来说，标注数据、训练调参、显卡资源的成本都很高，很容易陷入“训练三天两夜，准确率还低得没法看”的尴尬局面。

所以当有同学来问我“用传统方法还是大模型”时，我会告诉他：这不是二选一，而是可以组合着用。传统方法作为兜底和对比，大模型作为核心情感判别引擎，这样既有工作量又有创新点。

2.3 百度千问大模型在这个项目里的合理定位

百度千问大模型（这里按题目陈述的第三方模型接口理解）在项目中的价值，主要集中在两个方面：

第一，少样本情感判别。你不需要自己标注几千条数据训模型，只需要给它几条示例，它就能按照示例的格式返回情感标签。比如构造一个prompt，告诉它“请判断以下微博内容的情感倾向，只回复正面、负面、中性三种结果”，实测下来对常规文本的把握比传统词典法高一个档次。

第二，观点抽取与摘要生成。除了判别情感，你还可以让大模型提取每条热门微博的核心观点，或者对一段时间内的舆情做摘要总结。这些内容能直接丰富你的可视化页面，让项目显得更有“智能感”。

但要提醒一点：不要把全部判断都交给大模型。因为API调用有成本限制，而且对于大量短文本逐条调用，速度和费用都不划算。更稳妥的路线是分层架构：先用情感词典或者轻量模型做初筛，把置信度高的样本直接判定；把置信度低、包含反讽或网络新词的复杂样本交给大模型做二次判别。这样既省资源，准确率也稳。

2.4 预测模型选型：ARIMA、Prophet还是LSTM

情感预测是整个项目里最容易翻车、也最容易被老师追问的部分。我的建议是：首选ARIMA或者Prophet，别一上来就碰LSTM。

说说原因。ARIMA是经典的时间序列模型，原理清楚、实现简单、可解释性强。你只需要把每天的舆情情感指数整理成时间序列，做平稳性检验、差分、定阶，然后就能预测未来几天的走势。它的局限性在于只能捕捉线性关系，对突发事件的反应比较迟钝。但对于毕设来说，解释清楚ARIMA的原理和流程，已经能拿到不少分了。

Prophet是时间序列预测的“傻瓜神器”，它对周期性和节假日做了内置处理，调参少，拟合效果好。微博数据的日维度情感指数天然带有周周期性（周末和工作日讨论同一个话题的情绪分布会不同），Prophet恰好能把这些周期分量拆出来。

LSTM则是看着高大上、实际上很容易让初学者怀疑人生的选项。它对数据量要求高、对超参数敏感、训练时间长，如果效果不好，答辩时很难解释清楚。除非你的数据集有几万条以上，并且你有充分的时间调参，否则不建议作为主模型。作为对比实验倒是可以的。

3. 实操全流程：从爬虫到可视化一步步落地

这一部分我把自己在实践中总结出的可复现流程写出来，每一节都有可以直接“抄作业”的要点。

3.1 微博数据采集：合法合规与反爬策略

先强调一件事：爬取微博数据做毕设，只限于学术研究，不要拿它去做什么商业用途，也不要采集敏感话题。

技术实现上，微博有开放API，但个人开发者申请权限门槛较高，而且配额有限。所以很多毕设项目采用的方式是模拟网页端请求。以微博移动端搜索接口为例，我们需要做的是：

• 设置合理的请求头，包含User-Agent、Referer、Cookie。
• 模拟关键词搜索，翻页获取结果列表。
• 从返回结果中提取微博正文、发布时间、转发数、评论数、点赞数、博主信息等字段。

下面是一段简化版的采集思路（基于常见实践补充）：

import requests import pandas as pd def fetch_weibo(keyword, pages=5): headers = { "User-Agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X)", "Referer": "https://m.weibo.cn/", "Cookie": "你的登录Cookie" } results = [] for page in range(1, pages + 1): url = "https://m.weibo.cn/api/container/getIndex" params = { "containerid": f"100103type=1&q={keyword}", "page": page } resp = requests.get(url, headers=headers, params=params, timeout=10) if resp.status_code == 200: cards = resp.json().get("data", {}).get("cards", []) for card in cards: if card.get("card_type") != 9: continue mblog = card.get("mblog", {}) text = mblog.get("text", "") results.append({ "time": mblog.get("created_at"), "text": text, "reposts_count": mblog.get("reposts_count"), "comments_count": mblog.get("comments_count"), "attitudes_count": mblog.get("attitudes_count") }) time.sleep(2) # 避免请求过快 return pd.DataFrame(results)

核心注意事项：

• Cookie会过期。头一天能跑通的代码，第二天可能就返回登录跳转。建议代码里加上cookie过期检测，如果结果为空或者出现“请先登录”的特征，就提示手动更新Cookie。
• 频率要控制。每次请求之间至少间隔1到2秒，翻页数量不要一下子调到100页。这个项目不是要你把全网微博都爬下来，只需要保证每个关键词有几千条或者上万条数据就够了。
• 去重机制。同一关键词多页抓取会出现重复内容，要按微博ID做去重。

存储方面，如果数据量在几万条以内，直接用CSV文件就够，方便pandas读取；如果超过十万条，建议入MySQL。字段不需要太多，时间、文本、转发数、评论数、点赞数这五六个核心字段足够支撑后续所有分析。

3.2 文本清洗与中文预处理：决定模型效果的下限

爬回来的原始文本是带HTML标签的，比如sina:、<a href="...">网页链接</a>之类。如果不处理，情感分析模型会把“网页链接”这种噪声也算进去，严重拉低准确率。

我的标准清洗流程是：

• 去除HTML标签和转义字符。
• 去除URL链接。
• 去除@用户名和“#话题#”两端的井号（但话题词本身可以保留，它是很好的关键词素材）。
• 去除多余的空白字符和换行。
• 繁体转简体。
• 表情符号处理：微博文本里经常有emoji，直接去掉会丢失情感信息。建议把emoji转换为对应的文字描述，比如笑脸→“开心”，哭脸→“伤心”。

清洗完之后是分词。我一般用jieba分词，并做两件事：加载自定义词典和去除停用词。自定义词典里要加进当前项目涉及的话题词、网络热词，比如“破防”“内卷”“躺平”等。停用词表可以直接用现成的中文停用词表，但要小心：像“不”这种否定词不能进停用词表，否则“不高兴”会被切成“高兴”，情感极性直接反转。这种细节看起来小，却直接决定情感分析的下限。

3.3 情感分析：词典初筛与大模型精判的组合方案

这才是整个系统的灵魂。我建议的架构是这样：

第一层：轻量初筛。用情感词典给每条文本打一个情感分。常用的方案是加载大连理工大学的情感词汇本体库，或者知网的情感词典。逻辑实现不难：

# 简化版词典打分逻辑 def sentiment_score_by_dict(text, pos_words, neg_words, degree_words): words = jieba.lcut(text) score = 0 for i, word in enumerate(words): if word in pos_words: score += 1 elif word in neg_words: score -= 1 # 程度副词加权，如“非常”“很”“稍微” if i > 0 and words[i-1] in degree_words: score *= degree_words[words[i-1]] return score

第二层：大模型精判。设置一个阈值，比如词典得分在-1到1之间的样本视为“不确定样本”，把它们抽取出来批量调用百度千问接口。这样做能大幅减少API调用量。我这里给出一个常见的prompt设计示例：

• 你是一个专业的微博舆情分析助手。
• 请判断下列微博文本的情感倾向。
• 只允许输出三种结果：正面、负面、中性。
• 请按JSON格式返回：[{"text": "原文", "sentiment": "正面/负面/中性", "confidence": 0.8}]

这里有个细节：一次请求可以塞多条文本，比如10条、20条，让大模型批量返回。这样既节省调用次数，又能保证每条文本都经过理解式判断。

第三层是结果融合。词典高置信度样本直接用词典结果，低置信度样本用大模型结果。最后可以按“正面=1、中性=0、负面=-1”的规则把情感标签转化为数值，便于后续聚合。

3.4 舆情指数计算与趋势预测

有了每条微博的情感值之后，要按天聚合。我常用的做法是计算日平均情感值和日情感倾向占比：

• 日舆情指数 = （当日正面微博数 × 1 + 中性微博数 × 0 + 负面微博数 × -1） / 当日微博总数
• 这个指数范围在-1到1之间，大于0代表当日整体情绪偏正面，小于0代表偏负面。

聚合出的时间序列就是预测模型的输入。以ARIMA为例，实操中有几个容易踩坑的点：

• 做ADF平稳性检验，如果p值大于0.05说明序列不平稳，需要差分。差分阶数d一般是0或1，不要直接取2。
• 定阶的时候不要光看ACF和PACF图凭感觉，可以用赤池信息准则或者贝叶斯信息准则自动确定p和q的范围。
• 预测结果要画出来和真实值对比，计算均方根误差（RMSE）和平均绝对误差（MAE），这两个指标一定要写进论文里。

如果你用了Prophet，就简单得多，直接把日期列和情感指数列丢进去，设置好周期参数，它会把趋势、周周期、年周期都拆出来。在毕设答辩时，能把Prophet分解出的“趋势变化”讲得清楚，反而是加分项。

3.5 可视化大屏：别只会堆图表

可视化是这个项目最直观的加分项。我见很多同学花大量时间在美工上，其实方向错了。老师看的是数据有没有串起来。

推荐的技术组合是：Flask提供后端接口，输出JSON数据；前端用ECharts做图表呈现。至少要有这样几个页面或板块：

• 总览面板：显示关键词、数据总量、时间范围、正负中占比。
• 情感趋势图：按天展示情感指数折线，并叠加未来3到7天的预测结果。
• 词云图：把出现频次高的关键词做成词云，能直观看到大家都在聊什么。
• 热门微博排行：按转发数或评论数排序，展示影响力大的文本及其情感。
• 地域分布图（可选）：如果采集到用户所在地字段，可以在地图上做颜色映射。

注意一个关键点：可视化不是独立模块，它的数据源要和前面分析模块的输出完全一致。很多同学做到最后发现图表数据对不上，就是因为前面每一步分析之后没有统一保存数据中间表。

4. 常见问题与排查实录：这些坑我帮你踩过了

这部分是真正的经验所在。下面这些问题我在指导过程中反复看到，几乎每个做同类项目的人都会遇到。

4.1 爬虫抓不到数据或者被限制

很多同学的代码第一天跑得好好的，第二天就挂。排查顺序：

• 先看返回状态码。如果302跳转，说明Cookie失效，重新登录抓取Cookie。
• 如果状态码正常但数据为空，检查containerid参数是否正确，不同关键词需要拼接不同的查询参数。
• 如果请求频率太高，会触发限制。解决方案是随机sleep 1到3秒，并且准备一个IP代理池备用。

经验心得：爬取微博数据别追求速度，稳定比数量更重要。哪怕只爬5000条干净数据，也够后续分析了。多花点时间在数据质量上，后面模型的效果才会好。

4.2 情感分析结果和直觉完全相反

我在测试时发现，模型会把“这球打得太漂亮了”判断为负面，原因在于“漂亮”在某些情感词典里被标记为褒义词没错，但整句话还有“太”这个程度副词。更离谱的是网络用语和反讽，“就这？就这也叫作品？”会被词典法判成正面，因为里面没找到明显的负面词。

我的处理办法是：

• 扩充自定义情感词典，把项目相关领域的热词加进去。
• 对反讽和问句，交给大模型去判断，词典只处理常规表述。
• 做完之后一定要人工抽检50到100条，自己看一眼结果，计算一个简单准确率。这一步会让你对整个系统的效果心里有底。

4.3 大模型API调用超时、返回格式不对

接大模型API的时候，最容易出问题的是返回格式不稳定。你让它返回JSON，它偶尔会多回复一句“好的，以下是结果：”，然后才是JSON。直接json.loads会报错。

解决方案是：

• 设置超时时间，比如10秒，超过就重试。
• 对返回文本做截取，只解析包含JSON数组的部分。
• 用指数退避的重试策略：第一次失败等2秒，第二次等4秒，第三次等8秒，最多重试3次。
• 批量发送时，单批不要超过20条，否则容易触发单次请求长度上限。

4.4 预测曲线几乎是一条直线，或者误差巨大

这个现象很常见。原因主要是数据本身波动太大——微博舆情受突发事件影响明显，某天一个事件冲上热搜，情感指数直接断崖式下跌，ARIMA这类线性模型根本接不住这种变化。

我的应对思路：

• 如果预测结果是一条水平线，多半是序列平稳化之后白噪声占主导，说明数据里没有显著的趋势信息。此时可以换Prophet，或者把预测区间缩短到未来3天，而不是7天。
• 如果误差大，不要急着换模型，先看数据量够不够。少于30天的日粒度数据用任何时间序列模型都很难出效果。我建议至少爬取60天以上的数据。
• 另一种思路是预测“情感倾向占比”而不是“平均情感值”，负面占比的规律性往往比均值更稳定。

4.5 论文和答辩准备的实用建议

文档写作方面，架构图不要画得太复杂，一张系统总体架构图加一张数据流程图就够了。重点是把每个模块的输入输出写清楚。答辩时老师通常会问：

• 为什么用这个情感分析方法？——答：传统词典法无法覆盖网络新词，大模型结合词典精判兼顾准确率和成本。
• 预测模型为什么选这个？——答：该模型适合中短期趋势预测，已做平稳性检验并和基准模型对比。
• 系统的创新点在哪？——答：大模型与传统方法的结合、完整的分析展示闭环。

我建议你把测试过程和结果截图保存下来，包括爬到的数据样例、清洗前后对比、情感分析结果示例、预测曲线和真实值对比图。这些素材不仅论文要用，PPT上也放得下，而且比任何文字都更有说服力。

写在最后：这个项目的真正价值不在“调通API”

如果只是把大模型接口调通，加上图表展示，那这个项目的深度是不够的。我做下来最大的体会是，系统里每一个环节都可能出问题，而解决问题恰恰是毕设训练的核心。爬虫被限制，你要学会伪装请求和降低频率；文本噪声太多，你要学会清洗和特征处理；情感结果不准，你要学会词典与大模型的融合策略；预测效果不好，你要学会从数据本身找原因，而不是盲目换模型。

还有两个小建议：第一，代码从第一天起就做好模块隔离，爬虫、分析、预测、展示分开写，否则最后联调时改一处崩三处；第二，提前把依赖环境写进requirements.txt，并且保留一个能稳定运行的项目快照，不要在答辩前一天晚上临时升级任何库的版本。

最后再分享一个通用的小技巧：把情感分析结果、预测曲线、词云数据全部导出成带有时间戳的中间表，不仅方便调试，答辩时还可以直接展示“从原始数据到最终结果”的完整流转过程。很多时候，这条数据链路本身，比单个模型的准确率更能体现你的工程能力。