企业官网建设流程全解析

简介：基于哈工大语言平台的蒸汽平台评论爬取情感分析可视化源码，是一份可直接运行的课程设计与期末大作业方案，面向需要完成数据分析类项目的学习者。项目完整覆盖评论采集、文本清洗、情感判断与图表展示等环节，从接口请求到数据预处理再到情感模型调用与可视化输出，过程一气呵成；代码注释详细，部署门槛低，新手也能轻松读懂并二次改造。压缩包共53个文件、大小约26MB，除核心代码外，还配有csv数据集、停用词表、需求说明文档、演示文稿及运行截图，目录结构清晰易查，便于按需查阅与快速定位。已有264人学习浏览，这套项目既适用于期末验收与课程设计展示，也能帮助学习者理解实际NLP情感分析流程，并学会如何将分析结果用图表直观表达。

1. 把steam几千条中文评论变成可视化口碑报表：hanlp、情感分析与Python爬虫一条链路打通

steam游戏页面下面几千条中文评论，想判断这游戏是好评如潮还是差评如潮，靠人肉翻页能翻到手发麻。用Python写个爬虫把评论拉下来，配hanlp做中文分词和情感打分，再用pyecharts把结果渲染成词云和趋势图，整条链路大概150行源码就能跑通。这个方案适合游戏开发者做口碑监控、游戏自媒体写选题，也适合刚把requests和pandas摸熟、想往NLP方向迈一步的Python新人。有个反直觉的点：hanlp不是装完叫两声就能告诉你好评差评，它负责分词和词性标注，情感判定要自己接词典或微调模型。这篇博文会把整套链路按能复现的标准拆开，顺手把参数和踩过的坑也写出来。

2. 先跑通评论数据管道：steam评论区不是没人管，但能给你开一扇窗

2.1 从steam返回的JSON里，把评论正文和voted_up挑出来

steam官方其实提供了一个非正式的评论接口，地址是store.steampowered.com/appreviews/<游戏appid>，不需要玩家API Key就能直接访问。国内网上很多教程还在教解析HTML页面，那是十年前的路子，现在直接拿到JSON响应体，字段齐全、结构稳定。这个JSON里最核心的部分是reviews数组和最外层的cursor字段。reviews数组里一条评论对应一个字典，其中review字段是评论文本，recommendationid是评论的唯一ID，voted_up表示玩家是否点击了“推荐”，author.playtime_forever是游戏时长（单位是分钟）。

常见做法是先写一个只拉一页的小函数，把返回结构看清楚，再进入翻页逻辑。我一般会这样写单页请求：

import requests APP_ID = 730 # CS2的appid，换成别的游戏在这里改 URL = "https://store.steampowered.com/appreviews/{}/".format(APP_ID) def fetch_one_page(app_id, cursor="*", language="schinese"): params = { "json": 1, "language": language, "cursor": cursor, "day_range": 90, "filter": "recent", "purchase_type": "all", } headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/124.0.0.0 Safari/537.36" } resp = requests.get(URL, params=params, headers=headers, timeout=15) resp.raise_for_status() data = resp.json() return data["reviews"], data.get("cursor", "*")

第一行resp.raise_for_status()会把403、429之类的HTTP异常直接抛出来，避免你拿回一页错误页面还在强行解析。cursor参数在第一次请求时固定传*，表示从最新评论开始取；之后每次翻页，都要用上一次返回的cursor值替换它。day_range=90是只取最近90天的评论，filter=recent表示按评论时间从新到旧排序，这两个参数直接决定你拿到的数据窗口。language=schinese表示要简体中文评论，这个字段对steam中国区玩家非常关键，不传的话默认返回英文评论。

这个函数返回的每条评论里还有timestamp_created，单位是Unix时间戳秒，后面画时间趋势图要把这个字段转成日期。字段名别记错，写成timestamp会让pandas转日期时认不出列。你可以先打印第一条评论看看结构，确认数据真的是中文再往下走。

2.2 用requests把任意游戏的评论落成CSV：翻页靠cursor不靠页码

steam评论接口的翻页是很多爬虫新手的第一道坎，它不认page=1、page=2这种页码参数，只认cursor。每次请求返回的JSON里，最外层会带一个cursor字段，你要把它原封不动地传给下一轮请求——这就是游标翻页机制，cursor记录的是评论集当前位置的服务器快照，不是页码。如果你在翻页过程中改了filter、language或者day_range里面任何一个参数，服务端生成的游标就对不上，翻着翻着就会拿到重复数据。

我一般会把翻页循环封装成独立函数，同时加一个上限保护，避免接口异常时无限跑下去：

import time import csv def crawl_reviews(app_id, max_pages=5): cursor = "*" rows = [] for page in range(max_pages): reviews, cursor = fetch_one_page(app_id, cursor=cursor) for r in reviews: rows.append({ "review_id": r["recommendationid"], "review_text": r["review"], "voted_up": r["voted_up"], "timestamp": r["timestamp_created"], "playtime_hours": round(r["author"]["playtime_forever"] / 60, 1), }) print("page {}: got {}, next cursor = {}".format(page + 1, len(reviews), cursor)) if not reviews: break time.sleep(1.5) with open("steam_reviews.csv", "w", newline="", encoding="utf-8-sig") as f: writer = csv.DictWriter(f, fieldnames=rows[0].keys() if rows else []) writer.writeheader() writer.writerows(rows) return rows

time.sleep(1.5)是给steam接口的喘息窗口，间隔压到0.1秒连续拉几百页很容易触发限流。encoding="utf-8-sig"是CSV能被Excel正常打开中文的关键，写成纯utf-8的话Excel里全是乱码。max_pages这个上限值在实际使用中最好从命令行参数传进来，这样换游戏爬数据时不用改源码。

2.3 评论数据落库：为什么我选SQLite而不是CSV

只跑一次实验CSV够用，但后面做情感分析和可视化时要反复读取、去重、合并字段，CSV会非常磨人。我习惯从第一步就把数据写进SQLite，建表时提前给情感分析结果留好字段，这样每次新算出的情感分只用UPDATE写回，不用整库重灌。

建表和写入用一段很薄的代码就够了：

import sqlite3 def init_db(db_path="steam_comments.db"): conn = sqlite3.connect(db_path) conn.execute(""" CREATE TABLE IF NOT EXISTS reviews ( review_id TEXT PRIMARY KEY, game_id INTEGER, review_text TEXT, voted_up BOOLEAN, timestamp INTEGER, playtime_hours REAL, sentiment_score REAL, sentiment_label TEXT, created_at TEXT DEFAULT (datetime('now')) ) """) return conn def save_reviews(conn, app_id, rows): conn.executemany( "INSERT OR IGNORE INTO reviews (review_id, game_id, review_text, voted_up, timestamp, playtime_hours) " "VALUES (?, ?, ?, ?, ?, ?)", [(r["review_id"], app_id, r["review_text"], r["voted_up"], r["timestamp"], r["playtime_hours"]) for r in rows] ) conn.commit()

INSERT OR IGNORE依赖review_id主键去重，第二次爬同一个游戏不会重复插入。这个习惯能救大命——后面调情感分析脚本时要反复迭代，每次跑完只需UPDATE新算出的字段，不用从头爬一遍。表里的game_id和timestamp字段是为后面按游戏过滤和画时间趋势准备的，想爬多个游戏做对比的话一定要留着。

第一次跑通管道后，你手上应该有几条到几千条不等的评论。先用pandas看一眼DataFrame的行数和review_id的重复率，我遇到过因为cursor参数传错导致第一页数据重复到第三页的情况，这种脏数据会让后面的情感统计全盘出错。

3. hanlp分词接情感打分：正向负向不能只靠“好玩”“垃圾”

3.1 hanlp装法和模型引入：装纯Python版还是Java版

hanlp在Python生态里有两代用法。第一代是早期基于Java的版本，pip install hanlp会把jpype也带进来，启动时要拉起一个JVM，还要在环境变量里指定JVM路径，很多人第一次跑就死在JVM内存上。现在主流的做法是直接用hanlp 2.x的纯Python版，底层是PyTorch，装完即用，模型文件首次加载后会缓存到本地目录。

装好之后先验证一下加载是否正常，再决定用哪个模型。我会先跑一个最小的分词模型确认环境没问题，再上联合模型：

import hanlp # 联合模型：分词/词性/命名实体/依存句法一次出 HanLP = hanlp.load(hanlp.pretrained.mtl.CLOSE_TOK_POS_NER_SRL_DEP_SDP_CON_ELECTRA_SMALL_ZH) doc = HanLP("这游戏手感真好，就是偶尔闪退") print(doc["tok"]) print(doc["pos"]) # 输出形如: # ['这', '游戏', '手感', '真', '好', '，', '就是', '偶尔', '闪退'] # ['DT', 'NN', 'NN', 'RB', 'VA', 'PU', 'CS', 'AD', 'VA']

CLOSE_TOK_POS_NER_SRL_DEP_SDP_CON_ELECTRA_SMALL_ZH是一组联合模型的名字，它把中文分词、词性标注、命名实体、依存句法、语义角色都算出来，返回的doc里可以直接取tok和pos。第一次加载会下载几百MB的模型文件，网络不通时会卡住，解决办法放在第5章。如果你只想拿词性标注来做情感词典匹配，也可以单独加载分词和词性模型，体积更小、速度更快：

tok = hanlp.load(hanlp.pretrained.tok.COARSE_ELECTRA_SMALL_ZH) pos = hanlp.load(hanlp.pretrained.pos.CTB9_POS_ELECTRA_SMALL) tokens = tok("这游戏手感真好，就是偶尔闪退") tags = pos(tokens)

单任务模型的优点是加载快、内存占用小，缺点是要自己把分词结果传给pos模型，代码多几步。联合模型的优点是一行出全部结果，但对老电脑不太友好。我自己的习惯是做steam评论这种短文本时直接用联合模型，因为口语化的“手感真好”“好是好就是卡”这种句子，分词正确率肉眼可见地更高，后面情感打分全靠正确的词边界。

3.2 用hanlp做分词和词性标注，然后打情感分

hanlp本身不直接给出一句话是好评还是差评，它做的是分词、词性、依存这些基础能力。情感判定这个活，常见做法是拿分词结果接一个情感词典打分，词典里每个词配一个极性权重，最后把整条评论的分值加起来。这样做的好处是逻辑透明，跑一次就能知道是哪个词拉的分数，效果不够还能回去改词典。

我先把打分函数写出来：

POSITIVE_WORDS = {"好", "不错", "舒服", "爽", "神", "优秀", "推荐", "喜欢", "值得", "好玩", "惊喜", "良心", "满意"} NEGATIVE_WORDS = {"差", "垃圾", "坑", "烂", "卡", "闪退", "后悔", "无语", "失望", "骗", "糟糕", "影响", "难受", "不值得"} NEGATION_WORDS = {"不", "没", "别", "无", "非"} def sentiment_score_from_tokens(tokens): n = len(tokens) flipped = [False] * n for i, tok in enumerate(tokens): if tok in NEGATION_WORDS: for j in range(i + 1, min(i + 3, n)): flipped[j] = True score = 0 for i, tok in enumerate(tokens): w = 0 if tok in POSITIVE_WORDS: w = 1 elif tok in NEGATIVE_WORDS: w = -1 if w == 0: continue if flipped[i]: w = -w score += w return score def analyze_comment(text, hanlp_instance): doc = hanlp_instance(text) score = sentiment_score_from_tokens(doc["tok"]) label = "positive" if score > 0 else ("negative" if score < 0 else "neutral") return score, label

打分逻辑里最关键的是否定词翻转。steam评论里“不推荐”“不行”“没意思”都是典型负面表达，但“推荐”“行”“有意思”单独看是正面词，如果没有翻转逻辑整条评论会被打成正面。flipped数组的处理方式是：碰到否定词，把它后面两个位置的词标记为需翻转，之后再统一计算，这样“不推荐”就会把“推荐”的+1变成-1。

这里有个必须强调的点：hanlp返回的doc对象不是普通Python字典，直接取doc["tok"]是能用的，但别在doc上瞎调其他方法。想整体看结果时用doc.to_dict()。如果你加载的是单任务模型，分词结果是普通字符串列表，直接喂给打分函数同样没问题。

3.3 情感词典的扩充和否定词处理：汉语句子里的“不推荐”千万别看反

steam评论里的高频词和新闻语料差很多，拿CS2评论跑一遍，top词除了“游戏”“手感”“优化”“挂”“队友”，还有不少电竞圈黑话。这些词得单独加进词典里，否则情感分析会大面积变成中性。我一般先用一段代码把高频词拉出来，人工过一遍再扩充词典：

from collections import Counter def print_top_words(df, top_n=60): counter = Counter() for text in df["review_text"].dropna(): tokens = HanLP(text)["tok"] counter.update(t for t in tokens if len(t) > 1) for word, freq in counter.most_common(top_n): print(word, freq)

跑完这一步，把明显带褒贬的词摘出来写进lexicon.txt，每行一个词加一个极性标签，用load函数读进来，这样词典可以脱离代码维护：

def load_lexicon(path="lexicon.txt"): pos_words, neg_words = set(), set() with open(path, encoding="utf-8") as f: for line in f: parts = line.strip().split() if len(parts) < 2: continue word, polarity = parts[0], parts[1].lower() if polarity in {"pos", "1", "正面"}: pos_words.add(word) elif polarity in {"neg", "-1", "负面"}: neg_words.add(word) return pos_words, neg_words

为什么不用现成的通用情感词典？大连理工情感本体库确实全，但它是通用领域语料，“手感”“优化”“闪退”这些steam评论里的关键词一概不覆盖。把领域词加进去，情感分析的准确率会明显提升。这不是黑匣子模型能给你的解释性，别嫌这一步土，它最见功夫。

否定词的翻转范围也要单独调，翻转窗口太大会误伤无辜。比如“不贵而且好玩”，“好玩”显然还是正面，但翻转窗口设为3时，“而且”后面那个“好玩”也被翻转，整句就反了。一般我设2到3，配合实际例子去试，跑几条评论看结果对不对，再固定下来。

4. 可视化：词云、情感分布、时间折线一张大屏看完

4.1 把情感分聚合成正/负/中性并画饼图

情感分析跑完，SQLite里的sentiment_score和sentiment_label已经写好了，接下来直接查库出结果。可视化我推荐pyecharts，因为它用几行代码就能拼出一个可视化大屏风格的HTML页面，浏览器直接打开，不用起Flask服务，这对快速分析steam评论这种一次性任务非常合适。

先看最基本的聚合饼图：

import sqlite3 import pandas as pd from pyecharts.charts import Pie from pyecharts import options as opts conn = sqlite3.connect("steam_comments.db") df = pd.read_sql("SELECT * FROM reviews WHERE game_id=730", conn) label_counts = df["sentiment_label"].value_counts() pie = ( Pie() .add( series_name="评论占比", data_pair=[list(x) for x in label_counts.items()], radius=["35%", "60%"], label_opts=opts.LabelOpts(formatter="{b}: {c} ({d}%)"), ) .set_global_opts(title_opts=opts.TitleOpts(title="steam评论情感分布")) ) pie.render("sentiment_pie.html")

label_opts里的{d}%是pyecharts自带的百分号格式器，不用自己算占比。radius传两个值是把普通饼图改成环形，视觉上比实心饼图干净，适合贴进分析报告。set_global_opts里还可以加legend_opts把图例放到右下角，配色用默认的series_palette就行。

4.2 词云图：卖出安利和火葬场的词，一眼抓出来

词云是steam评论分析里最有冲击力的输出，它把玩家反复提的“手感”“闪退”“优化”“匹配”这些词用字号大小展示出来，比表格直观太多。词频统计要建立在分词结果上，不能直接按空格分开，因为中文评论里没有空格。

from collections import Counter from pyecharts.charts import WordCloud STOP_WORDS = {"游戏", "这个", "真的", "可以", "还是", "就是", "觉得", "一个", "什么", "没有", "不过"} def build_word_freq(df, top_n=80): counter = Counter() for text in df["review_text"].dropna(): tokens = HanLP(text)["tok"] counter.update(t for t in tokens if len(t) > 1 and t not in STOP_WORDS) return counter.most_common(top_n) freq = build_word_freq(df) wc = ( WordCloud() .add( "", freq, word_size_range=[12, 80], shape="circle", font_family="Microsoft YaHei", ) .set_global_opts(title_opts=opts.TitleOpts(title="评论高频词")) ) wc.render("comment_wordcloud.html")

停用词这一步不能省，否则词云里全是“游戏”“这个”这种没有信息量的词。word_size_range控制字号下限和上限，词频越高的词字号越大。font_family参数务必带上，pyecharts的WordCloud组件默认字体大概率不支持中文，不带这个参数渲染出来全是方块，这个问题在Windows和Linux上都遇到过。

4.3 时间维度上的情感变化：评论口碑不是一条直线

把每条评论的timestamp转成日期，按天聚合并算平均情感分，就能看到这个游戏的口碑走势。这个图对游戏开发者极有价值，某次版本更新导致情感分断崖下跌，从视觉上会非常扎眼。

df["date"] = pd.to_datetime(df["timestamp"], unit="s").dt.date daily = df.groupby("date").agg(avg_score=("sentiment_score", "mean"), count=("review_id", "count")) daily = daily[daily["count"] >= 3] # 评论太少的天平均分没有意义 from pyecharts.charts import Line line = ( Line() .add_xaxis([str(d) for d in daily.index]) .add_yaxis( "平均情感分", [round(v, 2) for v in daily["avg_score"]], is_smooth=True, markpoint_opts=opts.MarkPointOpts( data=[opts.MarkPointItem(type_="min"), opts.MarkPointItem(type_="max")] ), ) .set_global_opts( title_opts=opts.TitleOpts(title="每日平均情感分变化"), yaxis_opts=opts.AxisOpts(min_=-1, max_=1), ) ) line.render("sentiment_trend.html")

按天聚合时滤掉样本数小于3的天，因为当天只有一两条评论时平均数会被极端值带飞，画出来全是一根根刺，看不出趋势。is_smooth打开后曲线会做平滑处理，视觉上更接近“口碑走势”而不是散点连线。y轴范围固定-1到1是配合打分体系的，如果词典权重让分数超出这个范围，记得改成数据驱动的min和max，否则曲线会顶到边界。

到这里三张图都渲染成独立HTML，最后拼成一个可视化大屏页面：

from pyecharts.charts import Page page = Page(layout=Page.SimplePageLayout) page.add(pie, wc, line) page.render("steam_dashboard.html")

Page.SimplePageLayout会把三张图按流式布局拼到一页里，浏览器滚动就能看完所有图表，这就是常说的一页看板。如果报告里要塞PDF，也可以分别render出图片用matplotlib拼，但我个人觉得直接给HTML链接更方便。

5. steam评论爬虫避坑指南：hanlp加载，翻页，编码，一团乱麻逐个捋

5.1 hanlp模型加载失败：别在import之后才求救

现象：hanlp.load执行后一直卡住不动，或者长时间下载后抛OSError，提示找不到模型文件。

原因：hanlp 2.x的模型默认从远端下载到~/.hanlp目录，国内网络环境下载几百MB的文件经常断在半路，留下一个损坏的缓存目录，下次加载就直接失败。

解决：先确认~/.hanlp目录的状态。如果里面有文件但加载报错，删掉整个~/.hanlp后重新执行load；如果网络实在不行，找一个能下载的时段提前把模型拉到本地，然后加载时写本地路径：

import os os.environ["HANLP_HOME"] = "/data/hanlp_models" HanLP = hanlp.load("/data/hanlp_models/close_tok_pos_ner_srl_dep_sdp_con_electra_small_zh")

HANLP_HOME指向的目录要和模型实际解压出来的结构一致，别再套一层用不到的子目录。另外，老教程里大量出现的from hanlp import HanLP在2.x里已经不建议用，直接import hanlp然后hanlp.load()即可。看到jpype报错的用户基本都是落进旧版本坑了。

5.2 爬虫翻页死循环：cursor是快照不是页码

现象：爬了好几百页，一看数据和第一页一模一样，或者cursor始终不变。

原因：steam的cursor是基于服务端生成的评论快照的，如果你在翻页过程中改了filter、day_range、language，或者两次请求间隔太长导致快照过期，游标就会失效。接口要么返回重复数据，要么停在原地。

解决：翻页循环里除了cursor，其他参数一个都不许变。具体代码里加一个安全阀，连续3页没有新增记录就停止：

def crawl_reviews_safe(app_id, max_pages=5): cursor = "*" seen_ids = set() stable_pages = 0 for page in range(max_pages): reviews, cursor = fetch_one_page(app_id, cursor=cursor) new_count = sum(1 for r in reviews if r["recommendationid"] not in seen_ids) if new_count == 0: stable_pages += 1 if stable_pages >= 3: print("连续3页无新增，停止") break else: stable_pages = 0 for r in reviews: seen_ids.add(r["recommendationid"]) time.sleep(1.5) return list(seen_ids)

用recommendationid去重是最稳的判断方式，比依赖cursor是否变化可靠得多。连续3页没有新评论基本可以确定已经翻到底了，再跑下去只是浪费时间。

5.3 情感分析结果全是中性：词典覆盖率和分词粗细问题

现象：跑了200条评论，正负加起来不到10条，剩下全是neutral。

原因：情感词典太小，steam评论的核心词一个没覆盖；或者hanlp分词把“不推荐”切成“不/推荐”后，翻转逻辑没有正确触发。

解决：先把评论里的高频词拉出来手动过一遍。具体方法是跑print_top_words打印top 50到100，把“手感”“优化”“闪退”“掉线”“挂”“队友”这些词按褒贬加入词典，再重跑分析。更关键的是，不要把neutral当成失败，它本来就是未知棋盘的占位，词典补到位之后neutral比例自然会降下来。

5.4 中文乱码：utf-8-sig能救CSV，但救不了你的终端

现象：CSV用Excel打开全是乱码，IDLE或终端里print中文也乱。

原因：CSV用utf-8写入，但Excel的默认读取方式是ANSI，中文全乱；Windows终端的代码页是GBK，读到utf-8的中文自然也是乱码。

解决：CSV写文件时encoding参数用utf-8-sig而不是utf-8，这是带BOM的UTF-8，Excel识别得很好。终端乱码时在Windows下先执行chcp 65001把代码页切到UTF-8，或者干脆把所有print语句里的中文改成英文标点和ASCII内容。我自己的代码里，print输出一律用英文，避免在别人机器上跑脚本时屏幕上一片问号，这个问题排查起来特别玄学。

5.5 pyecharts图表中文方块：字体没配好

现象：词云图上中文全是方框，但饼图的标题却是正常的。

原因：WordCloud组件的渲染需要加载字体，默认字体对中文支持不全，浏览器找不到能显示中文的字形，就渲染成方块。

解决：在WordCloud的add参数里显式指定font_family，Windows上一般用Microsoft YaHei，Linux服务器上可以用Noto Sans CJK SC。如果还不行，检查pyecharts版本，部分旧版WordCloud对font_family支持有问题，升级到较新的pyecharts版本即可。饼图和折线图的字体走的是ECharts默认字体，大多没问题，只有WordCloud最容易翻车。

6. 让口碑报表每天自己生成：定时任务+增量更新+One Page看板

这一步把前面所有代码拧成一条流水线，挂到定时任务里，第二天起床就能看到新鲜的口碑报表。增量更新的技巧在于不用再爬全量数据，把day_range改成1，只拉过去24小时的评论，入库时INSERT OR IGNORE去重，情感分析只对sentiment_label为空的行执行。这样每天新增几百条评论，处理耗时控制在两分钟以内，对steam接口的压力也小。

我用APSchedule做定时调度，完整结构大致是这个样子：

from apscheduler.schedulers.blocking import BlockingScheduler from datetime import datetime def refresh_report(): conn = init_db() rows = crawl_reviews(APP_ID, max_pages=3, day_range=1) save_reviews(conn, APP_ID, rows) df = pd.read_sql("SELECT * FROM reviews WHERE game_id=? AND sentiment_label IS NULL", conn, params=(APP_ID,)) for idx, row in df.iterrows(): score, label = analyze_comment(row["review_text"], HanLP) conn.execute("UPDATE reviews SET sentiment_score=?, sentiment_label=? WHERE review_id=?", (score, label, row["review_id"])) conn.commit() render_dashboard(conn, APP_ID) conn.close() print("report refreshed at", datetime.now()) sched = BlockingScheduler() sched.add_job(refresh_report, "interval", hours=24) sched.start()

验证这一步别偷懒。我习惯从全量数据里随机抽100条评论，按自己的判断标成正/负/中，再用sklearn的classification_report对比脚本结果，看看hanlp加词典这组方案到底什么准确率，新增词会不会误伤别的句子。

跑上一周之后你会觉得，真正的价值不在“能爬”，而在能解释口碑为什么变化。比如某天情感分断崖下跌，点开那天的评论看到“更新后闪退”出现的频率，答案就摆在面前。这个方案的缺点也摆在这里：词典维护是持续投入，每次游戏版本更新都可能冒出新的社区黑话，得定期回去看高频词；如果哪天你想按“哪类负面问题最多”做细粒度分析，就得把词典升级成分类模型，用hanlp的文本分类微调能力再往前迈一步。希望帮到你。

本文还有配套的精品资源，点击获取