消息操作 是做什么的？
当任务是实时消息检索时使用此技能：iMessage、私信、最近的一次性代码、或后续回复前的线程检查。
这不是邮件工作。如果主要操作界面是邮箱，请使用 email-ops。
技能栈
在相关情况下将这些ECC原生技能引入工作流：
email-ops— 当消息任务实际上是邮箱工作时connections-optimizer— 当私信线程属于外部网络工作时lead-intelligence— 当实时线程应指导目标定位或预热接触时knowledge-ops— 当线程内容需要捕获到持久化上下文中时
使用时机
- 用户说“读我的消息”、“检查短信”、“看看私信”或“找到验证码”
- 任务依赖于实时线程或发送到本地消息界面的近期验证码
- 用户希望证明哪个来源或线程被检查过
安全护栏
- 首先解析来源：
- 本地消息
- X / 社交平台私信
- 其他浏览器限制的消息界面
- 不要在不指明来源的情况下声称已检查线程
- 如果有现成的辅助方法或标准路径，不要即兴进行原始数据库访问
- 如果身份验证或MFA阻止了界面，报告确切的阻止因素
工作流
1. 解析确切的线程
在执行任何事情之前，确定：
- 消息界面
- 发送者 / 接收者 / 服务
- 时间窗口
- 任务是检索、检查还是为回复做准备
2. 先读后写
如果任务可能变成后续的出站回复：
- 读取最新的入站消息
- 识别未结束的循环
- 然后根据需要交给正确的出站技能
3. 将验证码视为聚焦检索任务
对于一次性验证码：
- 先搜索本地近期消息窗口
- 尽可能按服务或发送者缩小范围
- 一旦找到验证码或聚焦搜索用尽则停止
4. 报告精确证据
返回：
- 使用的来源
- 线程或发送者（如可能）
- 时间窗口
- 确切状态：
- 已读
- 已找到验证码
- 被阻止
- 等待回复草稿
输出格式
来源
- 消息界面
- 发送者 / 线程 / 服务
结果
- 消息摘要或验证码
- 时间窗口
状态
- 已读 / 已找到验证码 / 被阻止 / 等待回复草稿
常见陷阱
- 不要混淆邮箱工作和私信/短信工作
- 不要在不指明来源的情况下声称已检索
- 当任务是查找最近验证码时，不要在广泛搜索上浪费时间
- 不要在不呈现阻止因素的情况下反复重试被阻止的身份验证路径
验证
- 回复中指明消息来源
- 回复中包含发送者、服务、线程或明确的阻止因素
- 最终状态是明确且有限的