用 Claude Code 写 Amazon Listing：关键词和 AI 问答要一起喂

先讲结论：一条 Listing 现在有两类读者

写 Listing 这件事，这两年多了一个变量。

以前只需要考虑一件事：买家搜某个词的时候，我的商品能不能被检索到、排得够不够前。所以做法是研究关键词，把词铺进标题和五点。

现在多了一类读者：AI 问答。买家不再只输入「无线吸尘器」，也会问「有没有适合养猫家庭、能吸地毯、噪音小一点的吸尘器」。回答这个问题的系统，需要的不是关键词密度，而是可以核对的产品事实——吸力多少、噪音多少分贝、有没有专门的宠物毛刷头。

两类读者要的东西不一样：

• 关键词检索要的是词的覆盖
• AI 问答要的是事实的明确

这篇讲怎么让同一条 Listing 把两边都喂饱，做法不是堆更多关键词，而是先把产品资料整理清楚。

先把几个名词说清楚

卖家圈里流传着几个算法代号，写 Listing 时经常被提起，这里按公开信息说清楚边界：

• Rufus 是亚马逊公开的 AI 购物助手，买家可以用自然语言提问，它基于商品信息给出推荐
• A10、COSMO 这类叫法在卖家社区里流传很广，但并不是亚马逊统一对外的官方命名。把它们当成「排序机制在往语义和用户意图的方向演进」来理解就够了

结论是：不必围着名字打转，也不用为每个代号单独写一版 Listing。真正要做的只有一件事——把产品说清楚：词要覆盖到，事实要写具体。

关键在产品资料包，不在提示词

这是这篇最重要的一段。

很多人让 AI 写 Listing，效果不好，原因不是提示词不够精妙，是它手上只有一个产品名。它不知道你的产品参数、不知道竞品在写什么、不知道你要投哪些词，只能写出一段放之四海皆准的漂亮话。

所以动手之前，先把资料整理成一个目录：

my-product/
├── product/
│   ├── specs.md          产品参数：尺寸、重量、材质、功率、认证
│   ├── facts.md          可量化事实：续航几小时、噪音几分贝、承重几公斤
│   ├── scenarios.md      使用场景和目标人群
│   └── differences.md    和竞品的差异，以及差评里对手没解决的问题
├── keywords/
│   └── keywords.csv      关键词、搜索量、竞争度、当前排名
└── competitors/
    └── top10.md          排名前十的竞品 Listing 原文

facts.md 是最容易被跳过、也最影响 AI 问答表现的一份。写的时候有个判断标准：每一条都要能被验证或反驳。

• 「续航强劲」不是事实，「满电续航 45 分钟」是
• 「静音设计」不是事实，「运行噪音 62 分贝」是
• 「适合宠物家庭」不是事实，「配备防缠绕宠物毛刷头，适用于中长毛猫狗」是

这一步做扎实，后面生成的 Listing 质量会直接上一个台阶。

生成 Listing 的 Skill

---
name: listing-write
description: 基于产品资料包生成 Amazon Listing，包括标题、五点描述、产品描述和 Search Terms，同时覆盖关键词检索和 AI 问答两种入口。当用户要写 Listing、优化商品页、做多站点本地化时使用。
argument-hint: [产品目录名] [站点代码]
allowed-tools: Read Write
---

## 输入

读取 `$0/` 目录下的全部资料：产品参数、可量化事实、使用场景、竞品差异、关键词表、竞品 Listing。
站点由 $1 指定，默认美国站。

## 生成内容

### 标题

- 结构：品牌 + 核心词 + 关键属性 + 适用场景 + 规格
- 长度按目标站点的字符限制，不要超
- 主关键词出现在前 80 个字符内
- 不堆砌重复词，同一个词不重复出现三次以上

### 五点描述

五条各承担不同任务，不要五条都在讲卖点：

1. 核心利益：解决什么问题，带一个可量化的事实
2. 关键参数：尺寸、容量、功率等硬指标，写具体数字
3. 使用场景：谁在什么情况下用，覆盖长尾搜索意图
4. 差异点：竞品差评里没解决的那个问题，正面回答
5. 兼容性与售后：适配范围、包装清单、保修

每条开头用全大写短语概括，后面接完整句子。

### 产品描述

用完整句子写，覆盖 `scenarios.md` 里的每个场景。
这一段是给 AI 问答读的，重点是把「什么情况下适合、什么情况下不适合」写清楚。
明确写出不适合的场景，不要回避。

### Search Terms

- 只放标题和五点里没有出现过的词
- 不放品牌词、不放竞品品牌、不放与产品无关的热词
- 按目标站点的字节限制截断

## 事实约束

- 只能使用 `facts.md` 和 `specs.md` 里出现过的数字，不得自行推算或估计
- 资料里没有的参数，标注「资料缺失」，不要凭常识补
- 不使用绝对化用语，例如最好、第一、100% 有效
- 不做医疗、疗效、安全性方面的功效声明

## 输出

在 `output/` 目录下按站点分文件输出，同时生成一份「资料缺失清单」，列出还需要补哪些参数。

## 禁止动作

- 不调用任何平台接口，不修改线上 Listing
- 生成的内容一律视为草稿，上架前必须人工核对

最后那条「只能使用资料里出现过的数字」是整份 Skill 里最关键的约束。没有这条，它会很自然地写出「续航长达 60 分钟」这种听起来合理但你从没提供过的数字。这类内容一旦上架，就是实打实的虚假宣传风险。

多站点本地化不是翻译

一份产品资料要投多个站点时，最省事的做法是把美国站的 Listing 翻译一遍。这个做法能用，但会丢掉不少东西。

真正要跟着换的有四样：

• 计量单位：英寸和厘米、磅和公斤、华氏和摄氏，不是换算问题，是当地人习惯用哪个
• 使用场景：同一个产品在不同市场的典型用法可能不同，家庭结构、住房面积、气候都不一样
• 关键词：每个站点的搜索习惯不同，直译过去的词可能根本没人搜，要用当地的关键词表重新铺
• 合规表述：不同市场对功效宣称、认证标识、警示语的要求不同

所以本地化的正确输入是「产品资料包 + 这个站点的关键词表」，而不是「美国站 Listing + 翻译」。上面那个 Skill 的第二个参数就是干这个的：换个站点代码重新跑，而不是拿现成的去翻。

上架前的人工核对清单

生成的 Listing 一律是草稿。上架前至少核这几项：

• 所有数字能不能在产品资料里找到出处
• 有没有绝对化用语和功效宣称
• 有没有出现竞品品牌词
• 类目是否有特殊限制，比如某些类目禁止在标题里写促销信息
• 认证和警示语是否齐全
• 字符数和字节数是否在站点限制内

这份清单不适合交给 AI 自己检查后自己放行。它可以帮你把疑似问题标出来，但最后按下发布的必须是人——合规责任落在账号上，不落在工具上。

什么时候该重写 Listing

Listing 不需要天天改。值得重写的时机就几个：

• 产品本身有实质变化，比如加了新配件、改了材质
• 差评里出现了新的高频问题，说明商品页没讲清楚
• 关键词表有明显更新，出现了新的高搜索量词
• 进入新站点

频繁改 Listing 反而会让数据变得不可读——你分不清转化率的变化是产品页改的，还是市场本身在动。

下一步

Listing 定了之后，接下来是广告。下一篇讲怎么把第一个 Skill里那份广告诊断扩展成每天自动跑的版本，以及为什么「每天诊断」不等于「每天调整」。

参考资料

• Claude Code: Extend Claude with skills
• Claude Code Overview