景区评论采集与情感分析实战：从爬虫到SnowNLP应用

龙湖古寨评论采集工具，这个项目名字听起来像个小练手，实际做完我才发现，它就是一套典型的数据采集加文本分析流程：把散落在旅游平台上的游客评论抓回来，再用 SnowNLP 给每条评论算出一个情感倾向分，最后汇总成能看懂的口碑结论。如果你正准备做景区口碑分析、游客满意度调研，或者刚学完爬虫基础知识却不知道下一步做什么，这套思路完全可以整套抄走。

我先说一下项目背景。龙湖古寨位于广东潮州韩江边，是保存相对完好的古村落建筑群，游客评论分布在携程、马蜂窝、大众点评等好几个平台上。这些评论有一个共同特点：短、口语化、夹杂大量地点名词和表情符号，比如“古寨很出片但停车不方便”“巷子很有味道就是门票略贵”。人工逐条看当然能看懂，但要想回答“游客整体是满意还是不满”“槽点集中在哪个环节”，就必须先把评论结构化，再用算法批量打分。

这篇文章就按我实际的推进顺序来写：需求拆解和工具选型、评论采集实现、SnowNLP 情感分析原理与代码、统计洞察、最后是踩坑记录。整个过程没有用任何重量级框架，一台普通笔记本就能跑完，很适合中小规模评论数据的分析场景。

1. 项目需求与方案选型

1.1 龙湖古寨评论采集到底要解决什么问题

如果只是要“采集评论”，那需求一句话就结束了，但实际做下来，真正的难点在于把“散落的非结构化文本”变成“可分析的结构化数据”。

龙湖古寨这类景区的线上口碑有一个典型问题：不同平台的评论维度完全不一致。有的平台显示评分加上短评，有的平台只有长文游记，还有一些平台把用户评论折叠在“查看全部”里。直接拿原始页面文本去分析，结果会被大量无关标签、楼层引用和重复内容污染。所以项目的第一阶段目标不是急着写爬虫，而是明确数据管道：采集原始页面，解析出用户昵称、评分、评论内容、发布时间这几个字段，清洗去重后落成 DataFrame，再交给 SnowNLP 做情感打分。

我给自己定了三个具体功能目标：第一，评论可以按页翻取并稳定入库；第二，评论内容做过去重和空值过滤，缺失字段不影响后续分析；第三，每条评论自动附带一个情感得分，最终结果可以导出 CSV 复查。这个目标设定很关键，它决定了后面所有的技术选型都不会跑偏。

功能目标听起来不难，但真实情况里每条都可能踩坑。比如翻页参数到底是 page 还是 offset，评论列表里混着商家回复怎么办，用户输入的表情符号会不会导致编码中断，这些都属于“不做不知道，一做吓一跳”的细节。我的建议是先把目标拆成“采集”和“分析”两段来验收，别指望一步到位。

1.2 为什么情感分析工具最后选了 SnowNLP

市面上能做中文情感分析的工具不少，从百度 AI 开放平台到各类商用 API，再到 BERT 这类深度学习模型。但我最终选择了 SnowNLP，核心原因只有一个：这个项目的规模和数据性质，不需要重武器。

SnowNLP 是一个纯 Python 的中文文本处理库，默认训练好了一个基于朴素贝叶斯的情感分类模型。它最吸引我的点是没有 GPU 依赖，不用申请 API 密钥，离线就能跑，pip install snownlp之后直接调用s.sentiments就能拿到 0 到 1 之间的情感概率。对龙湖古寨这种千条级别的评论数据来说，这个精度和效率完全够用。

我拿它和另外两类方案做了对比，大家可以根据自己的场景参考。

做一个并不严谨但很贴切的类比：SnowNLP 就像一个用预制菜包炒菜的快手厨师，速度快、味道稳定，但你不能指望它做出创意菜。游客评论里最常见的“古寨很美但人也太多了”这类转折句，它往往会偏向正面，因为“美”这个词语气权重更高。后面我会专门讲怎么用自定义训练来缓解这个问题。

选型时还有一个现实考量：评论采集本身已经涉及多平台适配，如果再接入需要联网调用的大模型 API，整个项目的稳定性和成本都不可控。所以我决定把核心分析完全放在本地，这也是 SnowNLP 最终胜出的决定性原因。

2. 数据采集：从零构建评论数据集

2.1 评论数据源的选择与采集原则

动手写爬虫之前，我先做了一件事：打开浏览器开发者工具，把目标平台页面从头到尾看了一遍。这一步非常重要，很多人上来就写 requests 去请求网页 URL，结果发现拿回来的 HTML 里根本没有评论数据，因为数据其实是页面加载后通过接口异步返回的。

龙湖古寨的评论源我主要看了三类平台：OTA 平台的景点评价页、社区型游记平台、以及本地生活平台的评分页。它们的渲染方式差异很大。有些是服务端直接输出完整 HTML，用 BeautifulSoup 就能解析；有些是前端框架配合 JSON 接口，需要找到真正的数据接口；还有些评论做了懒加载，必须模拟滚动才能触发后续请求。最容易处理的是找接口返回 JSON 的那类，因为数据字段清晰，连解析都可以省掉一半功夫。

采集原则方面，我给自己定了三条底线：只采集公开页面的数据，不登录不绕过权限限制；控制请求频率，正常浏览速度以内；采集到的数据只用于个人研究，不商用不对外发布。这个框架既保护了平台服务稳定，也避免给自己惹上不必要的麻烦。实操中我会在两条请求之间随机休眠 1 到 3 秒，每次翻页都带上当前页面对应的来源参数。

要特别提醒的是，不要一上来就追求“全平台高并发采集”。项目目标是龙湖古寨的单点口碑分析，先在一个平台跑通全流程，再扩渠道才是正路。我一个平台一个平台地加，每加一个平台就顺手把解析规则和字段映射记录下来，后面整合数据时会轻松很多。

2.2 评论抓取与解析的核心代码

按最常见的接口型数据源来示例，核心逻辑就是“请求接口、解析 JSON、落盘 DataFrame”。下面这段代码是我简化后的版本，结构上完整保留了实际流程。

import requests import pandas as pd import time import random HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Referer": "https://example.com/scenic/detail/123", "Accept": "application/json", } def fetch_comments(page): url = f"https://example.com/api/comments?scene_id=123&page={page}" resp = requests.get(url, headers=HEADERS, timeout=10) resp.encoding = "utf-8" if resp.status_code != 200: print(f"请求失败: {resp.status_code}, page={page}") return [] return resp.json().get("data", {}).get("comments", []) def main(): rows = [] for page in range(1, 6): comments = fetch_comments(page) for item in comments: rows.append({ "user": item.get("user", {}).get("nickname", ""), "rating": item.get("rating"), "comment": item.get("content", "").strip(), "time": item.get("publish_time", ""), }) time.sleep(random.uniform(1, 3)) df = pd.DataFrame(rows) df = df.drop_duplicates(subset=["user", "comment", "time"], keep="first") df.to_csv("comments_raw.csv", index=False, encoding="utf-8-sig") print(f"共采集 {len(df)} 条评论")

代码里有几个细节值得展开说。

首先是响应编码。不少平台返回的文本虽然声明了 UTF-8，但实际里面混入了 HTML 实体或者 emoji，我的习惯是拿到响应后立刻统一设置resp.encoding = "utf-8"，避免后续解析出现乱码。其次是去重逻辑，我用了“用户加内容加时间”三元组做主键，比单纯用评论内容去重更可靠，因为不同用户可能发相同内容的模板评价。

还有一个很多人会忽略的点：原始 JSON 一定要完整保存一份，哪怕你现在只需要标题和评论。因为分析进行到后面，很可能会想补充字段，比如评论的点赞数、平台星级、是否含图片。到时候重新抓取既费时间又容易触发反爬，老老实实留底才是最优解。

这里用到的read_csv编码是utf-8-sig，也是我的一个小习惯。Excel 直接打开普通 UTF-8 的 CSV 经常出现中文表头乱码，utf-8-sig可以完美避免。

3. SnowNLP 情感分析：原理和落地写法

3.1 sentiment 分数到底是什么意思

SnowNLP 的sentiments方法返回的是 0 到 1 之间的浮点数，直觉理解是值越接近 1 越正面，越接近 0 越负面，0.5 左右算中性。比如我拿一条真实风格评论做测试：

from snownlp import SnowNLP comment = "古寨建筑很震撼，但小吃街有点脏乱" s = SnowNLP(comment) print(s.sentiments) # 输出类似 0.69

看到 0.69 的时候先别急着下结论说“游客比较满意”。这里涉及 SnowNLP 的底层机制：它本质上是一个基于朴素贝叶斯的中文二元情感分类器，输入评论后会先分词，再把词语特征丢进训练好的概率模型里，算出的结果归属于“这条评论是好评”的概率，而不是“游客有多么满意”。所以 0.69 的真实含义是：模型认为这条评论有 69% 的概率属于正例。

理解这一点很重要，因为它解释了为什么模型会被短句带偏。比如“垃圾但风景还行”这种转折句，模型更容易抓到“风景”这个强正面词，给出的分数会明显偏高。我的应对策略不是去修改单条分数，而是把阈值从默认的 0.5 调整到观察出来的合理区间，用相对变化代替绝对值。

默认模型中，0.5 是一个很平衡的分界点。但它训练时的语料偏向电商评论，电商语境里的“质量不错”“发货快”和景区语境里的“氛围好”“原生态”在表达方式上有差异。所以我建议第一次跑完数据后，人工抽样 50 条，看一眼模型分数和人类判断的偏差方向，再决定把你的正负分类阈值定在 0.6 还是 0.4。

3.2 批量打分、分类与导出结果

数据采集回来后，情感分析部分代码量很少，但它们是整个项目里最容易被低估的一环。我这里用 pandas 的map直接逐条处理，效率足够，代码也直观。

from snownlp import SnowNLP import pandas as pd df = pd.read_csv("comments_raw.csv", encoding="utf-8-sig") def score(text): if not isinstance(text, str): return None text = text.strip() if len(text) < 2: return None return SnowNLP(text).sentiments df["sentiment"] = df["comment"].map(score) df = df.dropna(subset=["sentiment"]) df["polarity"] = pd.cut( df["sentiment"], bins=[0, 0.4, 0.6, 1.0], labels=["负面", "中性", "正面"] ) summary = df["polarity"].value_counts() print(summary)

这里把分箱边界设成 0.4 和 0.6，是结合我前面说的“短文本容易偏正面”现象做的人为修正。如果直接用 0.5 一刀切，会发现几乎所有评论都堆在正面区间，分析结论失去区分度。

跑完之后可以顺手算几个关键指标：整体平均分、各分类占比、评分和情感的相关系数。我自己的结果是平均分 0.68，表面看起来不错，但拆开看“负面”比例占到 11%，说明仍然存在一批被平均分掩盖的差评。这就是为什么要保留分类而不是只看均值。

导出时我会多留一列polarity和原始评论内容，这样复查的时候可以快速筛选出模型打分为正面但我看起来明显是负面的样本，方便后续自定义训练和阈值调整。

4. 从情感分数到可读结论：统计与轻量可视化

4.1 先看分布，别急着看均值

很多项目在拿到情感分数后就输出一个“平均分 0.68”收尾，这种做法的信息损失很大。景区的口碑往往不是正态分布，而是典型的“多数好评加少数强负面”双峰形态。分开看分布比看均值有意义得多。

我通常先画两个图：一个是情感分数的直方图，一个是正负中三类的饼图。直方图能直观看出分数是否集中在 0.8 附近，饼图能看出负面评论的真实占比。

import matplotlib.pyplot as plt plt.rcParams["font.sans-serif"] = ["SimHei"] plt.rcParams["axes.unicode_minus"] = False df["sentiment"].hist(bins=30, alpha=0.7) plt.xlabel("SnowNLP 情感分数") plt.ylabel("评论数量") plt.title("龙湖古寨评论情感分数分布") plt.show()

这段代码里有两行是中文绘图的必备配置，缺少SimHei设置的话图表的坐标轴中文会全部显示成方块。我第一次画图就栽在这里，排查了很久才发现是字体问题。

直方图跑出来后，我注意到一个典型现象：分数在 0.9 附近有一根很高的柱子，在 0.1 附近又有一小撮尾巴。这其实是多数短好评和部分强差评的叠加效果。看到这种形态，我就知道不能简单用均值代表整体口碑，要看具体差评内容才能定位问题。

4.2 结合关键词维度，看游客的槽点和亮点

情感分数只能回答“正还是负”，回答不了“正在哪、负在哪”。所以我在项目中加了一步关键词维度拆解，这也是我认为最有价值的一步。

操作方式很简单：根据龙湖古寨的游览场景，先预设几个主题词，比如门票、停车、卫生、讲解、拍照、美食、住宿。然后遍历评论，判断每条评论是否命中某个主题，最后分组统计情感均值。

topics = { "停车交通": ["停车", "打车", "交通", "路"], "门票价格": ["门票", "票价", "性价比"], "环境卫生": ["卫生", "脏", "厕所", "垃圾"], "讲解体验": ["讲解", "导游", "介绍"], "拍照出片": ["拍照", "出片", "景色", "建筑"], } topic_sentiment = {} for topic, kws in topics.items(): mask = df["comment"].str.contains("|".join(kws), na=False) if mask.sum() > 0: topic_sentiment[topic] = df.loc[mask, "sentiment"].mean() print(topic_sentiment)

我这里的结果很有戏剧性：“拍照出片”主题的情感均值最高，说明游客对古寨建筑风貌普遍认可；“讲解体验”主题的均值偏低，说明在讲解服务上存在明显短板。假如只看整体均值，这个差异是看不出来的。

这步做完之后，我们就能把一套评论数据变成真正的决策信息：哪方面做得好需要保持，哪方面是差评集中点需要整改。对景区运营方来说，这个维度的价值远大于单一的情感分数。我后来把它做成了一个通用函数，输入任何景区评论 DataFrame 都可以直接输出主题情感表。

5. 实测中的高频问题与避坑指南

5.1 采集端最常遇到的五类问题

我把这次项目中实际碰到的问题整理成了一个表格，几乎每一个都是新手的经典坎。

表格里最后一条特别值得展开说。很多平台的评论区默认只显示前三条，后面的内容要么需要点击“查看全部”，要么通过不同的接口参数返回。如果没发现这一点，采集到的评论会有严重偏差，全是热门高赞评论，失去了代表性。我的处理办法是先看完整接口返回的总数量字段，再按接口参数逐页拉全，最后对比页面展示数量确认没有遗漏。

5.2 SnowNLP 默认模型太“乐观”怎么办

这个坑我相信每个用过 SnowNLP 的人都会遇到：默认模型在电商语料上表现正常，到了景区短评论上，分数整体偏高。原因是游客评论里到处是“不错”“值得”“很棒”这类强正面词，而模型对短语缺乏上下文理解能力。

第一次跑完龙湖古寨的数据，我的正面评论占比超过了 80%，直觉告诉我这不正常，因为实际评论里抱怨的声音并不少。我花了半天时间抽样复查，最终决定做三件事。第一，把正负分类阈值上调到 0.6；第二，对命中“但是”“不过”“失望”等转折词的评论做特殊标记，单独复核；第三，用自定义语料重新训练 Sentiment 模型。

自定义训练的思路并不复杂。SnowNLP 的 sentiment 模块支持传入正负样本文件重新训练，训练完成后把模型文件保存下来，下次加载时就会用新模型。

from snownlp import sentiment # neg.txt 每行一条负面评论，pos.txt 每行一条正面评论 sentiment.train("data/neg.txt", "data/pos.txt") sentiment.save("sentiment.marshal")

这里必须提醒一个关键点：训练样本的数量和质量直接影响结果。我一开始只准备了 50 条正负样本，训练出来的模型反而更差了，因为样本太少导致过拟合。后来手动标注了 300 条龙湖古寨相关评论，效果明显改善。如果你不想手动标注，也可以从采集到的评论里抽取出模型高置信度的样本，经过人工校对后作为训练集。

5.3 关于采集和分析这两件事的整体心得

项目做完后，我最深的体会是：数据采集和分析从来不是两个孤立环节。采集时如果不用分析视角去思考字段设计，采集回来的数据可能没法支撑后续判断。比如评论的发布时间，表面上只是一个时间戳，但结合日期能进一步看出周末和工作日的口碑差异；再比如平台自带的评分字段，可以和 SnowNLP 情感分数做交叉验证，帮我判断模型哪些环节判断不准。

龙湖古寨这个项目跑完之后，我把整个流程包成了一个函数，只要替换景区 ID 和平台解析规则，就能复用到其他古镇或景点上。后续还可以扩展的方向包括：用词云展示游客高频词，按月度做口碑趋势监控，或者把负面评论单独抽取出来做吐槽点分类。这套轻量方案虽然不如大模型精致，但胜在快速、低成本、可控，适合绝大多数中小规模口碑分析需求。如果你正准备做类似的评论分析项目，我建议你按这个流程走一遍，踩坑的体验会比我写出来的更深刻。