Python中文文本分析入门：从高德地图POI到评论情感识别的完整链路

地图上的用户评价看起来只是一条短文本，但当极端天气过境后，同一小区、同一路段的地图评论区域会在几天内收到大量反馈。这些反馈往往带着明确的地点、时间和真实情绪，内容集中在积水、停水、垃圾清理、物业响应速度等具体问题上，是观察社区运行状态的一手素材。手动逐条去翻地图评价效率很低，所以我把“获取地点基础信息 + 评论文本分析”串成了一条可复现的数据链路，以浙江玉环坎门海都花园为例，演示从高德地图 API 到中文分词、情感分析再到结果汇总的完整流程。做完之后，可以快速扩展到任意地点，生成一份带有数据支撑的居民反馈摘要。

整个项目用 Python 编写，分为三块：第一块用高德开放平台 Web 服务 API 获取目标 POI 的名称、地址和经纬度；第二块处理评论文本，完成清洗、分词、停用词过滤和关键词提取；第三块做简单情感分析并输出结构化表格。下面从需求分析开始拆解每个步骤。

1. 需求分析：地图评价为什么值得做文本分析

1.1 一条短评文本里有什么

地图上的用户评价通常不超过几十个字，但信息密度并不低。以台风天气后的小区周边评价为例，一条“地下车库昨晚又进水，物业今天早上才拉警戒线”至少包含三个信息点：事件地点是地下车库，事件类型是积水，责任主体是物业，还带有明显的负面态度。另一条“小区门口积水已经抽完，进出恢复正常”则表明问题已经处理。这些短文本如果只看单条，很难判断整体情况；但如果把同一 POI 下的几十条评价集中起来做词频和情感统计，就能看出哪个问题被提到最多、居民情绪是偏向不满还是偏向理解。

地图评价和电商评论、新闻评论不同，它天然带有地理坐标属性和时间段属性。分析者可以按地点聚合，也可以按时间切片，观察同一地点在不同天气事件前后的变化。这是地图 POI 评价文本不同于其他文本数据的地方。

1.2 完整数据链路

本次实现不直接爬取地图 App 的评论页面，而是采用更稳妥的链路：

1. 调用高德开放平台“关键字搜索 API”，输入地点名称，得到 POI ID、坐标和地址。
2. 准备一份经过授权或脱敏处理的评论文本数据，保存为 CSV。
3. 用 Python 读取 CSV，清洗文本噪声。
4. 使用 jieba 分词，并过滤停用词。
5. 使用 SnowNLP 对每条评价做情感打分。
6. 结合用户星级和情感得分做交叉校验。
7. 提取关键词，输出汇总报告。

其中第 1 步依赖高德 API，第 2 到第 7 步都在本地完成。为什么要这样设计？因为高德开放平台的 Web 服务 API 目前并不提供用户评论下载能力，评论数据只能通过 App 或网页查看，直接抓取公开页面违反了平台用户协议，也不符合数据合规要求。更合理的做法是：用高德 API 获取地点基础信息，再基于自有数据源或合法授权的评论数据做文本分析。

1.3 为什么用“坎门海都花园”作为示例

这个地点来自一个真实背景：连续多次台风天气过后，地图平台上出现了关于该小区的集中评价。文章只把它当作演示样例，重点不是评价这个小区，而是展示一套分析流程。实际项目中可以替换成任意小区、商场、学校或医院 POI，方法不变。需要注意，替换地点时，也要替换对应的授权评论数据，不能直接使用本文的模拟样本。

2. 环境准备与高德开放平台配置

2.1 本地 Python 环境和依赖库

推荐使用 Python 3.9 以上版本。需要安装的第三方库如下：

在终端执行：

pip install requests pandas jieba snownlp matplotlib

如果网络速度较慢，可以指定国内镜像源，但不要把这步写成必需步骤。安装完成后，在 Python 中逐个导入验证：

import requests import pandas as pd import jieba import jieba.analyse from snownlp import SnowNLP import matplotlib.pyplot as plt print("依赖库导入成功")

如果某个库导入失败，优先检查是不是存在多个 Python 环境，pip 安装到了其他环境的 site-packages 中。建议在项目根目录创建虚拟环境后再安装依赖，避免污染系统环境。

2.2 申请高德开放平台 Web 服务 Key

使用高德 API 前需要注册高德开放平台账号，然后创建一个应用并申请 Key。选择服务类型时，要选“Web 服务”，因为关键字搜索属于服务端接口。申请完成后，控制台会显示一个 Key 字符串。

这里有一个常见误区：高德的 Key 分为 Web 服务、Android、iOS、Web 端等类型，不同类型的 Key 不能混用。关键字搜索属于 Web 服务，不能把 Android 端的 Key 拿过来直接用。申请时还要注意 API 配额，个人开发者默认有日配额限制，超出后会返回配额超限错误。

生产环境中，不要把 Key 硬编码在代码里。可以把 Key 放到环境变量中，代码运行时读取环境变量，避免提交到 Git 仓库后泄露。示例：

export AMAP_API_KEY="你的Key"

Windows 环境下使用：

set AMAP_API_KEY=你的Key

Python 读取方式：

import os api_key = os.environ.get("AMAP_API_KEY") if not api_key: raise RuntimeError("请先设置环境变量 AMAP_API_KEY")

2.3 连通性检查

拿到 Key 后，先用一个最简单的请求验证 API 是否可用。高德关键字搜索接口的基础路径是https://restapi.amap.com/v3/place/text，必须包含key和keywords参数。

curl "https://restapi.amap.com/v3/place/text?key=你的Key&keywords=坎门海都花园&city=台州&output=json"

正常返回结果中status为1，pois数组存放候选地点。如果返回status为0，读取info字段查看错误原因，常见错误有INVALID_USER_KEY和USERKEY_PLAT_NOMATCH。前者表示 Key 无效，后者表示 Key 类型与服务端接口不匹配。

3. 用高德 API 获取目标地点的基础信息

3.1 关键字搜索接口参数详解

关键字搜索接口支持以下常用参数：

其中keywords越精确，返回结果越容易匹配。如果不传city，接口会在全国范围内搜索，同名地点多时会返回大量无关 POI。示例地点位于浙江台州玉环，因此city可以传“台州”，也可以直接传“玉环”。

types参数如果不确定，可以先不传。若搜索小区时返回多个类型相同或相似的候选，再用types缩小范围。POI 类型编码表很长，不建议手动记忆，按需查阅高德官方文档即可。

3.2 封装 POI 查询函数

下面封装一个查询函数，输入地点关键词，返回第一个匹配成功的 POI 信息。

import os import requests import json def get_poi(keywords, city=""): api_key = os.environ.get("AMAP_API_KEY") if not api_key: raise RuntimeError("请先设置环境变量 AMAP_API_KEY") url = "https://restapi.amap.com/v3/place/text" params = { "key": api_key, "keywords": keywords, "city": city, "offset": "10", "page": "1", "extensions": "base", "output": "json" } resp = requests.get(url, params=params, timeout=10) data = resp.json() if data.get("status") != "1": print("接口调用失败，错误信息：", data.get("info")) return None pois = data.get("pois", []) if not pois: print("未找到匹配 POI") return None first = pois[0] location = first.get("location", "") lng, lat = location.split(",") if location else ("", "") return { "name": first.get("name"), "poi_id": first.get("id"), "address": first.get("address"), "cityname": first.get("cityname"), "adname": first.get("adname"), "lng": lng, "lat": lat }

location字段在高德 API 中返回的顺序是“经度,纬度”，与直觉相反，解析时不要搞混。调用方只需要拿到经纬度，用于后续展示或地图打点。

3.3 运行结果与候选 POI 去重

在项目中运行：

poi = get_poi("坎门海都花园", "台州") print(json.dumps(poi, ensure_ascii=False, indent=2))

正常输出类似：

{ "name": "海都花园", "poi_id": "B000XXXXXXXX", "address": "玉环市坎门街道解放路", "cityname": "台州市", "adname": "玉环市", "lng": "121.2XXXX", "lat": "28.0XXXX" }

实际搜索时，关键词“坎门海都花园”可能匹配到“海都花园”而不是全名，也可能返回多个同名 POI。这时不能盲目取pois[0]，建议把前几个候选打印出来，对比address和adname字段。如果候选 POI 分布在多个城市，优先选择目标城市下的结果；如果同一城市内出现多个同名地点，再结合门牌地址判断。

这里要再次说明，高德 Web 服务 API 只提供 POI 基础信息，不包含用户评论接口。所以下一步的评论文本，必须来自合法渠道。

4. 准备评论文本数据：合法来源与示例数据

4.1 高德评论数据合规获取说明

地图 App 上的用户评论属于平台数据，受用户协议保护。普通开发者没有经过授权时，不应该使用自动化脚本批量下载评论内容。本文提到的“评论数据”，在实际项目中有三种合法来源：

1. 自有业务系统收集的用户反馈，比如物业公司自己搭建的报修登记、业主满意度调查。
2. 与平台或数据服务商签订数据合作协议后获取的授权数据。
3. 在获得用户明确授权的情况下，由用户主动导出或填写的文本。

为了演示完整流程，下面生成一份模拟评论数据，字段结构与真实授权评论保持一致。这份数据只用于说明处理逻辑，不包含真实平台用户信息，也不代表任何小区的真实情况。

4.2 构造示例评论数据集

在项目目录下新建comments.csv，内容如下：

time,user,star,content 2025-08-10 09:12,用户A,2,地下车库又进水了 物业早上才拉警戒线 2025-08-10 09:35,用户B,4,小区积水退得挺快 志愿者在清理道路 2025-08-10 10:01,用户C,3,门口的路变成池塘 出门要绕路走 2025-08-10 10:22,用户D,1,电梯停了半天才修 家里老人下楼不方便 2025-08-10 10:40,用户E,5,这次物业反应比上次快 物业管家一直在群里发通知 2025-08-10 11:05,用户F,3,车库进水 车泡了 希望能妥善解决 2025-08-10 11:30,用户G,4,清洁阿姨很辛苦 地下室淤泥很多 但一直在弄 2025-08-10 12:00,用户H,2,垃圾堆了两天没人清 有味道 2025-08-10 12:20,用户I,5,顶楼没漏水 阳台整理得很麻利 2025-08-10 13:02,用户J,3,路灯有几个不亮 晚上回来有点慌 2025-08-10 13:30,用户K,4,绿化带树倒了一棵 物业说第二天会处理 2025-08-10 14:00,用户L,2,二次供水水箱不知道有没有被淹 希望物业公示检测结果 2025-08-10 14:40,用户M,4,外面几个路口没有红绿灯 开车要让着走 2025-08-10 15:10,用户N,3,小区门禁被水泡坏了 临时开着 随便进出 2025-08-10 15:40,用户O,5,邻居自发帮忙疏通排水口 感觉小区很团结

这些文本包含“积水”“进水”“淤泥”“维修”“物业”等台风后常见关键词，也包含不同情绪表达。实际项目中的数据量会远大于此，但列结构和处理思路一致。

4.3 读取并查看基础分布

用 pandas 读取，并按星级统计数量：

import pandas as pd df = pd.read_csv("comments.csv", encoding="utf-8") print(df.shape) print(df["star"].value_counts().sort_index())

输出：

(15, 4) star 1 1 2 3 3 5 4 4 5 2 Name: count, dtype: int64

星级分布可以让我们先做一次直观判断：该时间段内中评和差评占比不低，可能需要进一步分析具体问题。但星级只能反映整体态度，不能说明用户到底在抱怨什么。只有把文本内容拆开统计，才能定位到“车库进水”“垃圾清理”等具体主题。

5. 中文短评文本预处理与分词

5.1 为什么不能直接拿原始文本做统计

中文评价没有空格分词边界，直接用整句做词频统计会把“地下车库又进水了”当成一个词，无法拆出“车库”“进水”。同时文本里可能有表情符号、多余的标点、英文字母和数字，这些噪声会影响分词和关键词提取。因此，在进入情感和主题分析之前，必须先做清洗和分词。

清洗的目标是尽量只留下有实际语义的中文词。步骤通常是：去除 URL、去除英文数字、去除 emoji、统一简化写法、去掉无意义标点。注意不要把所有标点都去掉，句尾的感叹号和问号对情感分析仍有一定作用，但在简单关键词提取场景中可以保留或去掉。

5.2 清洗函数：去噪声和统一格式

定义一个清洗函数：

import re def clean_text(text): if not isinstance(text, str): return "" # 去除 URL text = re.sub(r"http\S+|www\.\S+", "", text) # 去除 emoji 和其他非中文字符，保留中文、数字、字母、常用标点 text = re.sub(r"[^\u4e00-\u9fa5a-zA-Z0-9，。！？、；：\"\"''（）\s]", "", text) # 将连续空白符压缩为单个空格 text = re.sub(r"\s+", " ", text).strip() return text

这个函数会去掉大部分 emoji 和特殊符号。一个细节是，[^\u4e00-\u9fa5...]中的^表示取反，所以它会删除所有不在中文字符、字母、数字和常用标点范围内的字符。如果生产环境需要保留某些表情符号用于语气判断，可以单独维护一个允许列表，而不是一律删除。

对示例文本执行清洗：

df["clean_content"] = df["content"].apply(clean_text) print(df[["content", "clean_content"]].head())

输出：

content clean_content 0 地下车库又进水了 物业早上才拉警戒线 地下车库又进水了 物业早上才拉警戒线 1 小区积水退得挺快 志愿者在清理道路 小区积水退得挺快 志愿者在清理道路 2 门口的路变成池塘 出门要绕路走 门口的路变成池塘 出门要绕路走 ...

本示例数据比较干净，所以清洗后的文本变化不大。但如果是真实场景，评论里会出现大量“😭”“！！！！！”“ www.xxx.com”等噪声，清洗函数的作用会更明显。

5.3 分词与停用词过滤

jieba 支持精确模式分词，用cut方法可以得到词列表。先给地点和业务词添加自定义词典，避免“海都花园”被切成“海都”和“花园”。

import jieba # 添加自定义词，提高专有名词的识别率 jieba.add_word("海都花园") jieba.add_word("坎门") jieba.add_word("物业管家")

定义停用词集合，把“的、了、还是、很、都、又、在”等高频无语义词过滤掉：

stopwords = set([ "的", "了", "是", "在", "又", "很", "都", "也", "和", "与", "到", "就", "要", "会", "正", "但", "但", "而", "或", "之", "等", "被", "把", "让", "给", "这", "那", "我", "你", "他", "有", "没", "不", "别", "一下", "一个", "我们", "你们", "他们" ])

注意停用词表不能一刀切，“不”在“不方便”中是有实际语义的，但在“不好不坏”中又可能只是语气。简单场景下，把“不”加入停用词会导致丢失否定信息。因此这里先不加“不”，情感分析时再单独处理。

定义一个分词和过滤函数：

def tokenize(text): words = jieba.cut(text, cut_all=False) result = [] for w in words: w = w.strip() if not w: continue if w in stopwords: continue if len(w) == 1: continue result.append(w) return result df["tokens"] = df["clean_content"].apply(tokenize) print(df[["clean_content", "tokens"]].head(3))

输出：

clean_content tokens 0 地下车库又进水了 物业早上才拉警戒线 [地下车库, 进水, 物业, 早上, 拉, 警戒线] 1 小区积水退得挺快 志愿者在清理道路 [小区, 积水, 退, 挺快, 志愿者, 清理, 道路] 2 门口的路变成池塘 出门要绕路走 [门口, 路, 变成, 池塘, 出门, 绕路, 走]

分词后可以看到，短文本被拆成了有语义的词语，下一步就能直接统计高频词。

5.4 提取高频词与主题词

高频词统计用 Python 内置Counter即可：

from collections import Counter word_counter = Counter() for tokens in df["tokens"]: word_counter.update(tokens) top_words = word_counter.most_common(12) for word, count in top_words: print(word, count)

输出示例：

物业 5 车库 3 积水 3 进水 2 小区 2 道路 2 清理 2 垃圾 2 电梯 1 门禁 1 红绿灯 1 供水 1

“物业”出现次数最多，说明这段时间内居民反馈集中在物业服务响应上。更专业的做法是使用jieba.analyse.extract_tags做 TF-IDF 关键词提取，它会降低“小区”“问题”这类常见词的权重：

text_all = " ".join([" ".join(tokens) for tokens in df["tokens"]]) tags = jieba.analyse.extract_tags(text_all, topK=10, withWeight=True) for word, weight in tags: print(word, round(weight, 4))

输出可能类似：

物业 0.3421 车库 0.2810 积水 0.2645 进水 0.2131 清理 0.1982 垃圾 0.1845 电梯 0.1777 道路 0.1723 门禁 0.1601 供水 0.1589

无论用词频还是 TF-IDF，都能快速指向“物业响应、积水、清理”这几个主题。TF-IDF 更适合语料较大、通用词干扰明显的场景；小样本演示时，直接统计词频也能得出结论。

6. 情感分析：识别评价里的积极与消极信号

6.1 SnowNLP 情感得分的基本使用方法

SnowNLP 是一个针对中文文本的轻量情感分析库，内置了一个训练好的模型。输入一句文本后，sentiments属性返回 0 到 1 之间的浮点数，越接近 1 表示模型判定为正向，越接近 0 表示负向，约 0.5 附近表示中性。

from snownlp import SnowNLP df["sentiment"] = df["clean_content"].apply(lambda x: SnowNLP(x).sentiments) print(df[["content", "star", "sentiment"]].head(5))

输出示例：

content star sentiment 0 地下车库又进水了 物业早上才拉警戒线 2 0.2213 1 小区积水退得挺快 志愿者在清理道路 4 0.6835 2 门口的路变成池塘 出门要绕路走 3 0.4290 3 电梯停了半天才修 家里老人下楼不方便 1 0.1132 4 这次物业反应比上次快 物业管家一直在群里发通知 5 0.8451

可以看出，星级低、内容负向的评论，情感得分也低；星级高、内容偏正向的评论，情感得分较高。这说明 SnowNLP 在中文短评上能提供一定区分度。

6.2 处理短文本的反讽与幽默表达

标题中提到的“奇萌评价”，指的就是那些用幽默、反讽、夸张语气表达真实问题的短文本。比如“门口的路变成池塘，欢迎来小区看海”，表面轻松，实际是在表达积水问题严重。对这类文本，SnowNLP 很可能会给出一个偏中性的分数，因为它无法理解“欢迎来看海”背后的反讽含义。

简单处理方式是把情感判断拆成两层：

1. 先用 SnowNLP 得到基础情感分。
2. 再根据业务关键词表修正：如果文本中出现了“积水、泡水、垃圾、停水、被困、受伤”等强负向词，无论基础情感分多高，都标记为负向或至少进入人工复核清单。

示例实现：

negative_words = [ "积水", "进水", "泡水", "停水", "垃圾", "停电", "损坏", "被困", "受伤", "消毒", "臭", "堵", "漏", "塌", "倒" ] def adjust_sentiment(row): text = row["clean_content"] score = row["sentiment"] hit_negative = any(word in text for word in negative_words) if hit_negative and score > 0.6: # 可能为反讽或调侃，标记为需要复核 return "负向(需复核)" if score >= 0.6: return "正向" if score <= 0.4: return "负向" return "中性" df["sentiment_label"] = df.apply(adjust_sentiment, axis=1) print(df.groupby("sentiment_label").size())

输出示例：

sentiment_label 中性 5 正向 4 负向 5 负向(需复核) 1 Name: count, dtype: int64

这类关键词规则虽然朴素，但有一个好处：可解释性强。团队成员看到“负向(需复核)”时，能直接理解判断依据。它不能替代模型，却能作为模型上线前的兜底逻辑。

6.3 情感结果汇总与交叉分析

把星级和情感得分放在一起看，可以发现数据质量是否正常。如果某条评论给了 5 星，但情感得分只有 0.2，多半是打分与文本不一致，可能是用户在星级上误操作，也可能是文本为反讽。这类数据应该单独列出来人工复核。

analysis = df[["time", "user", "star", "sentiment", "sentiment_label", "content"]].copy() analysis["情感矛盾"] = ((analysis["star"] >= 4) & (analysis["sentiment"] < 0.4)) | \ ((analysis["star"] <= 2) & (analysis["sentiment"] > 0.6)) print(analysis[analysis["情感矛盾"]])

输出：

time user star sentiment sentiment_label content 2 2025-08-10 10:01 用户C 3 0.4290 中性 门口的路变成池塘 出门要绕路走

本示例没有明显的大矛盾，但会把这部分逻辑保留。在实际项目中，这一列表通常是需要物业运营方重点跟进的对象。

最后生成一份汇总报告，按星级、情感标签统计条数，并保存为 Excel：

report = df.groupby(["star", "sentiment_label"]).size().reset_index(name="count") report.to_excel("反馈分析汇总.xlsx", index=False) print(report)

这会输出一张包含“星级、情感标签、条数”的表格。连同前面的高频词，已经可以形成一份简要反馈摘要。

7. 常见问题排查

7.1 高德 API 返回错误码

调用关键字搜索接口时，最常遇到以下错误：

排查顺序是：先看返回 JSON 中的status和info，再检查 Key 是否正确，最后检查参数类型。不要只凭 HTTP 状态码判断，高德接口即使业务失败，HTTP 状态也往往是 200。

7.2 POI 匹配不到或匹配到错误地点

输入“坎门海都花园”没有返回结果时，先尝试简化关键词，去掉“坎门”“海都花园”中的修饰词。使用“海都花园”可能更容易命中。如果结果列表里出现多个同名的不同小区，需要在候选结果中过滤adname，确保目标 POI 属于玉环市。另一个思路是打开高德地图 App，手动搜索目标地点，把地图展示的名称、地址复制下来作为 API 的keywords，往往能提高匹配率。

7.3 jieba 把专有名词切碎

“海都花园”可能被切成“海都”和“花园”，“坎门”可能被切成“坎”和“门”。解决方法是在分词前调用jieba.add_word("海都花园")。如果自定义词表较大，可以单独写一个词典文件，用jieba.load_userdict加载。加载后要重新执行分词，因为加载操作只影响后续调用，不会改变已经生成的 results。

7.4 SnowNLP 评分全部集中在 0.5 附近

SnowNLP 的默认模型是在商品评论、微博等语料上训练的，和社区物业服务评价的领域并不完全匹配。出现评分集中在 0.5 附近时，说明文本中的特征词没有被模型充分识别。不要只看绝对值，可以先把同一批文本按得分排序，观察排名是否符合业务直觉；如果整体排名仍有区分度，就可以继续使用。若排名也不可靠，有两种改进方向：收集本领域标注语料微调或者自训练一个简单分类器；或者在 SnakeNLP 基础上叠加关键词规则。

7.5 CSV 读取/保存时中文乱码

Windows 环境用 Excel 打开 CSV 时，常常因为 UTF-8 编码猜错而出现乱码。建议读取时明确指定encoding="utf-8"，写入时使用encoding="utf-8-sig"。例如：

df = pd.read_csv("comments.csv", encoding="utf-8-sig")

Python 代码文件本身也统一保存为 UTF-8。如果仍然乱码，先确认原始 CSV 文件是不是 ANSI 编码，再用文本编辑器另存为 UTF-8。

8. 从演示脚本到生产落地的建议

8.1 数据合规与隐私保护

地图评论数据是否能拿来做分析，核心要看数据来源是否合规。如果使用自有业务系统的评论，需要确保用户协议中已经写明数据会被用于分析；如果使用第三方平台数据，必须获得明确授权。分析前还要做脱敏处理，移除用户的手机号、昵称、头像等个人信息。示例代码中的user字段在生产环境应该替换为脱敏 ID，不能直接保存用户原始账号。

8.2 工程化改造：调度、日志与结果入库

演示脚本把所有步骤写在一个文件里，便于阅读。生产环境至少需要拆分模块：api_client.py负责高德接口调用，text_processor.py负责清洗分词，emotion.py负责情感分析，report.py负责输出。每个模块都要有日志，记录处理了多少条文本、跳过多少无效数据、情感分析耗时多少。

如果希望定时运行，可以用系统的 crontab 或定时任务工具，每天将新增评论汇总到数据库表，再触发分析任务。同时要做失败重试，因为高德 API 偶尔会因为网络抖动返回超时，简单重试一次可以降低偶发失败概率。

8.3 模型提升方向

SnowNLP 适合入门和快速验证，但它不是专门为地图 POI 评价训练的模型。更稳妥的方案是，先通过本文的轻量方法跑一段时间，积累一批已经标注好正负情感的文本，再用这些文本训练一个简单的朴素贝叶斯分类器，或者使用 BERT 类中文预训练模型做微调。关键词规则可以继续保留，用于捕获模型容易忽略的反讽和领域词。

模型评估时，不建议只用准确率，还要看每条错误样本的分布。比如模型把“反应比上次快”判成正向，把“车库进水”判成中性都算错误，但前者是模型误判，后者则可能是领域知识不足。把这些错误样本记录下来，作为下一轮优化依据。

8.4 一条可复用的执行清单

在正式项目启动前，逐项确认以下内容：

1. 是否已经获得评论数据的合法使用授权，是否完成了必要脱敏。
2. 高德 Web 服务 Key 是否通过环境变量注入，是否配置了配额告警。
3. 评论 CSV 中是否包含时间、用户脱敏 ID、星级、正文四个必要字段。
4. 停用词表是否需要加入本地点常见的专有名词，例如小区名、物业公司名。
5. 是否已经把“积水、泡水、垃圾、停电”等业务负向词维护成配置项。
6. 是否有人工抽检机制，对“星级与情感得分矛盾”的样本进行复核。
7. 分析结果是否有下游消费方，例如物业整改工单、社区服务周报。

回到开始的那批地图评价，它们之所以值得分析，是因为短文本背后有相对具体的诉求。无论是物业公司处理积水报修，还是社区管理者关注路灯和门禁故障，都能从高频词和情感统计中找到线索。本文实现的最小链路已经能做这件事，后续需要补充的是更多合规数据、更准的领域模型和更稳定的任务调度，让分析结果真正进入日常管理流程。