# ReviewRadar 店铺口碑雷达

ReviewRadar 帮助一人电商卖家自动分析商品评论、差评和客服反馈，识别用户痛点，生成差评回复、客服知识库更新包、商品详情页改写建议、售后 SOP 和今日三项优先行动，让一个人也能完成客服主管、运营、品控和文案团队的工作。

如果需要快速上手、查看 FAQ、完整案例或测试用例，请参考根目录 [START_HERE.md](START_HERE.md)。

## 快速开始：你可以这样使用

### 1. 完整口碑诊断
请分析以下商品评论和客服记录，输出完整的 ReviewRadar 店铺口碑诊断报告。

### 2. 只看差评风险
请只分析以下差评，告诉我最需要优先处理的 3 类问题，并生成对应回复话术。

### 3. 生成客服知识库
请根据以下评论和客服记录，生成客服知识库更新包，包括高频问题、标准回答、触发关键词和人工介入条件。

### 4. 优化商品详情页
请根据以下用户反馈，帮我改写商品详情页中的尺码、颜色、面料、发货和包装说明。

### 5. 生成今日行动清单
请根据以下反馈，只输出今天一人店主最应该先做的 3 件事，每件事都要可执行、可追溯、有依据。

### 6. 低样本快速判断
我只有以下几条评论，请帮我做初步口碑判断，并标注低置信度和不确定结论。

## 不知道怎么开始？直接复制这句话

```text
请用简版模式分析以下评论，只输出 Top 3 问题、高风险提示和今日三项行动：
[在这里粘贴 5–10 条评论]
```

## 想看完整报告？复制这句话

```text
请用完整版模式分析以下评论和客服记录，输出完整 9 个模块，并保留证据编号、风险评分和今日三项行动：
[在这里粘贴评论 / 差评 / 客服记录 / 售后反馈]
```

## 只想生成差评回复？复制这句话

```text
请只根据以下差评生成真诚、克制、合规的回复话术，并说明哪些情况需要人工介入：
[在这里粘贴差评]
```

## 最小完整案例

### 输入示例

```text
R01【负向】等了五天才发货，客服只说帮忙催一下。
R02【负向】颜色比图片深很多，有点失望。
R03【中性】包装有点破，但商品本身还可以。
R04【负向】客服态度不错，但没有解决问题。
R05【正向】版型好看，价格也能接受。
```

### 期望输出摘要

- Top 1 问题：发货慢 / 客服无闭环，风险等级：高，置信度：中。
- Top 2 问题：颜色预期不一致，风险等级：中，置信度：中。
- Top 3 问题：包装破损，风险等级：中，置信度：低。
- 今日三项行动：
  - P0：人工跟进发货异常用户，并给出明确回访时间；
  - P1：修改详情页颜色说明，补充自然光实拍提示；
  - P2：新增包装破损处理 FAQ。

### 说明

该案例只有 5 条评论，适合第一次体验简版模式。由于样本量较小，风险判断应标注中 / 低置信度，不应输出复杂经营结论。
更多日常问题和不建议用法见 [FAQ 与反模式说明](docs/faq_and_antipatterns.md)。

## 适用场景

- 商品评论分析
- 差评归因分析
- 客服聊天记录复盘
- 售后反馈整理
- 用户痛点聚类
- 差评回复话术生成
- 客服知识库更新包生成
- 商品详情页优化和改写
- 售后 SOP 生成
- 每日 / 每周口碑运营日报生成

## 输入类型

支持用户提供以下平台无关数据：

- 商品评论列表
- 差评列表
- 客服聊天记录
- 售后反馈
- 用户主动导出的 CSV / Excel 文本内容
- 混合文本输入

处理输入前先检查隐私风险。若内容包含姓名、手机号、地址、订单号、账号 ID、物流单号等敏感信息，提醒用户先脱敏；如果用户已经提供，应在分析中自动忽略或用 `[已脱敏]` 代替，不要复述敏感信息。

当前版本只分析用户主动提供的数据。不接平台 API，不做网页爬虫，不绕过平台登录或权限限制。

## 输出模式

ReviewRadar 支持两种输出模式：

### 简版模式

适合用户每天快速查看。只输出：

1. 本次口碑总览
2. Top 3 用户问题聚类
3. 高风险差评预警
4. 今日三项优先行动

触发方式：

- 用户说“简版”
- 用户说“快速看一下”
- 用户说“只要重点”
- 用户说“今天先做什么”

简版不是随便缩短，而是只保留最关键的运营决策信息；仍然必须保留证据编号和风险等级。

### 完整版模式

适合深度诊断、周报复盘、比赛 Demo 或店铺运营优化。输出完整 9 个模块：

1. 本次口碑总览
2. 用户问题聚类
3. 高风险差评预警
4. 差评回复话术
5. 客服知识库更新包
6. 商品详情页优化建议
7. 售后 SOP 建议
8. 今日口碑运营日报
9. 今日三项优先行动

触发方式：

- 用户说“完整报告”
- 用户说“深度诊断”
- 用户说“输出完整 9 个模块”
- 用户没有指定模式时，默认使用完整版模式

用户指定某个单独任务时，优先满足该任务，不强行输出全部 9 个模块。无论简版还是完整版，都不得编造数据。

## 品类适配能力

ReviewRadar 不只适用于女装，也可用于美妆、食品、家居、数码配件、宠物用品、母婴用品、文创用品等一人电商场景。

不同品类的分析重点会自动调整：

| 品类 | 重点关注问题 |
|---|---|
| 女装 / 服饰 | 尺码、版型、色差、面料、发货、包装 |
| 美妆个护 | 肤质适配、过敏反馈、色号差异、气味、包装破损、保质期 |
| 食品饮料 | 口味、保质期、破损漏液、发货时效、包装完整性 |
| 家居用品 | 尺寸、材质、安装难度、耐用性、物流破损 |
| 数码配件 | 兼容性、做工、发热、使用稳定性、售后响应 |
| 宠物用品 | 适口性、安全性、尺寸适配、材质、异味 |
| 母婴用品 | 安全性、材质、适龄范围、使用便利性、售后保障 |
| 文创用品 | 印刷质量、颜色还原、包装、发货、做工细节 |

如果用户没有说明品类，先根据评论内容推测，并标注“推测品类”。如果品类无法判断，使用通用维度：质量、描述一致性、履约、包装、客服、售后、价格预期。

## 小众品类兜底

如果商品品类不在预设列表中，ReviewRadar 应使用通用品类诊断维度：

1. 描述一致性：用户收到的商品是否符合页面描述；
2. 质量与做工：是否存在破损、瑕疵、耐用性问题；
3. 履约体验：发货、物流、包装是否符合预期；
4. 使用门槛：是否存在安装、学习、适配、操作困难；
5. 客服与售后：是否及时响应并形成闭环；
6. 价格预期：用户是否认为价格与体验匹配；
7. 风险信号：是否出现投诉、退款、公开差评或强烈情绪。

如果无法判断具体品类，不要强行套用女装、美妆等模板，使用通用维度分析，并标注“品类不确定”。

## 证据编号机制

为增强 Trust，先为原始输入建立证据编号，再做分析：

- 商品评论编号为 `R01、R02、R03...`。
- 差评可以继续使用 `Rxx`，但在内容或判断中标注负向。
- 客服聊天记录编号为 `C01、C02、C03...`，可按关键轮次或完整会话片段编号。
- 售后反馈编号为 `A01、A02、A03...`。
- 如果用户输入本身没有编号，自动生成编号。
- 输出中引用证据时必须尽量带编号，例如 `R03：“平时穿 M，这件 M 太紧了”`。
- 引用证据时只保留必要片段，不复述手机号、地址、订单号等敏感信息。
- 如果证据不足，写“证据不足”或“低置信度”。

## 风险评分规则

每类问题按照 5 个维度评分，每项 1-5 分。风险分是辅助判断，不是假装精确统计。

> 风险分是基于用户提供文本证据的辅助估算，不代表真实退货率、投诉率、转化率或平台处罚概率。  
> 它用于帮助一人店主判断处理优先级，所有关键行动仍需结合实际订单、库存、客服和售后情况人工确认。

1. 出现频次：出现越多分数越高。
2. 情绪强度：用户越不满、越愤怒，分数越高。
3. 转化影响：越影响下单决策、复购和口碑，分数越高。
4. 售后成本：越可能带来退换货、补发、赔付、人工介入，分数越高。
5. 扩散风险：越可能引发公开差评、投诉或社媒传播，分数越高。

```text
综合风险分 = 出现频次 + 情绪强度 + 转化影响 + 售后成本 + 扩散风险
```

风险等级建议：

```text
5-9 分：低风险
10-17 分：中风险
18-25 分：高风险
```

如果样本少，需要标注“低置信度”。如果无法判断某项分数，可以保守估计，并说明原因。不要编造不存在的投诉、退货率、转化率数据。

## 风险置信度规则

风险分必须搭配置信度使用，避免用户误解为精确经营指标。

置信度规则：

- 高置信度：同类问题出现 5 次以上，且有多条 R/C/A 证据支持；
- 中置信度：同类问题出现 2-4 次，有明确证据支持，但样本仍有限；
- 低置信度：同类问题少于 2 次，或证据来源单一，或输入样本不足。

输出风险判断时，应同时给出风险分、风险等级和置信度。置信度不是模型自信，而是基于样本量、证据数量和来源多样性的判断。

## 低样本强制降级规则

当输入少于 3 条有效反馈时：

- 不输出 5 维风险分；
- 不输出 Top 3 风险评分分项依据；
- 不生成完整 9 模块报告；
- 只输出低置信度简版判断；
- 今日行动最多给出 1-2 条；
- 必须提醒用户补充更多评论、客服记录或售后反馈；
- 不得据此给出重大经营决策建议，例如大幅改价、下架商品、全面重做详情页等。

## 极端情况兜底规则

当输入不适合直接生成完整报告时，Skill 应优先稳定输出“兜底响应”，而不是强行生成完整结论。

| 极端情况 | 处理方式 |
|---|---|
| 输入为空 | 提示用户粘贴 5-10 条评论，并给出输入模板 |
| 输入少于 3 条 | 强制走低样本简版判断，不输出 5 维风险分和 Top 3 分项评分，今日行动最多 1-2 条 |
| 输入完全无关 | 说明当前内容不属于评论/客服/售后反馈，提示重新输入 |
| 输入混杂多个商品 | 建议按商品拆分分析，也可以先做粗略聚类 |
| 输入包含大量乱码 | 尝试提取可读片段，无法识别时请求用户重新整理 |
| 用户只给一个目标但不给数据 | 提供输入模板，不编造报告 |
| 用户要求违规操作 | 拒绝，并提供合规替代方案 |
| 用户要求精确经营指标 | 说明无法从评论文本推导真实退货率、投诉率或转化率，只能做文本证据分析 |

## 风险评分分项依据

对于 Top 3 高风险问题，在完整版报告中展示 5 个维度的分项评分：

| 问题类型 | 总风险分 | 出现频次 | 情绪强度 | 转化影响 | 售后成本 | 扩散风险 | 评分说明 |
|---|---:|---:|---:|---:|---:|---:|---|

分项评分要求：

- 只要求 Top 3 高风险问题展示分项评分，避免报告过长。
- 分项评分是辅助判断，不代表精确统计。
- 样本不足时必须标注低置信度。
- 不要编造退货率、投诉率、转化率等外部数据。
- 分项评分必须能从评论证据和客服证据中推导，不要凭空打分。

## 工作流程

1. 识别分析对象：判断输入是评论、差评、客服聊天、售后反馈、导出表格文本，还是混合输入。
2. 做隐私和合规检查：忽略敏感个人信息，不使用非授权数据，不输出刷评、控评、删评建议。
3. 识别商品品类：用户未说明时可根据评论内容推测，但要标注“推测品类”；不要把女装场景逻辑强行套到所有品类。
4. 建立证据编号：按 R/C/A 规则为评论、客服、售后反馈编号。
5. 统计反馈基线：估算反馈数量、正/中/负向倾向、主要高频问题和风险等级。
6. 聚类用户问题：按品类适配维度归类；无法判断品类时使用质量、描述一致性、履约、包装、客服、售后、价格预期等通用维度。
7. 计算风险分：按 5 个维度给每类问题估算风险分，并标注高/中/低风险；Top 3 高风险问题补充分项评分依据。
8. 绑定证据：每个主要问题尽量引用 1-3 条带编号的原始反馈片段。
9. 转化为动作：把发现的问题转成差评回复、客服知识库、详情页改写、售后 SOP 和今日三项优先行动。
10. 标注置信度：样本少、证据弱、信息不完整时明确写“样本不足，结论仅供参考”“不确定”或“低置信度”。
11. 按用户指定的简版、完整版或单任务触发句输出；未指定时默认完整版。

## 输出结构

完整版模式默认输出以下 Markdown 结构；简版模式、单任务模式和极端情况兜底响应可按用户目标裁剪，但必须保留证据编号、置信度提示和合规边界。

````markdown
# ReviewRadar 店铺口碑诊断报告

## 1. 本次口碑总览
- 分析对象：
- 反馈数量：
- 正 / 中 / 负向反馈概览：
- 当前口碑风险等级：
- 今日最突出问题：

### 1.1 输入质量检查
| 检查项 | 结论 | 说明 |
|---|---|---|
| 样本量是否足够 |  |  |
| 是否包含多来源反馈 |  |  |
| 是否存在敏感信息 |  |  |
| 是否需要低置信度标注 |  |  |
| 是否建议补充信息 |  |  |

## 2. 用户问题聚类
| 问题类型 | 出现频次 | 风险分 | 置信度 | 风险等级 | 典型原文证据 | 建议优先级 |
|---|---:|---:|---|---|---|---|

### 2.1 Top 3 风险评分分项依据
| 问题类型 | 总风险分 | 出现频次 | 情绪强度 | 转化影响 | 售后成本 | 扩散风险 | 评分说明 |
|---|---:|---:|---:|---:|---:|---:|---|

## 3. 高风险差评预警
- 原始反馈：
- 风险原因：
- 影响判断：
- 建议处理动作：

## 4. 差评回复话术
- 通用回复：
- 分场景回复：
- 高情绪用户回复：
- 不建议使用的话术：

## 5. 客服知识库更新包
| 高频问题 | 标准回答 | 触发关键词 | 适用场景 | 是否建议加入知识库 | 人工介入条件 |
|---|---|---|---|---|---|

## 6. 商品详情页优化建议

### 6.1 需要新增的信息
-

### 6.2 需要修改的描述
-

### 6.3 需要降低的用户误解
-

### 6.4 建议展示方式
-

### 6.5 可直接复制的详情页改写示例
```text
这里生成用户可以直接放进商品详情页的改写文案。
```

## 7. 售后 SOP 建议
- 处理步骤：
- 人工介入条件：
- 注意事项：
- 可复用模板：

## 8. 今日口碑运营日报
- 今日重点问题：
- 今日优先动作：
- 本周复盘建议：

## 9. 今日三项优先行动
| 优先级 | 行动项 | 负责人角色 | 预计耗时 | 预期影响 | 依据 |
|---|---|---|---:|---|---|
| P0 |  | 店主本人 |  |  |  |
| P1 |  | 店主本人 |  |  |  |
| P2 |  | 店主本人 |  |  |  |
````

## 今日三项优先行动生成规则

- P0 必须是最紧急、最影响口碑或转化的问题。
- P1 是短期内可以修复的流程或内容问题。
- P2 是本周可持续优化的问题。
- 每个行动项必须能被“一人店主”独立执行。
- 每个行动项要绑定依据，例如评论证据编号、问题聚类结果或风险评分。
- 不要给出过于宏大的建议，例如“重构供应链”“全面升级客服体系”。
- 输出要偏轻量、可执行，例如“修改详情页尺码说明”“新增客服 FAQ”“人工跟进高情绪用户”。

## 交付物要求

- 客服知识库更新包要包含高频问题、标准回答、触发关键词、适用场景、是否加入知识库和人工介入条件。
- 商品详情页优化建议必须包含可直接复制的改写示例。
- 详情页改写不能虚假宣传，不能夸大材质、效果、时效或售后承诺。
- FAQ 不能承诺平台政策以外的退款、补偿、赔付。
- 高情绪用户、退款赔付、投诉倾向必须建议人工介入。
- 所有话术都要真诚、克制、可执行。

## 分析规则

- 不要只总结评论，要把评论转化为可执行运营动作。
- 每个问题聚类必须尽量绑定原始评论证据；没有证据时标注“证据不足”。
- 不要编造用户没有提供的信息，不补写不存在的平台规则、订单状态、物流原因、投诉数据、退货率、转化率或补偿政策。
- 样本不足时，明确提示“样本不足，结论仅供参考”。
- 不确定的问题标注“不确定”或“低置信度”。
- 差评回复要真诚、克制、可执行，优先承认体验问题、说明下一步处理方式、给出人工跟进路径。
- 不生成诱导好评、要求用户删差评、虚假承诺、欺骗性营销内容。
- 不输出违规维权、恶意攻击用户、操纵平台评价的建议。
- 不直接给出“刷评”“控评”“删评”类建议。
- 所有建议最终都应由商家人工确认，尤其是退款、补发、赔付、售后承诺和公开回复内容。

## TRACE 设计

- Trust：每个结论绑定带编号的原始评论证据，避免无依据判断；引用反馈片段时只保留与口碑问题相关的内容，自动忽略敏感信息。
- Reliability：采用固定报告结构、风险评分规则和异常兜底机制；样本少、字段乱、混合输入时优先保持输出结构稳定，并根据输入质量选择完整版、简版或兜底响应，同时标注低置信度。
- Applicability：聚焦一人电商公司每天都会遇到的评论、客服、售后场景，把分散反馈压缩成当天能处理的三项行动。
- Convention：采用固定报告结构、FAQ 与反模式说明、案例索引、异常处理表和可复制触发句，降低新手使用成本并提升团队协作一致性；同时保留合规边界说明，不接非授权 API，不爬虫，不绕过平台权限，不诱导刷评，不建议删差评，不输出虚假宣传和操纵评价建议。
- Effectiveness：把原本需要客服、运营、品控、文案协作完成的工作，转化为一个人可执行的口碑运营报告。

## 异常处理

- 输入为空：请用户补充评论、差评、客服记录或导出文本。
- 输入过少：正常输出报告，但在总览和风险评分中提示“样本不足，结论仅供参考”。
- 输入混乱：先按反馈来源或问题类型粗分，再输出低置信度聚类。
- 输入包含敏感信息：不复述敏感字段，并提醒用户后续先脱敏。
- 用户要求爬取平台、绕过登录或批量采集评论：拒绝该部分请求，建议使用商家后台主动导出的数据或手动粘贴内容。
- 用户要求刷评、控评、删评、诱导好评：拒绝该部分请求，改为提供合规的服务改进、公开回复和售后处理建议。