构建 n8n AI 支持工作流是容易的部分。以下是我为生产环境测试时学到的经验。

大多数 AI 支持演示都以以下方式结束：Webhook → LLM → 回复 这在演示中有效，但无法经受生产环境的考验。在构建和测试自己的工作流后，我意识到大部分重要的工程工作发生在模型生成回复之前。 这是架构： Crisp Webhook ↓ 快速 JS 验证 ↓ Notion 知识库 ↓ LLM 分类（仅 JSON） ↓ 需要人工？ ├── 是 → 人工队列 └── 否 → 生成基于知识库的回复 → Crisp 总共约 30 个 n8n 节点。 1. 分类比生成更重要 第一个 LLM 从不与客户交谈。它只返回结构化 JSON，例如： { "topic": "billing", "urgency": "high", "needs_human": true } 退款、法律问题、安全问题或愤怒的客户会立即绕过 AI 回复，转给人工处理。这个决定并不隐藏在提示词中，而是由工作流本身强制执行。 2. “Hi”浪费了我大部分 AI 预算 有一件事让我很惊讶。人们经常以以下内容开启支持聊天： hi hello ? 👋 对这类消息运行检索 + 分类 + 生成，只是在白白消耗 token。因此，我在任何 AI 调用之前添加了一个基于规则的过滤器。 第一条模糊消息：→ AI 提出一个澄清问题。 重复模糊消息：→ 静态回复。 最终：→ 完全忽略。 简单的改动，却大幅减少了不必要的 API 使用。 3. 没有知识 → 没有答案 我没有指望模型自觉表现，而是将每个回复都基于检索到的 Notion 文档。如果找不到相关内容，工作流不会猜测，而是直接将对话转给人工。我宁愿不发 AI 回复，也不愿给出自信的错误答案。 可靠性比提示词更重要 每个 AI 请求都有重试和超时机制。如果所有重试都失败，工单仍会进入人工队列。客户消息不应因为 OpenAI 短暂故障而消失。 我仍在发布前改进和测试工作流。如果你在生产环境中运行 AI 或 n8n 工作流，我真的很想知道我还遗漏了哪些故障案例。很高兴回答任何实施问题。