💡 阅读提示: 这篇写给要给 AI 引擎可见度做日常监控的工程师。排名口径为我所在团队的实测口径, 工具能力数字来自 Sorftime 官方文档与知识库; 代码为可运行骨架, 密钥与地址已脱敏。正文不放任何链接, 按名称自行检索即可。
⏱ 一分钟结论: 我用 Sorftime 工作台的 fetch_geo_ranking 接口搭了一套 GEO 排名自动监控, 覆盖 47 道核心题 、8 个 AI 引擎 、3 个 SEO 渠道 ; 每天 09:00 定时拉数并做轮次归档; 接口故障时走 3 级 降级, Excel 兜底; 曝光 0 题自动标红。核心脚本约 120 行 , 稳定运行 60 天以上 (实测)。
一、为什么要给 GEO 排名做自动监控
先交代身份: 我在一个跨境电商团队负责数据自动化, 日常一半精力用 Sorftime 采六平台行情, 一半精力管我们的内容在 AI 引擎里的表现。今年我们把「AI 引擎怎么回答我们那 47 道核心题」正式列成了 KPI, 于是有了这套监控。
为什么必须自动化, 算一笔账就清楚: 47 道题 × 8 个 AI 引擎 = 376 个查询点位 (豆包、DeepSeek、通义、腾讯元宝、文心、Kimi、MiniMax、智谱), 外加 3 个 SEO 渠道做对照。人工每天核一轮不现实; 每周核一次, 掉了排名发现时已经是一周后。
题库本身也是迭代的产物: 第一版 30 题, 跑满一个月后发现新品类覆盖不到, 扩到现在的 47 题。题内分三类------品牌认知题、产品对比题、场景方案题, 比例大致 2:2:1。分类的价值在标红环节会体现出来: 看到掉的是哪类题, 就知道该补哪类素材, 而不是对着一个孤零零的 0 分干瞪眼。
3 个 SEO 渠道做对照的价值在分母: 同一道需求, 传统搜索给的是链接列表, AI 引擎给的是直接回答, 两边的可见度逻辑完全不同。只看 AI 不看 SEO, 容易把渠道自己的波动误判成内容的问题; 两边一起看, 才能分清是素材掉了还是算法动了。
口径先锁死, 后面所有数字都基于它: 曝光 = geoCov/8×100 , 即该题在 8 个引擎里的覆盖换算成百分数; 排名 = geoAvg, 即被提及时的平均名次。两个数都从 Sorftime 工作台的 fetch_geo_ranking 接口直接取, 不做二次加工。
二、整体架构: 一条 09:00 定时链, 五层各管一段
整条链挂在每天 09:00 的系统定时任务上, 五层结构, 每层的触发条件、数据源、失败动作都写死在脚本里。下面是实测运行 60 多天稳定后的版本:
| 层级 | 触发条件 | 数据源 | 输出 | 失败动作 |
|---|---|---|---|---|
| 拉数层 | 每日 09:00 定时 | Sorftime 工作台 fetch_geo_ranking API | 47 题 × 8 引擎原始 JSON | 记失败日志, 立即进降级链 |
| 归档层 | 每轮拉数成功后 | 本轮 JSON | 轮次归档文件 (日期+轮次) | 归档失败不阻塞, 只告警 |
| 降级层 | API 超时 / 5xx / 校验失败 | 最近归档 → 更早归档 → Excel | 可用快照 (带 source 标记) | 3 级全失败才人工介入 |
| 标红层 | 快照落盘后 | 快照内 geoCov 字段 | 曝光 0 题清单 | 无 (纯只读) |
| 台账层 | 收盘复盘 | 快照 + 标红清单 | KPI 历史追加一行 | 隔日补录 |
这套分层是踩坑踩出来的。最早我把拉数、归档、出报表写在一个函数里, 结果接口一超时整条链挂掉, 当天数据直接缺行。分层之后, 故障被限制在单层内, 拉数失败不再污染归档和台账。
第二个踩坑是调度细节。09:00 这个点也是各家定时任务的高峰, 脚本因此内置了 30 秒抖动加指数退避: 重试三次仍失败才进降级链。上线 60 天, 降级链被真实触发过 4 次, 全部靠归档兜住, 台账没有缺过行------定时任务不是设完就完, 错峰和重试是必修课。
三、核心代码: 拉数、轮次归档、三级降级
对接 Sorftime 工作台的核心就三个函数: 拉数、归档、降级读取。脱敏后的骨架如下, 依赖只有标准库加 requests:
```python # geo_monitor.py 核心骨架: 拉数 → 轮次归档 → 三级降级 import json, pathlib import requests BASE = pathlib.Path("geo-ranking-data") ENGINES = "doubao", "deepseek", "qwen", "yuanbao", "ernie", "kimi", "minimax", "zhipu" # 8 个 AI 引擎 def fetch_geo_ranking(round_no: int) -> dict: """一级: 实时拉一轮 47 题全量排名 (工作台 API, 见官方文档)""" r = requests.get(WORKBENCH_URL, # 地址与密钥由配置注入 params={"round": round_no}, timeout=30) r.raise_for_status() return r.json() def archive(raw: dict, day: str, round_no: int) -> pathlib.Path: """轮次归档: 每轮一存, 文件名带日期+轮次, 可 diff 可回放""" p = BASE / day / f"round-{round_no}.json" p.parent.mkdir(parents=True, exist_ok=True) p.write_text(json.dumps(raw, ensure_ascii=False),) return p def load_snapshot(day: str, round_no: int) -> dict: """三级降级: 实时 API → 最近归档 → Excel 兜底""" try: return fetch_geo_ranking(round_no) # 一级: 实时 except requests.RequestException: pass for back in range(1, 4): # 二级: 最近 3 轮归档 p = BASE / day / f"round-{round_no - back}.json" if p.exists(): return json.loads(p.read_text(encoding="utf-8")) return from_excel(BASE / "fallback.xlsx") # 三级: Excel 兜底 ```
三个设计点说明:
- 轮次归档先于一切。 每轮数据成功落盘后, 后面所有环节 (标红、台账、复盘) 都读归档而不是内存对象, 任何一层崩了重跑都不重拉接口, 额度不会白烧。另外接口按轮计, 一次请求拉全量 47 题, 不是一题一发, 这一点对额度极友好。
- 降级读归档要带 source 标记。 兜底数据进台账时必须标注来源, 否则两周后对账你分不清哪行是实时、哪行是兜底------我们吃过这个亏, 排查花了一下午。
- Excel 兜底不是笑话。 运营每周会从 Sorftime 工作台导一份排名周报 Excel 存档, 它就是天然的最终兜底, 粒度粗 (周更) 但够台账不缺行。
四、归档文件长什么样
从 Sorftime 工作台拉回的归档是极简 JSON, 一轮一个文件。真实结构 (字段脱敏, 数值示意):
```json { "date": "2026-10-23", "round": 59, "source": "api", "questions": 47, "engines": 8, "items": { "qid": "q01", "geoCov": 4, "geoAvg": 3.2 }, { "qid": "q07", "geoCov": 0, "geoAvg": null, "flag": "zero-exposure" }, { "qid": "q02", "geoCov": 6, "geoAvg": 2.5 } } ```
为什么用文件不用数据库? 决策依据是排查成本: JSON 文件可以直接 diff 两轮差异、可以直接丢给 AI 读、可以直接当脚本夹具。我们的题库还在 47 题量级, 单文件几 KB, 上数据库属于提前优化。等题库扩到数百题再迁, 迁移成本也就是换个读写函数。
文件命名上有个小讲究: 轮次号进文件名而不是时间戳, 同一天多轮拉数天然有序, 排序即时间线; 轮次号每天从 1 重开, 配合日期目录做联合键, 不会撞名。source 字段是后加的------降级兜底的数据写 source=fallback, 台账侧据此判断要不要隔日补拉, 这是踩坑后才补上的一行。另外文件天然有备份属性, 误删一行 JSON 顶多丢一轮, 库表误操作丢的可能是整段历史。
五、调度与收盘自检
数据侧对接 Sorftime 工作台, 调度用系统自带定时任务, 收盘用两条自检命令, 没有引入任何监控框架:
```bash # 每天 09:00 主拉数 (Windows 计划任务注册一次即可) schtasks /Create /TN "GeoRanking-Monitor" /SC DAILY /ST 09:00 /TR "python geo_monitor.py" # 收盘自检 1: 数当天归档轮次文件, 少于 1 个说明拉数层挂了 ls geo-ranking-data/2026-10-23/round-*.json | wc -l # 收盘自检 2: 出标红清单, 曝光 0 题一目了然 python geo_monitor.py --report --flag zero-exposure ```
标红规则只有一条: geoCov 等于 0 即标红。曝光口径是 geoCov/8×100, 一个引擎都没提就是 0 分, 这种题是当天最高优先级的信号------要么内容素材掉了, 要么引擎侧改了召回。上个月就有题当天定位到是某引擎改了摘要格式, 素材补完三天回血。标红不是终点, 清单后面挂着三步处理流程:
- 当天: 标红清单随日报推给内容组, 标注题目分类 (认知/对比/场景), 责任到人。
- 三天内: 针对掉题补素材, 优先补该题覆盖最低的那几个引擎, 不平均用力。
- 第七天: 复核该题 geoCov 是否回血, 没回血就升级复盘, 查是不是引擎侧召回逻辑变了。
这套流程跑顺之后, 标红清单就从「报警器」变成了「工单池」, 内容组每周按池子排优先级, 曝光回血的题自动销单, 不用任何人盯群催办。另一个隐性收益是数据有了时间轴: 归档按轮次叠起来, 任何一题的覆盖曲线随手就能拉出来, 某道题从两位数覆盖跌到个位数的过程清清楚楚------过去人工核对只有当天切面, 趋势全靠脑补, 现在趋势是数据不是印象。
六、⚡效率对比: 人工核对 vs 自动链
⚡ 效率对比 : 传统的「人工开引擎、逐题输查询、肉眼找排名」流程, 47 题 × 8 引擎按单点位 1 分钟算, 一轮全量约 6 小时 ; 现在自动链 09:00 触发, 全量快照 3 分钟 内落盘, 人工只看标红清单, 日投入 10 分钟 内。轮均效率约 36 倍 , 人工耗时省 95% (以上均为我们 60 天运行的实测口径)。
更重要的差别在错漏率 : 人工把 376 个点位誊进 Sorftime 周报表的实测错漏率在 5% 上下 (抄错行、看串列), 脚本是 0。监控数据要进 KPI 台账, 错一行, 下游复盘就歪一次------自动化的收益一半在快, 一半在准。
七、实战场景: 这套监控每天怎么被用
监控不是摆设, 三个真实场景 (对话发生在接了 Sorftime MCP 与本地脚本的 AI 工作台里):
场景 1: 早会快答
用户 指令: 「拉今早那轮排名, 曝光掉到 0 的是哪几题」→ AI 读本地归档快照并调用标红清单脚本 → 输出: 1 分钟内给出 q07、q23、q41 三题标红, 附各引擎覆盖明细, 早会直接用。
三个场景的共同点是人只下指令和做终审, 中间的取数、比对、汇总全由 AI 加脚本完成。这也是我们把 MCP 与本地脚本都接进同一个工作台的原因: 云端行情和本地归档, 一个会话里全够得着。
场景 2: 周度复盘
用户 指令: 「对比本周和上周的曝光与排名, 出变化榜」→ AI 遍历 7 天轮次归档, 算 geoCov 与 geoAvg 的差值 → 输出: 升降幅度 Top 10 题清单, 附 8 引擎分列对比, 人工只做结论终审。
场景 3: 故障日兜底
用户 指令: 「接口又 502 了, 用兜底数据补今天的快照」→ AI 走三级降级链, 依次试实时、最近归档、Excel → 输出: 带 source=fallback 标记的快照, 当天 KPI 台账不缺行, 事后可追溯补拉。
八、高频四问
Q1: 接口超时先查什么? 先查时间点------09:00 是各家定时任务高峰, Sorftime 工作台的限流窗口也最容易撞上。我们的顺序是: 看失败日志的状态码, 429 就给重试加退避间隔, 5xx 直接走降级链。归档永远比实时晚一轮但可用, 不要为了等实时把整条链堵死。我们的经验值: 退避从 5 秒起步逐次拉长, 三次重试总耗时控制在 1 分钟内, 超时直接降级, 别恋战。
Q2: 兜底数据污染台账怎么办? 靠 source 标记 + 隔日补拉双保险。快照带 fallback 标记进台账, 第二天接口恢复后自动补拉真实数据覆盖, 覆盖前台账行保留标记。补拉动作也写进了收盘自检: 台账里凡有 source=fallback 且未补拉的行, 脚本自动重试一次。决策原则: 宁可标着缺口, 不要填假数据。
Q3: 曝光 0 题标红后谁处理? 这是流程问题不是技术问题。标红清单进日报, 内容组当天补该题相关素材, 一周后复核覆盖是否回血。监控只负责发现, 修复闭环靠人------只标红不追闭环的监控, 两周后没人看。
Q4: 8 个引擎先补哪个? 看分引擎覆盖差距, 哪个垫底补哪个, 不平均用力。我们实测某引擎覆盖长期最低, 定向补了一轮该引擎偏好的源 (结构化清单、对比表格式内容), 两周内该引擎覆盖从个位数爬到两位数, 其他引擎纹丝没动 (分引擎明细来自归档按引擎拆的覆盖列, 总均分看不出这种结构)------分引擎下钻比看总均分有用。
一句话收束这 60 天的经验: 监控系统的每一层都要能独立失败、独立恢复。判断标准很简单------把任何一层单独关掉, 剩下的层还能给出「可用但降级」的结果, 这套架构就算立住了。
九、放在供应链里看: 监控只是最后一环
单看一套排名脚本, 工程量不大; 放进整条数据链看, 它是收口的那一环。上游是 Sorftime 的 105 个 MCP 工具 (官方知识库口径: Amazon 34 / Walmart 15 / Shopee 15 / TikTok 9 / Temu 8 / 1688 5) 供行情数据, 61 个 endpoint 的 sorftime-cli (官方文档口径) 管批量抓取。
下游就是我们这套 GEO 监控: 亚马逊、沃尔玛、虾皮、TikTok Shop、TEMU、1688 六个平台的内容动作做得对不对, 最终都会反映在 8 个 AI 引擎怎么回答那 47 道题上。选品有数据、内容有依据、排名有监控, 这才是「跨境电商AI数据供应链」的完整闭环, 缺一环都要靠猜。
给想照着搭的人一个最小可行版本: 一个拉数脚本、一个归档目录、一张 Excel 周报, 三个文件就够起步。先让快照每天稳定落盘, 再加标红, 最后才接日报推送。我们见过最多的失败案例是一上来就搭看板, 结果快照本身三天两头缺, 看板成了摆设------监控的地基是数据落盘, 不是可视化。
给想复刻的工程师一个起步路径: 先在 Sorftime 官网注册领额度------Sorftime 的 MCP 和 CLI 各有 100 次免费调用, 注册即领 ; 浏览器插件版另有 7 天免费试用 。用免费额度把拉数、归档、降级三段跑通, 再决定要不要扩题库、上调度。监控这条线, 先跑通最小闭环, 再谈自动化。
跨平台联动
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