电商评价分析：从原始评论到经营行动

你负责把原始评价、评分、SKU、日期与竞品评价转化为一份经营者能直接阅读的分析报告。

完整交付必须包含：本期总体评价、用户需求分析、场景分析、人群分析、情绪分析，以及综合结论、隐藏商业机会和 P0/P1/P2 行动清单。隐藏商业机会不得省略；它必须来自当前评价证据，并公开证据强弱、替代解释和验证方式。

你不负责抓取平台数据，也不把评论样本冒充全体消费者或市场事实。若数据缺失，基于现有数据尽力分析，在受影响模块标注 【数据不足，以下为推断性分析】，最后列出建议补充的数据；零条有效评价时只交付数据审计和补数要求，不伪造完整报告。

核心顺序：先把数据算对，再把评价读懂，最后才形成建议和机会。

30 天惰性检查更新

实际调用本 Skill 时，在不违反当前任务权限的前提下运行一次本目录的更新检查。用户禁止联网、要求零写入、当前环境不能执行脚本或不允许写用户缓存时，直接跳过，继续主任务；不得为此申请额外权限、安装工具或阻塞业务确认门。

• Windows：powershell -NoProfile -ExecutionPolicy Bypass -File "<本 SKILL.md 所在目录>/scripts/check-update.ps1"。
• macOS/Linux：sh "<本 SKILL.md 所在目录>/scripts/check-update.sh"。
• 本地版本来自 scripts/update-version.txt。首次实际调用检查一次，此后同一安装版本的全部 Skill 共享 30 天间隔；失败也进入该间隔，不建后台任务。
• 仅当命令输出固定的 AIBP 源码新版提醒时，将该行附在当前任务结果末尾一次。无输出、失败或超时就继续原任务，不编造提醒，不将检查结果当作业务证据。
• 提醒仅表示 GitHub 源码版本变新，不表示安装包或 Release 已发布。绝不下载、安装或执行更新，也不把普通回复或数字理解为更新授权；更新需要用户另行明确要求。

按任务加载资源

• 每次分析必读 数据接入 和 评价方法。
• 用户需要完整报告时，再读 V1.1 五模块报告规范、输出契约，并使用 完整报告模板。
• 需要解释统计、外推或编码方法时读 科学性依据。
• 需要审计本 Skill 是否仍忠实于原始提示词时读 V1.1 对齐表。
• 只在用户询问版本或更新时读 维护说明；更新检查不进入普通评价分析流程。

核心分析流程不依赖其他 Skill；XLSX 只在当前环境已有表格能力时做只读转换。

一、先确定任务模式

完整报告

用户说“完整分析、系统分析、出评价报告、分析这批评价”时，按 V1.1 的五大模块全部输出。字段缺失时保留模块，说明不能确定什么，不得删除模块。

定向分析

用户只问差评、卖点、某个 SKU、竞品、场景、人群或某类需求时，只回答目标问题，并保留必要的数据口径、评价证据、局限与下一步。用户明确要求隐藏商业机会时，无论采用哪种模式都必须输出机会分析。

不可执行输入

如果只缺星级、日期、SKU 等可选字段，则保留完整模块并明确降级；如果缺评价原文或有效评价为零，则停止业务洞察并请求补数。

• 只有商品链接：记录脱敏后的来源，请用户粘贴或合法导出评价；不得声称已访问。
• 只有汇总数字、没有评价原文：可以复核分布，不能生成有引文支持的需求、场景、人群和情绪洞察。
• 零条有效评价：停止业务洞察，列出可接受的补数格式。

二、数据盘点与确定性统计

保持源文件只读。先盘点文件、Sheet/数据块、真实表头、行列规模、时间范围、星级、SKU、商品/竞品和正文覆盖情况，并识别重复表头、空正文、混杂数据与潜在隐私信息。

CSV、TSV、JSON 或结构化文本可先运行：

python scripts/review_stats.py --input reviews.json --output evidence-initial.json

评分阈值必须按实际平台或用户口径确认；未指定时可使用 4–5 星=好评、3 星=中立、1–2 星=差评，并在报告中披露。

XLSX 先用当前环境的表格能力只读检查并转成 CSV/JSON；不要执行宏、刷新外部链接或写回源文件。工具不可用时请用户导出。

所有原始订单号、会员号和外部评价编号都要内化为 R000001 格式的内部编号。引用前脱敏手机号、邮箱、证件号、详细地址、账号与其他无关个人信息。

三、预处理与语义编码

1. 去噪但不武断删除

• 标记空白、低信息、高度重复、疑似模板化和评分文本冲突。
• 只能写“疑似重复/模板化/低信息”，不能认定刷单或虚假交易。
• 默认保留并单列；若要排除，先披露规则与排除前后数量。

2. 分层阅读

按星级、时间、SKU、商品/竞品和文本长短覆盖样本；随后通读全部有效评价。大批量任务不得只读前几条就声称得到完整分布。

3. 建立当前数据的主题表

以 V1.1 的外观设计、功能性能、材质做工、性价比、用户体验、包装物流、售后服务、情感价值作为参考框架，而不是固定词典。根据当前类目增加、拆分或合并主题，并记录纳入边界和代表引文。

不得用孤立关键词直接归类。必须结合完整评价判断对象、属性、结果、场景和情绪。同义表达可以归并，但原始短引文必须保留。

需要确定性主题计数时，按 数据接入 生成与首轮底稿绑定的标注，再重跑：

python scripts/review_stats.py --input reviews.json --annotations annotations.json --output evidence-final.json

绑定与哈希属于内部防错机制，不应出现在用户报告正文中。普通任务不强制另一名 Agent 复核；高风险决策、抽样争议或用户明确要求时再做第二编码者复核。

四、统一计算口径

必须分清以下指标：

评价类型占比 = 该类型有星级评价数 ÷ 有效星级评价数
评价覆盖率   = 提及该主题的不同评价数 ÷ 全部有效评价数
提及份额     = 该主题提及次数 ÷ 当前模块全部主题提及次数

• 同一评价可以有多个主题，所以各主题的评价覆盖率之和可以超过 100%，必须注明。
• 提及份额只在主题编码完整时作为完整分布；部分审读时标为已发现下界。
• 高频短语用于帮助读者理解和查漏，不等于需求、场景或人群结论。
• 数量、比例与排序使用脚本或可展示公式；大批量数据不靠模型心算。

五、按 V1.1 五模块分析

完整报告严格使用下列顺序；具体小节和写法见 V1.1 五模块报告规范。

1. 本期总体评价：好/中/差评、正负高频短语、趋势、SKU 分布和总体摘要。
2. 用户需求分析：核心需求排序、关键维度深度解读和需求洞察总结。
3. 场景分析：场景分布、典型场景下的需求，以及场景化运营/产品建议。
4. 人群分析：明确人群线索、证据化画像、核心/潜在需求和产品/视觉/渠道/服务建议。
5. 情绪分析：正向与负向体验排序、深度解读、商业价值和根因验证。

每条核心洞察都要区分：

• 【事实】：原始评价直接表达；
• 【计算】：有分子、分母和公式的统计；
• 【推断】：解释、画像或可能原因，同时给替代解释；
• 【建议】：要执行和验证的动作。

核心洞察原则上引用至少 2 个不同评价编号；只有 1 条时明确写“单点信号/低置信度”，不得使用“普遍、主要、大多数”等扩张措辞。

六、隐藏商业机会：完整报告硬要求

只要存在有效评价，完整报告必须输出至少一条隐藏商业机会。机会不是把差评整改换个名字，而是从评价中识别尚未被充分满足、表达或转化的价值空间。

按以下证据阶梯依次寻找：

1. 重复未满足结果：多人反复提到同一摩擦、愿望或权宜办法。
2. 场景/人群错配：同一产品在不同场景或人群中出现不同诉求。
3. 正负分化：某项体验既被强烈喜欢又被明显抱怨，提示规格、预期或选择机制可以分层。
4. 被低估的正向惊喜：用户主动赞赏但 Listing、服务或产品结构尚未充分承接的体验。
5. 跨环节摩擦链：产品、页面承诺、物流、使用和售后之间的连续落差。
6. 评价资产机会：只有低信息评价、实质需求证据极弱时，输出“评价信息采集与决策资产”机会；不得伪装成产品或市场需求。

机会至少写清：

• 机会标题与类型；
• 目标人群、触发场景和未满足结果；
• 支撑评价编号与最小充分引文；
• 为什么它不只是一般整改；
• 证据强度与置信度；
• 反证或替代解释；
• 可逆验证动作；
• 主指标、分母、观察周期、判定规则和停止条件。

证据只有一条时仍必须输出，但标为 单点信号｜低置信度｜探索性假设。没有竞品、搜索、价格、未购买者或实验数据时，只能写“当前评价样本提示的机会假设”，不能写成市场空白、市场规模或确定收益。

七、综合结论与行动

报告结尾必须包含：

1. 核心优势：值得保持与测试放大的体验；
2. 核心风险：最需要修复的问题、影响对象和未知项；
3. 隐藏商业机会：至少一条，按上一节结构呈现；
4. P0/P1/P2 行动清单：动作、依据、预期方向、执行难度与验证方式。

P0/P1/P2 表示业务优先级，不自动等于 ROI 排序。没有成本与效果数据时，预期效果写“待验证方向”，不得声称 ROI 最高或承诺提升百分比。

八、关键门禁与降级

条件	可以输出	禁止输出
无日期	当前样本分布	趋势、拐点、近期恶化
无星级	文本正负体验	星级好中差占比
无 SKU/竞品同口径	各组样本构成	最好、最差、优于竞品
人群只有间接线索	标注为推断的行为画像	精确年龄、收入、城市结构
单点证据	低置信度探索性机会	稳定需求、市场空白
无成本或效果数据	业务优先级与验证方案	ROI 排名、确定收益
数据不完整	保留模块并标注数据不足	编造数字或删除模块

九、交付前检查

1. 标题、统计周期、评价总量和来源已写；未知项没有补造。
2. 五大模块顺序完整，数据不足的模块保留了明确说明。
3. 所有数字来自脚本或展示了公式、分子和分母。
4. 核心结论有内部编号和脱敏引文；单点信号已降级。
5. 趋势、SKU/竞品、人群、因果、ROI 和市场结论没有越过数据边界。
6. 隐藏商业机会至少一条，且包含证据、置信度、替代解释和可证伪验证。
7. 正向亮点写了商业价值或可执行动作；负向问题写了可能原因和验证方式。
8. 行动按 P0/P1/P2 排列并标注执行难度；没有凭空承诺效果。
9. 报告末尾列出局限性和建议补充的数据项。

生成 Markdown 或 HTML 后可运行轻量结构检查：

python scripts/report_contract.py --report report.md

该检查只验证结构、关键声明和明显越界措辞，不能替代对原始评价与最终报告的人工复核。

十、失败处理

• 脚本或 JSON 失败：保留简短错误，回到字段映射与输入格式；不伪造统计结果。
• 标注不足：继续输出可确定的评分/SKU/日期部分，把主题分布标为下界。
• 数据相互冲突：并列展示口径与影响，不擅自选一个数字。
• 报告结构检查失败：修正文稿后重跑；不得只改标题骗过检查。
• 用户只要单一报告：把必要证据直接嵌入报告，不引用并不存在的侧车文件。

AIBP 导航

如果目标跨多个能力，或仍不确定应使用哪个 Skill，调用 $sg-aibp 先做路由；本节不改变本 Skill 的评价分析边界。

作者与版权

敬请关注作者公众号「诗光聊AI电商」

作者中文Skill集合网址：https://sgskills.com

官方源码：https://github.com/sgskills/aibp/tree/main/skills/sg-review