亚马逊爆款趋势挖掘提示词怎么写？AI四要素拆解

在青虎AI 里做一次「亚马逊爆款趋势挖掘」，最后能拿到什么样的结果，很大程度上不取决于工具，而取决于你在输入框里写了什么。同一套平台数据工具，有人写出来的指令能调回一屏结构清楚、可以直接拿去开会的分析；有人跑完只得到一堆泛泛的描述，看完不知道该干什么。差别就在提示词这一行字上。

这件事的难点不在语法，而在信息密度。你需要在短短一段话里，把「看哪个平台、看哪一片市场、用什么口径收口、想拿到什么形状的结论」交代清楚。少交代一件，系统就只能猜。

这篇专讲怎么写。下面会把文档里给出的四要素逐个拆开，每一要素配上「写得清」与「写得糊」的对照，再给出一条完整指令的组装顺序。读完之后你应该能对着自己的类目，写出第一条不靠运气的亚马逊爆款趋势挖掘指令。

图1：一条好的趋势挖掘指令，是把四类信息按顺序写进同一段话

亚马逊爆款趋势挖掘的提示词，为什么值得单独学

很多人对提示词的理解停留在「会说话就行」。这个理解在单次问答里基本成立，因为问错了重新问一句成本很低；但在调研场景里不成立——一次调研要跑数据、出报告，跑偏一次浪费的是实实在在的时间，你很难分辨结果是「市场真的这样」还是「我问得不对」。

文档里的定位原句说得很明确：「仅需输入商品链接、类目关键词、运营需求，AI自动调用平台数据工具完成市场研判，输出可直接复用的分析报告。」这句话的重点在「调用平台数据工具」这几个字上。系统不是凭空作答，它要根据你的描述去决定调哪一片数据、按什么口径筛。描述得粗，调回来的就是一大片；描述得准，调回来的才是你要看的那一段。

还有一层原因是，调研的结论是要被复用的。「可直接复用」意味着输出不能是一团模糊的描述，得有结构、有清单、有能对得上的口径，而输出结构的形状恰恰由你输入的分析目标决定：要一份商品清单和要一份竞品拆解，得到的组织方式完全不同。

所以这条能力在青虎Agent里被当成一件正经事来做：它围绕电商选品调研、数据复盘高频工作。亚马逊爆款趋势挖掘属于前半段，要回答的是「接下来往哪个方向找机会」，答案质量与你怎么提问直接相关——提示词是任务的一部分。

把这件事想得更透一点：写提示词的过程，其实是你自己做一次调研设计的过程。一份调研的水位在上路之前就定了——你打算问谁、问什么、按什么标准收样本，决定了最后能得出什么结论。在青虎AI 里，「问谁」是站点与类目，「按什么标准收样本」是筛选条件，「想得出什么结论」是分析目标。同一句提示词换个人用效果差很多，差异不在遣词造句，而在于写下这句话的人，脑子里是否已经有一个清楚的问题。工具放大的是你原本的清晰程度。

先对齐口径：趋势挖掘在文档里的原名叫法

写指令之前有一件事必须做，就是把叫法对齐。文档全文没有出现「趋势」这两个字，也就没有名为「趋势挖掘」的按钮或功能模块。业务侧说的这件事，在文档里的原词是市场调研与新品挖掘。

这个落差带来的实际影响是：如果你写「帮我去挖掘一下趋势」，系统能理解意图，但没有对应的能力名可以挂靠，只能按最宽泛的方式理解；如果写「帮我做一次某个站点、某个类目的市场调研，输出商品筛选清单」，系统立刻就能挂到市场调研这条链路上，调数据的动作、输出的结构都会更明确。

再往下一层，文档里提到的用词还包括「市场研判」「分析报告」「商品资料沉淀」「商品档案管理」。这几个词构成同一件事的前后段：市场研判是过程，分析报告是产物，商品资料沉淀与商品档案管理是产物的去处。一份调研做得完整不完整，看的就是这四段有没有接上。

把四格连起来看，写提示词时的自我检查就有了标准：我这段话有没有说清输入是哪一个入口？有没有提示这是一次市场研判？有没有说我想要什么形态的输出？如果三问都答得上，这条指令的基本盘就稳了。

还有一处容易混的地方要在这里说明。青虎AI 有两种运行模式，页面中央顶部可以切换——Agent模式与SoClaw模式，默认使用Agent模式做数据分析。Agent 模式下有三个核心辅助按钮：上传、工具、提示词库；SoClaw 模式下的辅助操作是另外四类：上传、技能、模型、提示词库。写提示词这件事主要发生在 Agent 模式下，所以后面提到 @工具指令、模板填充，都按 Agent 模式来说。

四要素逐个拆：站点、类目、筛选条件、分析目标

文档给出的自定义写法是这样一句：「无匹配模板时，直接在输入框完整描述站点、类目、筛选条件、分析目标，搭配 @工具指令调用对应平台数据源。」这句话就是本篇的骨架。四个要素加一个动作，缺哪一项都会让结果模糊一层。

先说站点。站点决定的是「看哪一个市场」。同一个类目在不同站点上的竞争结构可能完全不同，一边可能是头部品牌把持、价格带挤得很窄，另一边可能还是分散竞争、白牌有机会。不说站点，结果要么落到默认站点，要么是一个跨站点的模糊结果。

再说类目。类目决定的是「看哪一片商品」，最忌讳写得太宽。写一个一级大类，跑回来的商品可能横跨好几个完全不同的使用场景，挑不出东西；写到一个具体的细分品类，跑回来的才是彼此可比的一批商品。文档在典型工作方式里建议「围绕单个类目/单品持续迭代分析」，「单个」这两个字就是给提示词提的要求。

接着是筛选条件。筛选条件是收口动作。同一片市场里既有卖得动的也有卖不动的，不设口径放一起看，报告会很热闹但你判断不出什么。文档在第二次使用流程里提到可以准备「想要筛选的商品条件」，在结果调整环节里给出的是「评论/销量筛选数值」这类可调项，在模板用法里给的是「筛选数值」——这几个说法指向同一件事：给结果设一道门槛。

最后是分析目标。分析目标决定输出的形状。文档在推荐流程里把任务目标归成三类：选品、竞品拆解、关键词分析。你写「帮我看看这个类目」，得到的是一份泛读；你写「这次要做选品，重点看哪些细分需求在被反复提及」，得到的就是一份朝选品组织的材料。目标说得越具体，输出越贴近你真正要交付的东西。

四要素之外还有一个动作要记住：@工具指令。它的作用是指定去调哪一个平台数据源。在无匹配模板、需要完全自定义的场景下，描述完四要素，再配上 @工具指令，系统就知道该去调用对应的数据源，而不是凭已有信息作答。

「写清 vs 写糊」两列对照

下面这张表把四个要素排成两列，左列是带上关键信息之后的样子，右列是常见的省略写法。看表的时候可以拿自己平时写的那句话去对，看它落在哪一列。

写得清的样子（关键信息带齐）	写得糊的样子（关键信息缺席）
站点：明确说是哪一个站点，比如要做的是亚马逊这个站点上的调研，就直接把站点名写出来，让系统知道去哪一片市场调数据	站点：整段话里不提站点，或者只写「国外平台」「几个平台都看看」这类模糊说法，结果落到哪个市场完全靠默认值决定
类目：写到可以判断使用场景的那一层，让跑回来的商品彼此可比，同时说明这是围绕单个类目做的持续迭代	类目：只给一个大类名，或者一次塞进好几个不相关的品类，跑回来的商品横跨不同场景，翻起来没有抓手
筛选条件：说清本次要用什么口径收口，比如按评论量、按销量这类可调数值设一道门槛，并说明是想先看规模还是先看细分	筛选条件：完全不提门槛，或者写「不限」「都行」，报告里既有卖得动的也有卖不动的，混在一起看不出结构
分析目标：在选品、竞品拆解、关键词分析里明确选一个，并补一句这次最想回答的问题，比如想避开已经被头部占满的方向	分析目标：只写「帮我分析一下」「看看有什么机会」，输出只能按最通用的方式组织，读完不知道自己得到了什么

这张表有一个用法上的提醒：右列不是「错误写法」，而是「信息不足的写法」。信息不足时系统不会报错，它会给你一个看起来完整的结果，问题是你无法判断它覆盖了什么、遗漏了什么。左列的价值在于把判断依据留在指令里，结果出来之后你能一眼看出这次看到的是哪一片市场。

把四行横着读一遍，会发现左列的每一格都在回答同一个问题：这件事的边界在哪里。站点回答「哪片市场」，类目回答「哪一段商品」，筛选条件回答「留下多少」，分析目标回答「要得出什么」。四者合起来构成一个封闭的框，青虎AI 在这个框里作业，结果的解释权才留在你手上。

反过来说，右列的每一格都在把边界交出去。不提站点，边界交给默认值；不提类目层级，边界交给系统的泛化理解；不提筛选口径，边界交给数据的自然分布；不提分析目标，边界交给通用模板。交出去的边界越多，结果越像一份「谁都能用」的报告。

落地做法很简单：写完指令之后，用这四个词逐项扫一遍，扫到哪一项找不到对应的说法就补上。这个动作花不了多少时间，却能挡住大部分「跑完才发现问错了」的情况。

四行里最容易被省略的是站点，因为大多数人默认自己只做一个站点。但指令是写给系统看的，你心里的默认值不会自动传过去——把站点写出来只需要两个词，却决定了整份报告是不是落在你的战场上。

筛选项则最容易被写得太随意。有人一上来就把门槛拉高，想直接看「好的」，结果符合条件的太少，反而不成结构。稳妥的顺序是先按宽松口径跑一次看规模，再在同一个会话里收紧。文档明确说过优先在当前会话内修改指令，补充调整站点、评论与销量筛选数值这类可调项，不需要新建对话——第一次的口径不必一步到位，留出调整余地反而更快。

图2：左边是四要素带齐的写法，右边是常见的信息简化写法

一条完整指令的组装顺序

四个要素知道是什么了，接下来的问题是先写哪个、后写哪个。顺序不是形式，它决定了系统读这段话时的理解路径。下面这个顺序按「范围从大到小、目标从后往前」来排：先把场地圈定，再收口径，最后说目的。

按这个顺序写出来的指令天然是分层的：范围、口径、目标各占一段，读的人（以及系统）都能看出你的意图边界在哪。结果不理想时，你也能迅速定位是哪一层出了问题。

图3：一条完整指令的组装顺序——先说范围，再说口径，最后说目标，必要时补 @工具

这里要澄清一个常见期待。文档里「任务输入编写建议」与「可直接套用的输入模板」这两处章节是配图说明，正文没有可引用的文字明细，所以本篇不给示范指令的原文。这是口径纪律：凡是文档没有写死的字段与句式，都不适合被当成标准答案传出去。你要带走的是这四段的顺序与内容要求，而不是某一句现成的话。

@工具指令：趋势挖掘数据不够时的兜底手段

写完指令发出去，多数时候能拿到一份结果。但总有一些情况是结果偏薄：符合条件的商品很少，或者某个维度的信息不够支撑判断。文档给出的处理方式很直接：「若数据覆盖不足，可在指令内新增 @对应平台工具重新调取数据源。」

这句话有几个要点值得拆。第一，它是在指令内补的，也就是在原会话里继续写，而不是换个地方重新开始。第二，@ 的对象是对应平台的工具，做亚马逊的调研就去 @ 与之对应的那一个，而不是随便挑一个数据源。第三，它的动作是重新调取数据源，属于把覆盖范围再拉一遍，而不是让青虎Agent 凭已有内容多写几句。

把这个兜底手段和另外四类可调项放在一起看，就是完整的调整工具箱。文档在结果不符合预期的调整方案里写的是：优先在当前会话内修改指令，无需新建对话，补充调整站点、评论/销量筛选数值、新增卖点限制、更换分析维度；若数据覆盖不足，再新增 @对应平台工具重新调取数据源。

五件事分工很清楚。站点、筛选数值、卖点限制、分析维度这四项调的是「看法」，@工具调的是「来源」——数据的底子够不够。结果不对时先判断是看法问题还是来源问题：方向对但样本偏少是来源问题，样本够多但看到的不是你想看的是看法问题。

还有一条纪律要记住：调整就在同一个会话里做。文档强调「优先在当前会话内修改指令，无需新建对话」，原因是同一次会话保留了上下文，青虎AI 知道你前面已经看过什么、筛过什么，追加时结果会更连贯。频繁开新对话等于每次从零描述，既慢又容易前后矛盾。

把这个兜底手段与四要素的关系理一遍会更清楚。四要素解决的是「怎么问」，@工具解决的是「数据从哪来」。前者是表达问题，后者是供给问题。多数时候问题出在表达上，所以文档把调整四类可调项放在前面，把重新调取数据源作为排在后面的补充手段——先怀疑自己问得不准，再怀疑数据不够。

另外，@工具指令写多了并不会让结果更好。它的作用是钉住数据来源，重复堆砌只会让指令变长而不变清楚。判断标准很简单：如果去掉这个 @，结果仍然落在你要的那片市场里，说明它不是必需的。

最后说一句关于「追加」的心态。追加不是补救，而是这条能力的正常节奏。把调整当成流程的一部分而不是失败的信号，用起来会顺手得多。

关于趋势挖掘提示词的四个常见误解

写指令这件事上有几个反复出现的误解，它们听起来都挺合理，但一对文档就站不住。逐个拆掉。

四个误解里，第四个最值得反复强调。前三个属于技巧层面的偏差，改一改就好；第四个属于对工具性质的误判，不改的话提示词写得再好也会失望。看清楚一件事和把这件事搬回家之间，隔着产品决策、供应链、合规这一整套动作。

第三个误解也值得再补一句。迭代不是「写得不好才要改」，而是这条能力本身的工作方式。文档建议围绕单个类目或单品持续迭代分析，「持续」说明它本来就是多次的动作——把第一轮当成探路，第二轮才开始收口。

第二个误解背后其实是一个更普遍的心理：担心自己说得不够「专业」，于是把精力花在措辞上。但青虎AI 不需要你专业，它需要你准确。把「想找一个需求还在涨、竞争还没被占满的细分方向」写成一句大白话，效果远好于写一堆看起来讲究却什么都没指定的形容。

第一个误解还有一层值得说：长指令往往暴露出写的人自己没想清楚。当你把同一件事反复换着说法写三遍，通常是因为你自己还在犹豫要什么。这时候最该做的不是继续加字，而是停下来把那四件事各写一句。

写趋势挖掘提示词的四条操作技巧

下面四条都来自文档里的原文口径，可以直接拿去用。

四条里，第一条与第四条是一对：一个解决「不知道怎么写」，一个解决「写完了不满意」。夹在中间的第二条和第三条解决的是同一个问题的两面——第一次别写太复杂，但该说的目标一定要说到。

再补一条不是技巧但很重要的提醒：保留指令。同一条指令跑出好结果之后，把它存下来。青虎AI 的输入框底部有提示词库这个辅助按钮，作用是调用已经保存的标准化指令模板。下次换个类目名就是新任务，团队里也能直接传给同事用——写得好的一次，值得变成长期可用的资产。

还有一处细节与写指令直接相关：输入框下方有三个核心辅助按钮，除了提示词库，另外两个是上传与工具。上传负责把商品链接、参考文档这类附件递进去——调研对象是一条具体链接时，它比在文字里描述准确得多；工具负责调用平台数据源。这三个是 Agent 模式下的配置，SoClaw 模式下的辅助操作是另外四类，不要混着记。

三个场景：趋势挖掘提示词落在什么活儿上

把提示词放回真实工作里，判断会更容易。下面三个场景对应文档里明确提到的几类使用者。

图4：提示词写对了，产出才能直接进入选品会与调研报告的流程

三个场景有一个共同前提：写指令的人得先知道自己要问什么。工具能处理的是把数据调出来、整理好，处理不了「我该关心什么」。站点是你选的，类目是你给的，筛选条件是你定的，分析目标是你写的——这四个环节决定了这份调研的上限。

再补一个团队层面的用处。四要素的结构一旦固定下来，就成了团队内部的沟通模板。开会时不用再争「这次调研到底看什么」，直接对着这四项过一遍：站点是哪几个、类目收到哪一层、口径按什么设、目标定成哪一类——比事后返工便宜得多。

能做与不做：提示词里能要求什么

最后把边界整理成一张表。左列是指令里可以要求的事，右列是文档里没有、因此不该写进指令的事。这张表建议直接拿去对照自己的期望。

指令里可以这样要求	指令里不该这样要求
指定站点与类目范围，让系统去调对应那一片市场的数据	要求一键抓取亚马逊全站或拿到全站数据，文档没有这类口径
指定评论量、销量这类筛选数值作为收口门槛，先宽后窄分两轮调	要求系统给出预测准确率，或承诺某个方向的成功概率，文档并无此项
要求输出结构化内容：分析报告、商品筛选清单、市场机会与后续运营动作	要求它替你把货搬进店铺，也就是写下上架、跟卖这类动作要求，文档里都没有对应的能力
要求在当前会话内更换分析维度、新增卖点限制，继续追加提问	不要要求它去监控全部类目，这类范围口径不存在，范围只能由你给的类目与关键词划定
在数据覆盖不足时，用 @对应平台工具重新调取数据源	要求接入平台官方数据库，文档没有提到与官方接口打通这类能力
要求把结论整理成可归档的形式，便于后续存入商品库复用	要求给出数据更新的频率承诺，文档并未约定这类节奏

这张表右列的每一条，都不是「暂时做不到」，而是「这件事本来就不属于调研环节」。把一份调研指令写成搬运指令，结果一定是失望，而且失望的原因和提示词写得好不好没有关系。指令能改变的是你看到什么、看得多细；它改变不了工具本身的性质。

常见问题：关于亚马逊爆款趋势挖掘提示词的十一个疑问