shield_lock
JinDaGe
← Back to skills
extension
Category: Data & AnalyticsNo API key required

卖点挖掘机

评价驱动卖点挖掘机。当用户要求分析某款商品的评论、评价、口碑来发掘产品卖点时触发。触发词包括但不限于：卖点挖掘、卖点发掘、评论分析、评价分析、帮我看看XX的评论、XX用户评价、挖掘卖点、产品卖点、消费者洞察、口碑分析、评价反馈分析。输入一个具体商品名称，自动从全网采集真实评价数据，生成结构化卖点发掘报告。数据必须真实采集，严禁捏造。

personAuthor: user_ae3e4973hubcommunity
downloadDownload package

卖点挖掘机 — Selling Point Miner

Overview

基于全网真实用户评价，自动发掘产品卖点、识别消费场景、对标竞品的分析工作流。输入一个商品名称，输出一份可直接交付的卖点发掘报告。

核心原则

数据真实性底线

  • 所有数据必须来自真实采集，严禁凭空捏造评价内容、评分、销量、用户评论
  • 搜索不到数据时，如实告知用户并说明哪些平台未获取到信息
  • 每条引用必须附带来源 URL
  • 引用原文时保持原始表述，不得自行编造"用户评价"
  • 如需推断趋势，必须明确标注"基于有限样本的推测"，并说明样本量

工作流总览

用户输入商品名称
       │
       ▼
  Step 1: 商品身份确认（品牌+品类+规格）
       │
       ▼
  Step 2: 多平台评价采集（web_search + web_fetch）
       │
       ▼
  Step 3: 评价数据交叉验证与分类
       │
       ▼
  Step 4: 卖点提炼与场景发掘
       │
       ▼
  Step 5: 竞品对标分析
       │
       ▼
  Step 6: 生成报告（Markdown）

Step 1: 商品身份确认

在采集数据前，先确认商品的准确身份，避免混用不同上市主体/规格。

操作步骤

  1. 搜索确认：用 web_search 搜索 "{商品名称} 品牌 公司 规格" 确认：

    • 正确的品牌名和所属公司
    • 产品品类定位
    • 主要规格/口味/型号
    • 主要销售平台（抖音/淘宝/京东等）

  2. 输出确认：向用户简要展示确认结果，格式：

确认分析对象：
- 品牌：XXX
- 品类：XXX
- 主销平台：XXX
- 主要规格：XXX

是否正确？如需调整请告知。

如果用户提供了更具体的商品信息（如指定口味、规格、平台），优先使用用户提供的信息。

Step 2: 多平台评价采集

采集平台优先级

| 优先级 | 平台 | 数据类型 | 搜索方式 | |--------|------|----------|----------| | 1 | 抖音 | 种草视频评论、店铺评分、直播数据 | web_search + web_fetch | | 2 | 小红书 | 真实使用体验、对比测评、避雷帖 | web_search + web_fetch | | 3 | 淘宝/天猫 | 买家评价、追评、差评 | web_search + web_fetch | | 4 | 京东 | 好评率、晒单评价、差评分析 | web_search + web_fetch | | 5 | 搜索引擎 | 综合口碑、媒体评测、论坛讨论 | web_search | | 6 | 行业媒体 | 竞品分析、品类趋势、市场报告 | web_search + web_fetch |

搜索策略

对每个平台，执行 2-3 轮搜索，覆盖不同维度：

第一轮：商品基础口碑

搜索词："{商品名称} 评价"
搜索词："{商品名称} 怎么样"
搜索词："{商品名称} 好不好"

第二轮：平台特定搜索

抖音："{商品名称} 抖音 评价"
抖音："{商品名称} 抖音 评论"
小红书："{商品名称} 小红书 测评"
淘宝："{商品名称} 淘宝 买家评价"
京东："{商品名称} 京东 评价 好评率"

第三轮：深度/差评/场景

"{商品名称} 差评"
"{商品名称} 缺点"
"{商品名称} 口碑"
"{商品名称} 值得买吗"

web_fetch 使用规范

搜索结果中，对以下类型页面优先使用 web_fetch 获取详细内容：

  • 商品评价聚合页（如什么值得买、辣妈帮等）
  • 博客/自媒体评测文章（有实际使用体验）
  • 行业分析/竞品对比文章
  • 问答平台（知乎、百度知道）相关帖子

注意：web_fetch 可能被部分网站拦截。如果失败，记录失败并跳过，不要重试超过 2 次。

数据记录格式

采集过程中，每条有效数据记录为：

- 平台：[抖音/小红书/淘宝/京东/其他]
- 类型：[好评/差评/中性/种草/评测]
- 原文摘要：[用户原话或近原话引用]
- 来源URL：[具体链接]
- 互动量（如有）：[点赞数/评论数/播放量]

Step 3: 评价数据交叉验证与分类

分类维度

将采集到的评价按以下维度归类：

  1. 正面评价（种草/好评/推荐）
  2. 负面评价（差评/投诉/避雷）
  3. 中性评价（客观描述/优缺点并存）
  4. 场景绑定（用户在什么场景下使用）

关键词频次统计

从评价中提取高频关键词，统计出现频次并标注情感倾向：

| 关键词 | 出现次数 | 情感倾向 | 来源平台 | |--------|----------|----------|----------| | ... | ... | 正面/负面/中性 | ... |

仅统计真实出现的词语，不要自行推测。

Step 4: 卖点提炼与场景发掘

卖点提炼方法

从评价数据中提取卖点，遵循以下逻辑：

  1. 高频正面词 → 直接卖点：用户反复提到的正面特征
  2. 意外惊喜 → 差异化卖点：用户"没想到"的体验（如"没想到这么好喝"）
  3. 复购表达 → 信任卖点：用户说"回购""一直买"说明的核心价值
  4. 对比竞品 → 竞争卖点：用户主动拿它和别的产品对比时的优势表述
  5. 负面反馈的反面 → 补强卖点：差评中暴露的不足，反过来说明品牌在某些方面做得好

每个卖点的标准格式

### 卖点 X：[一句话标题]

**评价证据**：
- [用户原话引用 + 来源]

**可强化方向**：
> [分析说明]

**建议话术**：
> *"品牌可用的传播话术"*

消费场景发掘

从评价中提取用户自发提到的使用场景，并识别品牌尚未覆盖的空白场景。

Step 5: 竞品对标分析

操作步骤

  1. 从评价中提取用户主动提到的竞品名称
  2. 搜索该品类的头部竞品（3-5个）
  3. 对比维度：价格、口味/规格、渠道表现、卖点覆盖

竞品矩阵格式

| 维度 | 目标商品 | 竞品A | 竞品B | 竞品C | |------|----------|-------|-------|-------| | ... | ... | ... | ... | ... |

Step 6: 生成报告

报告结构

严格按照 references/report-template.md 中定义的模板生成最终报告。

输出规范

  1. 报告以 Markdown 格式写入工作区
  2. 文件命名：{商品名称}-评价驱动卖点发掘.md
  3. 使用 open_result_view 展示报告
  4. 向用户口头总结核心发现（3-5 条要点）

常见问题处理

Q: 某个平台搜索不到数据怎么办？

如实记录"该平台未获取到有效评价数据"，不要编造。转向其他平台继续采集。

Q: 数据量太少怎么办？

  • 降低分析颗粒度，从"量化统计"转为"定性洞察"
  • 明确标注"基于有限样本"的局限性
  • 建议用户补充更多渠道线索

Q: 评价内容矛盾（有说好有说差）怎么处理？

  • 将矛盾点同时记录，不偏袒任何一方
  • 分析矛盾的可能原因（如不同批次、不同口味、不同渠道）
  • 在卖点发掘时标注"争议点"

Q: 用户输入的是品类名而非具体商品？

  • 先确认用户想分析的具体品牌/商品
  • 如果用户确实想分析整个品类，调整搜索策略为品类维度

Resources

references/

  • report-template.md — 报告标准模板，定义最终输出的 Markdown 结构
  • search-strategy.md — 各平台搜索策略详细指南，含搜索词模板和 URL 模式

scripts/

（无脚本依赖，全部通过 web_search + web_fetch 完成）