消息运维 是做什么的？
当任务是实时消息检索时使用：iMessage、私信（DM）、近期一次性验证码，或在后续操作前检查线程。
这不是邮件类工作。如果主要界面是邮箱，请使用 email-ops。
技能栈
在相关时将以下ECC原生技能引入工作流：
email-ops— 当消息任务实际上是邮箱操作时connections-optimizer— 当DM线程属于对外网络工作时lead-intelligence— 当实时线程应为目标定位或预热式外联提供信息时knowledge-ops— 当线程内容需要捕获到持久上下文时
使用时机
- 用户说“读我的消息”、“检查短信”、“查看私信”或“找到验证码”
- 任务依赖于某个实时线程或已交付到本地消息界面的近期验证码
- 用户希望证明检查了哪个来源或线程
安全护栏
- 首先明确来源：
- 本地消息
- X / 社交媒体私信
- 其他浏览器限制的消息界面
- 未指定来源时，不得声称已检查某线程
- 如果存在已检查的辅助工具或标准路径，不得擅自进行原始数据库访问
- 如果认证或MFA阻挡了访问，需报告确切的障碍信息
工作流
1. 确定具体线程
在进行任何操作之前，先明确：
- 消息界面
- 发送者/接收者/服务
- 时间窗口
- 任务是检索、检查还是回复准备
2. 先读取，后起草
如果任务可能转为对外跟进：
- 读取最新入站消息
- 识别未完成的环节
- 然后按需移交至相应的对外技能
3. 将验证码视为聚焦检索任务
对于一次性验证码：
- 首先搜索近期的本地消息窗口
- 尽可能按服务或发送者缩小范围
- 一旦找到验证码或聚焦搜索已穷尽即停止
4. 报告精确证据
返回：
- 使用过的来源
- 可能时提供线程或发送者
- 时间窗口
- 精确状态：
- 已读取
- 已找到验证码
- 受阻
- 等待起草回复
输出格式
来源
- 消息界面
- 发送者/线程/服务
结果
- 消息摘要或验证码
- 时间窗口
状态
- 已读取 / 已找到验证码 / 受阻 / 等待起草回复
常见陷阱
- 不要混淆邮箱工作和私信/短信工作
- 未指定来源时，不得声称已检索
- 当需求是查找近期验证码时，不要浪费时间在广泛搜索上
- 不要反复重试受阻的认证路径而不报告障碍
验证
- 响应中应指明消息来源
- 响应中应包含发送者、服务、线程或明确的受阻信息
- 最终状态应明确且有边界