messages-ops

消息运维

当任务是实时消息检索时使用：iMessage、私信、近期一次性验证码，或在跟进前检查线程。

这不是邮件工作。如果主要场景是邮箱，请使用 email-ops。

技能栈

在相关时将这些ECC原生技能拉入工作流：

• email-ops：当消息任务实际上是邮箱工作时
• connections-optimizer：当私信线程属于对外网络工作时
• lead-intelligence：当实时线程应指导目标定位或预热路径外联时
• knowledge-ops：当线程内容需要捕获到持久上下文中时

使用时机

• 用户说“读我的消息”、“检查短信”、“看私信”或“找验证码”
• 任务依赖于实时线程或发送到本地消息界面的近期验证码
• 用户希望证明检查了哪个来源或线程

护栏

• 首先确定来源：
  • 本地消息
  • X/社交私信
  • 其他浏览器限制的消息界面
• 未指明来源时，不得声称已检查线程
• 如果存在已检查的辅助工具或标准路径，不得自行进行原始数据库访问
• 如果认证或MFA阻止了界面，报告确切的阻止因素

工作流

1. 确定确切线程

在执行任何操作之前，先确定：

• 消息界面
• 发送者/接收者/服务
• 时间窗口
• 任务是检索、检查还是准备回复

2. 先读后写

如果任务可能转为对外跟进：

• 读取最新的入站消息
• 识别未解决的问题
• 然后根据需要移交给正确的对外技能

3. 将验证码作为聚焦检索任务处理

对于一次性验证码：

• 首先搜索近期本地消息窗口
• 尽可能按服务或发送者缩小范围
• 找到验证码或聚焦搜索耗尽后停止

4. 报告确切证据

返回：

• 使用的来源
• 线程或发送者（如可能）
• 时间窗口
• 确切状态：
  • 已读
  • 验证码已找到
  • 被阻止
  • 等待回复草稿

输出格式

来源
- 消息界面
- 发送者/线程/服务

结果
- 消息摘要或验证码
- 时间窗口

状态
- 已读 / 验证码已找到 / 被阻止 / 等待回复草稿

陷阱

• 不要混淆邮箱工作和私信/短信工作
• 未指明来源时，不得声称已检索
• 当要求是查找近期验证码时，不要在广泛搜索上浪费时间
• 不要在不报告阻止因素的情况下反复重试被阻止的认证路径

验证

• 响应中指明了消息来源
• 响应中包含发送者、服务、线程或明确的阻止因素
• 最终状态明确且有边界