AI 输出不应该静默覆盖人的工作

在 Elosay 的沟通草稿实验里，我开始把一个看似很小的问题放到前面：当人已经手动改过文字，AI 下一次返回的结果凭什么直接替换它？生成质量当然重要，但即使候选写得更好，静默覆盖也会抹掉人刚刚完成的工作。

这不是一次已证实的生产丢稿事故。早期原型暴露的是覆盖风险，旧应用也没有同样的可编辑稿能力。后来的实验把它做成了可验证的控制边界。我想记录的是这段设计变化，以及为什么“模型别覆盖”不是一句提示词就能解决的事。

等待期间，人的稿子仍然在变化

发送请求的时候，系统拿到一个草稿快照。模型还在生成，人可能删除了一句不合适的承诺，补了条件，或者只改了一个金额。等响应到达，当前稿已经不同于请求时的稿子。网络返回顺序也未必等于用户操作顺序。

如果把每次成功响应直接写回编辑区，用户需要记住自己刚才改过什么，再检查哪些改动消失了。取消后晚到的响应、前一次请求的重复返回，也可能让已经结束的操作重新影响当前内容。界面看起来很流畅，恢复成本却落在人身上。

我现在把这个问题看作对编辑权的分配。异步任务结束，只能说明一个候选已经可用；它不能说明用户同意放弃当前稿，更不能说明候选对应的仍是此刻的要求。

实验因此把手稿、请求和候选分开。人继续修改当前稿，AI 的结果先展示为候选。采用之前不替换当前文字；用户可以采用，也可以放弃。这增加了一个显式动作，却让替换发生在能看见、能选择的位置。

晚到响应需要由请求身份和状态决定是否仍有效，不能交给模型理解“这是旧请求”。取消和失败也不应清空手稿。重试绑定原来的请求快照；如果用户想按最新手改稿重新生成，应发起一个新的生成动作，避免把“重试”变成含义不明的重新提交。

我不想把所有差异都做成复杂比较器。这个阶段最必要的事情，是让人明确知道现在编辑的是哪一份，模型提出的是哪一份，以及按下采用会改变什么。单是这层归属，就比自动把结果塞回去更容易解释。

另一个容易忽略的问题在对话历史。如果候选还没被采用，服务端已经把它当成有效输出写进历史，那么界面上虽保住了手稿，下一次模型仍可能沿着被放弃的版本继续写。用户说“不要这版”，系统却在看不见的地方接受了它。

当前实验先暂存候选，明确采用后才提交相应输出；放弃不把 AI 输出加入已采用历史，但会保留该次用户要求，并标明候选已经放弃。放弃一个答案，并不一定表示撤销了人的请求，二者的区别仍需要模型根据实际语境理解。

“撤销采用”也不只是把屏幕文字换回去。实验同时恢复采用前的草稿、历史和未提交要求，否则下一次生成的依据会与用户看见的内容分离。普通键盘改字的撤销和一次候选采纳的撤销，各有自己的边界。

本轮有自动测试、原生集成和真实界面操作，观察了手改保留、采用、撤销、放弃与复制等路径。精确竞态主要由自动与集成测试验证；不能把一张界面截图说成证明了所有返回时序。最后补丁之后的部分故障恢复，以及中文输入法和跨应用操作，仍有待人工验收。

更重要的是，模型语义可靠性没有因此通过。实验中的真实输出仍出现未授权通知承诺、概率加强、条件遗漏和要求丢失。最后一次真实界面生成也没有满足结论前置要求，我保留了失败并放弃候选。显式采用能保护控制权，不能认证文字含义正确。

如果为了追求少点一次，把这些错误更快地复制出去，人的整体工作未必减少。现在没有证据证明这个实验缩短了完整任务时间，也没有人工签收证明它比熟悉的工具更省心。

当前恢复只在应用进程内有效。退出或崩溃后的会话没有持久化保障；本地文字能恢复，也不等于旧服务端历史已经恢复。这些限制需要留在体验说明里，不能因为做了撤销按钮，就把它称作完整版本管理。

我暂时选择保留这套候选机制，继续验证它能否减少检查和返工。它让我把一个问题说得更清楚：AI 可以建议下一版，人仍拥有当前稿。以后若要扩大自动化，也需要新的授权和恢复证据，不能从“生成成功”顺手推到“可以替人决定并发送”。