防封的本事，在节奏和形态上

01  /  先纠一个误解

防封不是开关，是一组概率的调整

很多人问的是同一个问题：用了这个会不会被封。诚实的回答是没有人能保证不封，包括手工发的人。平台判断的是一串行为特征，不是某个软件的名字。所以防封不是找一个安全的工具，而是把你账号的行为形态调整到接近正常卖家的范围里，让误判的概率足够低。

由此有三个推论，后面的做法都从这里来。

下面几节按可控程度排序：节奏最容易控，指纹去重次之，操作层的拟人化再次，设备与账号的隔离是基础条件。每一节都给具体取值，取值来自系统当前实际在用的参数，不是建议值。整体框架可以对照防封控那一页看，那边讲模块关系，这里讲具体怎么做。

有一件事要先摆明：这页讲的是把行为调回正常范围，不是教怎么钻规则的空子。凡是需要靠不断试探平台边界才能维持的做法，都不具备可持续性，也不在这套系统的设计范围内。

判断自己的风险水位，有一个朴素的问法：把过去一周的行为摊开，如果换成一个人来看，会不会觉得这个店铺是有人在认真打理的。会，说明形态没问题；如果特征是"同一个时间点、同一批图、同一个模子"，那不用等平台判断，自己就能看出问题。

02  /  节奏

节奏：五个数字定住每天的形态

节奏是最容易被忽略、也最容易出问题的一项。内容是好的，但一天发四十条，形态本身就是异常。系统里的节奏参数是下面五个，取值可直接照用。

这五个数字要一起看，不能只看一个。每天发六条、全挤在上午十点到十二点，虽然日总量没超，但两小时内六条属于密集；反过来，一天两条但每周七天不间断、间隔精确到分，也属于异常。判断标准是整体像不像一个真人在打理店铺。

抖动怎么做：在最小间隔上加一个随机量，让相邻两条的间隔每次都不一样。不要用固定间隔加固定偏移，那还是规律。抖动范围不必很大，关键是让它不可预测。系统的节奏控制在发布节奏控制里实现，配置项就是上面这五个参数。

还有一个容易忘的点：改价、改描述、下架重发这些动作也占节奏。很多人只算发布，一天发八条没问题，但同时改了二十次价，行为总量还是超的。所有写操作都应该在同一套节奏里排队，而不是只给发布限速。

周上限这一项要多说一句。日上限管的是当天的密度，周上限管的是账号的性质。一个账号每天发五条、连发七天，一周三十五条，日维度看每一条都不多，周维度看就是个批量铺货的账号。这两个维度必须同时限，只限一个等于留了个大口子。

节奏定完之后不要频繁改。一周之内改了三次条数，等于人为制造了一组不规则的数据，之后看台账既判断不出是节奏变了还是账号变了。要调就一次调到位，然后至少跑满一周再看结论。

03  /  指纹与分散

商品指纹：四条链接不能长成一个样

同一件商品发多条链接是常见做法，但多条链接之间的差异必须是真的。系统用商品指纹做两件事：一是去重，避免同一条内容重复提交；二是算分散度，看多条链接是不是过于相像。

指纹由标题、描述、价格等要素算出。它的用途不止防重，还决定了下游的相似度判断和台账反查。标题里必须带够可识别的信息——品类、规格、成色，否则算出来的指纹全是噪声，同款链接会互相撞车，撞了之后你还得人工分辨哪条是哪条。

具体条数上有两条硬线：同款链接不超过 3 条，单链接图片 3–9 张。前者控制同款密度，后者是商品页的基本完整性——图太少信息不够，图太多重点不清，两个方向都不好。

差异要落在买家真能用上的信息里。价格档位不同就改配置，成色不同就改瑕疵描述，配件不同就改包含物。只调词序、换近义词，属于形式差异，过不了分散度检查，也不解决实际问题。买家看到两条措辞不同内容相同的链接，只会觉得重复。这部分与商品合规检查是两条独立的判断，一条看措辞合规，一条看形态分散，都要过。

指纹还有一个用途容易被忽略：反查。事后发现某条商品有问题时，用指纹可以在台账里找到同一批次的所有记录，一次处理干净。如果标题里只有一句情绪化的短语，反查就失效了，你只能一条条翻。所以标题写得具体，不只是给买家看的，也是给自己留的检索线索。

分散度检查看四项：类目、时间、标题、主图。四项同时异常是最坏的情况，只有一项异常通常只是提醒。实际执行时按"先拆时间、再换主图、最后动标题"的顺序调整，前三项调整成本低，动标题会影响已经积累的检索权重。

去重的判断要放在提交之前，不要放在提交之后。提交之后再发现重复，处理方式是删一条，这一删一发的动作本身也是行为。前置判断的成本是几行代码，后置处理的成本是一次多余的写操作。

04  /  操作层

操作层：四个参数让点击不像机器

节奏管的是发多少、什么时候发；操作层管的是每一次点击长什么样。人点屏幕有一个特点：间距不均匀、落点不精确、按压有长短。这三件事都可以参数化。

这四个参数的意义在于去规律化。机器操作最容易被识别的不是快，而是准和稳：每次都点正中心、每次间隔都一样、每次按压都是零毫秒。把这三样打散，点击序列就和人力操作没有统计上的区别。

落点偏移要受控件边界约束。控件本身只有二十像素宽的时候，还偏四像素就可能点到外面去，这时候要按控件尺寸收缩偏移量。这是实现细节，但它决定了偏移参数是不是安全：偏移的目的是不精确，不是点错。

还有两条与参数无关的操作习惯。第一，不要在同一屏反复来回点。人的操作是有方向的，从列表进详情再返回，路径清楚；机器容易在同一个位置反复试探。第二，遇到加载慢要等，不要连点。连点是典型的急躁特征，人也会连点，但不会每次都连点五次。这两个习惯靠流程结构解决，不是靠参数。

操作层调好之后，注意力和网络波动带来的随机失败会明显减少，因为点击落点稳了、等待有上限了。这部分在手机 APP 自动化通道里有实现层面的说明。

参数不要调得太极端。间隔调到三秒以上，一条商品要跑十来分钟，批量时排不开，而且慢到不自然；落点偏移调到十几像素，就开始点不中控件了。参数的意义是去掉规律，不是制造新的异常。改成更慢更偏，反而引入新特征。

这四个参数还有一个前提：页面加载得稳定。页面还在加载就点，落点再准也没用。所以等待要按条件等而不是按固定时间等，等控件出现再操作，最多等一个上限，超时就判失败重来。一条流程里固定等待越多，整体耗时越不可控。

参数是否生效要验证，不能假设。验证方式很直接：跑一条流程，把每一次点击的时间戳和坐标记下来，看间隔是否落在设定区间、落点是否在控件范围内随机分布。间隔全一样、落点全在中心，说明参数没接上，这种情况在实现里很常见，因为默认值会在某处被覆盖。

05  /  设备隔离

设备与账号：一对一是最省心的结构

一台设备固定登录一个账号，这是最省心也最容易维持的结构。反过来做的成本很高：两台设备轮流登同一个号，平台看到的是登录设备在变；一台设备上频繁切换账号，看到的是同设备多账号。两种形态都不像个人卖家。

设备侧的几件事要在开工前定死。

• 一机一号设备与账号绑定，不交叉使用。换设备要走正常换机流程，不要直接登
• 端口不冲突uiautomator2 一个进程只绑一个 adb server 端口，多设备要给端口加锁，否则第二个进程会抢掉第一个的连接
• 驱动跑在 Windows 侧WSL 到 Windows 的 TCP 不通，从 Linux 侧连会一直超时，看着像设备离线
• 环境固定关掉自动锁屏、折叠通知、停掉系统更新自动下载，避免跑批中途被打断
• 网络稳定设备与执行机在同一网络下，不要中途切网，IP 频繁变化本身也是特征
• 同网设备数量同一出口下不要挂过多设备，密度过高时行为特征会互相叠加

多设备并行的时候，最容易出问题的是槽位归属。同一份发布计划里，哪条走哪台设备、哪个账号，这个归属应该是算出来的，不是手工标记的——手工标记会在任务重排之后失效，出现两条任务抢同一台设备，或者一台设备同时跑两条流程。系统里这个归属由同一个函数对象计算，两条通道用的是同一套算法。

设备数量不是越多越好。三台设备各跑一个账号，比一台设备三个账号稳；十台设备同时跑，如果出口网络是同一个，整体行为密度反而更显眼。加设备的判断依据是账号数，不是想发的条数——想多发货，先加账号，账号够用了再加设备。多设备的管理方式见多设备并行管理。

换机也要按规矩来。设备坏了要换，先在旧设备上退出登录，再在新设备上登录，隔一段时间再恢复发布。不要旧设备还没退、新设备已经登上去发了几条，这种重叠在设备维度看就是异常。换机当天按最低节奏跑，观察一天再恢复。

最后一条容易被忽略：设备的时间和时区。设备时间偏了几分钟，发布记录的落点就会漂，与计划窗口对不上；时区错了更麻烦，你以为在发白天，平台看来是凌晨。开工前对一次时间，是成本最低的一项检查。

06  /  外部状态

平台健康闸：该停就停，不停才是风险

前面几节讲的都是你能控的部分，这一节讲你控不了的部分：平台侧的状态。平台侧出现异常时，系统的做法是暂停发布，不硬发。

这条规则看起来消极，实际上是防封里性价比最高的一条。硬发的代价是连续多条失败记录加一段异常行为，而等待的代价只是半小时到几小时的进度。进度可以补，记录补不回来。

恢复之后的处理有一个常见错误：把暂停期间没发的量一次性补上。这等于在恢复的第一时间制造一次密集发布，比暂停前的行为更异常。正确做法是恢复到正常节奏，欠的量摊到后面几天，或者直接放弃——少发几条的损失远小于再被拦一次。

判断平台是否恢复，不要靠感觉，要靠一次真实提交。先发一条，确认链路通、回执正常、商品可见，再恢复到日常条数。这一条既是测试也是校准，能同时验证账号状态与页面结构。

还有一条边界：平台健康闸只在系统里生效，手工发不受它管。所以暂停期间最该克制的就是手工补发。看到系统停了就自己去点几条，等于绕过了唯一的保护。

暂停要给个明确的恢复判据，否则会变成凭心情恢复。可用的判据有三条：账号能正常登录且没有新的提示；用一条测试商品提交能拿到正常回执；商品页能正常打开且信息正确。三条都成立才恢复，缺一条就继续等。这些判据写进流程里，比记在脑子里可靠。

如果暂停超过一天还没有恢复，就不要继续等，按上一节的处置顺序走：先取证，再分类。有些限制是静默的，等你发现时已经过了最佳处理时间。

暂停期间最好给账号一点正常活动：不要密集刷新自己的商品页看状态，也不要反复退出重登。看状态用一次就够，看十次和看一次得到的信息一样，但留下的行为不一样。需要观察变化，交给监控去做，人不要手动刷。

这一节的三条判据和前面的五个节奏参数，构成了防封的日常部分。日常做到位，异常处理就不会频繁发生；日常做不到位，异常处理做得再好也只是补救。日常的成本是每天二十分钟，补救的成本是几周。这笔账算清楚了，就知道该把力气花在哪一头。先把这份账算完，再决定要不要加设备、要不要加账号。这一步想清楚，后面所有参数才有意义。

07  /  处置顺序

真出问题时：按这个顺序处理，不要乱试

账号出现限制、商品被下架、发布被拒，这三种情况处理顺序不一样。顺序错了会放大损失，尤其是反复登录、反复申诉这类动作。

有几件事在任何阶段都不要做：反复登录同一个账号去试探状态；短时间内多次提交申诉；用另一个账号发同样的内容验证是不是内容问题；把同一批素材换个账号重发。这四个动作都会把单账号的问题扩散成多账号的问题。

内容类问题建议先去商品合规检查把规则过一遍，很多所谓的行为问题其实是措辞问题引发的连锁反应。行为类问题回到防封控看模块层面的规则，确认是节奏、指纹还是操作层。

如果处理完还是反复出现同类问题，说明触发条件没找到。这时候不要再加大试错频率，把范围缩小：只发一条、只用一个类目、只用最简单的描述，看还出不出现问题。范围缩到最小还出问题，那问题多半在账号本身，不在流程。

取证有一个细节：把失败那一条的完整字段存下来，包括你提交的标题、描述、价格、类目，以及平台回显的内容。两边并排看，才能看出是平台改写了你的字段，还是你提交的就是错的。只留一边，事后无法判断。

处置过程中要有人盯时间。停多久、什么时候试探、试探几次，都提前定好，不要边处理边决定。没有时间约束的处置，最后会变成反复试探，而反复试探正是最该避免的动作。

08  /  复盘

把每次异常写回规则，而不是记在心里

防封这件事，一次处理完不算完，要让它变成规则的一部分。否则同样的问题过两个月会再来一次，而你还要重新判断一遍。

复盘要产出三样东西：触发条件的描述、新增或修改的规则、验证这条规则的方法。三样都写了才算复盘完成，只写一句"以后注意"等于没写。

复盘记录建议和台账放在一起。台账里有每一条的时间、标题、价格、类目，复盘时可以直接回看那段时间的分布，不用凭记忆还原。台账的字段与用法见发布数据台账。

最后，防封的日常工作量其实很小：每天看一次台账、每周看一次分布、异常时按清单处理。真正花时间的是出事之后的恢复，而恢复的时间长短，取决于你之前有没有把规则写下来。规则在纸上，恢复是按部就班；规则在脑子里，恢复就是重新摸索一遍。

复盘还有一个副产品：你会知道自己账号的边界在哪。每个账号的历史、类目、粉丝都不一样，能承受的节奏也不同，这些差异只能从自己的记录里看出来，别人的参数只能当起点。

如果暂时没有异常可复盘，就做定期体检：把最近两周的台账拿出来，看分布在四项上有没有偏移。类目集中度升高、时间挤到同一段、同款条数逼近上限，任何一项开始偏，就提前减速。这种主动调整比出事之后补救便宜得多，也是发布监控告警里每天要看的东西。