thread-object-realignment

name	thread-object-realignment
description	长 thread 切题后的对象重定协议——thread 历史 ≥5 条且检测到切题信号时，回复前必做「用户最后显式问题对象 vs 待发回复对象」一致性校验，不一致则改写或反问。Use when Slack thread 历史 ≥5 条且当前用户消息出现切题信号（主题词突变、问句指向新实体、时间线跳跃、出现「另外」「话说」「回到 X」「换个话题」等切题语，或 ≥3 turn 后用户显式问题对象与最近 assistant 回复对象不同）。
provenance	user-authored

Thread 对象重定（Realignment）协议

长 thread 切题后，agent 容易沿最近技术支线惯性续答，导致回复对象失焦。本 skill 给出切题信号识别 + 一致性校验 + 改写/反问模板。

When to Use

满足以下任一条件时召回：

• Slack thread 历史 ≥5 条
• 当前用户消息含切题信号词（见下）
• 最近 ≥3 turn 都在某技术支线，但当前用户消息的对象不在那条线上

短 thread（≤4 条）/ 单一对象的连续追问 → 跳过本协议。

切题信号识别

显式信号（高置信度）：

• 转折词：「另外」「话说」「对了」「顺便」「换个话题」
• 重定向：「回到 X」「先不说 Y」「我们回 Z」
• 元问句：「我刚才问的是…」「你没回答…」「我说的是…」

隐式信号（中置信度，需结合上下文判断）：

• 主题词突变：thread 一直在讨论 A，当前消息出现完全不相干的 B 实体（人名/项目名/系统名）
• 问句指向新实体：用户用具体名词指代但前文没出现过该名词
• 时间线跳跃：thread 在讨论今天，用户突然问昨天/上周
• 编号引用错位：用户说「1」「2」但当前 thread 中编号语义已变

陷阱（看似切题实则未切题）：

• 用「这个」「那个」指代最近对象 → 不是切题，按 § 上下文先行 第 3 条处理
• 在同一对象下追问细节 → 不是切题，正常深入

一致性校验流程（回复前必做）

1. 抽对象：从「用户最后一条消息」抽出显式问题对象（is what / who / which）。注意是「最后一条」，不是 thread 整体主题
2. 看回复：当前草稿回复在讨论的对象是什么
3. 比对：
   • 一致 → 正常发出
   • 不一致 → 改写或反问，不要带过渡句蒙混（如「关于这个，顺便也说下…」）

改写 / 反问模板

完全不一致 → 改写：直接回答用户最后显式问题，丢掉惯性支线内容。如要保留可放结尾一行「（关于刚才 X 支线，要继续吗？）」交给用户决定

不确定切题对象 → 反问：

• 「你这条问的是 A 还是 B？thread 上文有提到两个对象，怕答错」
• 「『1』『2』指的是 [候选 A] 还是 [候选 B]？」

部分相关 → 分层回复：先答用户最后显式问题（主体），再用一句话挂上下文支线（备注）

Gotchas

• 别假装"对象一致"：明知道切题了还硬接最近支线 + 加过渡句，比直接说"我刚才偏了"更糟。Karry 比较敏感
• 反问不是逃避：但反问要有具体候选项（A/B），不要泛泛问「你指什么」
• thread 历史读全：不能只看最近 1-2 条。切题判断需要看用户最后显式问题，可能是 3-5 条之前的元问句
• 不在每个 turn 都做校验：短 thread / 同对象追问跳过，否则反而拖慢响应。trigger 严格按 § When to Use
• 代码任务里编号歧义最容易翻车：「1 改一下」在长 thread 里可能指列表项 1 / 第一步 / 选项 1，三者完全不同对象