企业官网建设流程全解析

简介：基于百度云API与Python的微博评论情感偏向分析工具包，面向社情舆情分析、市场调研及自然语言处理入门者，解决微博评论大规模情感倾向判定的效率问题。压缩包内含15个文件，覆盖Python脚本、XML配置、Excel表格、CSV数据集等类型；其中apiGetSheet.py负责调用百度API计算评论文本情感得分，sheetGetValue.py对返回分值做标准化处理，CSV与XLS文件则提供可直接复用的评论样本和结果表，适合对照学习完整分析流程。已有202人学习，资源包仅421KB，轻量实用。通过学习可掌握百度云接口调用、情感得分映射及标准化处理思路，同时了解数据集字段组织方式和脚本协作逻辑，为后续扩展到舆情监测或产品口碑分析打下基础。

1. 用百度云API给微博评论判情绪：先想清楚这件事值不值得做

品牌方发布会后两小时，微博评论区涌进上千条反馈；产品上线新功能，用户是夸还是骂，运营主管要你在下班前给个结论。逐条读不现实，关键词统计又分不清“太烂了”和“太棒了”这种带情绪的短句。省事的路径就是用Python把微博评论抓下来，调百度云API里的情感倾向分析接口，逐条算正面、中性、负面概率，最后汇总成占比和情感指数。这个方案适合已经会用Python写脚本、但没接触过NLP的运营、产品和技术，核心不是调通API——调通只是半小时的事，难点在数据清洗、限速和结果置信度的把握。先泼盆冷水：接口返回的是概率不是定论，置信度低的样本如果直接算进统计，结果比不分析还误导人。这篇就把整条路完整走一遍。

2. 开通百度云API并搭好Python环境：认证、鉴权与三个必须装的库

2.1 别走错门：情感倾向分析在百度智能云，不在百度网盘

标题里写的“百度云API”是很多人第一个踩坑的地方。百度云这个词被两种东西占着：普通人熟悉的百度网盘，和做云服务的百度智能云。做情感分析要用的，是后者里面的AI开放平台，具体产品叫“情感倾向分析”，归属在自然语言处理大类下。

老版本入口在ai.baidu.com，新控制台在百度智能云里，都能搜到“情感倾向分析”。进去之后第一眼看到的是产品介绍和价格说明：有免费调用量，够个人做小规模分析和试验；超出后按次计费，单价很低，抓几百条评论花不掉几块钱。这里值个提醒：不要一上来就买套餐，先用免费额度把脚本跑通，再决定要不要扩容。

这个接口做的事很窄：输入一段中文文本，输出它属于正面、中性还是负面，同时给出置信度和正负概率。它不关心评论是谁发的、有没有人点赞，也不做多模态情感分析（不需要传图片和音频）。对微博评论这种短文本，它的效果是够用的；反而是在长文本、反讽和网络梗上容易翻车，这些坑放到第5章细说。

2.2 创建应用：只在控制台点几下，拿到API Key和Secret Key

用百度账号登录控制台，在自然语言处理分类下找到情感倾向分析，第一次进入会让你创建应用，应用名字随意写，比如“weibo_sentiment”。创建完成后，应用详情页里有两串很长的字符串：API Key和Secret Key。

这两串东西的用途得先立住：它们不是拿来直接调情感分析接口的，而是用来换取访问令牌access_token。把API Key想象成门禁卡号，Secret Key是门禁卡密码，access_token是刷卡后发的临时通行证。这个通行证有有效期，过期就重新刷一次门禁——所以代码里必须有一个获取token的函数，而不是把token写死在文件里。

我见过不少人把Secret Key直接贴到代码里然后传到公开仓库，第二天就收到恶意调用账单。别干这事。本地测试无所谓，脚本一旦要入库或者给同事看，至少用环境变量读，比如os.environ["BAIDU_SECRET_KEY"]，别把密钥跟在代码后面走。

2.3 Python环境与依赖：requests、pandas、matplotlib，按需装

代码基于Python，环境要求不高，3.8以上的版本都行，3.7也能跑只是个别语法别用。如果你刚接触python入门，先确认安装时勾选了Add Python to PATH，否则在cmd里敲python会提示找不到命令；装完之后用python -m pip --version验证pip能用。

下面四个库是这个方案的主力，各自定位很明确：

python -m pip install requests pandas matplotlib openpyxl

逻辑说明：requests负责所有HTTP请求，包括换token、抓微博评论、调情感分析；pandas是后面数据清洗和统计的主力，它内部会依赖numpy，不需要单独装numpy；matplotlib是最后一章画分布图用的；openpyxl是pandas把结果写成Excel时背后的引擎，如果你只存CSV可以省掉。

参数说明：用python -m pip而不是直接pip，能确保装进当前解释器而不是系统里的另一个Python，这点在装了多个python版本时会救命。装完检查一下，命令行里执行python -c "import requests, pandas; print('ok')"，不报错就是环境齐了。这里再补一句：pycharm里最好给当前项目单独建一个虚拟环境，避免和别的项目互相污染依赖版本。

2.4 写一个鉴权函数：token是唯一会过期的钥匙

环境就绪后，第一个要落地的代码就是从API Key和Secret Key换token。这是所有百度云API调用的公共前置步骤，写一次后面所有脚本都能复用。

import requests API_KEY = "你的API Key" SECRET_KEY = "你的Secret Key" def get_access_token(api_key=API_KEY, secret_key=SECRET_KEY): url = "https://aip.baidubce.com/oauth/2.0/token" params = { "grant_type": "client_credentials", "client_id": api_key, "client_secret": secret_key, } resp = requests.post(url, params=params, timeout=10) data = resp.json() if "access_token" not in data: raise RuntimeError(f"换取token失败: {data}") return data["access_token"] if __name__ == "__main__": token = get_access_token() print(token[:20] + "...")

逻辑说明：百度AI开放平台的OAuth2.0流程里，grant_type固定是client_credentials，client_id填API Key，client_secret填Secret Key，请求成功后返回的JSON里就是access_token。整个换token过程不需要额外权限，因为你已经在网页端登录过的账号里创建了应用。

参数说明：timeout设成10秒，避免网络卡住让脚本挂死；打印前20位是为了确认拿到了token，不要整串打出来。如果返回结果里没有access_token，多半是API Key或者Secret Key复制错了，回控制台重新复制一遍，注意别把空格也带进去。

token的有效期百度侧不是永久，过期后接口会返回特定的错误码，到时不要怀疑是接口挂了，重新调一次这个函数就行。第5章会专门讲这个错误码。

3. 抓微博评论：用pycharm跑一个能翻页的爬虫，数据存成DataFrame

3.1 评论数据的正确入口：m.weibo.cn的JSON接口，不用去啃网页

微博评论没有一个对个人开发者友好的官方开放接口，开放平台那一套通常需要企业资质，申请周期长、审核严。事实上的通行做法是抓移动端网页版m.weibo.cn背后的JSON接口，它返回结构化数据，比抓静态HTML再解析省事得多。

这个接口长这样：https://m.weibo.cn/api/comments/show?id=微博ID&page=页码，返回的JSON里data.data是一个评论数组，每条评论的text字段是带HTML标签的正文，user.screen_name是用户名，created_at是发布时间，like_count是点赞数。评论总量大时接口还会返回data.max_id，用这个字段做游标翻页，比单纯页码稳定。

用pycharm跑这个脚本有个小优势：可以在resp.json()附近打断点，直接看到返回结构，理解字段比读文档快。但抓取这件事本质上是python爬虫，频率控制不好会被风控。我的习惯是每个请求之间至少间隔1秒，页面数控制在个位数，只抓公开评论，抓完存本地就不再重复请求。

3.2 第一条能跑起来的代码：带上Cookie和User-Agent把首页评论拉下来

下面的代码直接可以塞进你的pycharm脚本里。它拿了第一页评论，清洗后用DataFrame存下来。

import requests import re import time import pandas as pd COOKIE = "把你的微博登录Cookie整段贴这里" WEIBO_ID = "微博正文URL里那串数字" HEADERS = { "User-Agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) " "AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 MicroMessenger/8.0.32", "Cookie": COOKIE, "Referer": "https://m.weibo.cn/", } def clean_comment(raw): text = re.sub(r"<[^>]+>", "", raw) text = re.sub(r"@[\u4e00-\u9fa5a-zA-Z0-9_-]+", "", text) text = re.sub(r"#[^#]+#", "", text) return text.strip() def fetch_comments(wid, max_pages=5): results = [] for page in range(1, max_pages + 1): url = "https://m.weibo.cn/api/comments/show" params = {"id": wid, "page": page} resp = requests.get(url, params=params, headers=HEADERS, timeout=10) if resp.status_code != 200: print(f"HTTP {resp.status_code}，停止翻页") break raw = resp.json() comments = raw.get("data", {}).get("data", []) if not comments: break for item in comments: results.append({ "user": item["user"]["screen_name"], "text": clean_comment(item.get("text", "")), "created_at": item.get("created_at", ""), "like_count": item.get("like_count", 0), }) print(f"第{page}页，共{len(comments)}条") time.sleep(1) return pd.DataFrame(results) if __name__ == "__main__": df = fetch_comments(WEIBO_ID, max_pages=5) df.to_csv("weibo_comments.csv", index=False, encoding="utf-8-sig") print(df.shape)

逻辑说明：fetch_comments里每翻一页就构造一次GET请求，params带id和page；响应里data.data是评论列表，空列表说明翻到底。逐条提取字段时做了一层防御，item.get("text", "")拿不到text不会抛异常。全程用一个HEADERS字典，保证Cookie、UA、Referer三个关键头每次请求一致。

参数说明：COOKIE需要你用自己的微博登录态，从浏览器F12的Network面板里随便找一个m.weibo.cn的请求，复制请求头里的Cookie整段。这种Cookie有效期短，可能过几个小时就失效。max_pages控制最大翻页数，个人做情感分析几十页评论已经足够，别贪多，爬太多页风控概率直线上升。

3.3 翻页游标与清洗规则：max_id才是靠谱的下一页

上面的代码用page字段翻页，其实接口真正的翻页游标是data.max_id。第一页返回的max_id是下一页的起点，第二页请求带上max_id参数而不是page=2，在评论数很多的微博下更稳定。改造起来不复杂：

def fetch_comments_by_max_id(wid, max_pages=5): results = [] max_id = "" for _ in range(max_pages): url = "https://m.weibo.cn/api/comments/show" params = {"id": wid} if max_id: params["max_id"] = max_id resp = requests.get(url, params=params, headers=HEADERS, timeout=10) raw = resp.json() comments = raw.get("data", {}).get("data", []) if not comments: break for item in comments: results.append({ "user": item["user"]["screen_name"], "text": clean_comment(item.get("text", "")), "created_at": item.get("created_at", ""), "like_count": item.get("like_count", 0), }) max_id = raw.get("data", {}).get("max_id", "") if not max_id: break time.sleep(1) return pd.DataFrame(results)

清洗是另一个关键动作。评论正文是HTML片段，包含p标签、a标签，还有赤裸裸的表情占位符比如[微笑]这种微博原生表情，以及@用户名链接。如果不洗直接传给情感分析接口，接口看到的是标签和噪声，判断会诡异。clean_comment里的三个正则分别解决：去标签、去@用户名、去话题词。我还会顺手把连续的表情符号替换成一个空格，免得它们黏在词中间破坏语义。

清洗有个细节值得说：re.sub(r"<[^>]+>", "", raw)对嵌套标签不一定干净，但微博评论的HTML结构简单，够用了。如果发现某些行清洗后还是带 之类的实体，再加一行把 替换成空格即可。清洗规则没有银弹，跑一次看输出再补，这是爬虫的血泪经验。

3.4 落盘成CSV：DataFrame一次搞定，Excel打开不乱码

清洗完的评论用pandas的DataFrame存下来，一是为后面接情感分析做准备，二是给自己留个后悔药——API分析结果如果不对，随时能从原始评论重新算，不用再爬一次微博。

df.to_csv("weibo_comments.csv", index=False, encoding="utf-8-sig") print(df.head()) print(df.info())

逻辑说明：encoding参数是这里最容易忽略又最影响体验的一个。默认的utf-8存CSV，Excel直接打开会中文乱码；utf-8-sig是带BOM的UTF-8，Excel和常见编辑器都能正确识别。index=False是让导出的文件不带着行号那一列，后续读回来时结构更干净。

参数说明：如果你后面想用Excel筛选，可以把to_csv换成df.to_excel("weibo_comments.xlsx", index=False)，前提是装了2.3节的openpyxl。文件里至少要有两列：评论正文和点赞数，内容用于情感分析，点赞数可以用来做加权统计——高赞评论的情绪，比零赞评论更值得关注。这个加权逻辑放到第4章一起讲。

4. 调用情感分析接口：把评论一条条变成“正/中/负”概率

4.1 请求URL与必传参数：text是唯一硬性条件，版本号别写错

读完CSV里的评论，接下来就是整个方案的核心环节：调用百度云API的情感倾向分析接口。请求方式为POST，接口地址固定，access_token放在query参数里，JSON体里只放一个text字段。

import requests TOKEN = get_access_token() API_URL = "https://aip.baidubce.com/rpc/2.0/nlp/v1/sentiment_classify" def analyze_sentiment(text, token=TOKEN): if len(text) > 500: text = text[:500] payload = {"text": text} resp = requests.post( API_URL, params={"access_token": token}, json=payload, headers={"Content-Type": "application/json"}, timeout=10, ) data = resp.json() if "items" not in data: return {"error": data.get("error_code"), "msg": data.get("error_msg")} return data["items"][0]

逻辑说明：百度这个接口的返回结构是items数组，正常情况下只有一项，包含sentiment、confidence、positive_prob、negative_prob四个字段。sentiment的取值0代表负面、1代表中性、2代表正面；confidence是这条判断的置信度，范围0到1；两个prob分别是模型给的正负面概率，加起来不一定等于1，因为还有中性部分。

参数说明：代码里先做了长度截断，超过500字符只保留前500。这是针对微博评论的实际操作，一条正常评论很少超过200字，但偶尔有长评，而接口对单条文本长度是有上限的，按字节算中文会更快触顶。保守截断比等到报错再处理省心。如果返回里没有items，说明调用失败，错误码会在error字段里，110是token问题，18是限流，后面展开。

4.2 批量跑起来：单条调用谁都会，关键是限速和重试

一条条调接口本身没有难度，真正的工程问题在于批量：几百条评论如果连发，个人应用的QPS限制很快被打爆，然后一整串请求返回错误码18。我的处理方式是每条之间sleep一下，加上遇到错误码自动换token重试一次。

import time def batch_analyze(df, text_col="text", interval=0.5): rows = [] for idx, row in df.iterrows(): result = analyze_sentiment(row[text_col]) if "error" in result: if result["error"] == 110: new_token = get_access_token() result = analyze_sentiment(row[text_col], token=new_token) else: print(f"第{idx}条失败: 错误码{result['error']}，跳过") continue merged = row.to_dict() merged.update(result) rows.append(merged) time.sleep(interval) return pd.DataFrame(rows) result_df = batch_analyze(df) result_df.to_csv("sentiment_result.csv", index=False, encoding="utf-8-sig")

逻辑说明：iterrows逐行取评论，每次调用结束后固定sleep。返回结果不再单独存列表，而是把原始行字段和情感分析字段合并成一行存进新DataFrame，这样一条评论对应一行，原始文本、情感、概率都在，后续任何统计都不用回头再对ID。

参数说明：interval=0.5意味着每秒最多两条，个人配额一般扛得住；如果你是企业认证的配额高，可以缩到0.2，否则别低于这个值——限流后一条条重试的耗时反而更久。遇到错误码110（token失效），当场重新换token重试该条，这是最常见的救火路径。其他错误码不要盲目重试，先打日志，看看是不是text太长或者文本为空。

4.3 情感偏向怎么算：占比、情感指数、置信度过滤三件套

拿到包含sentiment和confidence的表格之后，最忌讳的做法是直接统计0/1/2的条数占比就完事。正常流程是三件事一起做：整体占比、情感指数、置信度过滤。

label_map = {0: "负面", 1: "中性", 2: "正面"} result_df["label"] = result_df["sentiment"].map(label_map) pct = result_df["label"].value_counts(normalize=True) * 100 print(pct.round(1)) sentiment_score = (result_df["positive_prob"].mean() - result_df["negative_prob"].mean()) print(f"情感指数: {sentiment_score:.3f}") high_conf = result_df[result_df["confidence"] >= 0.6] print(f"高置信度样本占比: {len(high_conf) / len(result_df) * 100:.1f}%")

逻辑说明：置信度过滤是容易被忽略的一步。confidence是接口对这个判断有多大把握，遇到反讽、梗、无意义短句时confidence会掉到0.5甚至更低。把低于0.6的样本单独标出来，不参与最终占比，宁缺毋滥。情感指数用正负概率均值差，范围在-1到1之间，接近-1就是明显负面，接近1就是明显正面，0附近表示口碑分裂或中性评论多。

参数说明：0.6这个阈值是我习惯用的，你可以抽几十条自己看效果再调；数据量大时取0.7会更保守。另外加权统计也在这里做：用like_count做权重，头部评论影响更大，np.average(result_df["sentiment"], weights=result_df["like_count"])，这条可以单独算一版和普通版对比。

4.4 一条龙：从CSV读到情感结果表的完整路径

前面几段是模块化组件，实际跑的时候不需要每次都从爬虫开始。第3章存好的weibo_comments.csv在这里直接读入，跑完情感分析再存一个新文件，整个过程就是下面这几行。

df = pd.read_csv("weibo_comments.csv") df = df.dropna(subset=["text"]) df = df[df["text"].str.strip() != ""] result_df = batch_analyze(df) result_df.to_csv("sentiment_result.csv", index=False, encoding="utf-8-sig")

逻辑说明：读CSV前先做两步过滤：去掉没有text的脏行，去掉清洗后变成空字符串的行。空文本调情感分析会返回参数错误，白费一次调用配额。批处理函数接收的DataFrame里只要有text列就行，其他列它不管。

参数说明：如果你的原始评论超过1000条，建议分批跑，每批200条然后拼起来，避免中途网络异常导致整个结果丢失。内存不是问题，问题是接口稳定性。跑完去打开的sentiment_result.csv看一眼，text、sentiment、confidence三列都正常，再做4.3节的统计。

5. 避坑手册：微博风控、token失效、表情乱码，五个常见翻车点

5.1 微博返回403：Cookie失效或频率太高，第一条爬虫就翻车

现象：第3章的爬虫昨天还能跑，今天一运行就打印HTTP 403，甚至第一页就失败。

原因：微博移动端接口对Cookie时效非常敏感，登录态通常几小时内就失效；另外如果你把sleep调成0或者开多线程抓，也会因为请求频率异常被风控封掉请求头里的Cookie。

解决：打开浏览器重新访问m.weibo.cn，确认登录后重新复制Cookie。同时把请求间隔调整为固定的1到3秒，甚至可以随机一下，time.sleep(1 + random.random() * 2)。如果只是Cookie过期，复制完就恢复；如果是被风控，换一个浏览器UA冷却半小时再试。

5.2 token失效报错110：不是接口挂了，是临时通行证过期

现象：情感分析脚本跑了一会儿，突然所有请求都返回错误码110，错误信息类似Access token invalid or no longer valid。

原因：第2章换取的access_token有有效期，跟微博Cookie一样会过期。很多人把token写死在代码里，一跑一整天，到后半段必然全挂。

解决：写死token是坏习惯。每次跑脚本都先调get_access_token()重新拿；长时间运行的批处理里，把所有调用处包一层判断，错误码是110就换token重试该条。4.2节的代码已经演示了这个救火路径。这里补一张错误码速查表，贴在手边比现查文档快：

5.3 返回错误码18：QPS打满，限速那行sleep不是摆设

现象：某次为了快点出结果，把interval改成了0.05，结果跑了十几条之后剩下的请求全部返回错误码18。

原因：18在百度AI开放平台代表QPS超限，个人应用的配额通常很低，比如每秒几次甚至更低。你短时间内的并发请求数超过了配额，接口直接拒绝。

解决：interval改回0.5秒以上，已经报18的批次休息10秒再补跑。另外做一个失败清单，把返回错误的文本记录到一个CSV里，脚本结束后单独重跑这些失败样本，比在热循环里反复重试更安全。

failed = [] for idx, row in df.iterrows(): result = analyze_sentiment(row["text"]) if "error" in result and result["error"] != 110: failed.append(row["text"]) pd.DataFrame(failed, columns=["text"]).to_csv("failed.csv", index=False)

限流是保护机制，目的是不让你把后端配额打穿，顺着它走就行。等10秒再跑失败清单，通常一次就能补齐。

5.4 评论明明在骂，接口说是正面：表情和话题标签在干扰

现象：一条评论写“太烂了[吐]@官方 #新品发布会#”，清洗前直接传给接口，sentiment居然是正面或者中性。

原因：text字段里的HTML标签、微博表情、话题词、@用户名是无效噪声。表情占位符在NLP模型眼里可能被当成独立token，话题词自带褒贬又会整体拉偏判断。

解决：先清洗再调用，用3.3节的clean_comment把标签、@、话题全部去掉。表情占位符替换成空格，避免它们和前后词粘连。清洗后用print抽查10条再批量跑，别信清洗函数自己觉得已经洗干净了。一个直观的对比是：清洗前的“太烂了[吐]”和清洗后的“太烂了”，调同一个接口，结果经常是两个方向。

5.5 反讽和网络梗：置信度低的结果，宁可单独拎出来

现象：“太棒了，又双叒叕崩了”被判成正面，而且是高置信度；“我服了，这波操作真的6”被判成负面，实际可能是表扬。

原因：情感倾向分析是文本分类模型，学的是字面语义，对反讽、阴阳怪气、语境反转理解有限。网络梗一天一变，训练数据里根本没有。

解决：不追求模型理解梗，而是用置信度做闸门。凡是confidence低于0.6的结果，单独标记成“疑似反讽/梗，待人工复核”，不混进最终统计。

result_df["manual_review"] = result_df["confidence"] < 0.6 review_df = result_df[result_df["manual_review"]] print(f"建议人工复核: {len(review_df)}条")

百来条评论里这类样本通常占一成左右，人工过一遍很快，换来的是统计结果可信。如果你要处理的是新梗密集的饭圈评论，做好心理准备：这个接口只能帮你筛掉明显正负，剩下的靠人。

6. 进阶：结果可视化与一次人工抽检，让情感偏向结论真的能信

6.1 用matplotlib画一张分布图，汇报时一张图顶十句话

统计数字适合自己看，汇报时柱状图或饼图更直观，可以直接放进周报。matplotlib的用法固定，代码量很小：

import matplotlib.pyplot as plt counts = result_df["label"].value_counts().reindex(["负面", "中性", "正面"]) plt.figure(figsize=(6, 4)) plt.bar(counts.index, counts.values, color=["#d9534f", "#f0ad4e", "#5cb85c"]) plt.title("微博评论情感分布") plt.ylabel("评论条数") plt.tight_layout() plt.show()

逻辑说明：value_counts统计完用reindex固定顺序，保证柱状图永远按负面、中性、正面的顺序画，不然pandas会按出现次数排序导致每次图都不一样。颜色上红黄绿符合直觉，负面红色、正面绿色。

参数说明：title和ylabel按你的汇报场合改。更进阶一点可以用result_df里的positive_prob和negative_prob画散点图，横轴正面概率纵轴负面概率，所有点挤在哪个象限一目了然，适合判断口碑分裂程度。

6.2 唯一靠得住的验证方法：抽50条人工标注，对一下再下结论

API结果到底准不准，不看接口文档给的准确率，只看你的数据上表现如何。我的做法是每次跑完都抽50条样本，人工标一遍正/中/负，然后和API结果比对，算简单一致率。一般能达到八成以上就可以放心用占比说话；如果只有六成，先检查是不是清洗没做干净，再看是不是反讽太多。

抽样的代码一行：

sample = result_df.sample(n=50, random_state=42)[["text", "label", "confidence"]]

逻辑说明：random_state固定下来，复现和复查都方便。把sample里的text复制到一个表格里，手工标完再合并回来比对，人工标注和API的label一致就算对。这一步看起来土，但它是唯一能让你在汇报时说“我们验证过一致性”的方式。

我每做一个项目的情感分析都会留这套抽检结果，时间长了攒下不同领域的一致率区间，反而比接口文档里的数字更有参考价值。另一个习惯是跑完把原始评论、情感结果、抽检表三个文件放同一目录，任何结论都能回溯。文本情感分析不是玄学，但也别把接口输出当标准答案——希望帮到你。

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