n8n-workflow-automation Skill 入门：让 AI 生成带幂等、重试与人工审批的 n8n 工作流

n8n-workflow-automation 属于给 AI 助手加装的一份技能说明。装上之后，向 Claude Code、OpenClaw 这类 AI 助手描述一句“每周一早上八点汇总上周订单，发一封对账邮件给财务”，助手不会直接拼出一段流程，而是按一套固定顺序追问触发时间、数据来源、去重依据和失败怎么办，最后给出一份能直接导入 n8n 的工作流配置，外加一份运维手册。它解决的不是“能不能自动化”，而是自动化跑起来之后数据悄悄丢了、任务重复执行了、出错了没人知道这一类麻烦。

技能补的是哪一环

n8n 是可视化的流程编排平台，把定时器、HTTP 请求、数据库、邮件、表格这些节点用连线串起来就能跑自动化任务。搭一条流程并不难，难的是把它做成生产环境敢依赖的样子，做到重跑不会写两遍数据、每次运行留下痕迹、中途失败有人收到通知。

n8n-workflow-automation 把这套可靠性要求写成了 AI 助手的行为准则。技能文档里的定位句是“设计并输出带有稳健触发器、幂等性（idempotency，同一请求重复执行结果不变）、错误处理、日志、重试和人工复核队列的 n8n 工作流 JSON”，成功标准也写得很死：工作流必须幂等、必须记录每一次运行、重试要安全、失败项要进复核队列。四条有一条没做到，就算没完成。

技能由开发者 kowl64 发布在 CocoLoop 技能商店，当前版本 v1.0.0，标签涵盖自动化、DevOps、后端、运维等方向。整个技能包只有 2.8 kB，拆开是一份 3.9 kB 的 SKILL.md 和一份 0.6 kB 的运维手册模板，没有任何可执行脚本。

八步设计流程

技能文档规定了固定的设计顺序，AI 助手接到需求后会按这八步推进。

图：n8n-workflow-automation 技能文档定义的八步设计顺序

第一步确认触发方式，定时任务、Webhook 还是手动执行，附带调度时间、时区和并发预期。第二步定义数据契约，把输入长什么样、哪些字段必填、怎么校验写清楚。

第三步是整套流程里最关键的一环，选定去重键，并指定去重记录存在哪里（数据库或表格）。有了它，同一条记录重试多少次都只会被处理一次。第四步植入可观测性，每次运行生成唯一的 run_id，记录开始时间、结束时间、状态行和错误详情。

第五步构建错误处理，要求逐节点设置错误分支、配置带退避的重试、并在最终失败时发出通知。第六步引入人工复核队列（HITL，human-in-the-loop），失败的条目自动写进一张待审清单，需要人工批准后才能重新处理。第七步设置“零静默失败”闸门，处理条数或阈值对不上就直接中断流程并告警，而不是当作没事发生。第八步才是输出，交付可导入的 workflow.json 和配套的 runbook.md。

文档另外规定了四种必须停下来反问用户的情形：目标系统不明确、找不到可用的去重键、凭证策略（环境变量怎么配）没说清、流程需要尚未批准的特权访问。这条边界设计比八步流程本身更有价值，它把信息不全时凭猜测生成配置的风险挡在了输出之前。

输出的两份文件

默认状态下技能是只读的，给出的是一份设计说明，内容包含节点清单、数据契约和失败场景分析，不直接给出配置文件。只有用户明确要 JSON，才会按下面的骨架产出工作流文件：

{
  "name": "<workflow name>",
  "nodes": [ { "name": "Trigger", "type": "n8n-nodes-base.cron", "parameters": {}, "position": [0,0] } ],
  "connections": {},
  "settings": {},
  "active": false
}

注意 "active": false，生成的工作流默认不启用，需要人工在 n8n 界面里确认后才会开始跑。

另一份 runbook.md 来自技能包里的模板，固定八个章节：流程用途、触发方式、输入与凭证、输出去向、幂等设计（去重键是什么、重跑行为如何）、错误处理（重试策略、失败通知、复核队列位置）、日志与审计（run_id、每次运行记什么、日志存哪）、运行检查（预期条数与阈值、什么情况下停机）。这份模板的价值在于把“这条流程出问题找谁、怎么查”变成了必填项，而不是只存在于某位同事的经验里。

装上并跑起来

CocoLoop 页面提供两条路：用 Molili、OpenClaw、Claude Code、Cursor 等支持的客户端一键安装，或者手动下载 2.8 kB 的 zip 包，解压后把 SKILL.md 和 assets 目录放进 AI 助手的技能目录。技能本身是纯 Markdown，没有依赖、不联网、不执行代码，装的过程几乎没有出错空间。

需要提前准备的是提供给助手的信息。技能文档列出的必填项有两类：一是流程意图，包含触发类型、调度时间与时区、以及什么算成功；二是落地目标，结果写到邮件、云盘、表格还是数据库，需要哪些字段。可选项包括已有的工作流 JSON（用于改造）、样例数据、以及去重键的定义。

文档给出的两个示例可以直接照着改：一句“每周一定时运行，发送合规汇总邮件，失败要重试”，产出的是 Cron → 拉取 → 汇总 → 邮件的节点图，外加通往复核队列的错误分支；一句“接收 Webhook，记录每次运行并写入状态行”，产出的是 Webhook → 校验 → 处理 → 追加状态行，出错则记录、通知、入队。

落地前要改的几处

技能给的是设计规范，实际运行时还有几处需要对照 n8n 官方文档调整。

节点类型是旧写法。输出骨架里的 n8n-nodes-base.cron 对应的 Cron 节点，在 n8n 现行文档中已经查不到，官方的定时触发节点换成了 Schedule Trigger，按秒、分、时、天、周、月设置间隔之外也保留了自定义 Cron 表达式。导入后提示节点未知，替换触发节点即可。

时区默认值对国内不友好。n8n 官方文档写明，自托管实例的默认时区是 America/New_York，云端版本会尝试按注册者所在地判断，判断不出则回落到 GMT。技能文档里的示例用的是 Europe/London。国内使用需要在工作流设置里显式指定 Asia/Shanghai，或者用环境变量改掉实例级时区，否则“每周一早八点”跑出来的是别的时间。

指数退避没有现成开关。技能第五步要求重试带退避，而 n8n 节点自带的重试配置只有三项：Retry On Fail 开关、Max Tries 最大次数、Wait Between Tries 等待毫秒数，等待时间是固定值。想要递增等待，得自己在错误分支里串 Wait 节点，或者拆成多级重试。另外，全局失败通知在 n8n 里的标准做法是单独建一条以 Error Trigger 开头的错误工作流，再到业务工作流的 Options → Settings → Error workflow 里挂上，这一步技能文档没有提到。

复核队列的存储要换。技能默认把失败项写进 Google Sheets 或数据库。国内团队用 Google Sheets 并不现实，更稳妥的组合是飞书多维表格或企业微信文档配合 n8n 的 HTTP Request 节点调接口，再不然直接写一张 MySQL 表，配合最小权限的数据库账号。审批数据本身包含原始业务记录，存储位置的权限要单独确认。

平台标注不等于客观事实。CocoLoop 是第三方技能市场，不是 Anthropic 或任何 AI 助手厂商的官方商店，页面上的安全评级、收藏数、“编辑精选”都是平台自己的口径。技能包的 _meta.json 里标注了上游提交地址，指向 GitHub 上一个名为 clawdbot/skills 的仓库，该地址目前公开访问返回 404，无法核对原始提交内容。这类纯 Markdown 技能风险确实有限，但“来源可追溯”这一条暂时打了折扣。

成本与部署选择

技能免费，要算账的是 n8n 本身。

图：n8n 官网定价页公布的各档位价格与执行次数额度

云端版按年付折算，Starter 每月 20 欧元含 2500 次执行，Pro 每月 50 欧元含 10000 次，Business 每月 667 欧元含 40000 次，按 9 月中旬 1 欧元约合 7.7 元人民币粗算，分别约合 154 元、385 元和 5100 元。计费单位是“执行次数”而非节点数，一条二十个节点的流程跑一次也只算一次，流程里节点多少不影响费用。

自托管的社区版从 GitHub 获取，软件免费，成本落在服务器和运维上。官方 Docker 镜像 n8nio/n8n 的拉取量已超过 2.6 亿次，部署资料相当成熟。需要留意许可证：n8n 采用的是 Sustainable Use License，允许内部商业使用、修改和分发，但不是 OSI 认可的开源协议，拿 n8n 做成托管服务转售受限；文件名或目录名带 .ee 的部分另需企业授权。自己团队用没问题，打算包装成产品卖的要先读许可证原文。

对国内团队来说，自托管通常是更合适的选择，数据不出内网，定时任务不受网络波动影响，也绕开了云端版按执行次数计费在高频场景下的成本曲线。

适合谁

技能瞄准的是三类场景：运维和 DevOps 团队需要可审计、可回滚的自动化；风控与合规岗位要求关键操作留痕并有人工复核；n8n 管理员希望统一团队的流程设计规范，避免各人各写一套。金融对账、跨系统数据同步、定期合规报告这类不允许静默失败的任务，最能从这套规范里受益。

文档也明确写了三种不该用的情况：只需要纯代码自动化、不打算引入 n8n 的（改用脚本或 CI 技能）；想绕过安全管控或隐藏审计痕迹的；涉及违规采购的。

局限同样清楚。技能只产出配置，不负责执行，导入 n8n 后连的是真实生产系统，API 密钥授权过宽、重试策略配错引发连锁故障这类风险全部落在部署环境这一侧。能力边界也绑死在 n8n 的节点生态上，配置没法迁移到 Zapier、Make 这类平台。超大规模工作流的可维护性，文档里没有覆盖。

更适合已经在用 n8n、并且遇到过任务静默失败问题的团队。完全没接触过 n8n 的使用者，更稳妥的顺序是先跑通一条简单流程，再来上这套规范，否则八步流程里的术语会先成为障碍。

延伸阅读

• n8n 的功能介绍与入口见站内条目页：n8n 工作流自动化平台，同类平台还可对比 Zapier 与 Make。
• 不清楚技能怎么装、装在哪里的，可以先看 find-skills 入门：让 AI 助手自己发现和安装技能。
• 同样走“企业级规范”路线的技能，还有 terraform-engineer Skill：让 AI 助手按企业级规范写 Terraform，两者的设计思路可以对照着看。