用n8n搭建WhatsApp智能线索自动化：AI分级让商机不再流失

在大多数企业的日常运营中，咨询线索(lead)源源不断，但真正的难题在于：很多人只是询问服务、了解报价，却不会当场下单。如果派人工去应对每一条消息，成本极高且效率低下。这篇文章拆解一个基于 n8n 的 WhatsApp 自动化工作流，看它如何用 AI 把线索自动分级、按紧急程度决定是否惊动真人，从而把人力集中到真正愿意成交的客户身上。

工作流解决的核心痛点

线索管理的本质矛盾是「数量」与「质量」的错配。咨询量大，但其中大部分是温吞的、尚未决定购买的意向，只有少数属于「现在就要用」的高价值客户。原视频作者给出的思路很直接：让 AI 代理先接管所有进线，自动完成初步应答与分类，只有在客户表现出紧急需求时，才把信息推送给真人老板处理。

这样做的价值在于——业务负责人不再需要为每一条「我想了解一下」浪费时间，而是只在系统判定为「热线索」时介入。换句话说，AI 承担了筛选和培育的工作，人力只用在转化率最高的环节。

四级线索分类机制

该工作流把所有进来的消息分为四类：hot（热）、warm（温）、cold（冷）、unclassified（未分类）。分类逻辑的核心是判断客户的「紧急程度」与「成交意愿」。

作者在演示中发了几条不同的消息来测试：

• 当发送「我对 WhatsApp 自动化感兴趣」时，系统判定为 warm——因为只是表达兴趣，没有明确的紧急服务需求。
• 当发送「我急需 WhatsApp 自动化」时，有趣的是系统仍可能判定为 warm，因为代理认为客户尚未明确表现出成交动作。
• 当发送「今天就安排通话，我要和老板谈」时，系统立即判定为 hot，并触发邮件通知业务负责人。

这种梯度判断体现了一个设计原则：不是看关键词里有没有「紧急」二字，而是看客户是否发出了实际的行动信号（如「安排通话」「想谈价格和付款」）。

四级分类本质上是一种**意图识别（Intent Detection）与紧迫度评估（Urgency Scoring）**的组合。传统规则引擎依赖关键词匹配（如检测到「急」「今天」等词就触发高优先级），容易被措辞变体绕过。基于大语言模型的分类则通过理解语义来判断客户是否发出了「行动信号」——例如「安排通话」「讨论价格」「今天落地」等表达，即使不含「紧急」二字，也能被识别为高意向。这类方法的优势是泛化能力强，劣势是分类边界不如硬规则透明，偶尔会出现让人费解的判断（如演示中「我急需」被判为 warm 而非 hot）。在实际部署中，通常需要通过迭代优化系统提示词、加入少样本示例（Few-shot Examples），甚至对历史数据做分类对齐，来提升判断的一致性和准确率。

AI 应答与评分系统

对于 warm 和 cold 的线索，AI 代理会直接回复而不打扰老板。比如面对兴趣咨询，代理的回复是：「感谢联系，能否告诉我您主要的使用场景，以及大致有多少 WhatsApp 联系人或消息量？」——这是一种标准的线索培育话术，通过提问引导客户提供更多信息。

当线索被判定为 hot 时，系统会给业务负责人发送邮件，并附带一个线索评分（lead score）。演示中那条「今天安排通话」的消息拿到了 90 分，邮件里还自动生成了摘要：该客户需要立即的 WhatsApp 自动化服务、已准备好实施、希望今天通话讨论价格与付款。这意味着老板打开邮件就能快速掌握客户状态，而无需翻看完整聊天记录。

记忆机制与动态评分

这个工作流最值得玩味的地方是它的记忆（memory）机制。系统会持续存储同一客户的历史对话，并据此动态调整评分。

作者演示了一个场景：之前那位发了「安排通话」的客户，稍后又发了一条简单的「hi」。系统再次给老板发了邮件，但评分从 90 降到了 85。原因在于——系统推断是「老板当时没空、客户又来追问」，但由于新消息只是「hi」缺乏实质信息，评分相应回落。

作者解释了为什么同一个人的消息有时被判为 hot、有时又回到 warm 或 cold：很多时候是因为信息不足，系统无法确定客户是否真的紧急。一旦客户再次明确写出「我需要紧急通话」，记忆会再次更新，重新升级为 hot。这种随对话演进而变化的评分，比一次性静态打标签更贴近真实销售场景。

这里的「记忆」在技术实现上通常是对话历史窗口（Conversation History Window），即把同一客户的历史消息拼接进每次新的模型调用 Prompt 中，让模型在有上下文的情况下做出判断。n8n 提供了内置的内存节点（如 Window Buffer Memory），可以按会话 ID（在本场景中通常是 WhatsApp 的手机号）隔离并存储不同客户的对话记录。需要注意的是，这种内存默认是短期的（存在内存或本地数据库中），服务重启后会清空；若要实现跨会话的持久记忆，需要接入外部数据库（如 Postgres 或 Redis）。动态评分的背后逻辑是：模型每次都对「截至目前的完整对话」重新打分，而非在原分数上做加减——这既是它灵活的原因，也意味着评分标准的一致性依赖于系统提示词的稳定表述。

处理异常输入的兜底设计

一个成熟的自动化流程必须考虑非标准输入。该工作流还设计了两种兜底：

• 空消息：如果客户只发了一个空消息框，系统会回复「感谢联系，能简单告诉我们您在找什么服务，或想解决什么问题吗？」
• 缺失联系方式：如果客户没有提供联系信息，系统会追问「请提供您的电话号码和邮箱，以便我们联系您」。

这些兜底环节保证了流程不会因为异常输入而中断，始终把对话引导回「收集有效线索」的轨道上。

为什么需要两个 AI 代理

作者特别指出，这个工作流用了两个 AI 代理（需要两个大模型调用）。第一个代理负责更新信息并完成分类（判定 hot / cold / unclassified）；当结果出来后，第二个代理再基于分类结果与具体客户进行对话应答。这种分工让「分类决策」与「对话生成」各司其职，也让整个流程的逻辑更清晰、更易于维护。

这种「双代理」架构在 AI 工程领域被称为**任务拆分（Task Decomposition）**模式。将一个复杂任务拆成多个专职代理，而非让单一模型同时完成分类、推理与生成，有几个实际好处：首先，不同代理可以使用不同的系统提示词（System Prompt），让每个模型在自己的职责范围内表现更稳定；其次，分类代理的输出是结构化的标签（如 hot/warm/cold），可以直接被后续节点当作条件分支的判断依据，减少自然语言解析的不确定性；最后，两个代理独立运行意味着排查问题时更容易定位——如果邮件通知不对，只需检查分类代理；如果回复措辞有问题，只需调整对话代理。在 n8n 这类低代码自动化平台中，每个 AI 代理节点通常对应一次独立的大模型 API 调用，因此双代理方案的代价是成本翻倍，但换来的是更高的可控性与可维护性。

小结

这个 n8n WhatsApp 自动化案例虽然演示中因为缺少 API key 没能在真实 WhatsApp 收到消息，但完整展示了一套可落地的线索管理思路：AI 自动应答与培育、按紧急度四级分类、动态线索评分、记忆驱动的持续判断，以及异常输入兜底。对于咨询量大、人力有限的中小企业来说，这类工作流能把宝贵的人工精力精准投放到最可能成交的客户身上。