邮件附件自动归档到网盘，为什么关键在三个交接点？

一封带附件的邮件到了。下载、在网盘里找到对应文件夹、上传、复制链接、发到聊天窗口——每一步都不难，难的是每次都记得做完。

这套流程可以压成一条自动化链路：收到附件，按发件人和日期归档，保存文件，再把链接发到 Telegram。整条链路拆开是六个阶段。

• Gmail：接收新附件
• 格式化器：把邮件的接收日期转成日期文件夹名
• Google Drive：查找或创建文件夹路径
• Google Drive：把附件上传进该文件夹
• Google Drive：设置文件的查看权限
• Telegram：发送一条包含上传文件链接的消息

最终文件可能落在这样一条路径下：Gmail attachments / 发件人邮箱 / 2026-10-26 / 附件文件名。发件人、日期和文件名都来自真实邮件本身。

动手前要准备什么

先把 Gmail 和 Google Drive 连接到自动化平台，再连接要用的 Telegram 机器人，把它加进目标频道并给它发消息的权限，同时准备好该频道的 Chat ID。

机器人连接和 Chat ID 是两件事：连接决定由哪个机器人发消息，Chat ID 决定消息发到哪里。消息映射里不需要粘贴机器人令牌。

测试时先用一个无害的附件。演示流程里包含一步显式分享，让任何拿到链接的人都能查看上传的文件。如果附件需要受限访问，应改用相应的 Drive 分享设置。把链接发到 Telegram 本身并不会授予 Drive 访问权限。

在接入真实收件箱之前，用 Gmail 触发器的搜索查询把处理范围限制在你想处理的那部分邮件上。演示里出现过查询为空的情况，个人邮箱不要把它当默认配置。

第一步：把流程描述给 AI Builder

新建一个工作流，打开 Build with AI，把想要的结果和每一步需要的数据都描述清楚。提示词里要说明：使用已连接的 Gmail 账户；在激活前会配置搜索查询来限定处理范围；对每个附件事件，把接收日期格式化为 YYYY-MM-DD，按“Gmail attachments / 发件人邮箱 / 格式化日期”查找或创建文件夹，把附件文件上传到最终的日期文件夹，为演示目的仅对该文件设置 anyone 权限和 reader 角色，再用已连接的 Telegram 机器人向指定 Chat ID 的频道发送消息，内容包含发件人邮箱、格式化日期、附件文件名和上传文件的 Web View Link。

提示词里还要写明：使用前序步骤的动态输出，工作流保持草稿状态，以便在激活前检查连接和字段映射。看完 AI 给出的步骤后选择创建草稿。这份提案只是起点，启用前要核对选中的账户、动作设置和字段映射。

第二步：配置 Gmail 触发器和日期

选择“收到新附件”和要用的 Gmail 连接，为测试邮件配置搜索查询。演示中的触发器采用轮询，间隔大约五分钟，它不是即时推送通知，测试时要留出延迟时间。自己工作流里显示的间隔要单独确认。

接着把 Gmail 的接收日期映射进格式化器，格式设为 YYYY-MM-DD，格式化器的输出就成为文件夹路径里的日期段。用邮件的接收日期，文件夹就跟着邮件走，而不是跟着你碰巧查看工作流的时间走。

第三步：用动态字段拼出文件夹路径

在“查找或创建文件夹”里，把固定的父文件夹和两个动态值拼在一起：Gmail attachments / [Gmail: 发件人邮箱] / [格式化器: 输出]。动态值通过字段选择器插入，方括号里的名称描述的是这些选择，不是要粘贴的字面文件夹名。

这个动作会复用已有的文件夹路径，缺失的文件夹则新建。它返回的 ID 指向最终的日期文件夹，下一步上传需要用到它。

第四步：上传真正的附件

这里有两个关键映射。第一，映射附件的文件本身，而不是它的文件名或邮件正文——文件名只告诉下一步这个文件叫什么，不提供文件内容。第二，上传会产生新的文件 ID 和 Web View Link，这两个输出要分开用：分享步骤用 ID，Telegram 消息用链接。

第五步：设置分享并组装通知

演示中的分享文件动作这样设置：文件用上传步骤返回的 ID，权限类型为 anyone，角色为 reader。这只作用于那一个上传的文件，不是整个文件夹。reader 可以查看文件，但不会拿到编辑权限。

在 Telegram 的发送消息动作里，选择机器人连接，填入目标频道的 Chat ID，用动态字段拼出消息：发件人、接收日期、附件名、链接。链接要映射上传步骤的 Web View Link，而不是从之前某次测试里复制的 URL——那样每次通知都会指向旧文件。

第六步：跑通整条链路

检查配置，激活工作流，等到状态变为 ACTIVE，再发一封带无害附件的新测试邮件，然后留出 Gmail 轮询的时间。结果要在三个地方核对：

• 运行历史：查看这次运行和每个动作的结果。只看配置不能证明文件真的上传了、消息真的送达了
• Google Drive：依次打开父文件夹、发件人文件夹、日期文件夹，确认预期的附件在里面
• Telegram：查看通知，点开链接，确认它打开的是同一个文件、权限也符合预期

演示用的是单个附件的例子。真实邮件如果有多个附件，要单独测试这种情况，在依赖它之前先确认文件数量和通知数量。

结果不对时看哪里

这条工作流真正有价值的部分，是应用与应用之间的交接：邮件元数据决定文件夹，文件夹 ID 决定上传位置，上传得到的链接变成通知内容。AI Builder 帮忙把步骤搭起来，而检查这些交接点，才让自动化变得可理解、可测试。

回到自己的场景，还可以往这条流程里加什么：附件过滤、换一种文件夹结构，还是换一个通知去处？