【征文】#WorkBuddy# 早上 9 点自动出邮件晨报：归档 + 摘要 + 待办，一条指令跑完

一、你会遇到的场景

早上 9 点坐下，邮箱里躺着三十多封新信。你的大脑要做三件事：判断哪封今天必须处理、把剩下的归位、把这周要还的人情账记下来。

这三件事有个共同点：判断标准每周都一样，但每周都要重做一遍。这正是自动化最该出手的位置——不是让 AI 替你想，而是让它把"想"的原料（一份结构化的清单）端到桌上。

我的做法是：不做"AI 帮我读邮件"，做一条指令 → 一份只读晨报。AI 负责按时把数据拉出来、整理好、排好优先级；判断和回信仍然由人完成。

二、结论先行

一句话：用 WorkBuddy 的定时任务，每天 9:00 触发「拉取最近 24 小时邮件 → 跑规则脚本 → 生成 Markdown 晨报 → 写进本地归档目录」，全程只读，零代发。

为什么值得做：

适用边界：邮件正文里隐含要求（比如"这个你看着办"）不会被抓出来；本方案只解决"整理"，不解决"决策"。

三、完整操作步骤

第 1 步：确认邮箱以只读方式接入（macOS）

WorkBuddy 里打开连接器市场，启用「智能体邮箱（Agent Mail）」。首次使用会引导授权，只授予读取权限即可——本文全流程不需要 mail:send 作用域。

授权完成后，可以先做一次连通性验证，让 WorkBuddy 执行：

列出我最近 3 天的收件邮件，只要发件人、主题、时间三个字段，不要正文

如果这里返回空列表，不要慌。先用最原始的方式确认账号状态：

查一下我的邮箱账号信息和当前授权范围

第 2 步：把邮件导出成本地 JSON

在 WorkBuddy 里下达：

用邮箱连接器拉取最近 24 小时的收件邮件，导出为 JSON 数组，
每条保留 id / from / subject / date / snippet 五个字段，存到
~/Desktop/mail-raw/inbox-$(date +%Y%m%d).json

说明三点：

1. snippet 而不是 body：先只取摘要字段。完整正文往往带 HTML，噪声大，等晨报跑通了再决定要不要拉全文。
2. 按天分文件：文件名带日期，天然形成时间序列，出错时能精确回溯是哪一天的规则出了问题。
3. 为什么要落盘而不是直接喂给 AI：规则脚本要有稳定、可重复的输入。你直接对话提问，每次拿到的数据都不一样，没法验证规则改动到底是好是坏。

第 3 步：把规则脚本放进项目目录

脚本全文见附件 mail_digest.py，无第三方依赖，Python 3.11+ 直接跑。核心是三张规则表：

# 归档建议规则：(正则, 目标文件夹)，命中第一条即停
ARCHIVE_RULES = [
    (r"(?:告警|报警|异常|失败|error|alert|incident)", "需要立刻处理"),
    (r"(?:安全|登录|密码|验证码|异地登录|security)", "账号安全"),
    (r"(?:订阅|推广|优惠|营销|newsletter|promo|unsubscribe|退订)", "订阅营销-可批量清空"),
    (r"(?:课程|学习|资料|白皮书|报告下载)", "知识沉淀"),
    (r"(?:合同|协议|条款|法务|compliance|contract)", "合同协议"),
    (r"(?:面试邀请|面试|笔试)", "待办-面试"),
    (r"(?:发票|报销|付款|到账|账单|order|invoice|receipt)", "财务凭证"),
    (r"(?:日报|周报|月报|季度报告|OKR|周会|例会)", "工作记录"),
]

# 待办判定：请求词 + 明确截止时间，两者同时命中才算数
TODO_VERBS_ZH = r"(?:请|麻烦|烦请|需要|帮忙|务必|记得|辛苦|烦)"
DEADLINE = (
    r"(?:今天|今日|今晚|明天|明日|后天|大后天|本周[一二三四五六日天]?|下周[一二三四五六日天]?|"
    r"本周内|本月\s*\d{1,2}\s*[日号]|\d{1,2}\s*月\s*\d{1,2}\s*[日号]|\d{4}-\d{2}-\d{2}|"
    r"\d{1,2}\s*[:：]\s*\d{2}|\d{1,2}\s*点(?:半)?|今天下班前|下班前|上班前|上午|下午|晚上|月底前)"
)

规则表顺序就是优先级，这是本方案最容易踩的坑，第五节详述。

第 4 步：先手动跑通，再挂定时

# 1) 造一份虚构数据先验证脚本本身（附件 sample_inbox.json）
python3 mail_digest.py sample_inbox.json -o /tmp/digest.md -w 72

# 2) 再跑真实导出数据
python3 mail_digest.py ~/Desktop/mail-raw/inbox-$(date +%Y%m%d).json \
  -o ~/Desktop/mail-digest/晨报-$(date +%Y%m%d).md -w 24

脚本返回码约定：0 正常、2 文件不存在、3 JSON 解析失败（会打印出错的行号列号）、4 顶层结构不对。这四个码覆盖了 95% 的失败场景，定时任务里可以直接按码判断要不要告警。

第 5 步：挂上每天 9:00 的定时任务

在 WorkBuddy 里说：

创建一个每天早上 9:00 执行的自动化任务：
1. 用邮箱连接器拉取最近 24 小时收件邮件，导出为 JSON 到 ~/Desktop/mail-raw/
2. 运行 python3 mail_digest.py 处理该文件，输出晨报到 ~/Desktop/mail-digest/
3. 把当日待办数量与 P0 邮件主题列在结果里
4. 如果脚本返回码非 0，把完整 stderr 原样回传给我
5. 全程只读：不发送邮件、不修改邮件状态、不删除任何邮件

第 4 条和第 5 条是整段配置里最值钱的两句。前者让失败对你可见，后者把风险锁死。

配好后 WorkBuddy 会生成类似下面的定时规则（自然语言 → 结构化 rrule）：

FREQ=DAILY;BYHOUR=9;BYMINUTE=0

第 6 步：让 AI 只做它擅长的那一步

晨报出来后，你要回信时，不要让定时任务替你发。正确姿势是：把晨报内容粘回 WorkBuddy 会话，让它起草，你改完再发。

根据下面这封邮件的摘要，起草一封回复。
要求：语气专业克制，不承诺任何未确认的交付时间，
不代替我做决定，只把需要我确认的点列成清单。

「不代替我做决定」「不承诺时间」这两句约束，比任何提示词技巧都管用——邮件是有法律效力的通信，出错的代价不对称。

四、实测数据

以下均为本人在 macOS（Apple Silicon，Python 3.13.12）本机真实执行的结果，数据源为虚构演示数据 sample_inbox.json（6 封邮件，72 小时窗口）：

完整输出见附件 digest_output_sample.md。真实数据部分：

• 用本人真实邮箱（近 30 天、平均【待本人实测补充】封/天）跑同一脚本，耗时：【待本人实测补充】
• 真实邮箱的待办准确率（人工抽检 20 条）：【待本人实测补充】

迭代过程值得一写：这个脚本的待办提取逻辑我改了 5 版才收敛。V1 把邮件标题也纳入抽取，结果「面试邀请：后端工程师」被当成待办；V2 要求"请求词 + 截止时间"同时命中，误报清零；V3 漏掉了「本月 20 日」这种表达；V4 切分出的待办主体只剩「请于（今天前）」这种没有动作的碎片；V5 归档规则顺序没排对，「本周 AI 周报（订阅）」被判成工作记录。每一次都是跑真实输出、看表格、发现不对、再改，不是坐在那里想。

五、踩坑与边界

坑 1：归档规则的顺序就是优先级

ARCHIVE_RULES 是顺序匹配，命中第一条即停。一封标题为「本周 AI 办公产品周报（订阅）」的邮件，如果「周报」规则排在「订阅」规则前面，它会被判成"工作记录"，而不是"订阅营销"——而这两类邮件的处理动作完全相反：前者要归档查阅，后者要批量清空。

结论：把"需要立刻处理""账号安全""订阅营销"这类动作差异最大的规则放最前面，业务分类放后面。

坑 2：HTML 标签会让匹配悄悄失效

正文里的 <b>发票</b> 如果不去标签，正则匹配到的字符串就变成 <b>发票，同类规则会漏判。脚本里统一做了 re.sub(r"<[^>]+>", " ", body)，注意替换成空格而不是空串，否则 <p>请</p><p>于</p> 这种拆分标签会拼成错误的新词。

坑 3：时间格式比想象中多

实测踩到的：RFC 2822 格式（Tue, 16 Oct 2026 08:41:00 +0800）、ISO 8601 带时区、Unix 时间戳（秒/毫秒两种量级）、internalDate 这种 Gmail 字段名。脚本里写了 to_dt() 逐个尝试，解析失败就返回 None，宁可漏掉这封邮件，也不要用一个错误的时间把它排到错误的窗口里。

时间戳量级判断也踩过坑：| raw > 1e11 用来区分秒和毫秒，2026 年的秒级时间戳约 1.79e9，毫秒级约 1.79e12，阈值 1e11 是安全的分界。

边界 1：待办会漏，这是刻意的取舍

规则只认"显式请求 + 明确截止时间"。以下三类必然漏：

• 「这个方案你尽快看一下」——没有截止日期，不算待办
• 「另外附件里有份合同」——没有请求词，不算待办
• 「下周一例会讨论」——没有请求词，不算待办

我选择漏而不是全抓。一份晨报里如果 30% 是噪音，你就不再信任它了，这是自动化工具的death grip：可信度一旦崩掉，人就会回到手动看邮件，自动化沦为一次性演示。

边界 2：待办主体偶尔会被截断

最新一版仍有瑕疵：正文是「连接池占用 98%，请于今天下班前确认扩容方案」时，主语段可能被截成「98%」而不是「连接池占用 98%」。原因是主语段与请求词之间只隔一个逗号时，代码会把它们当作同一段的两个部分。根治要靠分词或语义切分，纯正则做不到。 当前状态是 6 条里错 1 条，可接受——错的那条人一眼能看出来。

边界 3：绝不代发

本文全流程没有任何一处调用发送接口，脚本里也不存在发送函数。这不是功能没做完，是设计目标：邮件一旦由 AI 自动发出，收件人的信任、责任归属、后续追责全都会变得不可控。把"起草"交给 AI，把"发送"留给人，是目前唯一稳妥的分工。

边界 4：邮箱数据属于个人隐私资产

导出到本地的 JSON 里包含全部邮件正文。这些文件不要进任何公开仓库、不要贴进公开对话、不要随手丢进云盘同步目录。 建议做法：归档目录单独设权限，用完按周清理，只保留晨报 Markdown，删掉原始 JSON。本文附件里的 sample_inbox.json 是我虚构的，可以随便看、随便跑。

六、小结

邮件整理这件事，难点从来不是"读邮件"，而是在不越权的前提下，把判断的原料准备好。一条指令、一份只读晨报、一个人来拍板，这个边界是这套方案能长期跑下去的原因。

如果你也想试，先只做两件事：跑一次脚本看输出，然后手动校对一次待办表。等你发现连续一周都没漏掉重要事项，再挂定时。先验证，再自动化，反过来就是本末倒置。