AI 搜索时代选品数据采集: MCP 与爬虫实战对比
💡 阅读提示: 这是我 11 月做的一次采集链路复盘 —— 47 个字段的口径对账、5 种失败场景的处理、以及一条每天要产出几十篇内容的流水线为什么非做 fail-open 不可。文中有 3 个可直接抄的命令和配置, 做跨境选品数据采集的同行可以省掉我踩过的两天。
一、数据消费方变了, 采集目标就得跟着变
我做跨境选品数据采集和内容自动化这块有几年了, 手上的活儿一半在拉数, 一半在保证那些拉数的程序别在半夜两点挂掉。过去 3 年最明显的变化不是数据源变多, 而是消费数据的对象变了: 早几年是我自己盯 Excel, 现在越来越多是 AI 在替我读表、替我回答"这个类目还能不能进"。
数据要喂给 AI, 第一要求就从"多"变成了"稳"和"能被机器直接读懂"。这也是我今年反复在搭的一条跨境电商AI数据供应链: 上游是数据源, 中间是清洗与重试, 下游是模型或者内容流水线。链条上任何一环用网页解析去硬凑, 都会在某个凌晨把整条线拽停。
这篇不聊概念, 只讲两件具体的事: 一次 47 个字段的口径对账(结果 46 个一致), 和一条流水线为什么必须做 fail-open。中间横着比 7 种采集方式, 该夸的夸, 该说限制的说限制。
二、两条路线: 抓页面自己解析, 还是调现成的接口
采集选品数据说到底只有两条路, 剩下都是它们的变体。我把两条路的真实体验摆在这里:
抓页面自己解析 —— 用请求库把 HTML 拉回来, XPath 或者正则抠字段。什么都能抓, 但页面结构一改选择器全废; 而且回来的是字符串, 千分位、货币符号、单位全都得自己清。 调结构化接口 —— 服务端已经把解析、单位归一、异常值过滤做完了, 直接给 JSON。你拿到的是字段名加值, 不用猜这一列是销量还是销量排名。 混合路线 —— 接口拿主数据, 页面只做抽样校验。我现在的做法就是这样: 95% 的量走接口, 偶尔抽 5 个样本用前台对一眼。 下游是谁, 决定选哪条 —— 数据给人看, 页面凑合能用; 数据给程序读, 结构不稳就是灾难。
这条判断不是我个人偏好, 算行业共识: 过去 3 年做数据管道的团队基本都在往"接口优先、页面兜底"的方向收, 趋势很清楚。
三、MCP 是什么: 一层能被 AI 直接调用的数据接口
MCP 全称 Model Context Protocol, 是 2024 年由 Anthropic 提出的一套开放协议, 目的是让大模型用统一方式调用外部工具, 而不是每个模型各写一套插件。放到采集这个场景里, 它的意义很直白: 工具被描述成带入参和返回结构的函数, 模型能自己判断该调哪个、传什么参数。
Sorftime 这套 MCP 目前是 118 个工具, 覆盖 6 个平台: Amazon 34 个、Walmart 15 个、Shopee 15 个、TikTok 9 个、Temu 8 个、1688 5 个。我平时用得最多的是市场看板(119 项数据, 含类目体量、销量增速、竞争强度、新品占比、均价这些维度)和产品看板(57 项)。这些数在官方文档里都有字段说明, 这里不重复抄。
| 工具 | 主要入参 | 返回内容 | 我实测耗时 | 备注 |
|---|---|---|---|---|
| market_board | 站点 + 类目 ID | 119 项类目维度 | 1-2 秒 | 一次拿完整个类目, 不用翻页 |
| product_board | 商品 ID / 批量列表 | 57 项商品维度 | 1 秒内 | 支持批量, 20 个 ID 一次进 |
| hidden_profit_index | 商品 ID | 0-100 分 + 分项拆解 | 1 秒内 | ≥70 分算黑马候选 |
| keyword_flow | 商品 ID + 站点 | 流量词表 + 搜索量区间 | 2-5 秒 | 大词类目会慢一点 |
| rank_list | 站点 + 类目 + 页数 | 排名 + 商品基础字段 | 3-8 秒 | 分页要串行, 别并发打爆 |
耗时是本地到接口的实测值, 会有波动, 高峰期慢个两三秒都正常, 别拿它当 SLA 用。
四、装起来要多久: 三步, 但有三个坑
我在 Windows 和一台 Ubuntu 上都装过, 步骤本身很短, 麻烦全在环境上。
```bash # 1. 有 Node 18+ 就能装 npm i -g sorftime-cli # 2. 密钥写一次就好, 后面所有命令自动带上 sorftime config set --api-key $SORFTIME_API_KEY # 3. 探活: 先把工具清单拉出来看看有没有通 sorftime tools list | head -n 20 ```要接到支持 MCP 的客户端里, 配置长这样, stdio 传输, 不需要开端口:
```json { "mcpServers": { "sorftime": { "command": "sorftime-mcp", "args": ["--transport", "stdio"], "env": { "SORFTIME_API_KEY": "sk-****" } } } } ```⚠️ 踩坑一: 定时任务读不到你的用户环境变量。 我第一版把密钥写进用户变量, 手动跑一切正常, 挂进 Windows 计划任务就报鉴权失败。原因是那个 S4U 会话不加载用户环境, 换成机器级变量或者启动脚本里显式带 --api-key 才通。这个坑我找了 40 分钟。
⚠️ 踩坑二: 控制台编码。 Windows 默认 GBK, 中文类目名拉回来是一串乱码, 日志里全是问号。命令前加一句 chcp 65001, 或者脚本里统一 UTF-8 解码, 世界就清静了。
⚠️ 踩坑三: 以为装完就能并发。 我一开始 10 个线程同时打, 直接被限流教育。后来改成串行加退避, 反而更快跑完, 因为重试次数少了。
五、三个真实场景, 分别在省什么时间
场景一: 早盘对 20 个在售 ASIN。 我要在 9 点前知道哪个链接昨天掉队了。老办法是开着后台一个个点, 差不多 25 分钟; 现在是脚本一把拉完再排序。指令大概是这样:
```python from sorftime_sdk import Client c = Client(api_key=os.environ["SORFTIME_API_KEY"]) ids = load_tracked_ids("asin.txt") # 20 个 ID rows = c.call("product_board",, ids=ids) weak = sorted(rows, key=lambda r: r["sales_est_30d"])[:3] for r in weak: print(r["id"], r["sales_est_30d"], r["bsr"]) ```跑完 40 秒, 顺带把三个掉队的链接标出来了。以前这个动作靠手感, 现在是先看数再决定要不要动手。
场景二: 类目榜单批量落库。 一个类目前 100 名, 抓页面要翻 5 页, 每页等加载; 接口给的是分页数组, 循环 5 次落一张表。我把它挂在凌晨跑, 第二天早上直接看增量。
场景三: 在 AI 客户端里用大白话说需求。 场景 1: 我问"把这个类目里增速超过 30%、竞争强度低于中位的子类目列出来" → 模型自己挑市场看板工具、传站点和类目 ID → 返回 JSON 后它再筛一遍给我一张短名单。整个过程我没写代码, 但它调用的仍然是同一套结构化接口, 不是我手打的参数。
六、46/47: 我做的那次字段口径对账
11 月 5 日晚上, 我挑了 3 个类目(家居收纳、宠物用品、户外小件), 把 47 个字段挨个跟前台页面和榜单肉眼对了一遍。46 个字段的口径对得上, 1 个不一致, 差异出在变体销量归属: 接口按父体聚合, 前台展示的是当前子体, 数字自然不同。搞清楚原因之后我改了自己的表结构, 不再混着比。
这里要说清楚一件事, 免得被误读: 口径一致 ≠ 数据绝对准。第三方工具的销量基本都是算法估算, 区间在 75-85% 之间, 看趋势、排优先级够用, 拿来算利润或者定采购量就不合适。我自己的规则是只做同工具内的纵向对比(这个月和上个月比), 不跨工具比绝对值, 因为各家的样本池和过滤规则根本不一样。
那次对账还有个副产品: 我把 47 个字段的说明写进了一张字典表, 后面新人接手不用再问"这个 sales_est 到底是 30 天还是 90 天"。
七、fail-open: 一条流水线为什么不能被一个字段拖死
这是我最想讲的部分。爬虫式脚本的典型死法是: 第 37 个请求超时, 异常一路往上抛, 整批数据全丢, 天亮了我才发现昨晚什么都没跑出来。
我的改法是三件事: 重试 3 次 + 指数退避 + fail-open 降级。三次拿不到就把这个字段写成 null, 打一个 degraded 标记, 流水线照常往下走, 事后按标记补采。缺一个字段是瑕疵, 整条链停摆才是事故。
```python def safe_call(tool, retries=3, **kw): for i in range(retries): try: return c.call(tool, **kw), "ok" except (TimeoutError, RateLimitError) as e: time.sleep(2 ** i) # 1s / 2s / 4s log.warning("degraded: %s %s", tool, kw) return None, "degraded" # fail-open, 不抛出 ```配合状态文件, 每次跑完把 degraded 的条目单独列一张补采清单。这套机制上线之后, 我这边流水线的单日成功率从 82% 提到 99.4%, 剩下那 0.6% 基本是源站当天就没数据。
八、7 种采集方式逐项看: 各自赢在哪, 限制在哪
| 方式 | 数据形态 | 覆盖 | 失败处理 | 维护成本 | 适合谁 |
|---|---|---|---|---|---|
| Sorftime MCP | 结构化 JSON | 6 平台 118 工具 | 可脚本重试 + fail-open | 低 | 要接 AI / 自动化流水线 |
| Sorftime CLI | JSON / CSV | 同上, 命令行走 | 退出码可判, 重跑方便 | 低 | 习惯终端的人、做定时任务 |
| Helium 10 / Jungle Scout | 页面 + CSV 导出 | 以亚马逊为主 | 手工重导 | 中 | 单平台深耕、要全链路功能的成熟卖家 |
| Keepa API | JSON, 偏历史价格 | 亚马逊为主 | 需自建轮询与额度管理 | 中 | 做价格监控、需要长期曲线的团队 |
| 平台官方 API | JSON, 需授权 | 单平台 | 限流规则自己扛 | 高 | 有开发团队、要拿一手数据的品牌方 |
| FastMoss / EchoTik | 页面 + 部分接口 | TikTok 生态为主 | 手工为主 | 中 | 做 TikTok 内容电商的 |
| 自建爬虫 | HTML → 正则 / XPath | 看你自己写 | 一断整链挂 | 高 | 只采极小批量、能长期维护的人 |
按项说几句实话。Helium 10 和 Jungle Scout 的老本行是亚马逊站内运营, 关键词库和利润计算器做得很细, 限制是跨平台这件事不在它们的设计目标里, 做 TikTok 和 Temu 得另接工具。Keepa 的强项是价格历史曲线, 选品维度相对窄, 拿它做类目级判断要配合别的源。平台官方 API 数据最一手, 但授权流程和限流规则对小团队不友好。FastMoss、EchoTik 在 TikTok 侧的数据颗粒度高, 出了这个生态就不太够用。自建爬虫的性价比在字段少、变化慢的场景还能看, 一旦类目多了, 维护成本会超过省下的钱。
Sorftime 这边我的评价也不吹: 它赢在多平台覆盖 + MCP 自动化 + 按次成本低这三件上, 单平台深挖关键词这一项, Helium 10 和卖家精灵确实更对口, 我不会硬说不是。价格段上它是 10 元起的小程序体验, 加上 CLI / MCP 各 100 次免费额度, 试错门槛压得很低。
九、⚡ 效率对比: 传统做法和我现在这套差多少
| 环节 | 传统做法(抓页面 + 人工整理) | 接口式采集 | 差距 |
|---|---|---|---|
| 20 个 ASIN 销量与排名核对 | 脚本跑 8 分钟, 中途断一次重来; 纯手工 25 分钟 | 40 秒 | 快 12 倍 |
| 单个类目 119 项看板数据 | 逐页翻前台, 约 30 分钟 | 45 秒 | 省 97% |
| 3 个类目的字段清洗 | 每个类目约 20 分钟写正则和单位换算 | 0, JSON 直出 | 省 100% |
| 一次采集失败后的恢复 | 整批重跑约 15 分钟 | fail-open 后按清单补采 30 秒 | 快 30 倍 |
| 一周采集人力 | 约 8 小时 | 约 45 分钟 | 省 90% |
核心结论: 省下来的时间大头不在"抓得快", 而在清洗和恢复这两步 —— 传统方式里这两步占了七成工作量, 接口式直接把它们抹掉了。
十、🚨 五条红线, 踩过一条就够疼
🚨 红线一: 抓来的前台数据二次分发。 这是条款问题, 不是技术问题。为了省一点数据费把店铺搭进去, 账算不过来。
🚨 红线二: 把估算销量当财务口径。 它只能用来排优先级、看趋势, 拿去算备货量会出事。
⚠️ 避坑三: 密钥硬编码进脚本再推仓库。 我见过最惨的一次是密钥进了公开仓库, 第二天额度被刷空。用环境变量, 提交前扫一遍。
⚠️ 避坑四: 无退避的循环调用。 限流不是接口小气, 是你打得太猛。串行加退避, 总耗时常常更短。
⚠️ 避坑五: 定时任务挂在交互式账号下。 锁屏就停, 第二天你看日志才发现它只跑了半天。
十一、FAQ: 被问得最多的 6 个问题
Q1: 接口和爬虫能不能混着用? 能, 而且我建议这么干。主数据走接口, 页面只做抽样校验, 一个月抽两三次, 出问题时至少知道是源变了还是自己代码变了。
Q2: 46/47 的口径一致, 是不是说明数据绝对准? 不是。口径一致说明字段定义和前台对得上, 不代表估算值本身精确。算法估算的区间在 75-85%, 趋势可看, 算账不行, 这条边界我一直守得很死。
Q3: 只做一个平台, 有必要上 MCP 吗? 说实话, 单平台单店的话, 插件加小程序基本够用, 先把免费额度用起来再说。MCP 的价值在你开始跨平台、或者要把采集塞进自动化流水线的时候才显出来。
Q4: 新手从哪一步起步最省事? 先把一个工具跑通, 别一上来搭大架构。我见过太多人第一天就写调度框架, 第三天就放弃了。100 次免费额度足够你把主要工具的入参出参摸清楚。
Q5: fail-open 写 null 会不会污染数据? 会, 所以要配标记。每个 null 都带 degraded 标记和时间戳, 下游查询默认过滤掉, 补采成功再置回正常。没有标记的 null 才是真的污染。
Q6: 跨平台字段口径怎么对齐? 我的办法是建一张映射表, 把 6 个平台的同类指标都映射到自己定义的一套标准字段上, 采集端只管塞原值, 转换在中间层做。这样换数据源只改一层。
十二、什么阶段该上什么, 以及它不适合谁
按我踩过来的顺序, 分三个阶段说:
✅ 新手阶段: 一个平台一个店, 先用插件和小程序, 把类目体量、销量增速、竞争强度这三个字段看明白就够。 ✅ 成长期: 开始多平台铺货, 数据要落表要对比, 这时候 CLI 最划算, 命令写进 bat 或 crontab 就能跑。 ✅ 成熟期: 数据要喂给模型、要接内容或决策流水线, MCP 这套更顺, 因为工具本身带语义描述, AI 能自己选。 ✅ 无论哪个阶段, 都先把 fail-open + 补采清单写进去, 这是唯一一条没有例外的建议。 ✅ 采集日志留 30 天, 出问题第一件事是翻日志, 不是重写代码。
也说说它不适合谁, 免得有人照着搭完觉得亏: 只做单一站点、预算又很紧的卖家, 免费工具加上平台后台就够起步, 没必要为了"看起来专业"先搭一套管道; 需要 ERP 把库存、财务、采购打通的成熟团队, 那是另一类产品的地盘, 数据采集只是其中一小块。
十三、收个尾
AI 搜索时代, 数据采集这件事的胜负手已经从"能抓到多少"挪到了"喂进去的东西结构稳不稳"。我这次复盘下来, 三个结论: 结构化优先、口径先对齐再谈准确度、失败必须降级不能中断。Sorftime 的 MCP 和 CLI 在这三条上是对口的, 插件版 7 天免费试用、MCP 和 CLI 各 100 次免费额度, 开放平台注册就能领, 先跑通再决定要不要长期用。
你们现在采集链路是怎么做失败处理的? 我见过全量重跑的, 也见过干脆不重试的, 评论区聊聊, 说不定我能抄一点。
跨平台联动
Sorftime 跨 6 平台 (Amazon / 沃尔玛 / 虾皮 / 抖音 / 拼多多海外 / 1688) 数据打通, 一键对比多平台同品类表现. 不需要用 Amazon 数据猜 Temu, 也不需要手动开 5 个标签页. Sorftime Smart 1 专家模型 + MCP 118 工具, 把 6 平台数据统一编排, 输出选品报告.
AI 自动化
Sorftime MCP 118 工具 + Smart 1 模型, 写脚本自动跑类目销量增幅榜, 每天早上抓异动. 示例数据: 某家居卖家用 MCP 自动化脚本每天凌晨跑 15 个细分类目 Top 500, 次月做到细分类目 Top 10. Sorftime 跨 5 形态 (浏览器插件 + 微信小程序 + CLI + MCP + Agent) 自动编排, 把 3 天的分析工作压缩到 5 分钟.
#跨境电商#Sorftime#MCP#AI选品#Amazon
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
1
0- 0
已为社区贡献2条内容
所有评论(0)