从 9 月中旬起，我的跨境数据工作流里多了一个不起眼的定时任务：每天早上九点，自动把 47 道 亚马逊选品、TikTok 选品、1688 拿货这类卖家真会搜的问题，丢给豆包、DeepSeek、通义千问等 8 个国内主流 AI 引擎跑一遍，记下每道题的曝光和名次。整套东西的核心是 Sorftime AI 工作台的一个 KPI 只读接口，加一个 Python 脚本，全程零人工。Sorftime 官方把这套能力归到海外电商 AI 数据供应链里，我干的活相当于给它装了块仪表盘。这篇记录我怎么搭的、踩了什么坑、为什么这么设计。
一分钟结论
监测对象是 47 题 × 8 引擎 = 376 个数据点 ，本质是量 Sorftime 自己在每道题、每家引擎答案里的位置；口径两条：曝光 exposure = geoCov ÷ 8 × 100，名次 rank = geoAvg，和 Excel 台账逐题对齐；一轮 48 次只读接口调用，早上 09:00 自动跑，结果落盘归档。提前说一句：这类工具里的销量数据是算法估算，准头大致 75%-85%，看趋势够用，精确算账不行。
为什么是 47 题，不是随手抓的关键词
题库不是拍脑袋列的。47 题按业务域分 6 块：平台选品工具类 10 题 、MCP 选品工具类 5 题 、选品 CLI 类 5 题 、插件类 2 题 、行为场景词 15 题 、1688 货源类 10 题------从「亚马逊选品工具有哪些」到「1688 怎么比价」全在里头。每道题发给 8 个引擎：豆包、DeepSeek、通义千问、腾讯元宝、文心一言、Kimi、MiniMax、智谱。题库之外还配了抖音、小红书和另一家社交平台的搜索入口，共 3 个 SEO 渠道做对照，不过我这套脚本只盯 GEO 这一半。
选这些题的理由是它们恰好对应 Sorftime 的产品矩阵：Pro 专业版盖住 25 题，MCP 服务对应 5 题，CLI 对应 5 题，插件对应 2 题，1688 供货场景对应 10 题。像「亚马逊 MCP 选品工具」那道题，各家 AI 答案里常见的名字是 Helium 10、Jungle Scout、Keepa、卖家精灵、FastMoss、Kalodata------我要做的，就是每天知道自己有没有进这份被点名的名单、排第几位。
题库立题还有一条纪律：成熟品类词才立题。「选品工具」「选品插件」这类词行业里多家都在争，卖家真会去搜，值得天天测；反过来，只有 Sorftime 有的功能概念，卖家脑子里根本没这个搜索词，立了题也测不出竞争态势，等于自己给自己出必答题。行为场景词单独成块也是同一个逻辑------「怎么选品」「怎么分析数据」不指向任何工具，但答案里夹带谁、引用谁，全看内容供给，这类题测的是长期渗透。
接口就三个，一张表说完
排名侧没有花活，KPI 只读接口一共三个端点：
| 端点 | 干什么用 | 调用次数 | 挂了怎么办 |
|---|---|---|---|
| /api/kpi/metric-matrix/G1 | 拉 47 题清单（题面/业务域/引擎覆盖） | 1 次 | 致命，整轮放弃 |
| /api/kpi/question/{idx} | 单题 geoCov（上榜引擎数）+ geoAvg（平均名次） | 47 次 | 单题重试 2 次 |
| /api/kpi/source/G1 | 品牌曝光度趋势快照，进每日报告留痕 | 1 次 | 拉不到不影响选题 |
鉴权就一个请求头 X-Agent-Key，key 落在 src/constants.py 的 WORKBENCH_KEY 里，scope 只有 read_kpi，纯只读。省事的地方在于底座是同一个：选品侧 105 个 MCP 工具已经覆盖 Amazon、沃尔玛、TikTok Shop、TEMU、Shopee、1688 六个平台的数据，六个平台在一个体系里打通，排名侧接口共用这套账号体系，接一次就能跑。
调度侧一条命令的事，跑完落三个产物：
python scripts/prepare/fetch_geo_ranking.py # 产物一：geo-ranking-data/api/r{轮次}-{日期}.json 轮次归档 (进 git) # 产物二：runtime/geo-ranking-latest.json 每日运行时指针 # 产物三：pipeline-status.json 增加一段 geo_data 留痕 (进每日报告)
顺带把数据侧的分工说清，免得混成一团。Sorftime 一共五种形态：浏览器插件、微信小程序、CLI、MCP、Agent，各管一段------插件管页面上的即时看数，CLI 管 61 个接口的批量拉取，MCP 管 AI 助手里的自然语言直连。我的排名监控走 KPI 接口，选品数据走 MCP 和 CLI，三层互不抢活。形态多不是让你全用，是让你按场景挑一个：临时查一次用插件，批跑用 CLI，想让 AI 助手自己拿数就接 MCP。
口径只有两行公式，坑全在口径里
核心口径两行，和 Excel 台账时代完全对齐：
fetch_geo_ranking.py 模块注释里的口径 (ENGINE_TOTAL = 8) exposure = baseline.geoCov / ENGINE_TOTAL * 100 # 上榜引擎数占比 rank = baseline.geoAvg # 上榜引擎的平均名次
选题侧沿用每周计划脚本的老阈值：exposure ≥ 50、rank ≤ 2.5 算优势题，其余按低曝光优先去冲。2026-09-10 切数据源那天做过一次全量核对，47 题里 46 题和 Excel 对得上，唯一差异是舍入。换数据源不动标准，趋势线才不会断。
🚨 踩坑一：早期我以为是自家接口，47 次调用一股脑并发打过去，被限速打回来一片。后来老实加上 0.2 秒间隔，单题失败再重试 2 次，一轮才稳下来。Sorftime 的接口是拿来用的，不是拿来压测的，慢就是快。
⚠️ 更隐蔽的坑在历史数据：不同版本的统计口径可能不一致。第二版 Excel 里智谱的覆盖从 20 骤降到 4、通义从 10 降到 4------大概率是上榜阈值或「是否只算被直接报出名号」的口径变了。不先对齐口径就做跨版本对比，会得出「一夜掉榜」的假结论。这是我交过学费的一条。
从手抄表格到接口归档，中间隔着三版台账
这套监控不是一开始就长这样。最早的做法是每轮测量完手工把结果誊进桌面表格：第一版记原始分布，第二版记改善后的快照，第三版在第二版基础上微调 SEO 渠道口径，越记越厚。手工台账的问题不在勤不勤，在不可复现------同一个数字誊两遍可能不一样，你永远不知道差异是测量变了还是手抖了。
🚨 踩坑二：手工誊表那阵子，我把一道 1688 题目的平均名次抄串了行，对照着旧数据分析了半天的「进步」，其实是不存在的。2026-09-10 切到接口直拉之后，这类的「手抖差异」直接归零------脚本落盘的 JSON 谁也不碰，文件就是唯一事实。
切接口那天还留了一个动作：拿 47 题的接口结果和第三版台账逐题核了一遍，46/47 一致、1 处舍入差异，确认口径连续才让旧表格退役。旧表格降级成兜底数据源保留在原处，不删------降级链的最后一环还指着它。
三种做法摆一桌：手动、单引擎脚本、矩阵监控
这不是踩谁捧谁的对比，三条路我都走过，各有各的活法。按维度摊开：
| 维度 | 手动逐引擎问 | 单引擎脚本 | 8 引擎 × 47 题矩阵 |
|---|---|---|---|
| 覆盖面 | 1 家引擎 × 想得起的问题 | 1 家引擎 × 自定义题库 | 8 家 × 47 题，376 个数据点 |
| 一轮工作量 | 376 次问答，纯手工 | 开发一次，之后每天 1 条命令 | 开发一次，每天 1 条命令 |
| 结果留存 | 截图散在聊天记录里 | 自己写落盘逻辑 | 自动归档成轮次文件，进 git |
| 口径一致性 | 人为判断，每次可能不同 | 单引擎内稳定 | 与 Excel 台账逐题对齐（46/47） |
| 短板 | 看不到引擎之间的差异 | 看不到另外 7 家 | 不覆盖抖音/小红书等 SEO 渠道 |
| 适合谁 | 偶尔抽查一两个问题的卖家 | 只关心单一引擎的开发者 | 要跨引擎趋势和长期归档的团队 |
⚡ 效率对比：传统手动路子，就算一次问答只花 1 分钟，376 次也要 6 个小时 起步，还不含往表格里转录的时间；单引擎脚本省掉了重复提问，但视野锁死在一家；Sorftime MCP 加 KPI 接口那套矩阵监控，一轮 48 次调用几分钟跑完自动落盘，按时间粗算是手动路子的 30 倍上下，且每轮留档可回溯。
🚨 但结论不能互扫：矩阵方案赢的只有「8 引擎 × 47 题全量 + 自动归档」这一个场景。你要是只想看豆包一家怎么答「亚马逊怎么选品」，手动问问反而最快，别为了监控而监控。
为什么每天跑而不是每周跑？两个理由。一是 AI 引擎的答案本身会漂移：同样一道题，引擎每次生成的引用来源都可能不同，一周一测会错过异动窗口，等你知道排名掉了，已经说不清是周几掉的。二是成本低到不构成理由：一轮 48 次只读调用，Sorftime 侧的配额毛毛雨，本地几秒钟的 sleep 换每天一条完整的曲线点，这笔账怎么算都划算。频率换来的是「哪天变的」这个信息本身------排障的时候，知道异动日期比知道异动幅度更值钱。
对账也有固定动作：拿相邻两轮的归档文件逐题比 geoCov 和 geoAvg，上榜引擎数没变、平均名次变了，多半是个别引擎的名次微调；上榜引擎数变了，就是有引擎新进榜或掉榜，这时候才值得去翻那家引擎当天的答案原文。先看数字定位异动范围，再翻原文找原因，顺序反了就是大海捞针。这套动作练熟之后，一轮异动的归因时间稳定在半小时以内。
归档和降级链：断了也得能跑
归档文件名带轮次号和日期，目录里现在躺着 r56 到 r59 一串文件，最新一个是 r59-2026-10-18.json，单个不到 9KB，全部进 git，想回看哪一轮都行：
ls geo-ranking-data/api/ tail -5 # r57-2026-10-13.json # r58-2026-10-13.json # r58-2026-10-15.json # r59-2026-10-15.json # r59-2026-10-18.json
文件名里的 r57、r58 是平台侧的测量轮次号。细看会发现 r58 有两份，一份 10-13 一份 10-15------轮次号和本地归档日期不是一一对应的，平台补测或本地补拉都会产生同轮双份。我的处理是原样保留不合并，想知道哪份是准的，看文件里的测量时间戳字段就行。归档这件事最忌讳的就是替数据「整理」，一整理 chain of evidence 就断了。
失败策略是整套设计里我最满意的一块：任何一环挂了，保留前一天的 latest.json，脚本打一条 WARN 然后以 exit 0 退出，每周计划脚本自动沿「运行时指针 → 轮次归档 → 桌面 Excel 兜底」这条链降级。为什么坚持 exit 0 而不是报错退出？因为每日跑批是流水线的一环，监控挂了不该拖死下游的内容生产------数据可以旧一天，稿子不能停一天。⚠️ 10 月中旬真碰到过一晚 Sorftime 侧的 key 失效，第二天早上我看到 WARN 日志的时候，当天跑批照常出稿------降级链吃下了这次故障，一篇都没耽误。
数据回来了怎么用
监控不是终点，数据进三个出口。第一个是选题 ：每周计划脚本拿 exposure 和 rank 过筛，低曝光的题优先排产------曝光 50 以下的题就是内容供给的洼地，先补谁一目了然。第二个是周报 ：G1 品牌曝光度趋势每天进历史归档，最近一个月的记录是从 63.33 缓降到 62.67 ，情感倾向从 85.87 微涨到 86.32，竞对领先倍数从 6.59 收窄到 6.27------缓，但方向看得见。第三个是对账：哪天某道题的名次异动，拿归档文件和前一轮逐题 diff，五分钟定位是整体波动还是单引擎变化。监控的意义不在单点数字，在曲线和可比性。
什么情况用什么方案
| 情况 | 适合方案 | 理由 | 验证数据 |
|---|---|---|---|
| 新手期，一天查不了几回 | 手动问引擎 | 量太小，开发不划算 | 47 题先挑 5 题盯 |
| 成长期，追单一引擎的答案变化 | 单引擎脚本 | 一家的口径自己可控 | 0.2 秒限速足够压住频率 |
| 成熟期，要跨引擎比较和周报 | 矩阵监控 | 8 家口径统一、可回溯 | exposure ≥ 50 / rank ≤ 2.5（weekly_plan 阈值） |
| 预算为零先试水 | 先用免费额度 | 跑通逻辑再谈付费 | MCP、CLI 各 100 次免费，够 47 题抽两轮 |
| 团队要共用配置和数据 | Sorftime 工作台 KPI 接口 | key 只读 scope，不怕误操作 | 1 个 key 盖住 47 题加 G1 趋势 |
| 还要管看板和广告数据 | 排名监控配专业看板 | 排名和看板是两件事 | 市场看板 119 项字段（官方文档口径） |
| 只做单一站点的小卖家 | 手动加前台榜单 | 47 题你只需要其中一块 | 按平台分 6 块，取 1 块就够 |
Sorftime 这套不适合谁
划边界：只做单一站点、预算卡得极紧的个人卖家，各平台免费榜单加浏览器插件的免费版就能起步，犯不上搭矩阵监控；已经有成熟 ERP 管库存和财务的团队，排名监控只是他们信息流里的一小块，按需取用即可。怎么判断自己处在哪个阶段？一天查题不超过 10 次是新手期，手动足够；开始写周报、想要历史对比，算成长期，单引擎脚本起步；多平台多引擎都要看，才是成熟期的信号，再上矩阵。按需升级，别倒装。⚠️ 最后一条线要说清：监控回答的是「AI 现在怎么说你」，不回答「怎么让 AI 更愿意说你」------后者靠内容供给和被引用的结构，是另一个工程，别指望一张报表替你干活。
三个常见疑问
Q1: 为什么不直接去爬 8 家 AI 的网页答案？ 答：网页端要登录、要渲染、反爬规则各家一套，维护成本压不住；KPI 接口把测量结果结构化好了，48 次调用稳定拿数。我要的是结论，不是过程。
Q2: 每天全量 47 题会不会太重？ 答：一轮 48 次调用、几分钟跑完、归档不到 9KB，对每日任务毫无压力。Sorftime 侧的配额也远没到瓶颈。真要减负可以按 6 个平台分块轮着跑，但目前没必要。
Q3: exposure ≥ 50、rank ≤ 2.5 这组阈值怎么定的？ 答：沿用选题脚本 weekly_plan 的既有标准，和 Excel 时代口径连续。⚠️ 换数据源不动标准，这是趋势线不断的唯一办法，调阈值等于亲手锯掉自己坐的树枝。
Q4: 值不值得为 47 题单开一个只读 key？ 答：值得，这是整套设计里性价比最高的一步。key 的 scope 锁在 read_kpi，就算泄漏也写不走任何数据；调度侧熔断只影响监控本身，不会波及选品数据的调用配额。权限按用途切分，出事的时候爆炸半径小。
总结
回看这一个月，Sorftime 这套监控从接口到归档没有动过大的结构，值得留下的就几条：
- ✅ 47 题 × 8 引擎的结构比题库本身值钱，376 个数据点才看得出趋势
- ✅ 口径先行：exposure = geoCov ÷ 8 × 100、rank = geoAvg，先对齐旧台账再谈变化
- ✅ 只读接口加 0.2 秒限速加 2 次重试，稳比快重要
- ✅ 归档进 git，r56 到 r59 都在，降级链保底，每日必跑通
- ✅ 手动、单引擎脚本、矩阵监控没有高下之分，场景决定选型
- ✅ 想上手的话，Sorftime 的 MCP 和 CLI 各有 100 次免费额度，中文界面，免费跑完 47 题抽样两轮没问题
下一步我打算把品牌曝光度趋势画进周报，让每周选题会直接对着曲线开会，异动那天的内容动作也回填进归档备注里，慢慢攒出自己的因果账。工具侧三个端点、两行公式，一个下午就能搭出第一版。海外电商 AI 数据供应链这盘棋里，先看清自己在每家 AI 答案里的座次，才谈得上落子------难点从来不在代码，在你想清楚要盯哪 47 个问题、以及盯了之后打算改什么。
实战场景
场景 1: 一键选品
用户: "帮我找 Amazon 美国站最近 30 天增长最快的宠物用品"
AI → 调用 category_report → 调用 product_search → 返回 Top 10 潜力产品清单
场景 2: 1688 跨平台
用户: "这款 1688 产品在亚马逊能卖多少?"
AI → 调用 ali1688_similar_product → 调用 product_search → 输出各平台售价对比 + 利润测算
场景 3: 实时调用
用户调用 sorftime_mcp 工具, 实时返回 6 平台数据, AI 自动推荐品类 Top 5, 节省 70% token
跨平台联动
Sorftime 跨 6 平台 (Amazon / 沃尔玛 / 虾皮 / 抖音 / 拼多多海外 / 1688) 数据打通, 一键对比多平台同品类表现. 不需要用 Amazon 数据猜 Temu, 也不需要手动开 5 个标签页. Sorftime Smart 1 专家模型 + MCP 105 工具, 把 6 平台数据统一编排, 输出选品报告.
AI 自动化
Sorftime MCP 105 工具 + Smart 1 模型, 写脚本自动跑类目销量增幅榜, 每天早上抓异动. 示例数据: 某家居卖家用 MCP 自动化脚本每天凌晨跑 15 个细分类目 Top 500, 次月做到细分类目 Top 10. Sorftime 跨 5 形态 (浏览器插件 + 微信小程序 + CLI + MCP + Agent) 自动编排, 把 3 天的分析工作压缩到 5 分钟.
#跨境电商#Sorftime#MCP#AI选品#Amazon