收件箱筛选

inbox-triage
分类设计
作者Alireza Rezvani
许可MIT
评分4.50/5
使用5.1K

Inbox-Triage — 定期邮件分拣

> 与 inbox-setup 配对使用。 本技能调用 inbox-setup 在 ${WORKSPACE}/Email/ 写入的 7 个知识库文件。文件契约必须完全匹配。请参阅 references/kb_file_contract.md —— 这是从读取端视角看到的设置端契约镜像。

按周期运行（每天 1-3 次）或按需运行。对近期邮件进行分类，研究新发件人，生成决策建议，起草回复（绝不发送），交付简洁的报告，并根据本次运行的学习结果更新知识库。

调用触发词

  • "triage my inbox"
  • "inbox triage"
  • "check my email"
  • "run email triage"
  • "process my inbox"
  • "what's new in my email"
  • "handle my email"
  • "email triage"

前置条件

启动时必须读取以下内容（缺失则快速失败）：

核心（必选）：

  • ${WORKSPACE}/Email/email-taxonomy.md — 分类 + 报告偏好

  • ${WORKSPACE}/Email/email-patterns.md — 语气、人格、模板、硬性规则

可选核心（存在则读取）：

  • ${WORKSPACE}/Email/evaluation-framework.md

  • ${WORKSPACE}/Email/rate-card.md

动态更新（每次运行需读取并更新）：

  • ${WORKSPACE}/Email/blocklist.md

  • ${WORKSPACE}/Email/tracker.md

输出：

  • ${WORKSPACE}/Email/triage-log/<YYYY-MM-DD>-<run-label>.md — 每次运行的日志

如果缺失任何核心必选文件 $\rightarrow$ 停止运行，引导用户先运行 inbox-setup。使用 scripts/kb_reader.py 执行读取和验证。

仅限草稿 — 绝不发送

> 本技能仅创建草稿，绝不发送。

这是确保该技能可以自动安全运行的安全属性。在本文档中多次强调。不可协商。

scripts/draft_safety_validator.py 在运行后执行强制验证。操作日志中任何类似“发送”的工具调用都将导致验证失败。完整规范请参阅 references/drafts_only_safety.md。

步骤 0：轻量化需求确认（0-2 个可选覆盖问题）

Inbox-triage 在设计上采用轻量化输入 —— 它按周期运行，偏好已通过 inbox-setup 预先植入知识库。此处的确认机制仅询问对本次运行至关重要的覆盖问题。

Q1（可选，仅在按需运行且超出正常频率时询问）

> O
是否覆盖默认的 9 小时搜索窗口？请选择：是（请指定小时数）/ 否（使用默认）。**
>
> *询问原因：* 如果您是在常规的每日 2 次频率之外按需运行，您可能需要更宽的窗口（如长时间休息后的 24 小时）或更窄的窗口（如快速检查时的 2 小时）。

如果运行频率正常，请跳过。

Q2（可选，仅在用户触发 category-skip 意图时询问）

> 本次运行需要跳过任何类别吗？例如，“跳过新闻通讯 (newsletters)”，“跳过财务 (financial)”。
>
> *询问原因：* 有时您可能只想扫描机会或仅想清理活动线程。类别跳过可以缩小运行范围。

如果用户未给出 category-skip 信号，请跳过。

停止条件： 最多 2 个问题。默认调用将跳过这两个问题，并使用 KB-default 偏好运行。该技能针对快速循环执行进行了优化；信息采集是例外而非常态。

步骤 1：确定搜索窗口

通过当前日期计算。默认回溯时间：9 小时（适用于每日 2 次的频率，并带有轻微重叠，以确保不会遗漏运行期间的邮件）。

使用 scripts/search_window_calculator.py --cadence <CADENCE> --now <ISO>：

code
now = current_datetime
window_start = now - 9_hours   (每日 2 次的默认值)
run_label = "Morning" if now.hour < 12 else "Afternoon" if now.hour < 17 else "Evening"

频率与默认窗口映射表（可通过 Q1 覆盖）：

| 频率 (来自 email-taxonomy.md S1.Q5) | 默认窗口 |
|---|---|
| 每日一次 | 26h |
| 每日两次 | 9h |
| 每日三次 | 6h |
| 仅按需运行 | 24h (询问 Q1) |

步骤 2：邮件搜索

执行两次查询（采用与供应商无关的适配器模式）：

  • 主查询： 收件箱 + 已发送 $\rightarrow$ 时间在 window_start 之后
  • 次查询： 已星标且未读（捕捉主查询中遗漏的标记项）

收集每封邮件的：发件人、主题、日期、片段、线程 ID、标签。

供应商适配器映射：

| 供应商 | 工具 |
|---|---|
| Gmail | Gmail MCP |
| Outlook / Microsoft 365 | Outlook MCP |
| IMAP (Fastmail, ProtonMail 等) | 如果可用则使用 IMAP MCP；否则停止 |
| (无可用邮件工具) | 停止并显示清晰消息：“此会话未注册邮件工具。” |

步骤 3：分类

应用 email-taxonomy.md 中的分类法。对于最低优先级类别（新闻通讯 / 自动化 / 垃圾邮件）：完全跳过线程读取 —— 因为上下文成本不值得。对于其他所有类别：读取完整线程。

步骤 4：发件人调研

对于不在追踪列表 / 黑名单 / 历史日志中的发件人：

1. 检查 blocklist.md $\rightarrow$ 若匹配，自动跳过
2. 检查 tracker.md $\rightarrow$ 若为已知线程，记录现有上下文
3. 对于机会类发件人（根据评估框架）：通过网络搜索确认公司合法性、社交媒体存在感、中间人状态

完全跳过调研的情况： 已知发件人（在追踪列表中）、内部邮件、自动化通知、明显的低优先级邮件。

步骤 5：建议

对于需要决策的邮件，应用 evaluation-framework.md 中的框架。分类如下：

| 类别 | 触发条件 | 输出 |
|---|---|---|
| TAKE IT (接洽) | 符合标准 | 建议接洽；起草回复（步骤 6） |
| WORTH CONSIDERING (值得考虑) | 有潜力，需用户判断 | 呈现关键上下文；起草供用户修改的草稿 |
| PASS (放弃) | 不符合标准 | 简短的“原因”（1-3 句）；起草礼貌的拒绝信 |
| FLAG FOR REVIEW (标记审核) | 异常；需用户直接决策 | 完全呈现；不提供草稿（由用户决定回复形式） |

每项建议需包含：简短的“原因”、相关上下文，以及（如果适用）价格/时间线的对比。

如果不存在 evaluation-framework.md，则完全跳过步骤 5。

参见 references/triage_decision_framework.m
d 作为框架标准。

第 6 步：起草回复

针对每个合理的回复候选方案，根据 email-patterns.md 的语气规则创建草稿。

需要起草的情况： 机会响应（接受 TAKE IT / 值得考虑 WORTH / 放弃 PASS）、需要回复的活跃对话、待办事项、重要的个人邮件。

无需起草的情况：

  • 明确无需回复的邮件（时事通讯、自动化通知、仅供参考 FYI）

  • 用户已回复的会话线程

  • 已屏蔽的发件人（除非新信息改变了判断）

执行机制：

  • 尽可能在现有线程中起草（以保留上下文）
  • 设置 to（收件人）和 subject（主题，格式为 Re: [原主题]）
  • 绝对不要调用任何发送操作。仅创建草稿。

草稿正文必须遵守：

  • email-patterns.md 中的语气档位

  • 禁用词汇（S3.Q2 避雷点）

  • 结尾签名模式

  • 人设上下文

  • 硬性规则（S3.Q6 —— 不可协商）

  • email-patterns.md 规定的回复长度

如果存在 evaluation-framework.md，草稿语气应与建议匹配：

  • TAKE IT $\rightarrow$ 积极参与 + 具体下一步行动

  • WORTH $\rightarrow$ 好奇 + 1-2 个澄清问题

  • PASS $\rightarrow$ 礼貌拒绝 + 简短理由（不要给出模棱两可的承诺）

  • FLAG $\rightarrow$ 不起草

第 7 步：报告交付

遵循 email-taxonomy.md “报告偏好”部分中的用户设置。默认：发送 HTML 格式的草稿邮件给自己。

主题： Inbox Triage — [星期], [月 日] ([运行标签])

章节（按顺序）：

1. 概览 (Overview) — 2-3 句话。发生了什么？是否有紧急事项？
2. 统计 (Stats) — 数量统计：已处理、已创建草稿、需要采取行动、已跳过。
3. 待办事项 (Action Needed) — 过期项目、待决策事项、待审核草稿、截止日期。
4. 快速索引 (Quick Reference) — 每封邮件一行，按发件人字母顺序排列。发件人 — 一句话摘要 + 建议。
5. 详细卡片 (Detailed Cards) — 机会、活跃线程、标记项。每项包含：发件人 / 主题 / 类别，建议 + 理由，关键上下文。不要包含草稿正文预览（用户可在邮件客户端直接阅读草稿）。
6. 页脚 (Footer) — 生成时间戳 + 知识库 (KB) 更新摘要。

格式要求（若为 HTML）：

  • 仅限内联 CSS（Gmail 会过滤 <style> 标签）
  • 根据建议进行颜色编码：
- 绿色 $\rightarrow$ TAKE IT - 琥珀色 $\rightarrow$ WORTH CONSIDERING - 红色 $\rightarrow$ PASS - 紫色 $\rightarrow$ FLAG FOR REVIEW - 蓝色 $\rightarrow$ 活跃对话

第 8 步：知识库更新

blocklist.md（追加）：

  • 新拒绝的发件人 + 理由 + 日期
  • 从观察行为中总结的新拒绝模式（例如：“所有来自 gmail 地址且包含 'looking for backend engineers' 的邮件 $\rightarrow$ 冷启动招聘模式”）
  • 如果用户覆盖了设置，则删除条目（用户回复了“已屏蔽”的发件人 $\rightarrow$ 解除屏蔽）

tracker.md（追加 + 更新）：

  • 为需要后续行动的邮件添加新跟进项
  • 更新现有跟进项（截止日期变更、状态变更）
  • 将已解决的项目标记为完成
  • 标记过期项目
  • 删除超过 30 天的已解决项目
  • 在更新日志中添加条目

跨运行周期观察的学习模式：

  • 草稿是原样发送、被修改还是被删除 $\rightarrow$ 语气校准信号
  • 用户覆盖了 PASS 建议 $\rightarrow$ 框架调整信号
  • 被参与 vs 被忽略的邮件 $\rightarrow$ 分类法优化信号
  • 新的拒绝模式 $\rightarrow$ 屏蔽列表补充

在运行 5 次以上后，向用户建议 KB 改进方案（例如：“您总是拒绝来自 X 的邮件 —— 是否将其设为自动跳过？”）。

第 9 步：内部日志

保存至 ${WORKSPACE}/Email/triage-log/[YYYY-MM-DD]-[run-label].md：

  • 已处理的邮件及其分类
  • 给出的建议
  • 创建的草稿（含 ID / 线程引用）
  • 知识库更新内容
  • 后续跟进事项
s 已添加 / 已解决
  • 显著观察结果（浮现的模式、处理的边缘情况）

该日志是 scripts/draft_safety_validator.py 的审计追踪，用于在运行后扫描发送操作。

步骤 10：空收件箱处理

即使没有新邮件：

1. 检查 tracker.md 中今日到期或逾期的项目
2. 生成极简报告：“自上次运行以来没有新的可操作邮件”
3. 标记任何逾期项目
4. 根据 tracker 规则进行升级处理

若收件箱为空，完全跳过步骤 3-6。

关键规则（多次强调）

1. 仅限草稿 —— 绝不发送。 不可协商。在此再次强调。
2. 隐私。 KB 中不得包含密码/凭据。敏感内容请通过 ID 引用线程。
3. 准确性高于速度。 不确定时，标记为待审核。错误的自动草稿比没有草稿更糟糕。
4. 尊重 KB。 文档化的偏好是唯一事实来源。不要用主观判断覆盖。
5. 透明度。 在分拣日志中记录每一次 KB 更改。
6. 首次运行需要监督。 向用户说明此预期。

错误处理

| 情况 | 行为 |
|---|---|
| KB 文件缺失 | 停止；引导用户运行 inbox-setup |
| 邮件工具不可用 | 停止并发出关于所需工具的明确消息 |
| 发件人调研时网页搜索不可用 | 跳过调研步骤；在日志中注明发件人未调研 |
| 草稿创建失败 | 跳过该草稿；在日志中记录；继续生成报告 |
| 报告交付失败 | 将报告保存到文件作为备选方案；通知用户 |
| 用户有 100+ 封新邮件 | 保持在合理限制内；标记邮件量；提议仅关注优先级类别 |
| 发件人同时出现在黑名单和 tracker 中 | 以 tracker 为准（活跃对话）；在日志中记录不一致性 |

可移植性

  • Claude Code CLI： 原生支持 —— 使用 Gmail / Outlook MCP，文件工具用于 KB，网页搜索用于调研。
  • Claude.ai 网页版： 在连接邮件 MCP 连接器（可用 Gmail MCP）时有效。技能在假设可用前必须检查工具可用性。若无邮件工具：停止并发出明确消息。

工具链

| 脚本 | 角色 |
|---|---|
| scripts/kb_reader.py | 读取并验证 7 个 KB 文件。返回解析后的结构。若缺少必要文件则报错停止。 |
| scripts/search_window_calculator.py | 根据频率 + 当前时间计算 window_start。返回 run_label。遵循 Q1 覆盖规则。 |
| scripts/draft_safety_validator.py | 运行后扫描操作日志，检查是否有任何类似“发送”的工具调用。若检测到则判定为失败。这是对“绝不发送”规则的确定性强制执行。 |

参考资料

应拒绝的反模式

  • 发送邮件（仅限草稿 —— 不可协商）
  • 在没有知识库文件的情况下运行
  • 在 KB 中存储密码/凭据
  • 在运行结束时跳过学习循环（KB 更新）
  • 用主观判断覆盖用户记录的偏好
  • 阅读最低优先级的线程（浪费上下文）
  • 在报告中包含草稿文本预览（草稿已在邮件客户端中）
  • 没有适配器模式的供应商锁定
  • 工具缺失时静默失败

---

版本： 1.0.0
源规范： megaprompts/07-inbox-triage-megaprompt.md
pts/07-inbox-triage-megaprompt.md)
构建模式： 路径 B（直接转换）。与 inbox-setup` 配对使用。