亚马逊差评回复助手

解决什么问题

亚马逊商品页的评论区有一条硬规律：买家通常只看首页顶部那几条差评，尤其是带图的。一条高赞差评压在那里，转化会被持续侵蚀，而运营团队往往不知道该先处理哪一条——逐条翻列表、猜严重程度、手动起草回复，既慢又容易漏。更麻烦的是，差评不是孤立事件，它和评论采集频率、报告时点、历史趋势都有关系；只看今天一天的快照，很容易把已经解决的问题当成新问题再处理一遍。

核心能力与工作流

该技能通过 scripts/ari.py 提供 CLI 入口。每次会话先执行 python scripts/ari.py check，确认账户状态、邮箱是否已验证、当前可用积点；字段、命令和错误码的详细说明在 references/reference.md。

它把差评运营拆成几个明确的步骤：

• 定位伤害最大的差评：reviews --asin <ASIN> --stars negative --sort helpful 返回高赞差评榜（免费），加 --with-images 可以筛出带图差评。买家在商品页最先看到的就是这几条。
• 生成回复话术：workbench 按严重度排序，返回 stats（待处理/本周新增/本月已处理），再用 advise --review-id 生成回复建议。汇报时先说三个数字，再说具体条目，让用户看见推进状态。
• VOC 与趋势分析：默认 voc --site <站点> 报出采集加分析的总费用，用户确认后追加 --confirm 才执行。report --id 返回 deltaMd 时，先讲环比再讲正文。
• 持续采集：报告出来后跑一次免费的 schedule，如果该 ASIN 仍是 manual，主动提醒用户这只是快照；开启 weekly 后新评论持续进库，下一份报告才能回答“哪些问题解决了、哪些是新冒出来的”。
• 竞品与行业对比：analyze --type compare 用于本品与竞品对比（双方各需 ≥10 条评论），benchmark --asin 免费看行业表现，leaderboard 看类目排行。

适用边界与注意点

• 付费命令（voc、collect、analyze、advise 等）必须先报价，得到明确确认后再加 --confirm，禁止默认确认。
• 付费命令中断后（ARI_STREAM_INTERRUPTED、NETWORK_ERROR、WAIT_TIMEOUT）不得直接重试——服务端很可能已扣点并归档。先跑 reports --asin <ASIN> --limit 1 确认没有生成新报告，才可以重跑。
• 非美国站采集只能使用付费积点，以报价里的 usableBalance 为准，不要用账户总余额判断。
• 401/ARI_UNAUTHENTICATED 需重建 Key；402/ARI_INSUFFICIENT_CREDITS 引导充值，不得自动重试付费操作；ARI_EMAIL_NOT_VERIFIED 需先验证邮箱；426/ARI_SKILL_TOO_OLD 停止付费命令并引导更新，免费查询仍可继续。
• 解读时区分 📊 数据直读、🔍 数据推理、💡 策略建议。reviewCount 基于 ARI 已采集的 Amazon 评论样本，小样本或采集窗口有限时需结合更多信源验证。
• 站点默认 amz_us，可选 amz_uk、amz_de、amz_jp 等；charts/deepdive 的 --days 默认 0（全部历史），传非 0 时解读必须带上窗口说明。
• 输出含 reportUrl 时，结尾附上在线查看入口；同时列出使用的 CLI 命令、ASIN/站点、样本量、统计窗口、reportId、creditsUsed 和当前余额。