本地AI自动摘要客户新邮件实战：OGAD桌面版教程

客户发来一封设计评审更新，你正在赶另一个项目，需要快速判断哪些内容变了、是否必须今天回复。与其反复切换窗口翻找，不如让本地AI在邮件到达时自动生成结构化摘要。

OGAD（Off Grid AI Desktop）Pro 提供了这样一条路径：检测到匹配的新邮件后触发助手例程，识别客户的请求、截止日期和待决策事项，再将结果呈现在 God 界面中。选择本地文本模型后，摘要完全在你自己电脑上生成。前提是连接邮箱账户、启用例程，并保持电脑可用——邮件检查需要联网，触发机制是周期性轮询而非即时响应。

先想清楚：摘要要帮你做什么决定

假设客户在邮件里问"能否周五评审？"，有用的摘要应该指出：请求的具体变更、提到的日期原文、以及客户还需要补充哪些信息。它绝不该把"能否周五评审"曲解为"最终交付日是周五"——这两句话含义完全不同。摘要还应把发件人的原始请求与模型建议的下一步区分开。

一个实用格式是：三条事实、一个待确认问题、一个建议动作。你可以随时打开原邮件获取完整上下文。例程减少的是定位关键信息的工作量，它不替代邮件本身作为信息来源。

**工具调用（Tool Calling）**是本地模型能否胜任邮件摘要的关键能力。支持工具调用的模型不仅能生成自然语言，还能根据指令主动调用外部函数——在这里就是"读取邮箱里的某封邮件"。模型会输出一个结构化的调用请求（如 read_email(folder="inbox", limit=10)），由 OGAD 执行后把返回内容交回模型继续推理。若模型不具备这一能力，它只能凭空作答或依赖已注入上下文，往往产生看似合理却与真实邮件不符的摘要。因此在 God 中选择模型时，应确认其标注了工具调用支持，并用"查找最近一封客户邮件并识别主题和日期"这类小任务先验证一次。工具调用还决定了权限边界：模型只能触达被显式授权的工具，不会自行访问未开放的邮件或附件。

连接账户并验证一次手动请求

使用当前桌面版 beta 并启用 Pro。在 Integrations 中连接接收客户消息的 Google 或 Microsoft 账户，完成权限流程。如果连接过程要求填写你自己的应用信息，先完成这部分设置再创建例程。

选择一个已下载、支持工具调用的本地文本模型。在 God 中让它查找客户最近一封邮件，并识别主题和日期。这一步同时验证账户连接和模型的工具调用能力。

需要留意：不要假设邮件预览能提供所有附件或完整对话。让助手在需要更多文本时主动说明。如果截止日期只存在于它尚未读取的附件中，摘要必须将该日期标注为"未确认"。

OAuth 权限流程是连接 Google 或 Microsoft 账户时绕不开的一步。它并非 OGAD 自行设计的登录，而是由邮箱服务商颁发的授权令牌机制：你在浏览器中登录并勾选允许的访问范围（如"读取邮件"但不含"发送邮件"），服务商返回一个可撤销的令牌给 OGAD。这意味着两点：一是读取与发送是两套独立权限，勾选了读取并不等于获得了发信能力；二是你可以随时在邮箱账户的安全设置中撤销该授权，从而立即切断 OGAD 的访问。如果连接向导要求填写"你自己的应用信息"，说明该部署没有内置共享的 OAuth 客户端，需要你在服务商的开发者控制台注册应用并获得客户端 ID 与密钥，再把回调地址填回 OGAD。

添加邮件例程

进入 God 设置，展开 Scheduled tasks，选择 Add a scheduled task。给它一个清晰的名称，例如"客户评审更新"。在 What to do 中填入指令，在 When 中选择"When an email arrives"，在 From (optional) 中填入客户完整邮箱地址，保存并确认已启用。

示例指令：

阅读触发此例程的新邮件。确认发件人是 client@example.com。用三条要点总结请求。按原文精确引用任何日期，附一个待确认问题和一个建议动作。标明账户、发件人、主题和消息时间以便我找到原邮件。如果可用文本不完整，说明你无法读取的部分。不要发送回复或修改任何账户数据。

保存前替换示例地址。From 字段是对事件详情的文本过滤，并非精确的发件人身份规则。填写完整地址能减少宽泛匹配，在任务指令中保留发件人校验则让预期范围更明确。

任务与触发器要分开验证

用 Run now 检查指令是否能产出有用答案——这验证的是任务本身，并不证明后续邮件能触发它。

触发器验证需要保持例程启用、账户连接，然后等一封新的匹配邮件到达后检查结果。OGAD 在邮件例程启用期间大约每五分钟检查一次新邮件，还要加上账户请求和模型响应的时间。首次成功检查会建立一个基准点，收件箱中的存量邮件不会被当作新到达邮件处理。如果需要更早邮件的摘要，用日期范围单独请求。

当前检查机制读取每个账户中最近、有限数量的消息，并不是繁忙收件箱中每封邮件的可靠记录。不能等待的截止日期，仍然依赖常规邮件通知。

**周期性轮询（Polling）**是这里触发机制的本质：OGAD 并非与邮箱服务器保持长连接、也没有接收推送通知，而是每隔约五分钟主动查询一次"是否有新邮件"。这带来三个直接后果。其一，延迟是叠加的——轮询间隔加上账户请求往返再加模型推理时间，从邮件到达到摘要生成通常需要数分钟。其二，"新"是相对于上一次成功查询的基准点判断的，首次启用时会把当前收件箱视为基线，因此存量邮件不会被触发。其三，轮询只读取每个账户最近、有限数量的消息，在邮件量很大的收件箱里可能错过两次查询之间到达的信件。若需要推送级实时性，应改由服务商的 Webhook 或推送通知驱动，但那通常需要额外的服务端配置。

把摘要转化为实际工作

读完摘要后，打开原邮件确认请求内容。接着可以让 God 准备一封回复草稿供你审核，或将请求与相关项目笔记对照。例如：

起草一封回复，确认两项已达成一致的变更，并询问周五是评审日还是交付日。草稿保留在此处供我检查。

需要注意：连接邮件读取工具并不会自动提供发信工具。通过其他已启用的工具或浏览器任务发送邮件是独立操作，有各自的权限和审批要求。一个仅准备草稿的例程在没有自动发送的情况下依然很有价值。

草稿与发送的权限分离值得单独强调。邮件读取工具只授予了读取能力，它不会顺带带来发信工具；即便 OGAD 中装有发信或浏览器自动化工具，其启用、授权与审批也是另一套独立流程。因此一个"只准备草稿、由人审核后再手动发送"的例程，在权限上是最小化的，也是最安全的工作流。反过来，如果直接让模型自主发送，任何摘要偏差或语气误判都会原样进入客户收件箱，且事后难以撤回。稳妥的做法是让助手始终把拟好的回复留在草稿状态，再结合简报中的建议动作由你决定是否采纳，这样既保留了自动化的效率，又把最终判断权留在人这一侧。

常见问题排查

问题	检查项
没有新结果	例程已启用、电脑唤醒、OGAD 运行中、账户已连接
旧邮件未触发	首次检查建立基准；直接请求更早邮件
匹配邮件过多	使用更具体的地址或文本过滤器，检查发件人
摘要遗漏细节	检查完整文本或附件是否可用
任务运行但无法读取邮件	检查账户权限和所选模型的工具支持

在例程能可靠产出所需简报之前，保持范围狭窄。当输出过长或把事实与猜测混在一起时，编辑指令。项目结束后禁用它。

本指南基于 beta 122 的例程和账户实现。建议先从一个客户开始，在 OGAD 中验证一条新消息的摘要结果，再添加更多邮件规则。