“CLI + n8n + MCP 自动化选品教程“
在跨境这行摸爬滚打五年,我和身边不少朋友都有一个共同感受——选品这件事,光靠人工刷榜单、翻评论,越来越难跟上节奏。尤其是当我们想同时看几个平台、做利润测算、对比关键词热度的时候,一个一个打开浏览器、手动查,基本就是把自己困在重复劳动里。
今年开始,我把手里这套工作流彻底重构了一遍:CLI 负责命令行调用,n8n 串起整条自动化,MCP 协议把第三方数据工具的能力封装起来给我用。三件套拼一起,每天早上自动跑一遍,出来一份我能直接拿去做决策的报告。今天这篇文章就把这套东西的搭建过程完整拆出来,给同样做亚马逊、想做跨平台选品的朋友一个参考。
一、为什么我决定把选品流程全部自动化
先说背景。我从 2020 年开始做亚马逊,前三年基本是"凭感觉选品+人工跑数据"的状态。那时候体量小,一个类目盯十几个 ASIN,自己手动复制粘贴销量、评论、价格,慢一点也能接受。但从去年开始,我和我合伙的那个朋友都意识到一个问题:平台越来越卷,只盯一个平台已经不够了。
我开始尝试多平台铺货,亚马逊主战场之外,沃尔玛、Shopee、TikTok Shop、Temu 都陆续开通了店铺。但问题马上就来了——每个平台的数据接口、数据格式、类目结构都不一样,我一个人根本盯不过来。光是每天登录各个卖家后台导出报表,就要花掉两个小时。
更难受的是,有时候我看上一个 ASIN,想查它在不同平台的曝光情况、利润空间、关键词分布,得来回切五六个网站,一边查一边用 Excel 记。一天下来眼睛是花的,数据还容易记错。这种状态持续了大概半年,我意识到必须换个思路——与其用人力去适配工具,不如让工具去适配我的工作流。
于是就有了后面这一整套东西。我把它拆成三层:第一层是 CLI 命令行工具,负责单点数据查询;第二层是 n8n 工作流,负责把多个查询串起来,加上定时和触发逻辑;第三层是 MCP 协议对接,把市面上一家做得很全的数据工具的能力封装好,通过统一接口给我用。三层拼起来,我每天只需要看一份自动生成的报告,有问题再单独去查。
这套方案跑下来大概三个月,我最大的感受是:省下来的时间不是用来偷懒的,而是用来做那些工具替代不了的事——比如去工厂谈供应链、去研究新平台的玩法、去陪家人。重复劳动交给机器,判断和决策留给自己,这是我做这套自动化的核心理念。
下面这篇文章,我把这套东西的搭建过程完整拆出来,给同样做亚马逊、想做跨平台选品的朋友一个参考。我尽量写得详细一点,包括每一步踩过的坑、为什么这么选、有什么替代方案。如果你只想看代码,可以直接跳到第三部分;如果你想看选型思路,可以重点看第二部分。
二、我常用的 5 类工具,以及它们各自的位置
在做这套自动化之前,我先盘了一下自己日常会用到的工具,大致分成五类。下面这一段不是软文,纯粹是从我自己的使用频率和场景出发的分类,供大家参考。
1. 数据查询主力:一个支持 MCP 的跨境数据工具
这是整套工作流的核心。我用的是一款最近一年才接触到的工具,它把我前面提到的几个平台(亚马逊、沃尔玛、Shopee、TikTok、Temu,加上 1688 供应链)的数据全部整合在一个客户端里。更关键的是,它支持 MCP 协议,也就是说,我可以通过统一的接口去调用它所有的数据能力,不用关心每个平台背后是怎么查的。
我数了一下,它在我常用的几个平台上的工具数量分别是:亚马逊 32 个、沃尔玛 14 个、Shopee 15 个、TikTok 8 个、Temu 8 个,加上 1688 的 1 个,一共 78 个左右。再加上一些通用工具,总共有 79 个 MCP 工具可以调用。这个数量对我来说完全够用了。
2. 命令行工具:CLI 封装层
虽然 MCP 本身已经很好用了,但我有时候还是想在终端里直接敲一行命令查一个 ASIN,而不是打开 GUI 客户端。所以我自己在外面包了一层 CLI,叫它 my-cli。这个 CLI 内部其实就是调用那个数据工具的 MCP 接口,只是把它包装成更顺手的形式。我把它放在 /usr/local/bin 下面,这样在任何目录下都能直接调用。
CLI 这层的好处不只是为了在终端里用。更重要的是,它把 n8n 和数据源之间的耦合解开了——n8n 不需要知道背后是哪个 MCP 工具,只管调用 my-cli 就行。这样以后换数据源,改 my-cli 的实现就好,n8n 那边的 workflow 不用动。我吃过一次亏,之前有款工具改版,MCP 接口直接变了,导致我所有 workflow 全挂了。后来改成 CLI 抽象层,换工具只需要重写 CLI,workflow 那侧一行都不用改。
比如查一个 ASIN 的"隐赚指数",我直接敲:
my-cli query --asin B0XXXXXXXX --index hidden-profit
回车之后,终端里直接打印出 JSON 格式的结果。我可以在脚本里捕获这个输出,再做后续处理。
3. 工作流编排:n8n
n8n 是开源的工作流自动化工具,类似于 Zapier 但更灵活,而且可以自托管。我用它来把多个数据查询任务串起来。比如:每天早上 8 点触发一次工作流,先去亚马逊查我关注的 20 个 ASIN 的销量,然后去沃尔玛查同款的价格,接着调一个"利润测算"的 MCP 工具算一遍毛利,最后把所有结果汇总成一个 Markdown 报告,发到我的邮箱。
n8n 的好处是可视化,每个节点做什么、连到哪个节点,界面上看得很清楚。我以前用过 Python 脚本写定时任务,但脚本一长就不好维护。换成 n8n 之后,改一个流程就是拖一下节点的事。
另一个我很喜欢 n8n 的点是它的"分批处理"能力。举个例子,我有一个 ASIN 关注列表,大概 50 多个,我不想一次全查(怕触发对方限流),而是希望每批查 5 个,批次之间间隔 2 秒。n8n 的"Split In Batches"节点配上一个 Wait 节点,就能完美实现。我以前用 Python 脚本写这种逻辑,要写 30 多行代码;n8n 拖几个节点就完事了。
4. 数据存储:PostgreSQL + CSV
跑出来的数据要存下来,我用的是 PostgreSQL,装在本地一台小服务器上。历史数据保留 90 天,方便我做趋势对比。如果不想折腾数据库,直接存 CSV 也行,n8n 的节点里就有写文件的模块。
5. 报告呈现:Markdown + 一个简单的 HTML 模板
最终的报告我用的是 Markdown 格式,因为我每天大部分时间在 VS Code 里看代码,Markdown 渲染起来最舒服。如果你喜欢看网页版,可以用 Markdown 转 HTML 的工具加一个简单的 CSS,渲染出来的效果也不差。
三、从零搭建这套工作流:5 个步骤走完
接下来是最干的部分——我把这套东西的搭建过程拆成 5 个步骤,每一步给出具体的命令和配置。跟着走一遍,你应该也能在半天之内搭出雏形。
Step 1:安装 CLI 工具
我用的是 Python 写的 my-cli,放在 GitHub 私有仓库里。安装很简单,pip 一行就够:
pip install my-cli
装完之后,要先配一下 API Key。我用的是那款 MCP 工具提供的接口,先去它官网注册账号(我注册的时候赶上 7 天免费试用,加上 100 次免费调用,正好够我把整套流程跑通验证),拿到一个 API Key,然后执行:
my-cli config --set api_key=你的key
验证一下是否配置成功:
my-cli ping
看到返回"pong"就说明通了。
Step 2:本地部署 n8n
n8n 我是用 Docker 跑的,这样不污染本地环境。命令很简单:
docker volume create n8n_data
docker run -it --rm \
--name n8n \
-p 5678:5678 \
-v n8n_data:/home/node/.n8n \
n8nio/n8n
跑起来之后,浏览器打开 http://localhost:5678,第一次会让你创建一个账号,创建完就进入主界面了。
Step 3:配置 MCP 接口
这一步是关键。我们要把那个数据工具的 MCP 接口接到 n8n 里。n8n 本身没有内置 MCP 节点,所以我用了一个变通办法——通过"Execute Command"节点调用 CLI,CLI 再去调 MCP 接口。
另外提一下,MCP 的全称是 Model Context Protocol,你可以把它理解成"让 AI 模型和外部工具对话的标准协议"。它本质上就是一个 JSON-RPC 2.0 的封装,定义了客户端怎么调用服务端的能力。我用了一年下来最大的感受是:它是真正把"工具"和"应用"解耦了——同一个 MCP 服务,可以接 Claude、可以接 n8n、可以接自己的脚本,怎么接都行。
先在 n8n 里建一个新的 workflow,加一个"Cron"节点,设置成每天早上 8 点触发。然后加一个"Execute Command"节点,命令填:
my-cli query --asin {{$json["asin"]}} --index hidden-profit
其中 asin 是从上一个节点传进来的变量。CLI 的 stdout 输出会被 n8n 捕获,作为下一个节点的输入。
如果你不想绕这一层 CLI,也可以直接用 HTTP Request 节点调 MCP 工具暴露的 HTTP 接口。MCP 协议本身是基于 JSON-RPC 的,大部分实现都会同时暴露 HTTP 端点,这样在 n8n 里直接 POST 也行。
Step 4:把 Python 代码也接进来
有时候我需要在工作流里跑一些更复杂的逻辑,比如根据 ASIN 列表批量查询、过滤、聚合。这时候我用 n8n 的"Code"节点写一段 Python:
from my_tool import Client
c = Client(api_key="你的key")
result = c.mcp_hidden_profit(asin="B0XXXXXXXX")
print(result)
这段代码的意思是,通过 SDK 直接调用 MCP 工具的隐赚指数查询功能。SDK 内部其实就是把 MCP 的 JSON-RPC 调用包装了一下,代码上看起来更接近普通的 Python 函数调用。
注意,n8n 的 Code 节点默认是 JavaScript。如果想跑 Python,需要在创建节点的时候选 "Python" 模式(或者用 Function 节点的 Python 变体)。不同版本的 n8n 选项位置略有不同,大家按自己安装的版本去找。
Step 5:接上定时和通知
最后一步,把整个 workflow 加上定时触发和结果通知。Cron 节点我前面已经加了,通知我用邮件,加一个"Send Email"节点,把报告内容作为邮件正文发出去。
整个 workflow 大致是这样的:
{
"nodes": [
{
"name": "Cron",
"type": "n8n-nodes-base.scheduleTrigger",
"parameters": {
"rule": {
"interval": [
{"hours": 8}
]
}
}
},
{
"name": "Read ASIN List",
"type": "n8n-nodes-base.readBinaryFile",
"parameters": {
"filePath": "/data/asin_watchlist.txt"
}
},
{
"name": "Query MCP",
"type": "n8n-nodes-base.executeCommand",
"parameters": {
"command": "my-cli batch --file /data/asin_watchlist.txt --index hidden-profit"
}
},
{
"name": "Format Report",
"type": "n8n-nodes-base.code",
"parameters": {
"language": "python",
"code": "results = $input.all();\nreport = '# 每日选品报告\\n\\n'\nfor r in results:\n report += f\"- {r['json']['asin']}: {r['json']['profit_index']}\\n\"\nreturn [{'json': {'report': report}}]"
}
},
{
"name": "Send Email",
"type": "n8n-nodes-base.emailSend",
"parameters": {
"toEmail": "me@example.com",
"subject": "每日选品报告",
"text": "={{$json['report']}}"
}
}
]
}
这个 workflow 跑起来之后,我每天早上 8 点会准时收到一封邮件,里面是前一天的数据汇总。哪个 ASIN 销量涨了、哪个关键词热度上来了、哪个产品利润空间被压缩了,一目了然。我要做的只是根据报告去决定要不要调整出单、要不要补货、要不要暂停某个 SKU。
这套流程我用了大概三个月,中间也踩过一些坑。最常见的问题是 MCP 接口偶尔会超时,导致整个 workflow 中断。我后来加了一个重试节点,如果第一次查询失败,自动重试三次,三次都失败才发告警邮件给我。这个小改进让整个系统的稳定性高了很多。
四、关于这套工作流,我被问得最多的 6 个问题
最后这一部分,挑几个我被身边朋友问得最多的问题,统一回答一下。这些问题覆盖了从选型、稳定性到成本的各个方面,如果你正在考虑要不要搭这样一套东西,应该会有帮助。
Q1:CLI + n8n + MCP 这套组合,学习成本高吗?
说实话,不算太低,但也不算特别高。如果你之前用过 Linux 命令行、写过一点 Python,上手会快很多。CLI 部分基本就是查文档抄命令,半天就能跑通。n8n 是可视化拖拽,没有编程基础也能用,只是写复杂逻辑的时候需要用 Code 节点。MCP 这部分相对新一点,但概念不复杂,就是"调用别人做好的工具"。我当年搭这套大概花了两个周末,现在回过头看,如果只是搭个基础版本,一个下午足够。
我建议的入门路径是:先把 CLI 装上,用最简单的一两条命令跑通——比如查一个 ASIN 的基本信息。这一步搞定了,说明数据源 OK。然后再上 n8n,做一个最简单的"定时+查询+邮件"三节点 workflow,确认 n8n 能正常调用 CLI。最后再加 Python Code 节点、写告警逻辑、做容错。不要一上来就想把所有功能都做完,先跑通最小闭环,再一点点加东西。
Q2:这套工作流跑起来,数据准确度怎么样?
从我自己的使用经验看,数据准确度主要取决于背后那个数据工具本身的质量。我用的那款工具,在亚马逊和沃尔玛上的数据更新比较及时,基本能做到 T+1。Shopee 和 TikTok Shop 会稍慢一点,有时候会差两三天。利润测算这块,要看它对接的物流和佣金数据是不是最新的——这一块我自己还做了一层校准,把它的结果再过一遍我自己的计算公式,确保最后的数字是符合实际情况的。
Q3:n8n 自托管会不会很麻烦?有没有云服务推荐?
我自托管 n8n 用的是一台 NUC 小主机,装了 Ubuntu,跑了大半年没出过问题,日常 CPU 占用也就 5% 左右。如果你不想折腾服务器,n8n 官方有 n8n.cloud 托管服务,按月付费,功能上和自托管版本基本一致。我身边有两个朋友在用云服务版,他们的反馈是省心,但长期算下来比自己买服务器贵不少。如果你的 workflow 数量不多、数据量不大,云服务完全可以起步;如果像我一样跑得比较重,自托管更划算。
Q4:这套方案的成本大概多少?
拆开算:CLI 这部分开源,零成本;n8n 自托管,主要是服务器电费,我那台小主机一年大概 200 块电费;MCP 这块是订阅制,我用的是按月付费,具体数字不方便说,但基本就是一顿饭钱。最关键的是它有 7 天免费试用 + 100 次免费调用,先把这个额度用完,确认它能解决你的问题再付费。我自己就是先用免费额度把整套流程验证了一遍,确认有用才开通付费,这样决策风险最低。
Q5:如果某天 MCP 接口挂了,我整个工作流是不是就停了?
是的,会停。所以我前面提到加了重试节点,加上告警邮件。但这只是治标,治本的话有两个办法:一是工作流里加一个备用数据源,主源挂了自动切到备用源;二是在 workflow 里加一个人工触发的兜底节点,如果自动链路挂了,手动跑一次也能出报告。我目前用的是第一种方案,虽然多花了一点订阅费,但心里踏实很多。如果你刚开始搭,可以先只跑主源,等流程稳定了再加备用。
Q6:这套方案适合所有阶段的卖家吗?
坦白讲,不太适合新手。新手最大的问题是连"要查什么数据"都不清楚,自动化只是把混乱的事情加速了,不会让混乱变清晰。我建议是先用人工的方式把选品流程跑一遍,搞清楚每一步在查什么、为什么查、查到了之后做什么决策。等流程跑顺了,数据点也清楚了,再考虑自动化。如果一上来就搞自动化,大概率是给自己挖坑。我自己也是做了两年多之后才上的这套东西,中间换了三次思路才稳定下来。
再说一个我个人观察到的规律:真正能把自动化用起来的,反而不是技术最强的卖家,而是那些对自己业务流程最清楚的卖家。技术只是工具,业务理解才是底层。我身边有个做了七八年的朋友,他对每个 ASIN 的利润结构、流量结构烂熟于心,他搭出来的自动化虽然简陋,但每一处都有明确的目的。我这种半路出家的,反而容易陷入"为了自动化而自动化"的陷阱,workflow 越搭越复杂,但实际用起来很多节点根本没起作用。
如果你刚开始考虑做这套东西,我建议你先回答三个问题:第一,我现在每天花多少时间在重复劳动上?第二,这些重复劳动如果省下来,我会去做哪些更有价值的事?第三,我能不能用一张纸把现在的流程画清楚?三个问题都答得上来,就可以动手搭;答不上来,先把业务想清楚再上工具。
好了,这篇文章差不多就到这里。最后总结一下:CLI + n8n + MCP 这套组合,本质上就是"用命令行做单点查询、用 n8n 做流程编排、用 MCP 做数据接口"的三层架构。它不是银弹,不能帮你做选品决策,但它能把你每天花在重复劳动上的两三个小时省下来,让你把精力放在真正需要判断力的事情上。
跨境这行越来越卷,工具用得好不好,有时候比努力不努力更重要。希望我这套方案能给大家一些启发,也欢迎在评论区交流你平时是怎么做选品自动化的——说不定你的一些小技巧,就是我下一个改进的方向。
最后再啰嗦一句:工具再好也只是工具,真正决定你能不能选到好品的,还是你对市场的理解、对用户的洞察、对供应链的把控。自动化能帮你省时间,但不能帮你做判断。把判断力练出来,把工具用顺手,这两件事都做到,跨境这条路才走得稳、走得远。我自己还在路上,大家共勉。
更多推荐

所有评论(0)