我用 n8n 教自动化，结果自己在干最蠢的活作者开放 n8n 账号，API 邀请因表单外传被滥用。放弃 AI 图像识别，

前段时间我做了个决定，给学员们免费开放官方 n8n 账号。本来是个好事，结果变成了我的噩梦。

操作本身很简单：复制邮箱，点击邀请，发送。30 秒搞定。

但问题是——它会随时打断你。

你正在写代码，思路刚理顺，微信来了：'老师,我的邮箱是……' 你切过去，打开后台，复制，粘贴，发送，回复'已邀请'。再切回编辑器，刚才想到哪了?

一天来十次。每次 30 秒操作，但每次都要重新找回状态。

到第五天的时候，我盯着屏幕上那行写了一半的代码，脑子一片空白。

我在用 n8n 教人自动化，结果自己在干最割裂的活?

一、天真的第一版方案

然后我突然想起来——n8n 本身不就是个平台吗？是平台就有 API 啊！我为什么要在后台点点点?

我打开 n8n 的文档，果然在 API 页面找到了 POST /users 接口:

试了一下，输入邮箱和角色，返回用户 ID 和邀请状态。完美!

再看下平台数据，也收到了刚刚新邀请的用户。

于是我花了半小时搭了个简单流程:

多维表格表单做入口
n8n 监听表单提交
调用 n8n 的 Create User API
自动发送邀请

测试通过，上线。那天晚上我躺在床上，看着手机上的通知——'xxx 已成功加入！'……一条条自动蹦出来。

这才是自动化该有的样子啊！

二、AI 识别的失败尝试

第二天早上醒来，打开后台。

30 个新注册用户。

我翻了翻名单：6 个是我认识的学员，剩下 24 个……全是陌生邮箱。

表单链接是公开的，被人分享出去了。工作流不会分辨，来一个邀请一个。我辛辛苦苦搭的自动化，变成了“白嫖党的福音”。

我意识到，我得加个验证——上传付费截图或者公众号关注截图，只要证明自己是我们的付费学员，甚至只要是我的公众号粉丝，我都会给出这个福利。

对用户来说，多一个上传步骤而已，对于多维表格而言，无非是增加了一个附件字段。这两块的成本还是很小的。但是我们的 n8n 工作流该怎么调整呢？

我第一反应是：让大模型识别图片不就行了?

理想很丰满。用户上传的图片千奇百怪:

小红书下单截图
微信聊天记录
微信或者支付宝付款凭证
飞书入群记录
甚至一些意想不到的截图……

磨合了半天提示词后，我就放弃了这个方案。

三、HITL:让人类回到循环

后来我想通了：这本来就是个审核流程， 为什么非要机器做决定?

在这个“AI 万能论”的时代，我们好像总觉得——但凡有人工介入，就是自动化的失败。但真的是这样吗?

最好的系统，不是 100% 自动化，而是在该自动的地方自动，在该人工的地方人工。

这就是 Human-in-the-Loop(HITL)。

听起来高大上，实际上就是“让人类在关键时刻做决定”。

你的系统处理 95% 的重复劳动，但在那需要判断、需要经验、需要人类直觉的 5% 时刻，它会优雅地暂停，等你一个指令。

这不是缺陷，这是智慧。

n8n 里有很多 HITL 节点，我选了 Lark 节点。

因为飞书就是我的日常工作台，手机电脑都装了，消息来了肯定能第一时间看到。

当然前提是你需要先安装这个社区节点：n8n-nodes-feishu-lark

有了 HITL 节点，整个流程就简单了:

用户提交表单(邮箱 + 截图)
工作流自动提取信息
把截图发到我的飞书群
我看一眼又或者是群里我的小助理看到了，点个 ✅ 或 ❌
工作流根据选择，自动发送邀请或拒绝

整个审核时间？5 秒不到。比我之前手动操作快了非常多，而且不用切换后台，甚至也能在手机上随时处理。

这才是真正的效率提升。

四、工作流拆解:从表单到飞书的完整链路

听起来很简单？但实际搭建时，我花了不少心思做模块化设计。接下来我把完整的工作流拆解给你看。

整个系统分为 1 个主流程 + 1 个子流程。

主流程负责数据筛选和分发，子流程负责具体的审批处理。虽然节点很多，但我按功能做了模块化分区，用不同颜色的便签纸包裹起来，这样一眼就能看清楚每个模块在干什么。

一）主流程:数据筛选与分发

这是"调度中心",负责:

接收用户提交的数据(Webhook 或手动触发)
从多维表格读取邮箱和截图
把数据丢给子流程处理

核心节点:

表格 解析器 : 读取用户提交的邮箱、截图
查询审批记录: 避免重复处理同一个邮箱
Execute Workflow : 调用子流程

主流程保持简洁，只管"拿数据-检查-分发"，不涉及具体的审批逻辑。

1、配置入口(Manual)

手动触发节点，用来测试或手动执行整个流程，配置入口里填上以下信息。

2、获取申请数据

从多维表格中读取用户提交的:

邮箱
证明截图(附件 URL)

3、查询审批记录

以下是待审批记录的筛选条件

{
   "filter":{
      "conjunction":"and",
      "conditions":[
         {
            "field_name":"开通权限",
            "operator":"doesNotContain",
            "value":[
               "可开通","拒绝申请"
            ]
         },
         {
            "field_name":"状态",
            "operator":"doesNotContain",
            "value":[
               "申请中","已申请"
            ]
         },
         {
            "field_name": "您的邮箱",
            "operator": "isNotEmpty",
            "value": []
         }
      ]
   }
}

4、分发记录到子流程(Execute Workflow )

把处理好的数据传递给子工作流。

二）子流程:审批处理的三个阶段

子流程是整个系统的核心，我把它拆成了 3 个功能模块， 每个模块负责一个阶段。

你可能注意到，我用不同颜色的便签纸(Sticky Note)把节点包起来了。

这不是装饰，是实用技巧:

蓝色区域: 图片处理
黄色区域: 审批请求
绿色区域: 结果处理

一眼就能看出每个模块在干什么，出问题时也能快速定位。

就像写代码时加注释和空行，虽然不影响功能，但大大提升了可读性。

接下来我逐个模块拆解……

1、模块 1:图片审批处理流程(蓝色区域)

职责: 把用户上传的截图处理好，发到飞书群

流程:

接收主流程数据 → 拿到邮箱和截图 URL
检查是否包含图片 → 如果没图片，跳转到"无图片时跳过处理"节点，直接结束(不发送审批请求)
拆分截图数组 → 用户可能传多张图，拆开一张张处理
过滤图片文件 → 只保留 jpg/png，过滤掉 pdf 等非图片文件
获取下载链接 → 调用飞书 API，把 file_token 转成临时下载链接
上传到飞书 → 把图片发到飞书群

为什么要拆分数组?

因为用户可能上传多张图片(比如下单截图 + 付款截图)，如果不拆开，飞书 API 没法处理数组格式的图片。拆开后，每张图片单独上传，最终在飞书群里会连续显示，我能一次性看到所有截图。

2、模块 2:等待图片发送 + 发送审批请求(黄色区域)

职责: 等图片全部上传完成后，发送 HITL 审批消息

流程:

发送审核图片通知 → 先在飞书群里发送图片
等待图片发送完成 -> 确保所有图片都上传完毕
发送审批消息(Send and Wait) → 这是 HITL 的核心节点!

这个 Send and Wait 节点就是整个 HITL 方案的灵魂。

这个节点的配置很简单，但功能强大，配置界面长这样:

看起来很简单？确实很简单。但就是这几个配置，实现了“让工作流暂停等待人工决策”的能力。

1）Resource & Operation

Resource: Message(消息)
Operation: Send and Wait  ← 这就是 HITL 的魔法

普通的 Send Message 发完消息就继续往下走，不管你回不回复。

Send and Wait 发完消息后会暂停整个工作流， 等你点击按钮后才继续。

这就是 HITL 和普通消息通知的本质区别。

2）Receiver ID(接收者)

Receiver ID Type: Chat ID
Receive ID: {{ $('When Executed by Another Workflow').item.json.chat_id }}

指定把审批消息发到哪个飞书群。

小技巧

我这里是从主流程传过来的群 ID，这样可以灵活切换审批群。

你也可以直接写死一个固定的群 ID，比如 oc_xxx123456。

3）Subject & Message(标题和内容)

Subject: 🔔 n8n Cloud 自动邀请

Message: 确认 {{ $('When Executed by Another Workflow').item.json.email }} 是否为付费学员或公众号粉丝?

这里用了变量 {{ ... }}，把用户提交的邮箱动态插入到消息里。

实际发出的消息长这样:

🔔 n8n Cloud 自动邀请

确认 lunaraitalk@163.com 是否为付费学员或公众号粉丝?  

✅ 通过  ❌ 拒绝

干净、清晰、一目了然。

4）Response Type: Approval(审批类型)

这是最关键的部分:

Type of Approval: Approve and Disapprove
  (提供"通过"和"拒绝"两个按钮)

Approve Button Label: ✅ 通过
Disapprove Button Label: ❌ 拒绝

Response Type 还有其他选项:

Free Text: 用户输入文本回复(比如让用户填写拒绝理由)
Custom Form: 自定义表单(比如让用户填写多个字段)

但对于简单的二选一审批场景，Approval 是最合适的。

工作流会在这里暂停， 等我在飞书群里点击按钮。

我可能在写代码，可能在开会，可能在吃饭……不管什么时候，只要我看到消息，5 秒点一下，流程就继续。

Send and Wait 节点的两个关键特性:

暂停等待: 工作流执行到这里会停下来，不会报错，就静静等着
异步响应: 我点击按钮后，工作流立即继续执行，不需要我一直盯着

这就是 HITL 的核心价值：在需要人类判断的时刻优雅地暂停，在人类做出决定后立即响应。

3、模块 3:审批结果处理与状态更新(绿色区域)

职责: 根据我的选择(通过/拒绝)，执行不同操作

流程:

① 判断审批结果

看我点的是 ✅ 还是 ❌

② 如果点了 ✅ 通过:

可开通 → 更新多维表格状态为"可开通"
创建用户 → 调用 n8n Create User API
通过并记录 → 更新多维表格状态为"已申请"，并记录开通时间

③ 如果点了 ❌ 拒绝:

拒绝-更新记录状态 → 更新多维表格状态为"拒绝申请"。

重点说一下"创建用户"这个节点:

这是整个流程的最终落地点——前面的审批、判断，最终都是为了执行这一步。

说明:

n8n_base_url: 你的 n8n 实例地址(比如 https://your-n8n.com/api/v1)
N8N_API_KEY: 在 n8n 后台生成的 API Key
email: 从主流程传过来的用户邮箱
role: 用户角色，这里设置为 global:member(普通成员)

成功后，n8n 会自动发送邀请邮件给用户，用户点击链接就能激活账号。

需要注意的是，如果是私有化部署，邮件是需要自己主动发送的。

五、写在后面

搭完这套系统后，我躺在床上，又看到了那熟悉的通知:

但这次不一样。这次的通知，是我主动选择后的结果，而不是被动响应的产物。

这个案例给我最大的启发是:

自动化的终极目标，不是消灭人类，而是解放人类去做更有价值的事。

我不需要再复制粘贴邮箱，但我保留了“判断这个人是否值得给福利”的权利。

系统干重复劳动，我做核心决策。这才是理想的协作关系。

如果你也在搭建自动化流程，下次当你纠结“这个流程是不是不够自动化”的时候，不妨问自己一个问题:

你要追求的是 100% 自动化，还是 100% 的效率?

有时候，让人类回到循环中，反而是最高效的选择。

我用 n8n 教自动化，结果自己在干最蠢的活

一、天真的第一版方案​

二、AI 识别的失败尝试

三、HITL:让人类回到循环

四、工作流拆解:从表单到飞书的完整链路

一）主流程:数据筛选与分发

1、配置入口(Manual)

2、获取申请数据

3、查询审批记录

4、分发记录到子流程(Execute Workflow )

二）子流程:审批处理的三个阶段

1、模块 1:图片审批处理流程(蓝色区域)

2、模块 2:等待图片发送 + 发送审批请求(黄色区域)

1）Resource & Operation

2）Receiver ID(接收者)

3）Subject & Message(标题和内容)

4）Response Type: Approval(审批类型)

3、模块 3:审批结果处理与状态更新(绿色区域)

五、写在后面

一、天真的第一版方案