Amazon 商品 → 社媒爆款脚本

为什么这么设计

以前做带货短视频，选题和文案基本靠"拍脑袋"——运营凭经验猜什么会火，然后让 AI 直接生成。这个 skill 想解决的是"凭感觉"这件事：先让 AI 把能查到的事实（产品自己说了什么、买家自己说了什么）都摆出来，人只在最后需要判断"品牌调性/渠道策略要往哪个方向走"的时候介入一次。信息收集和分析这类工作，AI 应该自己扛完；方向选择这种价值判断，才是人真正该管的事。

所以整个流程分两段：Step 1-2 是信息收集，不要在中途打断用户去确认；全程只有两个停下来等用户答复的地方——Step 3（选内容方向）和Step 4 结束时（选视频生成路线），别的地方都不要停。跑到 Step 2 之前遇到的小问题（比如某条评论页加载慢）自己想办法绕过去，不要为了这些细节去打扰用户。

整体流程

Step 0：确认输入

检查链接是不是有效的 Amazon 商品页（amazon.com/dp/...、amazon.com/gp/product/... 或 amzn.to 短链）。如果用户给的是搜索页/类目页而不是具体商品页，先问清楚是要哪一个商品，因为后面所有分析都是围绕单一商品展开的。

Step 1：抓 Listing，提炼卖点

用 /browse 打开商品链接（不要用 mcp__claude-in-chrome__* 或裸 WebFetch 硬抓——Amazon 反爬很敏感，无头浏览器更稳，这也是 CLAUDE.md 里的硬性要求）。

提取：

• 标题
• 五点卖点（bullet points）原文
• 价格、星级、评分数量
• 类目
• A+ 页面/图文描述里出现的核心信息（如果能加载出来）

产出一份产品卖点摘要（先记在上下文里，不用急着写文件）。

价格核实提醒：/browse 打开 Amazon 时可能被识别成非美区收货地址（实测出现过自动定位到印度、价格显示成 INR 的情况）。如果抓到的价格不是 USD，在摘要里标注清楚"这个价格未经美区核实"，不要直接当成真实售价写进后面的脚本或简报里误导用户。

Step 2：抓评论，挖真实用户语言

只用商品页本身自带的评论模块，不要跳转到"查看全部评论"那个独立分页（URL 形如 /product-reviews/ASIN）。商品页自带的评论区通常已经有 8-10 条精选评论（好评差评都有），外加 Amazon 自己生成的"Customers say"AI 摘要（按维度列出正负面提及次数，负面维度的百分比也在里面），这些信息不需要登录就能看到，已经够挖了。完整评论列表页在一些账号/网络环境下会被 Amazon 的登录墙拦住——遇到这种情况绝对不要提示用户去登录 Amazon 账号，更不能让 agent 代替用户操作登录（账号安全问题，不是这个 skill 该碰的）。宁可评论样本少一点，也不要为了多挖几条评论去动登录这条线。如果商品页自带的评论区+AI摘要覆盖的负面样本确实很薄，在产出里如实说明"负面评论样本有限，未访问需要登录的完整评论列表"，不要假装挖得很全。

用 /browse 打开商品页，尽量多抓一些评论文本，好评差评都要——差评里的抱怨往往是最直接的切入点（比如"以为能装下我的大狗结果太小了"这种话，反过来就是视频里"专为大型犬设计"的钩子）。

不要只做单词词频统计，那没什么用。要挑出能直接抄进文案里的完整短语，比如买家形容使用体验、形容"before/after"变化、形容意外惊喜或失望的原话。给每条标注它是「验证了某个卖点」还是「暴露了一个待解决的痛点/常见顾虑」。

留意有没有评论本身就是一个自带起承转合的小故事（比如"孩子看博主推荐念叨了一周，我最后妥协下单"这种）——这种评论不用再套什么叙事框架去加工，本身就是剧情类脚本的现成骨架，比硬编一个故事真实、也更好判断是否受众会共情。挖到这种评论优先标出来，Step3 给用户选方向的时候可以单独作为一个"剧情类"选项提出来。

产出一份评论高频语言清单。

Step 3：汇总洞察，请用户选方向

把 Step 1-2 的产出汇总成一份简短的内容策略简报，然后向用户说明看到了哪几种可行的视频方向（通常会归成种草类/剧情类/直接转化类，具体叫法可以按实际挖出来的东西调整，不用死套这三个词——比如 Step2 挖到"自带剧情"的评论，就可以直接把这条具体故事作为剧情类的方案报出来，而不是空泛地说"可以做剧情类"），并请用户选一个方向。

这是全程两个停下来等用户答复的地方之一——前面两步能自己查清楚的都自己查清楚，不要在中途反复问"要不要继续""这样对吗"。

Step 4：按选定方向出脚本

生成分镜脚本，格式建议包含：

• 时间戳/分镜编号
• 画面描述
• 口播文案/字幕
• 这句文案的依据是什么（对应 Step 1 的哪个卖点 / Step 2 的哪句买家原话）——每一句都要能追溯到前面某一步的具体依据，不要凭空编，这是这个 skill 相比直接让模型"写个带货脚本"的核心价值所在

每个分镜的时长尽量落在 5-10 秒，不要拍脑袋切分镜。这不是审美要求，是产能约束：主流图生视频模型（比如 Seedance）单次生成的片段一般是 5-10 秒，一个分镜如果短于 5 秒，交给视频生成的时候会不好对应（要么浪费一次生成的容量，要么被迫和别的镜头拼在一起，破坏脚本原来的镜头划分）；长于 10 秒的分镜，视频生成那边根本生成不出来，还得再拆一次，等于脚本白设计了这道分镜。所以设计分镜的时候就要按这个产能上限来切，不要留到视频生成阶段再返工。

如果用户有多个市场/多种语言的需求，在这一步问清楚要出哪个语言版本，针对性调整痛点和用词——不同市场买家在意的点往往不一样，不要简单翻译一套通稿了事（这块目前还没有专门的多语言评论分析支持，先靠人工提醒模型注意本地化）。

脚本产出之后，问用户接下来想怎么生成视频：是逐镜生成（每个分镜单独生成一段 5-10s 视频，再拼接）还是先把关键分镜转成关键帧图片确认画面风格、满意后再图生视频（一致性更高，但多一轮确认）。这只是把"接下来怎么走"的选择交给用户，不是这个 skill 去做视频生成本身——別在这里调用任何视频生成 API，问完就算这一轮任务完成，用户会拿着这个答案去宿主平台（比如 Doubao 里的 Seedance）实际生成。

输出物

建议给每个产品建一个工作目录（比如用商品的简短英文名或 ASIN 命名），里面放：

• insights.md — Step 1-3 的汇总（卖点摘要 + 评论语言清单 + 内容策略简报）
• script.md — Step 4 的最终脚本

依赖

• /browse（gstack）：所有网页抓取都走这个，不要用 mcp__claude-in-chrome__*。如果执行 $B 命令报 Executable not found in $PATH: "bun"，先 export PATH="$HOME/.bun/bin:$PATH" 再重试——bun 装在 ~/.bun/bin，但不一定在当前 shell 的 PATH 里

当前版本不做的事（下一轮迭代再说）

• 视频生成本身：这一版只出脚本，遇到"直接出成片"的要求，说明现状，不要临时拼一个视频生成方案。近期路线已定（讨论过 A/自建网关/用户自带 key 三种，选了最省工程的一种）：脚本出来之后，视频生成这一步交给宿主平台自己的能力去做（比如在 Doubao「豆包工作」里就用它自带的 Seedance 模型），不在这个 skill 里接任何视频生成 API。等以后要跨平台复用视频生成能力、或者要控制成本/配额了，再考虑升级成自建网关（复用 Firebox→WorkBuddy 那套"key 藏服务端+脚本轻量调用"的打法），现在没必要一上来就重工程
• 系统化的多语言/多市场分析：目前只在 Step 4 提醒模型手动注意本地化，还没有针对不同国家评论区做专门的抓取和痛点分析
• 社媒爆款视频搜索/拆解：早期版本加过这一步（去 TikTok/YouTube Shorts 找同类目爆款视频，分析开头钩子和叙事框架），实测下来发现除了抖音（没在本 skill 里实测过），其它平台目前都只能拿到标题/简介/播放量这些页面元数据，看不懂真实画面和语音内容，分析深度有限、成本却不低（TikTok 搜索还直接被拦）。所以先跳过，专注在"卖点+评论"这两个更扎实、访问也更稳定的信息源上出脚本。想恢复这一步之前，先看下面"已知限制"，那是这一步被跳过的直接原因，得先解决

待加入的能力（比视频问题更容易解决，只是还没做）

• 商品图片还没有下载分析过：Step1 目前只抓文字（$B text/$B data），listing 图库里的场景图、尺寸对比图、卖点信息图（很多关键卖点是做成图片贴上去的，纯文字抓取会漏掉）都没碰过。这个跟视频问题不一样——图片可以用 $B media --images 或 scrape images 拿到链接下载下来，然后直接用 Read 工具看（Claude 在环时直接读图就行，不用接 OCR/视觉模型中转），是真能看懂内容的，成本比视频低很多。等确定要做的时候可以直接加进 Step1。

• 视频生成的参考图来源：这个不是 Step1 的需求（Step1 要看图就直接用 listing 真实图，没有"用户上传"这个选项），是下一轮接"图生视频"这类视频合成能力时才用得上的问题——生成视频时用什么图片保证产品外观和实物一致？两个来源：① 从商品链接抓 listing 真实图 ② 用户自己上传的商品图。这个必须让用户选，不能默认，因为直接用纯 AI 文生画面外观会跟实物有差异（Step2 挖到的真实差评"Green is much much darker and less vibrant than the product images"就是这个问题的活教训——视频画面和实物对不上，等于亲手制造下一条同款差评）。启用视频生成能力的时候，在那一步问用户选哪个来源，不要塞进现在 Step0-4 这个流程里当第二个停顿点——现在的设计里 Step3 是唯一的停顿点，加了会破坏这个约束。

已知限制（记录下来，回头想办法处理，不代表现在就要解决）

• Amazon listing 自带视频拿不到内容，只有元数据：blob: URL 流式播放，/browse 抓不到视频文件本身，也没有字幕/转写轨道。能拿到的只有标题/封面/时长/配套文字，看不了画面、听不懂语音
• YouTube Shorts 同样只有元数据级别：标题、简介、播放量/点赞/评论数、标签、发布时间、创作者能读到，但没有下载视频文件、没有转写实际画面和语音内容
• TikTok 搜索页直接拦无头浏览器，目前完全访问不了，连元数据都拿不到
• 抖音理论上是唯一能做到"下载级别"访问的平台（通过 douyin-video skill，能拿到无水印视频文件+文案+互动数据），但这个能力还没在本 skill 里实测跑过，只是复用现成能力的假设，没验证过
• 如果以后要恢复"社媒爆款视频分析"这一步、做到真正看懂视频内容（画面+语音转写），需要额外接下载+视觉理解/语音转写的能力，不是靠 /browse 就能解决的