用户直接编辑结果后，系统在后续轮次中必须尊重这些改动
别名: 尊重手工改动 · 编辑被覆盖 · sticky human edits
概念解释
用户把草稿里的公司名从错误的「华腾」改成了「华腾新能源」，下一轮只说「再短一点」。生成把名字改回了「华腾」，因为模型仍以自己上一份输出为条件，没把人的键入当成新的事实。后续轮次必须尊重就地改动（respecting in-place user edits）。不尊重，编辑器就是临时的：人改了等于没改，下一次生成会覆盖劳动。
这不是「生成不要动未提及的部分」那种一般副作用，而是一条更硬的规则：人已经写进去的字符，是对系统输出的否决，默认不可再生成回去。
机制
多轮生成的默认状态是「最新模型输出」。用户键入若只改了屏幕上的 DOM、没有写回对话状态，下一轮请求带出去的仍是模型自己的上一份。即使用户改动被拼进了提示，模型仍可能把它当成可润色的草稿，用更「顺」的旧名字覆盖。屏幕上的真源和模型的真源分裂了。
人把键入理解成提交事实。覆盖事实会被读成系统故意忘掉更正，伤害大于一次普通的乱改，因为它否定的是「我动手改过」这件事本身。之后用户会拒绝再在产品内编辑，改去外部文件，循环被打断。
怎么研究
协议分两段：先让人在产物上改一处事实（专名、数字、否定词），再发一条不提及该事实的修辞指令。检查该事实在新输出里是否原样保留。自变量：改动是否写入请求、是否被标成不可覆盖约束、指令与改动位置的距离。因变量：改动存活率、用户发现被覆盖后是否继续在产品内编辑。
覆盖有时是改了别的同义词而专名碰巧没了，要用对齐而不是字符串相等，避免漏计「华腾新能源有限公司」这种合法扩写；但缩回旧错名必须计为失败。
边界
用户改的是风格而不是事实（把「您好」换成「嗨」），后续「写得正式一点」应当允许改回敬语，否则尊重变成把一次试探锁死。需要区分事实性编辑与试探性编辑，可用显式标记，或用「改数字 / 改专名」这类类别当默认事实。协同场景里后写入的人可能覆盖先写入的人，那是权限问题，不是模型尊重问题。空改动（只敲了空格）不应当触发锁定。
怎么落地
- 把用户键入的跨度标成已确认事实，随请求作为硬约束带给后续生成，而不是只更新屏幕。
- 若后续指令与已确认事实冲突，停下来问该听哪一边，不要默默用模型输出覆盖键入。
- 覆盖一旦发生，提供「恢复我改过的那一处」而不是整篇撤销，并让那一处在 diff 里以「你写的」标出。
- 验证：在草稿里改一个专名，再连发三次不提该专名的指令。三次结果中专名必须保持用户的写法。任何一次回到模型旧名，记为覆盖事故。再看覆盖之后的编辑事件是否中断——中断说明人已经把产品内编辑判为无效。