n8n 工作流也需要锁定模型版本

周五还能正常生成草稿，周一就变了结构、语气，还少了关键字段。作者检查了 n8n 工作流、输入和提示词，都没动过。最后发现，调用的模型别名已经指向了新版本。

这篇文章讨论的是一个容易被忽略的上线风险：模型供应商更新了服务，你的应用也可能跟着变。作者给出的办法很工程化：固定版本、记录实际调用信息，用一组真实输入验证升级，再把模型和提示词一起发布、一起回滚。对已经把 LLM 接进业务流程的开发者，这比继续打磨一句提示词更值得先补上。

模型别名为什么也算生产依赖

作者维护并销售 n8n 工作流模板，文中的故障来自这些模板的实际运行。问题不在于模型完全不可用，而在于它仍然返回结果，流程也可能继续执行，输出却已经不符合客户预期。

模型家族名或别名看起来是一个稳定的字符串，背后指向的模型权重却可能变化。你保存了工作流配置，并不等于保存了它实际依赖的行为。

没有固定版本的模型别名，就是没有固定版本的生产依赖。

作者建议，供应商提供带日期的快照时，直接调用具体快照。如果只提供别名，就把它列为需要持续检查的风险，并设置日历提醒。原文没有给出具体供应商、模型版本或接口参数，不能据此照抄出一份配置。

另一个关键动作是补日志。每条任务记录应保存供应商、模型版本、尝试次数和最终状态。作者特别强调：记录供应商实际返回的模型字符串，而不只是请求里填写的名字，因为别名解析后，两者可能不同。

这些信息解决的是排查顺序。质量突然下降时，先确认究竟由哪个版本生成，再检查输入和提示词，能减少盲目修改。但原文没有说明供应商不返回实际版本时怎么办，能否追踪到底，仍取决于服务方提供的信息。

回归测试应该检查什么，才不会天天误报

固定版本能减少未经确认的变化，却不能证明新版本值得升级。作者为此保留了一组固定的真实输入，每次更换模型前都重新运行。

规模是 10 到 20 条，覆盖长而混乱的输入、短而模糊的输入、以前出过问题的边界情况，以及第二种语言。它的价值来自覆盖不同问题形态，不是数量本身。

断言也要换思路。生成文本通常存在随机性，如果要求逐字一致，表达方式稍有变化就会报错。久而久之，测试结果也就没人认真看了。作者检查的是输出必须维持的条件：

• 输出能通过 schema 校验，必填字段齐全，字段类型正确。
• 不出现禁止的形式，例如包裹 JSON 的 Markdown 代码围栏、虚构字段和占位文本。
• 输入中的姓名、日期、金额得到保留，没有被改写成其他事实。
• 长度落在合理区间，摘要变成原来的三倍，或缩成一句话，都需要检查。
• 同一输入运行两次，结构化字段不能互相矛盾。

这里最有用的提醒是：n8n 节点全绿，只能说明流程执行到了相应步骤，不能单独证明业务结果正确。一份 JSON 即使能解析，也可能把日期编错，或让摘要长到无法使用。

不过，测试也有实现成本。姓名、日期、金额怎样从输入里提取并验证，合理长度区间如何确定，原文都没有展开。这些仍需要结合业务补齐。

升级模型要同时验质量、成本和回滚

作者的升级流程不是单独试跑新模型，而是让当前固定版本和候选版本处理同一组输入，再比较输出。

自动断言负责发现明确违规，人工阅读差异负责识别更细的变化。例如，一个字段突然变得冗长，语气出现偏移，某个分类开始被用于不同含义。这些变化未必触发 schema 错误，却可能改变产品体验。

候选版本通过测试之后，输出差异仍然需要有人读过并接受。

回滚也不能只保存旧模型名称。作者把提示词版本和模型版本存成一对，因为针对旧模型调好的提示词，未必适用于新模型。回滚时，两者一起恢复，并保留上一组可用配置，直到新版本在生产中运行一段时间。至于这段时间多长，原文没有给标准。

成本和延迟同样属于验收条件。作者的回归运行会记录每条输入的输入 token、输出 token 和总耗时，并与当前版本比较。工作流一天运行 1000 次时，单次差异就会持续累积；如果质量相当而成本变成两倍，那应当是一次明确的采购取舍。

最终放行条件有三个：原有约束继续成立、输出差异已被接受、成本和延迟没有超预算。任何一项不通过，就继续使用已验证的固定版本。

我的判断

我赞成作者把模型升级纳入发布流程。对依赖结构化输出的自动化任务，固定输入、业务断言、版本日志和成对回滚，比只看几次生成效果更容易形成可重复的判断。

但文章提供的是作者的实践经验，没有给出升级前后的失败率、人工评审结果或成本对照数据，无法证明 10 到 20 条输入对一般团队已经足够。同一输入跑两次，也只能发现部分矛盾，不能说明模型整体稳定。

原文还有一处表述需要澄清：它提到输出通过 schema 却缺少必填字段。如果 schema 已正确声明并严格校验该字段，这两件事不应同时成立。落地时应检查必填约束是否真的写进去了，以及工作流是否确实执行了校验。

和完全依赖人工抽查相比，这套方法能稳定检查明确规则；和只做 schema 校验相比，它又覆盖了事实、长度和表达变化。但人工读差异仍然需要判断力，文章没有提供统一评分标准。固定版本也只是控制升级时机，不能据此推断输出会完全确定，或旧版本会一直可用。

能拿来做什么

• 给现有 n8n 或 Node 调用补齐任务记录，保存请求模型名、供应商实际返回的模型信息、提示词版本、尝试次数和最终状态，让质量问题能追溯到具体调用。
• 从真实失败案例中整理第一组 10 到 20 条回归输入，优先覆盖必填字段、日期金额、异常长度和禁止输出形式，再根据后续故障扩充。
• 每次准备更换模型时，让新旧版本处理相同输入，集中查看断言结果、输出差异、token 用量和耗时，再决定是否发布。
• 把模型版本与提示词版本作为一组配置保存，升级前确认上一组仍可调用，让回滚能够恢复到已经验证过的组合。