一、先说一次集体触发的验证先说事故。一个做区域农产品推广的团队手上三十多个内容账号分布在不同类型的平台上。图省事他们写了个脚本把所有账号的登录态存在一起循环调用发布一晚上推出去两百多条。第二天登录七成账号被要求验证其中几个直接被限制了发布权限。事后复盘问题不在脚本写得好不好而在它把三十个身份当成了一个身份。平台看一段发布行为从来不只看单个请求它看的是这批请求之间的关系同一台机器、同一个出口、同样的节奏、同样的内容这些信号叠在一起判定就很明确。所以多平台分发这件事本质不是自动化问题是身份与节奏的编排问题。后面我们把这一层重新做了一遍拆成四件事身份隔离、节奏控制、队列调度、状态回写。二、账号隔离要隔离三层不是只换 IP很多人一提账号隔离就说换 IP这只做到三分之一。真正要隔开的是三层网络层、浏览器上下文、本地存储。网络层是出口 IP每个账号尽量走独立出口。这里有个取舍动态 IP 便宜但会跳静态 IP 稳但贵品牌类账号建议走静态跑量测试的可以动态。要注意的是别让一个账号今天走国内、明天走境外这种跳变本身就是异常信号平台侧一眼就能看出来。浏览器上下文是第二层。同一个浏览器内核里开着多个账号指纹字段会互相污染做法是每个账号给一个独立的上下文目录缓存、Cookie、本地存储各存一份互不可见。第三层是本地存储。账号凭据加密后落在本地盘不上传云端。这一层既是安全考虑也是合规考虑尤其是替客户代运营的团队数据不出本机是底线很多客户在合同里就会把这一条写进去。有人会问能不能用同一份登录态反复切换账号。答案是不行。登录态是成套的Cookie、Local Storage、Session Storage 三者互相绑定只换其中一样平台那边认不出你页面会直接跳回登录页。这也是为什么多开这件事看着简单做扎实了全是细活。三、发布间隔的语义很多人一开始都理解反了这是我们在实际项目里被问得最多的一个问题。我设了三个账号间隔三十分钟为什么三个账号是同时发出去的。答案是间隔的语义被理解反了。间隔指的是同一个账号的两篇文章之间要等多久不是账号与账号之间的间隔。A 账号发完第一篇接着发 B 账号的第一篇再发 C 账号的第一篇一轮走完回到 A 发第二篇这时候才等那个间隔。理解这一层之后参数怎么设就清楚了。间隔值不要设太大超过一千秒容易在读取配置时出问题需要跨小时、跨天的间隔应该用定时任务去做而不是把间隔值一味拉长。还有两个配套规则值得一并考虑。同一个平台的两个账号不要推同一条内容这是判重的高发区要靠记录去判断不能靠记性。每个平台的每日篇数也建议设上限一天推二十条和推三条账号的体感完全不一样。四、任务队列不能只有一条道内容生成这一侧有个特殊约束调用网页版模型的通道是单线程的同一时间只能跑一个任务。你手动关掉界面进程往往还在下一个任务一启动就报错因为上一个没真正结束。而直接调 API 的模型没有这个限制可以按额度并发。所以我们把生成任务分成两条队列。网页模型队列严格串行前一个任务状态回到完成才放出下一个中间还要留一个清理浏览器残留进程的动作。API 队列按配置的并发数并行单条失败单独重试不影响同批其他任务。这套调度逻辑我们放在一个叫 AI智能媒体助理 的桌面工具里实现。它在设计上有个判断值得借鉴不追求所有模型都支持并发而是承认不同通道的约束不一样把约束显式写进调度层。承认限制比假装没有限制工程上要稳得多。五、失败要能定位不能只报一个错批量任务最怕的不是失败是失败了不知道断在哪一步。我们要求每一次发布都落一条状态记录覆盖五个状态待发、发布中、成功、失败、需人工。失败必须带上原始错误信息而不是统一回一句操作失败。落地时有几类高频原因值得提前处理。账号掉线这一类占失败的一半以上做法是发之前先做一次登录状态体检。内容缺图有些平台必须有图片才能生成封面文章里一张图都没有就会直接被拒。形态不匹配长文推到只吃短内容的地方接口层面就会拒绝这类要在分发前就分好流。还有一类是环境问题比如某些平台依赖本机的 Node 运行环境版本太旧就跑不动流程。这类问题在日志里其实留了痕养成先看日志的习惯比在界面上反复点重试快得多。六、内容侧要配合不然调度做得再细也白搭调度做得再细内容不配合也不会有好结果。我们要求在分发前先做一次格式适配长内容的地方给详实版本短内容的地方给精简版本不要一份稿子原样推二十个地方那样既浪费位置也容易被判重。首尾的固定信息也要能自动插入比如版权声明和来源标注这类东西每篇都要加手工加一定漏。这个动作放在生成环节做完分发环节就不用再管流水线各管一段责任才清楚。放量这件事我们没有一次性做过。新账号、新平台的组合先按个位数跑三天把失败原因摸清了再放开。这套动作听着慢实际上比上线后大面积失败再回头排查要快得多。批量任务的成本从来不在跑在排查能提前避免的排查就不该让它发生。七、三个真实踩过的坑第一个代理没关。用境外的模型通道生成完内容后忘记关代理接着去发布账号的登录环境变了直接触发验证。现在我们的流程里生成和发布之间的开关是硬绑定的生成任务一结束就归位。第二个新号抢跑。新注册的账号第一篇内容往往需要人工过一下有的还要做一个图片验证的动作脚本不知道这件事直接推就失败。做法是新号的第一篇走人工流程跑通之后再放进自动队列。第三个登录方式没统一。有些平台有双重验证必须走手机验证码登录用账号密码登进去的会话很快就失效表现为发着发着就掉线而日志里只写了一句登录失败。在建号阶段把登录方式统一成验证码后面能省掉大量排查时间。八、小结把这件事拆开看无非四层身份隔离、节奏控制、队列调度、失败可查。四层里最难的不是技术是承认每个通道都有它的限制然后把这些限制一条条写进系统里而不是指望操作的人记住。这套思路在 AI智能媒体助理 里落成了具体功能独立出口、账号分组、间隔与篇数上限、发布状态回写都是这一层的实现。但更值得带走的不是工具本身是那个判断凡是能被写成规则的就不要留给人的记性去扛。