User comment analysis

用户评论分析

When to Use

• 用户有一批评论 / 弹幕 / 私信 / 反馈，想提炼痛点信号、需求推断、情绪、高频问题。
• 用户做内容复盘、产品优化、选题灵感挖掘。
• 用户说："看看这些评论在说什么""从评论里提炼需求""评论区情绪怎么样"。

When NOT to Use

• 主动通过问卷 / 访谈挖掘需求 → 用 user-needs-discovery（R06）。
• 识别可能升级的负面舆情与争议 → 用 public-opinion-risk-identification（R08）。
• 撰写对单条评论的公开回复 → 用 comment-reply（P03）。
• 分类并制定负面评论处理方案 → 用 negative-comment-handling（P04）。

Inputs

必要信息：

1. 评论文本（原始粘贴或整理后的列表）。
2. 可选上下文：对应内容主题、发布平台、分析目的、样本周期。

缺失处理：无上下文时仅做通用归纳并标"假设：默认分析目的是内容优化"；若评论文本完全为空，集中询问一次（仅问能否提供评论内容）。

Workflow

1. 隐私匿名化：对含个人姓名、联系方式、账号 ID 等可识别信息的评论先做匿名化（替换为"用户 A"等）再分析。
2. 清洗去噪：剔除广告、疑似垃圾信息或疑似机器人内容（无法确认是否刷量时标"待验证"）、无意义表情，保留有效评论；重复评论保留为频次信号（标注出现次数），不剔除。
3. 情绪分层：正向 / 中性 / 负向，给出占比（标样本量；小样本优先用实际数量，如"正 6 / 中 4 / 负 2"，不输出无必要精确百分比）。
4. 评论意图分类（与情绪作为两套独立分类，不混在同一组比例）：求资料 / 提问 / 认可 / 投诉 / 建议 / 购买咨询 / 其他，给出分布（小样本用实际数量）。
5. 痛点信号与需求推断：从负向与疑问中提炼「痛点信号」与「需求推断」，标注推断；不写成确证事实。
6. 高频问题汇总：统计重复出现的具体问题（如"怎么买""第几集"），保留频次。
7. 行动建议：给内容 / 产品 / 运营下一步（标"建议"）。
8. 自检：是否含无来源数字、事实与推断是否混淆、是否越界、结论是否可回溯到证据。

Output

Markdown 分析，至少包含：

• 样本概况（数量 / 周期 / 平台 / 匿名化说明）
• 情绪分布（正 / 中 / 负，标样本量，小样本用实际数量）
• 评论意图分布（与情绪作为两套独立分类，不混入情绪比例）
• 痛点信号与需求推断清单（排序，标推断）
• 高频问题 TOP（带出现次数或频次判断）
• 行动建议（建议，1–3 条）

证据规则

• 默认仅分析用户提供的评论 / 弹幕 / 私信 / 反馈材料；仅当用户明确要求补充公开背景时，才调用搜索、浏览器或外部数据工具检索公开来源。涉及个人信息的材料须先匿名化，不得直接提交外部工具（见 Boundaries）。
• 来源优先级：用户提供的原始评论、弹幕、私信和反馈样本 > 用户补充的业务上下文 > 用户明确要求后检索的公开背景资料（默认不主动外部搜索）。
• 三级标注：区分「已观察事实（用户原话）」「证据支持的推断（标"推断"）」「未知（标"待验证"）」。
• 来源冲突：冲突时并列展示各方观点与证据强弱，不强行归一。
• 周期与日期：引用数据须标注数据周期与检索日期。
• 样本说明：给出样本范围、周期、数量与可信度；小样本不输出伪精确比例，改用"少量样本 / 频次信号"。

Boundaries

• 情绪与意图属"推断"，须标注基于样本，不夸大代表性。
• 痛点信号 / 需求推断非确证事实，须标"推断"。
• 含个人信息的评论须先匿名化；未经匿名化不得将含真实姓名、手机号、邮箱、账号 ID、订单号、地址或私信可识别信息的原始材料提交外部搜索或第三方工具。
• 引用代表评论须来自用户实际输入并继续保持匿名化，不得编造。
• 不夸大样本对全部用户的代表性；不编造评论内容或数据。
• 不替用户决定回复话术；行动点标"建议"。

Examples

例（虚构示例，仅示范结构，不代表真实事实）：用户输入 20 条视频评论，多问"资料在哪领""求模板"。输出：匿名化（无个人信息）→ 情绪（正向 6 条 / 中性 12 条 / 负向 2 条，合计 20 条，小样本用实际数量）→ 意图（求资料 8 条 / 提问 4 条 / 认可 3 条 / 购买咨询 2 条 / 其他 3 条，合计 20 条，与情绪分开单列）→ 痛点信号（找不到模板入口）/ 需求推断（想要可复用模板）→ 高频（"资料链接""怎么领"）→ 建议（置顶资料领取 + 做模板合集视频）。