使用本地 AI 回复邮件（LLM 私有）

#原则：仅作草稿，绝不自动发送

这里的目标不是让机器人代您回复，而是减少撰写重复性或标准回复所花费的时间，例如确认收悉、回答常见问题，或改写过于随意的草稿。LLM 生成文本，您阅读后按需修改，再决定是否发送。这个流程中的任何环节都不应在未经人工确认的情况下自动推进到发送。

#实际可行的架构

由三个部分构成本地邮件助手架构：您常用的邮件客户端（如Thunderbird，或任何支持插件的客户端）、一个能够调用语言模型API的插件或模块，以及在您设备上运行的本地模型，通过 Ollama 在默认本地地址（127.0.0.1，端口11434）提供服务。邮件的正常收发（IMAP接收、SMTP发送）仍由客户端处理：只有草稿文本会传输至本地模型进行生成，绝不会发送到第三方服务。

#一个现有扩展的示例

ThunderAI 是 Thunderbird 的扩展，可将 AI 直接集成到邮件客户端中，除云端提供商外，还明确支持 Ollama。其文档说明，它完全在本地运行（模型、上下文长度、温度、思考模式），因此可以将一切保留在本机上，而不必依赖外部服务器。

具体而言，此类功能可基于选定邮件生成回复草稿，支持简单提示、高级提示或您自定义的指令。生成的文本将在邮件客户端的常规编辑窗口中打开：任何内容都不会在您未经过该窗口的情况下被发送。

#同类其他扩展

ThunderAI 并不是唯一选择：面向 AI 的 Thunderbird 扩展生态已日益丰富，各种方案的做法略有不同。thunderbird-ai（Project516）主打一个“AI review”按钮，可在撰写过程中检查草稿的语气、错误，尤其是正文中提到、却在发送时忘记添加的附件——ThunderAI 并未明确提供这项实用检查功能。Quill 则提供写作辅助，可按需接入 Ollama、OpenAI 或 Claude。

这些扩展在文档中明确记载的共同点是：只有用户明确执行某项操作时，邮件内容才会发送给模型，绝不会在后台发送。thunderbird-ai 的文档对此表述得毫无歧义。安装任何扩展之前，无论它是否使用本地模型，都值得核实这一点：如果某个扩展持续分析您的邮件，即使使用的是本地模型，其隐私承诺的性质也会不同于按需生成的方式。

#‘本地’真正保证了什么

在本地设备上运行模型意味着，模型处理邮件内容时，不会将数据发送至第三方服务以生成草稿。这并不会影响邮件本身的传输过程：收发仍然通过标准协议（IMAP、SMTP）与您的邮件服务器（本地或远程）进行通信。‘本地AI’仅保障了文本生成环节的安全性，而非整个邮件流程的安全性。

#部署助手

1. 01
   安装 Ollama 及相应的模型

   采用 Q4 量化、拥有 70 亿至 80 亿参数的模型适合撰写日常邮件；如果您的机器能够运行更大的模型，它能帮助您写出更细致、更有分寸的回复。
2. 02
   安装兼容的扩展

   确认所选扩展明确提供 Ollama 模式或兼容 OpenAI API 的本地服务器选项，而不是仅支持云服务提供商。
3. 03
   配置本地地址

   将扩展指向 Ollama 服务器的默认地址，通常为 127.0.0.1:11434。
4. 04
   在非敏感邮件上进行测试

   先针对一封无关紧要的邮件生成初稿，确认语气和内容是否恰当，再用于重要的往来邮件。

#为何仍必须进行人工复核

模型生成的是看似可信的文本，不一定准确。在工作邮件中，语气不当、改写时夹带错误信息，或回答没有回应真正提出的问题，都是切实存在的风险，即使用的是好模型也一样。复核并非过度谨慎：这是唯一能确保以您名义发出的内容符合您真正想表达的意思的步骤。

核实文中所述事实

模型可能对日期、金额或承诺进行轻微重新表述：发送前需与原始邮件内容对比核对。

检查语气

生成的草稿可能过于正式、过于随意，或不适合您平时的交流对象。

检查收件人

模型不了解您与对方的关系背景：您需要自行判断，建议的措辞是否适合这位具体的收件人。

核实文中提到的附件

如果草稿中提到附带文件，发送前务必确认文件确实已附加：模型负责生成文本，而非文件本身。

这份清单并非走过场：它列出的是这类工具的用户最常报告的错误，而不是理论上的风险。几秒钟生成的草稿会给人一种可靠的印象，让人审阅时比审阅自己写的文字更草率，而真正能起到保护作用的恰恰是反过来做：生成速度快并不意味着可以省略任何核查步骤，只是从总耗时来看，认真审阅变得更划算。

#再进一步：分类整理与任务提取

在邮件客户端生成的零散草稿之外，社区项目还进一步推进：AI-Email-Agent 是一个本地优先的代理，通过 IMAP 连接邮箱，对邮件进行分类，并从中提取可执行任务，使用 Ollama（搭配 llama3 模型），同时将全部处理过程保留在本地设备上（Ollama 和本地 SQLite 数据库），这一部分处理无需依赖第三方云服务。

与上文描述的助手相比，结构上的区别在于：这类智能体涉及更自动化的步骤（分拣、分类），而不仅仅是按需生成一份草稿。因此，这些项目明确说明了在任何操作之前设置人工审核关卡（human-in-the-loop），而不是让自动化在无人把关的情况下完成整个流程。其原则与普通写作助手相同：自动化在流程中推进得越远（分拣、任务、回复），明确的人工审核就越不可或缺，绝非可选项。

#迈向邮件客户端的原生集成

除了第三方扩展外，Mozilla已向Thunderbird直接提交了一项集成式助手提案，旨在减少邮件处理时间并降低分类和撰写带来的认知负担，同时不损害提案中规定的隐私保护。此类举措与现有扩展方向一致：提供写作辅助、语气调整、草稿重写等功能，以邮件原文和讨论线为可选上下文，而非强制要求。

无论助手是第三方扩展还是未来原生功能，其核心原理保持一致：优势体现在写作时间的缩短，而非发送决策的委托。若某天邮件客户端提供无需确认的自动发送功能，这将改变工具的本质，而不仅仅是本指南所描述的写作助手的简单优化。

#它无法替代的内容

本地助手可以帮助您起草回复，而不是管理整个收件箱。自动分类、优先处理紧急邮件或在无人监督的情况下发送邮件，仍属于另一类自动化，其可靠性和责任问题与简单的写作辅助不同。本指南有意聚焦于经过复核的草稿：对于日常工作往来邮件，这是目前实际节省时间与所承担风险之间最划算的使用方式。

• 使用 n8n 和 Ollama 自动化工作流
• 一步步在本地安装 LLM
• 2026 年最佳免费本地 AI
• 本地使用AI的隐私检查清单
• 来源：ThunderAI 扩展（Thunderbird + Ollama）
• 来源：Mozilla提出的Thunderbird内置助手建议
• 来源：Ollama 官方文档（默认本地地址）
• 来源：thunderbird-ai 扩展（AI review，本地 Ollama/llama.cpp）
• 来源：AI-Email-Agent，采用本地优先方式并需人工确认的智能体