手动运行成功后，下一步应检查重复输入和失败情况。本文以 n8n AI 启动模板 为学习环境，设计一条只保存练习结果的流程。下面的记录结构是本站建议，不是模板自带的业务功能。

给每条材料一个稳定编号

为输入增加 source_id，例如 test-001。相同材料再次进入时沿用编号；内容变化则增加版本或内容摘要。不要用“本次运行时间”代替材料编号，否则每次都会被当作新内容。

source_id: test-001
version: 1
status: pending / processing / succeeded / failed
attempts: 0
result: 空
last_error: 空

在练习用表或数据库中保存记录。若可能并发执行，应由存储层用唯一约束或原子操作保证占用；简单的“先查询再插入”在两个执行同时开始时可能失效。

把判断放到模型调用之前

  1. 读取输入编号与版本，检查是否已经成功完成。
  2. 成功记录直接返回已有结果，不再次调用模型。
  3. 新记录标记处理中，再执行模型步骤。
  4. 成功后保存结果；失败后保存阶段、错误和次数。

按当前 n8n 版本的节点设置选择错误处理方式，再连接相应分支。不要只在最后增加一个“成功”字段，导致上游失败也被记为成功。

区分哪些错误值得重试

短暂连接失败可以在等待后有限次重试；字段缺失、凭据错误或不支持的参数，应先修复输入与配置。给重试次数设置上限。请求超时有时代表本地未收到答案，远端仍可能已处理并计费，因此不能把重试次数视为免费次数。

用三条记录做验收

先提交 test-001，再提交相同版本；确认第二次沿用结果。然后提交一个正文为空的 test-002，确认它被记录为失败或待修复，而不是发布空内容。最后修复正文并从明确入口重新执行，检查是否保留上次失败原因。

常见问题

保存结果后还要自动发布怎么办？

把生成与发布分成可追踪阶段；发布也需要自己的去重标识，防止保存失败后的重试重复创建文章。

执行日志能永久当数据库吗？

执行记录可能按保留策略清理。业务状态应保存到自己管理的持久存储中，并验证重启后仍能读取。

具体演练：先做重复判断，再接模型

本练习需要已可访问的 n8n 和可持久保存记录的数据表或数据库。先只处理测试数据，不连接正式发布节点。具体节点和字段以你的 n8n 版本为准；官方文档提供当前版本的数据表与错误处理说明。

  1. 创建测试记录表，准备 source_id、version、status 和 result 字段；为 source_id 与 version 的组合建立唯一约束，或使用所选存储提供的原子去重机制。
  2. 新建手动触发工作流，在 Edit Fields 节点设置 source_id 为 test-001、version 为 1、body 为一段短测试文本。
  3. 添加数据库查询节点，按 source_id 和 version 查询记录。用条件节点判断是否已有 succeeded：是则返回已有 result；否则进入处理分支。
  4. 处理分支应先以原子方式占用该编号，再调用已配置的模型。成功后保存 result 和 succeeded；失败时保存 failed 与错误原因。具体事务和错误分支依赖你采用的数据库与节点，不要假设简单先查询再插入能够避免并发重复。
  5. 连续运行同一编号两次，检查第二次没有再次执行模型；更改 version 为 2，再运行，应作为新版本处理。
  6. 把 body 清空并执行，确认输入验证使任务失败且不会保存成功结果；修正后再测试重试。

记录每次的输入编号、版本、执行状态与模型调用次数。仅靠 n8n 的临时执行历史无法替代持久业务状态；真正部署前还需测试并发占用、超时和恢复。

项目来源与许可

原项目：n8n-io/self-hosted-ai-starter-kit。许可说明：Apache-2.0（启动模板；各组件另有许可），详见原仓库许可与说明。仓库与许可核验于 2026-10-31。本文为本站编写的中文导读与练习设计，不是原教程逐字翻译；未在读者环境执行，运行结果需自行核对。