生产环境前如何测试n8n LLM工作流：四层断言测试法

LLM工作流上线前没有测试，就像部署代码没有CI——但难点在于，你无法断言精确的字符串输出，因为模型每次说的话都不一样。

这是一套在n8n LLM工作流进入生产前运行的测试夹具。它不测试主观感受，而是验证机械保证：来源可溯（grounding）、降级可用（fallback）、精确一次（exactly-once）、成本可控（cost）。

rss source: Trust, but Verify: How I Test n8n LLM Workflows Before They Touch Production

整套测试围绕一个核心思路展开：LLM本身是非确定性的，但围绕它的验证逻辑必须是确定性的。

测试夹具：三种预设转录文本

一切从三个预置的会议转录文本开始，与工作流JSON一起提交到代码仓库：

Clean（干净版）：结构良好的站会记录，发言人有名有姓，负责人和截止日期都明确标注。所有内容都应该在第一次mini尝试中通过。
Messy（混乱版）：发言重叠，截止日期是隐含的（“咱们在发布前搞定它”），有一个行动项没有明确负责人。旗舰模型应该能处理其中一部分，另一部分应该进入人工审核队列。
Adversarial（对抗版）：有人谈论做某事但从未承诺（“我们应该找个时间看看API速率限制的问题”）。正确的输出是零个行动项。如果工作流在这里提取出了行动项，就说明它没能通过最重要的测试。

这三个夹具的核心价值在于：输入固定，输出已知。在关键环节上保持确定性，才能把LLM的不确定性隔离在可控范围内。

测试一：证据引用门禁即断言

证据引用门禁本质上是一个等待被执行的单元测试。它独立运行在预置的LLM输出上，而非调用真实模型：

// n8n Code节点测试：给定此转录文本 + 预置模型输出
// 门禁必须保留item 1，丢弃item 2（无逐字引用）
const transcript = $input.first().json.transcript;
const items = $input.first().json.modelOutput; // canned, not live
const kept = items.filter(i => transcript.includes(i.quote));
return kept.map(i => ({ json: i }));

维护一张预置输出表：有效引用、改写引用（必须丢弃）、来自不同会议的引用（必须丢弃）、缺失引用（必须丢弃）。门禁是纯字符串匹配，所以这个测试完全确定。如果有人修改了门禁逻辑导致改写引用开始通过，测试会立刻捕获。LLM是非确定性的，门禁必须不是。

测试二：降级矩阵

当所有提供商都失败时会发生什么？这是必须通过强制触发来测试的场景。作者有一个测试模式，可以依次或同时将每个LLM节点指向一个失效端点：

杀掉提供商A → 工作流必须降级到提供商B，运行完成。
杀掉A和B → mini-first级联仍能将困难项路由到最后的备用提供商，运行完成。
全部杀掉 → 运行必须大声失败：触发错误分支、告警节点启动，不允许任何静默的半写入。

最后一种情况是大多数人会跳过的。如果所有提供商都宕机时工作流静默失败，它会在凌晨3点用不完整的结果污染你的任务管理器。宁可被呼叫告警，也不要产生幽灵任务。

测试三：崩溃测试

在运行中途杀掉执行——实际停止n8n执行——然后用同一份转录文本重新运行。断言：

无重复行动项（幂等性：按会议ID + 条目哈希执行upsert）。
崩溃前已提取的项目不会被重复提取（重跑预算）。
运行日志显示重试，而非静默覆盖。

这个测试手动执行，每个工作流版本一次，不放在CI中——五分钟的测试，却验证了唯一一个会花两次钱的故障模式（重复花费 + 重复条目）。这是对崩溃边界机制的实证，而非仅仅是设计声明。

幂等性（Idempotency） 是分布式系统中的经典保证：同一个操作执行一次和执行多次，对系统状态产生的最终影响应当完全相同。这里的实现方式是「按会议ID + 条目哈希执行upsert」——upsert 即「存在则更新、不存在则插入」，以业务主键去重，而不是盲目 append。没有这层保证，崩溃重跑就会把同一份转录里的行动项写两遍，任务管理器里出现孪生条目，下游通知、计费、SLA 统计全部被污染。值得注意的是，幂等键必须来自稳定的输入特征（会议ID、条目内容哈希），而不能依赖本次运行的顺序或随机ID，否则重跑时键会变，去重就失效了。

测试四：成本预演

任何新工作流版本上线前，将混乱版夹具跑一遍，对照级联预算检查两个数字：

升级率：多大比例的项目被送到了旗舰模型？如果超过三分之一，说明提示词有问题，而不是模型选错了。修提示词，别放宽预算。
单次会议成本上限：总token数 × 最坏情况价格。这个数字必须落在升级预算内。如果不满足，工作流不许上线。

这是最接近负载测试的环节。它无法精确预测生产环境成本，但能捕获灾难性情况：一次提示词修改导致升级率翻倍，或重试循环突破了界限。

模型级联（Model Cascade） 是一种成本与质量折中的路由策略：先用便宜的小模型（如 mini 档）处理全部输入，只在它输出低置信度、校验失败或触发特定条件时，才把该条目「升级」给昂贵的旗舰模型。因此「升级率」直接决定总成本——它乘以单次旗舰调用的开销，就是级联相对于纯小模型的额外支出。经验阈值（如超过三分之一）是提示词质量的信号：升级率异常升高通常说明任务描述含糊、格式约束缺失，让 mini 模型频繁「答不上来」，而不是旗舰模型真的更聪明。此时正确的动作是修提示词，因为放松预算只会掩盖根因，让成本随流量线性放大。

预发布检查清单

每个工作流版本都按顺序执行同一套运行手册：

跑三个夹具。Clean → 全部首次通过。Adversarial → 零条目。
依次强制每个提供商失败，然后全部失败。断言降级触发，然后大声失败。
崩溃并重跑一次。断言零重复、零重复花费。
跑混乱版夹具，检查升级率和成本上限。
发布。

整个过程大约二十分钟。“我第一次跳过第二步时，凌晨2点的提供商故障教会了我它为什么在那里。这个教训的成本比测试高得多。”

明确不测试什么

输出质量——行动项是否写得好、摘要是否读起来通顺——这些是主观的，由级联中的人工审核队列处理：模糊条目总是交给人类。测试验证机械契约（有据可查、去重、有界、失败时大声报警），人类验证文字表达。这样拆分让测试保持确定，审核队列保持精简——它只看到真正模糊的案例，而非机械性问题。

确定性测试与非确定性输出的边界 是这套夹具的设计核心。传统单元测试用「断言输出等于期望值」来验证，但 LLM 即使在同一输入下也会因采样温度、批处理、模型版本漂移而产生不同措辞，精确字符串断言必然失败。工程师的应对是把测试对象从「文本内容」上移到「结构性契约」：引用是否逐字来自原文（纯字符串匹配，可断言）、去重键是否唯一（可断言）、失败路径是否触发（可断言）、成本是否越界（可断言）。这些契约不随模型措辞变化而变化，因此可以放进 CI。而「行动项是否写得好」这类语义判断，交给人工审核队列，两者分工明确、互不重叠。