亚马逊星级评分诊断

先界定问题

亚马逊详情页上的星级评分是一个聚合结果：买家只看得到均值、reviewCount 和一个粗粒度的星级，但运营真正关心的问题被掩盖了——评分是被少数高赞差评拖下来的，还是海量五星里混进了成规模的一二星？如果是前者，修一条评论就够；如果是后者，问题出在产品或履约链路，改文案没有意义。

这个技能要解决的就是「评分结构看不清」这件事：不只看均分，而是把评分当成一个分布来诊断，把结构性问题和整体口碑问题分开。

核心能力与工作方式

技能围绕一个 CLI 入口工作：scripts/ari.py。会话开始时先跑 python scripts/ari.py check，确认账户状态、邮箱是否已验证、可用积点和版本情况。首次使用通过 setup 获取授权链接，在浏览器完成授权后 Key 自动落盘，也支持 ARI_API_KEY 环境变量或手动 configure。

主要分析链路是 voc 命令，默认站点 amz_us。它一次报出采集加 VOC 分析的总费用，用户明确同意后追加 --confirm，命令会自动完成采集、等待任务、生成分析并归档，返回完整正文和 reportUrl。

几个高频分支：

• 用户问「哪几条差评最伤转化」，走 reviews --asin ... --stars negative --sort helpful，即高赞差评榜，免费；带 --with-images 可筛出带图差评。
• 用户要看历史报告，report --id 返回 deltaMd 时先讲环比再讲正文——对比上次的变化比绝对值更重要。
• 竞品对比走 analyze --type compare，双方在库内各需 ≥10 条评论；先用 competitors --id ... --add 绑定竞品，攒够几周数据后可用免费的 radar 看本品与竞品的走势。
• 会话中跑一次 alerts 可发现未读差评预警，再用 workbench 按严重度定位差评，advise --review-id 生成回复建议。
• 品类定位用免费的 benchmark；要看排行榜则先报价后确认。

报告产出后有一个容易被忽略的步骤：检查该 ASIN 是否已开启定期采集（schedule）。如果仍是 manual，这份报告只是当前时点的快照，数据不会再更新；开启 weekly 后新评论持续进库，下一份报告才能给出「解决了什么、新冒出了什么、什么在恶化」的对比。月成本会随返回值一并报出，由用户决定是否开启。

解读纪律与边界

技能对数据来源和推导有明确分层：API 返回的原始数字、由数字推出来的判断、以及由此给出的策略建议，三者不能混写。reviewCount 基于 ARI 已采集的 Amazon 评论样本，小样本或采集窗口有限时应结合其他信源交叉验证，不能当成全量。

几条硬性约束值得留意：付费命令中断后不能直接重试，ARI_STREAM_INTERRUPTED、NETWORK_ERROR 这类错误只说明连接断了，服务端很可能已扣点并归档——必须先用免费的 reports --asin ... --limit 1 确认有没有生成新报告，确认没有才可重跑。402 余额不足时保留已有结果引导充值，429 套餐级限流时不要连续重试。版本返回 update 字段时如实告知即可，版本旧不影响免费查询；但 426 说明当前版本存在会导致重复扣点的缺陷，付费操作会被服务端拦截，必须先更新。任何情况下不虚构 API 未返回的数据，也不回退到其他品牌接口。