苹果群控，是通过一台电脑对多台 iPhone 做集中管理与批量操作的技术方案，不越狱、不装插件、不需要开发板。
这篇要回答的是：苹果群控怎么管亚马逊多店铺，订单、跟卖与买家消息怎么看。
前年阿良开始做家居用品，美国站五个店铺。
他给我描述的日常是这样的：早上七点起来第一件事，把五个后台的订单各看一遍；中午吃饭前再看一遍；晚上睡前最后一遍；五个店铺，一天十五趟。
十五趟里，十四趟是「没变化」。但你不能不看。真出事的那一趟，就是你没看的那一趟。
最怕的三件事，哪些能交出去
第一件事是跟卖。你辛苦做了半年的 listing，某天早上发现多了一个卖家，价格比你低两美元。这种事发现得越晚越麻烦。
第二件事是差评。尤其是排在前面的那条评论，一条带图的差评能压住后面十条好评。亚马逊的评价规则又紧，能做的事情有限，但至少要知道什么时候出事了。先知道，才谈得上处理。
第三件事是断货和库存。卖爆了但库存不够，listing 权重会掉；滞销的又不该继续挂着占位。
这三件事的共同点是：它们都需要被及时发现，而不需要立刻处理。发现是重复动作，处理是判断；这个区别很关键；能发现，是不是就等于能处理？不是。
订单巡检、库存阈值检查、断货自动下架、到货重新上架、买家消息归类，这几件都能交出去。
跟卖这件事，脚本能帮你「发现」，帮不了你「处理」。发现逻辑很固定：进商品页、看有没有其他卖家、有就记下来。但要降价跟、发警告信、还是走品牌备案流程，那是人的决定，而且每个店铺的策略可能不一样。
买家消息也一样。亚马逊的 Buyer-Seller Messages 大部分是三类：什么时候发货、能不能退货、地址对不对。这三类可以套话术。但涉及索赔、A-to-Z、还有那种明显在挑刺的消息，必须人接。所以脚本的正确做法是分类，不是回复。
这里有个容易忽略的细节：亚马逊对买家消息的回复时效有要求，超过 24 小时会影响账号表现。人不可能盯着五个后台，脚本可以。
设备怎么连、店铺怎么绑，先从几个店试
五个店铺对应五台手机，摆在桌面上不挪窝。这种情况用数据线直连就够：中控 10.7.0 以上配 iOS 17 以上的手机，一台一根线，不需要蓝牙板，也不需要 OTG 板，免越狱免签名。
如果店铺继续扩到十几二十个，手机多到一张桌子放不下、要分到几个工位，再考虑 WiFi。要彻底把线收掉可以用蓝牙板（ESP32C3）；工位离电脑太远，才需要 OTG 板（ESP32S3，只支持 iOS 17 以上）。判断口径是你有没有距离问题，不是哪个更快。没有距离问题，买板子图什么？
设备多了以后有两件物理上的事要先处理：集线器要用带独立电源的，手机别贴在一起摆。这两条跟软件无关，连接方式里写得更细。
一个店铺一台设备，物理绑死，不要一台手机轮流登两个店。
亚马逊的账号关联判断不只看登录信息，设备环境、网络出口都在里面。同一台手机上切两个店铺账号，等于主动把两个店连在一起。省下来的是设备钱，赌上的是店铺。
设备多了要分组和命名。建议按站点分（美国站一组、欧洲站一组），名字里写清站点加店铺加编号。多店铺运营里最费时间的往往不是操作，是「这台是哪个店来着」。
节奏上，五个店铺不要在同一分钟一起看；分两批，中间隔十几分钟，比五个同时动更自然。
设备和绑定都理顺了，还有个更现实的问题：几个店才值得上这套？
一两个店铺手工就够，用不上这套。到五个店铺、而且每个店每天都要看的时候，收益才开始明显。
要试的话建议先做只读的：一个订单巡检脚本、一个库存阈值脚本，跑两周。这两件事跑错了顶多是漏看，风险最低。确认没问题，再上「改」的动作：下架、上架、调价这些，一旦跑错直接影响生意。
阿良现在的做法是早上让脚本跑一遍订单和库存，把结果汇总给他看；跟卖和差评这两件事，脚本只负责发现和提醒，剩下的他自己来。他说现在每天花在五个后台上的时间从两个多小时压到二十分钟左右。