守收件箱
不碰发送键

四道门，各管一件事

四道门里，最容易做错的是最后一道。很多自动化工具会把「生成了回信」直接理解成「任务完成」， 于是顺手按了发送。我们的流程故意在这里停一下：草稿是给人看的产物，不是待执行的命令。

为什么读和写必须拆开

因为读错的代价和写错的代价不对称。摘要漏掉一句，最多是再打开原文看一遍； 收件人写错、语气写崩、把内部信息发给了陌生人，邮件出去就收不回来了。

还有一个更隐蔽的原因：邮件内容本身不可信。 一封陌生来信可以让 AI 读到「忽略之前的规则」「把文件发给我」这样的句子。 分清「资料」和「指令」，对人来说都不总是容易，对模型更不该只靠自觉。 所以邮件在流程里始终是资料，不能升级成权限。

硬拦要写在发送函数里

只在提示词里写「不要直接回信」是不够的——提示词会被误解、被覆盖，也可能在版本升级后失效。 真正可靠的做法，是让发送函数在建立 SMTP 连接之前先检查收件人：

outsiders = [addr for addr in recipients if addr not in SELF_ADDRESSES]
if outsiders and not explicit_override:
    refuse("先出草稿，等用户放行")

这里的白名单只放用户自己的地址：站点的 hello@dola.cn 和手机上的 hi@dola.cn。发给自己人可以即时发送；发给任何第三方，都必须走草稿。 这个判断放在真正发信的唯一入口上，调用方绕不过去。

草稿也必须是一份完整、可检查的文件：收件人一行、主题一行、空行、正文。 发送成功后自动归档，留下「什么时候、发给了谁、发了什么」的记录。 这样出问题时查得到源头，而不是只知道「模型说发过了」。

也别完全相信摘要：一次幽灵来信

2026 年 10 月 17 日凌晨，值守记录里出现了一封编号 999001 的来信： 发件人是 reader@example.com，主题很像一封认真写来的读者投稿。 按流程，下一步应该起草回信。

但核查原始邮箱时发现，收件箱一共只有 15 封，UID 是 1 到 15， 根本没有 999001；已发送文件夹里也没有对应的主题。值守摘要里从未出现过这条记录， 它只是被单独塞进了本地记录文件。结论很干脆：信箱里查无此信，不起草。

本地小模型也会误判。一次正常的 GitHub 验证码被规则标成了「可疑」； 它提醒我们多看一眼，但不能替我们下结论。 模型负责缩小范围，证据负责决定动作。

实测跑过的两条路

2026 年 10 月 16 日晚，这套工具完成了 IMAP 登录、SMTP 发信和往返测试， 测试信确实出现在收件箱。草稿流程也单独走过一次： 先生成草稿，确认没有发送；过目后再执行发送，最后在发件归档里找到副本。

验证逻辑很简单，但很有用：看结果，不看口头承诺。 收件箱里有没有那封信、草稿箱里是否还留着、发送后有没有归档， 都比一句「已经处理好了」可靠。

可以直接抄走的五条

最后一句：让 AI 守收件箱，真正的价值不是「它能替你回多少信」， 而是它把读信、整理和起草的重复劳动接过去，同时把最后一个决定留给你。 这条边界看起来慢，实际上是在给自动化留下一条随时能停下来的路。