店群自动化做到跨地域、多平台时，会遇到一个基础设施层面的难题：主控节点和执行节点该怎么分布？全部放在一个公有云区域？国内店铺访问TEMU海外站延迟高。全部放在海外？拼多多又访问不了。全部走代理？带宽成本爆炸。我们曾经把30个TEMU店铺的执行节点全部部署在阿里云美西，结果拼多多店铺任务总是超时。后来把拼多多节点放在上海，但两个集群的数据同步又成了问题。最终我们设计了一套混合云+边缘执行节点架构。这

店群自动化最怕的不是技术难实现，而是账号活不久。我见过太多团队，脚本写得飞起，店铺却在两周内批量阵亡。运营问为什么，开发说“我们也没有违规操作啊”。问题出在哪里？出在不了解平台的风控逻辑。拼多多、TEMU、TikTok Shop这些平台，不会因为你用了自动化就封号。它们封的是“异常的人类行为”——比如点击轨迹太完美、操作频率太均匀、登录时间太规律、鼠标永远不晃动。这篇文章不教你怎么绕过风控，那是违

调度器是店群自动化系统的大脑。但大多数团队的调度器，只是简单的FIFO队列加固定并发数。任务来了就执行，节点有空位就塞进去。这种调度方式在小规模下没问题。一旦店铺超过50个、任务类型超过10种、节点跨区域部署，问题就来了：高优先级任务被低优先级任务堵在后面、节点负载不均、高峰期任务排队太久、低谷期资源浪费……我们花了三个月，将调度器从“被动响应”升级为“主动预测+智能决策”。这篇文章不讲脚本编写，

店群自动化跑起来之后，你会发现一个现象：每天的成本是固定的，但业务量不是。晚上10点到凌晨2点，TEMU和拼多多的订单高峰；白天8点到18点，上架和改价任务集中；其他时段业务量很低，但服务器照跑、浏览器照开、代理IP照付。我们算过一笔账：在没有优化之前，每月云资源成本占总运营成本的20%。其中40%是浪费的——空闲时段的浏览器实例、闲置的节点、用不完的代理带宽。这篇文章不讲调度架构，也不讲脚本编写

店群自动化项目做到后期，脚本数量会爆炸式增长。我们统计过：50个店铺、8个平台、20多种任务类型，对应的影刀脚本和Python辅助脚本加起来超过200个。问题来了：改一个通用函数，怎么知道会影响哪些脚本？上架流程改了，怎么验证所有店铺的上架脚本都正常？新加一个原子操作，怎么确保不会破坏现有的编排流程？早期我们的做法是：改完脚本，手动跑几个店铺看看。没报错就上线。结果经常出现“开发环境没问题，生产环

店群自动化做到多平台、多店铺时，会遇到一个很隐蔽的问题：数据不一致。同一个商品，在拼多多上已经下架了，但TEMU上还是上架状态。订单已经在ERP里发货了，但店铺后台没同步。批量改价改了50个商品，第30个时脚本报错退出，前29个改了，后面21个没改。这些问题比脚本报错更麻烦。报错你能看见，数据不一致你可能过好几天才发现。我们早期处理这些问题的思路是“尽量避免”。后来发现避免不了——网络会抖、平台会

店群自动化跑久了，总会遇到一个让人头疼的问题：某个店铺悄无声息地“生病”了。登录成功率下降、验证码频率升高、订单同步延迟、页面加载变慢……这些早期征兆往往被忽略，直到账号被限制登录或永久封禁，运营才惊呼“昨天还好好的”。我们曾经在一个月内连续被封了5个TEMU店铺。事后复盘发现，每个店铺在封禁前3-5天就已经出现了明显的异常指标，只是没有人去关注。那次之后，我们设计了一套账号健康度评估与自动熔断恢

店群自动化做到一定规模，会面临一个尴尬的局面：运营的需求永远在变，开发的速度永远跟不上。今天要加一个“上架前检查库存”，明天要“根据利润自动调价”，后天又要求“订单发货后发短信提醒”。每个需求都要开发去改影刀脚本，测试、发布、验证，一套流程走下来两天过去了。我们当时就在想：能不能让运营自己编排任务流程？就像搭积木一样，把已有的影刀原子操作（登录店铺、上架商品、修改价格、处理订单）组合起来，加上条件

影刀RPA本身提供了强大的流程编排能力，但遇到复杂的数据处理、算法逻辑、系统调用时，还是得靠Python。混合编程是大多数店群项目的必经之路。但这条路不好走。我们踩过太多坑：Python脚本调用超时导致影刀卡死、环境依赖不一致、进程间通信数据丢失、异常无法透传……这篇文章不聊调度也不聊架构。专门聊聊影刀RPA和Python混合编程时的工程化实践——如何让两者稳定、高效、可维护地协同工作。适用场景：

店群自动化系统跑起来之后，你会发现一个现象：出问题不可怕，可怕的是你不知道哪里出了问题。我们经历过这样一个夜晚：凌晨两点，调度器还在正常跑，日志也没有报错。但第二天运营发现，过去6个小时所有拼多多店铺的订单都没有自动发货。原因是什么？影刀RPA脚本里的一个元素定位方式改了，脚本一直卡在“等待加载”，既没有崩溃也没有超时。调度器以为任务还在执行，实际上已经死锁了6个小时。那次之后，我们花了三周时间，

定时任务设了一个固定超时，短流程绰绰有余，长流程频频误杀。任务的执行时间不是常数，它是一个随数据量、网络状态、店铺规模变化的波动曲线。我们的调度系统在很长一段时间里，对任务执行时间的认知非常粗糙。流程配置里写一个固定的 ，比如订单采集设1800秒，消息回复设300秒。超时了就强行终止，标记失败，触发重试。日常情况下这个机制没大问题。但一旦平台搞促销、数据量翻倍、网络质量波动，固定的超时阈值就开始出

自动化跑得再顺畅，也总会撞上它搞不定的那一下。不是技术不行，是有些事天生就该交给人来判断。我们把店群自动化系统一层层建到了今天，流程失败率从早期的百分之十几压到了千分之几，自愈率做到了60%以上。但剩下那百分之几的异常里，有一类是无法绕过的——需要人类认知能力才能做出的判断和操作。登录过期后的扫码验证，平台弹出的图形验证码，一个模棱两可的买家消息意图，一张被系统标记为“疑似异常”但不确定该不该发货

告警告诉你出事了，监控告诉你哪里不对劲。但到底是什么原因，最终还得靠人翻日志、查截图、回溯执行链路，大半天就搭进去了。我们在前面把监控告警、运维巡检、安全熔断都建起来了，线上出了问题基本能在几分钟内被发现。但发现问题和解决问题之间，还有一道巨大的鸿沟——诊断。一个订单采集流程在凌晨3点失败了，告警推送到群里。值班的兄弟爬起来，打开Kibana翻日志，定位到是第37页翻页时报了元素超时。然后打开截图

同一个采集流程，在美国站能跑，到了德国站就报错。不是流程逻辑错了，是货币符号不认识、日期格式不兼容、页面语言对不上。TEMU和TikTok Shop把我们的业务从国内推到了海外。北美、欧洲、东南亚，店铺矩阵横跨十几个国家。原本跑得好好的自动化流程，迁移到新站点时开始出现各种“水土不服”——提取的价格对不上、翻页按钮找不到、时间筛选器完全失效。这不是平台改版，也不是架构瓶颈。根源在于我们把国内店铺的

回头看这一年半的工程化历程，最大的收获不是某套框架或某段代码。而是团队对于“自动化”这件事的认知，被彻底重写了一遍。这是这个专栏的第二十篇文章，也是我目前规划中的最后一篇。前面的十九篇，我们从浏览器实例池一路聊到容量规划与成本优化，把店群自动化系统拆开揉碎了讲了一遍。这篇不打算继续深入某个技术点，我想换个角度，以复盘的方式把整个演进历程串起来，聊聊我们在每个阶段做对了什么、做错了什么，以及整个过程