重复劳动最耗人的地方，往往不是单次操作有多难，而是它每周都要做，而且步骤几乎不变。n8n 适合把这类流程画成一张图：某个事件发生，就按固定顺序调用接口、改表格、发通知。这篇文章只做一件事：带你把第一条工作流跑通，并且在它失败时能通知到人。
如果你已经在用代码仓库做定时任务，可以先看 GitHub Actions 自动化流水线，再决定哪一段留在 n8n。
先选一个配得上自动化的任务
不是所有重复工作都值得自动化。第一条工作流用这三条来筛：
- 频率够：每周至少三次。一个月才做一次的事，配置时间通常比省下的时间更长。
- 步骤固定：输入、判断、输出都能写成清单。中间如果经常要”看情况”，先把判断标准写下来，写不下来就先别自动化。
- 失败可补救：跑错了可以手工重做，不会直接给客户发错信、扣错款。
适合起步的例子：把表单提交写进表格并通知群聊；每天把前一天的订单摘要发到频道；把带特定标签的邮件整理成待办。不适合起步的例子：自动给客户退款、自动合并生产数据库。
本地运行还是用云端
两条路都能完成同一张图，差别在数据和运维。
| 方式 | 适合 | 你要自己管的事 | 不适合 |
|---|---|---|---|
| 官方云端 | 先验证流程、没有内网系统 | 账号、额度、凭据授权 | 数据不能出域 |
| 自托管 | 内网接口、调用量大、要审计 | 升级、备份、进程守护、访问控制 | 没人愿意看服务器 |
| 先云端后迁移 | 流程还没稳定 | 导出工作流、重配凭据 | 节点依赖了云端专有功能却没记录 |
建议先在云端或本机用 Docker 跑起来，把图跑通，再决定要不要搬进内网。不要在第一条工作流上同时解决”流程对不对”和”服务器稳不稳”。
本机最快的验证方式是官方镜像。跑起来之后打开界面，创建一个空工作流即可。容器的数据卷要挂出来，否则容器一删，凭据和工作流一起没了。升级前先备份这个卷。
一条最小工作流的四段
把流程收成四段，比一上来拖十几个节点更容易排查。
- 触发器：什么时候跑。手动点击、定时、表单提交、收到 Webhook，先选一个。定时用明确的时区，不要假设服务器时区就是北京时间。
- 取数：把这次要处理的原始数据拿出来。表格的新行、接口的一页结果、邮件的标题和正文。这一步只取数，不做判断。
- 处理：过滤、改字段、调用下一个接口。一次只做一个判断，例如”金额大于 0 才继续”。复杂条件拆成多个 IF，不要把五个规则塞进一个表达式。
- 落地：写入目的地，并发出成功通知。成功通知可以很短，但要带上处理了几条、跳过了几条。
每段之间用 n8n 的执行记录看输入输出。节点显示绿色不代表业务成功：接口可能返回了 200，正文里却是”参数错误”。处理外部接口时，把响应里的业务状态也做成判断。
表达式只用来取上一个节点的字段，例如 {{$json.email}}。不要在表达式里写一段没人看得懂的逻辑。看不懂的逻辑，改成一个单独的 Code 节点，并在节点名称上写清它在做什么。
凭据、重试和错误分支
凭据不要写进节点参数的明文里。用 n8n 的凭据库，按服务分开：表格一个、即时通讯一个、业务接口一个。人员变动时，只轮换对应的凭据，不用打开每张图去找密钥。
外部接口会偶发超时。对”读取”类节点打开重试，次数两到三次，间隔几十秒。对”写入、发信、扣减”类节点不要盲目重试，先确认对方接口是否幂等。不幂等的操作重试一次，就可能发出两封邮件或写下两行重复数据。
错误处理用分支，而不是指望自己看见执行记录：
- 主路径成功：写结果，必要时发一条简短成功通知。
- 主路径失败：走错误输出，把节点名、错误信息和原始输入发给负责的人。
- 能跳过的单条脏数据：记一条失败明细，继续处理后面的记录，不要因为一行坏数据让整批停住。
原始输入一定要留底。第二天有人问”这条为什么没同步”，只靠记忆是对不上的。
失败时怎么通知到人
没有告警的自动化，等于多了一个会悄悄停掉的岗位。通知里至少包含三件事：哪张工作流、哪一个节点、这次输入的关键字段（例如订单号或邮箱，不要把整份客户资料贴进群）。
通知渠道用团队已经在看的地方。如果平时用即时通讯处理故障，就发到那个频道，并 @ 到具体的人，而不是丢进一个没人看的”机器人”频道。同一类错误要做节流：接口宕机时，一分钟发五十条和发一条”连续失败，已暂停”相比，后者才有人会处理。
连续失败超过阈值时，应暂停触发器，而不是一直重试。恢复之后手工重放留底的输入，确认补跑的结果没有重复写入。
什么时候改用代码流水线
n8n 适合”连接现成服务”。下面这些情况，继续堆节点会更难维护，应改到 GitHub Actions 或一段小脚本里：
- 逻辑超过两三层判断，还夹着循环和临时文件。
- 需要代码审查、测试和回滚，而不是只在界面里点保存。
- 依赖仓库里的代码、密钥和构建产物。
- 执行时间很长，界面里的单次执行记录已经很难读。
一个务实的分法：n8n 负责接收事件和通知人，真正的计算放到仓库里的脚本。两边用 Webhook 衔接。这样图保持短，复杂逻辑留在能被审查的代码里。更细的工具取舍可以对照 Make 和 n8n 怎么选。
上线前用三组真实数据各跑一遍：一条正常、一条缺字段、一条下游接口失败。三组都符合预期，再把触发器从”手动”改成”定时”或”事件”。
常见问题
n8n 必须自托管吗？
不是。想先验证流程，用云端即可。数据不能离开内网、或者调用量已经大到云端额度不划算时，再自托管。自托管要同时安排备份和升级，不要只把容器跑起来就当作完成。
第一条工作流应该选多复杂的任务？
选每周至少三次、步骤固定、失败了也能手工补上的任务。需要人临时拍板的流程，先把拍板标准写成清单；写不出来，就还没到自动化的时候。
节点报错时已经处理的数据会丢吗？
已经成功的上游节点不会自动重做。所以写入类操作要能识别重复：用业务上的唯一编号做去重，而不是每次都追加一行。失败的原始输入要另外存一份，方便补跑。
和 GitHub Actions 冲突吗？
不冲突。连表格、邮件、群通知，n8n 更快。要跑仓库里的代码、做定时构建，用 GitHub Actions。很多团队两套一起用，用事件把它们接起来。