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

我用 n8n 教自动化，结果自己在干最蠢的活 我用 n8n 教自动化，结果自己在干最蠢的活 Modified October 30, 2025 💡 • 绿色区域: 结果处理 一眼就能看出每个模块在干什么，出问题时也能快速定位。 就像写代码时加注释和空行，虽然不影响功能，但大大提升了可读性。 接下来我逐个模块拆解…… 1、模块 1:图片审批处理流程(蓝色区域) 📌 职责: 把用户上传的截图处理好，发到飞书群 流程: 1. 接收主流程数据 → 拿到邮箱和截图 URL 2. 检查是否包含图片 → 如果没图片， 跳转到"无图片时跳过处理"节点，直接结束(不发送审批请求) 3. 拆分截图数组 → 用户可能传多张图，拆开一张张处理 4. 过滤图片文件 → 只保留 jpg/png，过滤掉 pdf 等非图片文件 5. 获取下载链接 → 调用飞书 API，把 file token 转成临时下载链接 6. 上传到飞书 → 把图片发到飞书群 为什么要拆分数组? 因为用户可能上传多张图片(比如下单截图 + 付款截图)，如果不拆开，飞书 API 没法处理数组格式的图片。拆开后，每张图片单独上传，最终在飞书群里会连续显示，我能一次性看到所有截图。 2、模块 2:等待图片发送 + 发送审批请求(黄色区域) 📌 职责: 等图片全部上传完成后，发送 HITL 审批消息 流程: 1. 发送审核图片通知 → 先在飞书群里发送图片 2. 等待图片发送完成 确保所有图片都上传完毕 3. 发送审批消息(Send and Wait) → 这是 HITL 的核心节点! 这个 Send and Wait 节点就是整个 HITL 方案的灵魂。 这个节点的配置很简单，但功能强大，配置界面长这样: 看起来很简单？确实很简单。但就是这几个配置，实现了“让工作流暂停等待人工决策”的能力。 1）Resource & Operation Code block Plain Text Copy Resource: Message(消息) Operation: Send and Wait ← 这就是 HITL 的魔法 💡 普通的 Send Message 发完消息就继续往下走，不管你回不回复。 Send and Wait 发完消息后会暂停整个工作流，等你点击按钮后才继续。 这就是 HITL 和普通消息通知的本质区别。 2）Receiver ID(接收者) Code block Plain Text Copy Receiver ID Type: Chat ID Receive ID: {{ $('When Executed by Another Workflow').item.json.chat id }} 指定把审批消息发到哪个飞书群。 💡 小技巧 我这里是从主流程传过来的群 ID，这样可以灵活切换审批群。 你也可以直接写死一个固定的群 ID，比如 oc xxx123456。 3）Subject & Message(标题和内容) Code block Plain Text Copy Subject: 🔔 n8n Cloud 自动邀请 Message: 确认 {{ $('When Executed by Another Workflow').item.json.email }} 是否为付费学员或公众号粉丝? 这里用了变量 {{ ... }}，把用户提交的邮箱动态插入到消息里。 实际发出的消息长这样: Code block Plain Text Copy 🔔 n8n Cloud 自动邀请 确认 lunaraitalk@163.com 是否为付费学员或公众号粉丝? ✅ 通过 ❌ 拒绝 干净、清晰、一目了然。 4）Response Type: Approval(审批类型) 这是最关键的部分: Code block Plain Text Copy Type of Approval: Approve and Disapprove (提供"通过"和"拒绝"两个按钮) Approve Button Label: ✅ 通过 Disapprove Button Label: ❌ 拒绝 💡 Response Type 还有其他选项: • Free Text: 用户输入文本回复(比如让用户填写拒绝理由) • Custom Form: 自定义表单(比如让用户填写多个字段) 但对于简单的二选一审批场景，Approval 是最合适的。 工作流会在这里暂停，等我在飞书群里点击按钮。 我可能在写代码，可能在开会，可能在吃饭……不管什么时候，只要我看到消息，5 秒点一下，流程就继续。 🎯 Send and Wait 节点的两个关键特性: 1. 暂停等待: 工作流执行到这里会停下来，不会报错，就静静等着 2. 异步响应: 我点击按钮后，工作流立即继续执行，不需要我一直盯着 这就是 HITL 的核心价值：在需要人类判断的时刻优雅地暂停，在人类做出决定后立即响应。 3、模块 3:审批结果处理与状态更新(绿色区域) 💡 • 绿色区域: 结果处理 一眼就能看出每个模块在干什么，出问题时也能快速定位。 就像写代码时加注释和空行，虽然不影响功能，但大大提升了可读性。 • 绿色区域: 结果处理 一眼就能看出每个模块在干什么，出问题时也能快速定位。 就像写代码时加注释和空行，虽然不影响功能，但大大提升了可读性。 接下来我逐个模块拆解…… 1、模块 1:图片审批处理流程(蓝色区域) 📌 职责: 把用户上传的截图处理好，发到飞书群 流程: 1. 接收主流程数据 → 拿到邮箱和截图 URL 2. 检查是否包含图片 → 如果没图片， 跳转到"无图片时跳过处理"节点，直接结束(不发送审批请求) 3. 拆分截图数组 → 用户可能传多张图，拆开一张张处理 4. 过滤图片文件 → 只保留 jpg/png，过滤掉 pdf 等非图片文件 5. 获取下载链接 → 调用飞书 API，把 file token 转成临时下载链接 6. 上传到飞书 → 把图片发到飞书群 职责: 把用户上传的截图处理好，发到飞书群 流程: 1. 接收主流程数据 → 拿到邮箱和截图 URL 2. 检查是否包含图片 → 如果没图片， 跳转到"无图片时跳过处理"节点，直接结束(不发送审批请求) 3. 拆分截图数组 → 用户可能传多张图，拆开一张张处理 4. 过滤图片文件 → 只保留 jpg/png，过滤掉 pdf 等非图片文件 5. 获取下载链接 → 调用飞书 API，把 file token 转成临时下载链接 6. 上传到飞书 → 把图片发到飞书群 为什么要拆分数组? 因为用户可能上传多张图片(比如下单截图 + 付款截图)，如果不拆开，飞书 API 没法处理数组格式的图片。拆开后，每张图片单独上传，最终在飞书群里会连续显示，我能一次性看到所有截图。 2、模块 2:等待图片发送 + 发送审批请求(黄色区域) 📌 职责: 等图片全部上传完成后，发送 HITL 审批消息 流程: 1. 发送审核图片通知 → 先在飞书群里发送图片 2. 等待图片发送完成 确保所有图片都上传完毕 3. 发送审批消息(Send and Wait) → 这是 HITL 的核心节点! 职责: 等图片全部上传完成后，发送 HITL 审批消息 流程: 1. 发送审核图片通知 → 先在飞书群里发送图片 2. 等待图片发送完成 确保所有图片都上传完毕 3. 发送审批消息(Send and Wait) → 这是 HITL 的核心节点! 这个 Send and Wait 节点就是整个 HITL 方案的灵魂。 这个节点的配置很简单，但功能强大，配置界面长这样: 看起来很简单？确实很简单。但就是这几个配置，实现了“让工作流暂停等待人工决策”的能力。 1）Resource & Operation 💡 普通的 Send Message 发完消息就继续往下走，不管你回不回复。 Send and Wait 发完消息后会暂停整个工作流，等你点击按钮后才继续。 这就是 HITL 和普通消息通知的本质区别。 普通的 Send Message 发完消息就继续往下走，不管你回不回复。 Send and Wait 发完消息后会暂停整个工作流，等你点击按钮后才继续。 这就是 HITL 和普通消息通知的本质区别。 2）Receiver ID(接收者) 指定把审批消息发到哪个飞书群。 💡 小技巧 我这里是从主流程传过来的群 ID，这样可以灵活切换审批群。 你也可以直接写死一个固定的群 ID，比如 oc xxx123456。 小技巧 我这里是从主流程传过来的群 ID，这样可以灵活切换审批群。 你也可以直接写死一个固定的群 ID，比如 oc xxx123456。 3）Subject & Message(标题和内容) 这里用了变量 {{ ... }}，把用户提交的邮箱动态插入到消息里。 实际发出的消息长这样: 干净、清晰、一目了然。 4）Response Type: Approval(审批类型) 这是最关键的部分: 💡 Response Type 还有其他选项: • Free Text: 用户输入文本回复(比如让用户填写拒绝理由) • Custom Form: 自定义表单(比如让用户填写多个字段) 但对于简单的二选一审批场景，Approval 是最合适的。 Response Type 还有其他选项: • Free Text: 用户输入文本回复(比如让用户填写拒绝理由) • Custom Form: 自定义表单(比如让用户填写多个字段) 但对于简单的二选一审批场景，Approval 是最合适的。 工作流会在这里暂停，等我在飞书群里点击按钮。 我可能在写代码，可能在开会，可能在吃饭……不管什么时候，只要我看到消息，5 秒点一下，流程就继续。 🎯 Send and Wait 节点的两个关键特性: 1. 暂停等待: 工作流执行到这里会停下来，不会报错，就静静等着 2. 异步响应: 我点击按钮后，工作流立即继续执行，不需要我一直盯着 这就是 HITL 的核心价值：在需要人类判断的时刻优雅地暂停，在人类做出决定后立即响应。 Send and Wait 节点的两个关键特性: 1. 暂停等待: 工作流执行到这里会停下来，不会报错，就静静等着 2. 异步响应: 我点击按钮后，工作流立即继续执行，不需要我一直盯着 这就是 HITL 的核心价值：在需要人类判断的时刻优雅地暂停，在人类做出决定后立即响应。 3、模块 3:审批结果处理与状态更新(绿色区域) 📌 职责: 根据我的选择(通过/拒绝)，执行不同操作 流程: ① 判断审批结果 看我点的是 ✅ 还是 ❌ ② 如果点了 ✅ 通过: • 可开通 → 更新多维表格状态为"可开通" • 创建用户 → 调用 n8n Create User API • 通过并记录 → 更新多维表格状态为"已申请"，并记录开通时间 ③ 如果点了 ❌ 拒绝: • 拒绝 更新记录状态 → 更新多维表格状态为"拒绝申请"。 职责: 根据我的选择(通过/拒绝)，执行不同操作 流程: ① 判断审批结果 看我点的是 ✅ 还是 ❌ ② 如果点了 ✅ 通过: • 可开通 → 更新多维表格状态为"可开通" • 创建用户 → 调用 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 base url: 你的 n8n 实例地址(比如 https://your n8n.com/api/v1) • N8N API KEY: 在 n8n 后台生成的 API Key • email: 从主流程传过来的用户邮箱 • role: 用户角色，这里设置为 global:member(普通成员) 成功后，n8n 会自动发送邀请邮件给用户，用户点击链接就能激活账号。 💡 需要注意的是，如果是私有化部署，邮件是需要自己主动发送的。 需要注意的是，如果是私有化部署，邮件是需要自己主动发送的。 五、写在后面 搭完这套系统后，我躺在床上，又看到了那熟悉的通知: 但这次不一样。这次的通知，是我主动选择后的结果，而不是被动响应的产物。 这个案例给我最大的启发是: 📌 自动化的终极目标，不是消灭人类，而是解放人类去做更有价值的事。 自动化的终极目标，不是消灭人类，而是解放人类去做更有价值的事。 我不需要再复制粘贴邮箱，但我保留了“判断这个人是否值得给福利”的权利。 系统干重复劳动，我做核心决策。这才是理想的协作关系。 如果你也在搭建自动化流程，下次当你纠结“这个流程是不是不够自动化”的时候，不妨问自己一个问题: 你要追求的是 100% 自动化，还是 100% 的效率? 有时候，让人类回到循环中，反而是最高效的选择。 如果觉得这篇文章有用的话，感谢点赞、在看 ➕ 关注👆，我是林月半子，咱们下篇见！ 🔗 原文链接：https://mp.weixin.qq.com/s/jz9CMajlC aFk9Pix223bg ⏰ 发布时间：2025 10 30 17:08:00 (UTC+8) 作者：林月半子的AI笔记 前段时间我做了个决定，给学员们免费开放官方 n8n 账号。本来是个好事，结果变成了我的噩梦。 操作本身很简单：复制邮箱，点击邀请，发送。30 秒搞定。 但问题是——它会随时打断你。 你正在写代码，思路刚理顺，微信来了：'老师,我的邮箱是……' 你切过去，打开后台，复制，粘贴，发送，回复'已邀请'。 再切回编辑器，刚才想到哪了? 一天来十次。每次 30 秒操作，但每次都要重新找回状态。 到第五天的时候，我盯着屏幕上那行写了一半的代码，脑子一片空白。 我在用 n8n 教人自动化，结果自己在干最割裂的活? 一、天真的第一版方案 然后我突然想起来——n8n 本身不就是个平台吗？是平台就有 API 啊！我为什么要在后台点点点? 我打开 n8n 的文档，果然在 API 页面找到了 POST /users 接口: 试了一下，输入邮箱和角色，返回用户 ID 和邀请状态。完美! 再看下平台数据，也收到了刚刚新邀请的用户。 💡 于是我花了半小时搭了个简单流程: • 多维表格表单做入口 • n8n 监听表单提交 • 调用 n8n 的 Create User API • 自动发送邀请 于是我花了半小时搭了个简单流程: • 多维表格表单做入口 • n8n 监听表单提交 • 调用 n8n 的 Create User API • 自动发送邀请 测试通过，上线。那天晚上我躺在床上，看着手机上的通知——'xxx 已成功加入！'……一条条自动蹦出来。 这才是自动化该有的样子啊！ 二、AI 识别的失败尝试 第二天早上醒来，打开后台。 30 个新注册用户。 我翻了翻名单：6 个是我认识的学员，剩下 24 个……全是陌生邮箱。 表单链接是公开的，被人分享出去了。工作流不会分辨，来一个邀请一个。我辛辛苦苦搭的自动化，变成了“白嫖党的福音”。 我意识到，我得加个验证——上传付费截图或者公众号关注截图，只要证明自己是我们的付费学员，甚至只要是我的公众号粉丝，我都会给出这个福利。 对用户来说，多一个上传步骤而已，对于多维表格而言，无非是增加了一个附件字段。这两块的成本还是很小的。但是我们的 n8n 工作流该怎么调整呢？ 我第一反应是：让大模型识别图片不就行了? 理想很丰满。用户上传的图片千奇百怪: • 小红书下单截图 • 微信聊天记录 • 微信或者支付宝付款凭证 • 飞书入群记录 • 甚至一些意想不到的截图…… 磨合了半天提示词后，我就放弃了这个方案。 三、HITL:让人类回到循环 后来我想通了：这本来就是个审核流程，为什么非要机器做决定? 在这个“AI 万能论”的时代，我们好像总觉得——但凡有人工介入，就是自动化的失败。但真的是这样吗? 🎯 最好的系统，不是 100% 自动化，而是在该自动的地方自动，在该人工的地方人工。 最好的系统，不是 100% 自动化，而是在该自动的地方自动，在该人工的地方人工。 这就是 Human in the Loop(HITL)。 听起来高大上，实际上就是“让人类在关键时刻做决定”。 你的系统处理 95% 的重复劳动，但在那需要判断、需要经验、需要人类直觉的 5% 时刻，它会优雅地暂停，等你一个指令。 这不是缺陷，这是智慧。 n8n 里有很多 HITL 节点，我选了 Lark 节点。 因为飞书就是我的日常工作台，手机电脑都装了，消息来了肯定能第一时间看到。 当然前提是你需要先安装这个社区节点：n8n nodes feishu lark 🎯 有了 HITL 节点，整个流程就简单了: 1. 用户提交表单(邮箱 + 截图) 2. 工作流自动提取信息 3. 把截图发到我的飞书群 4. 我看一眼又或者是群里我的小助理看到了，点个 ✅ 或 ❌ 5. 工作流根据选择，自动发送邀请或拒绝 有了 HITL 节点，整个流程就简单了: 1. 用户提交表单(邮箱 + 截图) 2. 工作流自动提取信息 3. 把截图发到我的飞书群 4. 我看一眼又或者是群里我的小助理看到了，点个 ✅ 或 ❌ 5. 工作流根据选择，自动发送邀请或拒绝 整个审核时间？5 秒不到。比我之前手动操作快了非常多，而且不用切换后台，甚至也能在手机上随时处理。 这才是真正的效率提升。 四、工作流拆解:从表单到飞书的完整链路 听起来很简单？但实际搭建时，我花了不少心思做模块化设计。接下来我把完整的工作流拆解给你看。 整个系统分为 1 个主流程 + 1 个子流程。 主流程负责数据筛选和分发，子流程负责具体的审批处理。虽然节点很多，但我按功能做了模块化分区，用不同颜色的便签纸包裹起来，这样一眼就能看清楚每个模块在干什么。 一）主流程:数据筛选与分发 🎯 这是"调度中心",负责: 1. 接收用户提交的数据(Webhook 或手动触发) 2. 从多维表格读取邮箱和截图 这是"调度中心",负责: 1. 接收用户提交的数据(Webhook 或手动触发) 2. 从多维表格读取邮箱和截图 3. 把数据丢给子流程处理 核心节点: • 表格解析器: 读取用户提交的邮箱、截图 • 查询审批记录: 避免重复处理同一个邮箱 • Execute Workflow: 调用子流程 主流程保持简洁，只管"拿数据 检查 分发"，不涉及具体的审批逻辑。 1、配置入口(Manual) 手动触发节点，用来测试或手动执行整个流程，配置入口里填上以下信息。 2、获取申请数据 从多维表格中读取用户提交的: • 邮箱 • 证明截图(附件 URL) 3、查询审批记录 以下是待审批记录的筛选条件 4、分发记录到子流程(Execute Workflow) 把处理好的数据传递给子工作流。 二）子流程:审批处理的三个阶段 子流程是整个系统的核心，我把它拆成了 3 个功能模块，每个模块负责一个阶段。 你可能注意到，我用不同颜色的便签纸(Sticky Note)把节点包起来了。 这不是装饰，是实用技巧: • 蓝色区域: 图片处理 • 黄色区域: 审批请求