inbox

Inbox — 电子邮件分类系统

独立的电子邮件分类技能。通过一条命令完成设置和定期分类。自动检测自身状态并据此选择流程，无需记住要运行哪种模式。

状态检测（始终先执行）

开始任何操作前，先检查知识库（KB）：

状态	流程
参数为 update	→ 更新模式
${WORKSPACE}/Email/email-taxonomy.md 不存在	→ 设置模式
${WORKSPACE}/Email/email-taxonomy.md 存在	→ 分类模式

边缘情况：

• 用户说“设置我的收件箱”，但 KB 已存在 → 确认后询问：“运行分类 / 更新偏好 / 两者都做？”
• 用户说“分类我的收件箱”，但没有 KB → “未找到知识库。先运行设置，然后立即进行分类。” → 设置 → 分类
• KB 不完整（部分文件缺失）→ 列出缺失的文件，并询问：“运行完整设置 / 仅补齐缺失部分？”

---

设置模式 — 构建知识库

在不存在 KB 时运行。

访谈规范

不要一次性生成所有文件。 按顺序逐一完成 8 个部分。每个部分完成后，先写入对应文件，再继续。即使用户在访谈中途离开，已完成的部分也能构成可用的部分知识库。

• 每轮只问一个问题。 绝不合并问题，即使跨越部分边界也不例外。
• 每个问题都说明“我为什么要问”——用户知道问题的意义后，回答会更好。
• 尽可能采用强制选择格式。 多选优于开放式问题。
• 按依赖关系排序。 第 N 部分为第 N+1 部分提供信息。

有关 8 个部分的访谈规范详情，请参阅 references/grill_me_section_walk.md。

知识库 — 需要生成的 7 个文件

写入 ${WORKSPACE}/Email/：

文件	用途	是否必需？
email-taxonomy.md	分类系统 + 报告偏好	是
email-patterns.md	回复风格、语气、模板、硬性规则	是
evaluation-framework.md	机会类电子邮件的决策树	仅当用户会收到推介或机会信息时
rate-card.md	定价、条款、谈判立场	仅当用户有定价时
blocklist.md	自动跳过的发件人 + 学到的拒绝模式	是（预置后会随时间扩展）
tracker.md	正在跟进的事项、逾期事项、截止日期	是（初始时基本为空）
triage-log/	存放每次运行日志的目录	是（创建为空目录）

停止条件

8 个部分总计约 25–31 个问题。硬性上限：包括补充澄清在内最多 35 个问题。如果第 1 部分未发现机会类电子邮件，第 4 部分（评估框架）将完全跳过。第 8 部分确认并发送交接消息后，信息收集即告结束——如需更改偏好，请使用 update 模式。

第 1 部分：整体情况

一次只问一个，共 6 个深度访谈问题：

• S1.Q1：“你是做什么的？用 1–2 句话介绍你的角色和业务。我为什么要问： 背景决定了预期会出现哪些电子邮件模式——独立创作者的收件箱和企业项目经理的收件箱截然不同。”
• S1.Q2：“你的收件箱里哪些内容最多？选出排名前 1–2 的类别：销售推介 / 客户工作 / 内部团队 / 新闻简报 / 客户支持 / 财务 / 其他。我为什么要问： 占主导地位的类别决定分类体系。”
• S1.Q3：“大致的邮件量占比如何？例如：‘60% 商务咨询，20% 运营，20% 噪声’。我为什么要问： 占比能告诉我应该把分类精力放在哪里。”
• S1.Q4：“分类应涵盖哪些电子邮件地址？我为什么要问： 如果有多个地址，我会为每个地址分别设置分类体系。”
• S1.Q5：“运行频率：每天一次 / 每天 2 次 / 每天 3 次 / 仅按需运行？我为什么要问： 这会决定分类时默认的搜索时间范围（每天 2 次时重叠 9 小时）。”
• S1.Q6：“是否有人协助管理电子邮件，例如助手、虚拟助理或团队成员？还是由你独自处理？我为什么要问： 委托管理的收件箱需要采用不同的角色处理方式。”

操作： 建立整体认知模型。暂时不要写入文件。记下是否存在机会类电子邮件类别（这将决定是否跳过第 4 部分）。

第 2 部分：邮件类别

根据第 1 部分提出 5–7 个类别——预先推荐其中一部分：

• 新机会
• 正在进行的对话
• 需要采取行动
• 财务
• 重要／个人
• 信息类
• 忽略／低优先级

依次提出三个需要明确回答的问题：

• S2.Q1：“这是我提议的分类体系：[列表]。这符合你收件箱的实际情况吗——符合／大致符合／不符合？*我为什么要问：*如果你回答‘不符合’，在讨论其他部分之前，我需要先重新设计分类体系。”
• S2.Q2：“有没有缺少的类别？请列出来。（如果没有，请跳过。）*我为什么要问：*缺少的类别会导致后续邮件无法归类，影响分拣质量。”
• S2.Q3：“哪类邮件平均每封最耗时？*我为什么要问：*起草回复所需的精力应主要投入在这类邮件上。”

**操作：**生成 email-taxonomy.md，列出各类别、判别信号和默认操作。

第 3 部分：回复风格与语气

六个深入提问，以及一个关键的样例请求：

• S3.Q1：“语气：正式／随意／介于两者之间？*我为什么要问：*这有助于校准默认语气；接下来我们会根据样例进一步调整。”
• S3.Q2：“说出三件你在沟通中最反感的事——你讨厌的表达、会避免的开场白。*我为什么要问：*我会把这些视为草稿中的禁用内容。”
• S3.Q3：“你总会使用的表达或结尾语——请尽可能多地列出来。*我为什么要问：*这些是你语言风格的标志。”
• S3.Q4：“在不同情境下，你会使用不同的人设吗——例如由助手代你回复？*我为什么要问：*人设情境会影响代词和签名的处理方式。”
• S3.Q5：“你通常会写多长的回复——一句话／一小段／更长？*我为什么要问：*长度是最容易把握错的风格信号。”
• S3.Q6：“硬性规则——绝不做 X／始终做 Y？*我为什么要问：*每份草稿都会严格执行硬性规则，不作妥协。”

S3.SAMPLES（质量最高的输入）：

请从收件箱中粘贴 3–5 封你实际发出的邮件。

*我为什么要问：*对自身语言风格的描述并不可靠。真实样例是最好的信号——使用 scripts/voice_sample_analyzer.py 提取模式。

**操作：**生成 email-patterns.md。样例提取规范请参阅 references/voice_calibration.md。

第 4 部分：评估框架（有条件）

**如果第 1 部分没有发现任何机会类邮件，请跳过。**否则，回答六个深入问题：

• S4.Q1：“有人向你推介某样东西时，你首先会检查什么——说说你的直觉筛选标准。*我为什么要问：*这是决策树的第一步。”
• S4.Q2：“三个会让你立即拒绝的因素。*我为什么要问：*这些将成为自动判定为不接受的信号。”
• S4.Q3：“三个会让你立即感兴趣的因素。*我为什么要问：*这些将成为接受机会的信号。”
• S4.Q4：“标准价格／条款是什么？还是‘没有固定价格’？*我为什么要问：*如果你有价目表，我会生成一份。”
• S4.Q5：“谈判立场：坚定／灵活／视情境而定？*我为什么要问：*这会影响还价草稿的语气。”
• S4.Q6：“哪些 VIP 发件人或组织的邮件总是需要跟进？*我为什么要问：*VIP 名单会绕过常规的不接受筛选条件。”

**操作：**生成 evaluation-framework.md；如果有定价信息，则同时生成 rate-card.md。

第 5 部分：屏蔽名单与模式

• S5.Q1：“始终跳过哪些发件人或域名？（如果没有，请跳过。）*我为什么要问：*自动屏蔽名单能最大限度地节省每次运行的时间。”
• S5.Q2：“你总会删除的邮件有哪些模式？*我为什么要问：*通过识别模式，分拣可以自动跳过类似邮件，而无需持续维护精确匹配规则。”
• S5.Q3：“哪些特定公司／招聘人员／新闻简报在浪费你的时间？*我为什么要问：*这些信息会用于构建屏蔽名单；随着你覆盖分拣结果，系统也会添加更多条目。”

**操作：**生成 blocklist.md。

第 6 节：当前状态

• S6.Q1：“正在跟进的活跃邮件线程——逐项列出，并为每项提供一句背景说明。（没有则跳过。）提问原因： 这些内容会成为跟踪器条目，便于分诊时了解已有背景。”
• S6.Q2：“有没有逾期未回复的邮件？提问原因： 每次运行时，分诊都会将这些邮件标记为优先事项，直到问题解决。”
• S6.Q3：“有没有带截止日期的限时事项？提问原因： 跟踪器会管理截止日期，并在适当的时候将其显示为逾期事项。”

操作： 生成 tracker.md，并创建空的 triage-log/ 目录。

第 7 节：报告偏好

• S7.Q1：“交付格式：发送给自己的邮件草稿 / 工作区中的文件 / 仅聊天摘要。提问原因： 每次运行时，分诊报告都会发送到这里。”
• S7.Q2：“详细程度：30 秒快速浏览 / 详细分析 / 两者都要。提问原因： 这会影响报告长度。”
• S7.Q3：“有没有始终优先显示的内容——例如，逾期款项或 VIP 消息？提问原因： 自定义报告置顶规则会将你关心的内容显示在标准章节上方。”

操作： 将报告偏好追加到 email-taxonomy.md。

第 8 节：确认与交接

列出创建的所有文件，并为每个文件提供一句话摘要。运行 scripts/kb_validator.py --workspace ${WORKSPACE}，确认已满足 7 个文件的约定。

然后询问：

你的邮件分诊系统已就绪。现在运行分诊吗？

1. 是——立即处理我的收件箱
2. 否——我会单独调用

如果选择“是” → 直接切换到下方的分诊模式。

隐私边界

绝不在知识库文件中保存密码、完整账号、SSN 或其他敏感凭据。 如果用户在访谈中主动提供了这些信息，表示已收到，但不要保存——在相关文件中写入 [stored separately by user]。

---

分诊模式——定期邮件分诊

知识库存在时运行。此流程刻意采用简短的初始询问。

仅创建草稿——绝不发送

此技能会创建草稿。绝不会发送邮件。

这是不可妥协的要求。运行后，scripts/draft_safety_validator.py 会强制执行此要求。操作日志中任何类似发送的工具调用都会导致验证失败。参见 references/drafts_only_safety.md。

步骤 0：简短询问（0–2 个可选覆盖问题）

Q1（仅在按需运行不符合正常运行周期时询问）：

是否覆盖默认的 9 小时搜索窗口？是（请指定小时数）/ 否。

提问原因： 如果你在正常运行周期之外启动任务，可能会希望使用更长或更短的时间窗口。

Q2（仅在用户调用时表示想跳过某些类别的邮件）：

这次运行要跳过哪些类别吗？例如“跳过新闻简报”。

提问原因： 有时你可能只想查看机会，或清理活跃邮件线程。

最多 2 个问题。 默认调用时跳过这两个问题，并使用知识库中的默认偏好运行。

步骤 1：确定搜索窗口

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

运行周期（来自 email-taxonomy.md）	默认窗口
每天 1 次	26h
每天 2 次	9h
每天 3 次	6h
仅按需运行	24h（询问 Q1）

步骤 2：搜索邮件

执行两项查询：

• 主要查询： 收件箱 + window_start 之后的已发送邮件
• 次要查询： 已加星标的未读邮件（捕获主要查询中遗漏的已标记邮件）

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

邮件服务提供方适配器：

服务提供方	工具
Gmail	Gmail MCP
Outlook / Microsoft 365	Outlook MCP
IMAP（Fastmail、ProtonMail 等）	如果可用则使用 IMAP MCP；否则停止
（没有可用的邮件工具）	停止：“此会话未注册邮件工具。”

步骤 3：分类

应用 email-taxonomy.md 中的分类体系。对于优先级最低的类别（新闻简报/自动邮件/垃圾邮件），完全跳过邮件线程读取。对于其他所有类别，读取完整邮件线程。

第 4 步：发件人调查

对于未列入跟踪表 / 屏蔽名单 / 过往日志的发件人：

1. 检查 blocklist.md → 如果匹配，自动跳过
2. 检查 tracker.md → 如果是已知邮件往来，记录已有背景信息
3. 对于机会类发件人：通过网络搜索核实其合法性、社交媒体存在情况及中介身份

完全跳过：已知发件人、内部邮件、自动通知、明显优先级较低的邮件。

第 5 步：提出建议

应用 evaluation-framework.md（如果文件不存在，则完全跳过此步骤）：

类别	适用情况	输出
TAKE IT	符合条件	建议回复；起草回复（第 6 步）
WORTH CONSIDERING	有潜力，但需要用户判断	提供背景信息；起草供用户编辑的回复
PASS	不符合条件	简要说明“原因”（1–3 句话）；起草礼貌的婉拒
FLAG FOR REVIEW	情况特殊；需要用户直接决定	完整呈现；不起草回复

框架的权威版本见 references/triage_decision_framework.md。

第 6 步：草拟邮件

按照 email-patterns.md 中的语气规则起草。绝不调用任何发送操作，只创建草稿。

邮件正文必须遵循：

• 语气风格 + 禁用词语（S3.Q2 反感用语）
• 结尾模式 + persona 背景
• 硬性规则（S3.Q6 — 不可协商）
• email-patterns.md 中规定的回复长度

**不要为以下邮件起草回复：**新闻简报、自动邮件、供参考的邮件往来、已回复的邮件往来、被屏蔽发件人的邮件。

按建议类别设定语气：

• TAKE IT → 积极投入 + 明确的下一步
• WORTH → 保持好奇 + 1–2 个澄清问题
• PASS → 礼貌婉拒 + 简要说明原因（不要含糊地承诺）
• FLAG → 不起草回复

第 7 步：发送报告

遵循 email-taxonomy.md 中的偏好。默认：将邮件草稿发送给自己。

主题： Inbox Triage — [Day], [Month Date] ([Run Label])

章节（按顺序）：

1. 概览 — 2–3 句话。发生了什么？有没有紧急事项？
2. 统计 — 已处理 / 已创建草稿 / 需要采取行动 / 已跳过
3. 需要采取行动 — 逾期事项、待决定事项、待审核草稿、截止日期
4. 快速参考 — 每封邮件一行：**Sender** — summary + recommendation
5. 详细卡片 — 机会、正在进行的邮件往来、标记事项。不要预览草稿正文。
6. 页脚 — 时间戳 + 知识库更新摘要

HTML 格式（如适用）： 仅使用内联 CSS（Gmail 会移除 <style>）。颜色编码：绿色 → TAKE IT，琥珀色 → WORTH CONSIDERING，红色 → PASS，紫色 → FLAG FOR REVIEW，蓝色 → 正在进行的对话。

第 8 步：更新知识库

blocklist.md： 追加新拒绝的发件人和模式；如果用户选择覆盖，则移除。

tracker.md： 追加新的跟进事项、更新现有事项、标记已解决事项、标记逾期事项、移除超过 30 天的已解决事项，并在更新日志中添加条目。

运行 5 次或更多后，建议改进知识库：“你总是拒绝来自 X 的邮件 — 要将其设为自动跳过吗？”

第 9 步：内部日志

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

• 已处理邮件及其分类
• 提出的建议
• 已创建的草稿（含邮件往来引用）
• 知识库更新
• 值得注意的观察

供 scripts/draft_safety_validator.py 审计。

第 10 步：收件箱为空时的处理

即使没有新邮件，也要：

1. 检查 tracker.md 中今天到期或已经逾期的事项
2. 生成简要报告：“自上次运行以来没有新的待处理邮件”
3. 标记逾期事项

收件箱为空时，完全跳过第 3–6 步。

---

更新模式 — 刷新偏好设置

由 /notion inbox update 或“更新我的收件箱偏好设置”触发。

1. 检测 ${WORKSPACE}/Email/ 中现有的文件
2. 对每个文件询问：替换 / 合并 / 跳过
3. 仅处理用户选择更新的文件对应的章节
4. 跳过用户保留的文件对应的章节

---

关键规则

1. 仅创建草稿——绝不发送。 不容妥协。
2. 隐私。 知识库文件中不得包含密码或凭据。
3. 准确优先于速度。 不确定时，标记以供审核。
4. 遵循知识库。 已记录的偏好是事实依据。不要凭主观判断推翻。
5. 透明。 在分流日志中记录每一项知识库变更。
6. 首次运行需要监督。 向用户说明这一预期。

错误处理

情况	行为
没有知识库 + 启动分流	先运行设置，然后进行分流
知识库已存在 + 启动设置	确认已存在；提供分流、更新或两者兼做的选项
知识库不完整（缺少文件）	列出缺项；提供完整设置或仅补齐缺失部分的选项
无法访问工作区	停止；告知用户文件应保存的位置；询问路径
邮件工具不可用	停止并清楚说明原因
用户拒绝提供语音样本	使用自我描述；在模式文件中标记可能需要迭代校准
用户在访谈中途退出	保留部分知识库；已提交的文件可用
新邮件超过 100 封	标记邮件量；提供仅处理优先类别的选项
发件人同时出现在屏蔽列表和跟踪列表中	以跟踪列表为准；在日志中注明不一致

可移植性

• Claude Code CLI： 原生支持——直接将 Markdown 文件写入文件系统，并使用 Gmail/Outlook MCP。
• Claude.ai 网页版： 将文件生成为制品；指导用户将其保存到工作区。

工具

脚本	作用
scripts/kb_validator.py	设置后验证包含 7 个文件的知识库（必需文件是否存在、条件文件是否与已完成的章节匹配、标头和结构是否正确）。
scripts/section_progress_tracker.py	使用 JSON 跟踪 8 个访谈章节的进度状态。
scripts/voice_sample_analyzer.py	从粘贴的已发送邮件样本中提取语音模式。
scripts/kb_reader.py	在分流开始时读取并验证包含 7 个文件的知识库。缺少必需文件时停止。
scripts/search_window_calculator.py	根据频率和当前时间计算 window_start。返回 run_label。遵循 Q1 覆盖规则。
scripts/draft_safety_validator.py	运行后扫描操作日志，检查是否存在任何形式的发送工具调用。检测到时返回 FAIL。

参考资料

• references/grill_me_section_walk.md — 8 章节流程规范、跳过逻辑、每章提交
• references/voice_calibration.md — 基于样本的语音提取理论和反模式
• references/kb_file_contract.md — 7 文件约定（结构、章节、读取行为）
• references/triage_decision_framework.md — TAKE IT / WORTH / PASS / FLAG 分类法
• references/drafts_only_safety.md — 绝不发送的规范

应拒绝的反模式

• 发送邮件——仅创建草稿，不容妥协
• 不逐章进行引导，而是一次性生成所有知识库文件
• 一次性提出所有问题（破坏逐步引导的规范）
• 在知识库中存储敏感凭据
• 在没有知识库文件的情况下进行分流
• 分流结束时跳过知识库更新
• 凭自己的判断推翻用户已记录的偏好
• 设置问题中省略“为什么这个问题很重要”
• 在分流报告中包含草稿文本预览（草稿已在邮件客户端中）
• 不使用适配器模式，导致绑定单一服务提供商