n8n 评分流程：规则先筛，模型再判

给 n8n 工作流加上 LLM，最容易踩的坑，是让模型一边打分，一边决定下一步做什么。作者的结论很明确：规则先筛选，模型只处理规则难以判断的少量案例，最终执行仍交给确定性的节点。

这篇文章的价值在于把模型放进可控流程：输出怎么约束、失败怎么兜底、评分怎么复查。它提供了五个实用模式，但涉及效果和稳定性的数字，还需要分清作者的经验与可验证的证据。

哪些判断值得交给模型

作者做销售线索筛选时，会先用查表或规则处理公司规模、邮箱域名、职位级别。这些信息有明确边界，使用模型既增加成本，也增加不确定性。

真正适合 LLM 的问题是：「这条咨询是否符合我们卖的产品？」它需要理解需求，而不是匹配某个字段。作者曾为此堆出 40 个脆弱的 IF 节点，随后才把这部分判断交给模型。

规则能稳定处理的先处理，语义判断再交给模型。

模型选择也遵循这个思路。作者建议先用小而快、成本低的模型，把真实评分标准写进提示词，并提供示例：什么情况给 90 分，什么情况给 30 分，什么情况直接拒绝。

不过，「小模型加精确提示词胜过大模型加模糊提示词」是作者的经验判断。原文没有给出模型名称、成本或准确率对照，不能据此认定某个小模型已经够用。

模型填字段，IF 节点负责执行

作者要求评分结果使用固定结构，避免下游再从一段自然语言里猜分数、提取结论：

{
  "score": 0-100,
  "verdict": "sales" | "nurture" | "reject",
  "reasons": ["one line each"]
}

要注意 score 和 verdict 两行：这是结构示意，不是可以直接解析的合法 JSON，也不是完整的 JSON Schema。实际接入时，需要把它们落实为数值范围和枚举约束。

原文建议使用 n8n LLM 节点或 HTTP 节点调用 API 时支持的 JSON 响应格式，并设置 Temperature 0。这里要区分两件事：Temperature 0 用来降低生成的随机性，字段、类型和枚举是否合规，仍要依靠具体接口支持的约束与校验。

评分节点放在现有规则链之后，后面接一个 IF 节点。模型输出 sales、nurture 或 reject，IF 节点按预设条件分流；写入 CRM、发送提醒等动作由执行节点完成。

这让模型的职责收敛到「提供判断字段」。但路由固定，不代表判断正确。模型如果误判为 sales，IF 节点仍会忠实执行后续动作，评分质量依然需要单独检查。

失败要有出口，低分要能复查

超时、返回格式错误、请求突发时触发限流，都不能让整条工作流停住。作者的做法是让错误分支进入 Set 节点，写入默认分数，并在 reasons 中留下 ["model_unavailable"]。

这样，一次运行仍然能产出完整报告，后续可以找到哪些记录用了兜底值。原文没有规定默认分数是多少，也没有说明失败记录最终应该流向哪里，这需要结合业务后果补齐。

调用失败必须保留身份，不能悄悄变成一次正常评分。

日志则同时保存 score 和 reasons。作者举例，两周后复查时，可能发现某条只得 61 分的线索其实值得 90 分，再顺着理由定位评分标准中的问题。

这里的 reasons 是复查线索，不能当作模型判断过程的完整证明。它能帮助发现误解，也可能只是模型生成的一段解释，仍需对照原始请求核验。

作者称模板库运行了 1,892 次以上提醒周期，相关指标达到 99.7%；另一个求职项目累计评分超过 1,500 条职位信息。但原文没有交代 99.7% 的指标定义、统计周期和对照条件，因此不能把它理解为评分准确率，更不能据此确认日志带来了多少稳定性提升。

我的判断

我认同这套职责划分：确定字段交给规则，模糊语义交给模型，执行动作由预设流程控制。相比继续堆 IF 节点，它更适合处理表达多变的咨询内容；相比让模型直接操作 CRM，它也更容易检查每一步发生了什么。

它的前提是：团队已有可表达的评分标准，并且能容忍少量误判。如果连「什么叫合格线索」都没有共识，换模型并不能解决问题。

还要补上两个边界。第一，默认分数可能影响后续动作，兜底不能只考虑流程是否跑完。第二，日志让问题可见，但不会自动提高评分质量，需要有人复查并修改标准。作者没有提供对照实验，这套方法适合作为工程起点，效果仍应由自己的样本验证。

能拿来做什么

• 在现有 n8n 线索流程中，先保留公司规模、邮箱域名等规则，只把难以归类的需求描述送给 LLM，避免每条记录都调用模型。
• 用同一批历史请求检验评分标准，放入 90 分、30 分和直接拒绝的示例，再检查模型是否能稳定区分这些情况。
• 为超时、限流和格式错误设置 Set 兜底，并让 model_unavailable 在后续分流中保持可识别，防止失败记录被当成正常低分处理。
• 每次保存分数、理由和对应原始输入，定期抽查误判，再决定调整规则、提示词还是模型。