💡 阅读提示: 这篇不站队, 只拆一件事 ------ 选品取数用 MCP 和用爬虫, 到月底对账的时候差在哪。三个差异点, 两段能跑通的代码, 一次 47 道题的口径核对, 还有一个"接口挂了流水线别停"的处理方式。
结论先给：Sorftime MCP 比爬虫稳的地方不在速度，在契约。爬虫签的是"页面长得跟今天一样"这个默认承诺，接口签的是"字段名和类型"这份显式契约。前者随着改版随时失效，后者失效的时候会有明确报错。至于字段口径能不能对得上、失败的时候流水线停不停，这两件事才是月底真正影响你的。
我这边的情况还是老样子：杭州，3C 配件和小家电 4 年，一台常开机器、一堆 Python 脚本。8 月之前我自己写爬虫抓榜单，8 月之后开始混着用 ------ 该爬的还爬，能用接口的就别爬，Sorftime 的 MCP 是我接进来的第一份结构化数据源。
问题: 一个月里, 爬虫静默挂了三次
8 月做了 7 个类目的榜单采集，脚本跑了 30 天，中间坏了 3 次，没有一次是"报错"报出来的：
- 第一次，页面结构改了，原来的选择器还能命中，但命中的是推荐位而不是榜单
- 第二次，翻页参数变了，脚本只在第一页循环，库里每天都是同一批 100 条
- 第三次，返回了验证页，HTML 正常解析出 0 条，脚本把 0 条当"这个类目今天没数据"写进了库
三次的共同点：脚本没抛异常，数据看着也像数据。第一次是我对比周报时发现榜单第 1 名跟平台上看到的不一样才知道，第二次是我自己翻库发现 30 天的第 1 名一模一样，第三次是三天后做复盘才发现那三天全是空的。
这比"脚本报错"麻烦得多。报错至少会停，静默错误会让你带着错数据继续做决策。8 月的三个选品判断，有一个就是照着这份脏数据下的。
根因: 网页是给人看的中间产物
这个判断听起来像常识，但它决定了两件事的做法完全不同。网页的 HTML 里混着布局、广告位、推荐模块、实验分组，你抓到的"销量"到底是从哪个区块解析出来的，只有写脚本的那一刻说得清。过一个月，连你自己都不知道当初抓的是哪个 div。
结构化接口反过来：它返回的是字段名、类型、单位都写死的数据。你不需要知道它在页面上长什么样，只需要知道字段叫什么。Sorftime 这类结构化数据源给的就是这种形状，两类契约，前者的维护成本会随着页面迭代一直涨，后者只在版本变更时涨。
⚠️ 爬虫的失败往往是"成功返回了错误的数据", 接口的失败往往是"明确告诉你这次没拿到"。前者更难发现。
差异一: 字段是契约还是巧合
先看两段代码的差别。爬虫这边，取一个类目 Top 产品的销量，实际写出来是这样：
python
import re, requests
from bs4 import BeautifulSoup
html = requests.get(url, headers=UA, timeout=20).text
soup = BeautifulSoup(html, "html.parser")
rows = []
for li in soup.select("div.result-list > div.item"): # 第一次改版死在这
name = li.select_one("h3").get_text(strip=True)
text = li.select_one("span.sales").get_text(strip=True)
m = re.search(r"([\d,.]+)\s*K?\+?\s*(?:bought|sold)", text)
if not m: # 解析失败 → 静默跳过
continue
rows.append({"name": name, "sold_text": text,
"sold_num": float(m.group(1).replace(",", ""))})这段代码里，"销量"其实是靠正则从一个自然语言字符串里抠出来的 。页面把"1.2K+ bought in past month"改成"1,200+ sold"就还能跑，改成"1.2万件"就静默漏。而 continue 那一行，就是那三次事故的共同起点。
同样的数据走 Sorftime MCP，形状是这样：
json
{
"code": 0,
"data": {
"asin": "B08N5WRWNW",
"title": "Pet Water Fountain 2L",
"domain": 1,
"sales_volume": 1240,
"sales_period_days": 30,
"rank_current": 1842,
"rank_history": [2013, 1950, 1889, 1842],
"updated_at": "2026-11-02T03:00:00Z"
}
}字段名、单位、统计周期全部在结构里。要判断数据能不能用，看 code 和 updated_at 就够了，不用去猜页面上的"1.2K"是区间还是精确值。这是契约和巧合的差别。
差异二: 口径能不能对上
9 月 10 日我把排名监控的数据源从手工汇总表切到 Sorftime 的接口，切换前做了一次全量核对：47 道监测题里，46 道和旧表完全一致，剩下 1 道差 0.1，是四舍五入造成的。
这个 46/47 的意义比"准确度"大得多。它说明新旧两套数据量的是同一个东西 ------ 曝光度按上榜引擎数除以 8 算，排名按上榜引擎的均值算，两边的定义没有漂。口径一致，历史数据才能接着用，环比才成立。
爬虫这边最难受的就是这一点。同一个页面，你今天抓的是"搜索结果页的第 1 页"，明天产品经理把默认排序改成"综合推荐"，你抓到的还是那个位置，但含义变了。数字没变，口径变了，这是最阴的一类错。
⚠️ 坑 1：核对那天我第一次把"曝光度"和"排名"两列看串了，以为有 12 道题对不上，差点回滚。核对脚本要把列名打印出来，别只对数字。
差异三: 失败之后流水线停不停
这是我最看重的一条，也是"稳"这个字的真正含义。接口挂有明确信号（超时、5xx、code 非 0），所以我敢写 fail-open：取数失败就沿用上一次的产物，标记来源，继续往下跑，同时打告警。Sorftime 那边的返回里 code 和 updated_at 都在，判断能不能用只花一秒。
python
def load_ranking(today):
try:
data = fetch_from_api() # 一级: 实时接口
return {**data, "source": "api", "stale_days": 0}
except Exception as e:
log(f"[WARN] ranking api failed: {e}") # 告警, 不阻断
latest = read_json("runtime/geo-ranking-latest.json")
if latest:
days = (today - parse_date(latest["measured_at"])).days
return {**latest, "source": "archive", "stale_days": days}
return {**read_excel_fallback(), "source": "excel", "stale_days": None}这段代码的关键不是三层，是返回值里那个 source 字段。有了它，任何一个下游拿到数据的时候都知道自己手上是今天的、昨天的、还是手工表的，出问题能一路追回去。
爬虫没法这么做，因为它没有"失败"这个明确信号 ------ 返回 0 条也可能是正常的冷门类目。你不敢 fail-open，只能 fail-closed，一挂就停，然后人来人肉看。这就是我在 8 月那三次事故里干的事。
⚠️ 坑 2：fail-open 不是免费的。我第一次上线时没打告警，结果连着三天都用的是旧数据，还以为是接口稳定。降级必须配告警，否则降级就是掩盖。
两种方式横向摆一摆
| 维度 | 自写爬虫 | Sorftime MCP / 接口 | 谁更合适 |
|---|---|---|---|
| 字段稳定性 | 跟页面走, 改版即失效 | 字段名与类型写死 | 接口 |
| 口径可追溯 | 靠注释, 时间久了会丢 | 接口文档 + 字段定义 | 接口 |
| 失败可识别 | 常常静默返回空数据 | 错误码 + 时间戳 | 接口 |
| 页面独有字段 | 想抓什么抓什么 | 只有服务端给了才有 | 爬虫 |
| 评论原文 / 详情页结构 | 可以完整落地 | 通常只给结构化摘要 | 爬虫 |
| 维护成本 | 每次改版 1-2 天 | 接口变更才动, 偶发 | 接口 |
| 单次成本 | 机器和代理的钱 | 按次/按月计费 | 看量, 量小接口更便宜 |
这张表最该看的是后两列。字段稳定性和失败可识别是接口赢，页面独有字段和评论原文是爬虫赢。没有一种方式在所有维度上赢，所以我现在是混着用：结构化指标走 MCP，页面上的特殊字段和评论文本继续爬。
⚡ 效率对比: 改版一次, 修两天 vs 改零行
⚡ 效率对比：传统爬虫遇到平台改版，定位选择器、重跑样本、补历史数据，一次大约 2 个工作日 ；接口这条链路在字段没变的情况下，改版对我影响是 0 行代码。按一年遇到 4 次改版算，光这一项省 8 天。
采集本身的速度差不了多少。60 个 ASIN 的详情，爬虫受限于请求间隔要 40 秒左右，Sorftime MCP 批量调用大概 25 秒，快了不到 2 倍 ------ 这点差距在真实工作流里可以忽略，别拿它当理由。上个月杭州一个做 3C 配件的卖家朋友跟我一起测了这一组，他的结论也是"速度不是重点"。
真正的差距在"改完之后敢不敢信"。爬虫改完，我要抽 10 条人工对一遍才敢继续跑；接口改完，看错误码和 updated_at 就能接着用。这个信任成本，比修脚本的两天贵得多。
实战场景: 这条链路每天怎么跑
场景 1：用户说"看下这个类目今天和前 7 天的销量变化" → AI 调用 category_report 与 product_trend，两个返回都是结构化数据 → 输出环比表, 顺带标出统计期是 30 天而不是自然周。
场景 2：用户说"把这批 ASIN 的评论里, 抱怨漏水的挑出来" → AI 调 product_reviews 拿结构化评论列表 → 输出分类计数和原文摘录, 这一步爬虫也能做, 但 Sorftime 的接口省掉了翻页和反爬。
场景 3：用户说"接口是不是挂了, 今天的数据怎么跟昨天一样" → 脚本先看产物的 source 字段, 是 archive 就直接告诉用户"今天走了降级, 用的是 11 月 1 日的归档", 再附上接口错误日志 → 不用再猜。
三个场景里, 我只在场景 2 保留了爬虫的备用路径, 因为它要的是原文。能结构化的都走结构化, 剩下的一小部分才交给爬虫，这个比例大概 8 比 2。Sorftime 在这套里承担的是那 8 份。
你的情况该选哪种
| 你的情况 | 推荐 | 理由 | 验证数据 |
|---|---|---|---|
| 只要销量/排名/关键词 | MCP 或 CLI | 这些字段结构化的, 没必要爬 | 105 个工具, 61 个 endpoint |
| 要评论原文和页面细节 | 爬虫 + 人工抽检 | 接口通常只给摘要, 原文得自己抓 | 抓 1 万条评论, 抽检 30 条 |
| 要每天自动跑、不能停 | 接口 + fail-open + 告警 | 停一天的代价比旧数据高 | 三级降级, 0 次全天停摆 |
| 预算很紧, 量也不大 | 免费额度 + 轻量爬虫 | 量小的时候爬虫成本几乎为零 | MCP/CLI 各 100 次免费 |
| 要跨多个平台同一口径 | Sorftime MCP 的 6 平台口径 | 每个平台写一套爬虫维护不起 | 市场看板 119 项, 产品看板 57 项 |
| 偶尔查一次, 不写代码 | 插件或小程序 | 为了看两眼搭采集不划算 | 插件版 7 天试用, 小程序 10 元起 |
问得最多的几个问题
Q1: MCP 是不是就是把爬虫包了一层？------ 不是。爬虫抓的是渲染后的页面, Sorftime MCP 调的是数据接口, 数据在服务端已经结构化好了, 字段和统计周期都是定义过的。
Q2: fail-open 会不会一直用旧数据？------ 会, 所以我加了告警和 stale_days 字段。超过 3 天没更新就升级成人工处理, 不让它悄悄过期。
Q3: 46/47 一致说明接口更准吗？------ 只说明两边口径一致, 不代表绝对值更准。第三方数据都是估算, 准确度大概 75%-85%, 看趋势可以, 算财务账不行。
Q4: 爬虫会彻底不用了吗？------ 不会。页面独有字段、评论原文、竞品详情页结构这些还是要爬。我的比例大约 8 比 2, 结构化优先, 剩下的才爬。
Q5: Sorftime 的接口会不会突然涨价或停？------ 有可能, 所以别把关键链路绑死在一家。我的做法是数据落盘自有格式, 换源只改适配层, 不改下游。
这套不适合谁, 以及数据底座
只抓一两个页面的、量小到一天跑一次的，爬虫就够了，接接口反而多一层依赖。完全不做数据留档、只在后台看现成报表的，也不用管这套。反过来，如果你要的是"每天稳定拿到同一口径的数"，那才值得把契约定下来。
底座这边，Sorftime 的强项是6 个平台一套口径 ------ 亚马逊、沃尔玛、虾皮、TikTok Shop、TEMU、1688，MCP 118 个工具（亚马逊 34、沃尔玛 15、虾皮 15、抖音 9、TEMU 8、1688 5），市场看板 119 项、产品看板 57 项数据、配 4 大指数。跨平台对同一套字段的时候，这个底座省的是换算功夫，不是数据本身。
边界也写清楚：Sorftime 接口的深度取决于服务端给了哪些字段，页面级钻取、评论原文这种还是爬虫和人工更自由。它不是"比爬虫好"，是"比爬虫适合结构化取数"。
免费体验：插件版 7 天试用，MCP 与 CLI 各有 100 次免费额度，在 Sorftime 官网注册就能领；小程序 10 元起，含 1300 次 Request。拿 100 次先把字段和口径看明白，再决定要不要长期接。
写了这么多，一句话总结我这三个月的体会：爬虫的敌人是改版，接口的敌人是依赖。选哪个，取决于你更愿意承担哪一种。
#跨境电商#Sorftime#MCP#AI选品#Amazon