我以前总是被重复性的工作淹没。每周一早上，我都得手动从三个不同的 API 拉取数据，排版成报告，然后发到团队的 Slack 频道里。这大概要花 20 分钟，但这种让人灵魂出窍的枯燥日常，总会让你忍不住想：“肯定有更好的办法。”
我试过 Zapier，但免费版的限制实在太多。我也看了 Make，但它的可视化界面感觉又乱又让人摸不着头脑。后来，有个同事提到了 n8n——这是一个开源的工作流自动化工具，我可以免费自部署，而且它基于节点的编辑器用起来真的很顺手。
我决定把周一早上的报告作为我的第一个实战项目。以下就是我如何从零开始，一路搞定第一个能跑通的工作流的全过程，当然，也包括我踩过的那些坑。
初始设置：云端版 vs 自部署
n8n 给你提供了两条路：他们托管的 Cloud 服务，或者通过 Docker/桌面端自部署。对于第一次尝鲜，我注册了 n8n Cloud 的免费试用——不需要绑信用卡，我也不用为了看看这工具好不好用，先去跟 Docker 死磕一番。如果你是那种想从第一天起就把控制权完全握在自己手里的人，可以直接拉取 Docker 镜像（docker run -p 5678:5678 n8nio/n8n），几分钟就能在本地跑起来。
我建议先从 Cloud 版起步摸清门道，等你决定长期用下去了，再迁移到自部署。我后来也是这么干的。
画布：一切发生的地方
当你第一次打开 n8n 时，映入眼帘的是一个干净的画布和一个提示框：你可以“从零开始”，也可以选择一个模板。我点了“从零开始”，进入了工作流编辑器。
画布就是你搭建自动化的地方。你添加节点（也就是各个步骤），用线把它们连起来，数据就会从左往右流动。它是可视化的，但绝不是那种小儿科的积木玩具——它底层的功能非常强大。
第一步：添加触发器
每个工作流都需要一个起点。n8n 把这些起点叫做“触发器”。你可以每次想运行的时候手动去点“执行工作流”（这也就失去了自动化的意义），或者设置一个能自动触发的触发器节点。
对于我的周一报告，我需要一个定时触发器。操作如下：
- 在画布上点击添加第一步。
- 在节点选择器里搜索“Schedule”。
- 选择Schedule Trigger。
右侧打开了节点配置面板，我是这样设置的：
- 触发间隔：Weeks
- 间隔周数：1
- 触发星期：Monday
- 触发小时：9am
- 触发分钟：0
关掉面板，搞定——我的第一个节点就放在画布上了，准备在每周一早上 9 点准时触发。
我踩的第一个坑： 我一开始把触发器设成了“Days”，值填了 7，以为这跟按周触发是一回事。其实不是。“Weeks”选项可以让你指定具体的星期几，这才是我真正需要的。“Days”选项只是从你上次运行的那天开始往后数 7 天，时间一长日期就会慢慢偏移。
第二步：用 NASA 节点获取数据
n8n 官方教程用的是 NASA 节点来获取每日天文图片数据，这是个很好的练手项目。在搭建我实际的工作流之前，我先跟着做了一遍，好弄懂节点是怎么运作的。
- 点击 Schedule Trigger 节点右侧的 + 按钮。
- 搜索“NASA”并添加该节点。
- 选择 APOD（Astronomy Picture of the Day，每日天文图片）操作。
就在这里，我迎来了第一个真正的学习时刻：凭据。
n8n 里的很多 API 节点都需要身份验证。NASA 的 API 是免费的，但你依然需要 API 密钥。n8n 通过一套凭据系统来处理这个——敏感信息是跟工作流分开存储的，这样你就可以放心分享工作流，而不用担心密钥泄露。
设置步骤如下：
- 在 NASA 节点里，点击连接凭据 → 新建。
- 将其命名为“NASA API Key”。
- 粘贴我的 API 密钥（从 api.nasa.gov 获取，大概 30 秒就能搞定）。
- 点击保存。
然后我点击了执行节点来测试。节点亮起了绿灯，我在输出面板里看到了响应数据：APOD 的标题、解释、图片 URL 和元数据。就是在这个瞬间，n8n 彻底让我折服了——亲眼看到真实的数据流过我自己配置的节点，感觉太棒了。
第三步：用表达式处理数据
原始的 API 数据很少能直接满足你的格式需求。这时候 n8n 的表达式系统就派上用场了。
在我实际的周一报告工作流中（不是 NASA 那个教程），我需要从 REST API 拉取数据，提取特定字段，然后排版成 Slack 消息。表达式语法使用 {{ }} 来引用上游节点的数据。
比如，要在下游节点中引用 NASA 节点的 APOD 标题，我可以这样写：
{{ $json.title }}
$json 代表传入的数据项。如果你不确定有哪些字段可以用，n8n 会在表达式编辑器里直接展示上游节点的数据结构——完全不用瞎猜。
我踩的第二个坑： 我试着用 {{$node["NASA"].json.title}} 来引用数据——这是旧语法。虽然能用，但 n8n 已经改用更简洁的 $json 语法来引用当前节点数据了。旧语法在跨节点引用时依然有效，但尽可能还是用新规范吧。
第四步：用 IF 节点添加逻辑
真正的工作流是需要分支逻辑的。在我的报告工作流中，只有在满足特定条件时（比如有新内容需要报告），我才想发送 Slack 通知。
IF 节点（在较新版本中为了处理更复杂的分支，改名叫 Switch 了）可以让你按条件路由数据。我把条件设为检查：
{{ $json.count }} > 0
如果为真，数据就会顺着“true”分支流向我的 Slack 节点；如果为假，工作流直接结束——不发毫无意义的通知。
第五步：连接 Slack
最后一步就是发到 Slack 了。我添加了一个 Slack 节点，用我 Slack 应用的 Bot User OAuth Token 创建了凭据，然后用表达式填入动态数据，编写了消息正文：
📋 每周报告 - {{ $json.date }}
发现新内容：{{ $json.count }}
摘要：{{ $json.summary }}
在搭建工作流的过程中，我逐一测试了每个节点。这非常关键——n8n 允许你只执行单个节点而不用跑完整个链路，这让调试轻松了不是一点半点。
我用血泪换来的实用建议
逐步测试。 千万别一口气建好 10 个节点然后一次性全跑。建一个节点，测一下，确认输出没问题，再加下一个。这帮我省了无数抓瞎的时间。
给节点起个清晰的名字。 “HTTP Request1”和“HTTP Request2”这种名字很快就会让人看晕。我现在会把每个节点重命名为具有描述性的名字，比如“获取每周指标”或者“筛选活跃用户”。
多看数据标签页。 每个节点都会显示它的输入和输出数据。当出问题的时候（迟早会出的），这就是你的第一诊断工具。点开节点，看看进去的是什么、出来的又是什么，通常就能一眼看出问题在哪。
善用数据固定功能。 你可以在节点上“固定”输出数据，这样在测试时它就不会重新执行。当你在调试工作流的第 8 个节点，又不想每次都重新调 API 拉数据时，这功能简直就是救星。
实话实说的局限性
n8n 并非完美无缺。错误处理还能再强大点——单个节点没有内置带指数退避的重试逻辑（你得自己手动搭）；移动端体验基本不存在，这是个纯桌面端工具；虽然节点库很丰富，但偶尔还是会遇到没有专用集成的服务，这时候我就只能退回来用 HTTP Request 节点。
在处理复杂转换时，表达式语言也会显得有点笨重。如果你需要做大量的数据处理，考虑使用 Code 节点（写 JavaScript），而不是硬连一串基于表达式的节点。
我的最终归宿
我最初做的那个周一报告工作流已经连续运行四个月了，没出过一次岔子。后来我又搭建了十几个工作流——Webhook 处理器、邮件解析器、数据库同步等等——而且我已经从 Cloud 版迁移到了一个月 5 美元的 VPS 上自部署的实例。
n8n 完美击中了我的甜区：它足够强大，能搞定真正的自动化；它足够直观，我能直接给非技术的同事看懂工作流是干嘛的；而且它足够开源，我不会被别人的定价模式绑定。
从小处着手。先做个能帮你这周省下 5 分钟的东西。下个月再做个能省 1 小时的。n8n 就是这样把你拿下的——一次消灭一个枯燥的任务。