亚马逊评论驱动产品迭代

它解决什么问题

亚马逊评论分散在商品页深处，人工翻读几百条 Review 很难系统提炼产品改进方向：哪些问题在反复出现、上一轮修复后有没有真正解决、本品与竞品的差距在哪里，通常只能靠印象判断。该技能把评论采集、分析与归档接进一条 CLI 工作流，让「从差评里找迭代点」变成可重复执行的例行动作。

核心能力与关键步骤

• 以 voc 为入口：对指定 ASIN 与站点先报价，用户确认后追加 --confirm，命令自动完成采集、等待、VOC 生成与归档，返回完整正文与 reportUrl。
• 每次会话先跑 python scripts/ari.py check 确认账户、邮箱验证状态与可用积点；随后跑一次免费的 alerts 查看未读差评预警。
• 报告产出后用 schedule 检查该产品是否已开启定期采集，建议切换到 weekly；开启后新评论持续入库，下一份报告能给出环比：哪些问题已解决、哪些新出现、哪些在恶化。
• 定位「最伤转化的高赞差评」用 reviews --asin <ASIN> --stars negative --sort helpful；品类内表现用免费的 benchmark；竞品对比需双方在库各 ≥10 条评论，同样先报价后 --confirm。
• 读取历史报告时，report --id 返回的 deltaMd 要先讲环比再讲正文；export 可导出 Markdown/HTML 或评论 CSV（付费套餐功能）。

适用边界与注意点

• voc / collect / analyze 均为付费操作：缺 Key、积点不足（402）或会话中断时不得自动重试；中断后先跑免费的 reports --asin <ASIN> --limit 1 确认是否已扣点归档，确认没有生成才可重跑 --confirm。
• 非美国站采集只支持付费积点，是否够用以报价中的 usableBalance 为准，而非账户总余额。
• 评论样本为 ARI 已采集数据，小样本或统计窗口有限时应结合更多信源验证；解读时需区分数据直读、数据推理与策略建议。