邮件操作

当实际任务为邮箱工作时使用：分类、起草、回复、发送，或确认邮件已进入已发送文件夹。

这不是通用写作技能，而是围绕实际邮件界面的操作工作流。

技能栈

在相关场景下调用这些ECC原生技能：

• brand-voice 在起草任何面向用户的内容之前
• investor-outreach 用于面向投资者、合作伙伴或赞助商的邮件
• customer-billing-ops 当邮件线程属于账单/支持事件而非普通通信时
• knowledge-ops 当需要将消息或线程捕获到持久上下文中时
• research-ops 当回复依赖最新外部事实时

使用时机

• 用户要求分类收件箱或清理低价值邮件
• 用户需要起草、回复或发送新邮件
• 用户想确认邮件是否已发送
• 用户需要验证使用的账户、线程或已发送记录

安全护栏

• 除非用户明确要求实时发送，否则先起草
• 未经真实已发送文件夹或客户端确认，不得声称邮件已发送
• 不随意切换发件账户；选择与项目和收件人匹配的账户
• 清理时不删除不确定的业务邮件
• 若任务实为私信或iMessage工作，转交至messages-ops

工作流程

1. 确认具体界面

操作前明确：

• 哪个邮箱账户
• 哪个线程或收件人
• 任务是分类、起草、回复还是发送
• 用户需要仅起草还是实时发送

2. 撰写前阅读线程

若回复：

• 阅读现有线程
• 识别最后一次对外联系
• 识别任何承诺、截止日期或未回答问题

若创建新外发邮件：

• 确定亲密度等级
• 选择正确渠道和发件账户
• 起草前调用brand-voice

3. 起草，然后验证

仅起草任务：

• 生成最终副本
• 说明发件人、收件人、主题和目的

实时发送任务：

• 先验证最终正文
• 通过选定邮件界面发送
• 确认消息已进入已发送文件夹或等效的已发送副本存储

4. 报告确切状态

使用精确状态词：

• 已起草
• 待审批
• 已发送
• 被阻止
• 等待验证

若发送界面被阻止，保留草稿并报告确切阻止原因，而非未经说明即改用第二传输方式。

输出格式

邮件界面
- 账户
- 邮件线程/收件人
- 请求的操作

草稿
- 主题
- 正文

状态
- 已草拟/已发送/已拦截
- 适用时附上发送证明

下一步
- 发送
- 跟进
- 归档/移动

常见陷阱

• 未经已发送副本检查不得声称发送成功
• 不得忽略线程历史而撰写无上下文的回复
• 不得混淆邮箱工作与私信或短信工作流
• 不得泄露机密、认证详情或不必要的消息元数据

验证

• 回复中指明账户和线程或收件人
• 任何发送声明均包含已发送证明或明确的客户端确认
• 最终状态为：已起草/已发送/被阻止/等待验证