他一次买了 25 台，两周后卖掉了一半
认识一个做母婴跨境的老板，前年把设备从 5 台扩到 30 台，一次到位。
买回来第二周他就发现两个问题。一是 30 台还在同一个出口下，其中一台被限流的时候，其他台也开始出问题。二是他记不清哪台在跑哪个号了——5 台靠脑子能记住，30 台不行。
第三周他做了个决定：卖掉一半，重新按 10 台一批来过。第二批他只买了 10 台，跑稳了再进下一批。
他后来总结了一句话：钱不是花在买设备上的，是花在没准备好就买设备上的。
这篇文章就是他第二次扩张之前整理的那份清单。先回答最常被问的那句话：
「我现在 5 台跑得好好的，想加到 30 台，是不是再买 25 台就行？」
不行。因为这句话里藏着一个顺序错误：设备应该是最后才买的东西。
原因很简单。5 台规模上，很多事情你「凑合着」也能跑：共用一个网络出口、用一张表格记设备、谁看见问题谁处理。这些凑合在 5 台时几乎不产生成本，所以你不会觉得它们是问题。
但到了 30 台，同样的事情会同时爆发。而那时候，钱已经花出去了。
第一件事：网络出口，要提前分段
这是三件事里最容易被忽略的，因为它在小规模时完全没有症状。
5 台设备共用一条宽带、一个出口 IP，看起来毫无问题。但你要意识到：这个出口是这 5 台设备的共同特征。 平台侧看到的是「同一个来源下有一批行为相似的操作」。
到了 30 台还在同一个出口上，这个共同特征就变成了系统性风险——不是某台设备出问题，而是这个出口出问题时，30 台一起受影响。反过来也一样：如果某台的异常触发了对这个出口的限制，其余 29 台会陪着一起受影响。
分段的做法不用一步到位，可以按这个顺序：
- 先把出口拆成两到三条，不用一开始就做一机一 IP。哪怕只是分成「A 组走线路一、B 组走线路二」，也已经把风险从「全批同时受影响」降到「一半受影响」。
- 按业务用途分组，而不是随机分。 同一批干同样活的设备放在同一个出口下，出问题时你能快速判断是「这批的业务有问题」还是「这条线路有问题」。
- 留一段备用出口。 处置事故时最怕的是「只能全停」，有备用线路，你才能做分批恢复。
具体的独立 IP 怎么配，站内有一篇专门讲：iOS 手机群控工具批量操作手机配置独立 IP 的三种方案。
第二件事：管理方式，从手工记账换成系统管
5 台设备，你用一张表格记、脑子里清楚每台在跑什么，这是合理的。30 台还这么干就不行了，因为手工管理的成本不是随数量线性增长的，而是随「同时变化的事情数量」增长的。
要落实的是三件事：
设备要有稳定的编号和别名。 不能是「那台白色的」「左边第二台」。编号要能和物理位置对应上，别名要能说明用途。听起来是小细节，但故障处置时，「哪台出问题了」这一句话说不清楚，后面全是浪费。
任务要有集中的下发入口。 一台台点的方式在 5 台时没问题，30 台时你连「今天哪些任务还没下发」都说不清。集中下发还带来一个好处：任务和设备的对应关系是记录下来的，不是靠回忆。
执行结果要能统一回收。 这是最容易被忽略的一条。30 台设备跑完之后，如果结果散在 30 个地方，那你实际上没有可用的信息——出问题的时候，你连「这次跑成功了多少台」都要一台台数。
集中下发和统一回收，靠的是同一套东西：设备分组 + 任务面板。分组决定了你能一次管多少台，任务面板决定了你能一次看到多少台的结果。
这三件事要在设备到货之前就搭好。 等 30 台插上架子再开始整理，会是一个非常漫长的过程，而且是边跑业务边整理。
第三件事：人，比设备数量更关键
这一条最不像技术问题，但它决定了扩张之后稳不稳。
5 台的时候，「谁看见问题谁处理」是能凑合的。30 台就不行了，会出现两种典型状况：
- 同一类问题在不同人手上重复处理。没人负责根因，于是同一个故障每周被处理三次，每次都是临时措施。
- 出问题时没人能决策。比如需要临时停掉一批设备，一线的人不敢停，负责人不在——时间就耗在等确认上。
所以扩张之前，把人这一环定下来，至少明确三件事：
| 角色 | 负责什么 | 判断标准 |
|---|---|---|
| 日常运维 | 每天看设备状态、跑常规任务、处理小异常 | 有固定节奏，不需要别人催 |
| 异常处理 | 接到告警后判断影响面、按流程处置 | 能在没有负责人在场时动手 |
| 决策 | 决定扩不扩、停不停、换不换 | 只在需要拍板的时候出现 |
关键不是要配三个人，而是要明确每一类事情归谁。一个人同时担三个角色完全可以，但边界要清楚——不然出事的时候，他既在判断又在动手，很容易两头都做不好。
三个常见的扩张节奏错误
第一，一次到位。 直接从 5 台跳到 30 台，看起来省事，实际后果是：一旦出问题，你分不清是新设备的问题、新网络的问题，还是新流程的问题。变量太多，没法归因。
第二，设备和账号同时扩。 新设备配新账号，一起铺上去。出问题时最需要的那组「对照」就没有了——你手上没有任何一组稳定的老设备加老账号可以比对。稳妥的做法是先扩设备（用现有账号），跑稳了再扩账号。
第三，拿新设备跑没验证过的流程。 新设备上跑新流程，同样是在混合变量。新流程应该先在已经跑稳的老设备上验证过。
三条错误的共同点是同一件事：一次只动一个变量。 分两到三批扩张，每批只改一个维度，这是最省事的做法，因为它能让归因变得可能。
怎么判断现在该不该扩
不是所有「想扩」都该扩。三个信号都成立，才值得动手：
- 现有设备已经长期跑满，不是偶尔忙，是持续满负荷。
- 任务有明确排期在等设备，也就是需求是具体的、可描述的，不是泛指「业务会增长」。
- 增长是确定的而不是预期的。如果你只是觉得「以后可能会需要」，那属于备货，不属于扩容。
备货和扩容是两件事。备货可以买在价格合适的时候——但买了放架子上等业务，设备本身也在贬值、电池也在衰减。这笔账要算清楚：苹果群控成本到底多少。
最后
回到那位老板。他第二次扩到 30 台花了三个月，中间没有再卖过一次设备。他说这次的过程「没什么可讲的」——而这恰恰是最好的评价。
扩张这件事，真正难的不是买设备，是在设备到货之前把承载它的那套东西准备好。
网络分了段、管理方式换成了系统管、人明确了，30 台和 5 台在感受上的差别，其实没有你想的那么大。反过来，这三件没补就上设备，30 台会比你预想的乱得多——而且是在花完钱之后才发现的。
人力这块的账怎么算，可以接着看苹果群控到底能省多少人力。
关于 EasyClick：手机自动化 AI 智能体平台，覆盖安卓免 root、iOS 免越狱、鸿蒙 Next 三大生态，提供脚本开发、苹果群控、本地中控投屏与云控系统。→ 了解全部产品
想要真实跑起来？
本文介绍的方案均可在 EasyClick 手机自动化平台落地。官网提供完整文档、开发工具与群控云控产品，免费体验。