MailRoute 是一个轻量级的智能邮件路由系统，由管理前端和 Cloudflare Worker 后端组成，支持邮件自动分类、条件路由、归档管理和 Webhook 自动化。
它要解决的问题很简单：不是每一封邮件都值得进入收件箱，也不是每一封邮件都应该以相同的方式处理。
银行账单需要保存，验证码需要及时查看，工作通知可能需要转发，而大量营销邮件并不值得打扰。传统邮箱通常通过发件人、关键词和过滤规则管理这些邮件，但面对内容不断变化的邮件，仅靠静态规则很难准确判断其用途。
MailRoute 尝试在邮件进入收件箱之前，增加一层可编程的语义决策：
邮件接收 → 规则匹配 / AI 分类 → 路由决策 → 转发 / 归档 / 通知 / Webhook
邮件不再只有“收取”和“删除”两种结果，而是可以根据实际用途进入不同的处理流程。
一、核心理念：让邮件去它该去的地方
传统邮箱将收件箱作为所有邮件的共同入口，用户再通过筛选、标记、移动和删除维持秩序。
但很多邮件其实有明确的用途。
例如，银行的消费通知可以进入账单系统，服务器告警可以转发到工作邮箱，重要通知可以发送到 Slack，而普通营销邮件只需要保留在归档中。
MailRoute 不试图取代现有邮箱，而是将邮件分类与处理从邮箱客户端中独立出来。
邮箱负责通信，MailRoute 负责判断和分发。
用户仍然可以使用 Outlook、Gmail 或其他邮箱服务，不需要改变原有阅读习惯。
二、智能分类：规则负责确定性，AI 负责理解
邮件分类并不总是需要 AI。
对于已知发件人的系统通知、固定格式的账单邮件，直接使用规则往往更快、更可靠。只有无法通过明确规则判断的邮件，才需要引入语义分类。
因此 MailRoute 使用两级分类机制：
- 规则匹配：根据发件人、收件人、主题关键词等条件，按照优先级进行分类。
- AI 语义分类：未匹配规则时，调用 LLM Decisions 接口，结合邮件内容和用户定义的分类标准判断用途。
用户可以在管理界面中自定义分类名称、识别描述、典型示例及对应动作。例如：
| 分类 | 识别内容 | 处理方式 |
|---|---|---|
| 重要事项 | 需要及时关注或回应的通知 | 转发 |
| 账单 | 消费记录、发票、交易通知 | Webhook |
| 普通通知 | 订阅更新、日常服务消息 | Slack |
| 其他 | 无法归入明确类别的邮件 | 归档 |
分类定义不需要修改程序代码。用户调整分类描述和示例，就可以改变 AI 判断邮件的标准。
当模型不可用、结果置信度不足或分类失败时，系统会回退到预设类别，避免将不确定的判断直接转化为高风险操作。
三、路由动作：分类之后，邮件还能做什么？
分类本身并不是最终目的。
MailRoute 为每个类别配置对应动作，目前主要支持四种处理方式。
📩 Forward：转发
将指定类别的邮件转发至预先配置的目标邮箱。
例如，把重要的系统通知转发到日常使用的 Outlook 邮箱，而不需要在原始接收邮箱中逐一查看。
🔒 Quarantine：隔离归档
邮件保留在 MailRoute 中，但不继续向其他渠道发送通知。
适合不需要立即处理、但未来可能查询的普通通知和低优先级邮件。
🔔 Slack：即时通知
将邮件主题、发件人和可选的正文摘要发送到 Slack。
对于涉及隐私的邮件，还可以只发送邮件头信息，避免将正文内容直接暴露在通知渠道中。
🔗 Webhook：业务自动化
将邮件信息与解析后的正文，以结构化 JSON 发送至外部 HTTP 服务。
例如，收到信用卡账单后，不必再手动打开邮件、复制交易内容，而是直接触发账单导入服务。
账单邮件 → AI 分类 → Webhook → 账单解析 → 交易记录
从这里开始，MailRoute 不再只是一个邮件转发器，而是可以将邮件作为其他业务系统的事件入口。
四、管理界面：让邮件规则可以被管理
如果每次新增分类、修改规则都需要编辑配置文件，智能路由很快就会成为一个只有开发者愿意使用的工具。
因此 MailRoute 提供了独立的管理前端，将邮件处理策略与收件箱统一呈现。
分类与策略管理
用户可以在页面中创建分类、修改 AI 识别提示词、设置路由动作，并配置规则优先级、模型参数及 Webhook。
配置以结构化策略保存，支持版本管理，避免多个管理操作相互覆盖。
邮件收件箱
即使邮件已经被转发或发送通知，仍然有必要知道系统曾经收到什么，以及最终如何处理。
MailRoute 的收件箱支持：
- 按分类、处理状态、时间等条件筛选；
- 搜索主题、收发件人及正文预览；
- 查看邮件详情、分类来源与投递状态；
- 标记已读、归档、删除和批量删除；
- 在满足原文保存条件时，手动重新发送邮件或 Slack 通知。
这样一来，用户不仅可以配置自动化，还可以回头检查自动化做出了什么判断。
自动处理不应该意味着失去可见性。
五、技术架构：SPA + Worker + D1
MailRoute 选择了尽可能轻量的技术架构。
Internet Email
│
Cloudflare Email Routing
│
▼
Cloudflare Worker
│
┌──────────┴──────────┐
│ │
Rule / JEV AI D1 Database
│ │
Route Action Mail / Policy
│ │
┌───────┼────────┐ │
│ │ │ │
Forward Slack Webhook │
│
HTTP API /api/v2
│
管理服务接口
│
SPA 前端
Worker 承担邮件接收、MIME 解析、分类决策和外部动作执行；D1 保存策略、邮件数据与处理状态；SPA 则提供策略管理和收件箱操作。
系统无需部署常驻邮件处理服务器，也不需要维护额外的邮件同步队列。
邮件存储与可靠性
相比早期依赖对象存储的方案，MailRoute V2 直接使用 Cloudflare D1 保存邮件。
但 D1 并不是专用的邮件对象存储，因此系统对原文保存设定了明确边界：
- 不超过 1.5 MB 的邮件保留完整原文；
- 超过限制的邮件保存必要元数据与预览，并按兜底策略转发；
- 通过原文哈希与信封信息生成确定性邮件 ID，减少重复投递产生的重复动作；
- 对外部操作记录执行状态，避免在结果不确定时盲目重试。
这种设计并不追求成为一个支持海量附件的完整邮件服务，而是优先满足个人与轻量业务场景中的邮件路由需求。
六、实际应用：让邮件进入工作流
MailRoute 的价值不只是减少收件箱里的邮件数量，更在于让邮件能够直接参与日常工作。
1. 个人邮件整理
将账单、订阅、重要通知与普通消息自动分流。重要的邮件继续进入常用邮箱，不重要的邮件则保留在 MailRoute 中等待查询。
2. 系统通知集中管理
开发平台、云服务、监控系统和自动化任务会产生大量邮件。通过规则与语义分类，可以把真正需要关注的事件发送到 Slack，减少重复消息带来的干扰。
3. 邮件驱动的业务自动化
通过 Webhook，将邮件正文交给其他业务系统处理，例如账单导入、信息提取、任务创建或工作流触发。
MailRoute 负责判断邮件属于什么、应该交给谁；下游系统负责具体业务处理。
两者不需要耦合在一起。
MailRoute 并不试图重新发明一个邮箱。
它只是把传统邮箱中依赖用户手动完成的分类、判断和分发工作，变成一套可以配置、可以观察、也可以接入其他系统的自动化流程。
邮件负责传递信息，MailRoute 负责让信息抵达正确的位置。