返回答案，不等于完成任务
这次遇到的问题，表面上很像一个普通的自动化发送失败：我给一个已经存在的会话发问题，程序也返回了答案，回执里还有“正在生成”的状态。按很多人的第一反应，这可能只是等待时间不够，稍后再取一次就好。
但我把回执里的信息放在一起看，立刻发现了不对。请求指定的是一个目标会话，返回的会话却是当时页面正打开的另一个会话；问题匹配结果也是假，答案内容还属于另一个正在进行的任务。更严重的是，原问题后来没有出现在目标会话里。也就是说，系统不是“回答慢了”，而是根本没有证明自己把问题送到了该去的地方。
自动化调用的成功，不应该由“有没有返回文本”决定，而应该由“文本是否来自被请求的目标”决定。
这件事让我重新意识到，人工操作时我们会凭页面标题、上下文和直觉发现串线，程序却可能只看见一个非空字符串。如果它把非空字符串包装成成功回执，错误就会从一次可见的失败，变成一次很难追查的静默误导。
真正危险的是静默串线
多账号、多会话自动化最容易制造一种错觉：页面是打开的，输入框也能输入，发送动作似乎发生了，最后还拿到了一个看起来完整的答案。每一步单独看都像正常，组合起来却可能已经换了身份、换了会话，甚至换了任务。
当时页面从目标会话漂回了另一个打开中的会话。程序原本只在导航后检查过一次会话编号，后面页面发生漂移，它却继续输入、点击发送，并在等待超时时把当前页面上的旧消息当成了本次发送的证据。于是回执里出现了一个很容易误读的状态：像是消息已经发出，只是回答还没结束。
如果不处理，这会导致比“没有答案”更麻烦的后果。后续流程可能根据错误答案继续执行；操作者会以为目标会话已经收到问题，于是重复发送；当真正的问题没有留下记录时，排查者又只能回头猜是网络、模型还是页面出了问题。错误发生了，证据却被一张成功形状的回执遮住了。
这里最容易误判的是把“页面当前显示什么”当成“请求指定了什么”。前台页面只是一个共享的载体，它有自己的加载、切换和刷新时机，不能替代调用参数里的目标身份。
我先把一次投递拆成几层
我没有继续围绕“为什么这次答案不对”猜页面细节，而是把一次自动提问拆成发送前、发送中和回收后三个判断。
发送前，先绑定账号、会话和问题指纹。账号回答“用谁的身份做”，会话回答“送到哪里”，问题指纹回答“这次页面里回显的是否正是这一问”。这3个条件缺一不可。只绑定账号，不足以保证进入了正确会话；只绑定会话，也不能证明输入框里的内容没有被旧文本污染。
发送中，在导航完成后再次核对当前会话；准备输入前再核对一次；真正点击发送前，还要确认当前页面仍然属于目标。目标会话的身份校验必须贴近发送动作，而不能只在流程开头检查一次。
回收时，至少逐项核对会话编号、问题匹配、生成状态和内容归属。会话编号不一致，说明回答来自错误位置；问题匹配为假，说明这次问题没有被当前页面确认；生成状态只能说明页面还在生成，不能证明生成的是本次请求；答案内容即使读起来合理，也必须先确认它属于目标会话。
这个拆分很重要，因为每一层回答的是不同问题。发送成功不代表问题被正确接收，问题被接收不代表回答已经完成，回答完成也不代表它属于当前请求。把这些状态揉成一个“成功”，就是给串线留下了入口。
我也会把“未确认”当成一种有意义的结果，而不是尴尬的中间态。它准确表达了当前证据到哪里为止：系统知道自己没有证明投递完成，但还不知道问题究竟丢在导航、输入还是发送环节。这样的边界比编造一个确定结论更有价值，因为它让下一步定位有明确起点。
错误捷径为什么会把问题放大
最容易走的错误捷径，是只检查接口有没有返回文本。它实现起来最省事，也最容易让测试通过：只要答案字段非空，就返回成功。可是在多会话环境里，答案本身并没有自带归属。另一个任务的答案也可能非常完整，甚至刚好回答了一个相似问题。
另一个错误捷径，是把当前前台打开的会话当成目标会话。这样做等于把用户的视觉焦点当成程序的身份凭证。页面在切换、刷新或被其他动作复用时，这个假设就会失效。更隐蔽的是，旧消息数量增加也不能证明本轮消息已经发出；历史消息一直在那里，数量变化并不等于本次投递完成。
我选择失败即红，是因为这类错误的重试代价和误报代价都不一样。一个明确失败的调用，会迫使操作者保留原始回执、重新定位目标，至少不会把错误答案继续传给下一步。一个看似成功但实际串线的调用，则会让错误沿着流程继续扩散，直到业务结果出问题才暴露。
所以，问题匹配为假时也必须失败。之前有人可能担心这个字段有噪声，担心严格判断会把已经完成的回答误判为失败。但如果字段代表“当前回收内容不是本次问题的回显”，继续返回成功就没有足够证据。宁可把需要人工复核的情况标红，也不要替未知状态盖章。
失败回执也要能帮助定位
失败即红并不等于只返回一个“失败”。如果回执没有留下请求会话、实际观察到的会话、失败发生在哪一步，下一次排查仍然只能靠猜。一次安全的失败应该保留原始观察结果，但明确告诉后续流程：这次没有完成可确认的投递。
我会把失败分成几种容易区分的情况。请求的会话和页面实际会话不同，属于目标不一致；会话一致但问题没有回显，属于投递未确认；问题已经回显但回答超时，才可以说消息可能已经送达、回答仍待回收。它们不能共用同一个“等待中”，因为后续动作不同：前两种不能安全重发，后一种也应当沿原会话取回，而不是再次发送同一个问题。
这也是为什么收尾处必须再做一次身份校验。即使发送前检查通过，页面也可能在生成期间漂移。如果最后拿到的答案来自另一个会话，程序应该丢弃成功形状，返回非零失败，并保留请求目标与实际目标的差异。原始回执不是给用户看的答案，却是给定位问题的人看的证据。
一个流程成熟的标志，不是它顺利时能返回答案，而是它在证据不足时能拒绝替自己证明成功。
下次我会怎么做
下次设计类似自动化流程，我会把方法固定成一条安全回执规则：发送前绑定账号、目标会话和问题指纹；导航后、输入前、发送前核对目标；回收时核对会话编号、问题匹配、生成状态和答案归属；任一项不满足，就 fail-closed，保留原始观察结果，不返回成功答案。
这套方法不只适用于聊天。只要一个页面同时承载多个账号、多个窗口、多个任务，当前可见内容就不能自动证明身份。邮件、工单、后台订单、客服队列都一样：真正要确认的不是“系统给了我一个结果”，而是“这个结果来自我刚才指定的对象”。
这件事让我更愿意把安全回执看成一种工作习惯，而不是一个额外技巧。我们当然希望自动化更快，但速度不能建立在省略归属判断之上。在多会话系统里，宁可多做一次身份核对，也不要让一个答得很像的错误答案穿过成功状态。