微博评价监控
把微博的评论与评价数据变成一份能直接发给同事的舆情差评清单：负面率是多少、集中在哪些痛点、
和上期比是变好还是变差、哪几条规则已经触发了。
一、这个技能算什么
| 命令 | 算什么 | 产物 |
|---|---|---|
ingest |
读入 → 去广告 → 近似去重 → 时间排序 | clean.csv |
tag |
四维打标（产品 × 情感 × 场景 × 意图）+ 严重度推导 | tagged.csv |
cluster |
归入两层痛点树 + 原声佐证 | painpoints.md |
trend |
与基线环比 + 两比例显著性检验（z 检验） | trend.md |
alert |
按 5 类封闭规则逐条判定预警 | alerts.md |
report |
汇总成单文件网页报告（浏览器直接打开、离线可看） | review_report.html |
不做什么：不联网、不登录、不抓取、不代回复、不上传数据。数据只能由你提供。
本技能也不判断账号级信息——博主粉丝量、蓝V/黄V 认证、发布形式、更新节奏这类东西
不在正文文本里，见第九节的"未能判定"清单。
二、何时使用
- 想知道这一批评论里负面占比多少、集中在哪几个痛点上
- 想知道差评率是不是比上一期变高了、这个变化是不是统计显著的
- 想把评论区原声按痛点整理出来，直接贴进舆情周报
- 想给差评/控评监控立几条可复现的规则（而不是每天靠人肉翻评论）
- 想拿一份离线可看的网页报告发给不看 CSV 的人
不适用：需要实时监控、需要抓取微博、需要判断博主真假粉或水军账号画像时，本技能做不到
（见第九节）。
三、输入方式（全离线）
| 方式 | 用法 | 说明 |
|---|---|---|
| 粘贴文本 | --text "评论一\n评论二" |
几行到几十行，一行一条 |
| 导入 CSV | --csv 微博评论导出.csv |
后台导出的评论/评价表，表头不用改（内置别名） |
| 指定基线 | --baseline 上期.csv |
上一期导出，用于环比；给了它就按"上一期 vs 本期"比 |
| 固定时间基准 | --now 2026-09-17 |
把 3小时前、昨天、上周三 这类相对时间换算成绝对时间 |
| 时区 | --tz +08:00 |
裸时间按此时区解释，默认 +08:00 |
目录批量导入（把多份导出合并分析）本技能未实现：请先把多份导出合并成一个 CSV，
再用 --csv 导入。
四、命令
bash ${CODEBUDDY_SKILL_DIR}/run.sh ingest --csv 微博评论导出.csv
bash ${CODEBUDDY_SKILL_DIR}/run.sh tag --csv 微博评论导出.csv
bash ${CODEBUDDY_SKILL_DIR}/run.sh cluster --csv 微博评论导出.csv
bash ${CODEBUDDY_SKILL_DIR}/run.sh trend --csv 本期.csv --baseline 上期.csv
bash ${CODEBUDDY_SKILL_DIR}/run.sh alert --csv 本期.csv --baseline 上期.csv
bash ${CODEBUDDY_SKILL_DIR}/run.sh report --csv 微博评论导出.csv --now 2026-09-17
产物默认落在当前目录的 weibo-review-out/，真实路径以返回的 files 字段为准。
加 --json 拿结构化契约，不加则给人读文本。
五、微博特有的判断依据
微博的差异不在引擎里，而在本技能携带的档案（data/review.json 的词表与痛点树）
与渠道档案（data/channel.json 的别名与语态）。三个渠道共用同一份引擎代码，
所以"微博特有"就是下面这张表和它所对应的词表：
| 维度 | 微博的机制 |
|---|---|
| 语态 | 短文本为主（140 字以内），口语与情绪强烈；缩写与谐音极多（yyds、xswl、绝了），归一化不会强行展开 |
| 争论形态 | 公开转发链把观点对立放大，评论区易形成两派互撕；评论区、盖楼、两派、对线 都在场景词表里 |
| 负面表达 | 常伴 @ 官方账号与媒体，是舆情升级信号；词表里专门收了 @官方、@客服、官方给个说法、我要投诉 |
| 场景词表 | 热搜话题、超话社区、评论区争论、转发抽奖、品牌代言、粉丝应援、影视综艺、文娱追星、体育赛事、时事社会、游戏电竞、校园、职场、节日节点 |
| 痛点树里微博特有的两大类 | 舆情与控评（控评刷屏、水军痕迹、引战互撕）、明星与代言（代言翻车、粉丝控场、营销过度） |
| 预警里的微博关键词 | 控评、退货、过敏（首次达成各自阈值时触发 keyword_emergence） |
| 表头别名 | 正文列认 内容/微博正文/正文/文案/content；曝光列认 阅读量/阅读/展现量/曝光量；转发列认 转发/转发数/reposts；作者列认 昵称/作者/博主 |
| 微博没有收藏 | 渠道档案把 collects 标成 not_applicable：即使你的导出表里带了收藏列，它也不进任何计算，报告里会写"该渠道无此指标"，而不是"用户没给" |
微博的互动指标（阅读、赞、转发、评论）只用于展示与"未评估"说明：
本技能的核心结论来自正文文本，不来自互动量。给了互动量会进 clean.csv/tagged.csv，
没给就标"用户未提供"，绝不按 0 参与。
六、打标维度与取值（封闭集合）
| 维度 | 取值 | 怎么判 |
|---|---|---|
| 产品 | 17 个产品词表的取值 + 未识别 |
词典命中 |
| 情感 | 正面 / 负面 / 中性（穷尽且互斥） | 词典极性 + 否定词翻转 + 程度副词加权 |
| 场景 | 14 个场景词表的取值 + 未识别 |
词典命中 |
| 意图 | 咨询 / 投诉 / 建议 / 夸奖 / 无 |
按优先级取第一个命中；都不命中就是 无 |
| 严重度 | 高 / 中 / 低 | 由情感 × 痛点层级推导，不是单独打标 |
关于严重度，必须说清楚它是推导出来的：
| 情感 | 痛点归属 | 严重度 |
|---|---|---|
| 负面 | 命中子类（最具体一级） | 高 |
| 负面 | 只命中大类 | 中 |
| 负面 | 未归类 | 中 |
| 正面 / 中性 | 任意 | 低 |
无 与 未识别 是引擎的兜底值，不写进词表——否则"词典没命中"和"词典里真写了这个词"
就分不开了。
七、痛点与预警
痛点树是固定的两层（大类 → 子类），微博有 13 个大类、每个大类至少 2 个子类。
一条评价最多归入一个大类：子类优先于大类，仍并列时按名字排序取第一个（保证确定性）。
归不进任何节点的会被显式计为 未归类 并报告占比，不会悄悄丢掉。
预警规则是一个封闭集合，只有下面 5 种类型；本技能的档案里一共配了 12 条规则：
| 类型 | 判据 |
|---|---|
negative_rate_spike |
负面率相对基线的上升超过阈值（且要通过 z 检验的显著性） |
new_issue |
出现基线中不存在的痛点（按子类判定，各 ≥ min_count 条） |
volume_spike |
评价量相对基线上涨超过 multiple 倍 |
severity_concentration |
高严重度评价占比超过 share |
keyword_emergence |
指定词首次达成 min_count 次 |
每条规则的结果只有三种状态：已触发 / 未触发 / 无法判定。
"无法判定"（例如缺基线）与"未触发"严格区分——把算不出的说成"没问题"就是编造结论。
五种规则的判定力不一样（如实说明）
volume_spike（评价量突增，本技能档案里有 2 条，阈值 2.0 倍与 3.0 倍）必须有你显式提供的
上一期数据才有判定力，请用 --baseline 上期.csv。原因在基线怎么切：不给 --baseline 时，
基线是"本次数据的前半段"、当期是后半段，两者同源、条数几乎相同，
量比的上限就是 ceil(n/2) / floor(n/2)：
| 本次总条数 n | 前半段（基线） | 后半段（当期） | 最大量比 |
|---|---|---|---|
| 偶数（2、4、6、20…） | n/2 | n/2 | 1.00 |
| 3 | 1 | 2 | 2.00 |
| 5 | 2 | 3 | 1.50 |
| 7 | 3 | 4 | 1.33 |
据此，本渠道这两条规则在默认路径（不给 --baseline）下的实际可达性是：两条在默认路径下都不可达——3 条时量比恰好是 2.0000，而规则要求严格大于阈值。
所以不传 --baseline 时，volume_spike 可能一直显示"未触发"——这不代表没有爆发，
只代表"本次数据自己跟自己比"量不出爆发。要判断评价量是否突增，必须提供上一期导出
（trend / alert / report 都接受 --baseline）。
把阈值调低不是修法：偶数条时量比恒为 1.00，奇数条才略大于 1 且随条数增加趋近 1，
调到能触发就等于在"条数是奇数还是偶数"这种噪声上报警，比不报警更糟。
其余四种规则——negative_rate_spike / new_issue / severity_concentration /
keyword_emergence——在默认路径（不给 --baseline）下正常工作，可以放心看它们。
八、基线怎么来
trend、alert、report 要看基线。本技能档案声明的基线模式是 first_half：
- 没给
--baseline时：本次数据按时间排序后，前半段当基线、后半段当当期，两者不重叠；
产物顶部会写清"基线来源"是前半段以及切分点在哪。 - 给了
--baseline 上期.csv时：基线就是那个文件（当期是全部本次数据）。
产物顶部会写清"基线来源：用户提供的上一期文件 上期.csv（N 条）"，并回显它覆盖了档案模式。 - 时间列全缺时，
first_half切不出前半段 ⇒ 结论标无法判定（缺时间），不算，
绝不会退化成 0 基线。
九、明确的边界与局限
- 不联网、不登录、不抓取、不代回复、不上传数据。 数据只在本机读取。
- 判定基于词典与规则，没有在真实语料上校准过：词表与阈值来自本项目的行业经验整理，
因此本技能不声称任何准确率或召回率，也不保证把某条评价判成负面就是对的。
想验证就先人工标注一批自己的数据再对照。 - 账号级信息不在正文文本里，本技能不判：博主粉丝量、蓝V/黄V 认证、是否水军、
发布形式、更新节奏、转发链深度、热搜热度值、话题阅读量——这些需要正文之外的字段，
本技能既不算、也不猜。 - 可能"未能判定"的维度（这是如实说明，不是缺陷）：
- 产品：正文里没出现任何产品词表中的词 ⇒
未识别； - 场景：正文里没出现任何场景词表中的词 ⇒
未识别； - 意图：四个意图都不成立 ⇒
无（无是"都不成立"，不是"漏标"）； - 痛点：命不中任何节点 ⇒
未归类（占比会显式报出）； - 情感：没有任何情感词命中 ⇒
中性（三值必须穷尽，"没有情感证据"就是中性）。 severity是推导量：它只由"情感 × 痛点层级"决定，不是对严重程度的独立判断，
也没有经过人工校准。- 缺失的指标不按 0 算：评论文本导入完全不需要互动指标；给了就展示，没给就进"未评估"
清单并说明缺什么，不用 0 顶替。微博的"收藏"是渠道没有的指标，措辞与"用户没给"
严格区分。 - 相对时间只在给了
--now时才换算，换算基准会回显；不读系统时钟，
所以同一份输入两次运行会得到逐字节相同的产物。 - 不做预测、不承诺效果：本技能只描述这一批数据里已经出现的东西。
十、进一步阅读
references/data-sources.md：微博的评论/评价数据从哪来（合法、零门槛、不抓取）references/review-method.md：打标、痛点、基线、预警的具体算法与已知局限
