一个把脚本改到崩溃的人
有个自己做跨境电商的朋友，写脚本出身，一开始只有三台手机。
三台的时候他很轻松：每台一份脚本，账号、关键词、发布时间都写在代码里，想改什么直接改。后来加到二十台，问题就来了。
有一次平台改了一个按钮的位置，他要把二十份脚本里的坐标全都改一遍。改到第十一份的时候，他已经开始怀疑人生了。更要命的是，第二天他发现有两台设备跑的还是旧脚本，因为那两份他漏改了。
他后来跟我说了一句话：问题不在于脚本难写，而在于我的脚本没有为「二十台」这个规模设计过。
先把矩阵拆成三层
搭 ios手机矩阵，最容易犯的错是把它当成「设备的事」，上来就想着买几台手机、怎么接线。
设备是最后一层。动手之前先把结构拆清楚，后面每一步都会简单很多：
脚本层负责「做什么」：跑什么流程、在什么条件下做、失败了怎么办。 设备层负责「在哪做」：哪台设备对应哪个账号，怎么命名、怎么分组。 网络层负责「从哪出去」：每个账号的网络出口怎么分。
再补一层可选的：数据层负责「做得怎么样」：执行记录、截图、汇总。
下面按这四层讲。
脚本层：一套代码怎么跑 N 个号
这一层是矩阵和普通自动化最大的区别。
普通脚本的写法是把所有值写死在代码里。矩阵里的正确写法是：流程写死在代码里，值全部外置。
具体来说，账号、密码、关键词、发布时段、内容素材目录，这些每个号都不一样的东西，不要写在代码里，写成一份配置。代码里只保留流程，运行时按当前设备去查配置。
这样做有三个好处。
第一，改平台改版只需要改一处坐标，所有设备同时生效。 第二，加设备只是往配置表里加一行，不用碰代码。 第三，出了问题你能确定「所有设备跑的是同一份逻辑」，排除了脚本版本不一致这个干扰项。
配置表可以很简单，一行一台设备：
TikTok-US-01,account_a,pass_a,keyword_a,09:30
TikTok-US-02,account_b,pass_b,keyword_b,10:10脚本启动时拿到自己的设备名，去这张表里取自己那一行。中控下发任务的时候，设备名是天然带着的，所以这一步不需要额外传参。
设备层：接入方式、命名与分组
设备层的重点不是买什么手机，是让每台设备有清晰的、脚本能识别的身份。
接入方式按场地选。设备摆在架子上不挪窝，用数据线直连就行，中控 10.7.0 以上配合 iOS 17 以上的手机，一台一根线，不需要额外的硬件，也不用签名。设备要挪动或者分散在同一局域网，用 WiFi 更省事。设备离电脑太远、线拉不过去，才考虑外接硬件。
命名规则前面提过：用英文和短横线，「平台-市场-编号」。不要用中文，也不要用空格，因为这个名字要被脚本读取，中文在某些环节会有编码问题。
分组则按业务维度来。比较实用的是先按平台分组，再按市场分组。设备多了以后，下发任务和排查问题都是按组操作的。
分组做好之后，下发任务的时候按组选，不用一台台勾。加新设备只需要把它丢进对应的组，脚本不用改。
网络层：出口怎么分
出口这块，很多人是「每台设备一个独立代理」，也有人是「所有设备走同一个出口」。两种做法都不太对。
更合理的规则是按平台和市场分两层。
同一平台内的账号不共享出口。三个 TikTok 美国号走同一个出口，是明显的关联特征。 不同平台之间共享出口没问题。TikTok 美国号和 Amazon 美国号走同一组出口，这两个平台不交换数据，反而更像「同一个美国用户在正常上网」。 同一账号的出口要稳定。今天从 A 出口登录、明天从 B 出口登录，这个变化本身就是异常信号。
所以实际操作是：按市场准备几组出口，把设备的网络配置和它的市场对应起来，同一市场同一平台的账号错开使用。
稳定性这块要注意一点：频繁断线重连的出口，比稳定复用的出口风险更高。因为重连意味着短时间内出现了多次网络切换，这个特征很容易被记下来。
数据层：执行记录怎么收回来
这一层是可选的，但设备超过十台之后基本变成必需。
原因很直接：规模上去之后，你没法靠眼睛确认每台设备都跑对了。三十台设备同时跑，没有记录的话，你连「昨天那批任务跑完了没有」都答不上来。
需要记录三件事：哪台设备、跑了哪一步、结果是什么。
其中结果这一步，最省事的做法是让脚本在关键节点截图。截图有两个用处：一是失败时你能看到当时屏幕停在哪，二是它能作为执行过的凭证。
设备不多的时候，实时日志就够用了，边跑边看输出。设备多了之后，日志会刷得很快，这时候更需要的是「筛选」和「只看失败」。所以脚本里最好给不同结果打上不同的标记，方便后面过滤。
故障：掉线、卡死和补跑
矩阵跑到一定规模，故障是常态，不是意外。关键是有固定的处理顺序，不要每次都临时想。
第一层是掉线。先分辨是设备的问题还是链路的问题：换一根线、换一个口，如果恢复了就是线或口的问题。如果同一批设备同时掉，那更可能是集线器供电不够，把设备分到不同的控制器上试试。
第二层是脚本卡死。表现是画面还在但不动了，或者某一步一直不往下走。这种情况先看执行记录，确定卡在哪一步，再单独拿一台手动走一遍那一步，判断是脚本的问题还是页面变了。
关于批量发布的完整流程，YouTube 矩阵批量发布里有一份可以直接参考的写法。补跑的逻辑是：单台失败重试一次，连续两次不行就摘出去记下来。多台同时失败就停下来查脚本，不要继续重试。多台同时出问题，基本不可能是设备的事。
有了这三层，你基本能做到「故障不影响整体进度」。矩阵不能保证不出问题，但可以保证问题不扩散。
一套 20 台的参考配置
脚本层：一份主流程脚本 + 一份设备配置表。所有账号相关的值都在配置表里，代码里没有。 设备层：20 台同型号 iPhone，数据线直连，按「平台-市场-编号」命名，按平台和市场两级分组。 网络层：按市场准备 2 组出口，同平台账号错开使用，出口保持稳定。 数据层：脚本在关键节点截图，执行记录保留最近 30 天，失败的单独标记出来。 故障处理：单台重试一次后摘除，多台同时失败先查脚本。
这套配置可以直接照着搭。真正需要根据业务调的是配置表里的内容：账号、关键词、时段，这些跟你的生意直接相关，别人替不了。长期跑下来会遇到哪些问题，可以对照长期运行的效果与衰减来看。
最后
ios手机矩阵搭得好不好，判断标准很朴素：改一个参数，你需要动几个地方。
答案是「一个」的时候，你的矩阵是健康的。答案是「二十个」的时候，你搭的不是矩阵，是二十台互不相干的手机。
关于 EasyClick：手机自动化 AI 智能体平台，覆盖安卓免 root、iOS 免越狱、鸿蒙 Next 三大生态，提供脚本开发、苹果群控、本地中控投屏与云控系统。→ 了解全部产品
想要真实跑起来？
本文介绍的方案均可基于 EasyClick 能力在 iEasyClick 落地。官网提供完整文档、开发工具与自动化产品，免费体验。