n8n实战：搭建AI邮件摘要并推送Slack的自动化工作流

一个来自Upwork的真实客户需求：每当Gmail收到新邮件时，用AI自动生成摘要、识别待办事项、判断优先级，并把结果推送到Slack。这类看似简单的自动化，恰恰是自由职业者变现、也是忙碌创始人解放双手的典型场景。本文基于一位YouTube创作者的完整构建过程，拆解如何用n8n从零搭建这套工作流。

从客户需求到流程映射

客户的原始描述很直白："我需要一个简单的自动化，用AI总结收到的邮件。每当Gmail收到新邮件，自动读取内容、用OpenAI生成简短摘要、识别待办事项，然后把摘要通过Slack发给我。"客户还明确表示工具不限，Make.com、Zapier或其他均可，关键是简单、可靠、后期易于修改。

构建自动化前最容易被忽视、却最关键的一步是"流程映射"。创作者强调，拿到任何项目都不要急着打开工具硬写，而是先逐行阅读需求、把流程画出来。可以用draw.io、Miro这类工具，甚至一支笔一张纸就够。映射的价值在于：当你清楚每个节点的职责和顺序后，实际搭建时就不会手忙脚乱。

按需求逐句拆解后，整个流程被映射为四个核心节点：Gmail触发器 → 编辑/整理节点（Edit/Set）→ 基础LLM链（Basic LLM Chain）→ Slack发送节点。每个节点用不同颜色标注，形成清晰的处理链路。

Gmail触发器与数据清洗

第一个节点是Gmail触发器。n8n的Gmail节点只有一个触发选项"Message Received"，用于监听新邮件。创作者将轮询时间设为每小时检查一次，并添加了只抓取未读邮件的过滤条件，确保不会重复处理。

触发器抓到邮件后会返回大量字段——ID、threadId、snippet、payload等等，信息冗杂。这就引出了第二个关键节点：Edit/Set节点（编辑字段）。它的作用是清洗数据，只保留我们真正需要的字段：发件人姓名、邮箱地址、邮件正文、日期和主题。

这里有个实用技巧值得单独说明。Gmail返回的发件人字段往往把姓名和邮箱拼在一起（如"Adaptory Awali <email>"）。创作者用.split()方法以<符号为分隔符拆分：数组下标[0]取姓名，[1]取邮箱。这涉及JSON数组的概念——计算机从0开始计数，这也是初学者最容易困惑的地方。此外，日期字段通过.format()方法格式化为DD-MM-YYYY的易读形式，省去客户辨认长串时间戳的麻烦。

n8n的触发器有两种工作模式：Webhook触发（事件实时推送）和轮询触发（Polling）。Gmail节点采用的是轮询模式，即n8n按设定的时间间隔主动去查询Gmail API，而非Gmail主动通知n8n。这意味着邮件到达与工作流执行之间存在最长等于轮询间隔的延迟——设为每小时检查一次，最坏情况下延迟接近60分钟。如果业务对实时性要求较高，可以缩短轮询间隔（代价是消耗更多API调用配额），或改用支持Webhook推送的邮件服务。对于本文场景（日常邮件摘要），每小时一次的延迟完全在可接受范围内，也是兼顾成本与效率的合理默认值。

用Basic LLM Chain而非AI Agent

到了AI处理环节，创作者提出一个重要判断：并非所有自动化都需要AI Agent。当任务只是生成摘要、分类或路由消息，而不需要AI主动回复或调用工具时，用更轻量的"Basic LLM Chain"节点就足够了。这是区分n8n两类AI节点的关键经验。

Basic LLM Chain需要附加一个大模型作为"大脑"，这里挂载的是OpenAI模型。配置时将连接方式从chat trigger改为"define below"，以便手动填入用户消息（User Message）和系统提示词（System Prompt）。

用户消息中映射了前面清洗好的发件人、邮箱、主题、日期和正文字段——此时Edit节点的价值彻底体现：所有字段整齐可用，无需在海量原始数据里翻找。系统提示词则给AI下达三项明确指令：

• 用两到三句话写出简洁摘要
• 提取邮件中提到的所有待办事项或任务
• 判断优先级（高/中/低）

并规定输出格式为"摘要—待办事项—优先级"的结构化排版，要求专业、清晰、简洁。执行后，AI准确返回了邮件要点，例如"对方报告首页和关于页设计已完成待审阅，待办为审阅首页、审阅关于页，优先级为中等"。

AI Agent与Basic LLM Chain的本质区别在于"自主决策能力"。AI Agent内置了一个循环推理机制（ReAct循环），它能够自主决定调用哪些工具、执行多步骤操作，并根据中间结果动态调整下一步行动——例如先查询数据库、再发送邮件、最后更新日历。这种灵活性的代价是更高的延迟、更多的Token消耗，以及更难以预测的行为。

Basic LLM Chain则是一个单向的"输入→模型→输出"管道，没有工具调用能力，也不会自主迭代。对于输入确定、输出格式固定的任务（如文本摘要、情感分类、内容提取），这种简单结构反而更稳定、更快速、成本也更低。在n8n生态中，错误地使用AI Agent来完成本可用LLM Chain处理的任务，是初学者最常见的过度工程化问题之一。

推送到Slack收尾

最后一个节点是Slack消息发送。先在Slack中建好一个频道（示例中命名为"ai summary"），连接账号后选择"Send a Message"动作，目标指向该频道。

消息文本中依次映射发件人姓名、邮箱、主题、正文和AI摘要字段，形成一条结构清晰的通知。执行工作流后，Slack频道即收到完整的摘要卡片——包含发件人信息、邮件主题、AI生成的摘要、待办事项和优先级。整套流程从邮件进入到Slack通知，几乎在眨眼间完成。

这套工作流的商业价值

创作者在结尾点出了这类项目的变现思路。这套自动化本质上在做行政助理或虚拟助理（VA）的工作——帮忙筛选、总结邮件并提炼行动项。对于忙碌的创始人或企业主，与其雇人盯邮箱，不如用一套n8n工作流自动完成。

因此它既可以作为Upwork上的接单服务直接交付给客户，也可以打包成产品推荐给需要行政支持的目标用户。构建逻辑简单、可靠且易于修改，恰好满足了原始需求中"simple, reliable, easy to modify"的三个要点。