1. 从手动翻页到自动化流水线这个工作流到底解决了什么问题做跨境电商运营的朋友大概率都有过这样的体验想摸清一个竞品店铺的底细得手动点开卖家主页一页一页翻商品列表把标题、价格、销量、运费、卖家等级这些信息挨个复制到表格里。一个店铺几十上百个商品光采集就得花掉大半天更别提后续还要做价格带分析、品类结构拆解、爆款特征提取这些活了。我自己早期做选品调研的时候经常是开着十几个浏览器标签页复制粘贴到手腕发酸最后数据还对不上号。这个项目的出发点很直接把“采集—清洗—分析—输出”这条链路用 n8n 串起来让机器去干重复劳动人只负责看结论。n8n 是一个开源的工作流自动化工具核心逻辑就是“触发器 节点 数据流转”你可以把它理解成一个可视化的编程环境每个节点干一件事节点之间用数据线连起来数据像流水一样从上游流到下游。相比写一整套 Python 爬虫脚本n8n 的优势在于可视化编排、节点复用、调试直观而且内置了大量的数据处理和条件判断能力不用从零造轮子。标题里提到的 SKILL在这个语境下指的是一套封装好的技能模块或者提示词工程方案用来驱动大模型完成特定任务。具体到这个工作流SKILL 承担的是“理解页面结构”和“提取结构化字段”的职责。传统爬虫靠 CSS 选择器或者 XPath 硬编码定位元素eBay 页面一改版就得重新调而用大模型来解析页面内容相当于让一个懂业务的人去看页面你告诉它“帮我找出商品标题、价格、销量、卖家名称”它就能把这些字段抽出来页面结构微调也不容易崩。这是这套方案和传统爬虫最大的区别也是它值得开源分享的核心价值。这个工作流适合谁用三类人收益最明显。第一类是跨境电商卖家尤其是做铺货或者精铺的团队需要批量监控竞品店铺的动态第二类是选品分析师需要快速获取某个品类下多个店铺的商品结构数据第三类是对 n8n 和大模型应用感兴趣的开发者想找一个完整的、有实际业务价值的项目来练手。哪怕你之前没接触过 n8n跟着节点逻辑走一遍也能理解自动化工作流的设计思路。提示这个工作流的核心思路不仅适用于 eBay换成其他电商平台的店铺分析只要调整页面解析逻辑和字段映射整体框架是可以复用的。2. 整体架构拆解为什么这样设计节点链路2.1 工作流的四层结构整个工作流我把它拆成四层从下往上分别是触发层、采集层、解析层、输出层。每一层负责的职责边界很清晰这样设计的好处是调试的时候能快速定位问题出在哪一层而不是一锅粥地从头查到尾。触发层负责启动整个流程。常见的方式有三种手动触发适合调试阶段、定时触发适合周期性监控、Webhook 触发适合被其他系统调用。我在实际使用中调试阶段用手动触发跑通之后改成定时触发比如每天早上八点自动跑一遍目标店铺上班就能看到最新数据。采集层负责把目标页面的内容抓回来。这里有个关键决策是直接请求页面 HTML还是用无头浏览器渲染eBay 的商品列表页大部分内容是服务端渲染的直接请求 HTML 就能拿到商品信息不需要额外跑一个浏览器实例这样速度快、资源占用低。但如果遇到需要登录才能看到的页面或者页面有大量 JavaScript 动态加载的内容就得考虑用浏览器渲染节点。我的建议是先用 HTTP 请求节点试能拿到数据就不上浏览器毕竟无头浏览器的资源消耗和稳定性都是额外的负担。解析层是整个工作流的核心也是 SKILL 发挥作用的地方。采集层拿回来的是原始 HTML里面混杂着大量无关的标签、脚本、样式。传统做法是用 HTML 解析节点提取特定元素但 eBay 的页面结构经常调整class 名一改选择器就失效了。这里我用大模型来做内容提取把 HTML 清洗成纯文本或者精简后的结构化文本然后交给模型去识别字段。模型返回的是 JSON 格式的结构化数据后续节点直接按字段取值就行。输出层负责把解析好的数据落地。可以是写入数据库、追加到表格、发送到消息队列或者直接生成分析报告。我目前的做法是先把数据写入一个表格文件方便快速查看和二次处理同时把汇总统计结果推送到即时通讯工具这样不用打开电脑也能知道今天的采集情况。2.2 为什么用大模型做解析而不是传统选择器这个问题值得展开说。传统选择器方案的优势是快、准、可控只要页面结构不变提取结果百分之百稳定。但它的致命伤是脆弱性eBay 这种大型电商平台前端改版是家常便饭今天能用的选择器明天可能就失效了。而且不同品类的页面结构可能还有差异你得为每种页面写一套选择器维护成本很高。大模型方案的优势在于鲁棒性。你把页面内容给它用自然语言描述你要提取什么字段它就能理解并返回结构化结果。页面结构微调、字段位置变化对模型的影响相对较小。代价是速度和成本每次调用模型都有延迟而且按 token 计费大批量采集时成本需要考虑。我的折中方案是先用规则做初步筛选和清洗把无关内容去掉减少送给模型的 token 数量同时设置合理的并发和缓存策略避免重复解析相同内容。还有一个细节模型返回的 JSON 需要做校验。我在工作流里加了一个校验节点检查必填字段是否存在、价格字段是否是数字、销量字段是否在合理范围内。如果校验不通过就把这条记录标记为异常走单独的异常处理分支而不是让脏数据混进最终结果。2.3 节点编排的取舍逻辑n8n 的节点编排很灵活同样的功能可以用不同的节点组合实现。我在设计时遵循几个原则一是单一职责每个节点只做一件事比如“提取商品列表”和“提取商品详情”分成两个节点而不是揉在一起二是数据流清晰节点之间的数据传递尽量用明确的字段名避免用位置索引取值这样后续调整顺序不会导致数据错位三是错误处理前置在容易出错的节点后面接条件判断把异常分支单独处理而不是让整个工作流崩掉。举个例子采集层请求页面时可能遇到网络超时、返回 404、返回验证码页面等情况。我在 HTTP 请求节点后面接了一个条件判断节点检查返回状态码和内容特征。如果是正常页面走解析分支如果是异常页面走重试或告警分支。这样即使某个页面采集失败也不会影响其他页面的处理。3. 核心环节实操从页面采集到结构化输出的完整链路3.1 目标店铺的定位与分页处理第一步是确定要分析的店铺。eBay 的店铺主页 URL 有固定格式通常包含卖家 ID。你需要先把目标店铺的卖家 ID 提取出来拼成商品列表页的 URL。eBay 的商品列表默认每页显示一定数量的商品超过部分需要翻页。翻页有两种处理方式一种是分析分页链接的规律用循环节点逐页请求另一种是找到“每页显示数量”的参数把它调到最大减少请求次数。我采用的是循环加分页参数的方式。在 n8n 里用一个“循环”节点设置起始页码和结束条件每次循环把页码拼进 URL请求下一页。这里有个坑eBay 对频繁请求有频率限制如果并发太高或者间隔太短会触发限流甚至临时封禁。我的做法是在循环里加一个等待节点每次请求之间间隔几秒同时设置最大页数上限避免无限翻页。实测下来间隔三到五秒比较稳妥具体可以根据目标店铺的商品数量和自己的网络环境调整。注意采集频率一定要控制不要为了快而把间隔设得太短。一旦触发限流后续所有请求都可能失败反而更慢。3.2 页面内容的清洗与精简拿到 HTML 之后不能直接丢给模型那样 token 消耗太大而且噪声太多会影响提取准确率。我加了一个清洗节点做几件事去掉 script 和 style 标签及其内容、去掉注释、去掉多余的空白字符、把 HTML 标签转换成纯文本或者保留必要的结构标记。清洗之后的内容体积能减少百分之六七十模型处理起来更快成本也更低。清洗的粒度需要把握。如果洗得太狠把商品标题和价格之间的关联结构也破坏了模型可能无法正确对应字段。我的经验是保留基本的块级标签比如 div、li、tr去掉行内样式和脚本这样模型还能看出内容的层级关系。具体保留哪些标签可以拿一个样本页面做实验对比不同清洗策略下模型的提取准确率。3.3 SKILL 提示词的设计要点提示词是决定提取质量的关键。我试过几种写法最后稳定下来的结构是这样的先给模型一个角色设定比如“你是一个电商数据提取助手”然后说明任务即“从以下页面内容中提取商品信息”接着给出字段定义和格式要求用 JSON schema 的方式描述每个字段的名称、类型、是否必填最后附上页面内容。字段定义要尽量明确。比如“价格”字段要说明是数字类型单位是美元如果页面上有多个价格原价、折扣价要指定取哪一个。“销量”字段要说明是字符串还是数字如果页面上显示的是“已售出 100”要说明如何处理这个“”号。这些细节不写清楚模型返回的结果就会五花八门后续处理很麻烦。还有一个技巧在提示词里加一两个示例。给模型看一个输入输出的例子它就能更好地理解你的意图。示例不用多一个就够但要是真实数据的脱敏版本不要用编造的假数据否则模型可能学到错误的模式。3.4 结构化数据的校验与落库模型返回 JSON 之后我加了一个校验节点。校验分两层第一层是格式校验检查返回的是不是合法 JSON必填字段是否存在第二层是业务校验检查价格是否为正数、销量是否在合理范围、商品标题长度是否正常。校验不通过的记录会被打上标记写入一个单独的异常表方便后续人工排查。校验通过的数据写入表格文件。我用的是追加模式每次运行把新数据追加到已有数据后面同时记录采集时间戳。这样既能保留历史数据做趋势分析又能避免每次覆盖导致数据丢失。表格的列包括商品标题、价格、销量、卖家名称、商品链接、采集时间。如果后续要做更复杂的分析可以在这个基础上增加字段比如商品分类、运费、是否包邮等。3.5 汇总统计与结果推送数据落库之后我加了一个汇总节点计算几个关键指标本次采集的商品总数、价格的中位数和平均值、销量最高的前几个商品、价格区间的分布。这些统计结果会格式化成一段文本通过即时通讯工具的 Webhook 推送出去。这样即使不在电脑前也能快速了解目标店铺的大致情况。推送内容的格式我调整过好几版。最开始是纯文本后来改成带简单排版的 Markdown可读性好了很多。关键数据用加粗标出异常情况用引用块提示。推送频率和采集频率保持一致避免信息过载。4. 踩坑记录与排查手册那些文档里不会写的问题4.1 页面结构变化导致的提取失败这是最常见的问题。eBay 时不时会调整页面布局比如把价格从标题下方移到右侧或者改变销量显示的位置。传统选择器方案遇到这种情况直接报错大模型方案虽然鲁棒性更好但也不是万能的。如果页面结构变化太大模型也可能提取不到正确字段。我的应对策略是在工作流里加一个“提取结果质量检查”节点。如果某次采集中超过一定比例比如百分之三十的记录出现字段缺失或格式异常就触发告警提示我人工检查页面是否改版。同时保留最近几次的原始页面内容方便对比分析变化点。如果确认是页面改版就调整清洗规则和提示词重新跑一遍。4.2 模型返回格式不稳定的处理大模型有个特点同样的提示词不同批次的返回格式可能有细微差异。比如有时候返回纯 JSON有时候会在 JSON 外面包一层 Markdown 代码块标记有时候字段名的大小写会变。这些差异如果不处理后续节点解析就会出错。我的做法是在校验节点里做兼容处理。先用正则把可能的代码块标记去掉然后尝试解析 JSON。如果解析失败再尝试用更宽松的方式提取字段。同时在提示词里明确要求“只返回 JSON不要添加任何额外说明或标记”这样能减少大部分格式问题。如果还是遇到顽固的格式问题就在工作流里加一个“格式修复”节点用简单的字符串处理把常见问题修掉。4.3 请求频率与反爬机制的平衡eBay 对自动化请求有一定的检测机制。如果请求频率过高、请求头不完整、或者行为模式太像机器人可能会返回验证码页面或者直接拒绝请求。我在调试初期就遇到过这种情况连续快速请求了几十次之后后续请求全部返回异常页面。解决办法有几个一是控制请求间隔我设置的是每次请求之间等待三到五秒具体根据目标店铺的商品数量调整二是完善请求头把 User-Agent、Accept-Language 等字段设置成常见浏览器的值三是加一个“异常检测”节点如果连续多次请求返回异常就自动暂停一段时间再重试而不是继续硬刚。实测下来这套组合策略能有效降低被拦截的概率。4.4 数据去重与增量采集如果每天跑一次采集同一个商品可能会被重复采集多次。如果不做去重表格里会有大量重复记录影响后续分析。我的做法是在写入之前加一个去重节点根据商品链接或者商品 ID 判断是否已经存在。如果存在就更新价格和销量字段如果不存在就追加新记录。这样表格里每个商品只有一条记录但保留了最新的价格和销量数据。增量采集是另一个优化点。如果目标店铺的商品数量很多每次全量采集耗时太长。可以记录上次采集的时间戳只采集在那之后有更新的商品。不过 eBay 的商品列表页不一定支持按更新时间筛选这个需要根据实际情况调整策略。我目前的方案还是全量采集加去重因为目标店铺的商品数量在可接受范围内全量跑一遍也就几分钟。4.5 常见问题速查表问题现象可能原因排查方向解决方法采集返回空数据请求被拦截或页面结构变化检查返回状态码和内容长度调整请求间隔检查请求头人工查看页面模型提取字段缺失提示词不明确或页面内容被过度清洗对比原始页面和清洗后内容优化提示词调整清洗规则保留更多结构JSON 解析失败模型返回格式不稳定查看模型原始返回内容增加格式兼容处理强化提示词约束数据重复写入缺少去重逻辑检查表格中是否有重复商品链接增加去重节点按商品 ID 判断工作流中途卡住某个节点报错或等待超时查看节点执行日志增加错误处理分支设置合理的超时时间推送消息太频繁采集频率过高检查触发器的定时设置降低采集频率合并推送内容5. 工具选型与扩展思路这套方案还能怎么玩5.1 n8n 与其他自动化工具的对比选 n8n 而不是其他自动化工具主要考虑几点一是开源可以自己部署数据留在自己手里二是节点丰富内置了 HTTP 请求、JSON 处理、条件判断、循环等常用节点不用写太多代码三是社区活跃遇到问题容易找到参考方案。相比一些纯 SaaS 的自动化工具n8n 的灵活性和可控性更高适合有一定技术基础、愿意折腾的团队。当然n8n 也有学习成本。它的节点编排逻辑和传统的编程思维不太一样刚开始可能需要花点时间适应。我的建议是先从简单的两三个节点的工作流开始跑通了再逐步增加复杂度。官方文档和社区论坛里有大量示例照着改比从零写快得多。5.2 从单店铺到多店铺的扩展目前的工作流是针对单个店铺设计的。如果要扩展到多店铺有两种思路一种是在触发层加一个店铺列表用循环节点遍历每个店铺依次执行采集和分析另一种是把工作流拆成“采集”和“分析”两个独立的工作流采集工作流负责把数据写入数据库分析工作流从数据库读取数据做汇总。第二种方式更适合店铺数量多、采集频率不一致的场景解耦之后维护起来更灵活。多店铺场景下还需要考虑数据隔离和权限控制。不同店铺的数据要分开存储避免混淆。如果团队多人使用还要考虑谁可以触发采集、谁可以查看结果。这些在 n8n 里可以通过环境变量和工作流权限来管理具体配置可以参考官方文档。5.3 数据分析维度的深化目前的分析还比较基础主要是价格和销量的统计。后续可以扩展的维度很多比如商品标题的关键词分析看看哪些词出现频率高比如价格带分布看看店铺主打哪个价格区间比如商品上架时间的分析看看新品和老品的比例。这些分析可以在 n8n 里用代码节点实现也可以把数据导出到专门的分析工具里做。我个人的经验是不要一开始就追求大而全的分析。先把基础数据采集稳定了再逐步增加分析维度。每增加一个维度都要验证数据的准确性和分析结果的可解释性。否则堆了一堆指标最后没人看得懂反而失去了自动化的意义。5.4 异常监控与自动恢复工作流跑久了总会遇到各种意外情况。我加了一个简单的监控机制每次运行结束后记录运行状态、耗时、处理记录数、异常记录数。如果连续多次运行失败或者异常记录比例超过阈值就发送告警通知。同时对于可恢复的异常比如网络超时设置了自动重试机制重试几次都失败才标记为最终失败。自动恢复方面我目前只做了简单的重试。更复杂的场景比如某个节点持续失败可能需要人工介入排查。我的建议是保留足够的日志信息包括每个节点的输入输出、错误堆栈、时间戳这样排查问题时能快速定位。n8n 的执行日志功能可以满足这个需求关键是要养成查看日志的习惯不要等到出大问题了才去翻。6. 一些实操心得和后续想法这套工作流我从最初的想法到稳定运行前后调整了大概两周时间。最大的体会是自动化工具的价值不在于一步到位而在于持续迭代。第一版能跑通基本流程就行不用追求完美。跑起来之后你会遇到各种预料之外的问题这些问题才是真正让你理解业务和工具的契机。另一个心得是关于提示词的。我一开始把提示词写得很复杂恨不得把所有可能的情况都覆盖到。结果发现模型反而容易困惑提取质量不稳定。后来简化成“角色 任务 字段定义 示例”的结构效果反而更好。这让我意识到和模型沟通跟和人沟通一样说清楚核心需求比堆砌细节更重要。后续我打算在这几个方向继续完善一是增加对商品详情页的采集目前只采集了列表页的信息详情页里的描述、规格、评价数据也很有价值二是把数据存储从表格文件迁移到数据库方便做更复杂的查询和关联分析三是尝试用多个模型做交叉验证提高提取准确率。这些想法还在验证中等跑通了再整理出来分享。如果你也在做类似的电商数据采集和分析希望这套思路能给你一些参考。工具和方案会过时但“把重复劳动交给机器、把精力留给判断和决策”这个原则不会变。