n8n AI Workflow 实战：Gmail 邮件摘要自动写入 Google Sheets

适合谁读

• 每天被几百封工作邮件、订阅推送和推广广告淹没，急需建立物理过滤器释放认知宽度的效率折腾控。
• 想要利用开源工具和 AI 落地业务流，但又对商业 API 计费极其敏感、要求极致控制成本的独立项目经理。
• 希望将自托管的 n8n 实力与实际商业办公场景结合的小白全栈开发者。

2026 年的自动化不再是 If-Else，而是语义路由的胜利

传统的工作流自动化只是单向的 If-Else 规则拼贴。在这种老旧的架构里，你要为不同的发件人、不同的关键词写上几十个生硬的分支判断。一旦某封邮件的语气变了，或者标题换了个写法，你的 If-Else 链条就会直接崩溃。

而在接入了大模型（LLM）的现代工作流中，我们是在让 n8n 进行语义维度的推理和自动分发。我们不再关心邮件的具体文字组合，而是把整个 Gmail 收件箱看作一条不断流入的非结构化文本数据流。

通过把 n8n、OpenAI 和 Google Sheets 组合在一起，我们建立起了一个物理意义上的「数字漏斗」。它会把那些充斥着客套话、冗余信息的长邮件缩减为精炼的三句话摘要，并自动梳理出里面的待办事项（Action Items），最后以格式严整的数据库行格式保存在表格中。

每天早上，我不需要再去一个个点开繁琐的 Gmail 网页，只需泡一杯茶，扫一眼我的 Google Sheets 仪表盘，就能对所有需要处理的高优事务了然于胸。这正是语义自动化带给独立开发者的极致提效。

四层数字漏斗架构

在这个实战项目中，我们设计了一个四层的处理管道，将非结构化邮件加工为干净的数据报表：

第一层是 Trigger 层（触发层）。我们使用 n8n 官方的 Gmail Trigger，每隔十五分钟自动扫描收件箱。

第二层是 Filtering 层（物理过滤层）。这一步发生在大模型之前，目标是把占收件箱 70% 的推广邮件和订阅通知无情过滤掉，避免它们浪费我们宝贵的 OpenAI API 额度。

第三层是 Processing 层（AI 理解层）。我们使用 OpenAI Chat Model 节点，通过结构化 Prompts 约束大模型返回纯净的 JSON 文本。

第四层是 Storage 层（存储与去重层）。在这里，我们会利用 Google Sheets 节点对邮件进行防重复执行过滤，并将清洗好的结构化数据追加写入对应的行。

关键配置：物理过滤与节点设计清单

要实现这个数字漏斗，我们需要在 n8n 中编排以下 5 个核心节点，并对关键参数进行调优。

1. Gmail Trigger 节点配置

第一步是配置你的 Gmail 账号授权（OAuth2）。在 Google Cloud Console 中创建好凭证后绑定。

为了不让你的 Token 账单破产，千万不要把所有的未读邮件都扔给 OpenAI。我们必须在 Trigger 节点的 Query 字段中配置物理过滤表达式：

is:unread -category:social -category:promotions -from:noreply@

这个 Query 表达式的物理效果是：只拉取未读状态的邮件，并且排除掉社交网络提醒（如 LinkedIn）、推广邮件以及所有以 noreply 开头的自动化系统通知。这在源头上帮我们干掉了绝大多数无价值噪音。

2. Google Sheets Lookup (去重前置过滤)

在拉取到邮件后，我们需要做一道去重防护闸。在分布式环境中，网络波动可能会导致同一个 Gmail 节点被触发两次。

我们在 Google Sheets 节点之后，插入一个 Lookup 节点，根据拉取到的邮件唯一标识 messageId 在表格的最后一列进行搜索。如果搜索到了结果，说明这封邮件在之前的轮询中已经被处理过了，工作流直接进入 Stop 节点；如果未搜索到结果，则继续往后传递。

3. OpenAI Chat Model (语义摘要节点)

这是整个漏斗的算力中枢。我们需要将模型选择为 gpt-4o-mini 或 gpt-4o，并将 Temperature 调低至 0.1。温度越低，大模型的输出就越有确定性，不会出现天马行空的编造。

我们在 OpenAI 节点的 Prompt 中，需要传入邮件的发件人、主题以及正文内容。同时，为了确保后续写入 Google Sheets 不会因为格式错乱报错，我们必须在 n8n 中开启 JSON Schema 约束，强迫大模型只能返回我们定义的 JSON 数据结构：

{
  "type": "object",
  "properties": {
    "summary": {
      "type": "string",
      "description": "用三句中文话精炼总结邮件的核心内容"
    },
    "action_items": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "从邮件中提取的具体待办事项，如果没有则返回空数组"
    },
    "priority": {
      "type": "string",
      "enum": ["low", "medium", "high"],
      "description": "根据邮件紧急程度分类的优先级"
    }
  },
  "required": ["summary", "action_items", "priority"]
}

4. Google Sheets Add Row (存储层)

当大模型输出了结构化的 JSON 后，我们可以直接把解析出来的字段映射到 Google Sheets 的表格列中。

我们设计的表格字段包含：

• 收到日期 (Date)：={{ $json.messageDate }}
• 发件人 (From)：={{ $json.from }}
• 邮件主题 (Subject)：={{ $json.subject }}
• 智能摘要 (Summary)：={{ $json.summary }}
• 代办事项 (Action Items)：={{ $json.action_items.join('\n') }}
• 优先级 (Priority)：={{ $json.priority }}
• 邮件 ID (MessageID)：={{ $json.messageId }}

通过追加写入，新数据会呈流水账格式整齐保存在云端表格中。

5. Prompt 工程：System Prompt 全文配置

在 n8n 的 OpenAI 节点中，System Prompt 的质量直接决定了大模型能否产出合格的结构化摘要。以下是我在生产环境中经过反复迭代验证的完整 System Prompt，直接复制可用：

你是一个高效的企业邮件秘书。你的任务是对用户发来的邮件原文进行结构化分析。

规则：
1. summary：用不超过三句中文精炼总结邮件的核心内容，重点是「谁，做了什么，需要我做什么」。
2. action_items：以列表形式列出邮件中所有对收件人的显式要求（如「请于周五前回复确认」），如无则返回空数组。
3. priority：根据邮件中的紧迫词汇（如「紧急」「ASAP」「deadline」）判断优先级，分为 low / medium / high。

严格要求：
- 只输出 JSON，绝对不输出 JSON 之外的任何文字。
- 不要对邮件内容做价值判断或道德评估。
- 如果邮件正文为空，summary 返回「邮件正文为空」，其余字段返回空值。

配合 JSON Schema 强类型约束，这套 Prompt 在测试的 200 封邮件中，格式解析成功率达到 100%。

邮件摘要自动化：n8n vs Zapier vs Make 对比

对于处理日常邮件汇总，不同工具在链路定制能力和资源开销上存在物理层面的巨大差异：

比较维度	n8n (自托管 mini 模型)	Zapier (SaaS 方案)	Make (原 Integromat)
单次执行成本	约 0.0075 美元 (仅需极低 Token 费)	0.05 美元起 (高昂的 Tasks 计费)	0.01 美元起 (按 Ops 操作数计费)
数据隐私保护	极致安全性 (邮件内容和 API 在本地流转)	较低 (数据必须上传至第三方商业云服务)	较低 (数据在外部 SaaS 平台中转)
对复杂 JSON 支持	完美配合 OpenAI 节点进行 Schema 解析	较弱 (多节点传参较繁琐)	一般 (需要写复杂的数据结构映射)
自动重试与纠错	原生 Retry 且 0 额外费用	需订阅高阶 Team 版本才支持自动重试	需配置 Error Handler 节点

去重逻辑与幂等性实现

在生产环境中，工作流的幂等性（即无论执行多少次，结果都应该是一致的，不产生脏数据）是衡量系统好坏的核心标准。

如果我们的工作流因为中间的 OpenAI API 暂时超时，而在十分钟后触发了重试，Gmail 节点会重新把那一批邮件吐出来。如果没有去重机制，Google Sheets 里就会出现大量一模一样的邮件行，导致仪表盘数据失真。

我们的防重复执行控制阀是通过 messageId 来实现的。每封邮件在 Gmail 体系里都有一个在全宇宙唯一的 messageId 字符串。

我们通过在 n8n 中组合使用「Google Sheets Lookup」和「If」节点，构建出如下的物理逻辑：

[Gmail Trigger] -> [Google Sheets Lookup (按 messageId 查重)] -> [If: 存在记录]
                                                                   |
                                                                   +-> (True) -> [Stop 节点]
                                                                   |
                                                                   +-> (False) -> [OpenAI 摘要] -> [Google Sheets 写入新行]

这套逻辑相当于在工作流中建立了一个单向阀门。即使你手动点击重试一百次，已经成功落库的邮件也会在第二步直接被拦截过滤，绝对不会产生第二条脏行。

AI 自动化中的错误流设计 (Error Workflow)

在生产环境中，没有 100% 不出错的系统。大模型的调用可能会遇到 429 频次限制、Google Token 可能会过期、云服务器可能网络瞬时中断。

如果不配置 Error Workflow，一旦某个节点发生错误，n8n 就会直接中断当前的执行，而前台的我们对此毫无察觉，直到几天后发现表格没更新才去翻日志。

在自托管的 n8n 中，最标准的灾备设计是为你的主工作流绑定一个专门的子图式错误处理流（Error Trigger）：

1. 新建一个独立的工作流，起点放置一个 Error Trigger 节点。这个节点会自动捕获你整个 n8n 实例中所有发生失败的工作流元数据。
2. 后面连接一个 Code 节点，将报错信息、出错的工作流名称、错误节点以及执行时间格式化为一小段文字。
3. 最后连接一个 HTTP Request 节点，调用钉钉、企业微信或者飞书机器人的 Webhook 接口，将报错信息推送至你的个人手机上。
4. 在我们的主工作流配置中，打开 Settings -> Error Workflow，关联这个刚刚创建的错误处理流。

这样，一旦你的 OpenAI 额度欠费导致节点报错，你的手机会在秒级时间内收到精准的警报：“警告：Gmail 摘要工作流在节点 OpenAI 处运行失败，报错信息为 Balance Insufficient。“这能让你在客户报障前就完成物理排障。

生产运行成本估算

很多人对 AI 工作流的运行成本心里没底。我们可以来算一笔物理账：

假设你每天收到 100 封邮件，经过我们的前置 Gmail Query 物理过滤，被过滤掉的垃圾、社交和系统通知邮件大约占 75 封，真正需要大模型处理的高价值工作和个人邮件只有 25 封。

• 输入开销：假设每封邮件的平均长度为 1500 个字符，大约对应 1200 个 Tokens。25 封邮件每天产生 30000 个输入 Tokens。
• 输出开销：OpenAI 的 JSON 结构化输出非常简短（摘要+代办+优先级），每封邮件大约产生 200 个 Tokens，25 封邮件每天产生 5000 个输出 Tokens。

如果我们使用性价比较高且推理能力强悍的 gpt-4o-mini 模型：

• 输入费用：$0.15 / 百万 Tokens，每天约$0.0045。
• 输出费用：$0.60 / 百万 Tokens，每天约$0.003。

一天的总 AI Token 开销只有 $0.0075，换算成人民币不到 6 分钱。一个月跑下来，总成本只有 2 元人民币左右。

相比之下，SaaS 版本的 n8n 最低一档订阅是每月 $20，而 Zapier 稍微跑几百次就要几十刀。自托管加上克制的过滤逻辑，用极低的价格就帮我们实现了完全私有化的邮件秘书。

常见生产报错与排坑清单

报错一：JSON 返回格式混乱导致表格节点解析失败

这是没有开启结构化输出时最常遇到的报错：

SyntaxError: Unexpected token 'H', "Here is the JSON..." is not valid JSON
at JSON.parse (<anonymous>)
at Object.execute (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/Code/Code.node.js:84:22)

大模型在默认情况下，即使你在 Prompt 里反复强调「只返回 JSON」，它也经常会在输出的头部加上一句废话「以下是为您生成的 JSON：」，或者用 Markdown 的 ```json 代码块进行包裹。

要解决这个问题，除了在 OpenAI 节点中使用标准的 JSON Schema 外，最安全的做法是在 OpenAI 节点后面，插一个 Code 节点，用以下物理正则代码进行防御性清洗：

let rawText = $input.first().json.message.content;
// 用正则匹配 {} 之间的所有内容
const match = rawText.match(/\{[\s\S]*\}/);
if (match) {
    return JSON.parse(match[0]);
} else {
    throw new Error("无法从模型输出中提取有效的 JSON 结构");
}

报错二：Google Sheets 写入连接超时

NodeApiError: [TimeoutError] The request to Google Sheets timed out after 30000ms.
at Object.execute (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/dist/nodes/GoogleSheets/GoogleSheets.node.js:154:19)

这通常是因为你的工作流瞬间拉起了太多并发的 Google Sheets 写入操作，被谷歌云官方进行了频次限制，或者服务器网络波动导致。

解决办法是在 Google Sheets 节点设置中，开启「Retry on Fail」重试策略，并配置等待 5 秒后重试，最多重试 3 次，从而过滤掉大部分瞬时的网络抖动。

报错三：Gmail Token 无法刷新

ERROR: Google Mail API error: No refresh token found. Connect credential again.

这是因为在 Google Cloud Console 中，你的 OAuth 同意屏幕项目处于「测试 (Testing)」状态。在这种状态下，谷歌限制了用户凭证的生命周期，刷新密钥在 7 天后就会自动强制过期失效，导致你的自托管 n8n 无法拉取邮件。

解决办法是登录 Google Cloud 控制台，在 OAuth 同意屏幕配置中，点击「发布应用 (Publish App)」，将项目状态从 Testing 切换为 Production 生产状态。这样，你的刷新 Token 就会获得永久有效期，再也不会无故断连。

报错四：n8n 自托管实例因 SQLite 并发写锁导致工作流卡死

SqliteError: SQLITE_BUSY: database is locked
at Database.prepare (/usr/local/lib/node_modules/n8n/node_modules/better-sqlite3/lib/database.js:72:21)

这是一个在高并发场景下必然触发的底层架构缺陷。当你的 Gmail 触发器同时拉取大量邮件（比如 50 封），n8n 会为每封邮件并发起一个独立的工作流执行实例，同时写入 SQLite 数据库。SQLite 是一个单写锁数据库，并发写入超过其处理能力时，就会抛出这个 BUSY 报错并卡死。

根本解决方案是在 docker-compose.yml 中将 n8n 的数据库切换为 PostgreSQL：

environment:
  - DB_TYPE=postgresdb
  - DB_POSTGRESDB_HOST=postgres
  - DB_POSTGRESDB_PORT=5432
  - DB_POSTGRESDB_DATABASE=n8n
  - DB_POSTGRESDB_USER=n8n
  - DB_POSTGRESDB_PASSWORD=your_strong_password

切换到 PostgreSQL 之后，并发执行能力可以从 SQLite 的单线程模式提升到支持数十个并发写操作，彻底消除这类死锁报错。

Google Sheets 表格结构与数据看板设计

一个好的摘要工作流，不只是把数据写进表格，还要让表格本身成为一个可读的决策仪表盘。

在实际生产中，我的 Google Sheets 表头设计如下：

| Date | From | Subject | Summary | Action Items | Priority | Status | MessageID |

其中 Status 列是我手动维护的，用于标记每封邮件的处理进度（如 待处理 / 已回复 / 已归档）。结合 Google Sheets 的条件格式，把 Priority=high 的行自动高亮为红色背景，Priority=medium 高亮为橙色，就构成了一个零成本的邮件管理仪表盘。

在此基础上，可以利用 Google Sheets 的 COUNTIF 公式做每周邮件统计：

=COUNTIF(F:F, "high")    // 统计本周高优邮件数量
=COUNTIF(G:G, "待处理")  // 统计还未处理的待办事项数量

这套表格体系完全替代了我以前使用的付费 Inbox 管理 SaaS，一分钱订阅费都没多花。

进阶扩展：多收件箱聚合与优先级路由

当基础版跑稳后，可以进一步扩展为多账号、多规则的智能路由器。

在 n8n 中，一个 Gmail Trigger 只能绑定一个账号。要聚合多个邮箱（如工作邮箱 + 个人邮箱），需要并排配置两个独立的 Gmail Trigger 节点，分别授权不同的 OAuth2 凭证，然后将两路触发流在 Merge 节点处汇聚为同一条处理管道。

在 OpenAI 处理完成后，根据 priority 字段的值，可以用 Switch 节点进行三路分发：

priority=high  -> [立即发送企业微信/钉钉 IM 实时推送] -> [写入 Sheets]
priority=medium -> [写入 Sheets] -> [汇总到每日 Digest 邮件]
priority=low   -> [直接归档写入 Sheets，不发推送]

这样，真正紧急的邮件（如客户投诉、资金异动通知）会在一分钟内到达你的手机，而大量低优邮件则安静地沉入数据库，不打扰你的专注时间。

继续阅读

• 👉 n8n AI Workflow 生产化门户页
• 👉 n8n AI Workflow 生产化：错误处理、重试、超时与成本监控
• 👉 n8n Queue Mode + Redis 实战：大并发队列架构指南
• 👉 n8n vs Make 选型对比：谁才是最强 AI 自动化工作流中心？
• 👉 Self-hosted n8n AI Workflow 实战：Docker、Postgres、VPS 与 NAS 部署指南
• 👉 n8n AI Workflow 实战：构建 Notion 知识库智能体