用 n8n 做一个 AI 线索整理工作流

先说结论。

用 n8n 做 AI 线索整理，第一版只需要完成六件事：接收表单、校验字段、查询 CRM、生成摘要与候选标签、人工确认、写回并通知。不要一开始自动发销售邮件，也不要让模型独立决定线索价值。

本文按可复用的流程设计讲解，不提供绑定某个 CRM 的导入文件。n8n 官方文档入口 <https://docs.n8n.io/> 于 2026-07-15 核验；节点名称、凭据配置和产品能力可能变化，实施时以当前官方文档为准。

它解决的实际问题，是线索从表单进入 CRM 之前反复经历字段补齐、人工查重、摘要和复制写回，既慢又容易把模型建议混成客户事实。

这个工作流适合谁

适合已经有网站表单或活动线索、并使用 CRM 管理跟进的小团队。团队的痛点通常不是没有线索，而是字段不齐、重复录入、背景散落，销售打开记录后仍要自己找上下文。

不适合数据量极少、每条线索都由创始人亲自处理的团队，也不适合在没有合法处理依据时抓取外部个人信息。这里的“补全”只使用组织已经获准读取的内部数据和用户提交内容。

先定义输入和输出契约

输入至少包括来源、联系人、联系方式、公司、需求描述、同意状态和提交时间。缺少必需字段时进入待补充队列，不要让模型猜。

输出分为事实字段和建议字段。事实字段来自原始表单或 CRM；建议字段包括摘要、候选场景、候选标签和建议下一步。两类字段要分开保存，建议字段必须标记“待确认”。

这一步决定后续是否会把模型推断误当成客户事实。

节点一：表单触发后先做规则校验

Webhook 或表单触发器收到数据后，先做 schema 校验、空值处理、邮箱或电话格式检查，再进入 AI 节点。确定性问题不需要模型判断。

建议生成一个稳定的 lead_request_id，并保留来源记录引用。重复请求要有幂等策略，避免网络重试创建两条记录。

校验失败时返回明确状态，并把原因发到内部待处理队列；不要静默丢弃。

节点二：先查重，再做摘要

使用已授权的 CRM 接口按邮箱、电话或组织定义的键查询已有记录。查重规则应由业务确定，不能只靠姓名相似度。

若找到记录，读取必要的历史沟通摘要和当前负责人；若未找到，创建“候选新线索”状态，但暂不正式写入。查询只取本次任务需要的字段，减少敏感信息进入模型上下文。

查重结果与来源要进入审批卡，销售才能判断合并还是新建。

节点三：让模型输出受约束的结构

模型任务可以限定为：基于提交内容生成不超过约定长度的摘要，提取明确提到的业务场景，列出缺失问题，并从团队维护的标签集合中给出候选标签。

输出使用 JSON schema 或等价结构校验。标签只能来自白名单；无法判断时返回空值和原因。提示中要区分“原文事实”和“模型建议”，禁止补全预算、规模和采购时间。

结构校验失败可以重试一次，仍失败则转人工，不要无限循环。

节点四：人工确认是流程核心

审批卡展示原始表单链接、CRM 查重结果、AI 摘要、候选标签、缺失字段和拟写回内容。销售可以批准、修改、合并、退回或标为无效。

记录人工修改差异。摘要被改，是事实遗漏还是语气问题；标签被改，是规则不清还是上下文不足。分类后的修改记录可用于后续评估。

审批超时后只提醒或转交，不自动写入关键字段。

节点五：写回要可重试且不重复

批准后再创建或更新 CRM。每次写回携带幂等键，日志记录目标记录 ID、变更字段和返回状态。外部系统超时时，先查询是否已写入，再决定重试。

建议把 AI 生成字段单独存放，并附生成时间、流程版本和确认人。不要覆盖销售原始备注。

写回成功后才发送内部通知；失败通知应包含 task_id 和可操作的重试入口，而不是只说“流程失败”。

错误分支至少覆盖五类问题

1. 表单字段缺失：进入待补充队列。
2. CRM 凭据或权限失败：停止写入并通知管理员。
3. 模型超时或格式错误：有限重试后转人工。
4. 审批超时：提醒、转交或过期。
5. CRM 写回不确定：查状态后再重试，避免重复。

每类错误都要有责任人和恢复动作。把所有异常接到一个 Error Trigger 只能发现问题，不能完成恢复设计。

常见误区会让流程很快变脏

误区一是抓取未经授权的外部资料补全联系人。误区二是模型自由生成标签，几周后 CRM 出现大量同义词。误区三是摘要直接覆盖人工记录。误区四是没有幂等键，重试制造重复线索。误区五是自动发送邮件，把推断内容变成客户承诺。

替代方案也很简单：流程只有单一系统时，可以在现有后端服务中实现；业务主要需要可视化 LLM 应用时，可以评估 Dify；状态恢复和复杂分支成为核心时，再考虑代码化状态框架。

优势和限制决定是否值得接入

n8n 的优势是触发、系统连接和错误分支能在同一工作流中看见，适合小团队快速验证跨系统链路。限制是节点增加后，测试、复用和版本差异会变难；凭据、执行历史和敏感字段也需要组织级管理。

最小开始只建表单触发、字段校验、AI 结构化输出和人工审批四个节点，结果先停在审批卡，不查询也不写入 CRM。用十条去敏样本确认字段和标签稳定后，再增加查重与受控写回。这样每次只验证一层复杂度。

上线前按清单做小范围验证

还要安排一次凭据与迁移检查。确认 n8n 凭据由组织账号管理，开发、测试和生产环境分离，工作流导出文件不包含秘密，节点升级前有回归样本。工作流的所有者离开团队时，其他人应能找到连接说明、错误队列和停用入口。

若流程日后承载更多业务，建议把提示模板、标签白名单和字段映射作为版本化配置管理。这样一次标签调整不会混同于节点逻辑变化，也能在结果异常时回到上一版。

• 使用去敏后的真实样本，不只用理想表单。
• 检查缺失、重复、乱码和超长输入。
• 确认事实字段与建议字段分离。
• 验证模型输出 schema 和标签白名单。
• 测试 CRM 超时、重复回调和权限失败。
• 确认审批人能查看来源并修改结果。
• 检查日志中没有凭据和敏感原文泄露。

我的建议是先让流程旁路运行一周，只生成审批卡，不写 CRM。等查重、摘要和标签的修改原因稳定后，再开启受控写回。这比直接下载一个复杂模板更容易得到可维护的工作流。