一段问话发出去，几十秒后才发现有个词用错了。接下来的动作几乎是肌肉记忆：要么删掉重来，要么补一句「刚才那句应该是……」。两种都在花时间，区别只是花在哪一栏——前一种花在重写，后一种花在让模型重新理解一遍你其实想说什么。
消息撤回与气泡重编辑这类插件真正值得看的地方，不是「能不能改」，而是它把「改」这件事拆成了两个时间点：你在编辑器里敲字的时刻，和这段字真正进入模型上下文的时刻。两个时刻之间隔着一个按钮，所有手感差异都从这个间隔里长出来。本文讲的就是这两条时间线怎么走，以及走到哪里会断。
第一个断点：点下「确定」之后，什么都没发生
单击自己发出去的消息气泡，就地进入编辑态，框里是那条消息的原始 Markdown 原文，不是渲染后的样子。Esc 取消，Ctrl+Enter 确定——到这里为止，页面上的变化只有气泡变成输入框又变回去。
确认之后发生的事很克制：目标消息之后的回复被折叠隐藏，草稿回填到底部输入框，顶部多出一条「正在修改」标签条。对话内容、模型上下文、会话日志三样东西纹丝不动。你可以在这个状态下继续改字、切模型、换推理等级，也可以随时点 × 退回原样，退回时原草稿完好。
所以有一个反直觉的现象值得先说清楚：确定之后去会话历史里翻，是找不到这次修改的。不是没保存，是这条时间线还没走到落点。它保存的是「待定草稿」，不是「已改的消息」。理解这一点，后面的判断都会顺。
第二个断点：只有按下「发送」，上下文才被真正改写
真正的写入发生在你按「发送」的那一刻。此时的动作序列是：以目标消息所在回合的闭合边界为界截断，把新文本作为一条新提问发出去，原会话归档，同名新会话顶替。
这就是「无痕替换」的实际含义。你在界面上感知到的是「原来那条被编辑了」，而不是「凭空多出一个新会话」——因为顶替上来的会话名字一样、位置一样，旧的那份退到后台。需要补一句的是，归档不等于删除：原会话还在，入口在设置里的版本历史树，那条线上的每一版都能手动恢复。
同样在这个时刻，被撤回范围覆盖的后续提问一起消失。撤回确认胶囊会先告诉你代价——「撤回这条消息及其后 x 条提问？」，x 是实时统计出来的，只有当它是 0 的时候，提示才会变成「是否撤回这条消息？」。改中间某一轮，等于放弃那一轮之后的所有内容，这个数字是给你最后一次反悔机会的。
写了三遍才满意：一个上午的真实节奏
举个具体到有点琐碎的例子。上午要问一个接口的分页参数为什么在第二页开始重复返回第一条数据。第一版提问写的是「分页有 bug，第二页重复」，发出去得到的回复在讲前后端分页参数命名不一致，方向对了但没落到具体代码。
这时不回输入框重打，直接在第一个气泡上单击，把原话改成「page=2&size=20 时返回的第一条和 page=1 的第一条相同，怀疑 offset 少乘了一页」，模型选择下拉里换成推理等级更高的一档，重发。这一版准了，但回答太长，把整个查询构造过程都铺开了。
于是翻页器派上用场。新回答的操作区里出现 ‹ 2/2 ›，按一下 ← 回到第一版，再按 → 回来。两版并排看几眼，取第一版的短结论加第二版的边界条件，第三次编辑重发。翻页器变成 ‹ 3/3 ›，三个分支都在，后续上下文跟着当前选中的版本刷新。
整个过程里，输入框只被清空过一次——就是最初那次。后面两次都是原地改、原地重发，没有「复制原话、粘贴、再补一句」这套动作，也就没有把气泡撑成引用块堆叠的样子。
这条时间线会断在三个地方
第一处是回合没闭合。DSH 的 fork 只能在闭合回合边界截断，回复还在往外吐字的时候点撤回是无效的，界面会提示「该消息所在回合尚未结束」，得等这一轮跑完。想在生成中途打断换方向，用停止生成，不是用撤回。
第二处是覆盖模式下的草稿归属。设置里有一个回填冲突模式，选「覆盖」时，撤回或编辑的内容会直接占据输入框。原来的草稿并没有被丢弃，发送或取消之后会完整恢复，但如果你在这个中间态切去了另一个会话再回来，很容易以为草稿丢了。多会话并行的人，把这一项改成非覆盖模式会省掉一次心慌。
第三处是备份的时间窗。待定草稿要连续十秒没有处理、并且又有新变动，才会覆盖备份到 $DSH_HOME/dsh-easyrewrite/backups/<会话ID>.json；处理完成即删。写完最后一句立刻崩溃的那几秒，不在备份覆盖范围内——它防的是「写了一半跑去干别的」，不是防断电。
先改还是先发，取决于你改的是不是同一件事
如果改动只是把话说清楚，让它更贴合你脑子里的那个问题，那么走「原地改 + 重发」这条时间线更划算：一次编辑换掉整段后续，历史里不会留下「更正：刚才那句」这种补丁。
如果改动其实是换了个问题——原来问「为什么会重复」，现在想问「怎么绕过」，那就别用撤回，直接开新会话。截断掉的那几轮里可能有你还没读懂的线索，翻页器能帮你回去看，但两条不同的问题硬塞进同一条时间线，读起来会别扭。
总结
改一句话的成本不在敲字，而在「什么时候真正落地」这一步：确定只落草稿，发送才落上下文，认准这两个时刻就不会被折叠的回复和消失的历史吓到；想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：每天要在同一条会话里反复打磨提问口径的人；需要在几版回答之间来回比对、挑一个折中版本再继续的场景；带图提问、改字时不想把图片重新上传一遍的工作流；多人共用一台机器、草稿必须能跨刷新接续的环境。
不适合：主要在桌面端或终端里用 DSH 的人，这套交互只存在于 Web 消息层；宿主常年停在 0.1.1-rc.2 及更早、又不打算升级的实例，2.6.0 只声明适配 0.1.7-rc.1+ 与 0.1.2-rc.1+ 两代；要求安全结论明确的团队，它的扫描结果是「含敏感能力、尚无人工评估」，不是一纸安全背书。
标签：消息撤回重编辑、DeepSeek Harness、应用实践、会话版本管理
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。