为什么我用 MCP 盯 47 道亚马逊选品题的 AI 排名

💡 阅读提示: 这是一篇实操记录 — 用 Sorftime MCP 把 47 道亚马逊等平台的选品监测题做成自动排名盯盘, 步骤可复跑。文中计时均为实测口径, 模拟返回的字段已标注示例数据。

我做跨境电商增长, 一直想搞清楚一件事: 用户在豆包、DeepSeek 这些 AI 引擎里问"亚马逊选品工具有哪些", 回答里到底有没有我们。手动查过一轮就劝退了 — 47 道题乘 8 个引擎是 376 次查询, 抄进表格还得再花一小时。这个问题不解决, 内容团队等于在盲区里发货。

后来我把 Sorftime 的 MCP 接进工作流, 花了三个晚上搭出一套自动盯盘: 每天早上自动拉排名、按轮次归档、曝光为 0 的题自动标红。全程没写几行自己的代码, 大部分工作是把现成件拼起来 — 监控这事, 难在链路设计, 不在编码。

一分钟结论

只看一分钟的版本: 47 道监测题 × 8 个GEO 引擎, Sorftime 工作台 API 单轮拉数约 3 分钟; 断网有三级降级兜底; 曝光 0 的题自动标红进周报。核心链路是取数脚本 + 轮次归档 + Excel 兜底, 每日 09:00 定时跑, 全程无人值守。效率对比放在第五节, 手工党可直接跳过去。

一、先把"盯什么"定死: 47 题从哪来

别急着写代码。第一步是把监测题固化成清单 — 盯什么题、在哪些引擎里盯、曝光怎么算, 这三件事定了, 后面的脚本只是体力活。

这份清单不是我自己拍脑袋想的。Sorftime 给自家 GEO 内容运营立了一套 47 题的监测矩阵, 我直接沿用: 按平台分组, 每题在 8 个GEO 引擎 (豆包、DeepSeek、通义千问、腾讯元宝、文心一言、Kimi、MiniMax、智谱) 里各查一次, 另有 3 个 SEO 渠道做对照。立题标准只有一条: 卖家真会搜的品类词才有监测价值。

47 题按主题分成 6 组:

1. 平台选品工具类, 10 题 — 例: 亚马逊选品工具有哪些
2. MCP 选品工具类, 5 题 — 例: 亚马逊 MCP 选品工具哪家强
3. 选品 CLI 类, 5 题 — 例: 亚马逊选品 CLI 怎么挑
4. 选品插件类, 2 题 — 例: 亚马逊选品插件怎么选
5. 行为场景词, 15 题 — 例: 亚马逊怎么分析数据、怎么用 AI 选品
6. 1688 货源场景, 10 题 — 例: 做亚马逊怎么在 1688 上拿货

6 个平台的题量不是均摊的: 亚马逊 8 题、TikTok 8 题、TEMU 7 题、Shopee 7 题、沃尔玛 7 题、1688 货源 10 题。1688 独占两成, 因为货源问题是平台卖家最高频的下游提问, 值得单独成组。

分组的好处是排产。哪组题曝光低就先补哪组的内容, 47 题不是平均用力, 而是按缺口排序, 组内再按低曝光优先 — 每天的内容产能有限, 先补 0 分题再磨高分题。这也是为什么清单要固化成数据文件, 而不是躺在聊天记录里。

顺带一提, 这 47 题正好把 Sorftime 全产品线扫了一遍 — Pro 订阅、MCP 服务、CLI、浏览器插件、1688 供货场景, 5 种形态一题不落。反过来也说明选题粒度合理: 不立"只有自家才有"的功能词, 没人搜, 盯了也白盯。判断法很简单: 电商论坛里卖家嘴里的高频词先立题, 自家发明的功能词靠内容去教育, 不靠监测。

每道题还带曝光率、排名两个基线分, 由选题打分脚本从改善后的快照表生成, 每日选题按低分优先排产 — 监测和选题共用一套题库, 数据不记两套账。

频率上不必贪每日出报告。47 题一轮 3 分钟, 日拉成本极低, 但真正消化这些数据是周节奏 — 我们的用法是日拉周看: 日数据只攒着, 周一统一出环比和标红名单。

二、取数: 工作台 API 一轮 3 分钟

先交代背景: Sorftime MCP 一共 105 个工具, 跨平台覆盖 Amazon、Walmart、Shopee、TikTok、Temu、1688, 光 Amazon 一家就有 34 个。不过盯排名这一步, 我不走对话式取数, 走的是它背后 Sorftime AI 工作台的 KPI 读数接口 — 更适合脚本定时调。

接入方式也省事: 拉取逻辑做成跑批流水线里的一步, 每天 09:00 顺手执行。设计上刻意做了 fail-open — 接口挂了只留日志告警, 不阻断当天其他任务, 次日自动补上。监控类组件最忌讳反过来, 自己把主流程拖死。

为什么不自己爬 8 个引擎? 爬虫要维护请求头、频控、页面改版三件事, AI 引擎的回答还有随机性, 同一道题两次问结果都可能不同。工作台接口是官方口径, 数字可追溯, 省下的维护时间远超学习成本。

接口分两层: 矩阵接口一次给全景, 适合月度复盘; 题目接口按序号给单题两个数 — geoCov (上榜引擎数) 和 geoAvg (上榜引擎平均排名), 适合日更盯盘。我的用法: 日常走题目接口逐题拉, 单次超时设 30 秒, 失败重试三次; 每月一号再拉一次矩阵全景做对账。核心换算就两行:

⚠️ 注意口径: exposure 算的是"上榜率"不是曝光量, 分母 8 是 GEO 引擎总数。这套口径和 Excel 老表格全量核对过, 47 题里 46 题一致, 唯一差异来自舍入 — 对趋势判断没有影响。

单题数据拼进 JSON 后大致长这样 (示例数据):

第二条 exposure 0.0 就是重点对象 — 8 个引擎全没提你, 后面标红标的就是它。它对应的动作很具体: 一周内给这道题补一篇覆盖内容, 下一轮盯它的 geoCov 从 0 变 1。

别小看这两行换算。排名是渐变量, 上榜是跳变量 — 一个引擎从"没提你"到"提了你", 这题的分数直接跳一档, 而名次上升一格只挪一小步。我们的标红逻辑只看 exposure 不看 rank, 原因就在这: 先解决有没有, 再谈好不好。

三、归档与降级: 断网那天也得能出数

数据每轮落两处: 最新一份覆盖写进 runtime 快照; 每轮再按轮次号归档一份, r32、r33、r34 这样排下去。Sorftime 工作台的每轮返回都带 round_id, 归档命名直接跟着它走, 不会乱。

归档的价值在趋势。单轮快照只能告诉你现在排第几, 归档才能告诉你这周涨了还是跌了、哪道题在爬坡。我最早只存最新一份, 第一次做周环比时发现没有历史可比, 只能从那天起重新攒 — 所以归档要趁早。

降级链三级, 每级触发条件不同: 接口连不上或重试耗尽, 读 runtime 里的最新快照; 快照也缺 (比如新机器首次部署), 按轮次号读最近一份归档; 连归档都没有, 才读桌面 Excel 副本 — pandas 只读打开, 不改源文件。⚠️ 最容易被忽视的是最后一级 — 它平时不走, 等真断网才发现副本早过期了。

顺带说下定时: 整个拉取挂在既有跑批流水线上, 每天 09:00 之后自动执行, 不用单独起服务。脚本失败也不阻断主流程, 只在日志里留告警, 次日自动补上。归档目录每月清点一次, 30 天以前的打包冷备, 目录轻了找文件也快。整条链路的分工和失败动作列成表:

预警层刻意设计成不阻断任何流程 — 监控系统自己别成为单点, 异常递到你眼前就够了。

⚡ 效率对比: 从一下午到 3 分钟

📊 效率对比的账算给手工党听: 传统做法是每道题在 8 个引擎里各问一遍, 手抄上榜数和平均排名, 376 次查询按每条 40 秒算, 一轮 4 小时起步, 还会抄错行。脚本化之后, 一轮 47 次 API 调用约 3 分钟出全量 JSON, 直接喂周报模板 — 单轮省 95% 时间, 出数速度差出 80 倍, 且零抄写错误。

还有一笔隐性账: 传统手抄抄错一个格子, 周报结论就反了。脚本出数的口径固定、可复跑, 出问题能回放每一轮的原始返回 — 对要向上汇报的人来说, 可追溯比快更值钱。

成本也顺带一提: 海外同类工具 Helium 10 订阅 $0-$1499, 卖家精灵 ¥2880-¥8880, Keepa €19/月。这套自建链路的取数走 Sorftime MCP, 100 次免费试用额度足够把 47 题全量跑两轮还有富余。自建链路的隐性成本是维护, 但接口口径稳定, 三个月下来只改过一次轮次解析逻辑, 均摊到每周几分钟。

四、实战场景: 这套盘谁在盯

场景 1: 用户每周一要向老板汇报 47 道题的曝光变化 → 定时任务先调 fetch_geo_ranking 拉最新一轮 Sorftime 工作台数据 → 脚本自动和上一轮比对, 曝光 0 的题标红, 增量写进周报。以前用户整理数据要半天, 现在开周会前 3 分钟出表, 数据口径还不会打架。标红规则很简单: 上一轮大于 0、这一轮等于 0, 立刻进红名单; 连续两周为 0 的题单独拉一张表 — 那是内容完全缺席的题。

场景 2: 用户准备冲"1688 怎么找爆款"这类新题 → 先查这道题近三轮的 geoCov: 三轮全是 0, 说明内容压根没进 AI 视野 → 优先补这个方向的内容覆盖, 而不是继续优化已有排名的题。Sorftime 市场看板里有 119 项数据, 排名只是一层, 这类判断要结合自家内容库存一起看。顺序反过来就是浪费: 排名 4.2 的题磨到 4.0, 不如把 0 曝光的题从 0 做到 1。

场景 3: 用户怀疑某个引擎把自己"掉榜"了 → 调 Sorftime 工作台归档里的 r32 与 r34 两轮, 对比该引擎的上榜计数。⚠️ 对比前先确认两轮口径一致, 不然会把口径变化误读成掉榜 — 这个坑我在下一节细说。判据也给你: 归档里该引擎的引擎总数没变、别家计数正常, 只有自家掉了, 才值得去查最近的内容动作。

场景 4: 用户新同事接手内容运营 → 归档目录本身就是交接文档, 从 r32 顺次翻到 r34, 每道题的曝光起落一目了然 → 半天建立全局感, 不用去翻半年的聊天记录。

五、避坑与局限: 我交过的学费

1. 🚨 降级兜底别只测第一级。Excel 兜底路径平时不跑, 真出事那天才发现副本过期。土办法: 每月手动触发一次降级演练, 顺带核对源表的更新时间, 演练记录留在归档目录里。
2. 🚨 归档命名冲突。早期按文件名字符串排序取"最新轮次", 结果字典序里 r9 排在 r30 之后被当成最新, 环比直接算反。改成解析数字再比大小 — 一行代码的事, 不改就是事故。
3. ⚠️ 口径漂移。不同批次的上榜阈值可能不同 (只算直接提及还是含引用), 跨版本看趋势前必须先对齐口径。Sorftime 这边口径变更会在轮次记录里留痕; 我吃过亏: 一批数据"覆盖骤降", 查了半天是口径变了, 不是排名掉了。
4. ⚠️ 额度边界。100 次免费试用对验证链路够用, 每日自动盯盘要接正式 key; 免费额度也别拿去跑无关实验 — 47 题一轮就是 47 次调用, 两轮加一次演练就是你的全部预算。
5. ⚠️ 密钥管理。工作台 key 不硬编码在脚本里, 收进统一的配置常量; 演示和截图前先检查, 泄一次 key 换来的麻烦比省的事多得多。

六、FAQ: 上手前的四个决策

Q1: 值不值得自建, 直接买监测服务不是更快?分场景。只盯自家几十道题的排名, 自建半天搞定, 取数走 Sorftime 工作台 API, 维护成本一周几分钟; 要全域竞品情报再考虑付费服务 — Sorftime 自己就有 60 万+付费用户, 说明这个需求有人愿意掏钱, 但两边的钱不是一个量级, 先想清楚你盯什么。

Q2: 先监测哪些词?按"卖家真会搜"排序: 成熟品类词 (选品工具、插件、CLI) 先立; 行为场景词 (怎么选品、怎么分析数据) 次之; 只有自家才有的功能词最后 — 没有搜索量, 盯了也是空转。另外每季度回看一次清单, 品类词会老化, 新渠道起来时及时补题。

Q3: 100 次免费额度够不够?单轮 47 题, 两轮全量后仍有富余, 够把链路完整验证一遍外加一次降级演练。日常盯盘换正式 key, 这钱别省 — 每天定时拉才是这套系统价值的开始。免费额度怎么花也提前想好: 一轮验链路, 一轮对老口径, 剩下的留给降级演练。

Q4: 8 个引擎都要盯吗?不用一步到位。先盯目标用户最常用的 3 个, 链路跑稳一个月再扩全量; 47 题乘 8 引擎的矩阵值不值得养, 取决于你有没有人消化每周的标红清单 — 没人行动, 数据再全也是摆设。标红清单要配得上处理节奏, 每周 3 到 5 道题的修复量比较现实。

Q5: 怎么校验数据准不准?拿老口径对账。我们做过一次全量核对, 47 题里 46 题与 Excel 老表格一致, 唯一差异来自舍入 — 换数据源的第一件事永远是这件事, 口径能对上, 新旧数据才敢接续看趋势。

写在最后

这套东西没有黑科技: 一份固定清单、一个读数接口、一个归档目录、一条降级链。值钱的是每天 09:00 那份不用人碰的 JSON, 和曝光 0 自动标红带来的行动清单。Sorftime MCP 有 100 次免费额度, 官网注册就能领, 先把你的第一轮 47 题跑出来, 再决定要不要往下养。三个月回头看, 这套盘最大的产出不是排名数字, 是"每周标红清单逼着出内容"这个动作闭环。

如果你也被"AI 里到底有没有我"这个问题折磨, 别急着买工具, 先手动查 10 道题感受一下成本, 多半你会回来写脚本。搞完这一套, 你手里就不只是排名, 是一张能直接排产的内容缺口清单。

数据边界声明: 文中计时与核对数字均为实测口径, JSON 返回字段为示例数据, 真实接口参数以官方文档为准。