亚马逊差评预警

要解决的问题

亚马逊评论量一旦跨过几百条，靠人工翻页盯差评基本失效：高赞差评挂在页面顶部持续伤害转化，新的一星评价可能在几小时内被忽视，历史差评的整改效果也没有量化依据。常见的替代方案是每天手动导出评论表、用 Excel 做筛选，但这种方式延迟高、看不出趋势，更无法在差评出现时第一时间通知。本技能要补的正是这条链路：从评论采集、VOC 分析到差评预警，全部通过 CLI 自动化完成。

核心能力与工作流程

技能以 python scripts/ari.py check 作为会话起点，先校验账户状态、邮箱验证和可用积点，再进入实际分析流程。

评论舆情分析（VOC）：默认路径是 voc --site <amz_us|amz_uk|...> 先拿到总报价（采集 + VOC），用户确认后追加 --confirm 执行。命令会自动完成采集、等待任务、生成分析报告并返回 reportUrl，报告正文包含完整评论数据。竞品对比使用 analyze --type compare --asin <ASIN> --competitor <ASIN>，双方各需 ≥10 条在库评论。

差评预警：会话开始跑一次 alerts，有未读差评时主动推送，并用 workbench 按严重度排序定位待处理条目（stats 给出待处理/本周新增/本月已处理三个数字）。针对单条差评可用 advise --review-id 生成回复建议，同样先报价后确认。高赞差评榜通过 reviews --asin <ASIN> --stars negative --sort helpful 免费查询，带图差评加 --with-images。

定期采集与环比：报告生成后检查该产品采集计划（schedule），若仍是 manual 则提示当前只是时点快照。开启 weekly 后，后续报告会包含 deltaMd 环比——哪些问题解决、哪些新增、哪些恶化。已有归档报告用 report --id 读取，deltaMd 存在时先讲环比再讲正文。

安全协议与注意点

所有付费操作遵循先报价、后确认原则：默认命令只报价，必须由用户明确授权后才追加 --confirm。中断恢复有严格约束——ARI_STREAM_INTERRUPTED 等错误只说明连接断开，服务端可能已扣点归档，必须先跑免费的 reports --asin <ASIN> --limit 1 确认无新报告，才允许重试。

非美国站（amz_uk 等）采集仅支持付费积点，判断余额以报价中的 sufficient/usableBalance 为准，不用账户总余额。402 ARI_INSUFFICIENT_CREDITS 时保留已有结果引导充值，不自动重试付费操作。版本过期遇到 426 ARI_SKILL_TOO_OLD 时停止付费命令、引导用户自行升级——不替用户下载安装任何新版文件。

解读纪律上，reviewCount 等数字基于 ARI 已采集的 Amazon 评论样本，小样本时需结合其他信源验证。报告中明确区分数据直读、数据推理和策略建议，策略建议不冒充数据结论。