本文基于开源项目 dsh-relationship（本地关系记忆工作台）的真实演进过程，文中所有代码与缺陷均可在仓库历史中核对。上一篇讲写入闸门，这一篇讲另一件事：AI 干活干到一半，卡住了，要问你一句话。

一次迟到的回答

关系记忆工作台有两个窗口：AI 住在一个对话窗里，你住在一个网页工作台里。

你在工作台贴了一段聊天记录，点了「AI 整理」。AI 在对话窗里吭哧吭哧拆条，拆到一半卡住了——这段内容好像和库里刚删掉的一条记忆有关，到底要不要重新登记？

它停下来，在对话窗里问你。

可你正盯着工作台。素材卡上还是"整理中"，再没有下文。它在等一个永远不会从这个窗口传来的回答，你在等一个永远不会出现的整理报告。两个人就这么互相等着，直到你失去耐心。

这段代码没有任何 bug。AI 反问没错，对话也是它唯一的出口。问题只有一个：消息到了其中一个窗口，而人在另一个窗口。

第一反应往往是"干脆禁止 AI 反问"。但这会把事情搞得更糟：素材和库有冲突时，让 AI 猜一个继续，比问一句危险得多。所以要解决的是两件事——反问怎么送到你眼前，以及什么时候才值得问。前者靠一条通道，后者靠一条规矩。

先立规矩：能不问，就不问

真正的第一步，还不是"怎么把反问送过去"，而是"别让 AI 逮着什么都问"。否则通道建得再快，也会被鸡毛蒜皮的问题淹没。

于是先立了一条规矩，写进 AI 的行为准则：

整理中不反问：判断全以当前库为准，已删除的素材与记忆视为不存在；库里没有的直接登记……只有真正卡死、不问就没法继续的矛盾，才问。

"直接登记"这四个字敢写进去，是因为背后有人兜底：就算 AI 判断错了，写入闸门会把它拦下来。 上一篇讲的"纪律必须能被代码核对"，在这里兑现成了——因为有代码兜底，所以敢让 AI 放开手脚。反过来，闸门拦不住、又不确定的事，才轮到人来拍板。反问的范围，天生就是"代码管不住的那一截"。

建一条"看见"的通道

真到需要问的时候，AI 先调一个工具，把问题"登记"下来。工作台那张素材卡上，随即浮出一条横幅「AI 在等你回答」，下面几个按钮，你点一下就算答了。

这一步登记不能省、也不能顶替——后来的行为准则里甚至专门补了一句：连宿主自带的提问工具都不行，因为只有登记过的问题，才会落到你真正盯着的那个窗口上。

这里还偷偷埋了个当时不起眼、后来救命的细节。每个按钮，除了给你看的一行字，背后还藏了一条给 AI 看的完整指令，带着素材编号和明确决定：

{ "label": "照常登记", "command": "素材 mt_xx 照常整理：当前库里没有这些记忆，直接全部登记" }

这条指令扔到任何一个对话里都能接着干，不依赖原来那个会话。当时只是让你点得省事，后来发现它救了整个设计。先记住这个伏笔。

到这儿，功能"完工"了：登记、横幅、作答、清除，主流程全通，测试全绿。

一次迟到但尖锐的审计

过了一阵，一份外部反馈指出了三个毛病。最让人服气的是它的提问方式——不是"感觉不稳"，而是三条能逐行核验的事实，每条带着代码行号。

第一条就戳中了命门。那段"作答"的代码里，不管发送成功还是失败，最后一步"清除横幅"都会毫不留情地执行：

} catch (e) { toast('发送失败', true); } // 只弹个提示 await api(`/api/materials/${id}/question`, { method: 'DELETE' }); // 无条件清除

复制失败的你，看到的是横幅消失、选项也没了，只能凭记忆回对话里重新组织语言。问题没有被解决，只是被系统假装解决了。 这就是"看得见"和"不丢失"之间那条缝——通道让你看见问题，却没保证你丢不掉它。

另外两条轻一些：登记只有一条，AI 换问题会直接覆盖旧的，你分不清"刚问的"和"已经答过在等的"；作答又不跟原会话绑定，可能发进一个从没见过这个问题的对话。

对着代码逐条核完，事实全对。但核对的过程还给了第二个收获：第一条是硬伤，后两条要校准严重度——作答虽然发错了对话，可因为指令是自足的，新对话照样能继续整理，功能没断，只是原来的对话永远悬着，下次苏醒可能重复干活。真实的代价不是"断链"，是"悬挂"。

而"断链"和"悬挂"之间，就差那个伏笔——那条自足指令。这就是先核对代码、再定严重度的意义：事实对了，严重度不一定对，两个结论都值钱。

补上"不丢失"

回头一看，第一次只做了一件事——让你看见反问，却完全没管它的生命周期。可靠性恰恰藏在生命周期里，取决于三个必须摊开回答的问题：什么算送达？谁有权清除？失败了躺哪儿？