
# 安全地扩展 WhatsApp 外联规模

一份从每月 0 条消息扩展到 30,000+ 条消息且不被封号的实战指南。


## 每月 3 万条消息是什么样子的

运行此指南的账户通常每月会超过 **30,000 条 WhatsApp 消息**。典型的分配比例为：约 23,000 条外发消息和 10,000 条接收消息，覆盖 400–500 个联系人；同时保留一个 WhatsApp Business API 号码作为备份，专门用于向新联系人发起冷外联。

达到这一规模并非一蹴而就。最常见的失败模式也是代价最昂贵的：连接一个拥有真实历史记录的 WhatsApp Business 号码，将其线性扩展 60 天以上，然后——在达到每天约 **1,000 条消息**时——Meta 会将其封禁。没有警告，无法申诉，无法恢复。号码直接作废。

本指南中描述的几乎所有保障措施都是为了防止这种模式反复出现。从这些封禁案例中提炼出的原则如下：

- 切勿将所有流量集中在一个号码上。
- 使用路由层，确保每次新的点击都能分配到剩余容量最大的号码。
- 将全新的号码视为脆弱资源，并缓慢提升其发送量。
- 避免使用那些会悄悄带来全账户风险的“官方” Meta 解决方案。

如果您计划发送接近此规模的消息，请在连接第一个号码之前阅读本页全文。下方的“新号规则”是此列表中代价最昂贵的教训。

## 一段话概括策略

连接 **多个 WhatsApp Web 号码** 而不是一个。每个新号码都要经过 **60 天的预热期**，逐步解锁每天更多的消息发送量和新联系人额度。短链接路由器会自动将新的点击引导至剩余容量最大的已连接号码，并在 **号码达到其每日上限的 50% 后停止向其发送新联系人**，以确保现有对话能够持续进行。**跟进消息是随机发送的，并遵循静默时间**，这样自动化检测系统就无法通过时间规律进行匹配。对于实际的外发消息，推荐的风险分担模式是：**使用 WhatsApp Business API 向新联系人发起冷外联**（并在 Web 号码需要休息时作为备份），而 **WhatsApp Web 则承担大部分的接收、跟进和持续对话**。这就是整个系统。

***

## 新号规则（请先阅读）

> **最重要的规则：** 切勿连接从未接收过 WhatsApp 消息的 SIM 卡。如果您将一个全新的、从未被触碰过的号码放入应用程序并立即发送外发消息，您将面临永久封号。通常在几分钟内就会发生。且无法申诉。

这是几乎每个人都会掉入的陷阱。原因很简单——Meta 将接收消息的活动视为“这是一个真实用户”的最强信号之一。一个没有任何接收历史的 WhatsApp 账户如果开始大量发送消息，看起来就像一个垃圾邮件农场，因为从统计学上讲，垃圾邮件农场就是这么做的。

解决方法很简单：

1. 将 SIM 卡放入任何安装了 WhatsApp 的手机中。
2. 用您的个人手机给该号码发送三到五次短信。内容随意。
3. 让朋友或家人也给它发一两次短信。
4. 如果可以，让它静置过夜。
5. **然后**通过 [WhatsApp Web](whatsapp-web.md) 将其连接到应用程序。

只需少量真实的入站消息即可。在此阶段，您无需亲自“预热”号码——您只需向 Meta 证明该号码真实存在且有人与其互动。此后，平台会自动处理实际的预热曲线。

> **注意：** 此规则同样适用于已使用数周的号码。如果 SIM 卡在手机上处于活跃状态，但从未接收过 WhatsApp 消息，那么从 WhatsApp 的角度来看，它仍然是一个“新”号码。计时从有人首次向该号码发送 WhatsApp 消息时开始，而不是从 SIM 卡激活时开始。

***

## 预热的工作原理

您连接的每个 WhatsApp Web 号码都会经历一个自动**爬坡（ramp）**过程。该爬坡过程会跟踪“合格天数”——即号码实际发送量至少达到当前每日上限 75% 的天数。空闲天数不计入在内。这意味着平台不会被欺骗，从而让一个未在实际使用中证明过自己的号码通过预热。

**您在手机上手动输入的消息也算在内。** 它们不会出现在每日计量中（这些计量仅跟踪通过平台发送的消息），但它们确实计入符合条件的日期。这是刻意为之的：承载真实人类对话的号码正是 WhatsApp 所信任的号码，因此这些活动有助于推进预热过程。一个全新的、未使用的号码也没有手动输入的流量，因此它仍然会受到限制。

该公式是线性的：

- **每日消息上限** = `50 + 8 × (day − 1)`，上限为 **500 条消息/天**。
- **每日新联系人上限** = `floor((day − 1) × 5 / 6)`（向下取整），上限为 **50 个新联系人/天**。

消息上限在 **第 58 天** 达到，新联系人上限在 **第 61 天** 达到。在此之前，该号码会被有意限流。

请注意该公式在**第 1 天的含义：新联系人上限为 0**。您今天连接的号码可以回复任何写信给它的人，但不能与从未聊天过的人发起对话——首次触达发送（营销活动消息、自动化流程中的*发送 WhatsApp Web 消息*步骤、API 发送）会失败并显示 `Daily limit of 0 new contacts reached`。这是平台的预热机制，而非 WhatsApp 的封禁，随着号码积累合规天数，该限制会自动解除。如果该号码已经有实际的历史记录，请使用下方的**提高每日限额**，而不是等待；如果该号码仅用于*接收*信息（例如接收预订报告的经理手机），则完全不必将其作为渠道连接，只需使用已经预热的号码向其发送消息即可。

曲线上的几个示例点：

| 合格天数 | 每日消息量 | 每日新联系人 |
| -------------- | -------------- | ---------------- |
| 1              | 50             | 0                |
| 7              | 98             | 5                |
| 14             | 154            | 10               |
| 21             | 210            | 16               |
| 33             | 306            | 26               |
| 45             | 402            | 36               |
| 58             | 500            | 47               |
| 61             | 500            | 50               |

因此，对于一个有真实使用记录的号码，在第 33 天时，您可以每天发送约 300 条消息并开启约 26 个新对话。到了第 58 天，您就达到了自动爬坡的上限：500 条消息，47 个新联系人。

### “我知道该号码已有使用历史”的覆盖设置

有时，您连接的号码**已经**拥有数月的 WhatsApp 自然使用记录——比如您的个人号码、您一直用于支持的号码，或者一个已经有 6 个月双向聊天记录的号码。让这样的号码从预热的第一天开始是不合理的。在**渠道**页面（**设置 → 渠道 → 渠道**）上，WhatsApp Web 号码的**发送限制与预热**仪表盘中有一个**提高每日限额**操作，点击后会打开一个包含预热天数滑块的面板。如果您将一个有真实使用历史的号码的滑块设置为第 33 天，平台就会将其视为已经完成了 33 天预热的号码——因此上限会立即提升至第 33 天的水平：每天约 306 条消息和 26 个新联系人（请参阅[预热工作原理](#how-warm-up-works)下的预热表）。


请诚实地使用此滑块。如果该号码**没有**历史记录，请勿更改。设置爬坡过程是因为 Meta 在其后端执行相同的计算。如果在一个不符合条件的号码上跳过此过程，您将直接回到每天 1,000 条消息的封禁边缘。

### 超过爬坡期的手动覆盖

当号码完成完整的 58 天预热期后，同一面板会提供第二个覆盖选项，允许您将每日消息上限**提高**至 500 以上，最高可达 5,000 条。该选项从 750 条/天开始，并以 250 条为步长递增。

Meta 官方并没有关于此处安全限额的明确数字。上限需要通过反复试验来确定：保持滑块设置保守，留意“受限”状态（请参阅[“受限”的实际含义](#what-restricted-actually-means)），一旦发现该状态请立即调低限额。对于一个已完全预热且信号良好的号码，**每天 750–1,250 条消息**是一个许多高容量账户都能稳定运行的可行范围——但每个账户都有其自身的风险状况，您的号码与他人的号码并不相同。

::: tip
**提示：** 预热期后的覆盖选项**仅**适用于已实际完成 58 天预热期的号码。平台不允许新号码通过在第 1 天设置覆盖选项来跳过预热。这是刻意设计的。
:::


### 查看号码实际发送的情况

每个已连接的渠道——以及每个独立的 WhatsApp 号码——都在同一个“渠道”页面上拥有自己的**发送量**图表：一条显示过去 30 天内每天发送消息数量的小型折线图，旁边标有总数。对于 WhatsApp Web 号码，该图表直接位于该号码行的下方，紧邻其“发送限制与预热”指标，因此您可以核实该号码的实际每日输出量是否在逐渐攀升而非激增——这正是预热旨在产生的形态。将鼠标悬停在图表上可查看某一天的具体计数，点击其标题可将其展开为完整的性能视图——按天显示该渠道或号码的发送、送达、已读、回复和新联系人数据（与仪表板为您整个账户显示的图表相同）。当渠道或号码在过去 30 天内至少发送过一条消息时，该图表才会显示。


***

## 设置多个号码

一旦您的第一个号码开始预热，请**连接至少一个额外的号码**。对于任何实际的外呼量，两个号码是最低配置；四个号码可以轻松应对每月约 3 万条的消息量。

您可以在 **设置 → 渠道 → 渠道** 中的 **WhatsApp Web** 卡片处连接每个新号码——配对流程相同，且每个号码都遵循相同的新号码规则。每个号码都会显示其各自的连接状态、当前预热天数、今日使用量以及每个号码独立的**自动跟进**开关（下文将详细说明）。


“为什么要这样做”的原因很简单：风险分散。如果一个号码受到限制，其他号码可以吸收流量，确保您的外呼工作不会中断。如果您只有一个号码，一旦被封禁，您将面临一整天零流量的窘境，同时还要手忙脚乱地准备替代号码。

::: tip
**提示：** 错开连接新号码的时间。如果您在同一天将四个全新的号码放入平台，它们都会达到第 1 天的上限（每号 50 条，总计 200 条），并且它们会同时完成预热。间隔一两周连接它们，可以确保当下一个号码正在预热时，您的“最高级别”号码始终在产出流量。
:::


### 你到底需要多少部手机？

四个号码并**不**意味着需要四部手机。一部现代手机无需特殊设置即可容纳**三个 WhatsApp 号码**：

- **常规 WhatsApp 应用中的两个号码。** WhatsApp 支持同时登录两个账号，并允许你在两者之间切换（Android 自 2023 年起，iPhone 自 2026 年起）。
- **WhatsApp Business 应用中的一个号码。** 这是一个拥有独立账号的单独应用，因此它可以与上述两个账号并存。

真正的限制在于 SIM 卡，而非应用：**每个号码仍需其专属的 SIM 卡或 eSIM**，因此支持双卡或 eSIM 的手机才是实现这一点的关键。因此，四个号码完全可以轻松地放在两部手机上。

两部手机也比一部手机更好。手机上的每个号码都与该手机的命运绑定在一起——如果手机丢失、被抹除或恢复出厂设置，上面的所有账号会同时解除关联，而这正是本指南旨在避免的风险集中问题。

我们**不**建议采取以下做法：

- **WhatsApp 克隆应用。** 它们确实能让你在单台设备上堆叠更多账号，但它们超出了 WhatsApp 官方支持的范围，并且会为你试图保护的号码增加被封禁的风险。
- **模拟器和远程/虚拟设备设置。** 请坚持使用普通手机和真实的 SIM 卡。

### 手机无需时刻照看

一个常见的担忧是每隔几周就需要重新配对会话。其实不需要。会话在我们的服务器上运行，因此配对后的手机可以放在抽屉里，处于休眠或关机状态，而消息仍会持续传输。

唯一的要求是**手机至少每 14 天联网一次**——如果超过这个时间，WhatsApp 会解除所有已关联设备的连接。只需在手机上打开一次 WhatsApp 即可，无需重新扫描二维码。

如果你发现自己连接断开的频率高于上述情况，通常是以下两个原因之一：

- **配对过程中 WhatsApp 有时会增加的密钥（passkey）步骤**——请参阅 [连接有问题？使用浏览器扩展程序](whatsapp-web.md#trouble-connecting-use-the-browser-extension)。
- **在浏览器中保持打开了 web.whatsapp.com**，且使用了相同的号码，这会运行一个竞争会话并悄悄使我们的会话下线。

***

## 短链接路由

点击量在多个号码之间分配的方式是通过短链接系统实现的。当您发送包含链接的广播时，平台会创建一个指向您所有已连接号码的单一短 URL，而不是指向某个特定号码。每次点击都会到达重定向器，重定向器会为**该次**点击选择最佳号码，并将用户重定向（一种标准的、即时的 Web 重定向，称为“302”）到 `wa.me/<that-number>`。

用通俗易懂的语言解释选择逻辑：

1. **剔除任何离线、被封禁或处于“禁止”状态的号码。** 向无法回复的号码发送点击请求毫无意义。
2. **在仍然可路由的 WhatsApp Web 号码中，优先选择每日上限使用率低于 50% 最多的号码。** 它比较的是百分比（而非剩余绝对值），因此一个已使用 20% 的 500 条/天上限的号码，不会持续抢占一个已使用 10% 的 250 条/天上限号码的流量。
3. **如果所有 WhatsApp Web 号码的使用率都达到或超过 50%，则回退到 WhatsApp Business API 号码（如果您已连接）。** Business API 在我们这边没有追踪上限，因为 Meta 在服务器端执行其自身的限制。
4. **如果没有 Business API，则选择负载最低的 WhatsApp Web 号码作为溢出处理**，而不是丢弃该次点击。

50% 的截止点是刻意设置的。每日上限计算的是**所有**外呼消息，而不仅仅是首次触达。您今天开启的每一个新联系人明天和后天都会继续回复，这些跟进消息也会消耗同样的每日上限。如果我们允许新点击路由到 100% 的上限，您现有的对话就会耗尽额度。50% 的截止点为正在进行的对话留出了上限的后半部分。

请参阅“设置”中的“短链接”以了解如何进行配置。


***

## 外发广播发送节奏

当您以 WhatsApp Web 作为渠道启动**外发**广播（或传统的营销活动）时，平台会将每条消息的发送间隔随机设置为 **30–90 秒**，且针对每个联系人独立计算。发送给 34 位联系人的任务大约会在 25 分钟内完成，而不是一次性发出。发送给 100 位联系人的任务则大约需要一小时。

此机制为强制执行，无法关闭。从单个号码短时间内爆发式发送数十条首触消息是导致该号码被限制的最快途径，而这种逐条发送的节奏无论发送规模大小或号码新旧，都能有效规避此类风险。

如果您在发送过程中**暂停**任务，所有待发送的消息都将被取消。当您**恢复**任务时，剩余的联系人将从恢复的那一刻起，按照同样的 30–90 秒节奏继续发送，而不是从最初的启动时间计算。因此，如果您在发送 12 位联系人后暂停，并在三天后恢复，剩余的 22 位联系人将从那一刻起在接下来的约 25 分钟内发送完毕。

通过官方 WhatsApp Business API 进行的发送不受影响 — Twilio 管理的号码不存在与配对 WhatsApp Web 号码相同的封号风险，因此它们继续保持之前的批量发送行为。

***

## 自动发送保护

有些意外在为时已晚之前看起来并不像意外。最明显的例子是：一个闲置了数月的广播被暂停后又恢复，它没有从上次中断的地方继续，而是开始向你一直保持聊天的用户发送**开场消息**。从外部来看，这看起来就像机器人向联系人列表发送垃圾信息——这也是导致号码被封的最快方式之一。

平台现在会在每次发送时监控这种情况，并将其拦截。

**触发条件**

- 你的开场消息开始发送给那些**已经通过同一广播或活动与你进行对话**的人。开场消息旨在发给尚未联系过的人，因此向正在对话中的人发送开场消息是一个强烈的异常信号。
- **发送速度突然远超你平时的节奏**——在一小时内发送的开场消息数量远超该账户以往任何一小时的发送量。这种情况只会向我们发出警报，而不会停止你的发送，因为首次启动时的流量确实会比账户历史记录更繁忙。

**发生的情况**

- 发送立即暂停。该广播或活动不会再有任何消息发出，排在其后的任何消息都会被取消。
- 你会收到一条通知，告知你什么被暂停了以及原因。
- 我们的团队会同时收到警报，因此如果你需要第二双眼睛查看，我们可以与你一起检查。

**如何继续**

1. 打开已暂停的广播或活动。
2. 检查联系人列表和开场消息——特别是即将接收消息的人是否是你已经联系过的人。
3. 如果一切看起来没问题，点击**恢复**。

点击恢复即表示你确认这是你的意图：保护机制将在接下来的 **24 小时**内对该广播解除限制，以免陷入循环暂停。24 小时后，它将恢复监控。

如果这不是你的本意，请在恢复前修复联系人列表——保护机制已经完成了它的工作，原本可能被封禁的号码现在依然安全。

***

## 后续跟进是导致封号的主因

导致封号且最可预防的原因是鲁莽的后续跟进。具体表现为：

- **整点定时调度。** 多年前，如果后续跟进设置为“6 小时后”，每位联系人都会在刚好 6 小时整点收到消息。每条跟进消息都在同一分钟、同一秒钟送达。自动化滥用检测系统专门识别此类模式 — 同一个号码每天在同一分钟内发出五条消息，这看起来就像是机器人行为。**平台现在会为每条定时消息增加最多 15 分钟的随机延迟**，因此发送时间模式不再完全一致。
- **深夜发送。** 即使 AI 设置为 24/7 全天候工作，如果在联系人当地时间的凌晨 3 点发送跟进消息，您很可能会被举报。在多个联系人中重复进行凌晨 3 点的跟进会导致您被封号。
- **美国地区的周日批量发送。** 联邦 TCPA（限制未经请求短信的美国法律）的预期以及佛罗里达州的 FTSA（类似的佛罗里达州法律）规定，在周日向美国号码进行外联是导致投诉和账户受损的诱因。

### 免打扰时段

1. 打开 **设置 → 个人资料**。
2. 滚动至 **后续跟进时间** 部分。
3. 开启 **遵守免打扰时段**。


该时间窗口为 **联系人当地时间的 08:00 至 20:00**：

- 原定于联系人当地时间 08:00 之前送达的跟进消息将被推迟至 08:00（加上几分钟的随机延迟）。
- 原定于 20:00 或之后送达的跟进消息将被推迟至次日 08:00。
- 平台会根据联系人的电话号码解析其时区，因此即使您没有每位联系人的明确时区数据，此功能也能正常工作。

在其下方，**美国严格模式（周日不发送）** 会在每日 08:00–20:00 的窗口基础上，为美国联系人增加全天周日屏蔽。如果您在美国有较大的发送量，请务必开启此项。

### 每个号码的独立终止开关

在 **Channels**（渠道）页面上，每个已连接的 WhatsApp Web 号码都有一个 **Automated Follow-ups**（自动跟进）开关。这与您的广播/坐席级跟进设置是独立的——当此开关关闭时，无论您的外呼设置如何，该特定号码都**不会发送任何类型的跟进消息**。

**对于新号码（使用时间在 30 天以内的预热期），请完全关闭跟进功能。** 新号码应仅发送初始外呼消息。跟进消息是导致低信任度号码被归类为“机器人”的主要原因。一旦号码完全预热并稳定下来，您可以重新开启该开关。

***

## “受限”的真正含义

如果您触及了 Meta 的隐形阈值，号码并不总是会立即被封禁。有时它会先被**限制**——这相当于一张黄牌。其表现为：

- **现有聊天仍然有效。** 您可以回复任何已经给您发过消息的人。该号码在处理热度较高的对话时功能完全正常。
- **新聊天被阻止。** 任何向全新联系人发送第一条消息的尝试都会静默失败。

理解**风险究竟在哪里**至关重要。冷外呼——即向从未给您发过消息的人发送第一条消息——是 WhatsApp 上风险最高的活动。一旦建立了对话，您就可以来回发送数百条消息，几乎没有任何风险。平台的智能路由已经通过 50% 的余量规则考虑到了这一点，但您也需要内化这一点：**第一条消息成本高昂，而回复则成本低廉。**

如果您发现某个号码受到限制，请不要惊慌。停止向其推送新联系人，让它在现有聊天中度过限制期，同时将冷外呼转移到您的其他号码上。

***

## 分担风险：WhatsApp Web 与 WhatsApp Business API

一旦您的业务量达到一定规模，强烈建议采用并行运行两个渠道的设置：

- **[WhatsApp Web](whatsapp-web.md)** 承担大部分工作——入站流量、跟进以及所有正在进行的对话。Web 号码在接收者眼中看起来像真实用户（有输入指示器、“在线”状态、头像），这在潜在客户转化为客户的阶段非常重要。
- **[WhatsApp Business API](whatsapp-business.md)** 作为**备份**放在一旁，专门用于**向全新联系人发起冷外呼**——仅限第一次接触。Business API 的执行是在服务器端进行的，因此当您达到限制时，它会报错，而不是封禁。

交接过程如下：向全新联系人的第一条冷消息通过 Business API 发出。一旦该联系人回复——或者当您想要进行跟进时——对话就会转移到 WhatsApp Web 号码并留在那里。Web 号码负责处理繁重的工作量；API 号码保持较低的负载，以便在 Web 号码需要冷却或处于限制状态时，始终可用作备用方案。

这不是硬性规定——许多账户仅使用 Web 渠道——但这是每月外呼超过约 1 万条时最安全的扩展方式。

***

## 共存的神话

Meta 有一项名为**共存 (coexistence)** 的功能，他们将其作为在 Business App 和 Business API 上同时使用同一个号码的官方解决方案进行推广。虽然在其他地方被广泛推荐，但本平台刻意不依赖此功能。

> **请注意：** 共存（Coexistence）并**不会**解除底层的消息发送限制。每个号码的上限依然适用。而且，当 Meta 判定某个共存号码存在违规行为时，后果可能会波及到**您的整个 Meta Business 账户**，而不仅仅是违规的那个号码——这意味着同一商务管理平台（Business Manager）下的广告账户、主页访问权限和其他号码都会受到影响。Reddit 和 Meta 社区论坛上已经有多位用户报告过这种情况。

本指南中介绍的多号码策略可以帮助您绕过共存限制，且**不会**带来任何账户层面的风险。如果某个 Web 号码被封禁，只会影响该号码本身——您的其他号码、Business API 渠道以及您的 Meta Business 账户本身都不会受到影响。这正是该架构设计的核心意义所在。

***

## 数据库重新激活——从 100 个联系人开始

**数据库重新激活**是指重新联系沉睡的潜在客户——即从 CRM、旧导出文件或数月甚至数年未曾联系的列表中提取的历史联系人。这是 WhatsApp 上风险最高的对外发送模式之一，无论使用哪种渠道，结果都一样：此规则同样适用于 **WhatsApp Web 和 WhatsApp Business API**。

**切勿一次性群发整个列表。** 即使是在 Meta 通过服务器端强制执行限制而非直接封号的 WhatsApp Business API 上，如果一次性向数千名沉睡联系人发送糟糕的开场白，也会导致该号码的质量评分暴跌，并瞬间毁掉这次重新激活的机会。

有效的操作模式：

1. **从 100 个联系人开始。** 首次发送时不要超过这个数量。
2. **等待 24 小时并观察回复率。**
3. **回复率接近于零并不代表沉默——这是一种信号，表明收件人正在将消息举报为垃圾信息。** 那些不认识发件人的沉睡联系人，或者看到看起来像群发消息的开场白时，会点击“举报”而不是“回复”。请立即停止发送。重写开场白。尝试不同的切入点——比如提问、提及他们最初注册时的背景，或者采用更委婉的重新介绍方式。

   **我们现在可以为您自动处理此项工作。** 一旦发送量达到至少 100 个联系人，如果回复率低于 5%，我们会自动暂停发送并给您发送电子邮件。您剩余的联系人不会受到影响，因此您可以修改开场白并恢复发送，而不会浪费列表中的其余部分。对于少于 100 个联系人的发送，我们仅会发送警告邮件并保持发送继续——因为少量沉默的联系人不足以用来评估开场白的好坏。
4. **使用新的开场白再发送 100 个。** 再次衡量效果。
5. **不断迭代直到回复率看起来正常**，然后逐步扩大规模——250 个，接着 500 个，再到更大的波次——永远不要一次性推送整个列表。

100 个联系人的初始批次足够小，即使开场白不佳也不会永久损坏发送号码，但也足够大，使得回复率成为一个真实的信号而非噪音。

***

## 总结——操作手册

本文中所有规则的检查清单。请打印出来，贴在您的显示器上。

- [ ] **切勿**连接从未接收过 WhatsApp 消息的 SIM 卡。请先从您的个人手机向其发送 3–5 条短信。
- [ ] 连接**至少两个** WhatsApp Web 号码。对于每月约 3 万条消息的量级，四个号码比较从容。
- [ ] **错开**新号码的连接时间，间隔 1–2 周，这样它们就不会在同一天完成预热期。
- [ ] 让没有历史记录的号码完整经历 **60 天的预热期**。除非该号码确实有真实的自然历史记录，否则不要使用预热天数覆盖滑块。
- [ ] 在预热期少于约 30 天的号码上**禁用后续跟进**。仅限初始对外发送。
- [ ] 在“设置”→“个人资料”→“跟进时机”中开启**遵守静默时间**。如果您有美国流量，请添加**美国严格模式**。
- [ ] 对于任何包含链接的发送，请使用**短链接**，以便流量自动分配到您的所有号码上。
- [ ] 信任 **50% 路由截止点**——当一个 Web 号码的使用率达到 50% 时，它将停止接收新联系人，但现有的对话仍会继续进行。
- [ ] 一旦号码完全预热，请保守地使用**预热期后手动覆盖**（从每天 750 条开始，并仔细观察）。
- [ ] 如果号码变为**受限**状态，请停止向其推送新联系人。现有对话仍可正常工作——让它自然运行即可。
- [ ] **分散风险**：WhatsApp Web 承担主要流量（入站、跟进、持续对话）；保留一个 WhatsApp Business API 号码作为备份，并用于向全新联系人发起第一条冷启动消息。
- [ ] **数据库重新激活**：从 100 个联系人开始，衡量回复率，迭代开场白——切勿群发整个列表。如果 100 个以上联系人的回复率持续低于 5%，我们会为您暂停发送。
- [ ] **不要**使用 Meta 的共存功能。它不会解除限制，反而会使您的整个 Meta Business 账户面临风险。

***

## 需要帮助？

Email [<span data-t="supportEmail">hi@youraiconnector.com</span>](mailto:hi@youraiconnector.com) and we'll help you walk through your specific setup.
