iOS群控做小红书，图文笔记的批量发布怎么跑？

iOS群控，是指用一台电脑集中管理并批量操控多台 iPhone 的技术方案，免越狱、免签名、免硬件，靠外部输入注入驱动设备。

这篇要回答的是：iOS群控做小红书，图文笔记的批量发布怎么跑。

去年有个做家居的团队找我，说十台 iPhone 发小红书，每次发到一半就卡住。

发一条笔记，脚本走完全程也就几十秒；可要是素材没准备好，这几十秒你等一天也等不来。

小红书这条路的难点在哪

先说说它跟发视频的区别。

小红书的发布流程本身不复杂，选图、写正文、挑话题、发布，四步；麻烦的是这四个步骤全部依赖界面状态，而小红书又是一个界面元素特别密、位置经常变的 App。

iOS 这边还有个前提：读不到控件树。安卓上可以写「找到叫『发布』的按钮点它」，iPhone 上不行，只能靠图色识别、OCR 认字，或者记坐标。

这说明两件事。一是脚本对界面变化更敏感，小红书改版一次，好几处定位可能就失效了；二是同一批脚本在不同机型上表现会有差异，屏幕比例不同，坐标就不一样。

知道这两条，后面的做法就顺了。

素材怎么进到每一台手机的相册。 这是整个流程里最容易被低估的一步。

很多人第一反应是准备一套图，让十台手机发同样的内容。这条路基本走不通，同一批图、同一段时间、从多个账号发出去，平台的重复内容识别很容易把它们关联起来。十台发同一套图，平台会看不出来吗？

所以素材必须一台一套；十台设备就是十套图，每套三到九张。

那这些图怎么进到相册里？这一步通常在脚本之外完成，用电脑批量导入，或者提前把素材准备到每台设备上。脚本能覆盖的是「从相册里选图」这个动作，不是「把图放进去」这个动作，这一点先分清，不然规划的时候会算错工作量。

导入的时候有个小技巧：给每台设备的相册单独建一个相簿，命名带上设备编号；选图的时候直接进这个相簿，比在几千张图里翻要稳得多，也不会串。

正文、话题、封面怎么做到每条不一样。 素材分开之后，文案也要分开。

正文的差异化不是把同一段话改几个字。真正有用的做法是把内容拆成可替换的部分：开头的引入、正文的分点、结尾的引导，各自准备一批素材，发布时按设备取不同的组合。

话题标签同理，不要每条都挂同一组。

封面单独说一句。小红书的封面对点击率影响很大，但批量场景下最容易出的问题是所有封面长得一模一样。如果条件允许，不同设备用不同的封面图，哪怕只是换一张首图，效果也比统一封面好。

图色定位为什么会点不准。 这是 iOS 侧最实际的技术问题，值得单独讲。

图色识别靠的是「在当前画面上找到跟模板匹配的那块区域」；它有三个常见的失败原因。

一是页面还没加载完就去找。网络慢的时候，脚本已经走到下一步，界面还停在上一步，自然找不到。所以每一步之间要有等待，而且最好是「等某个特征出现」，不是死等固定秒数。

二是找到的东西不止一个。比如「发布」两个字可能在页面上出现两处，模板匹配会挑置信度最高的那个，但不一定是你要的那个。这时候要靠位置约束，限定在屏幕的上半部分或下半部分找。

三是滚动位置不固定。选择话题的时候列表位置会变，同一个话题在两台设备上的位置不一样；这类操作尽量用搜索框输入关键词再选，比在列表里滑要稳。

发布节奏怎么排。 节奏这件事，前面有一篇为什么不能都挤在同一小时讲得更细，这里只说小红书相关的两点。

第一，别在整点前后集中发。十台设备都在十点零分发出去，这个时间戳本身就是个很强的关联信号。把时间打散到各自的窗口里，每台的间隔不一样。

第二，留意各个账号自己的历史节奏。有些号原来就是晚上发的，突然改到早上，行为模式的变化比数量本身更容易被注意到。

失败之后怎么补，别整批重跑。 批量发布一定会有一部分失败，这是常态，不是脚本写得不好。

关键是失败要能被单独重试，而不是整批重来。整批重跑的代价不只是时间，还可能出现「同一批里一半发了两次」这种更难处理的情况。

做法是给每台设备的每次任务留状态：成功、失败、跳过；日志里能一眼看出哪几台没发出去，补跑的时候只挑这些设备。

如果同一台设备连续失败，先别急着重试，去看看它停在哪一步；连着三次卡在同一个位置，八成是那台设备的界面状态不对，重试一百次也没用。