Email Management

核心用法

Email Management Skill 是一套本地优先的收件箱管理工作流，核心解决「邮件过载」与「承诺遗漏」两大痛点。用户需在首次使用前阅读 setup.md 完成配置，系统将在 ~/email-management/ 目录下建立结构化记忆空间，包括状态追踪、待办跟进、回复模板、VIP 联系人名单及周期性摘要。

使用场景覆盖三类需求：
1. 收件箱分流 — 按 Action/Waiting/FYI/Noise 四象限快速分类，防止紧急事项被淹没
2. 上下文感知起草 — 基于邮件内容生成回复草稿，确保「下一步动作」明确（提问、决策或预约具体行动）
3. 承诺闭环追踪 — 自动提取邮件中的截止日期、责任人、当前状态，写入 follow-ups.md 防止遗忘

显著优点

• 零外部依赖：默认不连接任何邮件 API，不传输用户数据，纯本地文本分析
• 防错设计：强制「先分类再回复」「确认再发送」流程，杜绝自动化越界
• 可复用资产：模板系统支持高频场景（状态更新、婉拒、澄清、跟进）快速拼装，同时保留个性化空间
• 优先级纪律： urgency 判定绑定硬性信号（VIP 发件人、硬截止、财务/法律风险、阻塞决策），避免「事事紧急」的通胀陷阱

潜在缺点与局限

• 非全自动：需用户手动粘贴或导入邮件文本，无法直接读取 Gmail/Outlook 收件箱
• 学习成本：四象限分类、记忆目录结构、模板语法均需初期投入
• 无智能排序：依赖用户提供的 VIP 名单和规则，不具备机器学习驱动的自适应优先级
• 跨设备同步：纯本地文件，若用户多设备使用需自行配置云同步

适合人群

• 日邮件量 20-200 封、需要系统化管理承诺的知识工作者
• 对数据隐私敏感、拒绝 SaaS 邮箱助手的企业用户
• 已有邮件客户端、希望叠加「处理工作流」而非替换基础设施的用户

常规风险

• 模板滥用：未根据上下文调整模板导致回复机械化，损害专业关系
• 闭环幻觉：标记线程为「已完成」但未获对方确认，隐藏承诺残留
• 分类疲劳：长期未审视 VIP 名单和噪声规则，分类准确度衰减
• 本地数据：虽不上传云端，但本地文件若未加密，设备丢失即暴露工作关系网络

核心用法

email-management 是一个纯 Markdown 文档型 Skill，专注于电子邮件管理的结构化工作流。它不直接连接邮箱 API，而是通过本地文件系统 (~/email-management/) 维护邮件管理上下文，包括：

• 分类系统：将邮件标记为 Action/Waiting/FYI/Noise 四类，防止高优先级消息被淹没
• 回复起草：基于决策清晰原则，确保每封草稿明确下一步（提问、决策或具体行动）
• 承诺跟踪：在 follow-ups.md 中记录所有带截止日的承诺，标注负责人和状态
• 模板复用：通过预审批的模板块处理常见场景（状态更新、拒绝、澄清、跟进），但要求定制化开头结尾以避免机械感
• 定期摘要：高负载时输出优先级、逾期跟进、待他人回复、可归档邮件的精简概览

显著优点

1. 零代码风险：100% Markdown 文档，无可执行代码、无网络调用、零依赖，从根本上消除注入和执行风险
2. 数据主权保障：所有数据本地存储，无云端同步或外发，符合 GDPR 数据最小化原则
3. 用户控制优先：自动化边界、敏感操作均需显式确认，不自动发送邮件、不后台运行
4. 工作流即文档：分类、跟踪、模板等最佳实践被编码为可查阅的结构化指南
5. 清晰的隐私边界：明确声明不收集密码、令牌、API 凭证

潜在局限

• 无原生邮箱集成：需用户手动粘贴邮件内容或配合其他 Skill 获取邮件
• 依赖用户自律：系统本身无提醒机制，跟进跟踪的有效性取决于用户定期查阅 follow-ups.md
• 模板滥用风险：若用户不复用模板直接发送，可能导致回复显得冷漠机械
• 无协作功能：单用户本地文件，不支持团队共享状态

适合人群

• 收件箱常年过载、需要结构化方法而非更多自动化工具的知识工作者
• 对邮件隐私敏感、不愿将完整邮箱数据授权给第三方服务的用户
• 已使用 Claude 等 AI 助手、希望建立可复用邮件处理习惯的用户
• 需要维护大量"等待回复"状态的专业角色（销售、项目管理、客户成功）

常规风险

• 过度依赖模板：若机械套用模板不调整语气，可能损害沟通信任
• 分类疲劳：持续维护 Action/Waiting/FYI/Noise 标签需要纪律，中断后易堆积
• 本地数据丢失：~/email-management/ 目录无自动备份，误删或换机迁移需手动处理
• 隐私悖论：虽然 Skill 本身安全，但用户仍可能在模板中无意识记录敏感信息