用 n8n 构建可审核的销售线索智能体

把客户表单接进 n8n，让 AI 判断线索该交给销售、进入培育队列，还是补充信息，看起来并不复杂。真正难的是：模型会不会补出不存在的事实，重复创建客户，甚至替销售发出未经批准的承诺。

这篇文章给出的答案很明确：AI 负责理解文本，规则负责决定去向，人负责审核例外。它没有展示转化率提升的实验，却提供了一套值得程序员借鉴的工作流边界，尤其适合正在把 AI 从演示接入业务系统的团队。

AI 可以理解需求，但不能制定销售政策

作者先把任务收窄到一个具体问题：这条入站线索下一步去哪里？

初始版本只需要三个去向：销售审核、培育队列、请求补充信息。每个去向都要有负责人和响应时限。判断依据应该是公司类型、需求与产品的匹配程度、采购时间、请求的产品等业务条件，不能靠模型猜测个人属性。

这里最重要的是区分三类信息：客户自己提交的内容、系统核实过的数据、模型推断出的含义。

例如，客户写了「想了解自动化培训」，模型可以归纳其意图，但不能顺手认定对方已有预算、计划近期采购。推断可以帮助理解需求，不能悄悄变成 CRM 里的事实。

模型可以提取判断所需的信号，最终评分和去向必须由模型之外的规则计算。

作者建议把客户筛选标准做成带版本的评分卡（scorecard），明确允许使用的证据、权重、阈值和排除条件。每次结果都保存评分卡版本，以便日后回答：当时为什么把这条线索分到这里？

这比提示词里写一句「请找出高意向客户」多了不少准备工作，但也消除了一个隐患：修改提示词，不应该顺带修改公司的销售政策。

n8n 工作流的重点，是把每一步权限拆开

原文给出的流程共有八步：接收、校验、查询 CRM、AI 提取、规则计算、人工审核、写入、复盘。

接收端可以是表单、邮件或 webhook。进入模型之前，先整理出稳定字段：lead_id、source、message、company、consent_state 和 received_at。格式错误或未经授权的输入，应在这里拒绝，避免把后续节点当成补救工具。

随后查询 CRM。作者强调，要用经过验证的标识符检索，不能仅凭模糊姓名匹配。如果多个客户记录都可能对应这次咨询，就停止自动处理，交给人判断，同时保留已有负责人和未关闭的商机。

这一步很容易被演示项目省略。实际业务里，同一家公司再次咨询，并不代表应该新建客户，更不代表可以覆盖原销售负责人的记录。

AI 提取之后，再使用 n8n 的 IF、Switch 或代码执行评分卡。工作流还要检查枚举值、证据字段和来源 ID，不能直接接受模型输出的「高意向客户」标签。

人工审核也要绑定到确切的 CRM 修改内容。审批人同意某次更新，不等于之后任意变化的字段都获得了授权。写入时再使用 lead ID 作为幂等键，即让同一条线索重复执行时，不会重复产生同一次写入。

n8n 提供包括 HubSpot 在内的 CRM 集成，但接得上接口，只解决了调用问题。作者建议先开放只读查询和草稿输出，再逐步加入范围受限的写入；不确定、高价值、战略性或涉及政策例外的情况，继续进入人工审核。

结构化输出让错误有机会被拦下来

作者要求模型返回固定结构，包括用途、明确的时间安排、期望结果、原文证据、缺失字段和置信度。没有的信息返回 unknown，不要替客户补全。

下面这段原文示例，用来把线索判断转成可以校验和追溯的数据：

{
  "lead_id": "lead_2048",
  "fit_signals": ["requested workflow automation", "team of 12"],
  "intent": "evaluating_training",
  "timeframe": "unknown",
  "missing_fields": ["decision_timeline"],
  "recommended_route": "request_information",
  "scorecard_version": "2026-10-05",
  "source_ids": ["form_781", "contact_992"],
  "needs_human_review": true
}

要盯住的是 recommended_route：即使模型已经给出建议，工作流仍然必须根据校验后的字段重新计算，不能直接照单执行。

这里也暴露了原文没有展开的部分。前文要求返回引用证据和置信度，示例却没有对应字段；fit_signals 只是字符串列表，没有逐条说明它来自表单还是 CRM。因此，这份 JSON 适合说明思路，还不足以直接充当完整的数据契约。

重新计算路线，可以拦截格式错误和违反规则的建议，却不能自动证明输入信号是真的。如果「team of 12」本身就是模型编出来的，后面的确定性规则仍然可能算出错误结果。证据与来源如何关联，还需要落地时补齐。

权限和数据范围同样要收紧。作者建议只读取筛选必需的 CRM 字段，不默认把完整邮件历史和私人备注塞进提示词；敏感或受保护属性，以及模型推断出的替代指标，都不能进入评分卡。营销同意、服务咨询和合法利益判断也要分开处理。

销售承诺、折扣和对外声明需要审批。日志则记录来源 ID、评分卡版本、审核人和最终写入结果，避免复制不必要的个人信息。原文还提醒，涉及 GDPR 的组织需要把目的限制、数据最小化、准确性和透明度落实到工作流中，但没有展开具体合规实现。

我的判断

我认同它把语言理解与业务决策拆开的方向。对于条件清楚、需要追责的线索分流，版本化规则比让模型自由打分更容易排查：是事实提取错了，还是评分标准不合适，可以分别检查。

但这是一篇技术模式建议，不是效果验证报告。作者没有提供真实团队的运行样本、误判比例、处理耗时，也没有对比纯规则方案或模型直接评分的结果。文章还包含四周训练营的推广，不能把其中的架构建议当成已经证明有效的业务成果。

它的适用前提也很具体：团队得先有相对明确的客户标准、可查询的 CRM 数据，以及愿意处理例外的销售人员。如果这些条件缺失，AI 只会把原有混乱更快地搬进系统。咨询内容很规范时，表单校验加规则分流也可能已经够用；自由文本确实需要理解时，再加入模型提取才有明确价值。

测试方面，原文要求覆盖优质线索、不匹配线索、信息稀少、重复联系人、提示注入和边界情况，但没有给出提示注入的具体防护实现。把它列入测试集，只是开始。

评估也不能只看一个准确率。误接收会增加销售负担，误拒绝可能丢掉机会，两者必须分别统计，再结合分流耗时、缺失数据率、人工改判、重复预防和后续业务结果，按来源与评分卡版本分析。原文提出了这些指标，却没有给出达标阈值。

能拿来做什么

• 给前端咨询表单接 AI 时，先固定输入字段，并在工作流调用模型前完成必填、格式和处理权限校验，再让模型理解自由文本。
• 在 n8n 或 Node 中维护带版本的评分规则，让 AI 输出证据和缺失项，由代码计算去向，并把规则版本与结果一起保存。
• 接入 CRM 时先上线只读查询与跟进草稿，验证重复匹配和负责人保留逻辑；开放写入时，把审批绑定到具体变更，并加入幂等控制。
• 为日常 AI 工作流建立带日期的案例集，覆盖缺失信息、重复记录和注入尝试，分别记录误接收、误拒绝及人工改判原因，再决定是否扩大自动处理范围。