技能介绍

被分散的评论与不足的决策依据

亚马逊用户评论蕴含产品口碑、用户偏好与竞争信号，但它们散落在 amz_us、amz_uk 等不同站点，手动收集不仅耗时，还容易因筛选标准不一导致样本偏差。运营团队常困于「评论太多看不完」和「样本太少不准」，更难以在竞品间建立统一对比口径——这些问题会让产品优化、选品判断和广告策略失去可靠依据。

以 CLI 为中心的评论分析流程

该技能通过本地脚本 scripts/ari.py 与 ARI 服务交互，将「采集-分析-报告」串成一条可审计的流水线。

先检查状态：每次会话先运行 python scripts/ari.py check，确认账户积点、邮箱验证状态，避免到付费步骤才发现前置条件不满足。
再采集评论：对新 ASIN 执行不带 --confirm 的 collect，它会返回采集报价，只有用户确认后才追加 --confirm 完成付费采集。
然后做分析：deepdive --asin <ASIN> 默认不扣点，能一次性拿到产品状态、免费图表、评论样本和 VOC 分析报价；用户确认后再用带 --confirm 的版本执行深度分析。也可以用 analyze --type voc|insight|trend|variant 针对具体问题定向分析。
竞品对比同样要先报价：要求双方 ASIN 在库内各有至少 10 条评论，先运行 analyze --type compare --asin <ASIN> --competitor <ASIN> 取价，用户确认后再追加 --confirm。

解读结果时，必须把 API 返回的数字、由数字推导的判断和行动建议分开标记：📊 代表数据直读，🔍 代表数据推理，💡 代表策略建议。结尾要列出使用的 CLI 命令、ASIN/站点、样本量、统计窗口、reportId、消耗积点和当前余额；若返回中包含 reportUrl，需固定附上「在线查看图表版完整报告 / 导出：（需登录报告所属账户）」。

适用边界与操作纪律

该技能目标是降低评论分析门槛，但有几个边界必须遵守。首先，数据基于 ARI 已采集的评论样本，小样本或采集窗口有限时应结合更多信源验证，不能把结论当成全局事实。其次，非美国站（如 amz_uk、amz_de）的采集只能使用付费积点，赠送积点不可用，判断是否充足要看报价里的 sufficient / usableBalance，而非账户总余额。最后，付费命令中途断连（如出现 ARI_STREAM_INTERRUPTED、NETWORK_ERROR、WAIT_TIMEOUT）后不能直接重试，必须先运行 reports --asin <ASIN> --limit 1 确认服务端未生成新报告，否则可能导致重复扣点。