n8n工作流实战：人机协同JIRA工单与RAG落地

n8n 是一个带可视化画布的工作流编排工具，用节点串联起触发器和各类外部服务。它的价值不在于替代代码，而在于让控制流和数据流变得可见、可调试。本文基于 YouTube 创作者 Appandarajan Poornachandran 的实操演示，拆解两个典型场景：带人工审核环节的 JIRA 工单创建，以及基于 Supabase 向量库的保险理赔 RAG 助手。

为什么选 n8n：可视化编排的核心优势

n8n 的每个工作流都由触发节点和后续动作节点构成，节点之间传递的是 JSON 数据。创作者强调，你不需要记住节点顺序，也不一定要写 JavaScript——大多数字段映射靠拖拽完成。真正需要理解的是两件事：上一个节点的输出是什么，当前节点需要什么输入。

这种设计让调试变得直观。你可以逐节点执行，随时查看数据快照；遇到报错时，把错误信息和节点配置丢给 ChatGPT 之类的工具，往往能得到修正建议。对于想把 AI 能力接进现有系统的团队来说，这比从零写编排逻辑要省事得多。

场景一：人机协同的 JIRA 工单流程

从邮件触发到 AI 定级

第一个案例的起点是一封用户报障邮件。工作流以 Gmail 触发器开头，设置为每分钟轮询收件箱，一旦有新邮件就启动流程。邮件内容随后被送入 AI Agent 节点。

这个 Agent 使用 Gemini 模型，并挂载了结构化输出解析器（structured output parser）。创作者给出的输出格式示例是高/中/低三档优先级。结构化解析器的作用不是硬编码，而是约束模型按固定 JSON 结构返回结果，方便下游节点直接取用。Agent 的 user message 通过拖拽映射了发件人、收件人、主题和正文片段，system message 则明确要求它阅读邮件、判断问题性质并设定优先级。

结构化输出解析器（Structured Output Parser）是 LangChain 及 n8n AI 节点中常见的组件，用于把大模型的自由文本输出约束为符合预定义 Schema 的 JSON。它通常借助 Zod 或 JSON Schema 描述字段类型与枚举值，在请求模型时附带格式指令，并在返回后做校验与重试。相比在 prompt 里写「请返回 JSON」，解析器能显著降低格式漂移，让下游节点稳定地按字段取值，例如直接读取 priority 字段而不必再做字符串解析。

人工审核环节：Wait 节点与表单

定级完成后，流程并不是直接建单，而是先给审核人发一封 HTML 邮件，附上一个表单链接。这里的关键是 Wait 节点——工作流在此暂停，直到表单被提交才继续。

表单由 n8n 动态生成，包含可编辑的 bug 描述文本框和优先级下拉框。审核人可以修改 AI 给出的定级，比如把「中」改成「高」，然后提交。这个暂停再恢复的机制，正是 human-in-the-loop 的落地方式：让机器做初筛，让人做最终判断。

Human-in-the-loop（人机协同）指在自动化流程中保留人工判断节点，常见于高风险或需要问责的环节，如工单定级、内容审核、理赔审批。在 n8n 中，Wait 节点有两种恢复方式：按时间延迟，或等待外部事件（如 Webhook、表单提交）。工作流暂停期间，执行状态会被持久化，恢复后从暂停点继续，而不是从头重跑。这使得「机器初筛 + 人工确认」的模式可以低成本落地，同时保留完整的执行轨迹供审计。

写入 JIRA 并回执

表单提交后流程恢复，进入 JIRA 节点执行「创建 issue」操作。这里有一个值得注意的细节：n8n 里的优先级是文本（高/中/低），而 JIRA 用数字 ID 表示优先级，因此需要一层映射转换。创作者在演示中把文本优先级转换为 JIRA 对应的数值，再填入 summary 和 description 字段。

工单创建成功后，最后一个 Gmail 节点向最初报障的用户发送确认邮件，告知问题已被受理、团队正在跟进。整条链路从收信、分析、审核、建单到回执形成闭环。

场景二：基于 Supabase 的理赔 RAG 助手

为什么必须用向量数据库

第二个案例面向保险理赔场景：理赔专员每天处理大量案件，容易出现误判，需要一个 AI 助手依据保单条款给出「通过 / 需补充材料 / 拒绝」的建议。

这类任务的关键在于答案必须来自内部文档，而不是模型自由发挥。传统关系型数据库只能做精确匹配，一旦用户换个说法就查不到。RAG 的做法是把文档切块、转成向量存进向量库，查询时做语义检索。创作者选择 Supabase 作为向量库，先在后台执行一段 SQL 建好 documents 表，用于存放政策文档的分块与向量。

向量数据库专门存储和检索高维向量（即嵌入），核心能力是近似最近邻（ANN）搜索：把查询文本也转成向量，再按余弦相似度或欧氏距离找出语义最接近的文档块。Supabase 通过 pgvector 扩展在 PostgreSQL 上提供这一能力，因此同一张表既能存业务字段，也能存向量并建立 IVFFlat 或 HNSW 索引。相比专用向量库，它的优势是与关系型数据、权限体系共用一套基础设施，适合已经在用 Supabase 的团队。

数据摄取工作流

第一个子工作流负责「喂数据」。手动触发后，Google Drive 节点先搜索指定文件夹（演示中是 insurance 文件夹），找到 4 个文件，再逐一按文件 ID 下载。

下载后的文件经过 Default Data Loader 转成二进制文本，再由 Recursive Character Text Splitter 切成块，演示中块大小上限设为 100 或 1000（不同段落口述略有出入）。切好的文本块交给 Gemini 嵌入模型转成数值向量，最后通过 Supabase Vector Store 节点的 insert 操作写入 documents 表。这套「加载—切分—嵌入—入库」的链路是 RAG 摄取的标准做法。

Recursive Character Text Splitter 是一种按字符递归切分的文本分割器，它优先使用段落、换行、句子等自然边界，逐级回退直到块大小落入设定范围，并保留一定的重叠（overlap）以避免语义在切分处断裂。块大小是关键调参项：过小会丢失上下文，过大会稀释检索精度并推高嵌入成本。嵌入模型则把文本映射为固定维度的数值向量，语义相近的文本在向量空间中距离更近，这是 RAG 语义检索的基础。

对话工作流与三轮测试

第二个子工作流以 Chat Trigger 开场，理赔专员在聊天窗口输入理赔信息。AI Agent 配置了 Gemini 模型、会话记忆，以及一个「向量库问答」工具。该工具指向 documents 表，使用 Gemini 嵌入模型做检索，system prompt 要求它依据保障范围、免责条款和证据给出带推理的建议。

创作者用三份测试理赔做了验证：第一份得到「建议通过」，并附上推理与证据引用；第二份得到「需要补充更多信息」及具体原因。输出均基于检索到的保单内容，而非模型凭空推断。

实践建议与边界

两个案例共同说明了一件事：n8n 的定位是编排层，它把 Gmail、JIRA、Google Drive、Supabase 这些系统串起来，AI 则作为其中一个节点参与决策。创作者提到，通过 MCP 客户端还能接入更多外部系统。

但也应看到演示的局限：Supabase 免费版、JIRA 试用项目、单机测试数据，都说明这是可行性验证而非生产方案。真正上线前，向量库的检索质量、块大小调优、审核表单的权限控制，以及优先级映射的健壮性，都需要进一步打磨。