亚马逊类目星级差评分析

问题背景

亚马逊卖家常面对一个困境：自己的星级（比如 4.2）到底算好还是差？如果类目平均只有 3.8，这个数字就站得住；如果头部竞品普遍 4.5 以上，说明产品存在结构性问题。单看自家页面无从判断，必须把同一口径下的类目横向对比和评论中的问题变化趋势拉到一起看。

工作方式

技能通过本地 CLI 入口 scripts/ari.py 与后端 API 交互，每次会话先执行 python scripts/ari.py check，确认账户、邮箱验证状态与可用积点。核心能力：

• 类目对标：benchmark --asin <id> 返回产品在类目中的位置（免费）；进一步查看类目星级与差评率排行榜属于付费操作，同样先报价再确认。
• 竞品对比：analyze --type compare --asin <id> --competitor <id> 做本品与竞品的评论分析；竞品通过 competitors 绑定后会按周采集，攒够数据可用 radar 查看走势差异。
• 高赞差评定位：reviews --asin <id> --stars negative --sort helpful 拉出商品页最靠前展示的高赞差评（免费），加 --with-images 可单独看带图差评。
• 定期采集与环比：schedule 管理采集周期，开启 weekly 后新评论持续入库，报告支持环比——report --id 返回的 deltaMd 会先讲「相比上一份变了什么」。

付费命令（VOC 报告、leaderboard 等）遵循严格流程：先运行无 --confirm 的命令取报价，用户确认后再追加 --confirm 执行；中断后不得直接重试，先用 reports --asin <id> --limit 1 确认服务端是否已扣点归档。

边界与注意点

• 数据基于 ARI 已采集的评论样本，小样本时应结合其他信源验证；输出需区分数据直读、数据推理与策略建议，不得混淆。
• 非美国站点（如 amz_uk）采集只消耗付费积点，赠送积点不可用，以报价返回的 usableBalance 为准。
• 遇到 429 限流按提示降并发或稍后重试；402 欠费时引导充值，禁止自动重试付费操作。
• 收到 update 字段或 426 错误时，只负责告知用户通过原安装渠道更新，绝不自行下载或执行新版文件。