亚马逊评论数据决策助手

解决的问题

亚马逊评论分散在商品页和后台报表里，差评往往等转化掉了一截才被发现；竞品对比要靠人工翻页截图，维度不统一；想做“本期相比上期变好/变差”的判断，常常没有可比的基线。这个技能把采集、VOC 分析、预警和环比串成一条命令链，让运营判断有可复现的数据支撑。

核心能力与关键步骤

• 启动校验：每次会话先跑 python scripts/ari.py check，确认账户、邮箱验证状态和可用积点。
• VOC 分析：默认执行 voc --site <站点> 先报出采集 + 分析的总费用，用户确认后才追加 --confirm，命令会自动采集、等待、分析、归档，并返回正文与 reportUrl。
• 差评预警：alerts 检查未读差评；workbench 按严重度排序，先报 stats 里的“待处理 / 本周新增 / 本月已处理”三个数字；advise --review-id 生成回复建议（同样先报价再确认）。
• 高赞差评榜：reviews --asin <ASIN> --stars negative --sort helpful 免费返回买家最先看到的几条差评，--with-images 可筛带图差评。
• 竞品对比与基准：analyze --type compare 需双方在库内各有 ≥10 条评论；benchmark --asin 免费看类目表现，leaderboard 先报价。
• 环比报告：report --id 返回 deltaMd 时必须先讲环比再讲正文，_deltaStatus=generating 表示仍在后台计算，稍后重跑即可。
• 周期采集：报告产出后检查 schedule，若 ASIN 仍为 manual，说明数据只代表当天快照；开启 weekly 需向用户报出 _costNote 月成本并获得明确同意。

适用边界与注意点

• reviewCount 基于 ARI 已采集的评论样本，小样本或窗口有限时应结合更多信源验证，不要当作全量结论。
• 付费命令中断后不得直接重试：先跑 reports --asin <ASIN> --limit 1 确认是否已扣点归档，再决定是否重跑。
• 402 引导充值、401 重建 Key、ARI_EMAIL_NOT_VERIFIED 先去用户中心验证邮箱；429 提示套餐级限流时不要连续重试。
• 非美国站采集只能用付费积点，是否够用以报价里的 sufficient / usableBalance 为准。
• 解读纪律：📊 数据直读、🔍 数据推理、💡 策略建议 三者不可混标；任何情况下不虚构 API 未返回的数据，也不回退到其他品牌接口。

适合需要周期性评论复盘、差评响应和竞品监控的亚马逊运营场景，不适合替代完整的财务或库存系统。