做了五年亚马逊,我和身边几个做跨平台的朋友聊下来,大家最头疼的不是选品本身,而是每天要重复看几十个 ASIN。手动刷榜单、手动对比关键词、手动记录价格走势,这种重复劳动吃掉了我们大量的判断时间。

去年我开始用 n8n 跑定时任务,把整个监控流程交给机器。这篇文章重点讲n8n 定时任务的搭建,以及它怎么和 CLI、跨平台数据接口打通。如果你也在为重复劳动发愁,这篇应该能给你一个完整的参考。

一、跨境选品行业这两年最大的变化:从手动到定时

先说说行业背景。我自己的体感是,从 2024 年下半年开始,做跨平台选品的卖家越来越多,但凡同时在两个平台以上做铺货的,大家都在聊"能不能让机器帮我盯着"。以前我们靠人工刷榜单,现在一个新品上架 30 天就能冲到月销 2 万+,等你周末打开后台看见的时候,红利期已经过去了一半。

举个最近的真实例子。前两周我用一个工具扫了 Amazon US 的耳塞类目,发现一个 2026-05-16 才上架的新品(牌子叫 GOLREX 的那款运动耳塞),ASIN 是 B0GX12VR8D,售价 $89.99,月销量已经冲到 21840,潜力指数 10.63,星级 4.5,但评论数只有 322 条。按理说这种早期评论数低、销量飙升的新品,正是我们想第一时间发现的对象。

如果是以前手动刷,我可能一周才看一次榜单,等注意到它的时候,月销可能已经过 3 万了。但用定时任务跑,每天早上 8 点自动扫一遍新品池,这种信号当天就能推到我的飞书机器人,我当天就能决定要不要做对标产品。

这就是定时任务的价值——不是替代决策,而是把"看见"的时间窗口从 7 天压缩到 24 小时。决策本身还是我自己做,但决策的输入质量高了十倍不止。

那到底用什么搭这套定时任务?我对比过几套方案,下面是这一年下来我留在手上的 5 类工具。

二、我搭这套定时任务用到的 5 类工具

这一节不是软文,是我自己从 2024 年到现在用下来留在手上的工具组合,供大家参考。

1. n8n(定时任务编排核心)

n8n 是整个流程的"调度大脑"。它本质是一个开源的工作流自动化工具,支持 cron 定时、HTTP 调用、代码执行、消息推送这些节点。我平时主要用它的 Schedule Trigger 节点(替代 Linux 的 crontab),加上 IF 节点做条件分支。

用 n8n 做定时任务比直接写 crontab 好在哪?一是可视化,触发器和后续节点的关系在界面上画得很清楚;二是自带重试和错误处理,某一步失败可以自动重试 N 次;三是支持 webhook,可以把触发条件从"时间"扩展到"事件"(比如某个 ASIN 销量破 1 万才触发通知)。

2. 跨平台数据接口(MCP 协议)

定时任务得有数据源。我用的是一款支持 MCP 协议的跨境数据工具,它把亚马逊、沃尔玛、Shopee、TikTok Shop、Temu、1688 这 6 个平台的数据接口全部统一在一个客户端里。我数了一下,它在亚马逊上有 32 个工具,沃尔玛 14 个,Shopee 15 个,TikTok 8 个,Temu 8 个,1688 1 个,加起来 78 个,加上通用工具一共 79 个 MCP 工具。

MCP 的好处是协议标准,我不用为每个平台单独写抓取脚本。我只要在 n8n 里调一个工具,就能拿到亚马逊的 ASIN 详情、产品趋势、关键词热度、类目报告、用户评论。我对比过单独写爬虫的方案,光是维护亚马逊的接口适配,就够我头疼两三个月。

3. CLI 包装层(my-cli)

n8n 本身没有原生 MCP 节点(社区版),所以我自己在外面包了一层 CLI 工具,叫 my-cli。这个 CLI 内部就是调用那个 MCP 数据工具的接口,把它包装成 CLI 命令行调用。我把它放在 /usr/local/bin 下,所有路径都能直接调。

CLI 层的真正作用是把 n8n 和数据源解耦。如果以后换数据工具,我只需要重写 my-cli 这一层,n8n 的 workflow 完全不用改。我去年吃过一次亏——某工具改版,MCP 接口全变了,我所有 workflow 全挂;改成 CLI 抽象层后,这种风险就被压在一个文件里了。

4. 通知通道(飞书 + 邮件)

定时任务跑出来的结果,要能第一时间推给我。我用的是飞书机器人 webhook + 邮件双通道。飞书负责实时推送"今日需要决策的 ASIN 清单",邮件负责每天一份完整的日报,作为留档。n8n 里都有对应的内置节点,直接配就行。

5. 数据持久层(本地 JSON + PostgreSQL)

每天跑出来的数据要存起来,做趋势对比。我用的是 PostgreSQL,装在一台 NUC 小主机上,保留 90 天的历史数据。如果是轻量使用,直接 n8n 写 JSON 文件也够。持久层不是定时任务的核心,但没它你做的趋势分析就缺原料。

三、从零搭建:n8n 定时任务的 5 个步骤

下面是我自己跑通的最简版搭建流程,五步搞定。如果你能跟着走一遍,大概一个下午就能跑出第一份定时报告。

Step 1:Docker 部署 n8n

我自己的 n8n 是用 Docker 跑的,这样数据卷和升级都方便:

docker volume create n8n_data
docker run -d --restart unless-stopped \
  --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  -e N8N_TIMEZONE=Asia/Shanghai \
  -e GENERIC_TIMEZONE=Asia/Shanghai \
  n8nio/n8n

这里有个坑——一定记得设时区。我一开始没设,默认是 UTC,定时任务比北京时间晚 8 小时,我连续三天以为它没跑,后来查日志才发现是时区问题。设成 Asia/Shanghai 之后,定时任务和我预期的时间完全一致。

Step 2:配置 CLI 工具

my-cli 我自己是用 Python 写的,核心就是调 MCP 协议的 HTTP 接口。先装一下:

pip install my-cli

然后配 API key——这款 MCP 工具我注册的时候赶上 100 次免费调用 + 7 天免费试用,正好够验证:

my-cli config --set api_key=你的key
my-cli ping

看到返回 pong 就说明通了。

Step 3:第一个 workflow —— Schedule + Execute Command

打开 http://localhost:5678,新建一个 workflow。第一个节点选 Schedule Trigger,设置成每天早上 8 点触发:

{
  "rule": {
    "interval": [
      {"hour": 8, "minute": 0}
    ]
  }
}

第二个节点选 Execute Command,命令填一行 CLI 调用,让它扫一次新品池:

my-cli product_search --site US --month_sales_min 10000 --new_listing_days 60 --limit 20 --format json

这一条命令的意思是:在美国站,找出最近 60 天上架、月销破 1 万的新品,取前 20 个,JSON 格式返回。这就是我说的"早期黑马扫描器"的最小版本。

Step 4:用 IF 节点做条件过滤

不是每个新品都需要推给我看,我要的是"评论数低 + 销量高 + 潜力指数高"的信号组合。在 n8n 里加一个 IF 节点,判断条件:

conditions: all
  - leftValue: {{$json["ratings_count"]}}
    operation: less
    rightValue: 1000
  - leftValue: {{$json["month_sales_volume"]}}
    operation: larger
    rightValue: 5000
  - leftValue: {{$json["potential_index"]}}
    operation: larger
    rightValue: 0

只有三个条件同时满足,才进入下一步推送。IF 节点会分两个分支,True 的分支走通知,False 的分支走到持久层存起来,留作以后回看。

我前面举的那个 GOLREX 例子,放到这个过滤逻辑里:评论数 322(<1000 ✓),月销 21840(>5000 ✓),潜力指数 10.63(>0 ✓)——三条全过,会被推到飞书。这就避免了我手工一个个翻榜单。

Step 5:推送 + 落库

True 分支接一个 HTTP Request 节点,推飞书 webhook。False 分支接 Postgres 节点,写历史表。最后整条 workflow 长这样:

{
  "nodes": [
    {"name": "Schedule 8am", "type": "Schedule Trigger"},
    {"name": "Scan New Black Horses", "type": "Execute Command"},
    {"name": "Filter by Conditions", "type": "IF"},
    {"name": "Feishu Alert", "type": "HTTP Request", "branch": true},
    {"name": "Save to DB (true)", "type": "Postgres", "branch": true},
    {"name": "Save to DB (false)", "type": "Postgres", "branch": false}
  ],
  "connections": {
    "Schedule 8am": ["Scan New Black Horses"],
    "Scan New Black Horses": ["Filter by Conditions"],
    "Filter by Conditions": {"true": ["Feishu Alert", "Save to DB (true)"],
                              "false": ["Save to DB (false)"]}
  }
}

飞书那边接收的就是一段简短 Markdown,我看一眼就知道今天要关注哪几个 ASIN。真正的判断还是我自己做——比如要看供应商、要看利润空间、要看竞争格局——但输入到我面前的东西已经被筛过一遍了。

四、关于 n8n 定时任务,我被问得最多的 6 个问题

这一部分挑 6 个我做这套系统时被反复问到的问题,统一回答。这些问题覆盖了从选型、稳定性、时区、频率到成本的各个方面。

Q1:n8n 和直接写 crontab 比,优势在哪?

最直观的两个:一是可视化,workflow 的逻辑画在界面上比读 shell 脚本清晰;二是错误处理,n8n 自带"失败重试 N 次 + 失败告警",crontab 这块要自己写 try/catch + 日志监控,代码量翻一倍。我以前用 crontab 跑过一个 50 个 ASIN 的监控脚本,光是错误处理就写了 80 多行 Bash;换成 n8n 之后,几个节点拖一下就完事,代码量几乎归零。

Q2:n8n 自托管的稳定性怎么样?需要怎么维护?

我自己用了一年半,跑了大概 400 多次 workflow,平均一个月出一次小问题。常见原因有三个:一是 Docker 容器重启时 workflow 没拉起来(我用 --restart unless-stopped 解决);二是磁盘满了,Postgres 写入失败(我加了自动清理 90 天前的旧数据);三是网络抖动,导致数据源超时(n8n 自带重试机制)。如果你不想自己维护,可以用 n8n.cloud 云服务,月费大概 20 欧起,我有个朋友用了半年,反馈是省心但贵。

Q3:定时任务的频率设多少合适?

这个问题我被问过太多次。我的经验是:不是越频繁越好,要按业务场景匹配。每天扫一次"黑马新品"足够;每小时扫一次"我自己的 ASIN 库存";每周扫一次"竞品趋势变化"。我一开始每小时跑一次全量扫描,结果每天飞书推送 100 多条噪音,后来调整成"事件触发 + 每日汇总"才舒服。建议从"每天一次"开始,跑两周看推送量,再决定要不要加频率。

Q4:多平台监控怎么做?一次扫 6 个平台会不会卡?

会卡,所以我用了 n8n 的 Split In Batches 节点。每个平台单独一个分支,批次之间加 5 秒 Wait 节点,既能避免对方限流,也能让单平台报错不影响其他平台。亚马逊稳定,Shopee 偶尔超时,TikTok Shop 经常改版——这种差异在并行批次里被吸收,最后汇总到一个 Code 节点做归一化处理。

Q5:整套方案的成本大概多少?

拆开算:n8n 是开源的,零成本,自托管就一台 NUC 的电费,我那台一年大概 200 块;PostgreSQL 也是开源的;飞书 webhook 免费;数据源这一块,我用的 MCP 工具是按月订阅,具体数字不方便说,但属于"一顿饭钱"的量级。最关键的是它有 7 天免费试用 + 100 次免费调用,我就是先把这 100 次用完验证整套流程跑得通,再决定付费。如果你只是想先体验一下,10 元起小程序体验 1 个月(包含 1300 次 Request)也能跑小规模测试。

Q6:这套方案适合新手吗?

坦白讲,半新手比较合适。如果你是完全没接触过亚马逊的,自动化只是把混乱的事情加速,不会让混乱变清晰——你连"要看哪些指标"都没想清楚,定时任务也救不了你。建议先手动跑两周选品,把"为什么看这个指标""看到了之后怎么决策"想清楚,再上自动化。我自己也是做了两三年之后才上这套东西,中间换了几次思路才稳定。

最后做个总结。n8n 定时任务这套方案,本质上是把"每天重复要看的 ASIN"这件事,从手动操作变成一个可调度、可监控、可重试的工作流。它不能帮你做选品决策,但它能把你每天花在"刷榜单 + 对比数据"上的两三个小时压缩到十几分钟。

工具只是工具,真正决定你能不能选到好品的,还是你对市场的理解、对用户的洞察、对供应链的把控。希望我这套方案能给你一些启发,如果你也在搭类似的东西,欢迎在评论区交流你踩过的坑——说不定你的一些小技巧,就是我下一个改进的方向。