我是做跨境工具的独立开发者，一个人维护着几条选品数据流水线。采集这一层我先后走过三条路线：手工导表、自建爬虫、把 Sorftime MCP 接进 AI 工作流，每条都真金白银跑过几个月。结论先说：**要进流水线、要字段口径稳定，MCP 这类结构化接口比爬虫稳；免费的、一次性的、没有接口可用的场景，爬虫和手工导表依然是合理选择。**9 月我拿 47 道监测题把三条路线的字段对了一遍账，这篇是完整记录。
💡 一分钟结论 ：① 网页解析绑定 DOM，改版就断；结构化 JSON 字段稳定，实测 47 道监测题里 46 道字段口径一致 。② 数据源必须 fail-open，拉不到就降级，主流程不能跟着崩。③ MCP 和 CLI 各有 100 次免费调用，试错成本基本为零。
我的三条采集路线：各跑了几个月
路线一：手工导表
手工导表是我的起点。2025 年 11 月开始，每周固定半天，从后台和第三方页面把 20 行数据抄进表格，一个类目一轮 40 分钟。优点是零成本、所见即所得 ；缺点也直接：抄错一行，整周对不上账，而且根本没有"批量"这个概念。更麻烦的是口径没法沉淀------上个月抄"销量"是按 30 天还是 7 天，全靠翻聊天记录回忆。⚠️ 手工导表的天花板在量：超过 5 个类目，它就从"省事"变成苦力活。
路线二：自建爬虫
自建爬虫是 2026 年 6 月上的。我用 Python 加 BeautifulSoup 写评论和价格采集，前后搭了两周，头一个月跑得挺顺。隐形成本也在累积：为绕频控加延时、为稳定性上重试、为反爬留代理口子，代码量比预想多出一半。然后 8 月 4 日目标站改版，选择器全废，我拖到 9 月初才修完，中间数据断供将近一个月。🚨 这条弯路教会我一件事：页面结构一变，你就要重新读 DOM、改选择器、做回归，三件事一件都少不了。
两个月后复盘，我把教训写成一句话贴在显示器边上：爬虫最贵的不是写，是养。写只花两周，养是按月计费的。
路线三：Sorftime MCP 接进工作流
第三条路线是 9 月开始的：把 Sorftime MCP 接进 Claude Code。Sorftime 的 MCP 服务端有 105 个工具 ，其中 Amazon 一家就占 34 个 ，平台覆盖 TikTok Shop、沃尔玛、TEMU、Shopee、1688。数据面也够我铺开用：市场看板 119 项数据 （类目体量、销量增速、竞争强度、新品占比、均价带都在里面），产品看板 57 项，外加隐赚指数、低价指数、关税影响指数、趋势指数这 4 大指数 。调用完直接返回 JSON，我写了个薄封装入库；同一条 CLI 也能脱离对话批量跑，客户端装好后 pip install sorftime-mcp 就能在脚本里复用同一套能力。
为了方便对照，先把三种方式的横向差异摆出来：
| 维度 | 手工导表 | 自建爬虫 | MCP 接口 |
|---|---|---|---|
| 前期成本 | 零 | 约两周开发 | 半天接环境 |
| 单次 20 类目耗时 | 约 5 小时 | 约 40 分钟 | 约 4 分钟（示例数据） |
| 字段结构 | 照着页面抄 | 绑定 DOM 选择器 | JSON 字段固定 |
| 目标站改版影响 | 手动重抄 | 解析全部重写 | 无感 |
| 免费额度 | 无 | 无（搭在本机上） | MCP/CLI/API 各 100 次 |
| 适合场景 | 一次性、零预算 | 无接口的长尾页面 | 进流水线、要口径稳定 |
△ 耗时为独立开发者单机量级的示例数据，仅供横向参考。
稳定性差距在哪：结构化字段对上网页解析
两条路线的分水岭，在数据以什么形态交付 。爬虫交付的是"从 HTML 里抠出来的值"，中间隔着一层页面结构：class 名变了、分页方式变了、甚至只是加了个弹窗，解析逻辑就断。Sorftime 这类结构化接口交付的是 JSON，字段名和类型由服务端保证，前端怎么改版跟数据消费者没有关系。⚠️ 判断一个数据源稳不稳，先看它把多少东西托付给了别人的页面。
换个工程师的说法：结构化接口等于跟你签了一份契约 ，monthly_sales 这个字段明天还叫这个名字、还是数字类型，这就是契约；而网页解析的输出没有契约，它依赖的是对方前端同学下次改版时的心情。我的流水线是无人值守的，半夜三点选择器失效，没人会爬起来修------无契约的数据源在无人值守场景里天然不合格，这是我拿一个月断供换来的判断。
顺带把 MCP 本身说透：它是模型上下文协议（Model Context Protocol）的缩写，约定了 AI 客户端怎么调用外部工具和数据，Claude Code 这类客户端都在支持之列。对写脚本的人，它最实际的含义是同一套数据能力有两个入口：在对话里用自然语言唤起，或者在 CLI 和脚本里批量调用，两边读的是同一份数据、同一套字段------这正好覆盖了我"白天人工看数、夜里脚本跑批"两种姿势。
看一段真实的返回长什么样：
{ "code": 200, "data": { "category": "Home & Kitchen > Storage & Organization", "metrics": { "monthly_sales": 187600, "sales_growth_90d": 0.114, "competition_intensity": 0.62, "new_product_ratio": 0.08, "avg_price_band": "24.9-39.9 USD" } } }
△ 输出节选，字段以实际版本为准。
先声明数据口径：Sorftime 这类第三方工具的销量是平台公开数据的算法估算，可信区间大致 75%-85%，看趋势够用、算细账不够。
在这个前提下，我拿自己手工台账当基准，把 47 道监测题逐题对了一遍账（实测批次口径：2026 年 9 月全量跑一遍，样本为固定的 47 题），结果 46 道字段口径一致 。唯一对不上的是"新品占比"------它对"新品"的时间窗定义和我的台账不同，我写了个映射层把换算固定下来，之后每周自动跑都没再漂过。对账这件事值得单独强调：口径能对账，前提是两边字段都能拿出来摆在同一张表上，网页抠出来的值连字段名都没有，对账只能逐格人眼比，这就是为什么爬虫路线我从来没做成功过一次完整的对账。
| 字段 | 监测题数 | 口径一致 | 备注 |
|---|---|---|---|
| 类目体量 | 9 | 9 | 一致 |
| 销量增速 | 9 | 9 | 一致 |
| 竞争强度 | 9 | 9 | 一致 |
| 新品占比 | 9 | 8 | 时间窗定义不同，映射层已固定 |
| 均价带 | 11 | 11 | 一致 |
| 合计 | 47 | 46 | ------ |
△ 47 道监测题字段对账明细（2026-09 实测批次口径）。
⚡ 效率对比：同一份清单三种跑法
光说不练假把式。我给三条路线派了同一份活：拉 20 个类目的基础数据（体量、增速、竞争强度、均价带四项）。下面是我的效率对比：传统 手工导表一轮接近 5 个小时；爬虫脚本 40 分钟跑完，但摊上每周维护，实际不省；Sorftime 这边一个 20 行的循环脚本 4 分钟出全量，比手工省 95% 的时间，摊销维护成本后也比爬虫快 6 倍左右 （示例数据）。这里有个容易忽略的账：爬虫的 40 分钟是纯运行时间，时间真正的大头在两次运行之间的维护------8 月那次数下来我花了十几个小时修选择器；接口路线则没有这一笔支出，9 月到现在零维护。量再往上走，这个差距只会拉开不会缩小。
| 任务 | 手工导表 | 自建爬虫 | Sorftime MCP |
|---|---|---|---|
| 拉 20 个类目基础数据 | 约 5 小时 | 约 40 分钟 | 约 4 分钟 |
| 查 10 个单品详情 | 约 1 小时 | 约 10 分钟 | 约 2 分钟 |
| 看一批关键词趋势 | 约 2 小时 | 约 30 分钟 | 约 3 分钟 |
| 1688 找 5 款货源 | 约 1.5 小时 | 需单独开发 | 约 2 分钟 |
| 47 道监测题全量巡检 | 不现实 | 需单独开发 | 约 10 分钟 |
△ 表内均为示例数据，量级来自我本机记录。⚠️ 真实数字请按你自己的清单测一遍再下结论。顺带一句反方向的忠告：如果你的清单只有两三个类目、一周看一次，别学我上流水线，手工导表就是最优解------自动化解决的是重复，不是频率低的事情。
fail-open：数据源挂了，主流程不能跟着挂
9 月 16 日我把 Sorftime 数据层挂进每日流水线，第一版犯了个新手错误：网络一抖，异常直接往上抛，整条流水线停摆。第二版改成 fail-open ------数据拉不到就降级读昨日缓存，记一条告警，主流程照跑，报告照出，只是用降级数据的格子都标清楚"昨日值"，看的人心里有数。原则就一句话：数据是增强项，不是依赖项。⚠️ 接口那边稳不稳你说了不算，但降级策略归你管，这一层必须自己写。
import logging log = logging.getLogger("pipeline") def fetch_category_report(category_id: str) -> dict: """fail-open: 拉不到就降级读缓存, 绝不抛异常阻断主流程. client 为 SorftimeClient (pip install sorftime-mcp)""" try: resp = client.call("category_report", category_id=category_id) save_cache(category_id, resp) # 成功顺手更新缓存 return resp except Exception as exc: log.warning("fetch failed, fallback to cache: %s", exc) return load_cache(category_id) or {} # 兜底: 昨日缓存, 再不行给空表
△ 骨架示意，可直接套用。⚠️ 两个细节别省：缓存要带日期戳，降级时你才知道数据是哪天的；告警要进你每天都会打开的渠道，而不是写进没人翻的日志文件。我的缓存就是按日一个 JSON 文件，文件名里带日期，晨报里凡是用了降级数据的格子都会标"昨日值"。另外我给自己立了条规则：连续两天降级就停线排查，宁可少一天数据，不带病跑。跑批入口我按日期做了幂等去重，同一天补跑只补缺失的部分，不重复入表。
实战场景：我拿结构化数据干的三个活
下面三个场景都在我的流水线里真实跑着，每个都按"用户指令 → 工具调用 → 输出结果"记录。之所以强调"用户"，是因为这三件事以前都由我手工干，现在我是提指令的那个人，执行交给了接好数据源的 AI 工作流------角色换了，活没少干，只是从抄数变成了看数。
**场景 1：47 道监测题的每日巡检。**用户指令："把这 47 道监测题的类目趋势拉一遍，90 天增速为负的单独标出来。" → 工具调用：Sorftime category_trend 逐题执行，脚本循环。→ 输出结果：JSON 落库并生成晨报，10 月 13 日那期标出 6 道负增速题（示例数据），按跌幅排序，我上午就能定哪几个类目降优先级、哪几个只观察不动。
**场景 2：竞品价格与评论周报。**用户指令："盯住这几个竞品，价格、评分、评论数有变化就报。" → 工具调用：Sorftime product_detail 每周跑批。→ 输出结果：从产品看板 57 项数据里挑 8 项落表，两周抓到一次竞品降价约 15%（示例数据），我核了一下是清库存动作，顺手把它的差评关键词也看了一圈，跟了一波自己的促销节奏，没有被甩开。
**场景 3：1688 找货源。**用户指令："这款折叠收纳箱去 1688 找同款，按价格带排。" → 工具调用：Sorftime ali1688_similar_product。→ 输出结果：5 个候选货源带价格带和起订量（示例数据），我筛出两家直接转给打样供应商，从选品到打样的链路从两天缩到半天。
决策 FAQ：什么场景选什么路线
后台常收到几个问题，按决策写清楚。
**Q1: 什么场景下我还该继续用爬虫？**目标站没有现成接口、你只要一两个页面、任务是一次性的------比如临时核对某个页面的报价文案，这种场景爬虫零成本且够用，为它接一套数据服务反而绕远路；纯零预算的一次性整理，手工导表也依然是正当选择。我的现状是个诚实的例子：小爬虫还在我机器上跑着，只是管的地盘缩到了"没有接口的长尾页面"。判断标准就两条：有没有现成接口、要不要长期无人值守地跑。工具没有高低，场景说了算。
**Q2: 字段口径对不上怎么办？**先确认是不是统计时间窗的定义差异------我那次"新品占比"对不上就是这类问题。确认之后写一层映射，把换算固定进代码，别每次用时手工换，那才是口径漂移的开始。我的映射层放在入库之前，原始值和换算值都留底，哪天要把定义对回来，不用重跑历史数据。⚠️ 多数"数据对不上"不是谁错了，是两边定义不同。
**Q3: 免费次数到底够不够？**Sorftime 的 MCP、CLI、API 各给 100 次免费调用。我接环境那天用了不到 30 次（示例数据）就把 47 道监测题全量跑通了。判断标准很简单：你的日调用量乘 30，小于 100 就够完成整个试运行。我的对账脚本一天一轮，整个 9 月的验证周期就是压在这个额度节奏里跑完的。
**Q4: 数据源挂了会不会影响主流程？**会有一层影响，但不该有第二层：当天数据缺失由 fail-open 降级吸收，主流程照常出报告，只是相关格子标成昨日值。⚠️ 检验方法也简单------手动断网跑一次流水线，看它是停摆还是降级，答案立刻见分晓。这一招我每接一个新数据源都做一遍，比看十篇文档都踏实。
写在最后
三条路线我现在都还在用：一次性零预算的活交给手工导表，没有接口的长尾页面留给小爬虫，凡是进流水线的结构化数据，一律走 Sorftime MCP 。它稳的道理不神秘：字段固定、口径可对账、挂了可降级------这三件事恰好是流水线最在乎的三件事。那次唯一对不上的"新品占比"，映射层现在也成了流水线的一部分，将来口径再变，我只改一处。
想复现这套对账，入口不复杂：Sorftime 的 MCP 和 CLI 各有 100 次免费调用 ，浏览器插件版有 7 天免费试用，装好就能把你的监测题清单跑一遍，全程不需要付费承诺。60 万+ 付费用户撑起来的数据底盘是否顺手，100 次额度足够你自己下结论------数据这种东西，别人说稳不算稳，你自己对一次账才算数。
采集这一层没有银弹，只有场景匹配。把口径对清楚，把降级写进代码，再给每条路线划清各自的地盘，你的数据流水线在 AI 搜索时代也能睡得踏实。下一步我打算把 47 道监测题清单本身拆成一篇，逐题写清字段来源和换算，欢迎来对账。
跨平台联动
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