我为什么重新做一个 AI 邮箱系统
这不是一个换皮邮箱客户端，而是一次把“邮件”重新组织成“事情”的尝试。重点不是收发信，而是让订单、物流、账单、安全提醒自动变成可以处理的业务上下文。
我每天收到的邮件数量并不少，但真正需要处理的其实只占很小一部分。麻烦的是，传统邮箱会把所有东西都放在同一个时间线里：促销、验证码、账单、物流、订单、系统通知混在一起。
这对普通阅读没问题，但对“处理事情”很低效。比如 Apple 买手机这件事，先有下单邮件，再有付款、发货、派送、送达；Buy&Ship 又会有预报、入库、付款、集运、签收。它们在邮箱里是散开的，但在真实生活里明明是同一件事。
所以 Mailhub 的目标不是做一个更漂亮的 Gmail，而是做一个能替我把邮件理解成业务事件的个人邮箱系统。
传统邮箱的问题：它按邮件排序，不按事情排序
邮箱天然以“单封邮件”为中心，这让搜索和阅读很直接，但会把连续事件拆碎。一个订单可能跨越好几天、好几个发件地址、好几个主题模板，传统邮箱只能靠搜索关键词把它们临时找回来。
我想要的是系统主动知道：这些邮件属于同一个订单、同一票货、同一笔账单，当前状态是什么，下一步需不需要我操作。
- 促销邮件应该自动沉底，不应该和安全提醒抢注意力。
- 物流、账单、支付、验证码这类邮件需要被提取成结构化事件。
- 同一个订单的多封邮件应该合成时间线，而不是散落在搜索结果里。
比传统邮箱、网易 163 邮箱好在哪
先说清参照物。传统邮箱客户端（Outlook、Foxmail）和网易 163 / QQ 这类免费邮箱，本质都是“按时间倒序堆邮件 + 关键词搜索”，外加一层广告和会员墙。它们解决的是“收发与存储”，没解决“这封信到底要不要我做事”。
Mailhub 不是要替代它们收发信，而是补上它们最弱的一层——把邮件读懂、按事情归并、把要处理的捞到最前面。下面是我自己用下来最直接的几条差别。
- 网易/QQ 免费邮箱正文里塞广告、营销推荐位，重要邮件和促销抢注意力；Mailhub 自己托管，零广告，营销邮件自动沉底。
- 163 对很多券商、海外服务的邮件送达不稳、常进垃圾箱；Mailhub 自建 Postfix + OpenDKIM，mail-tester 满分 10/10，自己发出去的信不进垃圾箱。
- 免费邮箱一个账号一个地址；Mailhub 聚合 9 个自有域名的 catch-all，任意 xxx@域名 收到的信都进同一个工作台，注册哪个服务用哪个地址随便编。
- 传统邮箱只有“未读数”；Mailhub 把邮件变成“紧急 / 待付款 / 物流 / 安全确认 / 今天到期”这种可执行入口。
- 传统邮箱里一个订单的多封信是散的；Mailhub 按订单号/运单号自动合并成业务时间线，最新状态一眼可见。
- 外文邮件得自己复制去翻译；Mailhub 内置段落翻译，正文一键中译。
第一层：先把收件箱改成任务入口
Mailhub 的首页不是传统三栏邮箱，而是先给我看真正有业务含义的入口：紧急、待付款、物流、安全确认、今天到期。它更像一个个人事务工作台。
这一步的关键是不要让 AI 直接决定一切，而是先用规则和结构化字段搭出稳定骨架，再让 AI 负责摘要、解释和补充判断。下面这张是公开 Demo 的真实界面：左侧是按业务含义分好的入口，中间是带 AI 分类标签的邮件，右侧是选中邮件后展开的业务事件。
第二层：把同一件事合成业务时间线
我最在意的是订单和物流场景。比如 Buy&Ship 一票货会经历已入库、已打包、派送中、已送达；Apple 订单会经历已下单、准备出货、已发货、派送、送达。
实现上不能只靠邮件线程，因为很多系统通知并不会保持同一个 Message-ID 线程，也不一定用同一个主题。更可靠的方式是提取业务标识：订单号、运单号、包裹号、支付金额、商家名，然后再按时间合并。右侧面板还会给出 AI 建议动作和“为什么这么分”的依据，事实可追溯到原邮件片段。
- 优先提取强标识：订单号、运单号、包裹号。
- 再用发件域名、主题模板、时间窗口做弱匹配。
- 匹配成功后展示为一条业务时间线，让最新状态一眼可见。
第三层：AI 做理解层，规则做稳定层
我不希望 Mailhub 完全依赖 AI 判断，因为邮件系统需要长期稳定。AI 很适合读正文、压缩摘要、识别语气、判断是否需要回复；但订单号、金额、日期、域名、优先级兜底最好还是有规则参与。
所以这里的架构是混合式的：规则负责可验证的事实，AI 负责把事实翻译成人能快速理解的结论。
怎么实现的：从一封 .eml 到一条业务事件的完整链路
整套系统拆成“收 → 存 → 读 → 并 → 推”五段，每段都尽量做成可独立重跑、可追溯的环节。后端是 FastAPI（19 个路由模块：线程/搜索/草稿/发件人/文件夹/业务/规则/定时/模板/附件/联系人/导出/统计/配置/鉴权/翻译…），数据落在 PostgreSQL，前端是 Next.js，重要事件再经 Telegram 推到手机。
收信走 Postfix 的 catch-all：9 个 Cloudflare 域名的任意地址都路由进来，由 ingest.py 这个 pipe 把原始 .eml 解析成结构化记录入库，同时留底原文。新邮件靠一个常驻的 IMAP IDLE 守护进程实时推送，另有每 5 分钟的增量同步兜底，不漏信。
落库后由一个独立的 AI 分类 worker 逐封处理：生成摘要、判定优先级与业务类型、提取动作建议和截止时间；再由“抽业务事件”定时任务按订单号/运单号把多封邮件聚合成 events，并据此提升相关线程的优先级。发信侧自建 OpenDKIM 签名，mail-tester 满分，还支持草稿、回复模板和定时发信派发。
- 收：Postfix catch-all（9 域）→ ingest.py 解析 .eml → Postgres，留底原文。
- 推：IMAP IDLE 守护进程实时推新邮件 + 每 5 分钟增量同步兜底。
- 读：AI worker 逐封生成摘要 / 优先级 / 业务类型 / 动作 / 截止时间。
- 并：定时任务按订单号、运单号抽取 events，合并成业务时间线并提升优先级。
- 发：自建 OpenDKIM 签名（mail-tester 10/10）+ 草稿 / 模板 / 定时发信。
- 看：Next.js 前端 + 重要事件 Telegram 推到手机。
为什么不用现成开源邮箱系统改一改
开源邮箱系统通常把重点放在 IMAP、SMTP、账号、多租户、收发信和传统邮箱 UI 上，这些当然重要，但不是我这个项目的核心矛盾。
我的核心需求是“业务理解”：Apple 订单要聚合，Buy&Ship 通知要按货件串起来，Cloudflare 登录令牌要判断是不是本人操作，账单和付款要进入待处理。直接改一个传统邮箱系统，最后反而会被它原有模型牵着走。
- 传统邮箱的数据模型以邮件为中心，Mailhub 以业务事件为中心。
- 我需要的是个人自动化系统，不是一个通用企业邮箱套件。
- 从头搭业务层更快，也更容易把 AI 放在正确的位置。
从一封邮件到一条业务事件
收信与归档
先把不同邮箱来源统一入库，保留原始正文、发件人、主题、时间、附件和基础头信息。
规则预处理
用发件域名、关键词、正则和历史模板提取订单号、金额、截止日期、运单号等强结构字段。
AI 阅读理解
把正文交给模型生成摘要、动作建议、优先级、业务类型，并解释为什么需要处理或可以忽略。
业务聚合
按业务标识和时间窗口把多封邮件合并成订单、物流、付款、安全提醒等事务。
界面呈现
前端不再只展示邮件列表，而是展示收件箱、紧急入口、业务时间线和可执行操作。
先服务自己，不急着做通用 SaaS
邮箱是高隐私、高信任系统。先把自己的 Apple、Buy&Ship、账单、安全提醒跑顺，比一开始做大而全更重要。
允许 AI 给建议，但关键事实必须可追溯
摘要和建议可以由 AI 生成，但订单号、运单号、金额、日期这些事实必须能回到原邮件证据。
把“未读邮件”换成“待处理事务”
未读数本身没有意义，真正有意义的是哪些事情今天必须处理，哪些可以安全忽略。
AI 是阅读员
负责把长邮件压缩成一句话结论，提取发件人真正想让我做什么。
AI 是分类员
把邮件分到订单、物流、账单、安全、营销、系统通知等业务类型。
AI 是解释器
当系统把邮件标成紧急或无需处理时，AI 要给出人能看懂的理由。
Mailhub 现在还不是一个完整商业邮箱产品，但它已经证明了一个方向：AI 邮箱最有价值的地方，不是替我写几句回复，而是替我理解生活里的连续事务。
下一步我会继续打磨多端体验，把 iOS、Android、Mac、Windows 和网页版变成同一套业务视图。真正的目标，是让邮箱从信息堆变成个人事务系统。