从原始需求找到适合自己的节点 | 简单易懂的现代魔法

type

status

date

slug

summary

了解你需要的外部服务

当你在动手开始选择节点之前，你应该先想清楚自己需要什么节点。这话听上去是一个废话，但是大部分人其实并不能做到这一点。

举个例子来说，如果我想要将稍后阅读的文章存到 Notion 当中阅读，并且我希望能够通过大模型帮我自动分类，在这个场景下，我需要哪些工具？

我需要明确我的阅读器有哪些，这些阅读器是否都能把文章分享到 Notion，如果不能，我要用什么来接收？比如 Telegram 的机器人 or 微信的服务号；

存入 Notion 之后，我希望把这些文章读出来，并且大模型帮我先分类，再回填回 Notion 的 DataBase；

那么上面这个需求，涉及到了什么工具呢？

阅读器；

阅读器不支持分享到 Notion 的时候用来接收文章网址的服务，比如 Telegram Channel；

Telegram Channel 接收到网址，把网址转换成文章内容的服务；

Notion；

大模型；

其中的 2、3、4、5 都需要我们先想清楚用什么工具，市面上有没有类似的工具，想清楚之后，把类似的工具的名称记录下来，并且在 n8n 的节点里面去搜索，如果搜索不到，我们就只能选择自行写一些 Code （

🆓

半开放式节点（Code/HTTP Request）详细介绍）或者换个工具。

不过其中的 3 确实对于没有编程能力的人来说，要找到对应的节点是比较困难的，所以我们特意写了一个比较复杂的案例来说明 3 是怎么实现的：

📕

基于 RSS 的阅读分流器。

理解触发节点和执行节点的区别

执行节点（Actions）不能作为工作流的第一个节点，它只能被其他执行节点 or 触发节点触发执行。通常我们需要的复杂处理逻辑都是由执行节点完成的。

触发节点（Triggers）可以作为工作流的第一个节点，它可以是这个程序的“开始”。定时执行、从聊天软件接收一个信息、在界面上点一下按钮，这些都可以是触发节点。

下面我们以知名软件 Gmail 为例子，来详细说明这两类节点的区别。

触发节点

每个工作流必然有至少一个触发节点，不然这个工作流永远无法被开启。

因为一个工作流不可能无缘无故的自己启动起来，必须要认为设定这个工作流开始执行的条件，也就是 Trigger。

在界面上点击一下 Test Flow 这个本身也是一种触发节点。

n8n 的 Gmail 节点类型中封装了一个触发节点，叫做 On Message Received。

节点实际的含义是系统会每分钟（这个周期可以配置）有没有收到新的邮件，如果收到，就代表这个节点被触发了，它就被执行了，自然而然的它的后续节点，以及整个工作流都会开始执行程序。

执行节点

n8n 中 Gmail 节点类型中封装了 25 个执行节点。

包括给邮件打标签、删除邮件、读取邮件内容、改变邮件的读取状态、发送邮件等等所有你能想到的能在界面上进行的操作，n8n 几乎都可以实现。

这里你可能会有疑问，为什么读取邮件是执行节点而不是触发节点？

因为收到一封新邮件的通知，就好比在手机上收到了 App 的 Push，但是这个时候邮件的具体内容是什么，并不知道，因为人收到了通知，触发了后续的动作，所以收到新邮件的通知本身这件事是一个触发节点。

但是读取邮件内容，是在收到通知之后的行为，这就是一个执行节点，至于读取之后是否要回复，或者是选择把邮件直接扔到垃圾箱，这些都是执行节点。

大部分情况下，执行节点的数量都是远多于触发节点的。

n8n 节点菜单的分类逻辑

n8n 的节点根据是否涉及外部服务和节点的自身作用可以有两个分类维度。

ㅤ	触发节点（Triggers）	执行节点（Actions）
外部节点（需要依赖外部服务 API 的节点）	举例：Gmail 收到新的邮件，触发工作流执行；	举例：通过 Gmail 写一封邮件并且发出去；
自有节点（不依赖外部，或者基于标准协议，如 http/html/os 接口等开发的节点）	举例：点击Test Workflow 按钮，触发工作流执行	举例：内建的逻辑节点，比如条件、判断、循环、数据处理等；

用上面的分类，解读菜单，可以得知如下信息：

Action in an app：外界服务的API 封装的节点，比如 Google Sheets；【外部节点】

罗列了市面上众多的开放服务的节点；
每个外部服务的节点都会被分类成【触发节点】和【执行节点】

数据处理节点：用来做数据的过滤或者转化；【自有节点、执行节点】

Flow 节点：主要是条件、循环、合并等逻辑操作；【自有节点、执行节点】

Core 节点：主要是代码节点；【自有节点、执行节点】

人工智能节点；【为人工智能打造的复合型节点，比较特殊】

添加另一个触发器：【触发节点】

在 n8n 上面点击一下运行按钮，触发程序运行；【自有节点】
外界 API 发来的命令，比如 Telegram 收到一个消息；【外部节点】
每天/每小时固定一个时间执行;【自有节点】
通过 HTTP 请求触发任务；【自有节点】
由另一个 Workflow 触发这个任务；【自有节点】
由聊天框消息触发这个程序运行（AI 对话类节点专用）；【为人工智能打造的复合型节点，比较特殊】
文件变更/Email/等等；【自有节点】

通过搜索+对菜单的分类，我们就可以很容易找到自己需要的节点了。

理解外部服务节点的本质

n8n 的少部分节点是内部节点，不会和外界的 API 做交互，或者只会用公开协议 or 操作系统协议做交互，剩下的大量节点都会和外部 API 做交互，这些服务依赖于外部，是外部服务节点。

下面这张图，左侧是 Gmail 的官方 API 文档上的 API 列表，右图是 n8n 的 Gmail 相关的节点列表。

我们可以很容易个发现一个事情，n8n 能做的事情是 API 的子集，二者基本能遵循一一对应的关系，当然特别复杂的 API 也可能会被 n8n 拆解成 2 个节点，甚至单独包装成一个节点。

以 Mark a message as read 为例子，这个节点的含义是把某个消息设置为已读。

在 Gmail 的官方 API 文档我们可以发现，是否已读的状态是一个官方预设的 Label，所以理论上来说你也可以通过 Remove label from message 或者 add label to message 这两个节点来调节预设的 Label，从而来实现更改已读 or 未读的状态。

但是这个逻辑显然比直接封装一个节点要更加绕，所以 n8n 官方做了这个事情。

看完上面的例子，让我们再思考一下，n8n 的节点，尤其是外部服务节点的本质是什么？

节点的本质是对外部服务（比如 Gmail、Telegram）的公开 API 的封装，这些封装能够带来 2 个好处：

有一些过于抽象的接口设计会被包装的更易懂；